Re: PCI amiga's..

[Michel <dae...@st...>]

Michael Schmitz wrote:
> 
> > > No, that would not make sense unless we add code in the kernel to
> > > masquerade the m68k builtin framebuffer devices as PCI devices of some
> > > sort (and I don't just mean support for /proc/bus/pci).
> >
> > I have implemented something like this for the Permedia2 based boards in
> > the APUS tree. But I don't think it's feasible for all graphics hardware.
> 
> I guess you have to create a fairly close emulation of real PCI hardware
> to fool XFree.

Right, not hard with the Permedia2 boards where the PCI config space is
available.

> I'd rather have XFree not assume PCI is available on Linux.

It doesn't. Or at least it works without.


> > > Now how does XFree86 4.x deal with legacy Intel hardware with just ISA
> > > or EISA but no PCI bus? Does this still work, at all??
> >
> > Yes. There's similar code for (E)ISA.
> 
> Good. That's just using hardcoded (S)VGA addresses?

Dunno, haven't looked at the code.


> > > There should be a way (in site.def, perhaps) to say 'there's no PCI on
> > > this architecture, use other access methods like VGA or fbdev'. If
> > > that's not possible, dummy PCI functions could be implemented that just
> > > return -ENODEV for anything if /proc/bus/pci isn't present, hoping XFree
> > > does what it is supposed to in this case: fall back on fbdev to map and
> > > access the hardware.
> >
> > Just look at the PPC PCI code, that works fine without /proc/pci - tested
> > on APUS.
> 
> Does it also work without PCI hardware?

Yes, I had to add fbdev probing code to the glint driver though which is still
considered a hack.


> > > If even that isn't possible, the design of XFree86 4.0 is badly broken
> > > (not that I'd be surprised; in my eyes the way XFree messes with PCI
> > > resources bypassing the kernel is a big design flaw and just asking for
> > > trouble).
> >
> > Many people have complained about that, but they forget that XFree86 runs
> > on a lot more OSs than just Linux which may not have such a convenient API
> > for PCI. And even the older Linux kernels don't.
> 
> It's not about the convenient API for PCI but about the convenient API for
> mapping IO and memory of the graphics hardware plus the fbdev ioctls to
> set video modes, color entries and more. fbdev has been in the official
> kernel for quite a while now.

Yes, in the official _Linux_ kernel. What about all the BSDs, Solaris (I know
that also has some kind of framebuffer device, but nobody has bothered to add
code for that), the various System V flavours, OS/2, ... ?


> I do know that the option UseFBDev will make XFree use the kernel fbdev
> API _once the card has been detected_. What I complain about is the lack
> of a mechanism to tell XFree 'don't touch this card, the kernel fbdev
> driver at /dev/fb<index> knows how to handle it' already at the probe stage.

If you provide the bus ID, the X server won't mess with the device if the
memory regions etc. are sane. Development is taking place to automate the
(non-trivial) assignment fbdev <-> pcidev . If you know how to do it easily,
patches go to pa...@XF... or fi...@XF..., design suggestions to
xp...@XF... :)


> Right now there's no way for the kernel fbdev driver to figure out
> Xfree just disabled the PCI IO or memory resource for its card, resulting
> in the first kernel panics I've ever seen with XFree on sane (non-Intel)
> hardware. Makes me think about whether the GGI people had it right all the
> time.
> 
> OTOH, it's all Apple's fault for setting up crazy PCI resources, and the
> kernel's fault for not demangling the PCI resource allocation. At least
> that's going to be solved in 2.4.

Exactly, setting up sane PCI regions is a kernel task IMHO and I consider it
plausible for the X server to assume that overlapping regions are a problem.


Michel


-- 
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project