| Message ID | 20221013112339.2540767-1-matthias.schiffer@ew.tq-group.com |
|---|---|
| State | New |
| Headers | show |
| Series | serial: 8250_omap: remove wait loop from Errata i202 workaround | expand |
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 --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,
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(-)