[parisc-linux] LASI and serial port initialization

[parisc-linux] LASI and serial port initialization

[Grant Grundler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]


Helge and I exchanged some e-mail on the topic of LASI vis a vie
serial port initialization. Since then, I've come to the conclusion
all (or most) parisc platforms will have a similar problem.

The problem is LASI is "discovered" and initialized well after several
other drivers want to print things to the console. I see a few options
on how to handle it:
1) For each platform, force the console to be the first device "discovered"
   and initialized. This is not a really good idea since console can be
   different depending on configuration. Rebuilding the kernel to use
   a different console doesn't seem reasonable to me. Having the user
   figure out which devices need to be initialized first and build an
   appropriate kernel so console works also seems unreasonable.  We are
   headed down this path now though....

2) Use IODC until the console device is "owned" by the appropriate driver
   and can start taking input/output. 

3) buffer the output instead of calling IODC.
   Size of the buffer will impose some sort of limit.
   I think this is what HP-UX does but don't really know
   and it shouldn't matter to us.

Either 2 or 3 requires some software layer behind printk to change
behavior at some point. I don't know where that point is or how
exactly to define it. I just thought going down path #1 is going
to be a real pain to support on a broad set of platforms.

Any other thoughts?

BTW, I still don't know if Helge's changes to inventory.c are
needed or not. I don't have the warm fuzzy feeling they are needed
but can't prove they aren't either.

grant

Helge Deller wrote:
> Am Mon, 18 Oct 1999 schrieben Sie:
> > Helge,
> > I never understood this chunk of very well. I was wondering
> > why you moved code from the case HPHW_BA to outside the switch
> > statement in do_oldhw_inventory()? (inventory.c)
> > 
> > If this is of general interest please post to parisc-linux...
> > 
> > thanks,
> > grant
> 
> Hi Grant.
> 
> I just wanted to get it working, so I moved stuff around until it worked. Wit
>   h
> this I found, that the LASI-Controller should be added to the list before all
> other stuff underlying the lasi (same is also to the WAX(??)-controller with
> PS2/Keyboard/Mouse/RS232/HIL). This way it worked and I didn´t thought too muc
>   h
> about it later....   :-)
> 
> [Is this for global interrest ??]

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] LASI and serial port initialization

[Frank Rowand]

Grant Grundler wrote:
> 
> Helge and I exchanged some e-mail on the topic of LASI vis a vie
> serial port initialization. Since then, I've come to the conclusion
> all (or most) parisc platforms will have a similar problem.
> 
> The problem is LASI is "discovered" and initialized well after several
> other drivers want to print things to the console. I see a few options
> on how to handle it:
> 1) For each platform, force the console to be the first device "discovered"
>    and initialized. This is not a really good idea since console can be
>    different depending on configuration. Rebuilding the kernel to use
>    a different console doesn't seem reasonable to me. Having the user
>    figure out which devices need to be initialized first and build an
>    appropriate kernel so console works also seems unreasonable.  We are
>    headed down this path now though....
> 
> 2) Use IODC until the console device is "owned" by the appropriate driver
>    and can start taking input/output.
> 
> 3) buffer the output instead of calling IODC.
>    Size of the buffer will impose some sort of limit.
>    I think this is what HP-UX does but don't really know
>    and it shouldn't matter to us.

Yes, this is what HP-UX does.  And in the case of a panic, the buffered
messages are flushed to the console via IODC.

> Either 2 or 3 requires some software layer behind printk to change
> behavior at some point. I don't know where that point is or how
> exactly to define it. I just thought going down path #1 is going
> to be a real pain to support on a broad set of platforms.
> 
> Any other thoughts?

Yes, 2 or 3 sound best.

Some pros & cons... (assume that the pros are the opposite of the cons
for the other option)

  2) con: - polled I/O
          - may need to add infrastructure to do IODC I/O (but this should
            be in place for the panic and dump path anyway)
     pro: - should work on all platforms, once it works on one

  3) con: - when debugging new drivers and platforms, you won't get any
            debugging messages until the console driver works

-Frank

Re: [parisc-linux] LASI and serial port initialization

[Alan Cox]

> 2) Use IODC until the console device is "owned" by the appropriate driver
>    and can start taking input/output. 

