Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 31 Jan 2005 22:38:17 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > Ick, patch wasn't inline for me to comment on it :( Here's the patch inline. Big things that need to be addressed... 1) Generating the user space reset event. I tried using the pci hotplug event but ran into the fb blacklist. The reset events need to be serialized across multiple cards. Make a temp kobj or just use call_userspacehelp? 2) Things need to be set up so that it will generate the reset event when compiled in. So the event has to come after early user space is set up. 3) Where does this code go? It's not a specific device driver since it doesn't attach to a single piece of hardware. I also run into interference from existing fb driver as a normal device driver. It needs to tie into drivers for bus chips when those happen. 4) It needs to monitor hotplug add/remove. If you pull the bus with the console on it, it will try to move the console to another VGA device. diff -Nru a/arch/i386/pci/fixup.c b/arch/i386/pci/fixup.c --- a/arch/i386/pci/fixup.c 2005-01-27 04:01:08 -05:00 +++ b/arch/i386/pci/fixup.c 2005-01-27 04:01:08 -05:00 @@ -375,6 +375,6 @@ } bus = bus->parent; } - pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW; + pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW | IORESOURCE_VGA_ACTIVE; } DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video); diff -Nru a/drivers/pci/Kconfig b/drivers/pci/Kconfig --- a/drivers/pci/Kconfig 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/Kconfig 2005-01-27 04:01:08 -05:00 @@ -47,3 +47,13 @@ When in doubt, say Y. +config VGA_CONTROL + bool "VGA Control" + depends on PCI + ---help--- + Provides sysfs attributes for ensuring that only a single VGA + device can be enabled per PCI domain. If a VGA device is removed + via hotplug, display is routed to another VGA device if available. + + If you have more than one VGA device, say Y. + diff -Nru a/drivers/pci/Makefile b/drivers/pci/Makefile --- a/drivers/pci/Makefile 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/Makefile 2005-01-27 04:01:08 -05:00 @@ -28,6 +28,7 @@ obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o obj-$(CONFIG_X86_VISWS) += setup-irq.o obj-$(CONFIG_PCI_MSI) += msi.o +obj-$(CONFIG_VGA_CONTROL) += vga.o # # ACPI Related PCI FW Functions diff -Nru a/drivers/pci/bus.c b/drivers/pci/bus.c --- a/drivers/pci/bus.c 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/bus.c 2005-01-27 04:01:08 -05:00 @@ -85,6 +85,9 @@ pci_proc_attach_device(dev); pci_create_sysfs_dev_files(dev); +#if CONFIG_VGA_CONTROL + pci_vga_add_device(dev); +#endif } /** diff -Nru a/drivers/pci/pci.h b/drivers/pci/pci.h --- a/drivers/pci/pci.h 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/pci.h 2005-01-27 04:01:08 -05:00 @@ -11,6 +11,8 @@ void (*alignf)(void *, struct resource *, unsigned long, unsigned long), void *alignf_data); +extern int pci_vga_add_device(struct pci_dev *pdev); +extern int pci_vga_remove_device(struct pci_dev *pdev); /* PCI /proc functions */ #ifdef CONFIG_PROC_FS extern int pci_proc_attach_device(struct pci_dev *dev); diff -Nru a/drivers/pci/remove.c b/drivers/pci/remove.c --- a/drivers/pci/remove.c 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/remove.c 2005-01-27 04:01:08 -05:00 @@ -26,6 +26,9 @@ static void pci_destroy_dev(struct pci_dev *dev) { +#if CONFIG_VGA_CONTROL + pci_vga_remove_device(dev); +#endif pci_proc_detach_device(dev); pci_remove_sysfs_dev_files(dev); device_unregister(>dev); diff -Nru a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c --- a/drivers/pci/setup-bus.c 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/setup-bus.c 2005-01-27 04:01:08 -05:00 @@ -64,7 +64,9 @@ if (class == PCI_CLASS_DISPLAY_VGA || class == PCI_CLASS_NOT_DEFINED_VGA) - bus->bridge_ctl |= PCI_BRIDGE_CTL_VGA; + /* only route to the active VGA, ignore inactive ones */ + if (dev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_VGA_ACTIVE) + bus->bridge_ctl |= PCI_BRIDGE_CTL_VGA; pdev_sort_resources(dev, ); } diff -Nru a/drivers/pci/vga.c b/drivers/pci/vga.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/pci/vga.c 2005-01-27 04:01:08 -05:00 @@ -0,0 +1,254 @@ +/* + * linux/drivers/pci/vga.c + * + * (C) Copyright 2004 Jon Smirl <[EMAIL PROTECTED]> + * + * VGA control logic for ensuring only a single enabled VGA device + */ + +#include +#include +#include +#include +#include + +static int vga_initialized = 0; +static struct pci_dev *vga_active = NULL; + +static void bridge_yes(struct pci_dev *pdev) +{ + struct
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 31 Jan 2005 22:38:17 -0800, Greg KH [EMAIL PROTECTED] wrote: Ick, patch wasn't inline for me to comment on it :( Here's the patch inline. Big things that need to be addressed... 1) Generating the user space reset event. I tried using the pci hotplug event but ran into the fb blacklist. The reset events need to be serialized across multiple cards. Make a temp kobj or just use call_userspacehelp? 2) Things need to be set up so that it will generate the reset event when compiled in. So the event has to come after early user space is set up. 3) Where does this code go? It's not a specific device driver since it doesn't attach to a single piece of hardware. I also run into interference from existing fb driver as a normal device driver. It needs to tie into drivers for bus chips when those happen. 4) It needs to monitor hotplug add/remove. If you pull the bus with the console on it, it will try to move the console to another VGA device. diff -Nru a/arch/i386/pci/fixup.c b/arch/i386/pci/fixup.c --- a/arch/i386/pci/fixup.c 2005-01-27 04:01:08 -05:00 +++ b/arch/i386/pci/fixup.c 2005-01-27 04:01:08 -05:00 @@ -375,6 +375,6 @@ } bus = bus-parent; } - pdev-resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW; + pdev-resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW | IORESOURCE_VGA_ACTIVE; } DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video); diff -Nru a/drivers/pci/Kconfig b/drivers/pci/Kconfig --- a/drivers/pci/Kconfig 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/Kconfig 2005-01-27 04:01:08 -05:00 @@ -47,3 +47,13 @@ When in doubt, say Y. +config VGA_CONTROL + bool VGA Control + depends on PCI + ---help--- + Provides sysfs attributes for ensuring that only a single VGA + device can be enabled per PCI domain. If a VGA device is removed + via hotplug, display is routed to another VGA device if available. + + If you have more than one VGA device, say Y. + diff -Nru a/drivers/pci/Makefile b/drivers/pci/Makefile --- a/drivers/pci/Makefile 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/Makefile 2005-01-27 04:01:08 -05:00 @@ -28,6 +28,7 @@ obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o obj-$(CONFIG_X86_VISWS) += setup-irq.o obj-$(CONFIG_PCI_MSI) += msi.o +obj-$(CONFIG_VGA_CONTROL) += vga.o # # ACPI Related PCI FW Functions diff -Nru a/drivers/pci/bus.c b/drivers/pci/bus.c --- a/drivers/pci/bus.c 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/bus.c 2005-01-27 04:01:08 -05:00 @@ -85,6 +85,9 @@ pci_proc_attach_device(dev); pci_create_sysfs_dev_files(dev); +#if CONFIG_VGA_CONTROL + pci_vga_add_device(dev); +#endif } /** diff -Nru a/drivers/pci/pci.h b/drivers/pci/pci.h --- a/drivers/pci/pci.h 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/pci.h 2005-01-27 04:01:08 -05:00 @@ -11,6 +11,8 @@ void (*alignf)(void *, struct resource *, unsigned long, unsigned long), void *alignf_data); +extern int pci_vga_add_device(struct pci_dev *pdev); +extern int pci_vga_remove_device(struct pci_dev *pdev); /* PCI /proc functions */ #ifdef CONFIG_PROC_FS extern int pci_proc_attach_device(struct pci_dev *dev); diff -Nru a/drivers/pci/remove.c b/drivers/pci/remove.c --- a/drivers/pci/remove.c 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/remove.c 2005-01-27 04:01:08 -05:00 @@ -26,6 +26,9 @@ static void pci_destroy_dev(struct pci_dev *dev) { +#if CONFIG_VGA_CONTROL + pci_vga_remove_device(dev); +#endif pci_proc_detach_device(dev); pci_remove_sysfs_dev_files(dev); device_unregister(dev-dev); diff -Nru a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c --- a/drivers/pci/setup-bus.c 2005-01-27 04:01:08 -05:00 +++ b/drivers/pci/setup-bus.c 2005-01-27 04:01:08 -05:00 @@ -64,7 +64,9 @@ if (class == PCI_CLASS_DISPLAY_VGA || class == PCI_CLASS_NOT_DEFINED_VGA) - bus-bridge_ctl |= PCI_BRIDGE_CTL_VGA; + /* only route to the active VGA, ignore inactive ones */ + if (dev-resource[PCI_ROM_RESOURCE].flags IORESOURCE_VGA_ACTIVE) + bus-bridge_ctl |= PCI_BRIDGE_CTL_VGA; pdev_sort_resources(dev, head); } diff -Nru a/drivers/pci/vga.c b/drivers/pci/vga.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/pci/vga.c 2005-01-27 04:01:08 -05:00 @@ -0,0 +1,254 @@ +/* + * linux/drivers/pci/vga.c + * + * (C) Copyright 2004 Jon Smirl [EMAIL PROTECTED] + * + * VGA control logic for ensuring only a single enabled VGA device + */ + +#include linux/init.h +#include linux/fs.h +#include linux/cdev.h +#include linux/pci.h +#include linux/major.h + +static int vga_initialized = 0; +static struct pci_dev *vga_active = NULL; + +static void
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Thu, Jan 27, 2005 at 04:59:45AM -0500, Jon Smirl wrote: > On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > > This can be done today in the bus specific match functions. And because > > of that, I would argue that this belongs in the bus specific code, and > > not in the driver core, as it's up to the bus to know what the different > > types of "matches" that can happen, and what the priority is. > > Here's a version of the VGA control code that actually works. It helps > if I pci_enable() the device before using it. There was nothing wrong > with the routing code. > > I can also control multiple cards on the same bus by turning on/off > their response to IO space and then enabling VGA via the standard > ports. I can use this to move my console from card to card. > > I have this code in drivers/pci because it needs to know add/remove > from hotplug. Is there a better way to structure it? Note that this is > not a VGA device, it is just a mechanism for controlling which VGA > device is active. > > Another item I need to add is generating an initial hotplug event for > each secondary card. This event has to happen even if there is a card > specific driver loaded. The event will be used to run the reset > program needed by secondary cards. Ick, patch wasn't inline for me to comment on it :( Anyway, get rid of the ifdefs in the kernel .c code to start with. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Gwe, 2005-01-28 at 20:00, Matthew Wilcox wrote: > Possibly a better solution (less likely to break things) would be to allow > drivers to reserve the 10-bit aliases too. Something like this: > > static inline void request_isa_alias_regions(unsigned long start, > unsigned long n, const char *name) > { > int base; > for (base = 0x400; base < 0x1; base += 0x400) { > request_region(base + start, n, name); > } > } > > and then call that in drivers/video/console/vgacon.c Almost every x86 I/O device in ISA space has this problem so it would be better if request_region learned to take a decode mask instead of adding another 500 entries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Thu, Jan 27, 2005 at 04:59:45AM -0500, Jon Smirl wrote: On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH [EMAIL PROTECTED] wrote: This can be done today in the bus specific match functions. And because of that, I would argue that this belongs in the bus specific code, and not in the driver core, as it's up to the bus to know what the different types of matches that can happen, and what the priority is. Here's a version of the VGA control code that actually works. It helps if I pci_enable() the device before using it. There was nothing wrong with the routing code. I can also control multiple cards on the same bus by turning on/off their response to IO space and then enabling VGA via the standard ports. I can use this to move my console from card to card. I have this code in drivers/pci because it needs to know add/remove from hotplug. Is there a better way to structure it? Note that this is not a VGA device, it is just a mechanism for controlling which VGA device is active. Another item I need to add is generating an initial hotplug event for each secondary card. This event has to happen even if there is a card specific driver loaded. The event will be used to run the reset program needed by secondary cards. Ick, patch wasn't inline for me to comment on it :( Anyway, get rid of the ifdefs in the kernel .c code to start with. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > And yes, I agree that this needs to be done, I've been talking with a > few other people who are interested in it. I think the lock-rework code > needs to be finished before it can happen properly, so that we can do > the "unbind from one driver and give it to another one" type logic > properly. Unbind/give does not address what VGA control needs. VGA control needs to track hotplug remove events so that it can route the display to another VGA card if the active display is pulled. As far as I can tell there is no way to monitor hotplug remove events, that's why I had to add a callout in pci_destroy_dev(). VGA control also can't just install a device driver since that will prevent the real DRM/FB device drivers from installing. It looks to me like VGA control is more of a strange property of the PCI bus architecture than a device driver. Another strategy would be to create the concept of a PCI class driver which a normal device driver would inherit from instead of replacing it. But is there a need for another PCI class driver other than VGA? -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH [EMAIL PROTECTED] wrote: And yes, I agree that this needs to be done, I've been talking with a few other people who are interested in it. I think the lock-rework code needs to be finished before it can happen properly, so that we can do the unbind from one driver and give it to another one type logic properly. Unbind/give does not address what VGA control needs. VGA control needs to track hotplug remove events so that it can route the display to another VGA card if the active display is pulled. As far as I can tell there is no way to monitor hotplug remove events, that's why I had to add a callout in pci_destroy_dev(). VGA control also can't just install a device driver since that will prevent the real DRM/FB device drivers from installing. It looks to me like VGA control is more of a strange property of the PCI bus architecture than a device driver. Another strategy would be to create the concept of a PCI class driver which a normal device driver would inherit from instead of replacing it. But is there a need for another PCI class driver other than VGA? -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 08:00:10PM +, Matthew Wilcox wrote: > I've been thinking for a while that we should mark the 10-bit aliases > of ISA devices as used ISTR that windows does this. > Russell, would that allay your issues with the kernel io resource database? It makes the situation a whole lot clearer from the point of working out what is free and what isn't, making it less likely that we'll trample over some magic port which your VGA card needs. This, along with throwing in the ports found via ACPI (which Dominik has hinted) should (maybe that's the wrong word) give us a complete picture and allow things like PCMCIA to do reliable resource allocation. The same goes for Cardbus/PCI as well of course. Maybe at this point the idea that you need to tell PCMCIA about which resources it can validly use can finally be eliminated, which is a big step towards eliminating it's dependence on userspace. (I hope this is what you were talking about and I haven't just produced a load of unrelated waffle!) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 12:33:20PM -0700, Grant Grundler wrote: > > > If it is intended to work with multiple IO Port address spaces, > > > then it needs to use the pci_dev->resource[] and mangle that > > > appropriately. > > > > There is no resource for some of the I/O port space that cards respond to. > > Yes - I've heard several graphics cards are horrible broken WRT address > decoding. Are PCI quirks supposed to handle that sort of thing? No, PCI quirks are for fixing broken things. VGA cards are entitled to 3c0-3df and all their 10-bit aliases. I've been thinking for a while that we should mark the 10-bit aliases of ISA devices as used ... ie: x100-x3ff x500-x7ff x900-xbff xd00-xfff Unfortunately, that may break some legitimate setups, but is hinted at being a good idea in the EISA docs I've read. My laptop uses only the 10-bit aliases of motherboard space (x000-x0ff, x400-x4ff, x800-x8ff, xc00-xcff) for devices, except for the ISA bridge, which gets: 1180-11bf : :00:1f.0 1180-11bf : pnp 00:0b The K6-2 is similar; only 10-bit aliases of motherboard space except for: 0a79-0a79 : isapnp write Possibly a better solution (less likely to break things) would be to allow drivers to reserve the 10-bit aliases too. Something like this: static inline void request_isa_alias_regions(unsigned long start, unsigned long n, const char *name) { int base; for (base = 0x400; base < 0x1; base += 0x400) { request_region(base + start, n, name); } } and then call that in drivers/video/console/vgacon.c Russell, would that allay your issues with the kernel io resource database? -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 11:41:16AM -0800, Jesse Barnes wrote: > Yeah, I think I understand. We could probably do the same thing on sn2 > as you do on parisc--add a 'segment 0' offset to the port so that it's routed > correctly. I think that's a little less flexible than adding a new resource > though, since it makes it harder for drivers to support more than one device > or devices on non-segment 0 busses. To be clear, the parisc code defines this in include/asm-parisc/pci.h: #define HBA_PORT_SPACE_BITS 16 #define PCI_PORT_HBA(a)((a) >> HBA_PORT_SPACE_BITS) and PCI_PORT_HBA gets used in arch/parisc/kernel/pci.c. Offhand, I don't know if ia64 has the equivalent. But it sounds like it might need it. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 10:41:41AM -0800, Jesse Barnes wrote: > > Eh?! there can only be *one* legacy I/O space. > > We can support multipl IO port spaces, but only one can be the "legacy". > > What do you mean? If you define legacy I/O space to be > 0x-0x, then yes of course you're right. Yes - exactly. > But > if you mean being able to access legacy ports at all, then no. On SGI > machines, there's a per-bus base address that can be used as the base for > port I/O, which is what I was getting at. Ok - my point was "0x3fc" will get routed to exactly one of those IO port address spaces. > > If it is intended to work with multiple IO Port address spaces, > > then it needs to use the pci_dev->resource[] and mangle that appropriately. > > There is no resource for some of the I/O port space that cards respond to. Yes - I've heard several graphics cards are horrible broken WRT address decoding. Are PCI quirks supposed to handle that sort of thing? Another example was Xf86 was poking around in MMIO space to determine if such broken cards are installed. > I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to > accesses at 0x3bc for example. That's what I mean by legacy space--space > that cards respond to but don't report in their PCI resources. Can't PCI quirks fix up the resources to reflect this? I think one needs to fix up PCI IO Port resources to adjust for "The One" legacy IO port space getting routed to a different PCI segment - assuming no one submits a patch to change current behavior of using hard coded addresses. HP parisc and ia64 platforms implement seperate PCI segments under each PCI host bus controller. Linux PCI "BIOS" support provides the illusion it's all in one PCI segment on most (not all) platforms. Some HP chipsets also provide a "Legacy" IO Port space that gets routed to a chosen PCI Host bus controller. parisc PCI BIOS adds the controller instance number to the IO port space resource to help "inb()" generate the IO port cycle on the right PCI segment. This needs to be fixed up if we decide a different PCI segment should be segment 0 (and thus get references to 0x3fc). I expect other arches with multi-segment support to do similar fix ups. Am I making more sense now? thanks, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Friday, January 28, 2005 11:33 am, Grant Grundler wrote: > > But > > if you mean being able to access legacy ports at all, then no. On SGI > > machines, there's a per-bus base address that can be used as the base for > > port I/O, which is what I was getting at. > > Ok - my point was "0x3fc" will get routed to exactly one of those > IO port address spaces. Agreed, or it will cause a machine check if legacy I/O remapping isn't supported (like on SGI). > > There is no resource for some of the I/O port space that cards respond > > to. > > Yes - I've heard several graphics cards are horrible broken WRT address > decoding. Are PCI quirks supposed to handle that sort of thing? I'm not sure if broken is the right work. All this stuff predates PCI by quite a bit, so certain device classes claimed certain port ranges way before cards were required to have programmable address decoders. VGA cards are probably the most tenacious example of this, they respond to certain well known ports after reset, regardless of BAR values. > > I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to > > accesses at 0x3bc for example. That's what I mean by legacy space--space > > that cards respond to but don't report in their PCI resources. > > Can't PCI quirks fix up the resources to reflect this? Not sure, the I/O BAR may correspond to real registers too--and they may not overlap with the ones in the well known space. > I think one needs to fix up PCI IO Port resources to adjust > for "The One" legacy IO port space getting routed to a different > PCI segment - assuming no one submits a patch to change current > behavior of using hard coded addresses. I think we might just need a new resource for these well known ports, if my last statement is true. > Am I making more sense now? Yeah, I think I understand. We could probably do the same thing on sn2 as you do on parisc--add a 'segment 0' offset to the port so that it's routed correctly. I think that's a little less flexible than adding a new resource though, since it makes it harder for drivers to support more than one device or devices on non-segment 0 busses. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 02:26:40PM -0500, Jon Smirl wrote: > Next year we are going to see a lot of multiple VGAs. Depending on > configuration the Nvidia4 chipset can support from one up to eight PCI > Express video cards simultaneously. Oh geezsomeone is going to implement IO port space on PCI express device?! /me gets out the cluebat... grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, 28 Jan 2005 12:15:49 -0700, Grant Grundler <[EMAIL PROTECTED]> wrote: > I don't care if it gets fixed (or not) since I don't use > or need to support multiple VGA cards. If someone else (in Next year we are going to see a lot of multiple VGAs. Depending on configuration the Nvidia4 chipset can support from one up to eight PCI Express video cards simultaneously. I would like to get this fixed in the kernel so that apps like X won't do it from user space. Every time X does a read/alter/write to PCI config space from user space is a place where bad things can happen. The goal of this is to remove the PCI bus probing code from X. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 01:36:48PM -0500, Jon Smirl wrote: > > If it is intended to work with multiple IO Port address spaces, > > then it needs to use the pci_dev->resource[] and mangle that appropriately. > > Post a patch an I will incorporate it. Sorry - I only wanted to point out the short coming. I don't care if it gets fixed (or not) since I don't use or need to support multiple VGA cards. If someone else (in HP) does, it's just nice to warn them what's broken. thanks, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, 28 Jan 2005 10:32:22 -0700, Grant Grundler <[EMAIL PROTECTED]> wrote: > Moving the VGA device can only function within that legacy space > the way the code is written now (using hard coded addresses). > If it is intended to work with multiple IO Port address spaces, > then it needs to use the pci_dev->resource[] and mangle that appropriately. Post a patch an I will incorporate it. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Friday, January 28, 2005 9:32 am, Grant Grundler wrote: > On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote: > > But then again, > > I suppose if a platform supports more than one legacy I/O space, > > Eh?! there can only be *one* legacy I/O space. > We can support multipl IO port spaces, but only one can be the "legacy". What do you mean? If you define legacy I/O space to be 0x-0x, then yes of course you're right. But if you mean being able to access legacy ports at all, then no. On SGI machines, there's a per-bus base address that can be used as the base for port I/O, which is what I was getting at. > Moving the VGA device can only function within that legacy space > the way the code is written now (using hard coded addresses). > If it is intended to work with multiple IO Port address spaces, > then it needs to use the pci_dev->resource[] and mangle that appropriately. There is no resource for some of the I/O port space that cards respond to. I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to accesses at 0x3bc for example. That's what I mean by legacy space--space that cards respond to but don't report in their PCI resources. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote: > But then again, > I suppose if a platform supports more than one legacy I/O space, Eh?! there can only be *one* legacy I/O space. We can support multipl IO port spaces, but only one can be the "legacy". Moving the VGA device can only function within that legacy space the way the code is written now (using hard coded addresses). If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev->resource[] and mangle that appropriately. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote: But then again, I suppose if a platform supports more than one legacy I/O space, Eh?! there can only be *one* legacy I/O space. We can support multipl IO port spaces, but only one can be the legacy. Moving the VGA device can only function within that legacy space the way the code is written now (using hard coded addresses). If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev-resource[] and mangle that appropriately. grant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Friday, January 28, 2005 9:32 am, Grant Grundler wrote: On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote: But then again, I suppose if a platform supports more than one legacy I/O space, Eh?! there can only be *one* legacy I/O space. We can support multipl IO port spaces, but only one can be the legacy. What do you mean? If you define legacy I/O space to be 0x-0x, then yes of course you're right. But if you mean being able to access legacy ports at all, then no. On SGI machines, there's a per-bus base address that can be used as the base for port I/O, which is what I was getting at. Moving the VGA device can only function within that legacy space the way the code is written now (using hard coded addresses). If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev-resource[] and mangle that appropriately. There is no resource for some of the I/O port space that cards respond to. I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to accesses at 0x3bc for example. That's what I mean by legacy space--space that cards respond to but don't report in their PCI resources. Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, 28 Jan 2005 10:32:22 -0700, Grant Grundler [EMAIL PROTECTED] wrote: Moving the VGA device can only function within that legacy space the way the code is written now (using hard coded addresses). If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev-resource[] and mangle that appropriately. Post a patch an I will incorporate it. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 01:36:48PM -0500, Jon Smirl wrote: If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev-resource[] and mangle that appropriately. Post a patch an I will incorporate it. Sorry - I only wanted to point out the short coming. I don't care if it gets fixed (or not) since I don't use or need to support multiple VGA cards. If someone else (in HP) does, it's just nice to warn them what's broken. thanks, grant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, 28 Jan 2005 12:15:49 -0700, Grant Grundler [EMAIL PROTECTED] wrote: I don't care if it gets fixed (or not) since I don't use or need to support multiple VGA cards. If someone else (in Next year we are going to see a lot of multiple VGAs. Depending on configuration the Nvidia4 chipset can support from one up to eight PCI Express video cards simultaneously. I would like to get this fixed in the kernel so that apps like X won't do it from user space. Every time X does a read/alter/write to PCI config space from user space is a place where bad things can happen. The goal of this is to remove the PCI bus probing code from X. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 02:26:40PM -0500, Jon Smirl wrote: Next year we are going to see a lot of multiple VGAs. Depending on configuration the Nvidia4 chipset can support from one up to eight PCI Express video cards simultaneously. Oh geezsomeone is going to implement IO port space on PCI express device?! /me gets out the cluebat... grant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Friday, January 28, 2005 11:33 am, Grant Grundler wrote: But if you mean being able to access legacy ports at all, then no. On SGI machines, there's a per-bus base address that can be used as the base for port I/O, which is what I was getting at. Ok - my point was 0x3fc will get routed to exactly one of those IO port address spaces. Agreed, or it will cause a machine check if legacy I/O remapping isn't supported (like on SGI). There is no resource for some of the I/O port space that cards respond to. Yes - I've heard several graphics cards are horrible broken WRT address decoding. Are PCI quirks supposed to handle that sort of thing? I'm not sure if broken is the right work. All this stuff predates PCI by quite a bit, so certain device classes claimed certain port ranges way before cards were required to have programmable address decoders. VGA cards are probably the most tenacious example of this, they respond to certain well known ports after reset, regardless of BAR values. I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to accesses at 0x3bc for example. That's what I mean by legacy space--space that cards respond to but don't report in their PCI resources. Can't PCI quirks fix up the resources to reflect this? Not sure, the I/O BAR may correspond to real registers too--and they may not overlap with the ones in the well known space. I think one needs to fix up PCI IO Port resources to adjust for The One legacy IO port space getting routed to a different PCI segment - assuming no one submits a patch to change current behavior of using hard coded addresses. I think we might just need a new resource for these well known ports, if my last statement is true. Am I making more sense now? Yeah, I think I understand. We could probably do the same thing on sn2 as you do on parisc--add a 'segment 0' offset to the port so that it's routed correctly. I think that's a little less flexible than adding a new resource though, since it makes it harder for drivers to support more than one device or devices on non-segment 0 busses. Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 10:41:41AM -0800, Jesse Barnes wrote: Eh?! there can only be *one* legacy I/O space. We can support multipl IO port spaces, but only one can be the legacy. What do you mean? If you define legacy I/O space to be 0x-0x, then yes of course you're right. Yes - exactly. But if you mean being able to access legacy ports at all, then no. On SGI machines, there's a per-bus base address that can be used as the base for port I/O, which is what I was getting at. Ok - my point was 0x3fc will get routed to exactly one of those IO port address spaces. If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev-resource[] and mangle that appropriately. There is no resource for some of the I/O port space that cards respond to. Yes - I've heard several graphics cards are horrible broken WRT address decoding. Are PCI quirks supposed to handle that sort of thing? Another example was Xf86 was poking around in MMIO space to determine if such broken cards are installed. I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to accesses at 0x3bc for example. That's what I mean by legacy space--space that cards respond to but don't report in their PCI resources. Can't PCI quirks fix up the resources to reflect this? I think one needs to fix up PCI IO Port resources to adjust for The One legacy IO port space getting routed to a different PCI segment - assuming no one submits a patch to change current behavior of using hard coded addresses. HP parisc and ia64 platforms implement seperate PCI segments under each PCI host bus controller. Linux PCI BIOS support provides the illusion it's all in one PCI segment on most (not all) platforms. Some HP chipsets also provide a Legacy IO Port space that gets routed to a chosen PCI Host bus controller. parisc PCI BIOS adds the controller instance number to the IO port space resource to help inb() generate the IO port cycle on the right PCI segment. This needs to be fixed up if we decide a different PCI segment should be segment 0 (and thus get references to 0x3fc). I expect other arches with multi-segment support to do similar fix ups. Am I making more sense now? thanks, grant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 11:41:16AM -0800, Jesse Barnes wrote: Yeah, I think I understand. We could probably do the same thing on sn2 as you do on parisc--add a 'segment 0' offset to the port so that it's routed correctly. I think that's a little less flexible than adding a new resource though, since it makes it harder for drivers to support more than one device or devices on non-segment 0 busses. To be clear, the parisc code defines this in include/asm-parisc/pci.h: #define HBA_PORT_SPACE_BITS 16 #define PCI_PORT_HBA(a)((a) HBA_PORT_SPACE_BITS) and PCI_PORT_HBA gets used in arch/parisc/kernel/pci.c. Offhand, I don't know if ia64 has the equivalent. But it sounds like it might need it. grant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 12:33:20PM -0700, Grant Grundler wrote: If it is intended to work with multiple IO Port address spaces, then it needs to use the pci_dev-resource[] and mangle that appropriately. There is no resource for some of the I/O port space that cards respond to. Yes - I've heard several graphics cards are horrible broken WRT address decoding. Are PCI quirks supposed to handle that sort of thing? No, PCI quirks are for fixing broken things. VGA cards are entitled to 3c0-3df and all their 10-bit aliases. I've been thinking for a while that we should mark the 10-bit aliases of ISA devices as used ... ie: x100-x3ff x500-x7ff x900-xbff xd00-xfff Unfortunately, that may break some legitimate setups, but is hinted at being a good idea in the EISA docs I've read. My laptop uses only the 10-bit aliases of motherboard space (x000-x0ff, x400-x4ff, x800-x8ff, xc00-xcff) for devices, except for the ISA bridge, which gets: 1180-11bf : :00:1f.0 1180-11bf : pnp 00:0b The K6-2 is similar; only 10-bit aliases of motherboard space except for: 0a79-0a79 : isapnp write Possibly a better solution (less likely to break things) would be to allow drivers to reserve the 10-bit aliases too. Something like this: static inline void request_isa_alias_regions(unsigned long start, unsigned long n, const char *name) { int base; for (base = 0x400; base 0x1; base += 0x400) { request_region(base + start, n, name); } } and then call that in drivers/video/console/vgacon.c Russell, would that allay your issues with the kernel io resource database? -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Fri, Jan 28, 2005 at 08:00:10PM +, Matthew Wilcox wrote: I've been thinking for a while that we should mark the 10-bit aliases of ISA devices as used ISTR that windows does this. Russell, would that allay your issues with the kernel io resource database? It makes the situation a whole lot clearer from the point of working out what is free and what isn't, making it less likely that we'll trample over some magic port which your VGA card needs. This, along with throwing in the ports found via ACPI (which Dominik has hinted) should (maybe that's the wrong word) give us a complete picture and allow things like PCMCIA to do reliable resource allocation. The same goes for Cardbus/PCI as well of course. Maybe at this point the idea that you need to tell PCMCIA about which resources it can validly use can finally be eliminated, which is a big step towards eliminating it's dependence on userspace. (I hope this is what you were talking about and I haven't just produced a load of unrelated waffle!) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Thursday, January 27, 2005 1:59 am, Jon Smirl wrote: > Another item I need to add is generating an initial hotplug event for > each secondary card. This event has to happen even if there is a card > specific driver loaded. The event will be used to run the reset > program needed by secondary cards. Makes sense, having hotplug events would be nice. I've got a standalone bios emulator (based on the X int10 library) that I hope to open source soon, we could use that as a starting piont for the reset app. +static void vga_enable(struct pci_dev *pdev, unsigned int enable) ... + outb(~0x01 & inb(0x3C3), 0x3C3); + outb(~0x08 & inb(0x46e8), 0x46e8); + outb(~0x01 & inb(0x102), 0x102); + pdev->resource[PCI_ROM_RESOURCE].flags &= ~IORESOURCE_VGA_ACTIVE; + if (pdev == vga_active) + vga_active = NULL; + bridge_no(pdev); Those ins and outs won't work on all platforms unless they have a base address (assigned by arch code) associated with them. But then again, I suppose if a platform supports more than one legacy I/O space, it also supports multiple active VGAs, so maybe this enable/disable code isn't needed for them... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > This can be done today in the bus specific match functions. And because > of that, I would argue that this belongs in the bus specific code, and > not in the driver core, as it's up to the bus to know what the different > types of "matches" that can happen, and what the priority is. Here's a version of the VGA control code that actually works. It helps if I pci_enable() the device before using it. There was nothing wrong with the routing code. I can also control multiple cards on the same bus by turning on/off their response to IO space and then enabling VGA via the standard ports. I can use this to move my console from card to card. I have this code in drivers/pci because it needs to know add/remove from hotplug. Is there a better way to structure it? Note that this is not a VGA device, it is just a mechanism for controlling which VGA device is active. Another item I need to add is generating an initial hotplug event for each secondary card. This event has to happen even if there is a card specific driver loaded. The event will be used to run the reset program needed by secondary cards. -- Jon Smirl [EMAIL PROTECTED] patch Description: Binary data
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 20:24:59 -0800, Greg KH [EMAIL PROTECTED] wrote: This can be done today in the bus specific match functions. And because of that, I would argue that this belongs in the bus specific code, and not in the driver core, as it's up to the bus to know what the different types of matches that can happen, and what the priority is. Here's a version of the VGA control code that actually works. It helps if I pci_enable() the device before using it. There was nothing wrong with the routing code. I can also control multiple cards on the same bus by turning on/off their response to IO space and then enabling VGA via the standard ports. I can use this to move my console from card to card. I have this code in drivers/pci because it needs to know add/remove from hotplug. Is there a better way to structure it? Note that this is not a VGA device, it is just a mechanism for controlling which VGA device is active. Another item I need to add is generating an initial hotplug event for each secondary card. This event has to happen even if there is a card specific driver loaded. The event will be used to run the reset program needed by secondary cards. -- Jon Smirl [EMAIL PROTECTED] patch Description: Binary data
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Thursday, January 27, 2005 1:59 am, Jon Smirl wrote: Another item I need to add is generating an initial hotplug event for each secondary card. This event has to happen even if there is a card specific driver loaded. The event will be used to run the reset program needed by secondary cards. Makes sense, having hotplug events would be nice. I've got a standalone bios emulator (based on the X int10 library) that I hope to open source soon, we could use that as a starting piont for the reset app. +static void vga_enable(struct pci_dev *pdev, unsigned int enable) ... + outb(~0x01 inb(0x3C3), 0x3C3); + outb(~0x08 inb(0x46e8), 0x46e8); + outb(~0x01 inb(0x102), 0x102); + pdev-resource[PCI_ROM_RESOURCE].flags = ~IORESOURCE_VGA_ACTIVE; + if (pdev == vga_active) + vga_active = NULL; + bridge_no(pdev); Those ins and outs won't work on all platforms unless they have a base address (assigned by arch code) associated with them. But then again, I suppose if a platform supports more than one legacy I/O space, it also supports multiple active VGAs, so maybe this enable/disable code isn't needed for them... Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 07:55:23PM +, Russell King wrote: > On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote: > > Jon Smirl wrote: > > > Is this a justification for doing device drivers for bridge chips? It > > > has been mentioned before but no one has done it. > > > > > > Yeah, people are usually slack and work around the problem. > > > > A bridge driver is really wanted for several situations in today's > > hardware... > > There's a very good reason not to have a bridge driver at the moment - > some PCI to PCI bridges need special drivers. Currently, as the device > model stands today, we can only have ONE PCI to PCI bridge driver for > all P2P bridges, which is bad news if you need a specific driver for, > eg, a mobility docking station P2P bridge. > > As I said back in 2002, the device model needs a way to have driver > priories - how well a driver matches the hardware. > > My idea was for the bus match function to return the "goodness" > factor of the match. For PCI, matching on just the class IDs would > be low goodness, but an exact match with both the vendor and device > IDs would yeild a good match. This can be done today in the bus specific match functions. And because of that, I would argue that this belongs in the bus specific code, and not in the driver core, as it's up to the bus to know what the different types of "matches" that can happen, and what the priority is. And yes, I agree that this needs to be done, I've been talking with a few other people who are interested in it. I think the lock-rework code needs to be finished before it can happen properly, so that we can do the "unbind from one driver and give it to another one" type logic properly. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 19:55:23 +, Russell King <[EMAIL PROTECTED]> wrote: > There's a very good reason not to have a bridge driver at the moment - > some PCI to PCI bridges need special drivers. Currently, as the device > model stands today, we can only have ONE PCI to PCI bridge driver for > all P2P bridges, which is bad news if you need a specific driver for, > eg, a mobility docking station P2P bridge. There is no requirement that the bridge driver be generic code. I agree that it is simpler but there is nothing stopping a "generic" driver from just having PCI IDs for all of the existing bridges built into it and then load it like a normal driver. Loading all of the bridge PCI IDs into the "generic" driver gets rid of the need for driver priorities. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 02:17:15PM -0500, Jon Smirl wrote: > On Mon, 24 Jan 2005 17:51:31 +, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > Yes -- *very* platform specific. Some are even configurable as to how > > much they support. See http://ftp.parisc-linux.org/docs/chips/zx1-mio.pdf > > Is this a justification for doing device drivers for bridge chips? It > has been mentioned before but no one has done it. I don't think this is ... the bridges mentioned are host->pci bridges. > Any ideas why the code I sent won't work on the x86? I can shut > routing off but I can't get it back on again. > > The motivation behind the code is to get X to quit doing this from user space. I suppose we could log all access X does and compare to what your code ends up doing ... -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote: > Jon Smirl wrote: > >Is this a justification for doing device drivers for bridge chips? It > >has been mentioned before but no one has done it. > > Yeah, people are usually slack and work around the problem. > > A bridge driver is really wanted for several situations in today's > hardware... Annoyingly, we already have one, it's just special-cased for PCI Express. On my todo for this week is to take it out of the pcie directory and fix it. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote: > Jon Smirl wrote: > > Is this a justification for doing device drivers for bridge chips? It > > has been mentioned before but no one has done it. > > > Yeah, people are usually slack and work around the problem. > > A bridge driver is really wanted for several situations in today's > hardware... There's a very good reason not to have a bridge driver at the moment - some PCI to PCI bridges need special drivers. Currently, as the device model stands today, we can only have ONE PCI to PCI bridge driver for all P2P bridges, which is bad news if you need a specific driver for, eg, a mobility docking station P2P bridge. As I said back in 2002, the device model needs a way to have driver priories - how well a driver matches the hardware. My idea was for the bus match function to return the "goodness" factor of the match. For PCI, matching on just the class IDs would be low goodness, but an exact match with both the vendor and device IDs would yeild a good match. When the device model has a driver or device added, it scans all current devices or drivers (respectively) and chooses the best matched pair. If the device already has an existing driver, it calls the ->remove method to unbind the current device driver relationship before handing it over to the more specific driver. Unfortunately, I never got around to writing the mobility P2P bridge driver because I didn't see much chance of this idea being adopted. However, if we're going to start having generic drivers for such hardware, this kind of functionality needs to be thought about. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
Jon Smirl wrote: Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Yeah, people are usually slack and work around the problem. A bridge driver is really wanted for several situations in today's hardware... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 17:51:31 +, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > Yes -- *very* platform specific. Some are even configurable as to how > much they support. See http://ftp.parisc-linux.org/docs/chips/zx1-mio.pdf Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Any ideas why the code I sent won't work on the x86? I can shut routing off but I can't get it back on again. The motivation behind the code is to get X to quit doing this from user space. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 17:51:31 +, Matthew Wilcox [EMAIL PROTECTED] wrote: Yes -- *very* platform specific. Some are even configurable as to how much they support. See http://ftp.parisc-linux.org/docs/chips/zx1-mio.pdf Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Any ideas why the code I sent won't work on the x86? I can shut routing off but I can't get it back on again. The motivation behind the code is to get X to quit doing this from user space. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
Jon Smirl wrote: Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Yeah, people are usually slack and work around the problem. A bridge driver is really wanted for several situations in today's hardware... Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote: Jon Smirl wrote: Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Yeah, people are usually slack and work around the problem. A bridge driver is really wanted for several situations in today's hardware... There's a very good reason not to have a bridge driver at the moment - some PCI to PCI bridges need special drivers. Currently, as the device model stands today, we can only have ONE PCI to PCI bridge driver for all P2P bridges, which is bad news if you need a specific driver for, eg, a mobility docking station P2P bridge. As I said back in 2002, the device model needs a way to have driver priories - how well a driver matches the hardware. My idea was for the bus match function to return the goodness factor of the match. For PCI, matching on just the class IDs would be low goodness, but an exact match with both the vendor and device IDs would yeild a good match. When the device model has a driver or device added, it scans all current devices or drivers (respectively) and chooses the best matched pair. If the device already has an existing driver, it calls the -remove method to unbind the current device driver relationship before handing it over to the more specific driver. Unfortunately, I never got around to writing the mobility P2P bridge driver because I didn't see much chance of this idea being adopted. However, if we're going to start having generic drivers for such hardware, this kind of functionality needs to be thought about. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote: Jon Smirl wrote: Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Yeah, people are usually slack and work around the problem. A bridge driver is really wanted for several situations in today's hardware... Annoyingly, we already have one, it's just special-cased for PCI Express. On my todo for this week is to take it out of the pcie directory and fix it. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 02:17:15PM -0500, Jon Smirl wrote: On Mon, 24 Jan 2005 17:51:31 +, Matthew Wilcox [EMAIL PROTECTED] wrote: Yes -- *very* platform specific. Some are even configurable as to how much they support. See http://ftp.parisc-linux.org/docs/chips/zx1-mio.pdf Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. I don't think this is ... the bridges mentioned are host-pci bridges. Any ideas why the code I sent won't work on the x86? I can shut routing off but I can't get it back on again. The motivation behind the code is to get X to quit doing this from user space. I suppose we could log all access X does and compare to what your code ends up doing ... -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, 24 Jan 2005 19:55:23 +, Russell King [EMAIL PROTECTED] wrote: There's a very good reason not to have a bridge driver at the moment - some PCI to PCI bridges need special drivers. Currently, as the device model stands today, we can only have ONE PCI to PCI bridge driver for all P2P bridges, which is bad news if you need a specific driver for, eg, a mobility docking station P2P bridge. There is no requirement that the bridge driver be generic code. I agree that it is simpler but there is nothing stopping a generic driver from just having PCI IDs for all of the existing bridges built into it and then load it like a normal driver. Loading all of the bridge PCI IDs into the generic driver gets rid of the need for driver priorities. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Patch to control VGA bus routing and active VGA device.
On Mon, Jan 24, 2005 at 07:55:23PM +, Russell King wrote: On Mon, Jan 24, 2005 at 02:42:57PM -0500, Jeff Garzik wrote: Jon Smirl wrote: Is this a justification for doing device drivers for bridge chips? It has been mentioned before but no one has done it. Yeah, people are usually slack and work around the problem. A bridge driver is really wanted for several situations in today's hardware... There's a very good reason not to have a bridge driver at the moment - some PCI to PCI bridges need special drivers. Currently, as the device model stands today, we can only have ONE PCI to PCI bridge driver for all P2P bridges, which is bad news if you need a specific driver for, eg, a mobility docking station P2P bridge. As I said back in 2002, the device model needs a way to have driver priories - how well a driver matches the hardware. My idea was for the bus match function to return the goodness factor of the match. For PCI, matching on just the class IDs would be low goodness, but an exact match with both the vendor and device IDs would yeild a good match. This can be done today in the bus specific match functions. And because of that, I would argue that this belongs in the bus specific code, and not in the driver core, as it's up to the bus to know what the different types of matches that can happen, and what the priority is. And yes, I agree that this needs to be done, I've been talking with a few other people who are interested in it. I think the lock-rework code needs to be finished before it can happen properly, so that we can do the unbind from one driver and give it to another one type logic properly. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/