]> git.baikalelectronics.ru Git - kernel.git/commit
serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
authorAndrew Jeffery <andrew@aj.id.au>
Thu, 20 May 2021 02:13:33 +0000 (11:43 +0930)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 20 May 2021 15:14:46 +0000 (17:14 +0200)
commit1a681965e1409645927607ecba71da819f974a48
tree6981712c39d835561b8cc308de1897725d05eac7
parent560b1ff8b9d1dc361f0f3c3f387f7c25a43610c4
serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART

Aspeed Virtual UARTs directly bridge e.g. the system console UART on the
LPC bus to the UART interface on the BMC's internal APB. As such there's
no RS-232 signalling involved - the UART interfaces on each bus are
directly connected as the producers and consumers of the one set of
FIFOs.

The APB in the AST2600 generally runs at 100MHz while the LPC bus peaks
at 33MHz. The difference in clock speeds exposes a race in the VUART
design where a Tx data burst on the APB interface can result in a byte
lost on the LPC interface. The symptom is LSR[DR] remains clear on the
LPC interface despite data being present in its Rx FIFO, while LSR[THRE]
remains clear on the APB interface as the host has not consumed the data
the BMC has transmitted. In this state, the UART has stalled and no
further data can be transmitted without manual intervention (e.g.
resetting the FIFOs, resulting in loss of data).

The recommended work-around is to insert a read cycle on the APB
interface between writes to THR.

Cc: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Tested-by: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210520021334.497341-2-andrew@aj.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/tty/serial/8250/8250.h
drivers/tty/serial/8250/8250_aspeed_vuart.c
drivers/tty/serial/8250/8250_port.c