On Sat, 2009-10-31 at 16:17 +0100, Mark Kettenis wrote: > > It might. BAR 5 is the I/O map, and it's 256 bytes. They're all > > defined right up to 0xBC, which smells a little suspicious since the VGA > > ports it claims to decode are 3C[0-5ACEF] and 3[BD][45A]. So while it > > doesn't _say_ the VGA ports are aliased there starting at 0xC0, I'd be > > utterly unsurprised. > > > > I guess I don't see how it matters though, you can already get to the > > colormap and mode, and you won't be using VGA fonts. (Unless you do VGA > > console even on non-x86 machines? That would be vile.) > > You're right of course. I already disabled the VGA font save/restore > because that required mapping the legacy VGA memory area and on the > Sun Blade 1000 that I stuck this card in, that area is in use by other > devices. > > Still struggling a bit with how to map BAR 5 though. I have a hack to > make things work, but I'll need to discuss the implications for the > OpenBSD kernel and libpciaccess.
Most non-x86 arches have a way to mmap the I/O space, but x86 (and amd64) almost never does. The portable way to do this would be like: void *pci_device_open_io(struct pci_device *dev, int bar); void pci_device_close_io(struct pci_device *dev, void *handle); uint32_t pci_io_inl(void *handle, uint16_t reg); uint16_t pci_io_inw(void *handle, uint16_t reg); uint8_t pci_io_inb(void *handle, uint16_t reg); void pci_io_outl(void *handle, uint16_t reg, uint32_t data); void pci_io_outw(void *handle, uint16_t reg, uint16_t data); void pci_io_outb(void *handle, uint16_t reg, uint8_t data); On mappable arches the handle can be the mmap itself and the accessors can be trivial, but on x86 it'd probably be the file handle for /dev/port or the sysfs resource file and the accessors would be pread/pwrite. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel