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