Re: newbus ioport usage
From: M. Warner Losh (imp_at_bsdimp.com)
Date: 04/02/04
- Previous message: Nate Lawson: "Re: newbus ioport usage"
- In reply to: Nate Lawson: "Re: newbus ioport usage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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"
- Previous message: Nate Lawson: "Re: newbus ioport usage"
- In reply to: Nate Lawson: "Re: newbus ioport usage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
