Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755712AbZFTXsZ (ORCPT ); Sat, 20 Jun 2009 19:48:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752571AbZFTXsR (ORCPT ); Sat, 20 Jun 2009 19:48:17 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:50535 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752488AbZFTXsQ (ORCPT ); Sat, 20 Jun 2009 19:48:16 -0400 From: "Rafael J. Wysocki" To: Alan Stern Subject: Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O devices Date: Sun, 21 Jun 2009 01:48:56 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-rjw; KDE/4.2.4; x86_64; ; ) Cc: Magnus Damm , Greg KH , LKML , ACPI Devel Maling List , "Linux-pm mailing list" , Ingo Molnar References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906210148.57199.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2158 Lines: 48 On Saturday 20 June 2009, Alan Stern wrote: > Some more thoughts... > > Magnus, you might have some insights here. It occurred to me that some > devices can switch power levels very quickly, and the drivers might > therefore want the runtime suspend and resume methods to be called as > soon as possible, even in interrupt context. Then, we'll need special suspend and resume calls for them. > In terms of the current framework, this probably means holding the > runtime PM lock (i.e., not releasing it) across the calls to > ->runtime_suspend and ->runtime_resume. It also means that > pm_request_suspend and pm_request_resume should carry out their jobs > immediately instead of queuing a work item. (Unless the current status > is RPM_SUSPENDING or RPM_RESUMING, which should never happen.) > > Should there be a flag in dev_pm_info to select this behavior? I don't think we should complicate pm_request_suspend() and pm_request_resume() further to handle this particular case. IMO it's better to provide separate core calls for that. > When a device structure is unregistered and deallocated, we have to > insure that there aren't any pending runtime PM workqueue items. > Hence device_del should call a routine that changes the status to an > exceptional state (not RPM_ERROR but something else) to prevent new > requests from being queued, and then calls cancel_work_sync or > cancel_delayed_work_sync as required. This is done in the patch I've just sent. > Similarly, we should insure that runtime PM calls made before the > device is registered don't do anything. So when the device structure > is first created and the contents are all 0, this should also be > interpreted as an exceptional state. We could call it RPM_UNREGISTERED > and use it for both purposes. Hmm. How do you think is possible that the pm_runtime_* functions will be called in such a situation? Best, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/