Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbcCGKKR (ORCPT ); Mon, 7 Mar 2016 05:10:17 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:33260 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752385AbcCGKKK (ORCPT ); Mon, 7 Mar 2016 05:10:10 -0500 MIME-Version: 1.0 In-Reply-To: <2096023.P4Pq9IvUAO@avalon> References: <1481433.r0tFS4sTcH@avalon> <2096023.P4Pq9IvUAO@avalon> Date: Mon, 7 Mar 2016 11:10:08 +0100 Message-ID: Subject: Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended From: Ulf Hansson To: Laurent Pinchart Cc: Alan Stern , Laurent Pinchart , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Kevin Hilman , linux-renesas-soc@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1154 Lines: 27 [...] >> 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. As Alan said, let's just check against 1 instead. > > 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. I am aware of this and it's on my TODO list of improvements of genpd, The issue is related to an unoptimized behaviour for how genpd deal with wakeups during system PM. Kind regards Uffe