From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [patch update] Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Thu, 11 Jun 2009 21:43:56 +0200 Message-ID: <200906112143.57361.rjw@sisk.pl> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from ogre.sisk.pl ([217.79.144.158]:53802 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753305AbZFKTnV (ORCPT ); Thu, 11 Jun 2009 15:43:21 -0400 In-Reply-To: Content-Disposition: inline Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Alan Stern Cc: Oliver Neukum , Linux-pm mailing list , ACPI Devel Maling List , LKML On Thursday 11 June 2009, Alan Stern wrote: > On Thu, 11 Jun 2009, Rafael J. Wysocki wrote: > > > The point here is what the core is supposed to do. Does it need to handle > > this at all or leave it to the bus type and driver? > > > > After reconsidering it for a while I think that we should define what > > "suspended" is supposed to mean from the core point of view. And my opinion > > is that it should mean "device doesn't communicate with the CPUs and RAM due > > to power management". That need not be power management of the device itself, > > but such that leads to the device not doing I/O. > > > > Under this definition all devices behind an inactive link are suspended, > > because they can't do any I/O. Which appears to makes sense, because their > > drivers have to be notified before the link is suspended and the link has to be > > turned on for the devices to be able to communicate with the CPU and RAM. > > > > If this definition is adopted, then it's quite clear that the device can only > > be suspended if all of its children are suspended and it's always necessary > > to resume the parent of a device in order to resume the device itself. > > Okay, I'll agree to that. It should be made clear that a device which > is "suspended" according to this definition is not necessarily in a > low-power state. For example, before powering down the link to a disk > drive you might want the drive's suspend method to flush the drive's > cache, but it wouldn't have to spin the drive down. Exactly. > (But this example leaves open the question of how we would go about > spinning down the disk. Submitting a 15-minute (or whatever) delayed > autosuspend request wouldn't work; the request wouldn't be accepted > because the disk is already suspended as far as the PM core is > concerned. The disk's driver would have to implement its own > spin-down delayed_work.) Yes, it would. > > > > > I haven't checked the details of the code yet. More later... > > > > > > One more thought... The autosuspend and autoresume callbacks need to > > > be mutually exclusive with probe and remove. So somehow the driver > > > core will need to block runtime PM calls. > > > > That's correct and I'm going to take care of this. > > > > > It might also be nice to make sure that the driver core autoresumes a > > > device before probing it and autosuspends a device (after some > > > reasonable delay) after unbinding its driver. > > > > Agreed. > > This is another case where a usage counter comes in handy. The driver > core resumes the device and increments the counter -- thus preventing > any unwanted autosuspends -- before making the probe and remove calls. I like this idea. BTW, where exactly the counter should be increased in that case? I thought of driver_probe_device(), but is it sufficient? Or is there a better place? Best, Rafael