[PATCH] serial: mvebu-uart: fix tx lost characters

* [PATCH] serial: mvebu-uart: fix tx lost characters
@ 2018-03-06 15:47 ` Gabriel Matni
  0 siblings, 0 replies; 13+ messages in thread
From: Gabriel Matni @ 2018-03-06 15:47 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: stable, Miquel Raynal, Grégory Clement, Thomas Petazzoni, gregkh

From: Gabriel Matni <gabriel.matni@exfo.com>

Fixes missing characters on kernel console at low baud rates (i.e.9600).
The driver should poll TX_RDY or TX_FIFO_EMP instead of TX_EMP to ensure
that the transmitter holding register (THR) is ready to receive a new byte.

TX_EMP tells us when it is possible to send a break sequence via
SND_BRK_SEQ. While this also indicates that both the THR and the TSR are
empty, it does not guarantee that a new byte can be written just yet.

Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> 
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>  
Signed-off-by: Gabriel Matni <gabriel.matni@exfo.com> 
---
drivers/tty/serial/mvebu-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index a100e98259d7..f0df0640208e 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -618,7 +618,7 @@ static void wait_for_xmitr(struct uart_port *port)
   u32 val;

   readl_poll_timeout_atomic(port->membase + UART_STAT, val,
-             (val & STAT_TX_EMP), 1, 10000);
+             (val & STAT_TX_RDY(port)), 1, 10000);
}

static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
--
2.7.4

> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: March 5, 2018 4:47 AM
> To: Gabriel Matni <gabriel.matni@exfo.com>
> Cc: linux-arm-kernel@lists.infradead.org; gregkh@linuxfoundation.org;
> Grégory Clement <gregory.clement@bootlin.com>; Thomas Petazzoni
> <thomas.petazzoni@bootlin.com>
> Subject: Re: [PATCH] serial: mvebu_uart: fix tx lost characters
> 
> Hi Gabriel,
> 
> On Tue, 27 Feb 2018 21:56:03 +0000, Gabriel Matni
> <gabriel.matni@exfo.com> wrote:
> 
> > Hi Miquèl,
> >
> > > -----Original Message-----
> > > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > > Sent: February 27, 2018 8:13 AM
> > > To: Gabriel Matni <gabriel.matni@exfo.com>
> > > Cc: linux-arm-kernel@lists.infradead.org; gregkh@linuxfoundation.org;
> > > Grégory Clement <gregory.clement@bootlin.com>; Thomas Petazzoni
> > > <thomas.petazzoni@bootlin.com>
> > > Subject: Re: [PATCH] serial: mvebu_uart: fix tx lost characters
> > >
> > > Hi Gabriel,
> > >
> > > On Thu, 22 Feb 2018 20:30:56 +0000, Gabriel Matni
> > > <gabriel.matni@exfo.com> wrote:
> > >
> > > > From: Gabriel Matni <gabriel.matni@exfo.com>
> > > >
> > > > Fixes missing characters on kernel console at low baud rates (i.e.9600).
> > > > The driver should poll TX_RDY instead of TX_EMPTY to ensure that the
> > > > transmitter holding is ready to receive a new byte. Polling TX_EMPTY
> > > > isn't enough as the hardware buffer can become empty but not yet
> ready
> > > > for CPU to write the next byte.
> > >
> > > I am kind of sceptic with the explanation. My understanding is that:
> > > - TX_EMPTY means the FIFO is empty
> 
> I had a deeper look into the spec : TX_EMPTY != TX_FIFO_EMPTY. I was
> referring to TX_FIFO_EMPTY here so my understanding of your solution was
> wrong.
> 
> > > - TX_RDY means the FIFO is not full, neither empty, it is a "half
> > >   loaded" state.
> > > Polling TX_RDY instead of TX_EMPTY should work too, but I don't see why
> it
> > > would fix the loss of character by filling the FIFO when there are bytes in
> it
> > > rather than when it is fully empty.
> >
> > TX_READY is set whenever the UART Transmitter Holding register is ready
> to
> > receive a new byte. It gets cleared as soon as a new byte is written to the
> > register. If the FIFO is empty or still has room, the ready will be set.
> >
> > TX_EMPTY tells us when it is possible to send a break sequence via
> > SND_BRK_SEQ. While this also indicates that both the THR and the TSR are
> > empty, it does not guarantee that a new byte can be written just yet.
> 
> I do agree with this statement. You are right that polling on TX_EMPTY
> looks wrong and we should definitively poll on TX_READY instead.
> 
> > I am
> > unsure about the FIFO status in this case as I can encounter
> TX_FIFO_EMP=0
> > while TX_EMP=1, which suggests that the FIFO isn't necessarily empty
> when
> > TX_EMP is set.
> 
> That is weird but maybe the TX_FIFO_EMPTY is asserted only when all
> bits have been shifted, which is a 10-bit period after TSR is
> cleared, while TX_EMPTY would not wait for these bits to be actually
> shifted out and would be asserted a bit earlier, as soon as TSR is
> cleared. That is just and idea.
> 
> >
> > Therefore, the driver can either poll TX_FIFO_EMP or TX_READY to know
> > whether it can output a new byte. I personally like TX_READY as it takes
> > advantage of the FIFO.
> 
> True.
> 
> >
> > > >
> > > > Signed-off-by: Gabriel Matni <gabriel.matni@exfo.com>
> 
> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
> 
> Thanks,
> Miquèl
> 
> --
> Miquel Raynal, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

^ permalink raw reply related	[flat|nested] 13+ messages in thread