From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Martin Mares <mj@ucw.cz>,
geert@linux-m68k.org, Richard Henderson <rth@twiddle.net>,
"Wiedemeier, Jeff" <Jeff.Wiedemeier@hp.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 2.5] VGA IO on systems with multiple PCI IO domains
Date: 27 Jan 2003 18:55:04 +0100 [thread overview]
Message-ID: <1043690104.2756.42.camel@zion.wanadoo.fr> (raw)
In-Reply-To: <20030127134010.C2569@jurassic.park.msu.ru>
On Mon, 2003-01-27 at 11:40, Ivan Kokshaysky wrote:
> Then vgacon.c would be changed like this:
>
> ...
> - request_resource(&ioport_resource, &vga_console_resource);
> + if (legacy_ioport_remap(&vga_console_resource) < 0)
> + goto failure;
> ...
>
> And all in/out port calls would use respective resource.start+offset:
> ...
> - outb_p(6, 0x3ce)
> + outb_p(6, vga_console_resource.start + 0xe);
>
> No need for other special IO functions then.
Well, your example clearly limits us to one IO space for VGA, which
might not be what we want. The problem also exist for some fbdev drivers
which might need to tap the VGA IOs of a given PCI card (thus getting
access to the "legacy" IOs of the bus the card is on).
It would be nice to provide some more generic solution to deal with that
"ISA" problem...
Finally, in the embedded world, we frequently have to deal with "legacy"
controllers (ethernet, serial, ...) stuffed on whatever bus we have
around, at addresses that might not be usual port addresses.
It's definitely a good idea to always add a "base" to the legacy IOs as
your examples shows though. The problem remaining is how to actually
obtain this address for the various cases whe are interested in.
Ben.
next prev parent reply other threads:[~2003-01-27 17:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-26 15:13 Ivan Kokshaysky
2003-01-26 21:45 ` Martin Mares
2003-01-26 23:40 ` Benjamin Herrenschmidt
2003-01-27 9:46 ` Martin Mares
2003-01-27 10:40 ` Ivan Kokshaysky
2003-01-27 17:55 ` Benjamin Herrenschmidt [this message]
2003-01-27 22:17 ` Ivan Kokshaysky
2003-01-28 9:32 ` Geert Uytterhoeven
2003-01-28 10:24 ` Ivan Kokshaysky
2003-01-28 10:27 ` Geert Uytterhoeven
2003-01-28 10:40 ` Ivan Kokshaysky
2003-01-28 17:10 ` Ivan Kokshaysky
2003-01-28 17:23 ` Benjamin Herrenschmidt
2003-01-28 17:33 ` Ivan Kokshaysky
2003-01-29 16:06 ` Ivan Kokshaysky
2003-01-29 18:15 ` James Simmons
2003-02-05 11:12 ` Ivan Kokshaysky
2003-03-12 19:08 ` Jesse Barnes
2003-01-27 10:12 ` Ivan Kokshaysky
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=1043690104.2756.42.camel@zion.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=Jeff.Wiedemeier@hp.com \
--cc=geert@linux-m68k.org \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@ucw.cz \
--cc=rth@twiddle.net \
/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®