Hello Greg, On Fri, Feb 16, 2018 at 09:37:14PM +0100, Greg Kroah-Hartman wrote: > On Fri, Feb 09, 2018 at 02:51:46PM +0100, Uwe Kleine-König wrote: > > Hello Greg, > > > > On Wed, Oct 04, 2017 at 10:45:15AM +0200, Uwe Kleine-König wrote: > > > On Wed, Oct 04, 2017 at 10:19:34AM +0200, Greg Kroah-Hartman wrote: > > > > On Tue, Sep 19, 2017 at 08:49:55PM +0200, Uwe Kleine-König wrote: > > > > > When an i.MX UART is opened in RS485 for reading only the serial core > > > > > still calls uart_start at times which then calls .start_tx. In the i.MX > > > > > case start_tx then asserts RTS to prepare sending data and only at the > > > > > end notices that there is nothing to send and deassert RTS again. In the > > > > > mean time some data sent to the i.MX might already be missed or damaged. > > > > > > > > > > Instead of fixing that in the driver, do it in the framework instead for > > > > > other drivers to benefit. > > > > > > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > > > > --- > > > > > Hello, > > > > > > > > > > whenever I touch the serial core I feel that I don't understand all the > > > > > interaction with the tty layer and the expectations of a driver. Is > > > > > there something else that .start_tx is supposed to do such that it might > > > > > make sense to call it even though the fifo is empty? > > > > > > > > > > Looking at atmel_serial.c I think it suffers the same problem because > > > > > there the receiver is disabled, too, without first checking if there is > > > > > something to send. So maybe I really miss something? > > > > > > > > > > On the bright side: With this change I can transmit data in both > > > > > directions with my rs485 test setup between an i.MX6 and an i.MX25. > > > > > > > > > > Best regards > > > > > Uwe > > > > > > > > > > drivers/tty/serial/serial_core.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > > > > > index b4613aaf7a11..8ac2c1467a37 100644 > > > > > --- a/drivers/tty/serial/serial_core.c > > > > > +++ b/drivers/tty/serial/serial_core.c > > > > > @@ -133,7 +133,8 @@ static void __uart_start(struct tty_struct *tty) > > > > > struct uart_state *state = tty->driver_data; > > > > > struct uart_port *port = state->uart_port; > > > > > > > > > > - if (port && !uart_tx_stopped(port)) > > > > > + if (port && !uart_tx_stopped(port) && > > > > > + (port->x_char || !uart_circ_empty(&port->state->xmit))) > > > > > port->ops->start_tx(port); > > > > > } > > > > > > > > > > > > > Have you tested this with other serial port devices? > > > > > > No, currently nothing handy. > > > > > > > Why check for x_char? > > > > > > x_char (if != 0) is supposed to send even if the circular buffer is > > > empty, isn't it? > > > > This patch is still in my queue. In your's, too? > > Nope, sorry. That means resend, right? Do you delete a mail directly after you asked some review questions? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
