Ian Campbell wrote:
]It's not obvious whether the I/O space enable bit in the PCI cfg command ]register is supposed to control the availability of non-PCI registers or ]not. Neither the PCI spec nor the GD-5446 datasheet are particularly ]clear on the matter.
The VGA class code indicates that the legacy I/O ranges are decoded, when enabled in the command register. True the PCI spec does not spell this out. But there is really no other way it could work. The BAR mechanism does not provide a way to either report or accept programming for a range such as 3b0-3bb.
]I've just discovered that the ancient pentium box I use as a home ]firewall has a GD 5446 in it (useful to know!), it doesn't have any I/O ]BARS but it does have the I/O bit set in the PCI command register. ] ]It's not clear who was responsible for setting that bit, in general in ]the absence of an I/O BAR the BIOS wouldn't know to do so. I expect that ]either the VGA BIOS is expected to enable it if the hardware it drives ]requires it or that BIOSen special case class=VGA devices and always ]enable I/O for one of them.
BIOS or some other firmware (coreboot) must enable I/O decode in the command register for VGA class devices. Option ROMs in general do not enable it.
]It looks like coreboot always forces this bit on for the VGA device ]which it determines to be the primary, which is good enough for me -- ]I'll make a patch to the Xen pci setup code to implement that instead of ]this change to SeaBIOS.
Yes, right here: http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/devices/pci_devi ce.c#L619
Thanks, Scott