PCI Subsystem Rework for X.org 7.1 Proposal

[Jesse Barnes]

On Sunday, February 05, 2006 3:50 am, Egbert Eich wrote:
> 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 agree, the existing mechanism isn't very well separated so as to allow 
different arch. backends, but that sort of design is definitely doable 
(as shown by several projects).

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

That's too bad, I know you have a lot of familiarity with this code.  
Hopefully you can dig something up and post it...

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

Right, sounds good (btw, there are OSes besides Linux out there? :).

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

Sounds about right, but I'm not sure about the details either.  I *hope* 
the PCI stuff can be cleanly separated from memory management, but 
we'll have to see.

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

Heh, sounds famliar, I think many of the current helper functions fall 
into that category.

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

Definitely, I was just wondering if you had any ideas on that line.  It 
clearly needs to be handled in some way, since the X server will be the 
only one in a position to save and restore the state of the gfx chip in 
many cases.

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

Ah, ok.  Yeah for some OSes we'll need this sort of code, but in any 
case, it shouldn't be something drivers have to worry about, right?  
Shouldn't it only be part of the PCI library back ends that need it?

Thanks,
Jesse