From owner-freebsd-current@FreeBSD.ORG Fri Dec 5 15:31:49 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5A9E16A4CE; Fri, 5 Dec 2003 15:31:49 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD32F43FE0; Fri, 5 Dec 2003 15:31:47 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id hB5NVAT4005184; Fri, 5 Dec 2003 16:31:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 05 Dec 2003 16:30:32 -0700 (MST) Message-Id: <20031205.163032.04658870.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20031205103549.Y27123@root.org> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi-jp@jp.FreeBSD.org cc: brendon.humphrey@boeing.com cc: wendy.humphrey@comcast.net cc: freebsd-current@freebsd.org Subject: Re: [acpi-jp 2851] Re: Compaq Presario 2105US ACPI = NO MOUSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2003 23:31:50 -0000 In message: John Baldwin writes: : : On 05-Dec-2003 Nate Lawson wrote: : > My first order of business after 5.2R will be to import acpica 20031203. : > It has a lot of fixes in it that may take care of marginal AML. After : > that, I'll be adding code to call _PSx on ACPI-attached devices (not PCI, : > that's in imp's tree). This may initialize your hw properly. : : Hey, I'd actually like some thoughts on the power stuff in the p4 power : tree. I want to remove my cruft to just mess with _PSx since the : power resource code is much more mature and just use that from the PCI : drivers. For that to work correctly however, we will need to perhaps : do a pass over the ACPI tree early on (before child PCI bus devices are : attached I think) that registers all the producers and consumers. I think that's right, but something sounds odd about it. : We also might want to fix the register functions to use _PSC if it : is available to determine the current power state and then add code : to power consumers on before we probe/attach them. Note that with : the current power resource code, this would only call _PS0 if it : really needed to be called. I've been running with the 'bare' pci part of the power code in my tree for some time now. Devices that are in power states other than D0 are brought to D0 (after saving the config space and restoring it as required in the spec). Devices taht don't attach (or later detach) get powered down to D3, if they support it. Adding additional calls to the ACPI stuff wouldn't be hard, but hasn't been a priority for me. Warner