Hi, On Mon, Oct 03, 2022 at 09:42:24PM +0200, Lukas Wunner wrote: > 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 Maybe rare, but I know some projects use GPIO for DE control. > address them right from the start. Support for falling back So I think missing it is a regression, because this patch forces to use the RTS pin for DE control, this breaks the existing projects which use GPIO for RTS/DE or have customized delay_rts_{before,after}_send. -Bin. > 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
