Re: Fwd: Patch to control VGA bus routing and active VGA device.

2005-02-01 Thread Jon Smirl
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.

2005-02-01 Thread Jon Smirl
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.

2005-01-31 Thread Greg KH
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.

2005-01-31 Thread Alan Cox
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.

2005-01-31 Thread Greg KH
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.

2005-01-29 Thread Jon Smirl
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.

2005-01-29 Thread Jon Smirl
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.

2005-01-28 Thread Russell King
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.

2005-01-28 Thread Matthew Wilcox
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Jesse Barnes
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Jon Smirl
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Jon Smirl
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.

2005-01-28 Thread Jesse Barnes
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Jesse Barnes
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.

2005-01-28 Thread Jon Smirl
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Jon Smirl
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Jesse Barnes
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Grant Grundler
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.

2005-01-28 Thread Matthew Wilcox
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.

2005-01-28 Thread Russell King
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.

2005-01-27 Thread Jesse Barnes
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.

2005-01-27 Thread Jon Smirl
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.

2005-01-27 Thread Jon Smirl
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.

2005-01-27 Thread Jesse Barnes
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.

2005-01-24 Thread Greg KH
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.

2005-01-24 Thread Jon Smirl
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.

2005-01-24 Thread Matthew Wilcox
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.

2005-01-24 Thread Matthew Wilcox
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.

2005-01-24 Thread Russell King
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.

2005-01-24 Thread Jeff Garzik
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.

2005-01-24 Thread Jon Smirl
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.

2005-01-24 Thread Jon Smirl
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.

2005-01-24 Thread Jeff Garzik
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.

2005-01-24 Thread Russell King
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.

2005-01-24 Thread Matthew Wilcox
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.

2005-01-24 Thread Matthew Wilcox
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.

2005-01-24 Thread Jon Smirl
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.

2005-01-24 Thread Greg KH
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/