From patchwork Thu Oct 13 14:58:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 77623 Delivered-To: patches@linaro.org Received: by 10.140.97.247 with SMTP id m110csp277291qge; Thu, 13 Oct 2016 07:59:12 -0700 (PDT) X-Received: by 10.25.134.139 with SMTP id i133mr10533660lfd.27.1476370752879; Thu, 13 Oct 2016 07:59:12 -0700 (PDT) Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com. [2a00:1450:4010:c07::236]) by mx.google.com with ESMTPS id y133si8768942lfc.134.2016.10.13.07.59.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 07:59:12 -0700 (PDT) Received-SPF: pass (google.com: domain of ulf.hansson@linaro.org designates 2a00:1450:4010:c07::236 as permitted sender) client-ip=2a00:1450:4010:c07::236; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: domain of ulf.hansson@linaro.org designates 2a00:1450:4010:c07::236 as permitted sender) smtp.mailfrom=ulf.hansson@linaro.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: by mail-lf0-x236.google.com with SMTP id l131so101677854lfl.2 for ; Thu, 13 Oct 2016 07:59:12 -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; bh=+C9pSW/e7o0IF2V4gLDnAJgmrQtBuuF3fmDtPgBin+0=; b=DFr63QgMVGoBQFqk5TktlLM0DdbPZf4fkX0lhYUhuokpvOKdEyHgkRd54+hCZMOE1W d+sNhPZNp22R7A9WzDYT8BNIWst184dOeGg69yp2xZfUZ2TdZROz9JljGe2dKTDjWRry VU34rCGJMp0W/CaOL5W9ghMeF2S3qwCMc+TSc= 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; bh=+C9pSW/e7o0IF2V4gLDnAJgmrQtBuuF3fmDtPgBin+0=; b=ZvUR2SUHqtZhKyh5ErFyEdbCP7JRxUoS4shlf3muqzMSRwMAQjYKaKI6WIIcvKB4Ck XC2DTeh+c/qqKrsEgbOc/rvTuKaRzI2xdISxekCiJckvqdFugYlcMxcEb/9vInW3ZmrI 2+kgjLek+8HgCenak3ifHGzwAdD9bkpxPaoY42XD6qRCUM5+MSWCWPhw0LxHgYczV3vj vhtH2x+BB47dvGnL5fyy9F2mLXexvWHwoLGLwaWQ3wyGsZxbczXg0WXWBJAj7TSbakXw WYbF8EWF3AAWdWrkvWWehDvo835qMRXvLuD29d5NDDLeLtivgz/hLf2IwmStm5u0rUP5 G6Mw== X-Gm-Message-State: AA6/9Rkmrln+8o06gHU/+8gWDZmxCNdcuLcaF9ZcGRm4JnQW/krDikGPTeWAU7N11n4XkxFaDY4= X-Received: by 10.25.27.69 with SMTP id b66mr10364386lfb.36.1476370750578; Thu, 13 Oct 2016 07:59:10 -0700 (PDT) Return-Path: Received: from localhost.localdomain (h-155-4-221-67.na.cust.bahnhof.se. [155.4.221.67]) by smtp.gmail.com with ESMTPSA id v62sm3965781lfa.44.2016.10.13.07.59.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 07:59:09 -0700 (PDT) From: Ulf Hansson To: "Rafael J. Wysocki" , Alan Stern , Ulf Hansson , linux-pm@vger.kernel.org Cc: Len Brown , Pavel Machek , Kevin Hilman , Geert Uytterhoeven , Lina Iyer , Jon Hunter , Marek Szyprowski , Andy Gross , Laurent Pinchart , Linus Walleij Subject: [PATCH V3] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Date: Thu, 13 Oct 2016 16:58:54 +0200 Message-Id: <1476370734-23168-1-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 1.9.1 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 --- Changes in v3: - Updated to take care of parent-child relations. - Improved comment in the code and updated text in a function header to better describe the changes. This patch has earlier been sent standalone, but also as a part of series. In the end it turned out the solution needed some improvement to take care of parent-child relations, as reported by Geert [1]. Geert, I would really appreciate if you could help out testing to make sure the reported issue is fixed. [1] https://patches.linaro.org/patch/67940/ --- drivers/base/power/runtime.c | 35 ++++++++++++++++++++++++++++++----- 1 file changed, 30 insertions(+), 5 deletions(-) -- 1.9.1 Tested-by: Marek Szyprowski Tested-by: Geert Uytterhoeven Acked-by: Kevin Hilman diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index e097d35..f662267 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -1478,6 +1478,16 @@ int pm_runtime_force_suspend(struct device *dev) if (ret) goto err; + /* + * Increase the runtime PM usage count for the device's parent, in case + * when we find the device being used when system suspend was invoked. + * This informs pm_runtime_force_resume() to resume the parent + * immediately, which is needed to be able to resume its children, + * when not deferring the resume to be managed via runtime PM. + */ + if (dev->parent && atomic_read(&dev->power.usage_count) > 1) + pm_runtime_get_noresume(dev->parent); + pm_runtime_set_suspended(dev); return 0; err: @@ -1487,16 +1497,20 @@ err: EXPORT_SYMBOL_GPL(pm_runtime_force_suspend); /** - * pm_runtime_force_resume - Force a device into resume state. + * pm_runtime_force_resume - Force a device into resume state if needed. * @dev: Device to resume. * * Prior invoking this function we expect the user to have brought the device * into low power state by a call to pm_runtime_force_suspend(). Here we reverse - * those actions and brings the device into full power. We update the runtime PM - * status and re-enables runtime PM. + * those actions and brings the device into full power, if it is expected to be + * used on system resume. To distinguish that, we check whether the runtime PM + * usage count is greater than 1 (the PM core increases the usage count in the + * system PM prepare phase), as that indicates a real user (such as a subsystem, + * driver, userspace, etc.) is using it. If that is the case, the device is + * expected to be used on system resume as well, so then we resume it. In the + * other case, we defer the resume to be managed via runtime PM. * - * Typically this function may be invoked from a system resume callback to make - * sure the device is put into full power state. + * Typically this function may be invoked from a system resume callback. */ int pm_runtime_force_resume(struct device *dev) { @@ -1513,6 +1527,17 @@ int pm_runtime_force_resume(struct device *dev) if (!pm_runtime_status_suspended(dev)) goto out; + /* + * Decrease the parent's runtime PM usage count, if we increased it + * during system suspend in pm_runtime_force_suspend(). + */ + if (atomic_read(&dev->power.usage_count) > 1) { + if (dev->parent) + pm_runtime_put_noidle(dev->parent); + } else { + goto out; + } + ret = pm_runtime_set_active(dev); if (ret) goto out;