[PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

[Stefan Wahren]

Hi,

Am 06.03.24 um 18:07 schrieb Chen-Yu Tsai:
> On Thu, Mar 7, 2024 at 1:04 AM Stefan Wahren <wahrenst at gmx.net> wrote:
>> Hi guys,
>>
>> Am 06.03.24 um 14:40 schrieb Chen-Yu Tsai:
>>> On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>>>> On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens at kernel.org> wrote:
>>>>
>>>>> For the MediaTek device trees, the only two occurrences of "output-enable"
>>>>> actually describe conflicting information:
>>>>>
>>>>>       pins-rts {
>>>>>               pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
>>>>>               output-enable;
>>>>>       };
>>>>>
>>>>> The above asks for the UART function on this pin, but based on existing
>>>>> driver definitions, switches the function to GPIO output because of the
>>>>> "output-enable" property. Hence the confusion.
>>>> This is actually also driver-dependent.
>>>>
>>>> It is only conflicting if the pin controller has .strict set in struct
>>>> pinmux_ops,
>>>> because many SoCs are perfectly capable of using a pin as a function
>>>> such as UART RTS and GPIO at *the same time*.
>>> I don't think MediaTek falls in this category. Nor does BCM2835. It is
>>> quite obvious, since GPIO in/out are selectable pinmux functions.
>>>
>>>> Details on strict mode can be found in Documentation/driver-api/pin-control.rst
>>>>
>>>> I don't know which Mediatek this is but:
>>>> $ git grep strict drivers/pinctrl/mediatek/
>>>> drivers/pinctrl/mediatek/pinctrl-moore.c:       .strict = true,
>>>>
>>>> Only the Moore family is strict, and I think BCM2835 is not.
>>> While that would be true for new drivers, I believe we do have many existing
>>> drivers that cannot set the strict bit, as existing device trees already
>>> have their pinctrl options selecting the GPIO function in conjunction with
>>> *-gpios usage. We also had this on older Allwinner platforms. We ended up
>>> only setting the .strict option for new platforms, not because of any
>>> hardware difference, but because of backwards compatibility. Otherwise
>>> I would love to clean up many of them.
>>>
>>> In both MediaTek and BCM2835's cases, it is quite obvious from the driver
>>> that the hardware cannot use the pin as a dedicated function and a GPIO
>>> at the same time. And we should not give them more options to shoot
>>> themselves in the foot.
>> i tried following your discussion. Does it mean i should change anything
>> here in this series?
> I think support for PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT_ENABLE
> should be dropped from the series.
okay after applying this series pinconf-pins looks like this:

pin 31 (gpio31): input bias disabled
pin 32 (gpio32): input bias disabled
pin 33 (gpio33): input bias pull up (50000 ohms)
pin 34 (gpio34): input bias disabled
pin 35 (gpio35): input bias pull up (50000 ohms)
pin 36 (gpio36): input bias pull up (50000 ohms)
pin 37 (gpio37): input bias pull up (50000 ohms)
pin 38 (gpio38): input bias pull up (50000 ohms)
pin 39 (gpio39): input bias pull up (50000 ohms)
pin 40 (gpio40): input bias disabled
pin 41 (gpio41): input bias disabled
pin 42 (gpio42): input bias pull up (50000 ohms), output enabled, pin
output (0 level)

After dropping PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT_ENABLE it
looks like this:

pin 31 (gpio31): input bias disabled
pin 32 (gpio32): input bias disabled
pin 33 (gpio33): input bias pull up (50000 ohms)
pin 34 (gpio34): input bias disabled
pin 35 (gpio35): input bias pull up (50000 ohms)
pin 36 (gpio36): input bias pull up (50000 ohms)
pin 37 (gpio37): input bias pull up (50000 ohms)
pin 38 (gpio38): input bias pull up (50000 ohms)
pin 39 (gpio39): input bias pull up (50000 ohms)
pin 40 (gpio40): input bias disabled
pin 41 (gpio41): input bias disabled
pin 42 (gpio42): input bias pull up (50000 ohms), pin output (0 level)

In case anyone is fine with this, i will send v4.

Btw thanks for answering my questions from here [1] indirectly.

[1] -
https://lore.kernel.org/linux-gpio/102ae999-6574-4b14-a24b-826533b47a5d@gmx.net/
>
> ChenYu