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

[Lukas Wunner <lukas@wunner.de>]

On Tue, Oct 04, 2022 at 12:06:21PM +0300, Ilpo Järvinen wrote:
> On Mon, 3 Oct 2022, Lukas Wunner wrote:
> > On Wed, Sep 28, 2022 at 02:38:40PM +0300, Ilpo Järvinen wrote:
> > > On Tue, 27 Sep 2022, Lukas Wunner wrote:
> > > > @@ -1377,6 +1426,14 @@ static int omap8250_probe(struct platform_device *pdev)
> > > >  			 DEFAULT_CLK_SPEED);
> > > >  	}
> > > >  
> > > > +	if (priv->habit & UART_HAS_NATIVE_RS485) {
> > > > +		up.port.rs485_config = omap8250_rs485_config;
> > > > +	} else {
> > > > +		up.port.rs485_config = serial8250_em485_config;
> > > > +		up.rs485_start_tx = serial8250_em485_start_tx;
> > > > +		up.rs485_stop_tx = serial8250_em485_stop_tx;
> > > > +	}
> > > 
> > > I guess .rs485_supported shouldn't be equal in both cases?
> > 
> > I contemplated whether it should be different for hardware-assisted
> > RS485 but came to the conclusion that it shouldn't:
[...]
> Core is not handling just flags but also delay_rts_before_send and 
> delay_rts_after_send sanitization. See 
> uart_sanitize_serial_rs485_delays().
> 
> Btw, you can also get rid of this line once you provide separate 
> rs485_supported:
> 	rs485->delay_rts_before_send = 0;
> 
> What to do with delay_rts_after_send seems bit trickier though. Looking 
> the code, it cannot be configured to arbitrary values by the user but it 
> might not be zero either after the driver touches it. Maybe it safer to 
> have it supported (set to 1) to avoid spuriously triggering the warning in 
> uart_sanitize_serial_rs485_delays() (e.g., during init if non-zero delay 
> is provided).

If I understand Figure 12-276 on page 8783 of the AM65 TRM correctly,
there appears to be a 1 bit clock delay between writing to the THR register
and transmission of the start bit:

  https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf

I intend to respin the patch with the following addition:

  fixed_delay_rts_before_send = 1 * MSEC_PER_SEC / baud;

As a result, both delay_rts_before_send and delay_rts_after_send should be
set to 1 in the rs485_supported struct for hardware-controlled RTS.

The resulting struct is identical to serial8250_em485_supported.

Thanks,

Lukas