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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B907C32793 for ; Wed, 24 Aug 2022 13:31:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235635AbiHXNbf (ORCPT ); Wed, 24 Aug 2022 09:31:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237739AbiHXNbb (ORCPT ); Wed, 24 Aug 2022 09:31:31 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F35974CF4 for ; Wed, 24 Aug 2022 06:31:25 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id s6so12778029lfo.11 for ; Wed, 24 Aug 2022 06:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=/IenWy/p40/CNXuFHNI+gb1QvEr/h9waQZxVYY7VtNA=; b=Vngrw9lShipNLvEXsA+IF/7Qgw/5CAr21iEyiIDB3tfF8HE1j9whkx2nzgD3FZPTjY l5pJLdWoG2QCfauSzSAYf7ZyzAwdbZlu6qSfkPHsnY7hSwdsK01A6iL9NEc6jwiuL7fc 4s7UPn4w62w37ULGtqnYszVGIrhdyejdPzEXFObyNH9Ppm93tYWaiEc5ybp1HmxepakP 2/yNnnlYUaRu5qFbplo/uBNTApWfB62YLDIrYCNDTFyRsXlPQCUq7cMNqSS/2uOV+evH 2KtXeDwgcylnmBwkHuH6vpvmQViNfgCA+FPR/TTPNfkI3uoMh24mX8/Ri3QD7ogiJ0/C upLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=/IenWy/p40/CNXuFHNI+gb1QvEr/h9waQZxVYY7VtNA=; b=z9Ef763LV96bu1nDl+apT3bSbekZzQAUST20+c6QQxYZF7MxgEXmfJ9fJCsSbKJGWu SQBjWJ6Pim+oUFyc/njCyZ72pR/ro+x77H42hZ1tdUOJgA8hvUUc4e/4Fs9VzYtDC2R5 vSLQoJT4tF57DJsLeackB2dN2+mckDLdMovzmh9CU+6ayfrv5kP9OErMrZzb0T+uHfF6 Ic4kl0js5LRivMPwnIHkILPIalwuoF8S41QeZV7/uBKUhDCFo7hiNdmIV8IknoarhHpK aQd63a18LfYcfTlMSantqgows4lyerLjbaM+nSkfBySF7Dc5xex+zlVvUmYBbYIvP8jj dmeA== X-Gm-Message-State: ACgBeo3aHRArOzehUAPhjqrxEgHvcG+A2d1GXFOtvwstMHohjuhyjOBF R+0MG2CwVXQQM+8CRIZCnmFjucDxGm5QymDv4mW2xg== X-Google-Smtp-Source: AA6agR7aG4e2SL7nOyVn87QFL7QjxbVK06xMjGUHAovRGzCaUPQqfwQ4OJbyp5/rhtJoMq3QQqaoUK4HES51ulCbeoA= X-Received: by 2002:ac2:59cf:0:b0:492:bf97:9a03 with SMTP id x15-20020ac259cf000000b00492bf979a03mr10776265lfn.233.1661347883822; Wed, 24 Aug 2022 06:31:23 -0700 (PDT) MIME-Version: 1.0 References: <20220726083257.1730630-1-martin.kepplinger@puri.sm> <20220726083257.1730630-2-martin.kepplinger@puri.sm> <77baacb930bf2ba1a65cb1515e6795b48d2d4ed5.camel@puri.sm> In-Reply-To: <77baacb930bf2ba1a65cb1515e6795b48d2d4ed5.camel@puri.sm> From: Ulf Hansson Date: Wed, 24 Aug 2022 15:30:47 +0200 Message-ID: Subject: Re: [PATCH v6 1/2] power: domain: handle genpd correctly when needing interrupts To: Martin Kepplinger Cc: rafael@kernel.org, khilman@kernel.org, robh@kernel.org, krzysztof.kozlowski@linaro.org, shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com, pavel@ucw.cz, kernel@puri.sm, linux-imx@nxp.com, broonie@kernel.org, l.stach@pengutronix.de, aford173@gmail.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 22 Aug 2022 at 10:38, Martin Kepplinger wrote: > > Am Freitag, dem 19.08.2022 um 16:53 +0200 schrieb Ulf Hansson: > > On Fri, 19 Aug 2022 at 11:17, Martin Kepplinger > > wrote: > > > > > > Am Dienstag, dem 26.07.2022 um 17:07 +0200 schrieb Ulf Hansson: > > > > On Tue, 26 Jul 2022 at 10:33, Martin Kepplinger > > > > wrote: > > > > > > > > > > If for example the power-domains' power-supply node (regulator) > > > > > needs > > > > > interrupts to work, the current setup with noirq callbacks > > > > > cannot > > > > > work; for example a pmic regulator on i2c, when suspending, > > > > > usually > > > > > already > > > > > times out during suspend_noirq: > > > > > > > > > > [ 41.024193] buck4: failed to disable: -ETIMEDOUT > > > > > > > > > > So fix system suspend and resume for these power-domains by > > > > > using > > > > > the > > > > > "outer" suspend/resume callbacks instead. Tested on the imx8mq- > > > > > librem5 board, > > > > > but by looking at the dts, this will fix imx8mq-evk and > > > > > possibly > > > > > many other > > > > > boards too. > > > > > > > > > > This is designed so that genpd providers just say "this genpd > > > > > needs > > > > > interrupts" (by setting the flag) - without implying an > > > > > implementation. > > > > > > > > > > Initially system suspend problems had been discussed at > > > > > https://lore.kernel.org/linux-arm-kernel/20211002005954.1367653-8-l.stach@pengutronix.de/ > > > > > which led to discussing the pmic that contains the regulators > > > > > which > > > > > serve as power-domain power-supplies: > > > > > https://lore.kernel.org/linux-pm/573166b75e524517782471c2b7f96e03fd93d175.camel@puri.sm/T/ > > > > > > > > > > Signed-off-by: Martin Kepplinger > > > > > --- > > > > > drivers/base/power/domain.c | 13 +++++++++++-- > > > > > include/linux/pm_domain.h | 5 +++++ > > > > > 2 files changed, 16 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/base/power/domain.c > > > > > b/drivers/base/power/domain.c > > > > > index 5a2e0232862e..58376752a4de 100644 > > > > > --- a/drivers/base/power/domain.c > > > > > +++ b/drivers/base/power/domain.c > > > > > @@ -130,6 +130,7 @@ static const struct genpd_lock_ops > > > > > genpd_spin_ops = { > > > > > #define genpd_is_active_wakeup(genpd) (genpd->flags & > > > > > GENPD_FLAG_ACTIVE_WAKEUP) > > > > > #define genpd_is_cpu_domain(genpd) (genpd->flags & > > > > > GENPD_FLAG_CPU_DOMAIN) > > > > > #define genpd_is_rpm_always_on(genpd) (genpd->flags & > > > > > GENPD_FLAG_RPM_ALWAYS_ON) > > > > > +#define genpd_irq_on(genpd) (genpd->flags & > > > > > GENPD_FLAG_IRQ_ON) > > > > > > > > > > static inline bool irq_safe_dev_in_sleep_domain(struct device > > > > > *dev, > > > > > const struct generic_pm_domain *genpd) > > > > > @@ -2065,8 +2066,15 @@ int pm_genpd_init(struct > > > > > generic_pm_domain > > > > > *genpd, > > > > > genpd->domain.ops.runtime_suspend = > > > > > genpd_runtime_suspend; > > > > > genpd->domain.ops.runtime_resume = > > > > > genpd_runtime_resume; > > > > > genpd->domain.ops.prepare = genpd_prepare; > > > > > - genpd->domain.ops.suspend_noirq = genpd_suspend_noirq; > > > > > - genpd->domain.ops.resume_noirq = genpd_resume_noirq; > > > > > + > > > > > + if (genpd_irq_on(genpd)) { > > > > > + genpd->domain.ops.suspend = > > > > > genpd_suspend_noirq; > > > > > + genpd->domain.ops.resume = genpd_resume_noirq; > > > > > + } else { > > > > > + genpd->domain.ops.suspend_noirq = > > > > > genpd_suspend_noirq; > > > > > + genpd->domain.ops.resume_noirq = > > > > > genpd_resume_noirq; > > > > > > > > As we discussed previously, I am thinking that it may be better > > > > to > > > > move to using genpd->domain.ops.suspend_late and > > > > genpd->domain.ops.resume_early instead. > > > > > > Wouldn't that better be a separate patch (on top)? Do you really > > > want > > > me to change the current behaviour (default case) to from noirq to > > > late? Then I'll resend this series with such a patch added. > > > > Sorry, I wasn't clear enough, the default behaviour should remain as > > is. > > > > What I meant was, when genpd_irq_on() is true, we should use the > > genpd->domain.ops.suspend_late and genpd->domain.ops.resume_early. > > Testing that shows that this isn't working. I can provide the logs > later, but suspend fails and I think it makes sense: "suspend_late" is > simply already too late when i2c (or any needed driver) uses "suspend". Okay, I see. The reason why I suggested moving the callbacks to "suspend_late", was that I was worried that some of the attached devices to genpd could use "suspend_late" themselves. This is the case for some drivers for DMA/clock/gpio/pinctrl-controllers, for example. That said, I am curious to look at the DT files for the platform you are running, would you mind giving me a pointer? So, this made me think about this a bit more. In the end, just using different levels (suspend, suspend_late, suspend_noirq) of callbacks are just papering over the real *dependency* problem. What we need for the genpd provider driver, is to be asked to be suspended under the following conditions: 1. All consumer devices (and child-domains) for its corresponding PM domain have been suspended. 2. All its supplier devices supplies must remain resumed, until the genpd provider has been suspended. Please allow me a few more days to think in more detail about this. In some way, it looks like we should be able to combine the information genpd has about its devices and child-domains, use PM callbacks for the genpd provider driver - so we can rely on the depency-path the fw_devlinks would give us for its supplier devices. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 2BE96C00140 for ; Wed, 24 Aug 2022 13:32:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PnX4F/rqgNZnivPaS+ZWfKyNG3/ju14IItig6uUQMXo=; b=E7N/j6kwjJ+htd zBioryOV9A1TSX8sOoTFQLbrqk8G7tmxm5AYKPDvUMXIK4w7wwLranDI6/GaMsAv45+2FQZzJJr77 0ykBJZKUsRyqMEi5ITvYpotTG/P4MnapfnwglGujCJuiCIQa5Y+E0Q+z5viI6YCKIiONfcc1ZeR+c cfuhG2G8PnLWdSGcVV2CfYhEC7t81UiU7RS6CKpItXQh/OKZUFbSVRcbBVXfG0XV3rjJE8YbYsvbg beIxaNDgq3ypfRxgwUdysajY9M940KwNNj2EXYQL/nMP2TecTd+Bd5bE7sRBlb2Ycf9kdLRfSE+nr jEAM1R9F2CkQxwGnrIJA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oQqTh-00DFub-AN; Wed, 24 Aug 2022 13:31:29 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oQqTe-00DFtX-Ds for linux-arm-kernel@lists.infradead.org; Wed, 24 Aug 2022 13:31:28 +0000 Received: by mail-lf1-x133.google.com with SMTP id z25so24032392lfr.2 for ; Wed, 24 Aug 2022 06:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=/IenWy/p40/CNXuFHNI+gb1QvEr/h9waQZxVYY7VtNA=; b=Vngrw9lShipNLvEXsA+IF/7Qgw/5CAr21iEyiIDB3tfF8HE1j9whkx2nzgD3FZPTjY l5pJLdWoG2QCfauSzSAYf7ZyzAwdbZlu6qSfkPHsnY7hSwdsK01A6iL9NEc6jwiuL7fc 4s7UPn4w62w37ULGtqnYszVGIrhdyejdPzEXFObyNH9Ppm93tYWaiEc5ybp1HmxepakP 2/yNnnlYUaRu5qFbplo/uBNTApWfB62YLDIrYCNDTFyRsXlPQCUq7cMNqSS/2uOV+evH 2KtXeDwgcylnmBwkHuH6vpvmQViNfgCA+FPR/TTPNfkI3uoMh24mX8/Ri3QD7ogiJ0/C upLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=/IenWy/p40/CNXuFHNI+gb1QvEr/h9waQZxVYY7VtNA=; b=Pk9LiZSc8YCPYZbU939pqoIwz7FKPS6i1OSWUxsJTyTNDb494N/Ty5EMLlU0M3hlbZ n2tOnj617mZ5Y3uSckqWir6wnQuUx/T+wE82PqTBrlu6rDVVYqXqVc8a+MnraKebGvWL IC0CyMBpsV+jU7ZyofFr3SrHW8vV4Gbcbb9k+OaxaJcjt6v+5IRHGs+H9etaJhXn7AFv DHzJMyWAMCedMMM/yXRLDyD74P/5tfW5MYUfdx69Y6HOVDlgAYeopQ8PMSEvv1pV7vlc p3okRDJZBJfJEeEhQHkAaWxt0i98g+1jfdTJTQkkGLSUBKHjG0KrYCX0GW8K06/s8Bj5 9AVw== X-Gm-Message-State: ACgBeo3dwiy1Y0drQYgOVlx/+bugzgU3LbFqInY3UqB0CiWmAP7gZfcW dELWUyvGs6tPm3djuG0704zDwkDg+x/dZg0llIOMkQ== X-Google-Smtp-Source: AA6agR7aG4e2SL7nOyVn87QFL7QjxbVK06xMjGUHAovRGzCaUPQqfwQ4OJbyp5/rhtJoMq3QQqaoUK4HES51ulCbeoA= X-Received: by 2002:ac2:59cf:0:b0:492:bf97:9a03 with SMTP id x15-20020ac259cf000000b00492bf979a03mr10776265lfn.233.1661347883822; Wed, 24 Aug 2022 06:31:23 -0700 (PDT) MIME-Version: 1.0 References: <20220726083257.1730630-1-martin.kepplinger@puri.sm> <20220726083257.1730630-2-martin.kepplinger@puri.sm> <77baacb930bf2ba1a65cb1515e6795b48d2d4ed5.camel@puri.sm> In-Reply-To: <77baacb930bf2ba1a65cb1515e6795b48d2d4ed5.camel@puri.sm> From: Ulf Hansson Date: Wed, 24 Aug 2022 15:30:47 +0200 Message-ID: Subject: Re: [PATCH v6 1/2] power: domain: handle genpd correctly when needing interrupts To: Martin Kepplinger Cc: rafael@kernel.org, khilman@kernel.org, robh@kernel.org, krzysztof.kozlowski@linaro.org, shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com, pavel@ucw.cz, kernel@puri.sm, linux-imx@nxp.com, broonie@kernel.org, l.stach@pengutronix.de, aford173@gmail.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220824_063126_532827_A7608CB0 X-CRM114-Status: GOOD ( 45.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 22 Aug 2022 at 10:38, Martin Kepplinger wrote: > > Am Freitag, dem 19.08.2022 um 16:53 +0200 schrieb Ulf Hansson: > > On Fri, 19 Aug 2022 at 11:17, Martin Kepplinger > > wrote: > > > > > > Am Dienstag, dem 26.07.2022 um 17:07 +0200 schrieb Ulf Hansson: > > > > On Tue, 26 Jul 2022 at 10:33, Martin Kepplinger > > > > wrote: > > > > > > > > > > If for example the power-domains' power-supply node (regulator) > > > > > needs > > > > > interrupts to work, the current setup with noirq callbacks > > > > > cannot > > > > > work; for example a pmic regulator on i2c, when suspending, > > > > > usually > > > > > already > > > > > times out during suspend_noirq: > > > > > > > > > > [ 41.024193] buck4: failed to disable: -ETIMEDOUT > > > > > > > > > > So fix system suspend and resume for these power-domains by > > > > > using > > > > > the > > > > > "outer" suspend/resume callbacks instead. Tested on the imx8mq- > > > > > librem5 board, > > > > > but by looking at the dts, this will fix imx8mq-evk and > > > > > possibly > > > > > many other > > > > > boards too. > > > > > > > > > > This is designed so that genpd providers just say "this genpd > > > > > needs > > > > > interrupts" (by setting the flag) - without implying an > > > > > implementation. > > > > > > > > > > Initially system suspend problems had been discussed at > > > > > https://lore.kernel.org/linux-arm-kernel/20211002005954.1367653-8-l.stach@pengutronix.de/ > > > > > which led to discussing the pmic that contains the regulators > > > > > which > > > > > serve as power-domain power-supplies: > > > > > https://lore.kernel.org/linux-pm/573166b75e524517782471c2b7f96e03fd93d175.camel@puri.sm/T/ > > > > > > > > > > Signed-off-by: Martin Kepplinger > > > > > --- > > > > > drivers/base/power/domain.c | 13 +++++++++++-- > > > > > include/linux/pm_domain.h | 5 +++++ > > > > > 2 files changed, 16 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/base/power/domain.c > > > > > b/drivers/base/power/domain.c > > > > > index 5a2e0232862e..58376752a4de 100644 > > > > > --- a/drivers/base/power/domain.c > > > > > +++ b/drivers/base/power/domain.c > > > > > @@ -130,6 +130,7 @@ static const struct genpd_lock_ops > > > > > genpd_spin_ops = { > > > > > #define genpd_is_active_wakeup(genpd) (genpd->flags & > > > > > GENPD_FLAG_ACTIVE_WAKEUP) > > > > > #define genpd_is_cpu_domain(genpd) (genpd->flags & > > > > > GENPD_FLAG_CPU_DOMAIN) > > > > > #define genpd_is_rpm_always_on(genpd) (genpd->flags & > > > > > GENPD_FLAG_RPM_ALWAYS_ON) > > > > > +#define genpd_irq_on(genpd) (genpd->flags & > > > > > GENPD_FLAG_IRQ_ON) > > > > > > > > > > static inline bool irq_safe_dev_in_sleep_domain(struct device > > > > > *dev, > > > > > const struct generic_pm_domain *genpd) > > > > > @@ -2065,8 +2066,15 @@ int pm_genpd_init(struct > > > > > generic_pm_domain > > > > > *genpd, > > > > > genpd->domain.ops.runtime_suspend = > > > > > genpd_runtime_suspend; > > > > > genpd->domain.ops.runtime_resume = > > > > > genpd_runtime_resume; > > > > > genpd->domain.ops.prepare = genpd_prepare; > > > > > - genpd->domain.ops.suspend_noirq = genpd_suspend_noirq; > > > > > - genpd->domain.ops.resume_noirq = genpd_resume_noirq; > > > > > + > > > > > + if (genpd_irq_on(genpd)) { > > > > > + genpd->domain.ops.suspend = > > > > > genpd_suspend_noirq; > > > > > + genpd->domain.ops.resume = genpd_resume_noirq; > > > > > + } else { > > > > > + genpd->domain.ops.suspend_noirq = > > > > > genpd_suspend_noirq; > > > > > + genpd->domain.ops.resume_noirq = > > > > > genpd_resume_noirq; > > > > > > > > As we discussed previously, I am thinking that it may be better > > > > to > > > > move to using genpd->domain.ops.suspend_late and > > > > genpd->domain.ops.resume_early instead. > > > > > > Wouldn't that better be a separate patch (on top)? Do you really > > > want > > > me to change the current behaviour (default case) to from noirq to > > > late? Then I'll resend this series with such a patch added. > > > > Sorry, I wasn't clear enough, the default behaviour should remain as > > is. > > > > What I meant was, when genpd_irq_on() is true, we should use the > > genpd->domain.ops.suspend_late and genpd->domain.ops.resume_early. > > Testing that shows that this isn't working. I can provide the logs > later, but suspend fails and I think it makes sense: "suspend_late" is > simply already too late when i2c (or any needed driver) uses "suspend". Okay, I see. The reason why I suggested moving the callbacks to "suspend_late", was that I was worried that some of the attached devices to genpd could use "suspend_late" themselves. This is the case for some drivers for DMA/clock/gpio/pinctrl-controllers, for example. That said, I am curious to look at the DT files for the platform you are running, would you mind giving me a pointer? So, this made me think about this a bit more. In the end, just using different levels (suspend, suspend_late, suspend_noirq) of callbacks are just papering over the real *dependency* problem. What we need for the genpd provider driver, is to be asked to be suspended under the following conditions: 1. All consumer devices (and child-domains) for its corresponding PM domain have been suspended. 2. All its supplier devices supplies must remain resumed, until the genpd provider has been suspended. Please allow me a few more days to think in more detail about this. In some way, it looks like we should be able to combine the information genpd has about its devices and child-domains, use PM callbacks for the genpd provider driver - so we can rely on the depency-path the fw_devlinks would give us for its supplier devices. Kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel