[PATCH 0/4] pciaccess: I/O port API for non-Linux

[Michael]

-----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-----