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: > > > 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 > [...] > > > @@ -1335,10 +1387,7 @@ static int omap8250_probe(struct platform_device *pdev) > > > up.port.shutdown = omap_8250_shutdown; > > > up.port.throttle = omap_8250_throttle; > > > up.port.unthrottle = omap_8250_unthrottle; > > > - up.port.rs485_config = serial8250_em485_config; > > > up.port.rs485_supported = serial8250_em485_supported; > > > - up.rs485_start_tx = serial8250_em485_start_tx; > > > - up.rs485_stop_tx = serial8250_em485_stop_tx; > > > up.port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE); > > > > > > ret = of_alias_get_id(np, "serial"); > > > @@ -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: > > The polarity may be chosen both for hardware- and software-controlled RTS. > > Whether RX_DURING_TX is possible depends on how the RS485 transceiver > is wired to the UART: If RTS asserts !RE on the transceiver when sending, > the UART cannot receive data, regardless whether hardware- or software- > controlled RTS is used. > > TERMINATE_BUS works independently from RTS control. > > And ADDRB doesn't seem to be supported in either mode AFAICS. > > Am I missing something? 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). -- i.
