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: Sat, 13 Jun 2009 01:06:57 +0200 Message-ID: <200906130106.58464.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]: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 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 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