With the shift of PCI code to libpciaccess and the removal of Jensen support and other Alpha cruft from the Xserver the code to support Sparse I/O mapping on non-BWX capable Alphas is broken. It appears there is some interest in getting the sparse I/O mapping working again, see: http://bugs.freedesktop.org/show_bug.cgi?id=25678
What I am wondering about is the best way to implement this as it requires some interaction between libpciaccess and the Xserver's compiler.h MMIO_INx and MMIO_OUTx routines. Drivers call pci_device_map_range() to memory map the PCI resource file. If we wish to keep that interface for the drivers then on a non-BWX Alpha this routine should map the resourceX_dense resource file, and if it is an I/O bar also map the resourceX_sparse resource file. It is safe to return the address of the dense mapping only as the sparse mapping address is easily calculated from the dense mapping address. But the problem is then communicating to the MMIO_INx/MMIO_OUTx routines that they should use the sparse memory map for byte and word accesses. In the old Xserver all this was setup in the PCI initialisation code but now the PCI setup is shifted to libpciaccess and the Alpha specific code was left hanging and uncalled. I think Matt removed much of it when I pointed out to him that it was no longer being called from anywhere. My thought at the moment is to modify libpciaccess's pci_device_linux_sysfs_map_range() (and unmap routine) on the failure to map resourceX to try to map resourceX_dense and if it is an I/O bar to map resourceX_sparse as well. This could be enclosed with #ifdef ALPHA type conditionals if desired. I suspect this might require a change (an addition of a field) to the private part of struct pci_device but involves no change to the API. On the Xserver side, in some initialisation routine, when detecting the system type, if it is an non-BWX alpha then overtake the MMIO_INx/MMIO_OUTx routines in compiler.h with ones that use the sparse mapping. There is a disconnect here -- libpciaccess is detecting an Alpha system by the presence of resourceX_sparse/dense files in sysfs. The Xserver is doing it by more fundamental means (it will have to talk to the kernel and/or procfs to determine the Alpha system type, etc.). Maybe an opportunity for one to be out of sync with the other. Also this implementation will only work with Linux sysfs. Any thoughts or suggestions as to whether this is on the right track? Cheers Michael. _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel