From patchwork Mon Nov 13 15:46:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 118813 Delivered-To: patches@linaro.org Received: by 10.140.22.164 with SMTP id 33csp1944116qgn; Mon, 13 Nov 2017 07:46:53 -0800 (PST) X-Received: by 10.46.21.2 with SMTP id s2mr3328965ljd.71.1510588013166; Mon, 13 Nov 2017 07:46:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510588013; cv=none; d=google.com; s=arc-20160816; b=pkUuXwKX6fmDIgMpgP0p6ZU7SwBb3U66u5QilKO1uaAbzkESyGP/lr+EKojlWdrIDl JFL2jmPdVhycNFiKuwIk9qrh5ox6l6RhuTxf8WN4kTVfgsnGduUteab+cjbraAK+Kxo7 4irbD2FrUzhkT1g93azyKuCabTIBQQVkC/9tJwHj1UydZmv8PCl99mJyOt16nipHrM9t vpB2/MXzFhqk3tlejO0ab23gLGdiB+hLZ3q6hp6rkbLLTU5YdAMmKRO/HH1Ji0+TgVz5 xXL52ETPBMfiTRj37lsqfHPY9BBvHmfZPvTPd1RdhBrP00Q7YmdsmPu17z0lgjPy8qhV klKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=q76uhpKZu+7iy9TaqcGOp3GrOKELFVfIP/oorJUTTW8=; b=V9tmfKKmJV8dSX08Lhmes9iRIbLzm/QH3NT48ZN8GRrbYWGORIHCVGIjpnfrpDn/S7 2qPr2oqPbkxRTyVa/bgHOgR3U3M11bDR35J12K9DUpQglUI956pxqpE5IMuWSwJATt3Q mMs4EJRJ5bhs24Z4bgH2hIrxCNEpco3qY18p1vbzedXFs9jQCuIAX1Umw/NzHygiZRuq rpdPUjpmcuQRLix2Ix35fjQ0WNTtEQvFBMoxoInYhXYNBhHINqTZ47aU6TrsHs4Qg80/ RROH7ZI3nXre+bvvS0jD5ZVkZYUZeKkmPVj9MvtRcEglNd8qnGlLSzdqpNIqU/ENZMnw YDqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MRns2JXH; spf=pass (google.com: domain of ulf.hansson@linaro.org designates 209.85.220.41 as permitted sender) smtp.mailfrom=ulf.hansson@linaro.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r83sor2498943lfi.73.2017.11.13.07.46.53 for (Google Transport Security); Mon, 13 Nov 2017 07:46:53 -0800 (PST) Received-SPF: pass (google.com: domain of ulf.hansson@linaro.org designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MRns2JXH; spf=pass (google.com: domain of ulf.hansson@linaro.org designates 209.85.220.41 as permitted sender) smtp.mailfrom=ulf.hansson@linaro.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org 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=q76uhpKZu+7iy9TaqcGOp3GrOKELFVfIP/oorJUTTW8=; b=MRns2JXH7qN/WMvdBYBWxpRL6thFay3dBVqkquG/uGHny0tb4CE/Q3a0VCknM+4khQ KctIMlNJCkg25IwCKxbaAteM6fgoSp9hDk8mXBZ0tx5Mi8OAgIJHsRn3jAcu1SicUB5l 46FytBM0MbkeSi4UIgjpz/A1NFtfbrPcQGDXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=q76uhpKZu+7iy9TaqcGOp3GrOKELFVfIP/oorJUTTW8=; b=neByxk/mzS0nqf0gwSPio/LHyphohFW0vEE8g4RNZAgHKF0so7a0CghfP2U4z2ssMj 892G8+zpA/GD4F5FBlxwnm+N3UcLEvo8FGL94Po8xcHL0mA8Ng9pnNclqNHe454DCa+9 pzRFBIRs/VlMwdMQo4H1enqw67Ro0dl2dQkr3d3FWfalPw9YmWoyX5Yj1/1TUSxSHH9d CxGaxK19GG49KK36gs07FDIAloftKzcRUKomGh4YHDiEI/1hMx1plKXZTEIRFEP0qIJT WZi6vRcMwofsjmg3tCvWLJx8Y/VnzhCGG8zGBXCKkKq451vtCGXMBnP/er6yFzSPo+YC QNxA== X-Gm-Message-State: AJaThX50dXeY63ecrN4rwsTlOBECmYQsgUYUITsMJwuDvjOMq5dO7V6V ekYnOkC7M2AtVrpqso3GzQZq7bm1 X-Google-Smtp-Source: AGs4zMaY5fg0q1MpvIr6n8l1ap9znqhgVqJD9WmGkKgUeIBjRZx6thgOsUw2wQEAIbhg4eaHt0Fb7w== X-Received: by 10.25.41.143 with SMTP id p137mr12489lfp.56.1510588012642; Mon, 13 Nov 2017 07:46:52 -0800 (PST) Return-Path: Received: from localhost.localdomain (h-158-174-22-67.NA.cust.bahnhof.se. [158.174.22.67]) by smtp.gmail.com with ESMTPSA id m26sm177841ljb.61.2017.11.13.07.46.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Nov 2017 07:46:51 -0800 (PST) From: Ulf Hansson To: "Rafael J . Wysocki" , linux-pm@vger.kernel.org Cc: Kevin Hilman , Viresh Kumar , Geert Uytterhoeven , Simon Horman , Niklas Soderlund , linux-renesas-soc@vger.kernel.org, Ulf Hansson Subject: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag Date: Mon, 13 Nov 2017 16:46:42 +0100 Message-Id: <1510588003-16650-3-git-send-email-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1510588003-16650-1-git-send-email-ulf.hansson@linaro.org> References: <1510588003-16650-1-git-send-email-ulf.hansson@linaro.org> For some bus types and PM domains, it's not sufficient to only check the return value from device_may_wakeup(), to fully understand how to configure wakeup settings for the device during system suspend. In particular, sometimes the device may need to remain in its power state, in case the driver has configured it for in band IRQs, as to be able to generate wakeup signals. Therefore, define and document an IN_BAND_WAKEUP driver flag, to enable drivers to instruct bus types and PM domains about this setting. Of course, in case the bus type and PM domain has additional information about wakeup settings of the device, they may override the behaviour. Using the IN_BAND_WAKEUP driver flag for a device, may also affect how bus types and PM domains should treat the device's parent during system suspend. Therefore, in __device_suspend(), let the PM core propagate the wakeup setting by using a status flag in the struct dev_pm_info for the parent. This also makes it consistent with how the existing "wakeup_path" status flag is being assigned. Signed-off-by: Ulf Hansson --- Changes in v2: - Fixed comments from Rafael: - Rename flag to IN_BAND_WAKEUP. - Clarify doc and changelog. - Use a separate status flag when propagating to parents in PM core. - I didn't add Geert's Reviewed-by, because of new changes. --- Documentation/driver-api/pm/devices.rst | 11 +++++++++++ drivers/base/power/main.c | 8 +++++++- include/linux/pm.h | 6 ++++++ 3 files changed, 24 insertions(+), 1 deletion(-) -- 2.7.4 diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index 53c1b0b..b7fddf2 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -414,6 +414,17 @@ when the system is in the sleep state. For example, :c:func:`enable_irq_wake()` might identify GPIO signals hooked up to a switch or other external hardware, and :c:func:`pci_enable_wake()` does something similar for the PCI PME signal. +Sometimes :c:func:`device_may_wakeup(dev)` is not sufficient to understand how a +wakeup signal needs to be configured. Particularly, in some cases the driver +needs to instruct bus types and PM domains, that it has configured the device to +use an in-band wakeup setting, which may require the device to remain in its +power state to be able to generate wakeup signals. Therefore, drivers can set +``DPM_FLAG_IN_BAND_WAKEUP`` in :c:member:`power.driver_flags`, by passing the +flag to :c:func:`dev_pm_set_driver_flags` helper, which instructs bus types and +PM domains to use this configuration. However, the bus types and PM domains may +override this setting, in case they have additional information about wakeup +settings of the device. + If any of these callbacks returns an error, the system won't enter the desired low-power state. Instead, the PM core will unwind its actions by resuming all the devices that were suspended. diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 8089e72..8ec3189 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1432,8 +1432,11 @@ static void dpm_propagate_to_parent(struct device *dev) spin_lock_irq(&parent->power.lock); parent->power.direct_complete = false; - if (dev->power.wakeup_path && !parent->power.ignore_children) + if (dev->power.wakeup_path && !parent->power.ignore_children) { parent->power.wakeup_path = true; + parent->power.wakeup_path_in_band = + dev->power.wakeup_path_in_band; + } spin_unlock_irq(&parent->power.lock); } @@ -1547,6 +1550,8 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async) End: if (!error) { dev->power.is_suspended = true; + if (dev_pm_test_driver_flags(dev, DPM_FLAG_IN_BAND_WAKEUP)) + dev->power.wakeup_path_in_band = true; dpm_propagate_to_parent(dev); dpm_clear_suppliers_direct_complete(dev); } @@ -1671,6 +1676,7 @@ static int device_prepare(struct device *dev, pm_message_t state) device_lock(dev); dev->power.wakeup_path = device_may_wakeup(dev); + dev->power.wakeup_path_in_band = false; if (dev->power.no_pm_callbacks) { ret = 1; /* Let device go direct_complete */ diff --git a/include/linux/pm.h b/include/linux/pm.h index 65d3911..4efb16a 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -559,6 +559,7 @@ struct pm_subsys_data { * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device. * SMART_PREPARE: Check the return value of the driver's ->prepare callback. * SMART_SUSPEND: No need to resume the device from runtime suspend. + * WAKEUP_POWERED: Keep the device powered if it has wakeup enabled. * * Setting SMART_PREPARE instructs bus types and PM domains which may want * system suspend/resume callbacks to be skipped for the device to return 0 from @@ -572,10 +573,14 @@ struct pm_subsys_data { * necessary from the driver's perspective. It also may cause them to skip * invocations of the ->suspend_late and ->suspend_noirq callbacks provided by * the driver if they decide to leave the device in runtime suspend. + * + * Setting WAKEUP_POWERED instructs bus types and PM domains that the device + * needs to remain powered in system suspend, in case wakeup is enabled for it. */ #define DPM_FLAG_NEVER_SKIP BIT(0) #define DPM_FLAG_SMART_PREPARE BIT(1) #define DPM_FLAG_SMART_SUSPEND BIT(2) +#define DPM_FLAG_IN_BAND_WAKEUP BIT(3) struct dev_pm_info { pm_message_t power_state; @@ -595,6 +600,7 @@ struct dev_pm_info { struct completion completion; struct wakeup_source *wakeup; bool wakeup_path:1; + bool wakeup_path_in_band:1; bool syscore:1; bool no_pm_callbacks:1; /* Owned by the PM core */ #else