From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aisheng Dong Subject: RE: [PATCH 1/2] PM / Domains: Support enter deepest state for multiple states domains Date: Wed, 6 Mar 2019 15:36:27 +0000 Message-ID: References: <1551878926-8455-1-git-send-email-aisheng.dong@nxp.com> <1551878926-8455-2-git-send-email-aisheng.dong@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Ulf Hansson Cc: "dongas86@gmail.com" , "khilman@kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , dl-linux-imx , "linux-arm-kernel@lists.infradead.org" List-Id: linux-pm@vger.kernel.org > From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > Sent: Wednesday, March 6, 2019 11:18 PM> > On Wed, 6 Mar 2019 at 14:35, Aisheng Dong > wrote: > > > > Currently the generic power domain will power off the domain if all > > devices in it have been stopped during system suspend. > > > > It is done by checking if the domain is active in > > genpd_sync_power_off, then disable it. However, for power domains > > supporting multiple low power states, it may have already entered an > > intermediate low power state by runtime PM before system suspend and > > the status is already GPD_STATE_POWER_OFF which results in then the > > power domain stay at an intermediate low power state during system > suspend. > > Then genpd_sync_power_off will keep it at the low power state instead > > of completely gate off it. > > I agree that this could be a concern. However, before we look for a solution, do > you have practical use case where you observes this? > Yes, this solution[1] is used by NXP internally for former releases that we have two Level states for power Domains[2]. We use state 0 (Low Power Mode with state retention) for device runtime pm support and state 1 (power off with no state retention) for system suspend resume case. Without [1], we will meet the issue that all domains runtime suspended will stay at low power mode instead of power off during system suspend which consumes more power. 1. https://source.codeaurora.org/external/imx/linux-imx/log/drivers/base/power?h=imx_4.14.78_1.0.0_ga 2. https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/soc/imx/pm-domains.c?h=imx_4.14.78_1.0.0_ga#n325 > > > > Let's give the power domain a chance to switch to the deepest state in > > case it's already off but in an intermediate low power state. > > > > Signed-off-by: Dong Aisheng > > --- > > drivers/base/power/domain.c | 18 +++++++++++++++++- > > include/linux/pm_domain.h | 1 + > > 2 files changed, 18 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > > index 61cd500..847a69e 100644 > > --- a/drivers/base/power/domain.c > > +++ b/drivers/base/power/domain.c > > @@ -959,7 +959,17 @@ static void genpd_sync_power_off(struct > > generic_pm_domain *genpd, bool use_lock, { > > struct gpd_link *link; > > > > - if (!genpd_status_on(genpd) || genpd_is_always_on(genpd)) > > + /* > > + * Give the power domain a chance to switch to the deepest state > in > > + * case it's already off but in an intermediate low power state. > > + */ > > + genpd->state_idx_saved = genpd->state_idx; > > + > > + if (genpd_is_always_on(genpd)) > > + return; > > + > > + if (!genpd_status_on(genpd) && > > + genpd->state_idx == (genpd->state_count - 1)) > > return; > > This means that the ->power_off() callback may be called twice in a raw, for > the genpd in question and in cases of multiple idle states. > It could be a problem. > > Well, currently it may not be a real issue, as I doubt there is rather few genpd > backend drivers supporting multiple idle states, but still. > So far, I've no idea what the problem could be as there's no multi states power domain drivers in tree. For IMX, there's no problem as the driver could handle it well. The core code just provides an interface for driver to handle such requirement. Do you know who else using such power domain with multi states? I guess TI, but did not see their code in tree. > > > > if (genpd->suspended_count != genpd->device_count) @@ -970,6 > > +980,9 @@ static void genpd_sync_power_off(struct generic_pm_domain > *genpd, bool use_lock, > > if (_genpd_power_off(genpd, false)) > > return; > > > > + if (genpd->status == GPD_STATE_POWER_OFF) > > + return; > > + > > genpd->status = GPD_STATE_POWER_OFF; > > > > list_for_each_entry(link, &genpd->slave_links, slave_node) { > > @@ -1017,6 +1030,9 @@ static void genpd_sync_power_on(struct > > generic_pm_domain *genpd, bool use_lock, > > > > _genpd_power_on(genpd, false); > > > > + /* restore save power domain state after resume */ > > + genpd->state_idx = genpd->state_idx_saved; > > + > > genpd->status = GPD_STATE_ACTIVE; } > > > > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h > > index 1ed5874..95db21f 100644 > > --- a/include/linux/pm_domain.h > > +++ b/include/linux/pm_domain.h > > @@ -124,6 +124,7 @@ struct generic_pm_domain { > > }; > > }; > > > > + unsigned int state_idx_saved; /* saved power state for > > + recovery after system suspend/resume */ > > }; > > > > static inline struct generic_pm_domain *pd_to_genpd(struct > > dev_pm_domain *pd) > > -- > > 2.7.4 > > > > I need to think about this a bit more, let me get back to you. > Thanks for the help. Regards Dong Aisheng > Kind regards > Uffe From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C89EC43381 for ; Wed, 6 Mar 2019 15:36:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D36CE20840 for ; Wed, 6 Mar 2019 15:36:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fjj54Vha"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=nxp.com header.i=@nxp.com header.b="YPqGdriw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D36CE20840 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nxp.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SgCvR1vR/csE1PcNvk+W0BCaGIR8/uizzYkvUe3cyaM=; b=fjj54VhafNkVFn WrOv/55Z5JHyH5Kngc8NYSHRxF0kODERHJeZi9eKqw36TmiEQSF++LqLqNmUOvxJxde5VSJAjY8t6 a+bHX4XGHRtEL+OnqYqnarjDLdnrsPlWrV1kA7ud7EoFJRTfda+HP0+PbUViP/FSWaOnfyOlVqadI U4QABFhvUmLxkRYoyWxvin5qrTvIfj1ZXlo7kTJFwBUXN7YRwtUiB3QyqMJRVM6X5pEir5e9CtPxQ p6NLBsM1/YhXoGING+FFYGPXrOnJHSacRTr8kXM926rbUDiptAwcDu/44bYr21IovBj3MVjQVOIBN PrpmEFCwIMkhWwyFZEuQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h1Yb1-0001LR-1Z; Wed, 06 Mar 2019 15:36:39 +0000 Received: from mail-eopbgr40066.outbound.protection.outlook.com ([40.107.4.66] helo=EUR03-DB5-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h1Yas-00019P-Gq for linux-arm-kernel@lists.infradead.org; Wed, 06 Mar 2019 15:36:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B1QFWYhA/DY+hcIRmQDMbt05DaQ063O0BV39ZTm/v/M=; b=YPqGdriw7shjxJt1PyCCSmHrbZG0CRmZdMxH48efE/5vzOHwmzpM0zI8bcpz570AvZN58aFt/CVvZW38vWBQv7dKRE4BWqYk4LWpJjiphKF41gRJKhskeTw0liprtl1CAu19CX7an3HLTrL+4R3lgsLPRSVU4L9n2AziuPTdlls= Received: from AM0PR04MB4211.eurprd04.prod.outlook.com (52.134.92.158) by AM0PR04MB4274.eurprd04.prod.outlook.com (52.134.124.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.17; Wed, 6 Mar 2019 15:36:27 +0000 Received: from AM0PR04MB4211.eurprd04.prod.outlook.com ([fe80::50ed:d1b5:c043:3b79]) by AM0PR04MB4211.eurprd04.prod.outlook.com ([fe80::50ed:d1b5:c043:3b79%2]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 15:36:27 +0000 From: Aisheng Dong To: Ulf Hansson Subject: RE: [PATCH 1/2] PM / Domains: Support enter deepest state for multiple states domains Thread-Topic: [PATCH 1/2] PM / Domains: Support enter deepest state for multiple states domains Thread-Index: AQHU1CFx3mZA+LLWq0ehzswGR+73hKX+tzcAgAABSYA= Date: Wed, 6 Mar 2019 15:36:27 +0000 Message-ID: References: <1551878926-8455-1-git-send-email-aisheng.dong@nxp.com> <1551878926-8455-2-git-send-email-aisheng.dong@nxp.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=aisheng.dong@nxp.com; x-originating-ip: [101.93.238.110] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a059453-9568-4054-0db3-08d6a2497f82 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR04MB4274; x-ms-traffictypediagnostic: AM0PR04MB4274: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA0TUI0Mjc0OzIzOi85bldVRkR4NkhUUis2eE5LR0lVbFdTTDVh?= =?utf-8?B?cFRGMGtWUEo5dlFYcjNSalJxUkdpbkd4ZnBDUFFWTnJ1Wkk5OStFVnRIMlJv?= =?utf-8?B?STVvSGlRNlNoVGJtMXh3RG1uN3dIREEyNFpRZi9HSklCdmc4U0liNmhhVHJM?= =?utf-8?B?eVI0SndQK0s3ZFBoWHZPVTFYOExQUkZ3d3QvZGpET0RFVENzb2JsYmVZZGFq?= =?utf-8?B?aEtoWW4yVVE2dzFLWVJ4OXBtRjkxc0hhcThVK1FlRFdtTG00TlFGMm1VNGp2?= =?utf-8?B?ZkJXUWFpYTVlUUNpN01DZ1J6RXFCRUdlQ2poVmJ5OVU2bjA1WVY0S0xhak9l?= =?utf-8?B?NEI0aHJCYld2K1NyeThROFJ6VWFKb2VETERkdkxFRytnNFF3UlZtcUk5YjhQ?= =?utf-8?B?Z2FWTkVxOUxPS1ozWkJ5RnZROFJMaFdXQWRwY3piMG03dDJmSmRWd0Ywb01x?= =?utf-8?B?NjgzRXRZSUUyS1QwSWJUV3ZQUUlPNXpwNjFLR2daWFQzZ3I4UkRuWUdEOUc4?= =?utf-8?B?aUxmRFNHeC9IT0hPK1NIRFBGc0VvSXdHemVuY1dBRGxIeS9RbTR1cklaSkRs?= =?utf-8?B?R2RlSzZmdWRaaWx2VkNUbCsyZ1cvcFI3SnVlM3hGRGt4L1J0elZlSEhQM1Nl?= =?utf-8?B?dkNHVmRHYmh4ZFRUazFJMEZZK1h1VFRHYy9xY3RDd0FKbXJicW1FekoxRW53?= =?utf-8?B?aHBUMVRLMWdqamRkOHdhVFRjRlNjUDFtM3JqZndBU20vdkh0OVVnVmFRSW13?= =?utf-8?B?S3c3cHNtdXNjRmZYbFB4Y2FOOU9WVDlzeWFHTHg2cjFWU3BXWWUwM3N1WFR3?= =?utf-8?B?WVBGMXAxRFhlN0d1Ylc1enlCdHp6NXdyL2FyMUpjUkFnTnhYU3BHSkJPOENq?= =?utf-8?B?c0pjVnFsVWExaW54VEpYcE5ld1hHdzZ4NndxeS9KUFpkWUU4TFlFSjMzNDc5?= =?utf-8?B?OTdHazhCY0M2d0tRa1RZeGVZT1VoZDZsSHAwaFJwak42TFJ5M2NuS2RCRFlh?= =?utf-8?B?Y0l2akJPRUlaQTU4WDlINjEyYmFaUC9tYkJZOFJYRi9XSnpZTUF1WFdFQTNJ?= =?utf-8?B?MkZ3VDVKbWJpTklSdU51SnV3Q0RhdVdUQXhiMGhMZUIzOHRLelgxWkU4eUVr?= =?utf-8?B?dW0yZnRsRnYvTkZ6KzkxSjlCTVg3THRoa243MGIvQUM4QlVBb25IWldST2Zs?= =?utf-8?B?N3Y0dDVsOW5lQ0h6T2x3UjgzTE9pa0hEaXNqV2NxZGZaMjBpYzc5c0VmT3pi?= =?utf-8?B?ck1XYWt4MUpxOTlRSm4xYmxPZG9wdFdkR1hhdEd5NGlGSkFad25peWVPcjRs?= =?utf-8?B?VklMTFEyRjJFK0tXU2pBVGc4RFBLTnhsbEEzeHJGYTQrempTRGVHVEJKTEdO?= =?utf-8?B?cVpFSjVSZnQxY25EOHE1VFh0V25hSnlsSWNXTFpuYXZNZHdoWEVieU9ja0lD?= =?utf-8?B?a2R3bzNldnZBUWE5L01PNTU5SU9qUzlkUVAvQ0RmcGpGb2ZKRVM4UG8wemY3?= =?utf-8?B?RUdMUVFac2Vuc0FsL0JmSXMxNzcvaDBPMThoNWk4MC9OdUxSMXRaYkJRQzdT?= =?utf-8?B?bWpOU3E0ZVNOV1phem16cHFQK3pabnF1N2ljU3N6K3JHeCtLZVVBem56a1Ay?= =?utf-8?B?ZGNGc0VVWkk2eGkwNG53UG9OcVRZSjk0YXJxYTJmQTdSTUN1T3hxU2FVcjBQ?= =?utf-8?B?Nlp0R0d6Y0ZmWmZlTzBwcndSSFUvS3R6WmIzR015VnJsdHk2Mm9YeXpBamMw?= =?utf-8?Q?9e+kT+IxQpWWLxHaOrIcIZZfLsj7rO7cVE0GU=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39860400002)(396003)(346002)(189003)(199004)(51914003)(97736004)(81166006)(9686003)(6306002)(2906002)(14454004)(966005)(55016002)(25786009)(6436002)(53936002)(5660300002)(256004)(7696005)(486006)(476003)(446003)(102836004)(229853002)(76176011)(6506007)(14444005)(33656002)(71190400001)(99286004)(52536013)(186003)(66066001)(6916009)(26005)(54906003)(11346002)(68736007)(8676002)(81156014)(6246003)(74316002)(4326008)(71200400001)(8936002)(3846002)(305945005)(6116002)(106356001)(316002)(105586002)(478600001)(44832011)(86362001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR04MB4274; H:AM0PR04MB4211.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pO/tMm4BPq+h3CwhHzyO5YzEY5c6nj4fqfX63R2QI0zJxZMlUL+TusOZMXSvgC2A+2ZWcgBxnXMXiR5fSnLcj5zo1/udcqBWGu9V8X0WjY0Q9j/7vJtosF4qg1hhLX3oYW8xLPxyU0Ez3j/MWkZq/+6AykcKNU0fMOhfWG8v53vAMVn1DvCMdyzUieUBaUgTwJXZk6yhVr7gKs5mM/bvAI+197o0K2hX4VgomqC4R+kXh4geDHo/bo+SxdTzPU04M7FFT7seMAnuopr1lN9PEDt4wBMet3RvWvP7Xf3GKXxelK07DIYyyMgpkDlE4Osamp6pBmOlXfF7sJqeptowMkmBmPGKa/RzKDLtYi1uPZLbNMgzV3b9hl4OrWYEgFUXD7OYFnzAeXkLY6GHNYYsD3g+/xJNM5Izxkvrvl3RTJc= MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a059453-9568-4054-0db3-08d6a2497f82 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 15:36:27.4455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB4274 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190306_073631_297260_31FD99A8 X-CRM114-Status: GOOD ( 29.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "dongas86@gmail.com" , "khilman@kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , dl-linux-imx , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org > From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > Sent: Wednesday, March 6, 2019 11:18 PM> > On Wed, 6 Mar 2019 at 14:35, Aisheng Dong > wrote: > > > > Currently the generic power domain will power off the domain if all > > devices in it have been stopped during system suspend. > > > > It is done by checking if the domain is active in > > genpd_sync_power_off, then disable it. However, for power domains > > supporting multiple low power states, it may have already entered an > > intermediate low power state by runtime PM before system suspend and > > the status is already GPD_STATE_POWER_OFF which results in then the > > power domain stay at an intermediate low power state during system > suspend. > > Then genpd_sync_power_off will keep it at the low power state instead > > of completely gate off it. > > I agree that this could be a concern. However, before we look for a solution, do > you have practical use case where you observes this? > Yes, this solution[1] is used by NXP internally for former releases that we have two Level states for power Domains[2]. We use state 0 (Low Power Mode with state retention) for device runtime pm support and state 1 (power off with no state retention) for system suspend resume case. Without [1], we will meet the issue that all domains runtime suspended will stay at low power mode instead of power off during system suspend which consumes more power. 1. https://source.codeaurora.org/external/imx/linux-imx/log/drivers/base/power?h=imx_4.14.78_1.0.0_ga 2. https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/soc/imx/pm-domains.c?h=imx_4.14.78_1.0.0_ga#n325 > > > > Let's give the power domain a chance to switch to the deepest state in > > case it's already off but in an intermediate low power state. > > > > Signed-off-by: Dong Aisheng > > --- > > drivers/base/power/domain.c | 18 +++++++++++++++++- > > include/linux/pm_domain.h | 1 + > > 2 files changed, 18 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > > index 61cd500..847a69e 100644 > > --- a/drivers/base/power/domain.c > > +++ b/drivers/base/power/domain.c > > @@ -959,7 +959,17 @@ static void genpd_sync_power_off(struct > > generic_pm_domain *genpd, bool use_lock, { > > struct gpd_link *link; > > > > - if (!genpd_status_on(genpd) || genpd_is_always_on(genpd)) > > + /* > > + * Give the power domain a chance to switch to the deepest state > in > > + * case it's already off but in an intermediate low power state. > > + */ > > + genpd->state_idx_saved = genpd->state_idx; > > + > > + if (genpd_is_always_on(genpd)) > > + return; > > + > > + if (!genpd_status_on(genpd) && > > + genpd->state_idx == (genpd->state_count - 1)) > > return; > > This means that the ->power_off() callback may be called twice in a raw, for > the genpd in question and in cases of multiple idle states. > It could be a problem. > > Well, currently it may not be a real issue, as I doubt there is rather few genpd > backend drivers supporting multiple idle states, but still. > So far, I've no idea what the problem could be as there's no multi states power domain drivers in tree. For IMX, there's no problem as the driver could handle it well. The core code just provides an interface for driver to handle such requirement. Do you know who else using such power domain with multi states? I guess TI, but did not see their code in tree. > > > > if (genpd->suspended_count != genpd->device_count) @@ -970,6 > > +980,9 @@ static void genpd_sync_power_off(struct generic_pm_domain > *genpd, bool use_lock, > > if (_genpd_power_off(genpd, false)) > > return; > > > > + if (genpd->status == GPD_STATE_POWER_OFF) > > + return; > > + > > genpd->status = GPD_STATE_POWER_OFF; > > > > list_for_each_entry(link, &genpd->slave_links, slave_node) { > > @@ -1017,6 +1030,9 @@ static void genpd_sync_power_on(struct > > generic_pm_domain *genpd, bool use_lock, > > > > _genpd_power_on(genpd, false); > > > > + /* restore save power domain state after resume */ > > + genpd->state_idx = genpd->state_idx_saved; > > + > > genpd->status = GPD_STATE_ACTIVE; } > > > > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h > > index 1ed5874..95db21f 100644 > > --- a/include/linux/pm_domain.h > > +++ b/include/linux/pm_domain.h > > @@ -124,6 +124,7 @@ struct generic_pm_domain { > > }; > > }; > > > > + unsigned int state_idx_saved; /* saved power state for > > + recovery after system suspend/resume */ > > }; > > > > static inline struct generic_pm_domain *pd_to_genpd(struct > > dev_pm_domain *pd) > > -- > > 2.7.4 > > > > I need to think about this a bit more, let me get back to you. > Thanks for the help. Regards Dong Aisheng > Kind regards > Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel