Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752776AbbD3Ox5 (ORCPT ); Thu, 30 Apr 2015 10:53:57 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:43428 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752400AbbD3Oxh (ORCPT ); Thu, 30 Apr 2015 10:53:37 -0400 Date: Thu, 30 Apr 2015 10:53:35 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ulf Hansson cc: Tomeu Vizoso , Laurent Pinchart , "linux-pm@vger.kernel.org" , Dmitry Torokhov , "Rafael J. Wysocki" , Pavel Machek , Len Brown , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Kevin Hilman Subject: Re: [PATCH v3 1/2] PM / sleep: Let devices force direct_complete In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1838 Lines: 40 On Thu, 30 Apr 2015, Ulf Hansson wrote: > I hesitated to send this reply, since it might add confusion. If > that's the case, please ignore it. > > I have a long term vision to fully enable support for a runtime PM > centric configuration for drivers/subsystems. The idea is, that such > driver/subsystem should get system PM for "free". > > The main goal is to simplify PM implementation for these drivers/subsystems. > > They should need to implement the runtime PM callbacks only and not > the system PM ones. During system PM suspend, the requirement is that > the corresponding devices should be guaranteed to be "runtime PM > suspended". Somehow that then needs to be managed by the PM core. > > I am not sure it's doable, but I wanted to bring it up within the > context of $subject patch, since it proposes yet another optimization > path for runtime PM during system PM. I suspect it is _not_ doable. Consider a reasonable scenario: a driver that does pm_runtime_get_sync() in its open routine and pm_runtime_put() in its release routine. If a user process holds the device file open during a system suspend, it will be impossible for the PM core to do a runtime suspend. On the other hand, there's nothing to prevent drivers from setting their ->suspend and ->runtime_suspend structure members to point at the same routine. The routine would need to handle the case where it was called for a system suspend while the device was already runtime suspended, but that doesn't seem too hard. With the "direct-suspend" option, even this wouldn't be necessary. Alan Stern -- 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/