Messages in this thread |  | | Date | Fri, 15 Sep 2000 23:20:39 +0200 (CEST) | From | Gérard Roudier <> | Subject | Re: 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
Gérard.
- 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/
|  |