On Mon, May 30, 2011 at 2:53 PM, Mitch Bradley [off-list ref] 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.

g.

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