-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>> I agree, the Xserver shouldn't have to meddle with PCI BARs, at least
>> not to access the framebuffer. On the other hand the drivers I've seen
>> so far map the framebuffer when you mmap() offsets between 0 and
>> aperture_size.
>> As far as I can tell XFree's SBus code uses /dev/fb to talk to the
>> hardware.
>
> I think current our cgsix.c provides mmap() function via /dev/fb.
That's exactly what XFree uses, at least to find framebuffers and 
almost certainly also to access the hardware.

> (which is SunOS compatible?)
I think so, the Xsun source seems to indicate this.

> It's also provide to mmap register spaces, and an offset
> for fb memory is not zero. I guess that was the reason why
> OpenBSD guys introduced WSDISPLAYIO_MODE_DUMBFB for mmap op.
Probably. On the other hand I've yet to see a program that uses offset 
0 to mmap() the framebuffer - XFree seems to expect BAR contents to 
correspond to mmap() offsets though - not such a bad idea in my 
opinion, especially on platforms where the BARs don't contain actual 
physical addresses, like sparc64, because this way the Xserver doesn't 
have to deal with this kind of remapping.
So maybe we should just provide a list of mmap()able address ranges, 
probably with some additional flags which would sort of correspond to 
PCI BARs but also work on - say - SBus?
(hmm, this would partially allow bus-agnostic userspace drivers... )

>> Agreed again, but it would be a bit more complicated - some PCI
>> framebuffers use more than one BAR for registers, then there's this
>> nonsense with hard-wired VGA registers and so on, some need access to
>> PCI IO space which is different on x86 and almost everything else - 
>> for
>> kernel code that's not a problem thanks to bus_space_* but userland
>> code can't use it.
>
> Maybe we should have some generic APIs to access PCI space,
> but it may be another future project :-)
We have libpci, but it doesn't deal with IO abstraction at all. The 
main difference is that on most non-x86 architectures you have to 
figure out where the IO space of a particular PCI bus is mapped into 
memory, mmap() it and then use the same macros as x86 ( like in8(), 
out32() and so on ) - there should be some kind of abstraction which 
covers this and x86's i386_iopl().
Shouldn't really be complicated.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQfe/rcpnzkX8Yg2nAQIhOgf/U6osaUM1XL3GH75Pfo9XxcAeVYV87Sx2
hI3VqDjh3rTtAEgmgpAimjuXasu74Q4wQza6Uxcrc4kJN6fQAmQOCmCxfKV7jyFc
P7tiSsUYuokXKhkN0QEt1/V0OmJqMtIhBk9SyE2qTFFojV1EoYMTw9jooTDDL2J4
iAoA4KLcd4QEXPKu2Of1XgPttKq+7QRFlYqGIqq0xgkYWELd2pwMsQkM5nzSR6Ey
bbsxgmPemaSJ2DsG8rsndcJORfVoe1zUN0JnWuEbhyUgA2R6SAFBG3tHb7v0JDUB
ao6iTDwqHO+p1C99axqJKvEogr+9Kg/rz+oPe0Cos/jZxTYc0fA1XA==
=7Dxp
-----END PGP SIGNATURE-----