Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1562203 > unrolled thread

Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based  FSI master Rob Herring <robh@kernel.org> - 2017-01-18 23:00 +0100
    Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based  FSI master Jeremy Kerr <jk@ozlabs.org> - 2017-01-19 03:20 +0100

#1562203 — Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master

On Thu, Jan 12, 2017 at 04:35:43PM -0600, christopher.lee.bostic@gmail.com wrote:
> From: Chris Bostic <cbostic@us.ibm.com>
> 
> Define the device tree bindings for the GPIO master type.
> 
> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
> 
> ---
> 
> V2 - Break out this documentation update from the code implementing
>      The GPIO master function.
> 
>    - Move the documentation to an earlier patch than the code
>      implementing the function.
> 
>    - Document all 'compatible' strings used in the series.
> 
>    - Write binding document in terms of hardware, not software.
> 
>    - Elaborate on what a GPIO based FSI master is versus a non
>      GPIO based master.
> 
>    - Give a more detailed description of what each pin in the GPIO
>      FSI master is to be used for.
> 
>    - Re-order compatible strings in example so that most specific
>      comes first.
> 
>    - Indicate the proper order each pin should be initialized.
> 
>    - Fix an unmatched '>' bracket in the example for binding.
> 
>    - Bracket each element of the example list items individually.
> ---
>  .../devicetree/bindings/fsi/fsi-master-gpio.txt    | 71 ++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
> 
> diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
> new file mode 100644
> index 0000000..5d589bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
> @@ -0,0 +1,71 @@
> +Device-tree bindings for FSI master implemented with GPIO
> +---------------------------------------------------------
> +
> +Typically a FSI master is defined in hardware with output control
> +lines designated for Enable, Data, Clock, etc..  In the case of
> +a 'GPIO FSI master', however, it may be the case that there is no
> +such master defined in hardware and must be implemented in standard
> +GPIO to interact with its slaves.  In this 'virtual' FSI master
> +case the GPIO pins representing clk and data are directly
> +connected to the slaves.
> +
> +The GPIO FSI master node
> +-------------------------
> +This node describes a FSI master implmented with GPIO.
> +Required property:
> +	compatible = "ibm,fsi-master-gpio"

Generally, we don't have a vendor prefix for GPIO based implementations.

> +
> +The standard FSI master node
> +----------------------------
> +This node describes a FSI master implmemented fully in hardware
> +with dedicated input/output pins required for its function (i.e.
> +not using generic GPIO pins).
> +Required property:
> +	compatible = "ibm,fsi-master"

This and GPIO binding should be in 2 docs.

> +
> +
> +GPIO FSI master property/pin descriptions
> +------------------------------------------
> +clk -	The master controlled clock line that indicates to the
> +	slave when to read in or send out new data - required.
> +data -	The serial data line containing information to be sent or
> +	received by the master.  This line is bi-directional.  During
> +	command phase the master controls the line and when a response
> +	is required the slave takes control - required.
> +enable - Controls power state of data line - optional.
> +trans - Voltage translator control. In some applications the data line
> +	must have its signal levels altered by a translator. If this is
> +	necessary then control of signal direction is managed via this
> +	line - optional.
> +mux -	Multiplexor control.  This activates/deactivates the data line
> +	in cases where it is one of many possible selections via mux -
> +	optional.

Combine these descriptions and the property names, grouped as below.

> +
> +Required properties:
> +	- compatible = "ibm,fsi-master-gpio";
> +	- clk-gpios;
> +	- data-gpios;
> +
> +Optional properties:
> +	- enable-gpios;
> +	- trans-gpios;
> +	- mux-gpios;
> +
> +Order of property activation:
> +1. clk
> +2. data
> +3. trans
> +4. enable
> +5. mux
> +
> +
> +Example:
> +
> +fsi-master {
> +	compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";

From the description, these should be mutually exclusive.

> +	clk-gpios = <&gpio 0>, <&gpio 6>;
> +	data-gpios = <&gpio 1>, <&gpio 7>;
> +	enable-gpios = <&gpio 2>, <&gpio 8>;
> +	trans-gpios = <&gpio 3>, <&gpio 9>;
> +	mux-gpios = <&gpio 4>, <&gpio 10>;
> +}
> -- 
> 1.8.2.2
> 

[toc] | [next] | [standalone]

#1562380

Hi Chris,

From this:

>> +
>> +The standard FSI master node
>> +----------------------------
>> +This node describes a FSI master implmemented fully in hardware
>> +with dedicated input/output pins required for its function (i.e.
>> +not using generic GPIO pins).
>> +Required property:
>> +	compatible = "ibm,fsi-master"

and this:

>> +Example:
>> +
>> +fsi-master {
>> +	compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";
> 
> From the description, these should be mutually exclusive.

I agree with Rob here. The intention is for "ibm,fsi-master" to be an
abstract master -- simply indicating that this node describes a master,
with no specific implementation, and "ibm,fsi-master-gpio" to be a
GPIO-based implementation. A hardware-based FSI master would have a
different compatible value, based on the hardware.

We should remove references to implementations in the "The standard FSI
master node" section, because this is independent of implementation.

>> +	clk-gpios = <&gpio 0>, <&gpio 6>;
>> +	data-gpios = <&gpio 1>, <&gpio 7>;
>> +	enable-gpios = <&gpio 2>, <&gpio 8>;
>> +	trans-gpios = <&gpio 3>, <&gpio 9>;
>> +	mux-gpios = <&gpio 4>, <&gpio 10>;

Do we support multiple-link masters? This example implies a 2-link
master.

Cheers,


Jeremy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web