On Thu, Aug 31, 2017 at 10:22:12AM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 31, 2017 at 09:30:54AM +0200, Geert Uytterhoeven wrote: > > > 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. > > 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. This doesn't really work anymore if you throw into the mix hardware controllers that don't have muxing options for "a GPIO", but different muxing options for input and output. For pins that could change direction, you cannot just specify it in the DT anymore. And that's leaving out the user-space interface issue. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
