-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
On Sep 23, 2010, at 10:46 AM, Adam Jackson wrote:
On Wed, 2010-09-22 at 18:29 -0400, Michael wrote:
On Sep 22, 2010, at 4:10 PM, Adam Jackson wrote:
Not even compile-tested, but probably pretty close. OS maintainers
please to be building.
The FreeBSD backend is the only one that stands a chance of
working on
non-x86, the rest appear to not have _any_ facility for I/O port
access on other arches.
We (NetBSD) actually do have this facility since ~forever, it's in
use
on most powerpc ports, shark and so on. Otherwise we couldn't use
things like Voodoo3, ct65550 on macppc or any shark onboard graphics
chips in X.
Doesn't appear to be used in the X server, at least from my quick
read.
You do have /dev/io but the man page says it's deprecated and that
closing it doesn't drop iopl, which is a bit bizarre.
IIRC /dev/io is entirely x86 specific ( on NetBSD at least )
If there's a better way to be doing it on netbsd, I'm all ears.
There are two ways - one via /dev/pci* and one via wsdisplay ( as in /
dev/ttyE0 ) - ports that support it will define a constant named
PCI_MAGIC_IO_RANGE which usually ( but not necessarily ) corresponds
to the bus address where the host bridge(s) put their IO ranges. It
doesn't have to be within 4GB either.
The same works through /dev/ttyE0, the difference is that through /dev/
pci* you can see all devices on the given bus and map the IO range
belonging to the bus, via ttyE0 you see only the device that acts as
console ( if it is a PCI device in the first place ) and map the IO
range it's in without having to know anything about bus topology.
We used the ttyE0 method in non-x86 until a few years ago, then I
adapted libpciaccess to walk /dev/pci* in order to find buses and
devices. Shark uses /dev/ttyE0 since the graphics chips are VLB
devices but the principle is the same ( that reminds me - why are
there gratuitous differences between IO macros for ARM and those for
other architectures? Like ioBase vs. IOPortBase? )
That way the Xserver doesn't need any knowledge about bridges, PCI
chipsets and how to find their IO ranges etc., all it needs to know is
wether x86-like IO instructions are available.
We use this mostly on macppc since more recent PowerMacs tend to have
several host bridges which all may or may not have their own IO
ranges. On sparc64 I didn't bother with IO since all the graphics
chips Sun ever used are perfectly usable using memory-mapped IO only
and most of the time the firmware doesn't even initialize IO BARs.
Support for multiple host bridges works the same - mmap() via /dev/
pci* so it doesn't matter on what bridge any given chip lives.
The code inherited from xfree86 is stupid - it scans only /dev/pci0
and tries to mmap devices through /dev/mem or /dev/ttyE0 - the former
is more or less x86-specific and the latter only allows the Xserver to
access the console. On non-x86 this led to only one PCI instance being
visible to the Xserver ( usually the AGP slot on PowerMacs but not
necessarily ).
So, we got rid of most of the architecture specific bits in the PCI
handling code except the distinction of x86 vs. (almost) everything
else regarding IO.
What a pity. Also, none of these have appear to have any facility
for domainful I/O, so, that won't work either. Meh.
Whatever you mean by that. If you mean support for more than one PCI
host bridge with associated goo we have that as well.
From userspace?
Yes. There is one /dev/pci* instance for each PCI bus and you can
mmap() devices and IO ranges through them.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBTJutacpnzkX8Yg2nAQIjUQf+JV4bpsCyH1SaqsQoQ6SLaPGrBiCAXCdS
rm1q59OqCYUhwLR6JfBDNIGB54qYIpJU//TKbLBcbA66+f0G7NQ3UWq9uRajkuC9
AfFKfHtVkn247W/Xi8woGBDCYBIZhmWSUBwxE6XYjf6PvaPFAlGFFokVJ+8zzxXc
1ObL3b7YQw060g66K/9LDnBCxGSScTqbGise72BLW46Dh/j89zhvI0ncYY2gChl0
8oeiW61NuG4QR4BcFKcEkoNuo5OJDgiEbXZmMRzxIWt6mCEfq2H6JLGKvkxlCCSy
a64l26V6w1qs4Vnlgz9m0kXrCckZJlrdKysy6wrcHBtxPFdA+6zw1w==
=FblQ
-----END PGP SIGNATURE-----
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
