From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 07:29:27 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C031A16A4CE for ; Wed, 24 Nov 2004 07:29:27 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F37943D2F for ; Wed, 24 Nov 2004 07:29:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAO7TTp8022296; Wed, 24 Nov 2004 02:29:29 -0500 Message-ID: <41A4384F.1070003@root.org> Date: Tue, 23 Nov 2004 23:29:19 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <419EF7AD.8050007@root.org> <20041121.082812.116352579.imp@bsdimp.com> In-Reply-To: <20041121.082812.116352579.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 07:29:27 -0000 M. Warner Losh wrote: > In message: <419EF7AD.8050007@root.org> > Nate Lawson writes: > : The attached patch implements setting power states for ACPI (i.e. ISA) > : and PCI devices in the suspend/resume path. This may help with some > : problems; it's quite likely it may introduce problems. That's why I'd > : like it tested. If you have a system that suspends/resumes ok or that > : fails, please try it. The likely failure case is a hang in suspend or > : resume or a device that doesn't work afterwords. It's pretty > : heavy-handed, only avoiding changing power for serial ports since those > : are known to cause a hang (which can possibly be fixed by making > : sio/uart more aware of power states.) I suspect devices like PCI > : bridges may have problems with power changes. > : > : If you have problems, please let me know the info it prints before the > : hang so I can figure out what the problem device is. > > I suspect that we'll need finer grain control over the APM case. For > APM Bioses, the OS isn't supposed to put devices into lower power > states. The APM BIOS generally does this and restores things on > resume. APM is somewhat more limited in what it can do, so this makes > sense. Right, I agree. I've simply moved setting the power state under the acpi-only case to handle apm. > /* > - * Save the pci configuration space for each child. We don't need > - * to do this, unless the BIOS suspend code powers down the bus and > - * the devices on the bus. > + * Save the PCI configuration space for each child and set the > + * device in the appropriate power state for this sleep state. > */ > > So if APM implemented the ACPI_PWR_FOR_SLEEP interface, we'd be set. > However, there's at leas two problems with this. One is that we don't > have a way to get the 'power management' device generically (witness > the hacks to get acpi in generic pci code). Second, we don't have a > generic power interface, so having APM implement ACPI_ named methods > seems a little unsatisfying at best. I'm not sure what powermacs do > for their PM stuff, but I'm pretty sure it isn't acpi. The OS should not be setting Dx states on devices if running under APM mode. Currently, we only have 2 power management systems, apm and acpi. I don't know the PowerPC way but suspect it's largely handled by OpenFirmware, which makes it behave similar to APM, and fits nicely with the !acpi case there. Nothing I'm doing rules out a more general solution once someone implements PowerPC PowerMANAGEMENT. -Nate