Re: Confusion about Pinctrl and GPIO

From: Linus Walleij
Date: Tue Jan 07 2014 - 14:02:24 EST

On Thu, Dec 26, 2013 at 5:56 AM, æèè <caorr1980@xxxxxxxxx> wrote:

> I have read the latest Documentation/pinctrl.txt, and there is two examples
> about muxing logic in "GPIO mode pitfalls" section, let me take example A
> for instance:
> pin config
> logic regs
> | +- SPI
> Physical pins --- pad --- pinmux -+- I2C
> | +- mmc
> | +- GPIO
> pin
> multiplex
> logic regs
> Assuming that the pin has been configured as SPI mode, undoubtedly we can't
> use it as GPIO any longer. However, if we call gpio_request() (gpiolib API)
> to requet this pin for GPIO purpose, gpio_request() still can return
> successfully. I think this is unreasonable, gpio_request() should return an
> "error code" if the pin is in-use by PINMUX.

Yes but there is also example (B) where it is perfectly possible
to use the same pin as GPIO and for a device at the same time.
So that case needs to be supported as well.

> I read the codes of pin_request() in pinmux.c, and guess
> pinmux_ops->gpio_request_enable() may be responsible to handle this use
> case, that is, to return an "error code" if the pin has been owned by
> pinmux.

Yes this is one way to fix this: let the driver impose such

> However, no drivers in drivers/pinctrl/ implements such codes in
> pinmux_ops->gpio_request_enable().

OK so what about you fix it for a driver you have a problem
with? :-)

> Or, pinctrl subsystem is just resposible to set the pin in GPIO mode, and
> gpio subsystem (gpiolib) is responsible for other things like set direction,
> get value if input, or set high/low if output. Is my understanding right?

The pinctrl subsystem is responsible for all muxing, and the GPIO
subsystem drives and reads GPIO lines yes.

> Let me talk about the example described by Stephen. If actually only 4 pins
> of the group which contains 6 pins are needed by HW module, then why does
> the group be defined to contain 6 pins? I think the group should be defined
> only containing 4 pins rather than 6 pins, then the other 2 idle pins can be
> used for any other purpose.

Group definition should be done at the granularity needed to work
with the system mux configuration. Nominally the group definition
should reflect the electrical use case(s) indicated in the documentation
of the pin controller. Some choose to create one group per pin when
all pins can be muxed around individually.

Linus Walleij
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at