Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755849AbZFLXGr (ORCPT ); Fri, 12 Jun 2009 19:06:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752096AbZFLXGj (ORCPT ); Fri, 12 Jun 2009 19:06:39 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:60258 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbZFLXGi (ORCPT ); Fri, 12 Jun 2009 19:06:38 -0400 From: "Rafael J. Wysocki" To: Alan Stern Subject: Re: [patch update] Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Sat, 13 Jun 2009 01:06:57 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-rc8-rjw; KDE/4.2.4; x86_64; ; ) Cc: Oliver Neukum , "Linux-pm mailing list" , ACPI Devel Maling List , LKML 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: <200906130106.58464.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3093 Lines: 71 On Friday 12 June 2009, Alan Stern wrote: > On Fri, 12 Jun 2009, Rafael J. Wysocki wrote: > > > On Friday 12 June 2009, Alan Stern wrote: > > > On Fri, 12 Jun 2009, Rafael J. Wysocki wrote: > > > > > > > So, are you suggesting that the core should only check the "all children > > > > suspended" condition if special flag is set in dev_pm_info? > > > > > > Or rather, check it only if the special flag _isn't_ set. > > > > Where the default is unset, I guess? > > Yep. > > > But then, what about the resuming of the parents before the device is resumed? > > Should the parents be resumed regardless of the flag state? > > Yes. In general you should assume a device's parent (and the device > itself!) needs to be resumed whenever the kernel wants to do something > with the device. The special flag arises because sometimes it's safe > to suspend the parent without suspending the device _if_ the kernel > isn't using the device. > > Imagine an idle disk at the end of a link. We might want to > autosuspend the link without spinning down the disk. When we have to > communicate with the disk again, we autoresume the link. (Including > the case where the communication is a "spin-down" command.) > > > And if so, what's > > the condition for breaking the recurrence? Surely it's not sufficient to check > > if the parent is active, because its parent need not be active if it has this > > special flag set. > > That's a good question. Let's assume that situations like this will be > handled by the drivers. > > For example, suppose A is the parent of B is the parent of C, and A is > suspended but B isn't and C is. What happens when somebody wants to > use C? > > An autoresume request is generated for C. Since C's parent is already > resumed, the runtime_resume method in C's driver is called. The driver > has to do some I/O in order to resume C, so it passes an I/O request up > to B's driver. The request then gets passed up to A's driver. This > driver knows that A is suspended, so it starts an autoresume of A and > waits for the autoresume to complete before carrying out the request. > > Then the I/O can go through, so C gets resumed and everything works > out. > > I don't know how often this sort of pattern will arise. It certainly > could be used in usb-storage; there would be no difficulty starting an > autoresume when an I/O request arrives from the SCSI layer below. In > fact, that is exactly how some early runtime-PM patches for usb-storage > worked. So, the conclusion seems to be that we should break the recurrence at the point we find an already active device or a device with no parent and let the driver(s) handle the more complicated cases. Is this correct? BTW, is __device_release_driver() the right place for blocking the run-time PM temporarily during remove? 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/