From: ebiederm@xmission.com (Eric W. Biederman)
To: "Stuart MacDonald" <stuartm@connecttech.com>
Cc: "Khalid Aziz" <khalid@fc.hp.com>,
"Linux kernel development list" <linux-kernel@vger.kernel.org>
Subject: Re: Support for serial console on legacy free machines
Date: 31 Jul 2001 10:00:12 -0600 [thread overview]
Message-ID: <m1hevtytpv.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200107302332.f6UNWbxg001791@webber.adilger.int> <3B65F1A2.30708CC1@fc.hp.com> <000701c119cd$ebf0c720$294b82ce@connecttech.com>
In-Reply-To: <000701c119cd$ebf0c720$294b82ce@connecttech.com>
"Stuart MacDonald" <stuartm@connecttech.com> writes:
> From: "Khalid Aziz" <khalid@fc.hp.com>
> > AFAIK, you can not have console on a PCI serial port at this time. I
> > looked at it few months back and found out that PCI initialization
> > happens much too late for a serial console. It would take quite a bit of
>
> That's very odd. That implies that serial consoles don't use the serial
> driver at all then, as the pci serial port setup is done at the same
> time as the regular serial port setups.
>
> If a serial console is using serial.c, the pci serial ports will also
> be available.
>
> Hm, looking through the driver quick, I find some interesting things:
>
> A) Serial console support is mutually exclusive with the serial driver
> being a module.
> B) The serial console will not share its irq. Other ports with the same
> irq are set to polled mode. This may impact performance. It also suggests
> that using the console on a pci board isn't a good idea, as pci will
> share the irq to other devices.
> C) serial.c contains a completely separate serial console driver,
> complete with its own init routine. Which meshes with the current
> suggestion that the "serial driver" isn't used, and pci init happens
> too late.
>
> > work to get serial console working on PCI cards. PA-Linux faced the same
> > problem but they were able to get around it by using the firmware calls
> > to do console I/O. If serial console were working on PCI serial cards,
> > you wouldn't need ACPI to use it.
>
> It seems like pci consoles won't work, now that I think about it.
It depends. The pci iniitalization is straight forward. It should
be relatively simple to build a pci serial driver that hard codes the
pci card. I have done similiar things because for some debugging I
have done the current serial console is initialized too late. So I
hacked a hardcoded driver into printk.c
> The
> console driver gets an index, which I'm going to assume works thusly:
> lilo console=ttyS1 ends up passing 1 as the index. That index is used
> to pick a serial port out of the array of serial ports that the driver
> knows about. If console init happens early, and serial driver init happens
> late (it would be dependent on pci init) then only hard coded ports
> would work. Those are defined in asm/serial.h, and for i386 include the
> standard ports, and a number of isa ports from various board manufacturers.
>
> Using one of our pci ports would require knowledge of its io address,
> which wouldn't be available until the pci subsystem had inited. Perhaps
> that could be changed to allow pci based consoles?
I would say the simple solution would be to add a configure option to
do an early PCI init on the card, and to hard code it's ports.
> Elsethread someone mentions a stripped down usb console driver; that's
> analogous to the serial console driver contained in serial.c. And if
> serial can do it...
If it isn't too complex.
Eric
next prev parent reply other threads:[~2001-07-31 16:07 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-30 21:26 Support for serial console on legacy free machines Andreas Dilger
2001-07-30 21:38 ` Khalid Aziz
2001-07-30 22:40 ` Andreas Dilger
2001-07-30 22:53 ` Jan-Benedict Glaw
2001-07-30 22:53 ` Maciej W. Rozycki
2001-07-30 23:00 ` Khalid Aziz
2001-07-30 23:17 ` Randy.Dunlap
2001-07-30 23:39 ` Khalid Aziz
2001-07-30 23:52 ` Randy.Dunlap
2001-07-30 23:32 ` Andreas Dilger
2001-07-30 23:40 ` Ignacio Vazquez-Abrams
2001-07-30 23:45 ` Khalid Aziz
2001-07-31 14:34 ` Stuart MacDonald
2001-07-31 15:54 ` Miquel van Smoorenburg
2001-07-31 16:00 ` Eric W. Biederman [this message]
2001-07-31 16:10 ` Khalid Aziz
2001-07-31 16:39 ` Andreas Dilger
2001-07-31 18:43 ` Russell King
2001-08-01 2:01 ` Keith Owens
2001-07-31 16:42 ` Russell King
2001-07-31 17:14 ` Stuart MacDonald
2001-07-31 18:46 ` Russell King
2001-08-01 3:21 ` Eric W. Biederman
2001-08-01 3:39 ` Ignacio Vazquez-Abrams
2001-07-31 1:33 ` Keith Owens
2001-07-31 4:50 ` Johannes Erdfelt
2001-07-31 16:15 ` Khalid Aziz
2001-07-29 20:47 ` Alan Cox
2001-07-31 16:20 ` Randy.Dunlap
[not found] <no.id>
2001-07-26 22:20 ` Alan Cox
2001-07-30 17:47 ` Khalid Aziz
-- strict thread matches above, loose matches on Subject: below --
2001-07-26 21:13 Khalid Aziz
2001-07-27 13:28 ` Simon Richter
2001-07-30 17:49 ` Khalid Aziz
2001-07-30 18:21 ` Rik van Riel
2001-07-30 19:39 ` Khalid Aziz
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=m1hevtytpv.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=khalid@fc.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stuartm@connecttech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).