Re: [PATCH linux v5 15/18] drivers/fsi: Add GPIO FSI master

[Christopher Bostic <christopher.lee.bostic@gmail.com>]

>
> Say if we have a FSI master with two links, we would have four cells
> for all the *-gpios properties:
>
>      fsi-master {
>          compatible = "ibm,fsi-master", "ibm,fsi-master-gpio";
>          clk-gpios = <&gpio 0 &gpio 6>;
>          data-gpios = <&gpio 1 &gpio 7>;
>      }
>

Hi Jeremy,

One thing I don't understand is the numbering conventions.   What does
6 and 7 represent in this case?
There are five pins total 0-4 for the existing gpio master.  I've
followed the numbering as is listed here
in the latest patch set I'm submitting this afternoon.

> - and the binding would remain as is (just that we should use the plural
> of gpios for the property names, to make this a little more sensible).
>
> This could also be represented as two separate master nodes:
>
>      fsi-master {
>          compatible = "ibm,fsi-master", "ibm,fsi-master-gpio";
>          clk-gpios = <&gpio 0>;
>          data-gpios = <&gpio 1>;
>      }
>
>      fsi-master {
>          compatible = "ibm,fsi-master", "ibm,fsi-master-gpio";
>          clk-gpios = <&gpio 6>;
>          data-gpios = <&gpio 7>;
>      }
>
> Our choice there would depend on the hardware layout. Does is make more
> sense to represent this as two independent masters? Or a single one?
> Would there ever be any shared state between those two masters that a
> driver needs to handle?

Up until now, all available FSI masters in hardware,  FSP, P8 "hub", P8 cascade,
P7 cascade, have all had multiple links controlled by one master.   It would
make sense I think to continue this.

There is no direct sharing of information between masters other than what's
required by the firmware to start at the beginning master in the chain and
walk down each link  and checking 'sub' master states to determine where an
interrupt or error was sourced.

General flow:
Identify on which link interrupt / error was reported.
Look at each CFAM on that link to see if it was reported locally or downstream
if downstream,  Look at the cascaded master's owned links to see which
reported.  Etc..

In my opinion that type of master to master information is better kept separated
as it is in the interests of keep a general design common between real hardware
FSI masters such as the FSP's and the gpio type master implementations.

>
> Once we've settled that, we will need the device tree binding people to
> take a look, which just involves CCing devicetree-discuss@ozlabs.org for
> patches that modify Documentation/devicetree/*.
>
Will keep them off the cc list for now until we all agree which way we go.

Thanks,
Chris