Date: Thu, 07 Apr 2011 15:04:13 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: Atheros 9285 & Atheros AR8131 Message-ID: <4D9E0AAD.2010708@FreeBSD.org> In-Reply-To: <4D9DF38B.8050703@root.org> References: <AANLkTi=-rourdUbyH0MVceHi81vAHcNdpaxjpmxJ_BCk@mail.gmail.com> <AANLkTinPAF6dQ0Y4se2B7yqQxVBktv3X1_MUFkfb75dC@mail.gmail.com> <201103281406.27334.jhb@freebsd.org> <201104061600.53572.jhb@freebsd.org> <4D9CE06C.3070002@root.org> <4D9DC1C6.4040700@FreeBSD.org> <4D9DF38B.8050703@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/7/11 1:25 PM, Nate Lawson wrote: > On 4/7/2011 6:53 AM, John Baldwin wrote: >> On 4/6/11 5:51 PM, Nate Lawson wrote: >>> Wow, awesome work. This is really useful for fixing a common problem. >>> >>> Should bus_adjust_resource() be a DEVMETHOD or is this something that >>> should be done automatically within rman_alloc_resource(), possibly >>> based on a device flag? >> >> Hmm, I had only thought of it as being a wrapper around >> rman_adjust_resource(). I'm not sure what you mean by adjusting it >> inside another method? Note that one of the reasons I have the current >> method is that different devices may have different restrictions on how >> resources can grow. For example, the PCI-PCI memory windows are aligned >> on 1MB boundaries and are allocated in 1MB chunks while the I/O port >> windows are aligned and allocated in 4K chunks. >> >> I also plan to make use of rman_adjust_resource() for PCI bus >> renumbering, but in that case resources would only grow at the end, etc. >> Given that, I want to keep the logic to determine which kind of >> adjustment to perform in the relevant driver rather than having rman >> attempt to use a generic algorithm for expanding a resource and >> associated rman used for suballocation (if that makes sense). > > Yes, that makes sense. It's a question of complexity -- do you push a > set of rules to rman and have it apply them? Or do you do the adjusting > in the driver itself, which knows its own restrictions but may end up > replicating some general purpose code for applying those restrictions? > > This seems great for now. I don't have any complaints, just musing about > the future. Ahh, ok. So far my current plans for other places using rmans don't involve the same set of rules. However, I would be happy for their to eventually be a more general version of pcib_grow_window() if we find a need for it in the future. I think you could have a helper function at that level of granularity perhaps. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9E0AAD.2010708>