newbus ioport usage
M. Warner Losh
imp at bsdimp.com
Fri Apr 2 13:04:29 PST 2004
In message: <20040402123025.E3097 at root.org>
Nate Lawson <nate at 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
More information about the freebsd-arch
mailing list