Messages in this thread |  | | Date | Fri, 15 Sep 2000 22:05:57 +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, Richard B. Johnson wrote: > > > > The PCI Specification states, in part, that either the BIOS or the > > driver has to enable the device. So, many drivers find that the device > > has not been enabled. This is normal and necessary because many/most > > PCI hardware had better not be enabled until an ISR is in-place. > > But that's why we have the "pci_enable_device()" function. And that's why > we have the generic PCI setup functionality that finds and enables devices > at the right addresses. > > DO NOT USE ANY LOCAL HACKS. Use the proper function. Don't go mucking > around with random configuration state information: enabling a device > involves a lot more than just writing stuff to configuration ports. Things > like making sure the interrupt routing on the motherboard has been > enabled, etc. Things that the driver does not know about, and should not > even _try_ to understand. > > The PCI layer should be used to handle generic PCI issues. A low-level > driver should _never_ try to handle resource allocation and enabling in > hardware.
Disagreed about `enabling'.
> 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.
> 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).
> To make a long story short: a driver that touches the PCI_COMMAND or other > generic PCI registers by hand is a _buggy_ driver. It's a sure recipe for > disaster.
I disagree 100% with this statement. The genericity of PCI configuration is only here to facilitate configuration of all the devices on a BUS hierarchy. Indeed a PCI device driver must not tamper the resources the device got from the generic PCI layer. But it is expected to know better about the PCI devices it supports that any generic PCI layer. Not everything are generic in PCI. What about device bugs, for example? About bridges, part of their configuration can be handled generically, but not everything. The generic PCI layer that deals with bridges have to know bridge quirks and special features as you know. In some way, the PCI generic layer acts as PCI device drivers for the bridges. Configuring and enabling are 2 different issues. Configuring has been designed to be generic in PCI but the `enabling' should be performed by the entity that knows the best about the real device, thus the PCI device driver.
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/
|  |