On Mon, Oct 03, 2022 at 10:10:59AM -0500, Bin Liu wrote: > 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 [...] > > - 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? I expect those cases to be rare, hence do not see the need to address them right from the start. Support for falling back to software emulation can easily be added later. Indeed a device tree property might be an appropriate way to trigger such a fallback. Thanks, Lukas
