All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frank_rowand@hp.com>
To: Grant Grundler <grundler@cup.hp.com>
Cc: parisc-linux@thepuffingroup.com,
	Helge Deller <Helge.Deller@ruhr-uni-bochum.de>
Subject: Re: [parisc-linux] LASI and serial port initialization
Date: Tue, 19 Oct 1999 09:46:01 -0700	[thread overview]
Message-ID: <380CA049.E16634DF@hp.com> (raw)
In-Reply-To: 199910191630.JAA27454@milano.cup.hp.com

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

  reply	other threads:[~1999-10-19 16:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <99101821580101.00297@P100>
1999-10-19 16:30 ` [parisc-linux] LASI and serial port initialization Grant Grundler
1999-10-19 16:46   ` Frank Rowand [this message]
1999-10-19 16:58   ` Alan Cox
1999-10-19 17:22   ` Philipp Rumpf
1999-10-19 17:32 Mike Hibler
1999-10-19 18:36 ` Grant Grundler
1999-10-19 20:13   ` Phil Schwan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=380CA049.E16634DF@hp.com \
    --to=frank_rowand@hp.com \
    --cc=Helge.Deller@ruhr-uni-bochum.de \
    --cc=frowand@cup.hp.com \
    --cc=grundler@cup.hp.com \
    --cc=parisc-linux@thepuffingroup.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.