PCI Subsystem Rework for X.org 7.1 Proposal

[Jesse Barnes]

On Friday, February 3, 2006 11:28 am, Egbert Eich wrote:
> Some bugginess comes from the fact that we try to determine the
> topology of the PCI system as this is required for VGA routing. When
> the code was designed we assumed that there is a bridge to every PCI
> bus that's visible in the config space. Later on we learned that H2PCI
> bridges aren't always visible - although oddly they were on i386
> systems.
>
> Another problem arises from the fact that we still use the old
> separation code that was desinged for direct config space access.
> This code should only be used in a backend where necessary.

Yeah, I'm not saying it's an easy thing to get right.  The kernel has 
evolved in this area quite a bit, and seems to require changes whenever 
a new and funky platform is added.  It's not an easy thing to get 
working.

>  > > Required Functionalty
>  > >  There are seven broad pieces of functionality that X.org needs
>  > > to work with devices on the PCI bus. These are:
>  > >  Get a list of all devices matching some criteria.
>  > >  Reading the device's expansion ROM.
>  > >  Accessing the device's IO ports.
>  > >  Accessing the device's memory regions (BARs).
>
> Only recent kernels have support for this thru their PCI interface.
> I assume we can wrap this and add our own interface when kernels
> don't have this.
> And if you look at older Alpha's (pre EV6) the situation is really
> grim.

Linux kernels have supported mapping BARs for a long time, 
via /proc/bus/pci.  But that interface doesn't handle domains very well, 
iirc.  It also doesn't handle the ROM or I/O port features we need for 
cross-platform compatibility.

>  > >  Reading the device's capabilities (i.e., determine if the device
>  > > is AGP).
>
> Reading (and even writing) PCI config space beyond device's
> capabilities is essential.
> BIOS POST code requires it. The int10 code needs to catch config space
> accesses (it does so alrady if I recall correctly) and go thru a
> function that accesses config space.

Right, that's doable today as well (and has been for some time 
via /proc/bus/pci).

> For memory management you just need to know an address region and
> some properties that describe what this region is for. This can
> sit on top of the PCI subsystem.

But should it?  Or should it be a separate API, maybe accessible through 
DRI/DRM somehow?  I'm not sure about this one.

> We do flagging at the moment which gives us some more flexibility.
> Any automatic system will not do what you want at some point and
> then people start to kludge around it.

Yeah, that's probably true.  Some sort of explicit mechanism would be 
best, as long as the underlying system (i.e. the kernel) is free to 
ignore it if the platform can't support it.

> The problem here is that we may need to get an overview over the PCI
> device topology - not a single device. From the driver perspective
> this is different. There you only want to register a single device -
> although this view may prove to be too simplistic as some devices
> appear under 2 IDs.

Can you describe an example of this?  I can imagine that this might be 
true, but we don't want to overengineer something when we could just add 
a single special case call instead, for example.

> What about hotplug? If we destry the entire structure pieces that
> have pointers to some part may barf.

What about it?  Presumably this system would have to be aware of hotplug 
events and take the appropriate action.  If there are dangling pointers 
somewhere, that would be a definite bug, probably in the driver not the 
library (e.g. using a device after calling pci_system_cleanup() or 
somesuch).

> Currently the bases and sizes are used in common code.

For what?  I know they're used in some of the platform code to match 
devices, but iirc that's only because domains weren't supported 
properly.  Generally, it seems like BAR values shouldn't be used by a 
userspace application--they should use the mmap'd address instead.

Jesse