Re: newbus ioport usage

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 04/02/04

  • Next message: Perlegen HR: "Out of Office AutoReply: Mail Delivery (failure perlegen_hr@perlegen.com)" 
    Date: Fri, 02 Apr 2004 14:04:48 -0700 (MST)
To: nate@root.org

    In message: <20040402123025.E3097@root.org>
                Nate Lawson <nate@root.org> writes:
    : ACPI already abuses identify/probe/attach to get priority for different
    : probe tasks. We've run out of places to stick things since those are the
    : only 3 hooks provided.

    The ISA bus uses a priority number to determine when to do the probe
    of a given device. How does ACPI abuse things that isn't compatible
    with this? Why can't ACPI do things in a similar way? Why is ACPI so
    different than all other busses that it can't deal with things the
    same way? Maybe it is different, but what I know about ACPI right now
    is inconsistant with your assertions.

    : As a transition approach, we can add a flag to the end of the driver
    : structure that requests multi-pass attach. Legacy drivers or non-bus
    : drivers that just need the old behavior leave the flag 0 by default.
    : Drivers like acpi set the flag and parse the pass number (arg2).

    I don't like this much at all. newbus isn't like that: either you
    implement the interface or you don't, there's not flags around.
    However a similar approach could be taken so that we don't screw all
    the drivers with two different device_attach-like methods, so I don't
    think that will be a problem. If we do this, we should do it for all
    drivers.

    : This yields:
    :
    : #define BUS_PASS_BUS_HARDWARE 100
    : #define BUS_PASS_IRQ_SOURCES 200
    : #define BUS_PASS_IRQ_CONSUMERS 300
    : #define BUS_PASS_CLOCKS 400
    : #define BUS_PASS_LAST 0xffffffff
    :
    : int device_attach(device_t dev, int pass);
    :
    : One question I have is whether this process would be repeated as we
    : discover more depths of busses (e.g., the other side of bridges.)

    I think that you are confusing two fundamental sets of things, or I
    am. Depth of busses have nothing to do with the number of passes.
    The entire tree of devices are already known after the
    BUS_PASS_BUS_HARDWARE pass, at least how jhb@ and I were talking
    about.

    : If we decide to go this way, I'd like to get it in before 5-stable.

    That's likely too agressive a time scale. There's a lot of newbus/pci
    resource allocation in my p4 tree already.

    Warner
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Perlegen HR: "Out of Office AutoReply: Mail Delivery (failure perlegen_hr@perlegen.com)"

    Relevant Pages