On 13.09.2018 01:52, Linus Walleij wrote:
> On Wed, Sep 12, 2018 at 5:52 PM Adam Rudziński
> <adam.rudzinski@xxxxxxxxxx> wrote:
>> W dniu 2018-09-12 o 15:04, Linus Walleij pisze:
>> > On Tue, Sep 11, 2018 at 8:33 AM Adam Rudziński
>> > <adam.rudzinski@xxxxxxxxxx> wrote:
>> >
>> >> Yes. Actually, keeping control over CTS in IMX requires to keep UART
>> >> enabled (bit 0 in UCR1) and the receiver enabled (bit 1 in UCR2).
>> >>
>> >> Bullseye! There is a short moment on boot when Linux has already
>> >> muxed the pin to CTS, but didn't configure the peripheral yet. Yesterday
>> >> I've started to prepare a fix, and spent some time trying to understand
>> >> what was happening, just to have come to the same conclusion, that
>> >> it wouldn't work completely well.
>> >>
>> >> Here, I would argue that it is fundamentally wrong in Linux. I think
>> >> that the correct approach to pinmuxing would be if the driver did that
>> >> when probed. Is there available any mechanism preventing Linux
>> >> to do the pinmuxing but still starting the driver?
>> > This happens because you have a device tree (or similar) defining
>> > a "default" state for this device.
>> > (...)
>>
>> You mean, with the "default" and other states, something like that?
>>
>> &usdhc1 {
>> pinctrl-names = "default", "state_100mhz", "state_200mhz";
>> pinctrl-0 = <&pinctrl_usdhc1>;
>> pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
>> pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
>> (...)
>> };
>>
>> That would allow to start with GPIO muxed, and then switch to CTS_B
>> after the driver has already configured the UART. And everything in an
>> "official" way without any undisclosed peculiarities.
>
> Depends on what is inside the "default" state I guess, if it works for
> your system then it's fine?
>
> Whatever is fine with the i.MX pinctrl maintainers is fine with me,
> they can (hopefully) tell what they want. I added them to TO:
We have a similar situation in I2C, where the driver switches the pin to I2C in case of a bus lockup:
drivers/i2c/busses/i2c-imx.c
Documentation/devicetree/bindings/i2c/i2c-imx.txt
Adding a second state called "gpio" seems rather reasonable to me. If it is not present, the driver should behave as it did so far.
--
Stefan
>
> If it is hard to set up a "default" state that does not cause issues,
> just omit it completely and only use custom states.
>
> Yours,
> Linus Walleij
