AM6412: RS485 mode Linux driver testing

Hi Bin,

Re-cap, these were our original questions

• Does AM64x driver support RS-485 mode? I assume the answer is yes, but just checking.  My expectation is that we can set this mode through device tree at boot time.

Ans: Per https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt,

“   Any driver for devices capable of working both as RS232 and RS485 should

   implement the rs485_config callback in the uart_port structure. The

   serial_core calls rs485_config to do the device specific part in response

   to TIOCSRS485 and TIOCGRS485 ioctls (see below). The rs485_config callback

   receives a pointer to struct serial_rs485”

I looked through the omap-serial.c - drivers/tty/serial/omap-serial.c - Linux source code (v5.13-rc7) - Bootlin and noticed it has support for this CB

serial_omap_config_rs485(struct uart_port *port, struct serial_rs485 *rs485)

Based on the above kernel documentation and code, this statement does not seem accurate.   

So how did TI Test RS-485 mode in their driver on AM64x SOC?

• Does the UART controller have built-in support for controlling the direction of transfer? Or does the SW need to do this?
• Do you have any recommendation on HW test setup  to test RS-485 mode in EVMs?
• Do you know of any known reliability/timing/other issues with this mode? Has this RS-485 mode been tested on any AM64x SOC test setup or validation board?

Do you have test coverage for this mode in your internal testing?

Regards,

--Gunter

Bin Liu said:

Gunter Schmer said:

Does the UART controller have built-in support for controlling the direction of transfer? Or does the SW need to do this?

The kernel serial driver controls the UART RTS pin for the RS-485 transceiver direction control, the AM64x UART controls the RTS pin based on the driver.

I believe omap_8250_rs485_config() calls serial8250_em485_init() which sets up RS485 "software emulation". "controller built-in support" sounds like Gunter is asking for the kind of hardware-assisted direction control where hardware drives the direction pin when there's something to be sent in the FIFO or shift register.

According to the TRM (Rev. A, 12.1.5.4.8.2.1 RS-485 External Transceiver Direction Control ) the AM64x UART should support hardware control of the RTS pin (see 12.1.5.2.2.1 System Using RS-485 Communication for DIR==RTS) for this purpose. I don't think the 8250_omap.c driver knows about the necessary register configuration though.

I don't think the AM335x UART supported this feature.

The software approach has sometimes undesirable side effects, since you get software latencies into the path from TX of the last character to the transceiver being disabled.

Regards,

Dominic

Hi Dominic,

Yes, the UART in AM64x and AM335x does have the feature that RTS pin is driven when TX about to send data, the function is called hardware follow control. When hw flow control is enabled in application termios configuration, this feature is enabled. But I never used it for RS-485 DIR control, and not sure how it cooperates with rs485_config. 

Hello Bin,

that's not what I'm talking about. If you look at the AM64xx TRM chapters I referenced, the AM64x UART has dedicated support for using the RTS as the RS485 direction pin. This is enabled via the UART_MDR3[DIR_EN] of the AM64x - that bit isn't available on the AM335x, and I don't think the 8250_omap driver knows about this feature, and thus wont enable it.

I've never seen UART hardware flow control used for the purpose of driving a RS485 tx enable, and I doubt this would work. See 12.1.5.4.8.1.3.2 Hardware Flow Control for a description of what kind of hardware flow control the AM64x supports. The transmitter stops sending when CTS is high, and receiver sets RTS high when the RX FIFO grows full. This is a feature that the AM335x and the AM64x (and probably hundreds of others) support, but this has nothing to do with RS485.

Anyway, I suppose Gunter would have to be more specific what he's asking for. I'm just "guessing" that the AM64x's RS-485 is what Gunter was asking about.

Regards,

Dominic

Hi Dominic,

Dominic Rath said:

I've never seen UART hardware flow control used for the purpose of driving a RS485 tx enable, and I doubt this would work. See 12.1.5.4.8.1.3.2 Hardware Flow Control for a description of what kind of hardware flow control the AM64x supports. The transmitter stops sending when CTS is high, and receiver sets RTS high when the RX FIFO grows full. This is a feature that the AM335x and the AM64x (and probably hundreds of others) support, but this has nothing to do with RS485.

My apologies for the misleading, not sure what I was thinking while writing my response above yesterday. You are right, hw flow control is the RX side signals the TX to stop transmitting, while RS-485 direction control is completely opposite - TX signals RX, kind of...

Dominic Rath said:

that's not what I'm talking about. If you look at the AM64xx TRM chapters I referenced, the AM64x UART has dedicated support for using the RTS as the RS485 direction pin. This is enabled via the UART_MDR3[DIR_EN] of the AM64x - that bit isn't available on the AM335x, and I don't think the 8250_omap driver knows about this feature, and thus wont enable it.

Thanks for pointing this out, I wasn't aware of AM64x UART added this new feature until now. Unfortunately this feature currently is not validated in Linux, the kernel driver 8250_omap.c doesn't support MDR3[DIR_EN] yet. Due to lack of platform for validation I don't think this feature will be supported in near future.