Attached is a patch to control VGA bus routing and the active VGA
device. It works by adding sysfs attributes to bridge and VGA devices.
The bridge attribute is read only and indicates if the bridge is
routing VGA. The attribute on the device has four values:
/* echo these values to the sysfs vga attribute on a VGA device */
enum eEnable {
VGA_DISABLE_THIS = 0, /* If this VGA is enabled, disable it. */
VGA_ENABLE_THIS = 1, /* Disable all VGAs then enable this VGA, mark
as active VGA */
/* Used while resetting a board, board being reset may not be the active VGA */
VGA_DISABLE_ALL = 2, /* Remember active VGA then disable all VGAa and
devices */
VGA_ENABLE_ACTIVE = 3, /* Make sure all VGAs are disabled, then
reenable active VGA */
};
States 2 and 3 are using during a reset cycle. You need to disable the
active VGA, run the reset on the new card, turn it off and then
restore the active one.
I cannot get this code to work. I have a machine with three buses, the
main one, a PCI one and an AGP one. If I turn off routing from one
bridge and turn it on on the other, I cannot get the VGA card to
respond to the IO requests. There must be something more to routing
VGA than what is in this code. The patch is pretty simple so it
shouldn't be too hard to find the problem. I know my machine can route
VGA since vbios.vm86 does it when reseting my secondary cards.
Can any of you PCI/VGA experts tell me what is wrong? Patch is against
current Linus BK.
This code, plus the ROM code already in the kernel, plus a tiny piece
to generate a hotplug event, is enough to let me write a user space
app for secondary card reset.
--
Jon Smirl
[email protected]
On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> Attached is a patch to control VGA bus routing and the active VGA
> device. It works by adding sysfs attributes to bridge and VGA devices.
> The bridge attribute is read only and indicates if the bridge is
> routing VGA. The attribute on the device has four values:
How is it supposed to work? Is VGA routing determined by the chipset? Is it
separate from other legacy I/O and memory addresses?
Thanks,
Jesse
P.S. Can you fix your mailer to set a mimetype other than "unspecified binary
data" for patches to make them easier to read?
Followup to: <[email protected]>
By author: Jesse Barnes <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> > Attached is a patch to control VGA bus routing and the active VGA
> > device. It works by adding sysfs attributes to bridge and VGA devices.
> > The bridge attribute is read only and indicates if the bridge is
> > routing VGA. The attribute on the device has four values:
>
> How is it supposed to work? Is VGA routing determined by the chipset? Is it
> separate from other legacy I/O and memory addresses?
>
Yes, there are special control bits in any PCI bridge header for the
VGA ports.
-hpa
On Tuesday, January 18, 2005 11:38 am, H. Peter Anvin wrote:
> > On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> > > Attached is a patch to control VGA bus routing and the active VGA
> > > device. It works by adding sysfs attributes to bridge and VGA devices.
> > > The bridge attribute is read only and indicates if the bridge is
> > > routing VGA. The attribute on the device has four values:
> >
> > How is it supposed to work? Is VGA routing determined by the chipset?
> > Is it separate from other legacy I/O and memory addresses?
>
> Yes, there are special control bits in any PCI bridge header for the
> VGA ports.
Well, not all of them, which is why I asked. Though obviously this patch will
need some very platform specific bits at any rate.
Jesse
On Tue, 18 Jan 2005 13:06:03 -0800, Jesse Barnes <[email protected]> wrote:
> On Tuesday, January 18, 2005 11:38 am, H. Peter Anvin wrote:
> > > On Monday, January 17, 2005 7:43 pm, Jon Smirl wrote:
> > > > Attached is a patch to control VGA bus routing and the active VGA
> > > > device. It works by adding sysfs attributes to bridge and VGA devices.
> > > > The bridge attribute is read only and indicates if the bridge is
> > > > routing VGA. The attribute on the device has four values:
> > >
> > > How is it supposed to work? Is VGA routing determined by the chipset?
> > > Is it separate from other legacy I/O and memory addresses?
> >
> > Yes, there are special control bits in any PCI bridge header for the
> > VGA ports.
>
> Well, not all of them, which is why I asked. Though obviously this patch will
> need some very platform specific bits at any rate.
What is a case of where the VGA forwarding bit isn't in the bridge
control? It's part of the PCI spec to have it.
There are two components to this, bus routing and card control. When
each VGA device is on it's own bus the card specific control code
isn't required. Instead you can control the active VGA by shutting
down the bus routing. It's only when you have multiple cards on the
same bus that you need the card specific control.
But the point of this code is to allow reset of secondary cards. After
resetting a secondary card it will be left as the active VGA device
instead of the boot one. This moves your console from screen to
screen. Instead I want to remember the active device, run reset, and
then restore the original console.
In my machine I have one PCI and one AGP card. Bus routing is
sufficient to choose between the two. Opteron systems with AGP cards
on local buses can also use this code. Another example is where the
primary VGA device is on AGP and there are multiple PCI cards. You
just want all of the PCI VGA devices turned off.
We ultimately need both pieces of code, VGA bus routing, and card
specific VGA enabling code. Even without the card specific code the
routing code is still useful.
--
Jon Smirl
[email protected]
On Saturday, January 22, 2005 11:04 am, Jon Smirl wrote:
> > Well, not all of them, which is why I asked. Though obviously this patch
> > will need some very platform specific bits at any rate.
>
> What is a case of where the VGA forwarding bit isn't in the bridge
> control? It's part of the PCI spec to have it.
Hmm... lemme check my specs. It doesn't look like we support that aspect of
the PCI spec in our bridges.
> We ultimately need both pieces of code, VGA bus routing, and card
> specific VGA enabling code. Even without the card specific code the
> routing code is still useful.
Oh right, doing card specific up/down will allow multiple cards to share the
same bus, which would be nice.
Jesse
On Monday, January 24, 2005 9:25 am, Jesse Barnes wrote:
> On Saturday, January 22, 2005 11:04 am, Jon Smirl wrote:
> > > Well, not all of them, which is why I asked. Though obviously this
> > > patch will need some very platform specific bits at any rate.
> >
> > What is a case of where the VGA forwarding bit isn't in the bridge
> > control? It's part of the PCI spec to have it.
>
> Hmm... lemme check my specs. It doesn't look like we support that aspect
> of the PCI spec in our bridges.
Btw, I don't think this is the only chipset that doesn't support the VGA
routing bit, so new code shouldn't assume that it's ok to access VGA ports
w/o an offset based on the PCI bus the device is on.
Jesse