All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zev Weiss <zweiss@equinix.com>
To: Oskar Senft <osk@google.com>
Cc: Jeremy Kerr <jk@codeconstruct.com.au>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Troy Lee <troy_lee@aspeedtech.com>,
	Ali El-Haj-Mahmoud <aaelhaj@google.com>
Subject: Re: Slow performance of VUART on AST2500 with 5.15.5
Date: Thu, 16 Dec 2021 04:27:30 +0000	[thread overview]
Message-ID: <20211216042729.GJ25091@packtop> (raw)
In-Reply-To: <CABoTLcTACbnnPZ8dfc_oFwgoT5JikYBHgfTjzknJbqC98rLMQQ@mail.gmail.com>

On Wed, Dec 15, 2021 at 07:38:36PM PST, Oskar Senft wrote:
>Hi everyone
>
>I'm doing some more validation work with meta-tyan
>(https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/*/49181 ) on the
>current 5.15.5 kernel. I noticed that when using ttyS0 from the host
>(being the VUART in the AST2500), that the transfer host->BMC is
>really slow (like 300 baud slow). This is true even after stopping
>obmc-console-server and just doing `cat /dev/ttyVUART0`, so I figured
>it must be a kernel problem. When I then tried kernel 5.2.11 (with the
>DTS from 5.15.5 minus the uart_routing node), then VUART behaved
>normally. After having done this comparison, I think that 5.15.5 is
>generally just much slower.
>
>Is anyone aware of AST2500 VUART (or something else that would affect
>performance on an AST2500) having gotten broken somewhere between
>5.2.11 and 5.15.5?
>
>Thanks
>Oskar.

Yes, this is a known issue.

Prior to commit 54da3e381c2 ("serial: 8250_aspeed_vuart: use UPF_IOREMAP
to set up register mapping"), a long-standing bug in the aspeed-vuart
driver had a side-effect of unintentionally leaving the VUART's FIFOs
disabled.  With that patch applied to fix the bug, the FIFOs get enabled
as they were originally intended to be, but that in turn seems to expose
another bug with the host-side THRE bit not getting set when it should,
so the host-side driver's write routine ends up waiting for a timeout to
expire on every character (when it would otherwise continue on to the
next character upon seeing THRE asserted).  I think this may be a VUART
hardware problem, though that hasn't been officially confirmed thus far.

I'm hoping we can land on a better solution, but as a temporary
band-aid, hacking the driver to treat the device as an 8250 instead of a
16550A (effectively just re-disabling the FIFOs) should speed things
back up:

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 2350fb3bb5e4..c335f2b482bd 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -487,7 +487,7 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 	port.port.irq = irq_of_parse_and_map(np, 0);
 	port.port.handle_irq = aspeed_vuart_handle_irq;
 	port.port.iotype = UPIO_MEM;
-	port.port.type = PORT_16550A;
+	port.port.type = PORT_8250;
 	port.port.uartclk = clk;
 	port.port.flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
 		| UPF_FIXED_PORT | UPF_FIXED_TYPE | UPF_NO_THRE_TEST;

--

Zev

  reply	other threads:[~2021-12-16  4:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-16  3:38 Slow performance of VUART on AST2500 with 5.15.5 Oskar Senft
2021-12-16  4:27 ` Zev Weiss [this message]
2021-12-16  4:54   ` Oskar Senft
2021-12-27  4:30     ` Zev Weiss

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=20211216042729.GJ25091@packtop \
    --to=zweiss@equinix.com \
    --cc=aaelhaj@google.com \
    --cc=jk@codeconstruct.com.au \
    --cc=openbmc@lists.ozlabs.org \
    --cc=osk@google.com \
    --cc=troy_lee@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.