Initial version of PCI access library

[Ian Romanick]

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

Jesse Barnes wrote:
> 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 

Yes.  I started it as common_agp.c, but I realized that support for
querying other PCI capabilities could / should be put into the same
source file.  I changed the name but left the old file (which is
somewhat similar to moving the head stones but leaving the... nevermind.).

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

Hmm...the legacy I/O & memory access support currently in X is outside
the PCI support, so I left it out.  I'd like to keep this as a generic
PCI access library, so I'm inclined to keep it out.  I don't see any
reason why it couldn't be put in a different layer.  Do many drivers
still rely on legacy access?

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

Yeah.  I had some trouble figuring out how to read the ROMs at first,
but a little googling turned up a discussion on lkml.

>>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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD+hA8X1gOwKyEAw8RArZdAJ0cRXtBpFlUuTooH/+VJgHfKmPMggCeLY3d
pyxyqhVSthhdiCyRMWYFGSA=
=AT6i
-----END PGP SIGNATURE-----