serial: mvebu-uart: fix tx lost characters

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(-)

--
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

On Tue, Mar 06, 2018 at 03:47:03PM +0000, Gabriel Matni 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 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

Patch is corrupted and can not be applied :(

Please fix up and resend.

Also be sure to cc: the linux-serial mailing list,
scripts/get_maintainer.pl is your friend...

thanks,

greg k-h

Hi Gabriel,

On Thu, 15 Mar 2018 18:55:25 +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 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..400e1bc558b2 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);

I think this line should be indented like the one you replaced.

Thanks,
Miquèl