newbus ioport usage
jhb at FreeBSD.org
Wed Feb 4 10:21:14 PST 2004
On Tuesday 03 February 2004 06:03 pm, Nate Lawson wrote:
> On Tue, 3 Feb 2004, M. Warner Losh wrote:
> > : In the future, I'll make two passes, first to detect system resource
> > : objects (PNP0C01 and PNP0C02) and reserve resources and the second to
> > : actually probe acpi devices. I'd rather wait for newbus to do this
> > : multi-pass approach than attempt it myself with hacks to try to
> > : localize it.
> > Yes. We need a better discovery phase followed by an attach phase. I
> > don't know if this is a newbus API change yet or not. I can see it
> > being done with most of the APIs that are in place now, but a few
> > tweaks might be in order.
> I could implement this in acpi since we already make two attach passes for
> busses like PCI. Perhaps the general case could be a flags argument that
> is passed through to the attach handler that says what pass this is.
We need to allow something that allows legacy drivers to work out of the box
at the last pass and it needs to be more flexible than just special casing
PCI/ACPI resource allocation. I want more than just 2 passes btw:
pass 1: enumerate busses including bridges to further busses
- this would possibly include some rough resource allocation where each bus
would allocate space from its parent that it hands out to children
- this pass might also include things like pnpbios and acpi system resource
pass 2: enumerate interrupt source providers (i.e. PICs)
- after this, interrupt handlers should be able to run, though perhaps not
safe to rely on yet due to lack of working timeouts
pass 3: let all the previously probed devices attach interrupt handlers if
needed (like acpi0 needing the SCI)
pass 4: enumerate clock devices
- this lets us get timeouts working. We can now start scheduling ithreads
and allowing interrupt handlers to run.
pass 0 (done last): everything else
Now most devices will always probe/attach with interrupts and timeouts fully
up and running like they are when a driver is kldloaded after boot, meaning
that all the config intr hook crap can die, etc. I think that a driver with
a legacy foo_probe/foo_attach should only be called during the last pass.
One possible way to accomplish this with minimal damage is to add a pass
number field to the driver structure after the softc field and have pass 0 be
the magic pass that happens at the end. That would get legacy drivers
working w/ just a recompile.
The other thing you want to do though would be to add a pass number to
foo_attach(), and once a driver is probed, it's attach routine would get
called for every subsequent pass with the pass number passed in as the
argument. This would require an API/ABI change for foo_attach though. The
reason for this is that some devices might need to do different things for
different passes. For example, acpi0 would want to parse the madt to
enumerate PICs during pass 2 even though it would be a pass 1 driver. The
same for legacy0 and using the mptable in pass2.
I'm not sure if this is the best approach for that case. You might be able to
do it w/o changing foo_attach() by having an apic pass 2 driver that is a
child of acpi0 whose identify routine parses the MADT and similarly for
legacy0 by having the apic driver parse mptable for its identify routine.
That would allow us to keep API compatiblity and only adjust the driver
Doing this would allow us to finally kick things like CPUs, PICs, clocks and
other system devices under new-bus properly.
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-arch