lkml.org 
[lkml]   [2003]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch 2.5] PCI: allow alternative methods for probing the BARs
    From
    Date
    Linus Torvalds <torvalds@transmeta.com> writes:

    > On Sun, 5 Jan 2003, Ivan Kokshaysky wrote:
    > >
    > > Hopefully this patch should solve most problems with probing the BARs.
    > > The changes are quite minimal as everything still is done in one pass.
    >
    > Can you do the same with a multi-pass thing?
    >
    > I really think the single-pass approach is broken, because it means that
    > we _cannot_ have a fixup for device that runs _before_ the fixup for the
    > bridge that bridges to the device.
    >
    > As such, the "PCI_FIXUP_EARLY" is not _nearly_ early enough, since it's
    > way too late for the actual problem that started this whole thread (ie in
    > order to turn off a bridge, we have to make sure that everything behind
    > the bridge is turned off _first_).
    >
    > In other words, we really should be able to do all the bus number setup
    > _first_. That isn't dependent ont eh BAR's or anything else. The actual
    > _sizing_ of the bus is clearly somethign we cannot do early, but we can
    > (and should) enumerate the devices first in phase #1.
    >
    > Alternatively, we could even have a very limited phase #1 that only
    > enumerates _reachable_ devices (ie it doesn't even try to create bus
    > numbers, it only enumerates devices and buses that have already been set
    > up by the firmware, and ignores bridges that aren't set up yet). A pure
    > discovery phase, without any configuration at all.
    >
    > Hmm?

    I have done something similar to this in LinuxBIOS, perhaps a
    description of that will spark ideas.

    In the enumeration phase I look at the vendor+device id and then hdr
    type to assign methods. The methods I have are:
    scan_bus,
    read_bases,
    write_bases.

    Then for all children of a bus that have a scan_bus function I
    recurse. This fits in very naturally with devices not necessarily
    being pci devices.

    When it comes time to assign pci resources I call the read_bases
    method to get the size and possibly fixed location of the resource. I
    play with my data structures to get a non conflicting set of resources
    and then I call write_bases on each device to write the resource
    assignments to the actual device.

    The setup works well enough that I don't have to differentiation later
    in the code between pci busses and normal pci devices.

    I have not had to push beyond the standard pci devices yet, but I
    don't think I have missed anything that would cause me problems.

    Linus is this the kind of thing you are thinking of?

    Eric
    -
    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:32    [W:0.022 / U:61.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site