LongTrail PCI resource assignment

[Benjamin Herrenschmidt]

On Fri, Mar 24, 2000, Michael Schmitz
<schmitz at opal.biophys.uni-duesseldorf.de> wrote:


>I'd like to reach a point where I understand what's happening in the
>XFree PCI code before getting into that sort of discussion. And the X
>source is way too convoluted for me to achieve that right now.
>
>I'll stick to pre-4.0 XFree rather.

I spent some time discussion with Egbert. The result is basically that in
order to support all archs, bogus BIOS, legacy cards, softbooting, etc...
XF must take over the PCI the way it does it. There are lots of reasons
for that, I could try to summarize them if you really want the gory
details, I beleive Egbert is bored of repeating himself all the time ;)

I suggested making that optional (and relying, for example, only on fbdev
or disabling the re-assignement when the appropriate option is set in
XF86Config), but Egbert thinks that would be a support nightmare with
users playing with the config options.

He agrees that things are not perfect, especially since the way we handle
PIO and iobase is bogus (see other discussions about this). Also, the
current remapping scheme can make the kernel (and fbdev) quite confused
with new hot-swap PCI, Cardbus, etc... He plans to rework the PCI
interface of XFree so that better cooperation with the kernel can be
implemented. On another hand, I think _we_ should find a definitive
solution for the PIO problem before he can begin adapting XFree. There
are lots of changes to be done to legacy drivers (VGA) to make them grok
a notion of iobase (since iobase can be different per-device, it can't be
handled inside inb/outb and friends).

Note that XF will always have to disable IO response on VGA cards when
more than one card is present in the machine since that's the only way to
prevent 2 VGA cards from trying to hard-decode legacy VGA addresses at
the same time. We need to find a way to make the kernel (and the fbdev)
aware of what's going on.

No time do give more details now, tell me if you need more precisions on
one of these specific points.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/