Re: [PATCH] serial: 8250: 8250_omap: Support native RS485

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

 



Hi Lukas,

Thanks for enabling this feature.

On Tue, Sep 27, 2022 at 02:10:01PM +0200, Lukas Wunner wrote:
> Recent TI Sitara SoCs such as AM64/AM65 have gained the ability to
> automatically assert RTS when data is transmitted, obviating the need
> to emulate this functionality in software.
> 
> The feature is controlled through new DIR_EN and DIR_POL bits in the
> Mode Definition Register 3.  For details see page 8783 and 8890 of the
> AM65 TRM:  https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
> 
> Tested-by: Matthias Schiffer <matthias.schiffer@xxxxxxxxxxxxxxx>
> Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
> Cc: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
> Cc: Su Bao Cheng <baocheng.su@xxxxxxxxxxx>
> Cc: Vignesh Raghavendra <vigneshr@xxxxxx>
> Cc: Nishanth Menon <nm@xxxxxx>
> ---
> Matthias tested this patch on the AM64 board TQMa6442L + MBaX4XxL:
> He says both sending and receiving continue to work.
> He's verified via /dev/mem that DIR_EN and DIR_POL bits are set
> on an RS485-enabled UART and are not set on other UARTs.
> Also RTS polarity is correct and not changed by the patch.
> 
>  drivers/tty/serial/8250/8250_omap.c | 67 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 62 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 68f5a16..e734efe8 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -44,6 +44,7 @@
>  #define	UART_HAS_EFR2			BIT(4)
>  #define UART_HAS_RHR_IT_DIS		BIT(5)
>  #define UART_RX_TIMEOUT_QUIRK		BIT(6)
> +#define UART_HAS_NATIVE_RS485		BIT(7)
>  
>  #define OMAP_UART_FCR_RX_TRIG		6
>  #define OMAP_UART_FCR_TX_TRIG		4
> @@ -101,6 +102,11 @@
>  #define UART_OMAP_IER2			0x1B
>  #define UART_OMAP_IER2_RHR_IT_DIS	BIT(2)
>  
> +/* Mode Definition Register 3 */
> +#define UART_OMAP_MDR3			0x20
> +#define UART_OMAP_MDR3_DIR_POL		BIT(3)
> +#define UART_OMAP_MDR3_DIR_EN		BIT(4)
> +
>  /* Enhanced features register 2 */
>  #define UART_OMAP_EFR2			0x23
>  #define UART_OMAP_EFR2_TIMEOUT_BEHAVE	BIT(6)
> @@ -112,6 +118,7 @@ struct omap8250_priv {
>  	int line;
>  	u8 habit;
>  	u8 mdr1;
> +	u8 mdr3;
>  	u8 efr;
>  	u8 scr;
>  	u8 wer;
> @@ -345,7 +352,9 @@ static void omap8250_restore_regs(struct uart_8250_port *up)
>  
>  	up->port.ops->set_mctrl(&up->port, up->port.mctrl);
>  
> -	if (up->port.rs485.flags & SER_RS485_ENABLED)
> +	if (priv->habit & UART_HAS_NATIVE_RS485)
> +		serial_out(up, UART_OMAP_MDR3, priv->mdr3);

This makes the NATIVE_RS485 always used if the SoC supports it, but

> +	else if (up->port.rs485.flags & SER_RS485_ENABLED)
>  		serial8250_em485_stop_tx(up);

there are cases em485 should be used even if SoC supports NATIVE_RS485.
For example:
- the design has pinmux conflict and the RTS pin has to be used for
  something else. Then a GPIO pin would be used for RS485 DE control;
- the design requires customized delay_rts_before_send or
  delay_rts_after_send which NATIVE_RS485 doesn't support;

So we might need an option for such usecases. A device tree flag?

-Bin.



[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