Re: Accessing GPIOs from userspace using recent kernels

[Tony Lindgren <tony@atomide.com>]

* Linus Walleij <linus.walleij@linaro.org> [140523 04:36]:
> On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett <peter@peter-b.co.uk> wrote:
> > The current call chain seems to be: gpiod_export() --> gpiod_request() -->
> > omap_gpio_request().  Looking at other GPIO drivers, it seems like
> > omap_gpio_request() should eventually call pinctrl_request_gpio().  Would be
> > useful if someone who knows about OMAP4/gpio/pinctrl could take a look at
> > this.

If we do this, we also need a solution to prevent automatic remuxing
of GPIO pins from happending. For wake-up events, some drivers need
to remux a rx pin to GPIO input for the duration of idle, and then
back to device rx pin. This is needed on some other platforms too
AFAIK.

For the drivers needing GPIO wake-up events, request_gpio is done in
the driver after drivers/base/pinctrl.c has already muxed the device
pin to rx. At minimum we would get warnings about reserved pins if
we tried to automatically mux them to GPIO.

We may be able to use some GPIO specific property to prevent
automatic remuxing as we discussed in the #armlinux few days ago.

Related to automatic remuxing of GPIO pins, there are also other
needs for pinctrl and GPIO interaction. We need to remux GPIO output
pins to input + pull + safe_mode to prevent the GPIO pins losing
value briefly during off-idle. That's the gpio errata 1.158 at as
shown at least at [1]. Because the GPIO to pinctrl mapping is
sparse and SoC specific, there's currently now obvious way to do
that. And we would need few new GPIO functions to tell pinctrl
subsystem about the change.

Regards,

Tony


[1] https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch