[RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's from the device tree.

[Stephen Warren]

Mitch Bradley wrote at Monday, May 30, 2011 2:53 PM:
> ...
> GPIOs share the need to "point across the tree to different nodes", but
> it is unclear that there is a need for a entirely different hierarchy.
> 
> That suggests the possibility of using the device tree addressing
> mechanism as much as possible.  Normal device tree addresses could be
> used to specify GPIO numbers.
> 
> Suppose we have:
> 
>     gpio-controller1: gpio-controller {
>         #address-cells = <2>;
>         #mode-cells = <2>;
>         gpio1: gpio at 12,0 {
>             reg = <12 0>;
>             mode = <55 66>;
>             usage = "Audio Codec chip select";  /* Optional */
>         }
>     };
>     gpio-controller2: gpio-controller {
>         #address-cells = <1>;
>         #mode-cells = <1>;
>         gpio2: gpio at 4 {
>             reg = <4>;
>             #mode-cells = <1>;
>         }
>     };

A quick note on the way that Tegra's devicetree files are broken up in
Grant's devicetree/test branch:

* There's "tegra250.dtsi" which defines everything on the Tegra SoC
  itself.
* There's a per-board e.g. harmony.dts which includes tegra250.dtsi,
  And additionally:
  ** Defines all devices on the board
  ** Hence, defines the usage of e.g. all the Tegra GPIOs for the
     board.

I like this model, because it shares the complete definition of the
Tegra SoC in a single file, rather than duplicating it with cut/paste
into every board file.

As such, the code quoted above would be in tegra250.dtsi.

This has two relevant implications here:

1) The names "gpio1" and "gpio2" would be driven by the Tegra SoC's
naming of those GPIO pins, and not any board-specific naming, e.g.
"tegra_gpio_px1", "tegra_gpio_pb5". Equally, the usage comment would
be at the client/reference site, not the GPIO definition site.

2) The GPIO mode should be defined by the client/user of the GPIO, not
the SoC's definition of that GPIO.

Without those two conditions, we couldn't share anything through
tegra250.dtsi.

Re-iteration of these implications below.

>     [...]
>     chipsel-gpio =  <&gpio1>,
>         <&gpio-controller1 13 0 55 77>,
>         <0>, /* holes are permitted, means no GPIO 2 */
>         <&gpio2 88>,
>         <&gpio-controller2 5 1>;

> A GPIO spec consist of:
> 
> 1) A reference to either a gpio-controller or a gpio device node.
> 
> 2) 0 or more address cells, according to the value of #address-cells in
> the referenced node.  If the node has no #address-cells property, the
> value is assumed to be 0.

I'd expect address cells only if referencing a gpio-controller; if
referencing a gpio device node, the address would be implicit.

> 3) 0 or more mode cells, according to the value of #mode-cells in the
> referenced node.

Yes, I agree. Although, I think your (3) is inconsistent with the gpio
controller definitions you wrote above, which include the mode
definitions in the controller instead of the user.

> In the example, the chipsel-gpio specs are interpreted as:
> 
> <&gpio1>  -  refers to a pre-bound gpio device node, in which the
> address (12 0) and mode (55 66) are specified within that node.

Just re-iterating: I'd prefer mode to be solely in the reference, and
not in the gpio controller.

Does this SoC/board segregation make sense to everyone? Obviously it
does to me:-)

-- 
nvpublic