Re: GPIOs not correctly exported via sysfs on ATSAMA5D2

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Mon, Mar 02, 2020 at 09:39:59AM +0100, Uwe Kleine-König wrote:
> On Fri, Feb 28, 2020 at 11:58:21AM +0100, Romain Izard wrote:
> > Hello,
> > 
> > While experimenting with a new chip, I connected it on the SDIO
> > interface on my board based on a SAMA5D2 SoC. For a first step, I need
> > to drive the pins on the SDIO bus at a given level to program this new
> > chip. To do so, I tried to control the GPIO lines manually by unbinding
> > the SDHCI controller, and using /sys/class/gpio/export to control the
> > pins, with the following code:
> > 
> > echo a0000000.sdio-host > /sys/bus/platform/drivers/sdhci-at91/unbind
> > echo 4 > /sys/class/gpio/export
> > echo low > /sys/class/gpio/PA4/direction
> > 
> > Unfortunately, the state of the pin does not change and it remains
> > driven to 1. I checked the configuration register with devmem2, and it
> > appeared that the selected function remains the SDIO function even after
> > calling export.
> > 
> > The issue does not appear when I use a GPIO in a driver with an explicit
> > pinctrl configuration in the device tree, which explains why I did not
> > see it until now.
> > 
> > The kernel version used is Linux 5.4.22
> > 
> > Is this a user error from my part, or is there something missing in the
> > AT91 PIO4 pinctrl driver ?
> 
> IMHO this is all as expected. There are gpio controllers that
> automatically mux the matching pin, but you must not expect that.
> 
> My personal opinion on this is, that the downside of this automatic is
> worse than its benefits:
> 
>  - It's not universal, as there are SoCs that don't have a single pin
>    for a given GPIO, so you cannot reliably implement it for all
>    controllers.
> 
>  - Sometimes it is useful to make use of a GPIO and a dedicated function
>    on the same pin in a driver (e.g. an i2c driver might need to switch
>    to gpio to do a bus recovery). The automatic pinmuxing then has
>    strange side effect because you have to remux the pins after
>    requesting the GPIOs even if you didn't drive the pins as GPIO and
>    there is a short time where the pin function isn't the dedicated
>    one.

It's worse than that for the i2c driver.  The pins are muxed to the i2c
function when the driver binds.  When the i2c driver claims the GPIOs
corresponding with those pins, they get switched to GPIO mode behind
the back of pinctrl.  You then have to _explicitly_ switch pinctrl to
GPIO mode and back to I2C mode to get them back to I2C mode.

Merely requesting I2C mode after claiming the GPIOs doesn't do anything
- the pinctrl layer thinks they're still in I2C mode, and ignores the
call.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up