lkml.org 
[lkml]   [2002]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PATCH 2.5.x disable BAR when sizing
    On Mon, Dec 23, 2002 at 11:29:15AM +1100, Paul Mackerras wrote:
    > We could relocate the ASIC if we could find the ioremaps and fix them
    > up, or if we could get to all the drivers and have them re-do their
    > ioremaps. There is no way to do that at the moment, though.
    > Typically the ASIC will have a couple of IDE interfaces, audio,
    > serial, i2c, interrupt controller, wireless ethernet, timer, and PMU
    > (power management unit) interfaces in it, so there are several drivers
    > involved.

    I see, thanks. I always had an impression that pci_init is called
    way too late in the boot sequence, at least on the PCI-centric systems.
    This makes all that PCI surgery really painful. Ideally, the init
    order should be defined per architecture. This applies to the
    generic device model as well: currently we have legacy, isa-pnp
    and other stuff initialized and probed *before* PCI, though typically
    these are hanging of the PCI bus. And it's a real problem on machines
    with multiple PCI buses. Oh, well...

    > In fact we don't really need to probe the BARs of the ASIC at all,
    > because the device tree that we get from Open Firmware tells us the
    > size and location of the resources it is using (along with all the
    > other PCI devices in the system). If we could have a
    > platform-specific hook so that we could provide an alternative method
    > for probing the BARs of certain PCI devices, that would let us avoid
    > the whole problem.

    It can be trivially done using Linus' idea of probing in 2 phases.
    The pass 1 can be made 100% non-destructive: we can initialize
    device structures, read in device/vendor IDs, class codes and
    build the bus trees. Basically, everything that we do currently
    minus pci_read_bases(), so the resource fields are blank. Then we
    can call arch- and device-specific routines, where along with other
    fixups the device BARs could be probed in arch-specific way and written
    down in the pci_dev structure.
    In the pass 2 (generic BAR probing), we can check the resource flags
    for non-zero value and skip the probe of respective BAR.
    This would make the code a LOT more flexible.

    Ivan.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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