On Fri, 15 Sep 2000, Gérard Roudier wrote:
>
> > Just as an example: imagine that the IO windows haven't been set up
> > correctly. If the low-level driver just blindly enables IO cycles by
> > writing to the PCI_COMMAND register, that device may come up in an invalid
> > state, and mess up the whole system. The driver simply does not KNOW
> > enough. It doesn't know where other devices are, and it _shouldn't_ know.
>
> How do you want this to happen ? Could you elaborate.
It's really easy.
Call "pci_enable_device()".
What's so hard about that?
You don't seem to realize, but it's entirely possible to have a setup
where some device CANNOT be allocated it's IO region. The BIOS may have
left the device disabled on purpose, simply because there wasn't enough
free space in the memory map to enable the device anywhere.
You can't just have the device driver enable such a device. It _has_ to
ask the PCI layer to do it for it - because the PCI layer is the only one
that can figure out that "Oh, damn, this machine has 3GB of memory, and 4
video cards that want a 256MB aperture each, and we don't have any place
to map this card any more".
No ifs, why's or buts. A driver that just enables the IO windows is a
buggy driver.
> > In contrast, the general PCI layer _does_ know. It keeps track of
> > resources, makes sure that different cards do not have overlapping address
> > ranges, knows about PCI bridges (a card behind a PCI bridge can only be
> > enabled after the _bridge_ has been enabled and can only be mapped in the
> > region that the bridge maps).
>
> Yes, it is expected to do its work (e.g. assigning ressources to all
> agents on the BUS hierachy).
Right.
And sometimes it CANNOT.
End of story.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:26 EST