From: Zev Weiss <zweiss@equinix.com>
To: Oskar Senft <osk@google.com>
Cc: Andrew Jeffery <andrew@aj.id.au>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Troy Lee <troy_lee@aspeedtech.com>,
Jeremy Kerr <jk@codeconstruct.com.au>,
Ali El-Haj-Mahmoud <aaelhaj@google.com>
Subject: Re: Slow performance of VUART on AST2500 with 5.15.5
Date: Mon, 27 Dec 2021 04:30:13 +0000 [thread overview]
Message-ID: <20211227042940.GA5754@packtop> (raw)
In-Reply-To: <CABoTLcQapj0LRAAWoo4ncagVGzK9brSz0RJti4H=+eeX5-o5kg@mail.gmail.com>
On Wed, Dec 15, 2021 at 10:54:19PM CST, Oskar Senft wrote:
>Hi Zev
>
>> >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?
>>
>> Yes, this is a known issue.
>
>And I felt that I was going crazy! Thanks for confirming that 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.
>
>Did you reach out to Aspeed yet? I've had some good experiences when
>talking with them directly.
>
I've discussed it a little with Troy on Discord, though I haven't yet
heard any conclusive statements about the recommended course of action.
>
>> 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:
>
>I can confirm that this fixes things, thank you! Is it worth dropping
>that into upstream for the time being, or do you think a "better
>solution" is imminent?
>
I don't really know what the timeline on a better workaround might be
(or even if one is likely to exist); hopefully someone from Aspeed might
be more likely to have some insight on that...
I wouldn't be opposed to dropping that hack into the mainline driver at
least for the time being though; seems like it shouldn't leave things
any worse off than they were before the accidental bugfix side-effect of
the UPF_IOREMAP patch, anyway. Joel or Andrew, any particular opinions
here?
Zev
prev parent reply other threads:[~2021-12-27 4:31 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
2021-12-16 4:54 ` Oskar Senft
2021-12-27 4:30 ` Zev Weiss [this message]
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=20211227042940.GA5754@packtop \
--to=zweiss@equinix.com \
--cc=aaelhaj@google.com \
--cc=andrew@aj.id.au \
--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.