Slow performance of VUART on AST2500 with 5.15.5

[Oskar Senft]

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'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
console).

Thanks
Oskar.