PCI rework

[Jesse Barnes]

On Monday, May 1, 2006 12:08 pm, Mark Kettenis wrote:
> Well, io port space is certainly the stuff with the most quirks.  Lots
> of PCI stuff abuses the "unused" high bits of an IO BAR to store other
> stuff.
>
> But no, I've seen a few PCI devices that have "normal" memory BAR's in
> nonstandard locations, i.e. at offset 0xe0 or 0xf0 in PCI config
> space.  The libpciaccess interface can only deal with the standard
> BARs at offsets 0x10 through 0x28.

Sounds pretty broken... which devices behave this way?  Do we care about 
them anymore?  And even if we do, it sounds like something that should 
be hidden from X.  The library or kernel could have quirks describing 
these special regions if we really need them.

> Anothor major flaw in the libpciaccess interface is that it doesn't
> allow the caller to specify a size for the mapping.  This is
> important, since a video driver might want to map only part of a
> region.

I can see how that might be useful in some cases, but I think we'll need 
examples to justify adding the feature to the interface.  Do you have 
any concrete ones?

> If the firmware properly initialized things, PCI config does give you
> enough information.

Nope, even when a firmware does things right you still may not have 
enough info.  Remember bus address space is unique on some platforms and 
you need the OS to tell you what physical address a given bus address 
corresponds to (likewise for physical->virtual mappings of course).

> X should only be looking at the PCI config space 
> for the graphics card.

X should only be looking at platform assigned resource addresses, not 
config space itself (except maybe on platforms that don't have a decent 
PCI layer, but again that should be hidden in the library).

> It certainly shouldn't need to walk PCI 
> bridges and assigning memory addresses.

I think everyone agrees with this statement. :)

> Ah, but you could make PCITAG a structure, and include that void *.

Sure, that's basically what Ian is doing with this interface change, 
making PCITAG into a real, useful structure rather than a strangely 
encoded number that can't properly handle PCI domains.

> > X shouldn't be working around buggy BIOSes.  If this knowledge
> > belongs anywhere, it's in the OS (or at the very least some sort of
> > fairly centralized library).
>
> You're probably right.  But you releaze that this means dropping
> support for operating systems that don't fix things up right.

Not necessarily, support for those extremely simple (arguably broken) 
OSes could still be added to libpciaccess.

> There's 
> no way X can fix things up for you.  The same thing goes for new
> hardware that the OS doesn't know how to fix up yet.

Yeah, matching up driver vs. device release times is always a problem, 
not just for the OS, but for X, laptop vendors, etc., etc.  But I think 
it's really orthogonal to this discussion... pushing the problem of 
device knowledge onto the OS shouldn't make things any worse than the 
old situation of having X deal with it.

> > I'm talking about xf86MapDomainMemory vs. xf86MapPciMem, but it
> > sounds like we agree that it's a silly distinction.  PCI domains (or
> > segments in ACPI as you mention) need to be dealt with on a high
> > level.
>
> Something that should really be abstracted away by the OS.

Right.

> > Well, they're out there.  I don't really like the idea of userspace
> > drivers in general, but for certain devices a userspace driver is
> > the path of least resistance.  And there are quite a few of them out
> > there, mostly used for special purpose applications.
>
> Is there any hope these applications will adopt this new libpciaccess
> library and actually contribute back to it?  If not, thinking about
> libpciaccess as a third party library that the Xorg project doesn't
> have to maintain is just wishful thinking.

I think there's that potential, maybe Ian has been approached by other 
user level driver authors, I'm not sure.

Jesse