On Wed, Nov 13, 2013 at 4:20 PM, Ben Gamari <bgamari.f...@gmail.com> wrote:
> Linus Walleij wrote,
>> I think what Mark is saying is that you should not define a new node
>> for exports, but instead use the node for the gpiochip and extend
>> those existing gpiochip bindings, if you want to do this.
>>
> What might this look like? Should each exported pin have a node under
> the gpio-controller?
Maybe that is a good idea.
> If we want to allow for pins to be exported to
> userspace, a name alone is not sufficient; we also need to provide the
> allowed directions. I think this precludes the use of a plain /aliases
> node.
Sure.
> Perhaps something like this (please excuse my ignorance of devicetree
> norms)?
>
> gpio1: gpio-controller@1400 {
> #gpio-cells = <2>;
> compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> reg = <0x1400 0x18>;
> gpio-controller;
>
> pin_a: gpio {
> gpio-name = "pin-a";
We should not use names like "pin" because the pin controller
subsystem deals with pins. GPIO is about "lines". But I get the
idea.
> gpio = <&gpio1 2 0>;
You don't need to state the parent when you're a child of the same
controller, as you say yourself in the end.
> output;
> init-high;
This is essentially the GPIO hog concept that I've been talking
about before.
I.e. I think we should specify whether this is an export or not
and make this mechanism available also for non-exported pins
in that case.
I would like it to look like this:
line-a: gpio-hog {
gpio = <2 0>;
export-line; // export to userspace
line-name = "foo";
hog-as-output;
hog-init-high;
};
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
