Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751606AbcCFQ7U (ORCPT ); Sun, 6 Mar 2016 11:59:20 -0500 Received: from netrider.rowland.org ([192.131.102.5]:58169 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751237AbcCFQ7J (ORCPT ); Sun, 6 Mar 2016 11:59:09 -0500 Date: Sun, 6 Mar 2016 11:59:07 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Laurent Pinchart cc: Ulf Hansson , Laurent Pinchart , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Kevin Hilman , Subject: Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended In-Reply-To: <2096023.P4Pq9IvUAO@avalon> 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: 1818 Lines: 39 On Sun, 6 Mar 2016, Laurent Pinchart wrote: > > >> What I was thinking though, but it might be a bit controversial. :-)... > > >> Instead of relying on whether we actually forced runtime suspend > > >> earlier, why couldn't we instead check the runtime PM usage count of > > >> the device? > > >> > > >> Only when it's greater than zero, we shall do the forced resume of the > > >> device, otherwise just re-enable runtime PM. > > >> > > >> This would have the affect of leaving devices in runtime suspend, > > >> until they really needs to be used again. It would thus decrease the > > >> total system PM resume time. > > >> > > >> Do you think this could work? > > > > > > If you do this then there would be no need for is_force_suspended. It > > > seems like a good idea to me. > > > > I agree, that's a better idea. Drivers shouldn't call > > pm_runtime_force_resume() if they haven't called pm_runtime_force_suspend(), > > so checking the PM use count should be fine. I'll modify the patch, test it > > and resubmit. > > I gave it an unfortunately unsuccessful try. The problem I ran into is that > device_prepare() calls pm_runtime_get_noresume() calls > pm_runtime_get_noresume(), with the corresponding pm_runtime_put() call being > performed in device_complete(). The device power usage_count is thus always > non-zero in the system resume handler, so I can't base the decision on that. You could check for usage_count > 1 instead of > 0. With a comment explaining why, of course. Alan Stern > I also noticed that pm_genpd_prepare() runtime-resumes the device (when the > power domain is in the GPD_STATE_ACTIVE state). I don't know why that is, but > it means that in practice my device gets runtime-resumed when suspending the > system while it could stay runtime-suspended in practice.