Initial version of PCI access library
idr at us.ibm.com
Mon Feb 20 10:53:49 PST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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:
>>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)
-----END PGP SIGNATURE-----
More information about the xorg