Hi Russell,

On Thu, Aug 31, 2017 at 11:22 AM, Russell King - ARM Linux
[off-list ref] wrote:

On Thu, Aug 31, 2017 at 09:30:54AM +0200, Geert Uytterhoeven wrote:

quoted

quoted

Note that on my side, I've however not been convinced by this semantic:
I find it weird that when you request a GPIO, it gets automatically
muxed as such, without an explicit pinctrl configuration in the DT.

On lots of hardware, you first have to select between GPIO and "other
function".
For "other function", you have to select the actual function later.
In that case, switching to a GPIO can be done by flipping a single bit.

What about hardware which you can configure for some alternate function
but still monitor the pin via GPIO, even though it's not mux'd as GPIO.

For instance, you may have a timer block which can capture on both
edges of an external event signal, which needs the pin to be muxed for
that function.  However, you need to read the state of the pin, and
that is only available through GPIO.  Muxing the pin to be a GPIO just
because someone requests the GPIO is, imho, ill thought-out and breaks
some use cases.

Yes, reading from the GPIO can work if the pin is muxed to another function.

IMHO, the pinmux settings should always be specified in DT, and that's
what we should be using everywhere, not doing broken backdoor games like
"the gpio is being requested, it's obvious that we want this pin to be
a gpio" - that really doesn't follow.

Do we need to specify pinmux setting for pins used by e.g. the SDRAM
controller, which doesn't have a Linux driver?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds