Initial version of PCI access library

[Jesse Barnes]

On Friday, February 17, 2006 5:37 pm, Ian Romanick wrote:
> I have just made available the source to my first pass at a PCI
> access library.  The source can be found at:
>
> 	http://people.freedesktop.org/~idr/pci/
>
> This is an early version for review.  It implements pretty much
> everything described in the wiki.  This includes the "regex" based
> device iterator (more on that below).  A sample program, pcils, is
> included.  It operates somewhat like a stripped down lspci clone.

The library looks nice, seems to cover most of the stuff we care about.  
It looked like common_capability.c and common_agp.c had a lot of 
duplicated code though (maybe one of them is just a leftover)?  The 
sysfs access stuff looks nice, glad to see someone using it.  I think 
I/O port access will have to be done specially (didn't really see code 
in there to support it yet?), since not all platforms 
support /sys/class/pci_bus/<busno>/legacy_io files (which can be read 
and written but not mmapped); in fact I think only ia64 supports this 
type of access, though benh has expressed interest in making it work on 
some ppc machines as well iirc.  For platforms that don't support it, 
the glibc in/out routines will probably have to be used.

Some platforms (again only ia64 at this point I think) will also support 
a legacy_mem file in that same directory, corresponding to ISA memory 
that PCI devices may or may not describe in their config space, even 
though they still respond to bus cycles there.  On platforms without 
this file, /dev/mem will have to be used I guess, though I suppose in 
that case multiple legacy memory spaces wouldn't be supported without 
some sort of additional bridge/platform driver poking in between.

And in case you're curious, the reason why the rom file has those weird 
access semantics (write 1 to enable first then write 0 when you're 
done) is because shortly after the patch to support it went in, Linus' 
machine started wedging at boot.  It turned out that hal (iirc) was 
opening and reading every sysfs file at boot time, and reading the ROM 
while VGA memory is accessed is a no-no on some devices, since they 
share the same address decoder, causing master aborts.  So now, open 
doesn't imply enable, which protects the user from badly behaved 
programs with high privilege levels to some extent.

> The device iteration interface also needs to be reworked.  However, I
> want a better understanding of the server actually probes / iterates
> devices first.  Can anyone explain to me how this works?  Is that
> different from how we would /want/ it to work?  I like the Linux
> kernel model, but I don't think that would work with non-PCI devices.

Internally, the server does an iteration scheme similar to what your 
library provides (or at least some part of it did last time I looked, 
Egbert can provide more details).  But I think the important thing is 
the interface exposed to the drivers, and they typically just want to 
bind to a device based on vendor and device ID (though maybe a small 
survey of drivers is in order to make sure we provide the right 
interfaces).  That's why in the initial thread about PCI access I 
argued for a simpler device matching scheme, similar to the one Linux 
provides to its drivers.

Thanks,
Jesse