diff mbox series

serial: 8250_omap: remove wait loop from Errata i202 workaround

Message ID 20221013112339.2540767-1-matthias.schiffer@ew.tq-group.com
State New
Headers
Series serial: 8250_omap: remove wait loop from Errata i202 workaround |

Commit Message

Matthias Schiffer Oct. 13, 2022, 11:23 a.m. UTC 
  We were occasionally seeing the "Errata i202: timedout" on an AM335x
board when repeatedly opening and closing a UART connected to an active
sender. As new input may arrive at any time, it is possible to miss the
"RX FIFO empty" condition, forcing the loop to wait until it times out.

Nothing in the i202 Advisory states that such a wait is even necessary;
other FIFO clear functions like serial8250_clear_fifos() do not wait
either. For this reason, it seems safe to remove the wait, fixing the
mentioned issue.

Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
---
 drivers/tty/serial/8250/8250_omap.c | 17 -----------------
 1 file changed, 17 deletions(-)

Comments

Ilpo Järvinen Oct. 17, 2022, 8:12 a.m. UTC | #1 
On Thu, 13 Oct 2022, Matthias Schiffer wrote:

> We were occasionally seeing the "Errata i202: timedout" on an AM335x
> board when repeatedly opening and closing a UART connected to an active
> sender. As new input may arrive at any time, it is possible to miss the
> "RX FIFO empty" condition, forcing the loop to wait until it times out.

I can see this problem could occur and why your patch fixes it.

> Nothing in the i202 Advisory states that such a wait is even necessary;
> other FIFO clear functions like serial8250_clear_fifos() do not wait
> either. For this reason, it seems safe to remove the wait, fixing the
> mentioned issue.

Checking the commit that added this driver and the loop along with it, 
there was no information why it would be needed there either.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

Thanks.
Sebastian Andrzej Siewior Oct. 17, 2022, 9:08 a.m. UTC | #2 
On 2022-10-17 11:12:41 [+0300], Ilpo Järvinen wrote:
> On Thu, 13 Oct 2022, Matthias Schiffer wrote:
> 
> > We were occasionally seeing the "Errata i202: timedout" on an AM335x
> > board when repeatedly opening and closing a UART connected to an active
> > sender. As new input may arrive at any time, it is possible to miss the
> > "RX FIFO empty" condition, forcing the loop to wait until it times out.
> 
> I can see this problem could occur and why your patch fixes it.
> 
> > Nothing in the i202 Advisory states that such a wait is even necessary;
> > other FIFO clear functions like serial8250_clear_fifos() do not wait
> > either. For this reason, it seems safe to remove the wait, fixing the
> > mentioned issue.
> 
> Checking the commit that added this driver and the loop along with it, 
> there was no information why it would be needed there either.

I don't remember all the details but I do remember that I never hit it.
The idea back then was to document what appears the problem and then
once there is a reproducer address it _or_ when there is another problem
check if it aligns with the output here (so that _this_ problem's origin
could be this). This was part of address all known chip erratas and
copied from omap-serial at the time so that the 8250 does not miss
anything.
Looking closer, this is still part of the omap-serial driver and it was
introduced in commit
   0003450964357 ("omap2/3/4: serial: errata i202: fix for MDR1 access")

If someone found a way to trigger this output which is unrelated to the
expected cause then this is clearly not helping nor intended.

I would prefer to keep the loop and replace the disturbing output with a
comment describing _why_ the FIFO might remain non-empty after a flush.

In worst cases that loop causes a delay of less than 0.5ms while setting
a baud rate so I doubt that this is causing a real problem.

Either way I would like to see Tony's ACK before this is getting removed
as suggested in this patch.

> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> Thanks.

Sebastian
Ilpo Järvinen Oct. 17, 2022, 12:15 p.m. UTC | #3 
On Mon, 17 Oct 2022, Sebastian Andrzej Siewior wrote:

