All of lore.kernel.org
 help / color / mirror / Atom feed
From: ChiaWei Wang <chiawei_wang@aspeedtech.com>
To: Jiri Slaby <jirislaby@kernel.org>,
	Andrew Jeffery <andrew@aj.id.au>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	Jenmin Yuan <jenmin_yuan@aspeedtech.com>,
	Ryan Chen <ryan_chen@aspeedtech.com>,
	"miltonm@us.ibm.com" <miltonm@us.ibm.com>
Subject: RE: [PATCH v3 1/2] serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
Date: Thu, 20 May 2021 05:42:19 +0000	[thread overview]
Message-ID: <HK0PR06MB37798367F3F0321B15395DD3912A9@HK0PR06MB3779.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <b8eed269-f30d-af69-dbc2-c9fa70009091@kernel.org>

> -----Original Message-----
> From: Jiri Slaby <jirislaby@kernel.org>
> Sent: Thursday, May 20, 2021 1:25 PM
> 
> On 20. 05. 21, 4:13, Andrew Jeffery wrote:
> > 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>
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> 
> Reviewed-by: Jiri Slaby <jirislaby@kernel.org>

Tested-by: ChiaWei Wang <chiawei_wang@aspeedtech.com>

> 
> > ---
> >   drivers/tty/serial/8250/8250.h              |  1 +
> >   drivers/tty/serial/8250/8250_aspeed_vuart.c |  1 +
> >   drivers/tty/serial/8250/8250_port.c         | 12 ++++++++++++
> >   3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250.h
> > b/drivers/tty/serial/8250/8250.h index 52bb21205bb6..34aa2714f3c9
> > 100644
> > --- a/drivers/tty/serial/8250/8250.h
> > +++ b/drivers/tty/serial/8250/8250.h
> > @@ -88,6 +88,7 @@ struct serial8250_config {
> >   #define UART_BUG_NOMSR	(1 << 2)	/* UART has buggy MSR status
> bits (Au1x00) */
> >   #define UART_BUG_THRE	(1 << 3)	/* UART has buggy THRE
> reassertion */
> >   #define UART_BUG_PARITY	(1 << 4)	/* UART mishandles parity if FIFO
> enabled */
> > +#define UART_BUG_TXRACE	(1 << 5)	/* UART Tx fails to set remote DR
> */
> >
> >
> >   #ifdef CONFIG_SERIAL_8250_SHARE_IRQ
> > diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > index a28a394ba32a..4caab8714e2c 100644
> > --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > @@ -440,6 +440,7 @@ static int aspeed_vuart_probe(struct
> platform_device *pdev)
> >   	port.port.status = UPSTAT_SYNC_FIFO;
> >   	port.port.dev = &pdev->dev;
> >   	port.port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
> > +	port.bugs |= UART_BUG_TXRACE;
> >
> >   	rc = sysfs_create_group(&vuart->dev->kobj,
> &aspeed_vuart_attr_group);
> >   	if (rc < 0)
> > diff --git a/drivers/tty/serial/8250/8250_port.c
> > b/drivers/tty/serial/8250/8250_port.c
> > index d45dab1ab316..fc5ab2032282 100644
> > --- a/drivers/tty/serial/8250/8250_port.c
> > +++ b/drivers/tty/serial/8250/8250_port.c
> > @@ -1809,6 +1809,18 @@ void serial8250_tx_chars(struct uart_8250_port
> *up)
> >   	count = up->tx_loadsz;
> >   	do {
> >   		serial_out(up, UART_TX, xmit->buf[xmit->tail]);
> > +		if (up->bugs & UART_BUG_TXRACE) {
> > +			/*
> > +			 * The Aspeed BMC virtual UARTs have a bug where data
> > +			 * may get stuck in the BMC's Tx FIFO from bursts of
> > +			 * writes on the APB interface.
> > +			 *
> > +			 * Delay back-to-back writes by a read cycle to avoid
> > +			 * stalling the VUART. Read a register that won't have
> > +			 * side-effects and discard the result.
> > +			 */
> > +			serial_in(up, UART_SCR);
> > +		}
> >   		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> >   		port->icount.tx++;
> >   		if (uart_circ_empty(xmit))
> >

WARNING: multiple messages have this Message-ID (diff)
From: ChiaWei Wang <chiawei_wang@aspeedtech.com>
To: Jiri Slaby <jirislaby@kernel.org>,
	Andrew Jeffery <andrew@aj.id.au>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Cc: Ryan Chen <ryan_chen@aspeedtech.com>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jenmin Yuan <jenmin_yuan@aspeedtech.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v3 1/2] serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
Date: Thu, 20 May 2021 05:42:19 +0000	[thread overview]
Message-ID: <HK0PR06MB37798367F3F0321B15395DD3912A9@HK0PR06MB3779.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <b8eed269-f30d-af69-dbc2-c9fa70009091@kernel.org>

> -----Original Message-----
> From: Jiri Slaby <jirislaby@kernel.org>
> Sent: Thursday, May 20, 2021 1:25 PM
> 
> On 20. 05. 21, 4:13, Andrew Jeffery wrote:
> > 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>
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> 
> Reviewed-by: Jiri Slaby <jirislaby@kernel.org>

Tested-by: ChiaWei Wang <chiawei_wang@aspeedtech.com>

> 
> > ---
> >   drivers/tty/serial/8250/8250.h              |  1 +
> >   drivers/tty/serial/8250/8250_aspeed_vuart.c |  1 +
> >   drivers/tty/serial/8250/8250_port.c         | 12 ++++++++++++
> >   3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250.h
> > b/drivers/tty/serial/8250/8250.h index 52bb21205bb6..34aa2714f3c9
> > 100644
> > --- a/drivers/tty/serial/8250/8250.h
> > +++ b/drivers/tty/serial/8250/8250.h
> > @@ -88,6 +88,7 @@ struct serial8250_config {
> >   #define UART_BUG_NOMSR	(1 << 2)	/* UART has buggy MSR status
> bits (Au1x00) */
> >   #define UART_BUG_THRE	(1 << 3)	/* UART has buggy THRE
> reassertion */
> >   #define UART_BUG_PARITY	(1 << 4)	/* UART mishandles parity if FIFO
> enabled */
> > +#define UART_BUG_TXRACE	(1 << 5)	/* UART Tx fails to set remote DR
> */
> >
> >
> >   #ifdef CONFIG_SERIAL_8250_SHARE_IRQ
> > diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > index a28a394ba32a..4caab8714e2c 100644
> > --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > @@ -440,6 +440,7 @@ static int aspeed_vuart_probe(struct
> platform_device *pdev)
> >   	port.port.status = UPSTAT_SYNC_FIFO;
> >   	port.port.dev = &pdev->dev;
> >   	port.port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
> > +	port.bugs |= UART_BUG_TXRACE;
> >
> >   	rc = sysfs_create_group(&vuart->dev->kobj,
> &aspeed_vuart_attr_group);
> >   	if (rc < 0)
> > diff --git a/drivers/tty/serial/8250/8250_port.c
> > b/drivers/tty/serial/8250/8250_port.c
> > index d45dab1ab316..fc5ab2032282 100644
> > --- a/drivers/tty/serial/8250/8250_port.c
> > +++ b/drivers/tty/serial/8250/8250_port.c
> > @@ -1809,6 +1809,18 @@ void serial8250_tx_chars(struct uart_8250_port
> *up)
> >   	count = up->tx_loadsz;
> >   	do {
> >   		serial_out(up, UART_TX, xmit->buf[xmit->tail]);
> > +		if (up->bugs & UART_BUG_TXRACE) {
> > +			/*
> > +			 * The Aspeed BMC virtual UARTs have a bug where data
> > +			 * may get stuck in the BMC's Tx FIFO from bursts of
> > +			 * writes on the APB interface.
> > +			 *
> > +			 * Delay back-to-back writes by a read cycle to avoid
> > +			 * stalling the VUART. Read a register that won't have
> > +			 * side-effects and discard the result.
> > +			 */
> > +			serial_in(up, UART_SCR);
> > +		}
> >   		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> >   		port->icount.tx++;
> >   		if (uart_circ_empty(xmit))
> >

WARNING: multiple messages have this Message-ID (diff)
From: ChiaWei Wang <chiawei_wang@aspeedtech.com>
To: Jiri Slaby <jirislaby@kernel.org>,
	Andrew Jeffery <andrew@aj.id.au>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	Jenmin Yuan <jenmin_yuan@aspeedtech.com>,
	Ryan Chen <ryan_chen@aspeedtech.com>,
	"miltonm@us.ibm.com" <miltonm@us.ibm.com>
Subject: RE: [PATCH v3 1/2] serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART
Date: Thu, 20 May 2021 05:42:19 +0000	[thread overview]
Message-ID: <HK0PR06MB37798367F3F0321B15395DD3912A9@HK0PR06MB3779.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <b8eed269-f30d-af69-dbc2-c9fa70009091@kernel.org>

> -----Original Message-----
> From: Jiri Slaby <jirislaby@kernel.org>
> Sent: Thursday, May 20, 2021 1:25 PM
> 
> On 20. 05. 21, 4:13, Andrew Jeffery wrote:
> > 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>
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> 
> Reviewed-by: Jiri Slaby <jirislaby@kernel.org>

Tested-by: ChiaWei Wang <chiawei_wang@aspeedtech.com>

> 
> > ---
> >   drivers/tty/serial/8250/8250.h              |  1 +
> >   drivers/tty/serial/8250/8250_aspeed_vuart.c |  1 +
> >   drivers/tty/serial/8250/8250_port.c         | 12 ++++++++++++
> >   3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/tty/serial/8250/8250.h
> > b/drivers/tty/serial/8250/8250.h index 52bb21205bb6..34aa2714f3c9
> > 100644
> > --- a/drivers/tty/serial/8250/8250.h
> > +++ b/drivers/tty/serial/8250/8250.h
> > @@ -88,6 +88,7 @@ struct serial8250_config {
> >   #define UART_BUG_NOMSR	(1 << 2)	/* UART has buggy MSR status
> bits (Au1x00) */
> >   #define UART_BUG_THRE	(1 << 3)	/* UART has buggy THRE
> reassertion */
> >   #define UART_BUG_PARITY	(1 << 4)	/* UART mishandles parity if FIFO
> enabled */
> > +#define UART_BUG_TXRACE	(1 << 5)	/* UART Tx fails to set remote DR
> */
> >
> >
> >   #ifdef CONFIG_SERIAL_8250_SHARE_IRQ
> > diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > index a28a394ba32a..4caab8714e2c 100644
> > --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> > @@ -440,6 +440,7 @@ static int aspeed_vuart_probe(struct
> platform_device *pdev)
> >   	port.port.status = UPSTAT_SYNC_FIFO;
> >   	port.port.dev = &pdev->dev;
> >   	port.port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
> > +	port.bugs |= UART_BUG_TXRACE;
> >
> >   	rc = sysfs_create_group(&vuart->dev->kobj,
> &aspeed_vuart_attr_group);
> >   	if (rc < 0)
> > diff --git a/drivers/tty/serial/8250/8250_port.c
> > b/drivers/tty/serial/8250/8250_port.c
> > index d45dab1ab316..fc5ab2032282 100644
> > --- a/drivers/tty/serial/8250/8250_port.c
> > +++ b/drivers/tty/serial/8250/8250_port.c
> > @@ -1809,6 +1809,18 @@ void serial8250_tx_chars(struct uart_8250_port
> *up)
> >   	count = up->tx_loadsz;
> >   	do {
> >   		serial_out(up, UART_TX, xmit->buf[xmit->tail]);
> > +		if (up->bugs & UART_BUG_TXRACE) {
> > +			/*
> > +			 * The Aspeed BMC virtual UARTs have a bug where data
> > +			 * may get stuck in the BMC's Tx FIFO from bursts of
> > +			 * writes on the APB interface.
> > +			 *
> > +			 * Delay back-to-back writes by a read cycle to avoid
> > +			 * stalling the VUART. Read a register that won't have
> > +			 * side-effects and discard the result.
> > +			 */
> > +			serial_in(up, UART_SCR);
> > +		}
> >   		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> >   		port->icount.tx++;
> >   		if (uart_circ_empty(xmit))
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-20  5:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20  2:13 [PATCH v3 0/2] serial: 8250: Mitigate Tx stall risk for Aspeed VUARTs Andrew Jeffery
2021-05-20  2:13 ` Andrew Jeffery
2021-05-20  2:13 ` Andrew Jeffery
2021-05-20  2:13 ` [PATCH v3 1/2] serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART Andrew Jeffery
2021-05-20  2:13   ` Andrew Jeffery
2021-05-20  2:13   ` Andrew Jeffery
2021-05-20  5:24   ` Jiri Slaby
2021-05-20  5:24     ` Jiri Slaby
2021-05-20  5:24     ` Jiri Slaby
2021-05-20  5:42     ` ChiaWei Wang [this message]
2021-05-20  5:42       ` ChiaWei Wang
2021-05-20  5:42       ` ChiaWei Wang
2021-05-20  2:13 ` [PATCH v3 2/2] serial: 8250: Use BIT(x) for UART_{CAP,BUG}_* Andrew Jeffery
2021-05-20  2:13   ` Andrew Jeffery
2021-05-20  2:13   ` Andrew Jeffery
2021-05-20  5:25   ` Jiri Slaby
2021-05-20  5:25     ` Jiri Slaby
2021-05-20  5:25     ` Jiri Slaby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HK0PR06MB37798367F3F0321B15395DD3912A9@HK0PR06MB3779.apcprd06.prod.outlook.com \
    --to=chiawei_wang@aspeedtech.com \
    --cc=andrew@aj.id.au \
    --cc=gregkh@linuxfoundation.org \
    --cc=jenmin_yuan@aspeedtech.com \
    --cc=jirislaby@kernel.org \
    --cc=joel@jms.id.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=miltonm@us.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=ryan_chen@aspeedtech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.