newbus ioport usage

[John Baldwin]

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
   drivers
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 
struct ABI.

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