From: "David S. Miller" <davem@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Going beyond 256 PCI buses
Date: Thu, 14 Jun 2001 15:12:57 -0700 (PDT) [thread overview]
Message-ID: <15145.14057.67940.752173@pizda.ninka.net> (raw)
In-Reply-To: <20010614215709.23875@smtp.wanadoo.fr>
In-Reply-To: <15145.12584.339783.786454@pizda.ninka.net> <20010614215709.23875@smtp.wanadoo.fr>
Benjamin Herrenschmidt writes:
> That would be fine for PIO on PCI, but still is an issue for
> VGA-like devices that need to issue some "legacy" cycles on
> a given domain. Currently, on PPC, inx/outx will only go to
> one bus (arbitrarily choosen during boot) because of that,
> meaning that we can't have 2 VGA cards on 2 different domains
It's funny you mention this because I have been working on something
similar recently. Basically making xfree86 int10 and VGA poking happy
on sparc64.
But this has no real use in the kernel. (actually I take this back,
read below)
You have a primary VGA device, that is the one the bios (boot
firmware, whatever you want to call it) enables to respond to I/O and
MEM accesses, the rest are configured to VGA pallette snoop and that's
it. The primary VGA device is the kernel console (unless using some
fbcon driver of course), and that's that.
The secondary VGA devices are only interesting to things like the X
server, and xfree86 does all the enable/disable/bridge-forward-vga
magic when doing multi-head.
Perhaps, you might need to program the VGA resources of some device to
use it in a fbcon driver (ie. to init it or set screen crt parameters,
I believe the tdfx requires the latter which is why I'm having a devil
of a time getting it to work on my sparc64 box). This would be a
seperate issue, and I would not mind at all seeing an abstraction for
this sort of thing, let us call it:
struct pci_vga_resource {
struct resource io, mem;
};
int pci_route_vga(struct pci_dev *pdev, struct pci_vga_resource *res);
pci_restore_vga(void);
So you'd go:
struct pci_vga_resource vga_res;
int err;
err = pci_route_vga(tdfx_pdev, &vga_res);
if (err)
barf();
vga_ports = ioremap(vga_res.io.start, vga_res.io.end-vga_res.io.start+1);
program_video_crtc_params(vga_ports);
iounmap(vga_ports);
vga_fb = ioremap(vga_res.mem.start, vga_res.mem.end-vga_res.mem.start+1);
clear_vga_fb(vga_fb);
iounmap(vga_fb);
pci_restore_vga();
pci_route_vga does several things:
1) It saves the current VGA routing information.
2) It configures busses and VGA devices such that PDEV responds to
VGA accesses, and other VGA devices just VGA palette snoop.
3) Fills in the pci_vga_resources with
io: 0x320-->0x340 in domain PDEV lives, vga I/O regs
mem: 0xa0000-->0xc0000 in domain PDEV lives, video ram
pci_restore_vga, as the name suggests, restores things back to how
they were before the pci_route_vga() call. Maybe also some semaphore
so only one driver can do this at once and you can't drop the
semaphore without calling pci_restore_vga(). VC switching into the X
server would need to grab this thing too.
Later,
David S. Miller
davem@redhat.com
next prev parent reply other threads:[~2001-06-14 22:13 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-13 10:02 Tom Gall
2001-06-13 17:17 ` Albert D. Cahalan
2001-06-13 18:29 ` Tom Gall
2001-06-14 14:14 ` Jeff Garzik
2001-06-14 15:15 ` David S. Miller
2001-06-14 17:59 ` Jonathan Lundell
2001-06-14 20:50 ` Jonathan Lundell
2001-06-14 14:24 ` David S. Miller
2001-06-14 14:32 ` Jeff Garzik
2001-06-14 14:42 ` David S. Miller
2001-06-14 15:29 ` Jeff Garzik
2001-06-14 15:33 ` Jeff Garzik
2001-06-14 18:01 ` Albert D. Cahalan
2001-06-14 18:47 ` David S. Miller
2001-06-14 19:04 ` Albert D. Cahalan
2001-06-14 19:12 ` David S. Miller
2001-06-14 19:41 ` Jeff Garzik
2001-06-14 19:57 ` David S. Miller
2001-06-14 20:08 ` Jeff Garzik
2001-06-14 20:14 ` David S. Miller
2001-06-14 21:30 ` Benjamin Herrenschmidt
2001-06-14 21:46 ` Jeff Garzik
2001-06-14 21:48 ` David S. Miller
2001-06-14 21:57 ` Benjamin Herrenschmidt
2001-06-14 22:12 ` David S. Miller [this message]
2001-06-14 22:29 ` Benjamin Herrenschmidt
2001-06-14 22:49 ` David S. Miller
2001-06-14 23:35 ` Benjamin Herrenschmidt
2001-06-14 23:35 ` VGA handling was [Re: Going beyond 256 PCI buses] James Simmons
2001-06-14 23:42 ` David S. Miller
2001-06-14 23:55 ` James Simmons
2001-06-15 15:14 ` Pavel Machek
2001-06-15 2:06 ` Albert D. Cahalan
2001-06-15 8:52 ` Matan Ziv-Av
2001-06-14 21:35 ` Going beyond 256 PCI buses David S. Miller
2001-06-14 21:46 ` Benjamin Herrenschmidt
2001-06-16 21:32 ` Jeff Garzik
2001-06-16 23:29 ` Benjamin Herrenschmidt
2001-06-15 8:42 ` Geert Uytterhoeven
2001-06-15 15:38 ` David S. Miller
2001-06-14 19:03 ` David S. Miller
2001-06-14 20:56 ` David S. Miller
2001-06-14 15:13 ` Jonathan Lundell
2001-06-14 15:17 ` Jeff Garzik
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=15145.14057.67940.752173@pizda.ninka.net \
--to=davem@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
/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®