Linus Torvalds writes:
>
> On Wed, 15 Oct 2003, Michel Dänzer wrote:
> > On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
> >
> > > This new scheme allows the entire PCI probing stage of xfree to be eliminated.
> >
> > I'll believe it when the relevant XFree86 developers agree with you. :)
>
> If they don't, they are clueless.
>
> There's no way in _hell_ that XFree86 can do as good a job as the kernel,
> on as wide a variety of hardware. Basically, if the kernel booted far
> enough that XFree86 is an issue, then the kernel will know how to probe
> PCI devices. The same is _not_ true of XFree86.
I fully agree with you and I wish this had been true at the time I
implemented most of the PCI probing code in XFree86. At that time
Linux did not provide all information XFree86 required and also relied
on the PCI configuration the BIOS performed at POST time. This
configuration proved to be wrong in a lot of cases - at least for
non active VGA devices.
We had to jump thru hoops bending over backwards to 'guess' some
information that we could not savely probe.
I'm not sure if PCI probing can be eliminated completely from XFree86
as it was suggested in the original posting as it also needs to run
with hardware for which no DRI support is available.
Furthermore for RAC (Resource Access Control) it needs to know the
bus structure (ie which PCI buses live behind a PCI-PCI bridge on
which primary bus).
All this information however could be retrieved from the kernel.
In fact this is done on all platforms except the 'PC-like' ia32 and
AMD64 where direct IO access to the configuration space registers
is used for performance reasons.
On 'sane' OSes which take care of PCI probing and correcting of
PCI resources themselves a lot of the PCI validation code could
be bypassed.
Unfortunately when I suggested this I was told that this code should
stay in for all platforms to get much wider testing. I chose to
refrain from starting a flamewar....
>
> Yes, XF86 may need to have some legacy module for backwards compatibility.
> But thinking that X should try to probe on its own is just silly.
>
> There are things like cardbus or compact flash video cards - you need them
> for external video on things like an iPAQ. I don't think you _really_ want
> X to know about every single PCI bridge type out there, present and
> future, and for every architecture out there.
>
For RAC I just would like to know the bus tree (or better to say the
PCI-PCI bridges) and I would like to know if devices behind different
host bridges or in different domains are in the same address space
to know if VGA resources (which a lot of devices still need) may
conflict with each other.
The information about PCI host bridges was added for some special
purposes (like to know if we are allowed to probe for sparsely located
8514 registers). - A question that is rather academical in nature on
the platforms where it arises.
Egbert.
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
