SERIAL_IMX shutdown in RS485 mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I'm preparing Linux for a device based on i.MX6UL by Freescale, now NXP. The device uses RS485 interface, and I have noticed, that the current driver SERIAL_IMX (driver/tty/serial/imx.c) doesn't do that correctly. Thus, I have a question to you (four paragraphs below).

According to my understanding, at least for the i.MX family, the general agreement is that CTS_B signal of the processor, which is an output, should be used as "driver enable" (DE) signal of transmitter in the RS485 transceiver chip. Typically this DE signal is "normal logic", ie. high voltage == '1', while CTS_B is inverted logic signal, ie. low voltage == '1'. UART peripheral of i.MX processor has bit field CTS in register UCR2, and this bit field can be used for "manual" control of the CTS_B signal.

That is what the driver SERIAL_IMX does for ports defined in device tree as dedicated for RS485.

However, Linux can, and does, disable serial port, here, by putting '0' into UCR1 register of the UART peripheral. But then, CTS bit field is ignored and CTS_B a.k.a. DE signal line is high. For RS485 this ends up in having wrestling match of connected transmitters.

The correct state should be that for unused or disabled UART assigned for RS485 the DE signal line is low. That is something I want to implement. I can see two ways of doing that in software (described below), and my question is: which is preferred?

1) Prevent disabling UART peripheral. For that function imx_shutdown or imx_uart_shutdown could check if RS485 is enabled (in rs485.flags) and if yes, keep the enable bit in UCR1 asserted. This will not require engaging other things, but will not allow to fully disable the port. I don't know why Linux tries to do so, and I can't tell whether or not that is a potential problem.

2) Use GPIO to define the state of the signal when UART peripheral is disabled. That might be done by defining the GPIO muxed with CTS_B as output in low state, and muxing the processor pin to CTS_B when enabling the UART, and to GPIO when disabling it. This would allow to fully disable UART, but will require undisclosed control of an additional feature (GPIO channel) which somebody might want to use for another purpose.

I would appreciate letting me know your opinion on that.

Best regards,
Adam

---------------------
Adam Rudziński
A.R.f.
http://arf.net.pl




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux