powerpc: udbg based backend for hvc_console

[Milton Miller]

On Nov 21, 2008, at 10:13 AM, Timur Tabi wrote:
> Milton Miller wrote:
>> We want the last console= parameter on the command line to win.  So if
>> that implys the last call to add_preferred_console wins, then you have
>> code overriding the command line.
>
> Hmm, good point.  However, how likely is it that we'll have more than 
> one
> console driver?

For anything than custom embedded configs, quite likely.   As I said, I 
have 3 hvc clients, but that is unusual.  But frame buffer, vterm, 
rtas, and serial console would be a typical mix for a distribution.

> Also, without calling add_preferred_console(), the kernel needs
> to have a console= on the command line.

I'm not arguing against the call, I'm arguing when/from where it should 
be made.

> In my case, my driver only calls add_preferred_console() if the device 
> tree
> contains a specific property that it looks for.  In effect, this 
> property
> override the console= line.  However, the console= line goes to the HVC
> subsystem, and not my driver, and I can't use it to send the 
> configuration data
> the driver needs.

Discovering the hardware from the device tree and triggering your 
regitration is the right approach.  I think if you discover from an 
early setup then you can go before the command line.

As far as getting parameters, you are talking like ttyS0,9600,8,n,1 ? 
If you go after hvc_console then you could add a patch for hvc_console 
to remember the setup and return it to possible clients.

> Unfortunately, my driver hasn't been published yet, so it's hard to 
> explain the
> details.  I guess I need to think about this more.

I dont' know what details you would want on the console= command line 
that you should not have in the device tree.   If its which hypervisor 
channel, then I would think just choosing your hvc number accordingly 
would work.  But I can only make wild guesses without details.

milton