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.
Best regards,
Adam
