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

Grant Likely grant.likely at secretlab.ca
Thu Jun 2 11:40:05 EDT 2011

On Mon, May 30, 2011 at 2:53 PM, Mitch Bradley <wmb at firmworks.com> wrote:
> Perhaps the interrupt-mapping binding is not the best model.  Interrupt
> hardware in general is hierarchical but is not isomorphic to the physical
> addressing hierarchy of the device tree.
> 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>;
>                 }
>        };
>        [...]
>        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.
> 3) 0 or more mode cells, according to the value of #mode-cells in the
> referenced node.

I can see having nodes for individual gpios being useful in
circumstances, but I really don't like having multiple methods of
specifying a gpio (handle to the gpio-controller, or a handle to the
gpio node, and a different specifier depending on the contents of the
target node).  I think it will be less confusing for users if the
reference is always to the gpio controller.  A specific gpio
controller can still use child nodes to capture extra information
about specific gpios, but doing so doesn't need to be exposed to a
gpio consumer; it can all be internal to the gpio controller and its
hardware specific binding (since any mode details are going to be
hardware specific anyway most likely).

[Amending to the above which was written before you latest post: even
with the refined proposal to link to only a child node, the gpio
specifier still changes depending on the contents of the child node]

If a gpio controller does use child nodes, then I do like the approach
of using #{address,size}-cells to line up with gpio numbering.
However, we've already got a definition of #gpio-cells in use which
specifies the total number of cells for a '*-gpio' property binding,
so I do want to take care not to conflict with the existing pattern.
I suspect the solution would simply be to state that #gpio-cells >=
#address-cells must be true.

> 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.
> <&gpio-controller1 13 0 55 77>  -  refers to a GPIO controller node,
> specifing the address (13 0) and the mode (55 77) in the client's GPIO spec.
> <gpio2>  -  another reference to a gpio node on a different controller.  In
> this case the address (4) is bound in the gpio node, but the mode (88) is
> passed in from the client's GPIO spec.
> <&gpio-controller2 5 1>  -  another reference to a controller node, with a
> one-cell address (5) and a one-cell mode (1), according to the values of
> #address-cells and #mode-cells in that controller node.
> I expect that the "pre-bound gpio node" case would get a lot of use in
> practice, as it lets you isolate the client from the details of the
> interrupt controller addressing and modes.  In my experience, GPIOs often
> get reassigned between revisions of the same board, especially early in the
> development cycle.

I'm not convinced that the pre-bound gpio node will be any better or
worse from a usability standpoint that direct references.  I've
certainly not had problems with keeping up with gpio moves (and
everything else moving) on the FPGA projects that I've worked with.


Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

More information about the linux-arm-kernel mailing list