From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 7 16:22:54 2011 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE7A1065674 for ; Thu, 7 Apr 2011 16:22:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E348E8FC0C for ; Thu, 7 Apr 2011 16:22:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8348646B3C; Thu, 7 Apr 2011 12:22:53 -0400 (EDT) Received: from jhbmac.hudson-trading.com (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 09D588A01B; Thu, 7 Apr 2011 12:22:53 -0400 (EDT) Message-ID: <4D9DC1C6.4040700@FreeBSD.org> Date: Thu, 07 Apr 2011 09:53:10 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nate Lawson References: <201103281406.27334.jhb@freebsd.org> <201104061600.53572.jhb@freebsd.org> <4D9CE06C.3070002@root.org> In-Reply-To: <4D9CE06C.3070002@root.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 07 Apr 2011 12:22:53 -0400 (EDT) Cc: freebsd-acpi@freebsd.org Subject: Re: Atheros 9285 & Atheros AR8131 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:22:54 -0000 On 4/6/11 5:51 PM, Nate Lawson wrote: > On 4/6/2011 1:00 PM, John Baldwin wrote: >> On Monday, March 28, 2011 2:06:27 pm John Baldwin wrote: >>> We've never figured out what is zeroing the registers in the PCI-PCI bridges. >>> I suspect it is not something in the ASL, but is a side effect of some BIOS >>> code that runs in SMM when ACPI is turned on. >> >> Ok, so I have a patch to rework how PCI-PCI bridges manage resources for >> devices. This patch applies to HEAD, no idea if it applies to older branches >> (likely not). You will need to add the option 'NEW_PCIB' to your kernel >> config after applying this patch. >> >> http://www.FreeBSD.org/~jhb/patches/pcib_new.patch >> >> For my local testing I used a hack to wipe out the PCI-PCI bridges in my >> test machine similar to what the BIOS does on these machines. The bridges >> all grew windows to match their original BIOS-assigned windows based on the >> BIOS-assigned resources in the BARs of the child devices. >> >> These patches should also let us allocate new resources from scratch for >> devices behind PCI-PCI bridges once we have better support for determining what >> are valid PCI address ranges in the Host-PCI bridge drivers. > > 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). -- John Baldwin