From patchwork Mon May 30 09:33:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 9140793 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5065060759 for ; Mon, 30 May 2016 09:33:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 40E37281B4 for ; Mon, 30 May 2016 09:33:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 358D228212; Mon, 30 May 2016 09:33:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8078281B4 for ; Mon, 30 May 2016 09:33:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932141AbcE3Jde (ORCPT ); Mon, 30 May 2016 05:33:34 -0400 Received: from mail-lf0-f53.google.com ([209.85.215.53]:34651 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932219AbcE3Jdc (ORCPT ); Mon, 30 May 2016 05:33:32 -0400 Received: by mail-lf0-f53.google.com with SMTP id k98so69928199lfi.1 for ; Mon, 30 May 2016 02:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=NnTD/u+5/3U1R3g8QuGriEbst4xXhUwI20Nz/83Ta8M=; b=h+D6wFmGqTErYjVdoz5VJtc4B2fnbgaGkuB1af2/2Rl1A71dtdELBptC5ZWUtAxtr1 29uFWukajvmj6Mjm186jeSynfVqVmzVGUBQ5ybl8DnQYIooofuM1ediEbxuyYeukT0AR flNxK76gsRVyNfPR6uDoepR+segGZ3BFldkgA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=NnTD/u+5/3U1R3g8QuGriEbst4xXhUwI20Nz/83Ta8M=; b=Lp33RudvKTnPgeJu1ZbboKQL07bOc31C1qwk1VpxGWMUSeiy0Hg1MbrA6FlwcbMw6E remz9CvH4uWWyuzMdteV7k1J0Nt5kV4q5sqLkjayoW0LfwbkVZ9SkwiNJo8r3bHGYhDw nn5y5UcfVD+N2ZQ9OYsFJLpwPZaQ+EWStb+yFiIc+IQm0xo4Q51yud75tyklx9ePjP0D J8TLdAm/Y0d0j18UoJLRg8UHznSnbtEa6PbWCYZqYiN3A+mAC6BFjveYdnjUm0FtxpHC PQOFY/cfPUQ3Xtr2qYYJxT0zo4d+Wncfw4J+Cfl/ESmn8YD0THsN9uCCxsKCmH9DpAq0 +l6g== X-Gm-Message-State: ALyK8tLS+xSFeYzXaxqdjy7zFYL5YC8qs/BzaNSSg8HkhvkI7vHp4bgJ0ZXHUoJh3CKyey4s X-Received: by 10.25.133.10 with SMTP id h10mr338587lfd.28.1464600811111; Mon, 30 May 2016 02:33:31 -0700 (PDT) Received: from uffe-Latitude-E6430s.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id 75sm4596853lfw.25.2016.05.30.02.33.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 02:33:29 -0700 (PDT) From: Ulf Hansson To: "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , linux-pm@vger.kernel.org Cc: Len Brown , Pavel Machek , Geert Uytterhoeven , Lina Iyer , Axel Haslam , Marek Szyprowski , Jon Hunter , Andy Gross , Laurent Pinchart Subject: [PATCH v2 5/5] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Date: Mon, 30 May 2016 11:33:15 +0200 Message-Id: <1464600795-26307-6-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1464600795-26307-1-git-send-email-ulf.hansson@linaro.org> References: <1464600795-26307-1-git-send-email-ulf.hansson@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When the pm_runtime_force_suspend|resume() helpers were invented, we still had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options. To make sure these helpers worked for all combinations and without introducing too much of complexity, the device was always resumed in pm_runtime_force_resume(). More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was unset, we needed to resume the device as the subsystem/driver couldn't rely on using runtime PM to do it. As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it removed this combination, of using CONFIG_PM_SLEEP without the earlier CONFIG_PM_RUNTIME. For this reason we can now rely on the subsystem/driver to use runtime PM to resume the device, instead of forcing that to be done in all cases. In other words, let's defer the runtime resume to a later point when it's actually needed. Signed-off-by: Ulf Hansson Reviewed-by: Kevin Hilman --- Changes in v2: - Updated changelog. - Updated comment in the code. --- drivers/base/power/runtime.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 09e4eb1..81731a2 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev) if (!pm_runtime_status_suspended(dev)) goto out; + /* + * The PM core increases the runtime PM usage count in the system PM + * prepare phase. If the count is greater than 1 at this point, a real + * user (such as a subsystem, driver, userspace, etc.) has also + * increased it, indicating that the device was used when system suspend + * was invoked. In this case, the device is expected to be used on + * system resume as well, so invoke the ->runtime_resume() callback. + */ + if (atomic_read(&dev->power.usage_count) < 2) + goto out; + ret = pm_runtime_set_active(dev); if (ret) goto out;