Re: PCI amiga's..

[Michael S. <sc...@zi...>]

> > 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. I'd rather have XFree not assume PCI is available on Linux.
 
> > 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? 

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

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

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

	Michael