| Message ID | 20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
| Series | [1/3] clk: qcom: lpass-sc7280: Fix pm_runtime usage | expand |
Quoting Douglas Anderson (2022-11-04 06:56:29) > The sc7180 lpass clock controller's pm_runtime usage wasn't broken > quite as spectacularly as the sc7280's pm_runtime usage, but it was > still broken. Putting some printouts in at boot showed me this (with > serial console enabled, which makes the prints slow and thus changes > timing): > [ 3.109951] DOUG: my_pm_clk_resume, usage=1 > [ 3.114767] DOUG: my_pm_clk_resume, usage=1 > [ 3.664443] DOUG: my_pm_clk_suspend, usage=0 > [ 3.897566] DOUG: my_pm_clk_suspend, usage=0 > [ 3.910137] DOUG: my_pm_clk_resume, usage=1 > [ 3.923217] DOUG: my_pm_clk_resume, usage=0 > [ 4.440116] DOUG: my_pm_clk_suspend, usage=-1 > [ 4.444982] DOUG: my_pm_clk_suspend, usage=0 > [ 14.170501] DOUG: my_pm_clk_resume, usage=1 > [ 14.176245] DOUG: my_pm_clk_resume, usage=0 > > ...or this w/out serial console: > [ 0.556139] DOUG: my_pm_clk_resume, usage=1 > [ 0.556279] DOUG: my_pm_clk_resume, usage=1 > [ 1.058422] DOUG: my_pm_clk_suspend, usage=-1 > [ 1.058464] DOUG: my_pm_clk_suspend, usage=0 > [ 1.186250] DOUG: my_pm_clk_resume, usage=1 > [ 1.186292] DOUG: my_pm_clk_resume, usage=0 > [ 1.731536] DOUG: my_pm_clk_suspend, usage=-1 > [ 1.731557] DOUG: my_pm_clk_suspend, usage=0 > [ 10.288910] DOUG: my_pm_clk_resume, usage=1 > [ 10.289496] DOUG: my_pm_clk_resume, usage=0 > > It seems to be doing roughly the right sequence of calls, but just > like with sc7280 this is more by luck than anything. Having a usage of > -1 is just not OK. > > Let's fix this like we did with sc7280. Any Fixes tag? > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Hi, On Fri, Nov 4, 2022 at 2:19 PM Stephen Boyd <swboyd@chromium.org> wrote: > > Quoting Douglas Anderson (2022-11-04 06:56:29) > > The sc7180 lpass clock controller's pm_runtime usage wasn't broken > > quite as spectacularly as the sc7280's pm_runtime usage, but it was > > still broken. Putting some printouts in at boot showed me this (with > > serial console enabled, which makes the prints slow and thus changes > > timing): > > [ 3.109951] DOUG: my_pm_clk_resume, usage=1 > > [ 3.114767] DOUG: my_pm_clk_resume, usage=1 > > [ 3.664443] DOUG: my_pm_clk_suspend, usage=0 > > [ 3.897566] DOUG: my_pm_clk_suspend, usage=0 > > [ 3.910137] DOUG: my_pm_clk_resume, usage=1 > > [ 3.923217] DOUG: my_pm_clk_resume, usage=0 > > [ 4.440116] DOUG: my_pm_clk_suspend, usage=-1 > > [ 4.444982] DOUG: my_pm_clk_suspend, usage=0 > > [ 14.170501] DOUG: my_pm_clk_resume, usage=1 > > [ 14.176245] DOUG: my_pm_clk_resume, usage=0 > > > > ...or this w/out serial console: > > [ 0.556139] DOUG: my_pm_clk_resume, usage=1 > > [ 0.556279] DOUG: my_pm_clk_resume, usage=1 > > [ 1.058422] DOUG: my_pm_clk_suspend, usage=-1 > > [ 1.058464] DOUG: my_pm_clk_suspend, usage=0 > > [ 1.186250] DOUG: my_pm_clk_resume, usage=1 > > [ 1.186292] DOUG: my_pm_clk_resume, usage=0 > > [ 1.731536] DOUG: my_pm_clk_suspend, usage=-1 > > [ 1.731557] DOUG: my_pm_clk_suspend, usage=0 > > [ 10.288910] DOUG: my_pm_clk_resume, usage=1 > > [ 10.289496] DOUG: my_pm_clk_resume, usage=0 > > > > It seems to be doing roughly the right sequence of calls, but just > > like with sc7280 this is more by luck than anything. Having a usage of > > -1 is just not OK. > > > > Let's fix this like we did with sc7280. > > Any Fixes tag? Ah, right. I guess the most obvious one is actually: Fixes: ce8c195e652f ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180") That's what got us going negative. One could _sorta_ make the argument for a "Fixes" tag all the way to the start of the driver, though. The driver never did a pm_runtime_get() during probe and so there was (I guess) a chance that some of the bare register writes in probe could have been unclocked. I'm not aware of that ever being a problem, so I guess just the above "Fixes" is fine. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > Reviewed-by: Stephen Boyd <swboyd@chromium.org> Thanks! Yell if you want me to spin a v2 with the Fixes in place. -Doug
diff --git a/drivers/clk/qcom/lpasscorecc-sc7180.c b/drivers/clk/qcom/lpasscorecc-sc7180.c index ac09b7b840ab..a5731994cbed 100644 --- a/drivers/clk/qcom/lpasscorecc-sc7180.c +++ b/drivers/clk/qcom/lpasscorecc-sc7180.c @@ -356,7 +356,7 @@ static const struct qcom_cc_desc lpass_audio_hm_sc7180_desc = { .num_gdscs = ARRAY_SIZE(lpass_audio_hm_sc7180_gdscs), }; -static int lpass_create_pm_clks(struct platform_device *pdev) +static int lpass_setup_runtime_pm(struct platform_device *pdev) { int ret; @@ -375,7 +375,7 @@ static int lpass_create_pm_clks(struct platform_device *pdev) if (ret < 0) dev_err(&pdev->dev, "failed to acquire iface clock\n"); - return ret; + return pm_runtime_resume_and_get(&pdev->dev); } static int lpass_core_cc_sc7180_probe(struct platform_device *pdev) @@ -384,7 +384,7 @@ static int lpass_core_cc_sc7180_probe(struct platform_device *pdev) struct regmap *regmap; int ret; - ret = lpass_create_pm_clks(pdev); + ret = lpass_setup_runtime_pm(pdev); if (ret) return ret; @@ -392,12 +392,14 @@ static int lpass_core_cc_sc7180_probe(struct platform_device *pdev) desc = &lpass_audio_hm_sc7180_desc; ret = qcom_cc_probe_by_index(pdev, 1, desc); if (ret) - return ret; + goto exit; lpass_core_cc_sc7180_regmap_config.name = "lpass_core_cc"; regmap = qcom_cc_map(pdev, &lpass_core_cc_sc7180_desc); - if (IS_ERR(regmap)) - return PTR_ERR(regmap); + if (IS_ERR(regmap)) { + ret = PTR_ERR(regmap); + goto exit; + } /* * Keep the CLK always-ON @@ -415,6 +417,7 @@ static int lpass_core_cc_sc7180_probe(struct platform_device *pdev) ret = qcom_cc_really_probe(pdev, &lpass_core_cc_sc7180_desc, regmap); pm_runtime_mark_last_busy(&pdev->dev); +exit: pm_runtime_put_autosuspend(&pdev->dev); return ret; @@ -425,14 +428,19 @@ static int lpass_hm_core_probe(struct platform_device *pdev) const struct qcom_cc_desc *desc; int ret; - ret = lpass_create_pm_clks(pdev); + ret = lpass_setup_runtime_pm(pdev); if (ret) return ret; lpass_core_cc_sc7180_regmap_config.name = "lpass_hm_core"; desc = &lpass_core_hm_sc7180_desc; - return qcom_cc_probe_by_index(pdev, 0, desc); + ret = qcom_cc_probe_by_index(pdev, 0, desc); + + pm_runtime_mark_last_busy(&pdev->dev); + pm_runtime_put_autosuspend(&pdev->dev); + + return ret; } static const struct of_device_id lpass_hm_sc7180_match_table[] = {
The sc7180 lpass clock controller's pm_runtime usage wasn't broken quite as spectacularly as the sc7280's pm_runtime usage, but it was still broken. Putting some printouts in at boot showed me this (with serial console enabled, which makes the prints slow and thus changes timing): [ 3.109951] DOUG: my_pm_clk_resume, usage=1 [ 3.114767] DOUG: my_pm_clk_resume, usage=1 [ 3.664443] DOUG: my_pm_clk_suspend, usage=0 [ 3.897566] DOUG: my_pm_clk_suspend, usage=0 [ 3.910137] DOUG: my_pm_clk_resume, usage=1 [ 3.923217] DOUG: my_pm_clk_resume, usage=0 [ 4.440116] DOUG: my_pm_clk_suspend, usage=-1 [ 4.444982] DOUG: my_pm_clk_suspend, usage=0 [ 14.170501] DOUG: my_pm_clk_resume, usage=1 [ 14.176245] DOUG: my_pm_clk_resume, usage=0 ...or this w/out serial console: [ 0.556139] DOUG: my_pm_clk_resume, usage=1 [ 0.556279] DOUG: my_pm_clk_resume, usage=1 [ 1.058422] DOUG: my_pm_clk_suspend, usage=-1 [ 1.058464] DOUG: my_pm_clk_suspend, usage=0 [ 1.186250] DOUG: my_pm_clk_resume, usage=1 [ 1.186292] DOUG: my_pm_clk_resume, usage=0 [ 1.731536] DOUG: my_pm_clk_suspend, usage=-1 [ 1.731557] DOUG: my_pm_clk_suspend, usage=0 [ 10.288910] DOUG: my_pm_clk_resume, usage=1 [ 10.289496] DOUG: my_pm_clk_resume, usage=0 It seems to be doing roughly the right sequence of calls, but just like with sc7280 this is more by luck than anything. Having a usage of -1 is just not OK. Let's fix this like we did with sc7280. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/clk/qcom/lpasscorecc-sc7180.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)