Initial version of PCI access library
jbarnes at virtuousgeek.org
Mon Feb 20 10:03:44 PST 2006
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:
> 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.
More information about the xorg