From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Stern Subject: Re: Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Mon, 8 Jun 2009 22:49:21 -0400 (EDT) Message-ID: References: <200906082331.58933.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200906082331.58933.rjw@sisk.pl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: "Rafael J. Wysocki" Cc: ACPI Devel Maling List , linux-pm@lists.linux-foundation.org, LKML List-Id: linux-pm@vger.kernel.org On Mon, 8 Jun 2009, Rafael J. Wysocki wrote: > > Use of the RPM_UNKNOWN state isn't good. A bus may have valid reasons > > of its own for not carrying out an autosuspend. When this happens the > > device's state isn't unknown. > > I'm not sure what you mean exactly. > > If ->autosuspend() fails, the device power state may be known, but the core > can't be sure if the device is active. This information is available to the > driver and/or the bus type, which should change the status to whatever is > appropriate. But no matter what the driver or bus type sets the state to, your pm_autosuspend() will change it to one of RPM_UNKNOWN or RPM_SUSPENDED. Neither might be right. > The name of this constant may be confusing, but I didn't have any better ideas. It's not clear what RPM_ACTIVE, RPM_IDLE, and RPM_SUSPENDED are supposed to mean; this should be documented in the code. Also, why isn't there RPM_RESUMING? By the way, a legitimate reason for aborting an autosuspend is if the device's driver requires remote wakeup to be enabled during suspend but the user has disabled it. > > The scheme doesn't include any mechanism for communicating runtime > > power information up the device tree. When a device is autosuspended, > > its parent's driver should be told so that the driver can consider > > autosuspending the parent. > > I thought the bus type's ->autosuspend() callback could take care of this. Shouldn't this happen after the device's state has changed to RPM_SUSPENDED? That's not until after the callback returns. > > There should be a sysfs interface (like the one in USB) to allow > > userspace to prevent a device from being autosuspended -- and perhaps > > also to force it to be suspended. > > To prevent a device from being suspended - yes. To force it to stay suspended > - I'm not sure. I'm not sure either. Oliver Neukum requested it originally and it has been useful for debugging, but I haven't seen many places where it would come in useful in practice. > > What about devices that have more than two runtime power states? For > > example, you can't squeeze PCI's {D0,D1,D2,D3hot} range into {running, > > suspended}. > > That has to be bus type-specific. > > In the case of PCI all of the low power states (D1-D3) are in fact substates of > "suspended", because we generally need to quiesce the device before putting > it into any of these states. > > I'm not sure if we can introduce more "levels of suspension", so to speak, at > the core level, but in any case we can easily distinguish between "device > quiesced and in a low power state" and "device fully active". > > So, in this picture the device is "suspended" from the core's point of view > once it's bus type's ->autosuspend() callback has been successfully executed. This too should be documented in the code. Or in a Documentation file. Alan Stern