Date: Tue, 3 Feb 2004 15:03:58 -0800 (PST) From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: newbus ioport usage Message-ID: <20040203145412.P33636@root.org> In-Reply-To: <20040203.131641.26968129.imp@bsdimp.com> References: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org> <20040127.032119.28084825.imp@bsdimp.com> <20040203111312.Q32201@root.org> <20040203.131641.26968129.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Feb 2004, M. Warner Losh wrote: > [[ I'll draft a longer reply this evening ]] Great. > In message: <20040203111312.Q32201@root.org> > Nate Lawson <nate@root.org> writes: > : 1. Do I have to do all the bus_set_handle gyrations found in nexus? > > I think so. I'd have to look at the code. You may be able to copy > the bus_handle from the BUS_ALLOC_RESOURCE resource. I'm not quite sure how things work but I think I shouldn't have to do any post-processing of resources retrieved from BUS_ALLOC_RESOURCE. The nexus should do all the original setup and then I am just storing it in an rman pool with rman_manage_region. The handle may need to be regenerated when allocating a resource out of the rman pool (later), especially if the range changes. For example, if I BUS_ALLOC_RESOURCE 4 I/O ports and manage the whole region in rman, a later rman_release_resource and then rman_reserve_resource of 1 of them should re-set the bus handle. I can post the code if it would help. It makes my laptop hard reset a little ways into the boot. ;-) But for now, I think all I need to know is what I need to do differently in acpi than in the nexus. The differences as I see it are: 1. No previous knowledge of start/end for my rman pools. Call rman_manage_region for each resource retrieved from nexus. 2. Try a BUS_ALLOC_RESOURCE first instead of going straight to the rman pool. 3. Always release to the local rman pool, not the parent. 4. Skip most bus handle initialization that is already done in nexus. I'm sure there are problems with these assumptions. > : I > : thought that they could be dispensed with since nexus should do all those > : when acpi0 allocates resources from it with BUS_ALLOC_RESOURCE. > > It all depends on the details (eg, I'd have to look at the code you > are writing). > > : 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. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040203145412.P33636>