Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755235AbZFULc3 (ORCPT ); Sun, 21 Jun 2009 07:32:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753090AbZFULcV (ORCPT ); Sun, 21 Jun 2009 07:32:21 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:51500 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751261AbZFULcU (ORCPT ); Sun, 21 Jun 2009 07:32:20 -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 13:32:45 +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: <200906211332.46249.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2171 Lines: 50 On Sunday 21 June 2009, Alan Stern wrote: > On Sun, 21 Jun 2009, Rafael J. Wysocki wrote: > > > 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. > > Good idea. pm_runtime_resume_atomic() and pm_runtime_suspend_atomic(). > No need for _request variants since the status should never be > RPM_SUSPENDING or RPM_RESUMING while the lock is released. Yes, exactly. I also thought of the same names. :-) > > > 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? > > By mistake. :-) > > Seriously, there _are_ places where drivers get bound to device before > those devices are registered. This happens for example in USB when a > bunch of related interfaces are present in the same physical device. > When the first interface is registered, its driver binds itself to all > the others even though they haven't been registered yet. Well, the suspend functions could be protected against that under the assumption that no suspend is possible for resume_counter = 0 (then, the "good to go" value would be -1). Still, the resume functions start from acquring a spinlock, which is not going to work if that spinlock is uninitialized. 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/