That is basically the sparc approach. It also works well for bootstrapping
new hardware - nothing claims the console so you can see what happens until
you fix it

> Either 2 or 3 requires some software layer behind printk to change
> behavior at some point. I don't know where that point is or how

Not really. We have register_console() and unregister_console() already
in existance.

Alan

Re: [parisc-linux] LASI and serial port initialization

[Philipp Rumpf]

> 3) buffer the output instead of calling IODC.

This is what Linux does (have a look at kernel/printk.c)

Re: [parisc-linux] LASI and serial port initialization

[Mike Hibler]

We did all three of these at one point or another (in our BSD and Mach).
Our variation on #1 was that we had a separate pseudo-console device that
used a private interface to the drivers.  So the serial driver and STI
(graphics) had cn_init, cn_putc, etc. functions.  cn_init would take
whatever measures necessary to ensure that the HW was setup independent
of the normal kernel HW probe path.  Console_init was called as early as
possible and then called again after the bus walk was done (since that
screwed up the serial port).

On hp300s (long ago!) we had a cn_probe for each possible console device
that was called first thing so we could choose the "highest priority" device
as the console at boot time.  Carrying this approach over to the PA, we
originally had a pdc_console device to do #2.  It was the "default" console
til the real console_init got done.

For our BSD we basically just do #3, buffering output until the real console
comes up and then dumping the buffer before anything else.  The "real
console" in this case is whatever the PDC tells us it is (serial or graphics).

Personally I don't see spending a lot of time worrying about this.  Our
simple console interface with pre-init buffering has been perfectly adequate
for us.  But our PA world is pretty simple, older 700 series machines and
one J-series.  So the console is either the builtin serial port or the
graphics device.  Are there that many more options now?

> To: parisc-linux@thepuffingroup.com
> Date: Tue, 19 Oct 1999 09:30:45 -0700
> From: Grant Grundler <grundler@cup.hp.com>
> Subject: [parisc-linux] LASI and serial port initialization
> 
> Helge and I exchanged some e-mail on the topic of LASI vis a vie
> serial port initialization. Since then, I've come to the conclusion
> all (or most) parisc platforms will have a similar problem.
> 
> The problem is LASI is "discovered" and initialized well after several
> other drivers want to print things to the console. I see a few options
> on how to handle it:
> 1) For each platform, force the console to be the first device "discovered"
>    and initialized. This is not a really good idea since console can be
>    different depending on configuration. Rebuilding the kernel to use
>    a different console doesn't seem reasonable to me. Having the user
>    figure out which devices need to be initialized first and build an
>    appropriate kernel so console works also seems unreasonable.  We are
>    headed down this path now though....
> 
> 2) Use IODC until the console device is "owned" by the appropriate driver
>    and can start taking input/output. 
> 
> 3) buffer the output instead of calling IODC.
>    Size of the buffer will impose some sort of limit.
>    I think this is what HP-UX does but don't really know
>    and it shouldn't matter to us.
> 

Re: [parisc-linux] LASI and serial port initialization

[Grant Grundler]

Mike Hibler wrote:
...
> Personally I don't see spending a lot of time worrying about this.  Our
> simple console interface with pre-init buffering has been perfectly adequate
> for us. 

I agree the pre-init buffering is perfectly acceptable. No problem.

> But our PA world is pretty simple, older 700 series machines and
> one J-series.  So the console is either the builtin serial port or the
> graphics device.  Are there that many more options now?

No. But I expect at least two more options by next year.
But even with just two options I think my reasons are valid.

grant

ps. I'm still doing homework to reply to Kirk's response about clock drift.
Short answer is I belive him about N-class and thus don't care if this is
just a T- or possibly V-class problem.

Grant Grundler
Unix Developement Lab
+1.408.447.7253

Re: [parisc-linux] LASI and serial port initialization

[Phil Schwan]

On Oct 19, Grant Grundler wrote:
> I agree the pre-init buffering is perfectly acceptable. No problem.

I think the point that many people have noted (regarding ports to new
platforms and seeing data before the console is up) is worth thinking
about.  Why not register an IODC console immediately, and then
register a preferred console once it becomes available?

-Phil