The code in hw/xfree86/os-support/bus/sparcPci.c:simbaCheckBus()
is trying to mimmick VGA routing by disabling I/O space responses
behind the Simba PCI-PCI controller.
Unfortunately, doing this also happens to disable access to the
IDE controller I/O space registers, thus crashing the system. The
granularity of the I/O disabling in the Simba controller is not
fine enough to disable VGA without also disabling the IDE controller
registers.
Formerly we sized an array with a compile time constant, then initialized
its size to the same constant, but the Linux PCI init code would increase
that "constant". So if you happened to have more than 128 PCI devices,
you'd happily scribble into whatever variables happened to be in .bss
after that array.
Only really fixed for Linux atm. Other OSes will simply (still) fail to
work on video devices above the 128th PCI device.
/sys/devices reflects the bus topology, and we don't care that much.
Easier (and more reliable) to just look in /sys/bus/pci/devices, which
is a flat view.
Currently, the call to linuxPciOpenFile() is always made for read
only access which causes the subsequent mmap call to fail when the
memory is mapped read/write.
Xorg #9692
xf86ReadLegacyBIOS is only used by one function in int10/generic.c.
Move a generic implementation of that function there, rename it to
read_legcay_BIOS, and delete all remnants of it from all other places.
Convert xf86GetPciHostConfigFromTag to a new function called
get_parent_bridge. This name better represents what
xf86GetPciHostConfigFromTag is used for: walking up the lists of PCI
bridges from a device.
Eliminate xf86GetPciDomain. The domain from libpciaccess is the
domain. Period. This means that 0 is a valid domain. Make sure that
INCLUDE_XF86_NO_DOMAIN is *not* set. Always run in "domain mode,"
even if the only domain possible is 0.
Convert all uses of PCITAG in int10 and vgaHW to 'struct pci_device'.
This allows the conversion of xf86ReadLegacyVideoBIOS and
xf86MapDomainMemory to 'struct pci_device' from PCITAG.
If we're mapping something in the "legacy range" (0-1Mb), we shouldn't
expand the requested range to the entire 0-1Mb range. Typically this
is for mapping the VGA frame buffer, and some platforms support mmap of
the frame buffer but not the entire 0-1Mb range.
For example, HP sx1000 and sx2000 ia64 platforms can have memory from
0-0x9ffff, VGA frame buffer from 0xa0000-0xbffff, and memory from
0xc0000-0xfffff. On these platforms, we can't map the entire 0-1Mb
range with the same attribute because the memory only supports WB,
while the frame buffer supports only UC. But an mmap of just the
frame buffer should work fine.
Mach64 driver bails out on ia64 because it cannot map device
memory. It turns out that some bogus and unneeded code attempts
to find the root bridge of the device and fails to do so proberly
as there this host-to-pci bridge is not existant. This code has
been around for years although it completely unclear what it had
been intended for. Fixing this by eliminating the bogus code.
broken for any 32 bit X server running on a 64 bit kernel) so #ifdef
them out for now. the PCI rework tree will make all this crap go away,
so I think we can tolerate the extra #ifdef for the next release.
Conflicts:
hw/xfree86/common/xf86Init.c
hw/xfree86/int10/pci.c
hw/xfree86/scanpci/xf86PciData.h
hw/xfree86/scanpci/xf86PciStdIds.h
hw/xfree86/scanpci/xf86PciStr.h
hw/xfree86/scanpci/xf86ScanPci.h
hw/xfree86/utils/pcitweak/pcitweak.c
hw/xfree86/utils/scanpci/scanpci.c
Re-removed most of the conflicting files.
okay? Since xf86MapLegacyIO is called from only one place, cut the
parameter list down to the one parameter that actually conveys some
information: the one that gives a PCI device. Change from using a
PCITAG to a pci_device.
