On Thu, 6 Oct 2022, Lukas Wunner wrote: > 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: > > > > > > > > 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. Ok. I was just commenting what the code did but of course if you change it the situation is different then. > The resulting struct is identical to serial8250_em485_supported. Please note it down somewhere (either commit message or comment at the rs485_supported assignment) so that somebody else after us doesn't need to dig up this thread. -- i.
