PCI Subsystem Rework for X.org 7.1 Proposal

[Egbert Eich]

Jesse Barnes writes:
 > 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.

It's not so bad when we separate the backend that deals with OS
specialities cleanly.
The current model suffers from a wrong separation. One example are
those PCITags which we carry all over. PCITags are a left over of
PIO access mechanism 1.

I started working on a new backend a while ago. I don't know if
I still can find pieces of the code - a lot of it went down the
drain when my disk died.

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

Right. But not everything is Linux kernel. We may have to have a
legacy helper level which gets used by the backend if the kernel
doesn't provide this support. 
I don't see a problem here. The legacy code won't bother non-legacy
OSes and it's already there. Just needs to be rearranged a little.

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

Yes, I think that's done already. We don't use the PCI_MECH_1/2
access methods at all any more - unless some crazy user asks for it.

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

At the moment I feel that memory management should live outside of
the PCI code. It looks like if the PCI code can provide properties
of the memory regions that it offers and allows mapping (again with
certain properties) this should be possible.
Some ugly details may prove me wrong though.
 > 
 > > 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.

Well, what comes to my mind is that some intel chipsets appear under
two different device functions. Just a scanpci output on this box
here gives:

pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x3582
 Intel Corp. 82852/855GM Integrated Graphics Device

pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x3582
 Intel Corp. 82852/855GM Integrated Graphics Device

Before the driver was able to deal with that it erronously set up
two separate screens. 
Thinking back about this however the reason was more an overengineered
generic helper function which didn't leave the driver enough opportunity
to influence its behavior.

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

Dangling pointers is some thing to avoid. However I assume we need
to keep hotplugging in mind when we design our interface.

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

Recource validation. 
The interface there is *way* too overdesigned. It's never been
used to the extend of what it has been designed for and is much
closer to what I had originally in mind.
On Linux we don't need it any more. For legacy we can limit the 
design to what is actually used by the drivers today and push this 
into the legacy level of the PCI lib.
Same thing is true for ISA devices for which we would only have to 
find available address ranges.

Cheers,
	Egbert.