Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output

[Dave P Martin <Dave.Martin@xxxxxxx>]

On Tue, Oct 17, 2017 at 03:03:02PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 17, 2017 at 02:44:29PM +0100, Dave Martin wrote:
> > arch/arm/kernel/debug.S:
> >
> > ENTRY(printascii)
> >                 addruart_current r3, r1, r2
> >                 b       2f
> > 1:              waituart r2, r3
> >                 senduart r1, r3
> >                 busyuart r2, r3
> >                 teq     r1, #'\n'
> >                 moveq   r1, #'\r'
> >                 beq     1b
> > 2:              teq     r0, #0
> >                 ldrneb  r1, [r0], #1
> >                 teqne   r1, #0
> >                 bne     1b
> >                 ret     lr
> > ENDPROC(printascii)
> >
> > ENTRY(printch)
> >                 addruart_current r3, r1, r2
> >                 mov     r1, r0
> >                 mov     r0, #0
> >                 b       1b
> > ENDPROC(printch)
> >
> >
> >
> > Russell, do you know why we wait for the UART transmitter to go
> > completely idle before queueing a new char?
>
> It's the only way the /debug/ (and I stress /debug/) functions know
> that the character has actually been sent before allowing control to
> continue.  This is important for early-crashy-debug situations, but
> probably less so for early_printk.
>
> > For an individual printch this can makes sense, but it also introduces
> > delay for every char in printascii.
> >
> > This seems to interact interestingly with virtualised UARTs, because we
> > may thrash between the guest and hypervisor per-char, though there
> > may be a way to reduce the impact of this on the emulation side.
>
> Well, I guess re-using the early /debugging/ code for early printk is
> showing more and more issues - and reusing this code in this way is
> something that I've never really been a fan of.
>
> I'd personally like to see the coupling between the two things gone -
> I never really wanted that coupling in the first place.

Agreed.  I'll propose a patch for the amba-pl011 earlycon code so that
the flush is only per each write() call, which should at least mitigate
the impact.

For low-level debug, it makes more sense to be as conservative as
possible though: I don't see a need to change arm printch/printascii:
as you point out, these two bits of code have different purposes,
even if they have common ancestry.

Cheers
---Dave
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel