Date: Wed, 4 Feb 2004 10:47:17 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org>, "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: newbus ioport usage Message-ID: <200402041047.17902.jhb@FreeBSD.org> In-Reply-To: <20040203145412.P33636@root.org> References: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org> <20040203.131641.26968129.imp@bsdimp.com> <20040203145412.P33636@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402041047.17902.jhb>