[lkml]   [2000]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: New topic (PowerPC Linux PCI HELL)

On Fri, 15 Sep 2000, Linus Torvalds wrote:

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

This function delegates too much as a whole to the PCI generic layer, IMO.
Imagine that for sanity I want to allocate all the device resources, but
only _enable_ part of device features (for example only memory
transactions). Imagine some special handling to be necessary due to some
chip bug.

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

PCI specs said corresponding BAR must be set to ZERO, here.

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

I want to say the generic layer "What to do" in some more fine-grained way
than just a single verb, at least. I may accept to delegate it some "How
to do it".

> No ifs, why's or buts. A driver that just enables the IO windows is a
> buggy driver.

In PCI, you donnot enable windows, but you enable/disable devices to
generate and/or respond to transactions. OTOH, if you look at all the bits
in the COMMAND register, you will see that some other features are also to
be addressed by the enabling/disabling kernel interface.

> > > 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.042 / U:2.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site