[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Ian Campbell]

On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> On Fri, 19 Jul 2013, Ian Campbell wrote:
> > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > On 17 July 2013 14:25, Stefano Stabellini
> > > <stefano.stabellini at eu.citrix.com> wrote:
> > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > >> Even if uncompress debug is disabled, some board will continue to print
> > > >> information during uncompress step.
> > > >
> > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > some board will continue to print information during the uncompress step"?
> > > 
> > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > This is annoying because Xen doesn't expose the UART to dom0.
> > 
> > This is because Xen wants/tries to use the UART as its own console,
> > right?
> > 
> > There are at least two other options: Either Xen uses a different UART
> > to that configured statically into the kernel image (depends on how many
> > UARTs the platform exposes) or Xen uses no serial console at all.
> > 
> > Of course long term we just need to wait for the exynos stuff to get
> > integrated into the multiplatform kernel.
> > 
> > Having no Xen serial console is not as bad as it seems for actual
> > deployment, it is actually already the default on x86 (a serial console
> > needs to be explicitly configured). The Xen console would still be
> > available via the "xl dmesg" command and for debug environments people
> > can just hack around the issue for now (until MP kernels arrive for the
> > platform).
> > 
> > Perhaps a useful compromise would be for Xen to initially use the
> > console but to hand it over to dom0 once it starts (similar to how we
> > handle VGA where it is present), Xen could also steal it back on panic
> > (since dom0 isn't going to be using it after that...).
> 
> I like this last option, it looks like the best compromise.
> 
> 
> > Alternatively, since these early UART routines tend to be pretty simple
> > polled affairs, we could also consider extending the existing vpl011
> > code to have platform configurable addresses for the output and status
> > registers and a configurable fixed value for the read of the status
> > register. I'm not keen to have this code turn into a full "emulator" but
> > so long as it stays within the remit given in vpl011.c:
> >         /*
> >          * This is not intended to be a full emulation of a PL011
> >          * device. Rather it is intended to provide a sufficient veneer of one
> >          * that early code (such as Linux's boot time decompressor) which
> >          * hardcodes output directly to such a device are able to make progress.
> >          *
> >          * This device is not intended to be enumerable or exposed to the OS
> >          * (e.g. via Device Tree).
> >          */
> > then I think I could live with it getting a bit more flexible about
> > where the registers live in order to be able to handle more UART
> > variants.
>  
> We could end up emulating way too many devices and not all the platforms
> expect a pl011 uart.

My point was that all of these debug routines expect exactly two things:
  * An output register where they can write a character
  * A status register which when read indicates that a new byte can be 
    sent

The existing pl011.c could be extended to provide this level of
functionality for *any* UART, at least to the degree required by this
code, almost trivially, by simply making the two addresses and the
static status register value configurable.

The status register value is static for us because we have no FIFOs and
just accumulate into a buffer to be sent to the real console, so it is
always possible to send another byte.

ISTR some talk of doing something similar for the early-printk stuff via
DT, might have imagined that though...

Ian.