On Thu, Feb 14, 2013 at 2:01 AM, Linus Walleij <[email protected]> wrote:
On Thu, Feb 14, 2013 at 1:41 AM, Stephen Warren <[email protected]> wrote:
On 02/13/2013 05:34 PM, Doug Anderson wrote:
A little torn here. It adds a bunch of complexity to the code to
handle this case and there are no known or anticipated users. I only
wish that the GPIO polarity could be more hidden from drivers (add
functions like gpio_assert, gpio_deassert, etc)...
Yes, that would be nice. Alex, LinusW?
OK so good point since Alex is rewriting the way the external
API to GPIOs is done.
So this is one of the evolutionary artifacts of the GPIO subsystem:
that it has this concept of clients having to know if they want to
drive the line low or high.
Either way somewhere in the system the knowledge of whether
the low or high state counts as asserted must be stored.
Interestingly this knowledge is already more or less stored in GPIOlib -
all GPIOs descriptors have a FLAG_ACTIVE_LOW, but it can only be set
through the sysfs interface does not affect the in-kernel APIs. It does
affect what is returned by the "value" sysfs node, though.
If we are to introduce something similar for the in-kernel interface, it
would be nice to keep it consistent with the sysfs behavior, otherwise
it will become a nightmare to maintain two different polarity settings
for in-kernel and sysfs interfaces. The introduction of the gpiod
interface could be helpful here. Since it would work with descriptors
obtained through gpiod_get(device, consumer), the polarity could be set
transparently from either the DT or platform data (which would then have
a "flags" member). Then gpiod_set_value/get_value would take it into
account, and behave just like the sysfs interface.
So, in short:
- old gpio_* interface would *not* be polarity-aware
- new gpiod_* interface *would* be polarity-aware (and get the settings
from DT/platform data)
This looks simple but I don't have enough altitude to be sure we won't
hit some walls by doing so.
This would make the new gpiod and legacy gpio interfaces behave
differently, but at the same time is a good opportunity to have the
behavior as sysfs.
An undesirable side-effect would be that the legacy gpio interface could
not be built as a simple wrapper around gpiod anymore. That's sad, but
presenting interfaces that make sense is more important.
As a side-note, there is also this gpio_sysfs_set_active_low() public
interface that only mach-at91 seems to use (once!). Maybe we could try
to get rid of it?
Alex.
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
