Message ID | 20230213-sm6350-camcc-runtime_pm-v3-1-d35e0d833cc4@fairphone.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2902461wrn; Tue, 14 Feb 2023 03:07:20 -0800 (PST) X-Google-Smtp-Source: AK7set/swveGqW+a2g7CkIdNz8P6tTTWf3e6Lst7AQixeJ/FpyrMRHizZsVFbf8AyypiXUoFMSP1 X-Received: by 2002:a17:906:36d7:b0:878:5f35:b8d6 with SMTP id b23-20020a17090636d700b008785f35b8d6mr2093902ejc.51.1676372840098; Tue, 14 Feb 2023 03:07:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676372840; cv=none; d=google.com; s=arc-20160816; b=vZRKoD8TBtDCBm0CS1tCtbhueu+7qIN2qUMvjhd+BJTYHbKZDOeXj9eCxPdthFdX+W dhFZnRWm3nT+Z70S/5gJqf2hew4112sKPm4MulQfO/4b6wofNjAryXYQaKuek7BnrUT5 T1FRZlM+9+Ub6tRZOpBO4ZaJRBsqzinq1sLoBvxD2pDPky0fLW+PfJfnku072vIlfndW /kK3aozGxKNU8yO0IODsuSMjJUgun1P/hGKDRmxuhmu+EYh3oSOkZ3OZm/SIm+e1Z3TJ 1I8L6EYrZA/idTE5vKy1znSWQws6M1JGp/eOgri5dvTT+JIUPkExUS5RsuLRW8pCN68B FvCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=eFzfHrOtIZCqMj4zPJVlDbK817D86+LN2MDM7zmPIms=; b=jgSYyI8pL/0GMSXWlsgm86jl3T0dhIfCwonyMKtc3VfRwr0x7dM1LRx7CEjWiuYsjr Z8W5Lrib6kCjvjacgUjhQnlP+KfGK1z0udEfoQU+tkJF5B1Un/wU/z/WW6WYRaxNO6PK IKQ1GLvBcRV4YIgG/PrrzhW73WNDeu5DJKzxMutabAyRQOWiPuaW4ycScqJck+/GhmIu i2UKcHthD6uUPfTSqH3lkb/jjU07E7CYve6wkXjFqob3LXOFIIpibhKhMI5sM6b8Yx0W GunipH0dVq4OVuusYIdqgc5ifnCcF1gPHLNfWSPTHNnwUi9B5fKMRhkHAki2sPaq99wB v5Ag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=z7Y+KEKJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fairphone.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 16-20020a170906021000b0088b669590absi17072826ejd.104.2023.02.14.03.06.56; Tue, 14 Feb 2023 03:07:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=z7Y+KEKJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fairphone.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232718AbjBNLBv (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 14 Feb 2023 06:01:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232462AbjBNLBk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Feb 2023 06:01:40 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC6F8244B5 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 03:01:36 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id jg8so39077237ejc.6 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 03:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=eFzfHrOtIZCqMj4zPJVlDbK817D86+LN2MDM7zmPIms=; b=z7Y+KEKJCkG36g6nHpsRZt2V/JBZpah+ipSiZDJVgvbDsSx4Tv64H6Y3bVpYdX7o+r wOTURRQpXui2zhy+Bcnovh3VtWMqv948xVpvsGUec3Av9OHqUGlyHn4bU1v/JhFPks48 dqtDabMnErd5bzpW4+e2HG6j6tR8/DkWW+zInedQT1C7pmfnfDcvQvzSnTsC/ycT+4k8 MUfH+DvJeIspqCep3zPagWMJwcUYYuzRdFQOFOBsH+GkxflSQDkdEdkWoQyaB6Aq4Gnd DGRUrKlKcXKQctfYcZ3DTqC0HzK5qghRaYYWPxXdY7ehIWTdVVL0Q4yWkAfvAJCvT+/5 jduA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eFzfHrOtIZCqMj4zPJVlDbK817D86+LN2MDM7zmPIms=; b=eNpWe6q8G2V97gU+NXUP+6Pa9Dh/hSY6TQAMWRC7D3rj+PDyIyYoQ3AOIHlCJfUISY /KNHVaFJptxi6ltSQO6qKP8nPtjccXMl/fyyQ7xjJfkxA8qXZugLg+bqcVj57rXMA1gP 0UrZYVOQbiBeJzddnTHdYAUwivoQNZvmAQ6weX+KWc4bTedzfmJY5K7pOarLmGdXrKGl Qj/siIhQI8BrkZy6X+fKMncq7rc9uc90V8ZY9EYGiAjU+pvrKXtgDh0UPnZ+CNxLVe77 UzrThrIc97g9xURM2dZWW9R29Lf0ceiBEdyGNFWoMXW9BPjXHayz5wi4keVdW6Gk1MD9 mQ8w== X-Gm-Message-State: AO0yUKVhQxXZOJpw1aXVxple5yIFBxWgZTm2g5+OMCvUusC+HXfY3K/F 2rqg5cwfzJB9Z5SDAjDQ0j7rgQ== X-Received: by 2002:a17:906:6ad4:b0:877:573d:e919 with SMTP id q20-20020a1709066ad400b00877573de919mr2597986ejs.20.1676372495311; Tue, 14 Feb 2023 03:01:35 -0800 (PST) Received: from [172.16.220.87] (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id i21-20020a170906115500b008711cab8875sm7959596eja.216.2023.02.14.03.01.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 03:01:35 -0800 (PST) From: Luca Weiss <luca.weiss@fairphone.com> Date: Tue, 14 Feb 2023 12:01:32 +0100 Subject: [PATCH v3 1/2] clk: qcom: camcc-sm6350: add pm_runtime support MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230213-sm6350-camcc-runtime_pm-v3-1-d35e0d833cc4@fairphone.com> References: <20230213-sm6350-camcc-runtime_pm-v3-0-d35e0d833cc4@fairphone.com> In-Reply-To: <20230213-sm6350-camcc-runtime_pm-v3-0-d35e0d833cc4@fairphone.com> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Luca Weiss <luca.weiss@fairphone.com> X-Mailer: b4 0.12.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757804327100409634?= X-GMAIL-MSGID: =?utf-8?q?1757804327100409634?= |
Series |
Add pm_runtime support to SM6350 camcc
|
|
Commit Message
Luca Weiss
Feb. 14, 2023, 11:01 a.m. UTC
Make sure that we can enable and disable the power domains used for
camcc when the clocks are and aren't used.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/clk/qcom/camcc-sm6350.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
Comments
On Tue, 14 Feb 2023 at 13:01, Luca Weiss <luca.weiss@fairphone.com> wrote: > > Make sure that we can enable and disable the power domains used for > camcc when the clocks are and aren't used. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > drivers/clk/qcom/camcc-sm6350.c | 25 ++++++++++++++++++++++++- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c > index acba9f99d960..fc5532e2ee5b 100644 > --- a/drivers/clk/qcom/camcc-sm6350.c > +++ b/drivers/clk/qcom/camcc-sm6350.c > @@ -7,6 +7,8 @@ > #include <linux/clk-provider.h> > #include <linux/module.h> > #include <linux/platform_device.h> > +#include <linux/pm_clock.h> > +#include <linux/pm_runtime.h> > #include <linux/regmap.h> > > #include <dt-bindings/clock/qcom,sm6350-camcc.h> > @@ -1869,6 +1871,19 @@ MODULE_DEVICE_TABLE(of, camcc_sm6350_match_table); > static int camcc_sm6350_probe(struct platform_device *pdev) > { > struct regmap *regmap; > + int ret; > + > + ret = devm_pm_runtime_enable(&pdev->dev); > + if (ret < 0) > + return ret; > + > + ret = devm_pm_clk_create(&pdev->dev); > + if (ret < 0) > + return ret; This makes me wonder, what is the use for the pm_clk in your case? The driver doesn't seem to use of_pm_clk_add_clk(), of_pm_clk_add_clks() or pm_clk_add_clk(). So pm_clk_suspend() and pm_clk_resume() do nothing. > + > + ret = pm_runtime_get(&pdev->dev); > + if (ret) > + return ret; > > regmap = qcom_cc_map(pdev, &camcc_sm6350_desc); > if (IS_ERR(regmap)) > @@ -1879,14 +1894,22 @@ static int camcc_sm6350_probe(struct platform_device *pdev) > clk_agera_pll_configure(&camcc_pll2, regmap, &camcc_pll2_config); > clk_fabia_pll_configure(&camcc_pll3, regmap, &camcc_pll3_config); > > - return qcom_cc_really_probe(pdev, &camcc_sm6350_desc, regmap); > + ret = qcom_cc_really_probe(pdev, &camcc_sm6350_desc, regmap); > + pm_runtime_put(&pdev->dev); > + > + return ret; > } > > +static const struct dev_pm_ops camcc_pm_ops = { > + SET_RUNTIME_PM_OPS(pm_clk_suspend, pm_clk_resume, NULL) > +}; > + > static struct platform_driver camcc_sm6350_driver = { > .probe = camcc_sm6350_probe, > .driver = { > .name = "sm6350-camcc", > .of_match_table = camcc_sm6350_match_table, > + .pm = &camcc_pm_ops, > }, > }; > > > -- > 2.39.1 >
On Tue Feb 14, 2023 at 1:32 PM CET, Dmitry Baryshkov wrote: > On Tue, 14 Feb 2023 at 13:01, Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > Make sure that we can enable and disable the power domains used for > > camcc when the clocks are and aren't used. > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > --- > > drivers/clk/qcom/camcc-sm6350.c | 25 ++++++++++++++++++++++++- > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c > > index acba9f99d960..fc5532e2ee5b 100644 > > --- a/drivers/clk/qcom/camcc-sm6350.c > > +++ b/drivers/clk/qcom/camcc-sm6350.c > > @@ -7,6 +7,8 @@ > > #include <linux/clk-provider.h> > > #include <linux/module.h> > > #include <linux/platform_device.h> > > +#include <linux/pm_clock.h> > > +#include <linux/pm_runtime.h> > > #include <linux/regmap.h> > > > > #include <dt-bindings/clock/qcom,sm6350-camcc.h> > > @@ -1869,6 +1871,19 @@ MODULE_DEVICE_TABLE(of, camcc_sm6350_match_table); > > static int camcc_sm6350_probe(struct platform_device *pdev) > > { > > struct regmap *regmap; > > + int ret; > > + > > + ret = devm_pm_runtime_enable(&pdev->dev); > > + if (ret < 0) > > + return ret; > > + > > + ret = devm_pm_clk_create(&pdev->dev); > > + if (ret < 0) > > + return ret; > > This makes me wonder, what is the use for the pm_clk in your case? The > driver doesn't seem to use of_pm_clk_add_clk(), of_pm_clk_add_clks() > or pm_clk_add_clk(). So pm_clk_suspend() and pm_clk_resume() do > nothing. You're right that we're not using any of these functions in the driver. However still when camcc is not used, the associated power domain turns off correctly so that part works as expected. Honestly these lines have been copied from a different driver and I'm not familiar enough with the pm_runtime APIs to know what to use here without using the pm_clk* and pm_clk_suspend. Basically we need, if any clock is being used in the driver, the power-domain needs to be enabled as well, and if nothing is used the power-domain can be disabled again. Please advise. Regards Luca > > > + > > + ret = pm_runtime_get(&pdev->dev); > > + if (ret) > > + return ret; > > > > regmap = qcom_cc_map(pdev, &camcc_sm6350_desc); > > if (IS_ERR(regmap)) > > @@ -1879,14 +1894,22 @@ static int camcc_sm6350_probe(struct platform_device *pdev) > > clk_agera_pll_configure(&camcc_pll2, regmap, &camcc_pll2_config); > > clk_fabia_pll_configure(&camcc_pll3, regmap, &camcc_pll3_config); > > > > - return qcom_cc_really_probe(pdev, &camcc_sm6350_desc, regmap); > > + ret = qcom_cc_really_probe(pdev, &camcc_sm6350_desc, regmap); > > + pm_runtime_put(&pdev->dev); > > + > > + return ret; > > } > > > > +static const struct dev_pm_ops camcc_pm_ops = { > > + SET_RUNTIME_PM_OPS(pm_clk_suspend, pm_clk_resume, NULL) > > +}; > > + > > static struct platform_driver camcc_sm6350_driver = { > > .probe = camcc_sm6350_probe, > > .driver = { > > .name = "sm6350-camcc", > > .of_match_table = camcc_sm6350_match_table, > > + .pm = &camcc_pm_ops, > > }, > > }; > > > > > > -- > > 2.39.1 > > > > > -- > With best wishes > Dmitry
On Tue, 7 Mar 2023 at 16:54, Luca Weiss <luca.weiss@fairphone.com> wrote: > > On Tue Feb 14, 2023 at 1:32 PM CET, Dmitry Baryshkov wrote: > > On Tue, 14 Feb 2023 at 13:01, Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > > > Make sure that we can enable and disable the power domains used for > > > camcc when the clocks are and aren't used. > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > --- > > > drivers/clk/qcom/camcc-sm6350.c | 25 ++++++++++++++++++++++++- > > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c > > > index acba9f99d960..fc5532e2ee5b 100644 > > > --- a/drivers/clk/qcom/camcc-sm6350.c > > > +++ b/drivers/clk/qcom/camcc-sm6350.c > > > @@ -7,6 +7,8 @@ > > > #include <linux/clk-provider.h> > > > #include <linux/module.h> > > > #include <linux/platform_device.h> > > > +#include <linux/pm_clock.h> > > > +#include <linux/pm_runtime.h> > > > #include <linux/regmap.h> > > > > > > #include <dt-bindings/clock/qcom,sm6350-camcc.h> > > > @@ -1869,6 +1871,19 @@ MODULE_DEVICE_TABLE(of, camcc_sm6350_match_table); > > > static int camcc_sm6350_probe(struct platform_device *pdev) > > > { > > > struct regmap *regmap; > > > + int ret; > > > + > > > + ret = devm_pm_runtime_enable(&pdev->dev); > > > + if (ret < 0) > > > + return ret; > > > + > > > + ret = devm_pm_clk_create(&pdev->dev); > > > + if (ret < 0) > > > + return ret; > > > > This makes me wonder, what is the use for the pm_clk in your case? The > > driver doesn't seem to use of_pm_clk_add_clk(), of_pm_clk_add_clks() > > or pm_clk_add_clk(). So pm_clk_suspend() and pm_clk_resume() do > > nothing. > > You're right that we're not using any of these functions in the driver. > However still when camcc is not used, the associated power domain turns > off correctly so that part works as expected. > > Honestly these lines have been copied from a different driver and I'm > not familiar enough with the pm_runtime APIs to know what to use here > without using the pm_clk* and pm_clk_suspend. Please don't blindly C&P code. > > Basically we need, if any clock is being used in the driver, the > power-domain needs to be enabled as well, and if nothing is used the > power-domain can be disabled again. Adding power-domains to the camcc node and calling devm_pm_runtime_enable() should be enough. Please see how this is managed for dispcc on sm8250.
On Tue Mar 7, 2023 at 4:06 PM CET, Dmitry Baryshkov wrote: > On Tue, 7 Mar 2023 at 16:54, Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > On Tue Feb 14, 2023 at 1:32 PM CET, Dmitry Baryshkov wrote: > > > On Tue, 14 Feb 2023 at 13:01, Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > > > > > Make sure that we can enable and disable the power domains used for > > > > camcc when the clocks are and aren't used. > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > > --- > > > > drivers/clk/qcom/camcc-sm6350.c | 25 ++++++++++++++++++++++++- > > > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c > > > > index acba9f99d960..fc5532e2ee5b 100644 > > > > --- a/drivers/clk/qcom/camcc-sm6350.c > > > > +++ b/drivers/clk/qcom/camcc-sm6350.c > > > > @@ -7,6 +7,8 @@ > > > > #include <linux/clk-provider.h> > > > > #include <linux/module.h> > > > > #include <linux/platform_device.h> > > > > +#include <linux/pm_clock.h> > > > > +#include <linux/pm_runtime.h> > > > > #include <linux/regmap.h> > > > > > > > > #include <dt-bindings/clock/qcom,sm6350-camcc.h> > > > > @@ -1869,6 +1871,19 @@ MODULE_DEVICE_TABLE(of, camcc_sm6350_match_table); > > > > static int camcc_sm6350_probe(struct platform_device *pdev) > > > > { > > > > struct regmap *regmap; > > > > + int ret; > > > > + > > > > + ret = devm_pm_runtime_enable(&pdev->dev); > > > > + if (ret < 0) > > > > + return ret; > > > > + > > > > + ret = devm_pm_clk_create(&pdev->dev); > > > > + if (ret < 0) > > > > + return ret; > > > > > > This makes me wonder, what is the use for the pm_clk in your case? The > > > driver doesn't seem to use of_pm_clk_add_clk(), of_pm_clk_add_clks() > > > or pm_clk_add_clk(). So pm_clk_suspend() and pm_clk_resume() do > > > nothing. > > > > You're right that we're not using any of these functions in the driver. > > However still when camcc is not used, the associated power domain turns > > off correctly so that part works as expected. > > > > Honestly these lines have been copied from a different driver and I'm > > not familiar enough with the pm_runtime APIs to know what to use here > > without using the pm_clk* and pm_clk_suspend. > > Please don't blindly C&P code. I normally try to avoid this.. however pm_runtime is still quite a mystery to me. > > > > > Basically we need, if any clock is being used in the driver, the > > power-domain needs to be enabled as well, and if nothing is used the > > power-domain can be disabled again. > > Adding power-domains to the camcc node and calling > devm_pm_runtime_enable() should be enough. Please see how this is > managed for dispcc on sm8250. Following that driver, so just using devm_pm_runtime_enable and pm_runtime_resume_and_get doesn't seem to enable runtime_pm for the device.. $ cat /sys/devices/platform/soc@0/ad00000.clock-controller/power/runtime_status unsupported Also then I don't see the device in /sys/kernel/debug/pm_genpd/pm_genpd_summary I'm guessing we still need to set the dev_pm_ops with something? Not sure what to use here if it should just enable/disable the power domains that are not handled by the driver directly. I also couldn't find any example in existing code unfortuantely. Any pointers? Regards Luca > > -- > With best wishes > Dmitry
diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c index acba9f99d960..fc5532e2ee5b 100644 --- a/drivers/clk/qcom/camcc-sm6350.c +++ b/drivers/clk/qcom/camcc-sm6350.c @@ -7,6 +7,8 @@ #include <linux/clk-provider.h> #include <linux/module.h> #include <linux/platform_device.h> +#include <linux/pm_clock.h> +#include <linux/pm_runtime.h> #include <linux/regmap.h> #include <dt-bindings/clock/qcom,sm6350-camcc.h> @@ -1869,6 +1871,19 @@ MODULE_DEVICE_TABLE(of, camcc_sm6350_match_table); static int camcc_sm6350_probe(struct platform_device *pdev) { struct regmap *regmap; + int ret; + + ret = devm_pm_runtime_enable(&pdev->dev); + if (ret < 0) + return ret; + + ret = devm_pm_clk_create(&pdev->dev); + if (ret < 0) + return ret; + + ret = pm_runtime_get(&pdev->dev); + if (ret) + return ret; regmap = qcom_cc_map(pdev, &camcc_sm6350_desc); if (IS_ERR(regmap)) @@ -1879,14 +1894,22 @@ static int camcc_sm6350_probe(struct platform_device *pdev) clk_agera_pll_configure(&camcc_pll2, regmap, &camcc_pll2_config); clk_fabia_pll_configure(&camcc_pll3, regmap, &camcc_pll3_config); - return qcom_cc_really_probe(pdev, &camcc_sm6350_desc, regmap); + ret = qcom_cc_really_probe(pdev, &camcc_sm6350_desc, regmap); + pm_runtime_put(&pdev->dev); + + return ret; } +static const struct dev_pm_ops camcc_pm_ops = { + SET_RUNTIME_PM_OPS(pm_clk_suspend, pm_clk_resume, NULL) +}; + static struct platform_driver camcc_sm6350_driver = { .probe = camcc_sm6350_probe, .driver = { .name = "sm6350-camcc", .of_match_table = camcc_sm6350_match_table, + .pm = &camcc_pm_ops, }, };