PCI Subsystem Rework for X.org 7.1 Proposal

[Egbert Eich]

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

Yeah, the original goal was to separate it somehow.
However in the early days we were unable to envision what
we will have to expect on future systems.

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

I should be able to rework it.
I think the idea of having a completely separate library is the
way to go. This way things can get developed outside of the DDX
tree and we don't have to fire up a complete Xserver for testing.

I believe that we should have a little test program that runs
all functions of the lib to verify that it's working.

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

yeah, there are! It's hard to believe, I know.
The challange here is if our desing holds up when we
try to support more than one OS. I always found this
interesting.

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

Right. Let's start playing. We can still shove things around.

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

Right. These functions take away a tremendous amount of boilerplate stuff.
On the other hand they are too monolithic. If they were more modular
one could address special cases without having to write everything
by hand.

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

We can avoid dangling pointers by passing a private copy of all
data to the drivers. 
If we receive a removal event (prior to the removal of the hardware)
would be able to shut down a particular entity pretty much like we
do on a CloseScreen().
Adding new entities today is not possible largely because of
the Resource Manager.
We also need to answer the question how we deal with the 
card/port <-> screen assignement. Today this is tightly
coupled and creates nightmares in a vriety of ways.
I would like to get rid of this tight coupling.

This way you could have n screen on m heads. if m < n you
can make only n visible at a time. But with COMPOSITE this
should not be a real issue as you can make the windows
that live on each screen visible whereever else you want.

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

No, not at all. Unless you are a driver for an ISA card you may have 
to ask for a physical address range for which you need the physical
address to write to the chip in some chipset specific way.

 > Shouldn't it only be part of the PCI library back ends that need it?

Yeah, pretty much.

Cheers,
	Egbert.