From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Russell King <rmk@arm.linux.org.uk>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: uart_match_port() question
Date: Wed, 7 Dec 2005 15:15:11 -0700 [thread overview]
Message-ID: <200512071515.11937.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <1133050906.7768.66.camel@gaston>
On Saturday 26 November 2005 5:21 pm, Benjamin Herrenschmidt wrote:
> The reason is a bit complicated, but basically, we have some arch code
> that builds a list of available serial ports very early and registers that
> as a platform device. It also detects which one is the default firmware port
> and what speed it's been configured for and builds a proper config line to
> pass to add_preferred_console() so we get the default serial console setup
> properly automatically.
>
> This list includes however ports that are on PCI devices on some recent
> machines. Thus, we need to make sure that, when 8250_pci.c kicks in, it
> property detects that those platform ports are the same it's discovered
> and thus properly re-uses the same port & minor.
[Sorry for the late response, I haven't been keeping up on lkml lately.]
ia64 has basically the same situation. I decided it was a mistake to
have the arch code register serial ports early, because we only learn
about a few of the ports early, and the firmware console configuration
determines which ones we learn about.
The consequence is that changing the firmware configuration changes the
serial device names, which I thought was a bad thing.
I finally settled on this scheme:
- discover default firmware port (pcdp.c)
- set it up as an "early uart" which has no ttyS name
and runs in polled mode (early_serial_console_init())
- register it as a console
- let 8250_{pci,pnp,etc} discover all the ports and
figure out minor numbers (i.e., ttyS names)
- locate the port that matches the default firmware port,
switch console to it, and unregister the "early uart"
(early_uart_console_switch())
This all should work for any arch, though I've only really tried it on
ia64. Of course, the pcdp.c part would have to be replaced. You can
try it out without the firmware support using the "console=uart"
argument:
console= [KNL] Output console device and options.
...
uart,io,<addr>[,options]
uart,mmio,<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
next prev parent reply other threads:[~2005-12-07 22:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-27 0:21 Benjamin Herrenschmidt
2005-11-28 11:30 ` Russell King
2005-11-28 11:36 ` Benjamin Herrenschmidt
2005-12-07 22:15 ` Bjorn Helgaas [this message]
2005-12-07 23:13 ` Benjamin Herrenschmidt
2005-12-07 23:36 ` Bjorn Helgaas
2005-12-08 0:17 ` Benjamin Herrenschmidt
2005-12-08 16:26 ` Bjorn Helgaas
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=200512071515.11937.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®