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

[Stefan Wahren <stefan.wahren@xxxxxxxx>]

Hi Linus,

Am 21.01.19 um 14:32 schrieb Linus Walleij:
> 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.

looking at the initial commit [1] reveal the following:

Upstreaming changes by Stephen Warren:
...

* Don't set GPIO_IN function select in gpio_request_enable() to avoid
glitches; defer this to gpio_set_direction(). Consequently, removed
empty bcm2835_pmx_gpio_request_enable().

So maybe this "side effect" wasn't intended.

[1] - https://patchwork.kernel.org/patch/1516561/

>
> 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