On Mon, May 30, 2011 at 2:53 PM, Mitch Bradley <wmb@xxxxxxxxxxxxx> 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@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@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
