Re: [PATCH RFC] gpiolib: Take MUX usage into account

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Jan 14, 2019 at 4:53 PM Stefan Wahren <stefan.wahren@xxxxxxxx> wrote:

> > Only if the pin controller is strict can you assume that it's
> > use by something else than GPIO blocks the GPIO
> > usecase. Further explanations to this are detailed in
> > Documentation/driver-api/pinctl.rst section
> > "GPIO mode pitfalls".
> >
> > Since BCM2835 which IIRC is your target does not set
> > .strict to true, you might first have to look into and solve that.
>
> According to the BCM2835 datasheet (GPIO Function Select Registers
> GPFSELn on p.92) a pin can be configured as
>
> 0 = input
> 1 = output
> 2 = alternative function 5 (UART, PWM, ...)
> 3 = alternative function 4 (SPI, JTAG)
> ...
>
> so it's not possible to have GPIO and a alternative function at the same
> time. So in case bcm2835_pmx_gpio_set_direction is called the original
> function get lost. From this i conclude strict should set to true.
>
> BUT i must check that this doesn't break any BCM283x board.
>
> Does this make sense to you?

Yep. However I think (vague feeling) that people sometimes have
specified their pin muxes as non-strict for various reasons, like that
it may only work properly if the pinmux implements
.gpio_request_enable() etc as a shortcut for activating GPIO
lines.

The BCM2835 driver does not do that and instead has explicit
per-pin groups for each GPIO but curiously implements
.gpio_disable_free() so I don't know what the story is here.

This is because the pin control core must be able to distinguish
between GPIO uses and other random muxing to achieve
strictness (and the nicer debugfs that you want).

So if the driver is not using these callbacks, the pinmux
core needs some other way to infer if a pin is used as GPIO
or not.

Yours,
Linus Walleij