Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Apr 2011 10:25:31 -0700
From:      Nate Lawson <nate@root.org>
To:        freebsd-acpi@freebsd.org
Subject:   Re: Atheros 9285 & Atheros AR8131
Message-ID:  <4D9DF38B.8050703@root.org>
In-Reply-To: <4D9DC1C6.4040700@FreeBSD.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
Nate




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9DF38B.8050703>