> On 2022-10-17 11:12:41 [+0300], Ilpo Järvinen wrote:
> > On Thu, 13 Oct 2022, Matthias Schiffer wrote:
> > 
> > > We were occasionally seeing the "Errata i202: timedout" on an AM335x
> > > board when repeatedly opening and closing a UART connected to an active
> > > sender. As new input may arrive at any time, it is possible to miss the
> > > "RX FIFO empty" condition, forcing the loop to wait until it times out.
> > 
> > I can see this problem could occur and why your patch fixes it.
> > 
> > > Nothing in the i202 Advisory states that such a wait is even necessary;
> > > other FIFO clear functions like serial8250_clear_fifos() do not wait
> > > either. For this reason, it seems safe to remove the wait, fixing the
> > > mentioned issue.
> > 
> > Checking the commit that added this driver and the loop along with it, 
> > there was no information why it would be needed there either.
> 
> I don't remember all the details but I do remember that I never hit it.
> The idea back then was to document what appears the problem and then
> once there is a reproducer address it _or_ when there is another problem
> check if it aligns with the output here (so that _this_ problem's origin
> could be this). This was part of address all known chip erratas and
> copied from omap-serial at the time so that the 8250 does not miss
> anything.
> Looking closer, this is still part of the omap-serial driver and it was
> introduced in commit
>    0003450964357 ("omap2/3/4: serial: errata i202: fix for MDR1 access")

I found that one too but it doesn't give any explanation for it either.
In fact, the wait for empty is mysteriously missing from the itemized
description of the workaround in the commit message.

> If someone found a way to trigger this output which is unrelated to the
> expected cause then this is clearly not helping nor intended.
> 
> I would prefer to keep the loop and replace the disturbing output with a
> comment describing _why_ the FIFO might remain non-empty after a flush.
> 
> In worst cases that loop causes a delay of less than 0.5ms while setting
> a baud rate so I doubt that this is causing a real problem.
> 
> Either way I would like to see Tony's ACK before this is getting removed
> as suggested in this patch.

Thanks for chimming in.

I went to do some lore searching and came across this thread (it should 
be added with Link: tag the patch regardless of its final form):
  https://lore.kernel.org/linux-omap/4BBF61FE.3060807@ti.com/
Tony Lindgren Oct. 24, 2022, 5:28 a.m. UTC | #4 
Hi,

Adding Nishanth to Cc also.

* Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [221017 12:06]:
> On Mon, 17 Oct 2022, Sebastian Andrzej Siewior wrote:
> 
> > On 2022-10-17 11:12:41 [+0300], Ilpo Järvinen wrote:
> > > On Thu, 13 Oct 2022, Matthias Schiffer wrote:
> > > 
> > > > We were occasionally seeing the "Errata i202: timedout" on an AM335x
> > > > board when repeatedly opening and closing a UART connected to an active
> > > > sender. As new input may arrive at any time, it is possible to miss the
> > > > "RX FIFO empty" condition, forcing the loop to wait until it times out.
> > > 
> > > I can see this problem could occur and why your patch fixes it.
> > > 
> > > > Nothing in the i202 Advisory states that such a wait is even necessary;
> > > > other FIFO clear functions like serial8250_clear_fifos() do not wait
> > > > either. For this reason, it seems safe to remove the wait, fixing the
> > > > mentioned issue.
> > > 
> > > Checking the commit that added this driver and the loop along with it, 
> > > there was no information why it would be needed there either.
> > 
> > I don't remember all the details but I do remember that I never hit it.
> > The idea back then was to document what appears the problem and then
> > once there is a reproducer address it _or_ when there is another problem
> > check if it aligns with the output here (so that _this_ problem's origin
> > could be this). This was part of address all known chip erratas and
> > copied from omap-serial at the time so that the 8250 does not miss
> > anything.
> > Looking closer, this is still part of the omap-serial driver and it was
> > introduced in commit
> >    0003450964357 ("omap2/3/4: serial: errata i202: fix for MDR1 access")
> 
> I found that one too but it doesn't give any explanation for it either.
> In fact, the wait for empty is mysteriously missing from the itemized
> description of the workaround in the commit message.
> 
> > If someone found a way to trigger this output which is unrelated to the
> > expected cause then this is clearly not helping nor intended.
> > 
> > I would prefer to keep the loop and replace the disturbing output with a
> > comment describing _why_ the FIFO might remain non-empty after a flush.
> > 
> > In worst cases that loop causes a delay of less than 0.5ms while setting
> > a baud rate so I doubt that this is causing a real problem.

This sounds like a safe solution for me if it's needed.

> > Either way I would like to see Tony's ACK before this is getting removed
> > as suggested in this patch.
> 
> Thanks for chimming in.
> 
> I went to do some lore searching and came across this thread (it should 
> be added with Link: tag the patch regardless of its final form):
>   https://lore.kernel.org/linux-omap/4BBF61FE.3060807@ti.com/

Nishanth, do you have any more info on checking for fifo empty here?

Regards,

