Slow performance of VUART on AST2500 with 5.15.5
osk at google.com
Thu Dec 16 15:54:19 AEDT 2021
> >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'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've been trying REAL hard to keep meta-tyan (and our other downstream
stuff) patch free, but I can't leave it broken since it affects boot
time (both BIOS and Linux synchronize on writes to the serial
More information about the openbmc