Hi,
Am 06.03.24 um 18:07 schrieb Chen-Yu Tsai:
On Thu, Mar 7, 2024 at 1:04 AM Stefan Wahren <wahrenst@xxxxxxx> 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@xxxxxxxxxx> wrote:
On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@xxxxxxxxxx> 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@xxxxxxx/
ChenYu