Tony
Vignesh Raghavendra Oct. 26, 2022, 6:13 a.m. UTC | #5 
On 24/10/22 10:58 am, Tony Lindgren wrote:
> Hi,
> 
> Adding Nishanth to Cc also.
> 
> * Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [221017 12:06]:
>> On Mon, 17 Oct 2022, Sebastian Andrzej Siewior wrote:
>>
>>> On 2022-10-17 11:12:41 [+0300], Ilpo Järvinen wrote:
>>>> On Thu, 13 Oct 2022, Matthias Schiffer wrote:
>>>>
>>>>> We were occasionally seeing the "Errata i202: timedout" on an AM335x
>>>>> board when repeatedly opening and closing a UART connected to an active
>>>>> sender. As new input may arrive at any time, it is possible to miss the
>>>>> "RX FIFO empty" condition, forcing the loop to wait until it times out.
>>>>
>>>> I can see this problem could occur and why your patch fixes it.
>>>>
>>>>> Nothing in the i202 Advisory states that such a wait is even necessary;
>>>>> other FIFO clear functions like serial8250_clear_fifos() do not wait
>>>>> either. For this reason, it seems safe to remove the wait, fixing the
>>>>> mentioned issue.
>>>>
>>>> Checking the commit that added this driver and the loop along with it, 
>>>> there was no information why it would be needed there either.
>>>
>>> I don't remember all the details but I do remember that I never hit it.
>>> The idea back then was to document what appears the problem and then
>>> once there is a reproducer address it _or_ when there is another problem
>>> check if it aligns with the output here (so that _this_ problem's origin
>>> could be this). This was part of address all known chip erratas and
>>> copied from omap-serial at the time so that the 8250 does not miss
>>> anything.
>>> Looking closer, this is still part of the omap-serial driver and it was
>>> introduced in commit
>>>    0003450964357 ("omap2/3/4: serial: errata i202: fix for MDR1 access")
>>
>> I found that one too but it doesn't give any explanation for it either.
>> In fact, the wait for empty is mysteriously missing from the itemized
>> description of the workaround in the commit message.
>>
>>> If someone found a way to trigger this output which is unrelated to the
>>> expected cause then this is clearly not helping nor intended.
>>>
>>> I would prefer to keep the loop and replace the disturbing output with a
>>> comment describing _why_ the FIFO might remain non-empty after a flush.
>>>
>>> In worst cases that loop causes a delay of less than 0.5ms while setting
>>> a baud rate so I doubt that this is causing a real problem.
> 
> This sounds like a safe solution for me if it's needed.
> 
>>> Either way I would like to see Tony's ACK before this is getting removed
>>> as suggested in this patch.
>>
>> Thanks for chimming in.
>>
>> I went to do some lore searching and came across this thread (it should 
>> be added with Link: tag the patch regardless of its final form):
>>   https://lore.kernel.org/linux-omap/4BBF61FE.3060807@ti.com/
> 
> Nishanth, do you have any more info on checking for fifo empty here?
> 

At least TRMs of newer SoCs such as AM654 [0] have following note:

NOTE : Bits UART_FCR[2] TX_FIFO_CLEAR and UART_FCR[1] RX_FIFO_CLEAR are

automatically cleared by hardware after 4 × UARTi_ICLK + 5 × UARTi_FCLK
clock cycles.

This delay is needed to finish the resetting of the corresponding FIFO
and DMA control
 registers.

I guess we can drop FIFO empty check and instead add above delay
required for FIFOs to be reset.

[0] https://www.ti.com/lit/pdf/spruid7e 12.1.5.4.6 UART FIFO Management


Regards
Vignesh
diff mbox series

Patch

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 41b8c6b27136..484f791617af 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -193,27 +193,10 @@  static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
 static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
 				     struct omap8250_priv *priv)
 {
-	u8 timeout = 255;
-
 	serial_out(up, UART_OMAP_MDR1, priv->mdr1);
 	udelay(2);
 	serial_out(up, UART_FCR, up->fcr | UART_FCR_CLEAR_XMIT |
 			UART_FCR_CLEAR_RCVR);
-	/*
-	 * Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
-	 * TX_FIFO_E bit is 1.
-	 */
-	while (UART_LSR_THRE != (serial_in(up, UART_LSR) &
-				(UART_LSR_THRE | UART_LSR_DR))) {
-		timeout--;
-		if (!timeout) {
-			/* Should *never* happen. we warn and carry on */
-			dev_crit(up->port.dev, "Errata i202: timedout %x\n",
-				 serial_in(up, UART_LSR));
-			break;
-		}
-		udelay(1);
-	}
 }
 
 static void omap_8250_get_divisor(struct uart_port *port, unsigned int baud,