PCI Subsystem Rework for X.org 7.1 Proposal

[Adam Jackson]

On Thursday 02 February 2006 19:31, Jesse Barnes wrote:

> That's a good question.  Are there any OSes with active X maintainers
> that *don't* have a good PCI API?  And if so, this theoretical PCI
> interface you're implementing could be ported with an appropriate back
> end.

Even if there are, said backend could be implemented once by extracting the 
mmap-based code we already have.

I'm fairly sure *bsd and Solaris have a reasonably sane userspace API to the 
PCI bus.  I don't know of any other OSes shipping X servers based on the 
xfree86 DDX.  I suspect the only ones that would even be likely at this point 
are the X servers for AIX and HP/UX, everything else having shuffled off to 
end-of-life mode.

> The big missing pieces seem to be:
>   o VGA arbitration - we (the kernel folks) really need to tackle this
>     properly
>   o mapping memory with different attributes - benh and I discussed some
>     ideas awhile back, but no code ever came of it (did we settle on
>     thinking that an madvise(2) addition was best?)

madvise(2) currently seems to describe usage patterns rather than hardware 
attributes, so I'm mildly wary of that idea.  The flags argument to mmap(2), 
however, is already a grab-bag of attributes.

> Random naming thoughts: pci_system_init instead?  Or just pci_init,
> though that assumes that the 'pci' namespace is where we want these
> calls; anyway somehow pci_system seems redundant...

Are we really to the point where PCI is like Ethernet (ie, its replacement 
will also be called PCI)?  If not, or if we care about proprietary 
workstation busses like on older Sun or SGI kit, then we should possibly 
think about bus_* instead of pci_*.

> For some reason, using a regex here scares me a little, but maybe that's
> just because I'm not used to it.  Anyway, check out the Linux docs and
> see if you prefer that interface, I personally find it easier to read
> (things like PCI_ANY_ID for various subfields when doing matching seems
> a little more straightforward than a regex).

PCI even gives you field values that are specified as "never used in hardware" 
for exactly this reason.

> > ISSUE: The only thing not included
> > in the magic extended bus ID string is the device's interrupt. Should
> > it be possible to match based on that? X doesn't currently require
> > that.
>
> Doesn't seem like that would be necessary, generally you just want to
> match on vendor and device IDs, don't you?  The other information is
> needed later and can be had from the pci_device structure returned to
> you.

Well, and occasionally subsystem IDs.  Match on IRQ is probably not a useful 
feature.

> > The pci_device structure contains all of the expected fields and is
> > very similar to libpci.a's pci_dev structure. Some fields that are
> > important to X (e.g., subvendor_id) have been added, and some fields
> > that are unnecessary (e.g., rom_base_addr) have been removed.
> >
> > struct pci_mem_region {
> >     void * memory;
> >     pciaddr_t bus_addr;
> >     pciaddr_t base_addr;
> >     pciaddr_t size;
> > };
>
> Hm, I think the bus_addr and base_addr should be hidden from the
> interface, maybe in a void *platform_data structure or something, since
> they're generally only used by low level platform code (or am I wrong
> here, are there cases where the driver needs this info?).  I've seen way
> too many people mistake the bus address for something else.  Which
> reminds me, sparse annotation of the various address space pointers in X
> might be a good idea at some point (ala the Linux kernel's __user
> attributes)...

If addresses written to the card need to be proper bus addresses (instead of 
merely relative to some BAR) then the server needs to know that.

> It seems like the kernel may be doing power management of various devices
> as well, so should there be some sort of callback mechanism?  This could
> get tricky if the kernel suspends a device without telling X about it...

This sounds plausible.  I think in general we can say that devices that are in 
some sense managed by userspace should be shut down by userspace (if the 
managing process asks for it), and that userspace shutdown has to precede 
kernelspace shutdown.

> Anyway, the proposal looks great; I'm really glad someone is tackling
> this area.

No kidding.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060203/f5060472/attachment.pgp>