powerpc: udbg based backend for hvc_console

David Gibson david at gibson.dropbear.id.au
Tue Nov 18 11:40:05 EST 2008


On Mon, Nov 17, 2008 at 02:04:38PM -0600, Timur Tabi wrote:
> On Thu, Oct 23, 2008 at 9:54 PM, David Gibson
> <david at gibson.dropbear.id.au> wrote:
> 
> > This can be used to quickly implement a userspace usable console while
> > you're working on a proper driver for whatever console I/O device the
> > hardware has.  Or, it can be used to avoid writing a full blown
> > tty/console driver entirely for quick-and-dirty I/O hardware that will
> > later be replaced by something else.
> 
> Ok, I think I understand this better now.
> 
> Your approach seems backwards to me.  HVC console client drivers
> already have simple put/get functions.  You've written an hvc driver
> that makes udbg calls.  Wouldn't it have been better to make a udbg
> driver that makes hvc calls?  That way, you effectively give udbg
> support to all hvc drivers in one shot.

Well, except that hvc calls aren't necessarily safe in the context
that udbg calls are made.  The idea here is that you want to implement
udbg during bringup anyway, to get really early debug info.  This
means that you can then use that udbg support to get a full console.

> In order to support udbg in my hvc driver, I have to add udbg calls.
> In fact, now that I've thought about it, I don't understand what your
> driver does.  You take hvc callbacks and route them through udbg, but
> this only works on drivers that have udbg callbacks in the first
> place.  In that case, why would these drivers need an hvc middle-man?

Because the udbg console works for kernel messages, but doesn't
support a full tty interface, so you can't run userspace with only a
udbg console.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson



More information about the Linuxppc-dev mailing list