lkml.org 
[lkml]   [2000]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.039 / U:0.328 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site