Date: Fri, 2 Apr 2004 12:42:51 -0800 (PST) From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@freebsd.org Subject: Re: newbus ioport usage Message-ID: <20040402123025.E3097@root.org> In-Reply-To: <200402041047.17902.jhb@FreeBSD.org> References: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org> <20040203.131641.26968129.imp@bsdimp.com> <20040203145412.P33636@root.org> <200402041047.17902.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Feb 2004, John Baldwin wrote: > 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. 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. 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). 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.) If we decide to go this way, I'd like to get it in before 5-stable. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040402123025.E3097>