* [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
@ 2026-06-22 0:56 phucduc.bui
2026-06-22 13:04 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: phucduc.bui @ 2026-06-22 0:56 UTC (permalink / raw)
To: Heiko Stuebner, Mark Brown, Liam Girdwood
Cc: Nicolas Frattaroli, Krzysztof Kozlowski, Jaroslav Kysela,
Takashi Iwai, linux-sound, linux-rockchip, linux-arm-kernel,
linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Although switching to devm_clk_get_enabled() in a previous patch was
tested successfully, it introduces overlapping ownership of the clock
lifecycle. Since the driver requires early register access to read the
device version during probe(), enabling hclk at that point is mandatory.
However, relying on devres for automatic disabling at unbind, while calling
clk_disable_unprepare() manually at the end of probe() alongside Runtime
PM's autosuspend, creates redundant and overlapping clock management.
While this mixed approach might not trigger errors under normal test
conditions, it is architecturally sub-optimal. As stated in the code
comments, Runtime PM should exclusively own the clock for register
accesses after the initial configuration phase.
Clean up the design by:
1 Reverting back to devm_clk_get() to remove the implicit devres
enable/disable behavior.
2 Manually enabling and disabling hclk explicitly only around the
early register access before Runtime PM takes over.
3 Dropping the stray clk_disable_unprepare() at the end of probe()
so Runtime PM solely owns hclk afterward.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Links:
1 This change is based on the discussion around manual hclk handing during probe(),
as raised by Krysztof:
https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
2 Background for the earlier devm_clk_get_enbabled() conversion:
https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
manage clock enablement around register accesses. If preferred, I can rework the
driver accordingly.
sound/soc/rockchip/rockchip_sai.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..ebb491fac77d 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -1438,20 +1438,30 @@ static int rockchip_sai_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, PTR_ERR(sai->mclk),
"Failed to get mclk\n");
- sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
+ sai->hclk = devm_clk_get(&pdev->dev, "hclk");
if (IS_ERR(sai->hclk))
return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
"Failed to get hclk\n");
+ ret = clk_prepare_enable(sai->hclk);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
+
regmap_read(sai->regmap, SAI_VERSION, &sai->version);
ret = rockchip_sai_init_dai(sai, res, &dai);
- if (ret)
- return dev_err_probe(&pdev->dev, ret, "Failed to initialize DAI\n");
+ if (ret) {
+ ret = dev_err_probe(&pdev->dev, ret, "Failed to initialize DAI\n");
+ goto err_disable_hclk;
+ }
ret = rockchip_sai_parse_paths(sai, node);
- if (ret)
- return dev_err_probe(&pdev->dev, ret, "Failed to parse paths\n");
+ if (ret) {
+ ret = dev_err_probe(&pdev->dev, ret, "Failed to parse paths\n");
+ goto err_disable_hclk;
+ }
+
+ clk_disable_unprepare(sai->hclk);
/*
* From here on, all register accesses need to be wrapped in
@@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_put(&pdev->dev);
- clk_disable_unprepare(sai->hclk);
-
return 0;
err_runtime_suspend:
@@ -1493,6 +1501,11 @@ static int rockchip_sai_probe(struct platform_device *pdev)
rockchip_sai_runtime_suspend(&pdev->dev);
return ret;
+
+err_disable_hclk:
+ clk_disable_unprepare(sai->hclk);
+
+ return ret;
}
static void rockchip_sai_remove(struct platform_device *pdev)
--
2.43.0
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
2026-06-22 0:56 [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM phucduc.bui
@ 2026-06-22 13:04 ` Mark Brown
2026-06-23 10:53 ` Bui Duc Phuc
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2026-06-22 13:04 UTC (permalink / raw)
To: phucduc.bui
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
On Mon, Jun 22, 2026 at 07:56:13AM +0700, phucduc.bui@gmail.com wrote:
> Although switching to devm_clk_get_enabled() in a previous patch was
> tested successfully, it introduces overlapping ownership of the clock
> lifecycle. Since the driver requires early register access to read the
> device version during probe(), enabling hclk at that point is mandatory.
> Clean up the design by:
> 1 Reverting back to devm_clk_get() to remove the implicit devres
> enable/disable behavior.
> 2 Manually enabling and disabling hclk explicitly only around the
> early register access before Runtime PM takes over.
> 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> so Runtime PM solely owns hclk afterward.
Note that runtime PM can be disabled at build time so we might not have
runtime PM at all...
> Links:
> 1 This change is based on the discussion around manual hclk handing during probe(),
> as raised by Krysztof:
> https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> 2 Background for the earlier devm_clk_get_enbabled() conversion:
> https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> manage clock enablement around register accesses. If preferred, I can rework the
> driver accordingly.
> - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> if (IS_ERR(sai->hclk))
> return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> "Failed to get hclk\n");
>
> + ret = clk_prepare_enable(sai->hclk);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> +
> @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_put(&pdev->dev);
>
> - clk_disable_unprepare(sai->hclk);
> -
> return 0;
Are you sure that the runtime PM state there is such that it knows a
reference is held? The driver used pm_runtime_get_noresume() so the
device didn't have RPM_ACTIVE set I think?
The runtime PM API really is a miserable collection of landmines :(
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
2026-06-22 13:04 ` Mark Brown
@ 2026-06-23 10:53 ` Bui Duc Phuc
2026-06-24 2:37 ` Bui Duc Phuc
0 siblings, 1 reply; 6+ messages in thread
From: Bui Duc Phuc @ 2026-06-23 10:53 UTC (permalink / raw)
To: Mark Brown
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
Hi Mark,
Thank you for your review.
> > 1 Reverting back to devm_clk_get() to remove the implicit devres
> > enable/disable behavior.
> > 2 Manually enabling and disabling hclk explicitly only around the
> > early register access before Runtime PM takes over.
> > 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> > so Runtime PM solely owns hclk afterward.
>
> Note that runtime PM can be disabled at build time so we might not have
> runtime PM at all...
>
Thanks for pointing this out. You're right that with !CONFIG_PM, the
driver only relies on the
two manual calls to rokchip_sai_runtime_resume() / suspend(), so hclk
stays enabled the
whole time. I understand this is unvavoidable in that configuration,
throgh, since there's no
Runtime PM to re-enable the clock when it's needed.
I'll update the commit message to reflect that the driver uses a
combination of Runtime PM
and explicit manual enable/disable, rather than relying on Runtime PM alone.
> > Links:
> > 1 This change is based on the discussion around manual hclk handing during probe(),
> > as raised by Krysztof:
> > https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> > 2 Background for the earlier devm_clk_get_enbabled() conversion:
> > https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
>
> > An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> > manage clock enablement around register accesses. If preferred, I can rework the
> > driver accordingly.
>
> > - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> > + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> > if (IS_ERR(sai->hclk))
> > return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> > "Failed to get hclk\n");
> >
> > + ret = clk_prepare_enable(sai->hclk);
> > + if (ret)
> > + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> > +
>
> > @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> > pm_runtime_use_autosuspend(&pdev->dev);
> > pm_runtime_put(&pdev->dev);
> >
> > - clk_disable_unprepare(sai->hclk);
> > -
> > return 0;
>
> Are you sure that the runtime PM state there is such that it knows a
> reference is held? The driver used pm_runtime_get_noresume() so the
> device didn't have RPM_ACTIVE set I think?
You are right, pm_runtime_get_noresume() doesn't set RPM_ACTIVE. I
think we need to add
pm_runtime_set_active() before pm_runtime_enable(). Otherwise, with CONFIG_PM,
the pm_runtime_put() at the end of probe() might skip the suspend,
since the core still considers
the device suspended .
>
> The runtime PM API really is a miserable collection of landmines :(
Yeah, plenty of landmines indeed :(
I checked, and rockchip_spdif.c does use devm_regmap_init_mmio_clk() for hclk,
rather than wrapping every register access in pm_runtime_get_sync() /
pm_runtime_put()
the way rockchip_sai does.
Best regards,
Phuc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
2026-06-23 10:53 ` Bui Duc Phuc
@ 2026-06-24 2:37 ` Bui Duc Phuc
2026-07-21 12:08 ` Nicolas Frattaroli
0 siblings, 1 reply; 6+ messages in thread
From: Bui Duc Phuc @ 2026-06-24 2:37 UTC (permalink / raw)
To: Mark Brown
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
Hi all,
Regarding the case where PM configuration is not enabled, with the old
source code, I suspect there is an unbalanced clk_disable_unprepare()
call on hclk when the driver is unbound after a successful probe under
CONFIG_PM=n.
The actual enable_count / prepare_count sequence for hclk (with values
clamped at 0) would be:
probe:
devm_clk_get_enabled 0 -> 1
runtime_resume (manual) 1 -> 2
clk_disable_unprepare 2 -> 1 (at the end of probe)
unbind:
remove -> runtime_suspend 1 -> 0 (ops->disable/unprepare executed here)
devm cleanup 0 -> WARN "already disabled" /
"already unprepared"
This conclusion is based solely on code inspection; I do not have
hardware available to verify it.
I noticed that Nicolas tested and ACKed the use of devm_clk_get_enabled(),
so I'm not sure whether that testing included the CONFIG_PM=n configuration.
https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
If it did, then I may have overlooked something.
@Nicolas (or anyone familiar with this), could you please help
double-check if my understanding is correct?
Best regards,
Phuc
On Tue, Jun 23, 2026 at 5:53 PM Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
>
> Hi Mark,
>
> Thank you for your review.
>
> > > 1 Reverting back to devm_clk_get() to remove the implicit devres
> > > enable/disable behavior.
> > > 2 Manually enabling and disabling hclk explicitly only around the
> > > early register access before Runtime PM takes over.
> > > 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> > > so Runtime PM solely owns hclk afterward.
> >
> > Note that runtime PM can be disabled at build time so we might not have
> > runtime PM at all...
> >
>
> Thanks for pointing this out. You're right that with !CONFIG_PM, the
> driver only relies on the
> two manual calls to rokchip_sai_runtime_resume() / suspend(), so hclk
> stays enabled the
> whole time. I understand this is unvavoidable in that configuration,
> throgh, since there's no
> Runtime PM to re-enable the clock when it's needed.
>
> I'll update the commit message to reflect that the driver uses a
> combination of Runtime PM
> and explicit manual enable/disable, rather than relying on Runtime PM alone.
>
> > > Links:
> > > 1 This change is based on the discussion around manual hclk handing during probe(),
> > > as raised by Krysztof:
> > > https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> > > 2 Background for the earlier devm_clk_get_enbabled() conversion:
> > > https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> >
> > > An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> > > manage clock enablement around register accesses. If preferred, I can rework the
> > > driver accordingly.
> >
> > > - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> > > + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> > > if (IS_ERR(sai->hclk))
> > > return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> > > "Failed to get hclk\n");
> > >
> > > + ret = clk_prepare_enable(sai->hclk);
> > > + if (ret)
> > > + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> > > +
> >
> > > @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> > > pm_runtime_use_autosuspend(&pdev->dev);
> > > pm_runtime_put(&pdev->dev);
> > >
> > > - clk_disable_unprepare(sai->hclk);
> > > -
> > > return 0;
> >
> > Are you sure that the runtime PM state there is such that it knows a
> > reference is held? The driver used pm_runtime_get_noresume() so the
> > device didn't have RPM_ACTIVE set I think?
>
>
> You are right, pm_runtime_get_noresume() doesn't set RPM_ACTIVE. I
> think we need to add
> pm_runtime_set_active() before pm_runtime_enable(). Otherwise, with CONFIG_PM,
> the pm_runtime_put() at the end of probe() might skip the suspend,
> since the core still considers
> the device suspended .
>
> >
> > The runtime PM API really is a miserable collection of landmines :(
>
> Yeah, plenty of landmines indeed :(
> I checked, and rockchip_spdif.c does use devm_regmap_init_mmio_clk() for hclk,
> rather than wrapping every register access in pm_runtime_get_sync() /
> pm_runtime_put()
> the way rockchip_sai does.
>
> Best regards,
> Phuc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
2026-06-24 2:37 ` Bui Duc Phuc
@ 2026-07-21 12:08 ` Nicolas Frattaroli
2026-07-22 11:50 ` Bui Duc Phuc
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Frattaroli @ 2026-07-21 12:08 UTC (permalink / raw)
To: Mark Brown, Bui Duc Phuc
Cc: Heiko Stuebner, Liam Girdwood, Krzysztof Kozlowski,
Jaroslav Kysela, Takashi Iwai, linux-sound, linux-rockchip,
linux-arm-kernel, linux-kernel
Hello, finally got around to responding to this.
On Wednesday, 24 June 2026 04:37:33 Central European Summer Time Bui Duc Phuc wrote:
> Hi all,
>
> Regarding the case where PM configuration is not enabled, with the old
> source code, I suspect there is an unbalanced clk_disable_unprepare()
> call on hclk when the driver is unbound after a successful probe under
> CONFIG_PM=n.
If "old source code" refers to what's currently in the tree with the
devm_clk_get_enabled, then yes. There's the manual resume function
call which isn't balanced.
I think your follow-up patch does make sense in light of that.
>
> The actual enable_count / prepare_count sequence for hclk (with values
> clamped at 0) would be:
>
> probe:
>
> devm_clk_get_enabled 0 -> 1
> runtime_resume (manual) 1 -> 2
> clk_disable_unprepare 2 -> 1 (at the end of probe)
>
> unbind:
>
> remove -> runtime_suspend 1 -> 0 (ops->disable/unprepare executed here)
> devm cleanup 0 -> WARN "already disabled" /
> "already unprepared"
>
> This conclusion is based solely on code inspection; I do not have
> hardware available to verify it.
I'll e-mail you off-list to see if we can rectify that.
> I noticed that Nicolas tested and ACKed the use of devm_clk_get_enabled(),
> so I'm not sure whether that testing included the CONFIG_PM=n configuration.
Nope, I basically never build with PM/RPM disabled.
>
> https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
>
> If it did, then I may have overlooked something.
>
> @Nicolas (or anyone familiar with this), could you please help
> double-check if my understanding is correct?
>
> Best regards,
> Phuc
>
>
>
> On Tue, Jun 23, 2026 at 5:53 PM Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
> >
> > Hi Mark,
> >
> > Thank you for your review.
> >
> > > > 1 Reverting back to devm_clk_get() to remove the implicit devres
> > > > enable/disable behavior.
> > > > 2 Manually enabling and disabling hclk explicitly only around the
> > > > early register access before Runtime PM takes over.
> > > > 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> > > > so Runtime PM solely owns hclk afterward.
> > >
> > > Note that runtime PM can be disabled at build time so we might not have
> > > runtime PM at all...
> > >
> >
> > Thanks for pointing this out. You're right that with !CONFIG_PM, the
> > driver only relies on the
> > two manual calls to rokchip_sai_runtime_resume() / suspend(), so hclk
> > stays enabled the
> > whole time. I understand this is unvavoidable in that configuration,
> > throgh, since there's no
> > Runtime PM to re-enable the clock when it's needed.
> >
> > I'll update the commit message to reflect that the driver uses a
> > combination of Runtime PM
> > and explicit manual enable/disable, rather than relying on Runtime PM alone.
> >
> > > > Links:
> > > > 1 This change is based on the discussion around manual hclk handing during probe(),
> > > > as raised by Krysztof:
> > > > https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> > > > 2 Background for the earlier devm_clk_get_enbabled() conversion:
> > > > https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> > >
> > > > An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> > > > manage clock enablement around register accesses. If preferred, I can rework the
> > > > driver accordingly.
Hm, I'm worried only ungating the clock around register accesses isn't
going to go well if the clock is needed by the internal logic of the
device as well.
> > >
> > > > - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> > > > + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> > > > if (IS_ERR(sai->hclk))
> > > > return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> > > > "Failed to get hclk\n");
> > > >
> > > > + ret = clk_prepare_enable(sai->hclk);
> > > > + if (ret)
> > > > + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> > > > +
> > >
> > > > @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> > > > pm_runtime_use_autosuspend(&pdev->dev);
> > > > pm_runtime_put(&pdev->dev);
> > > >
> > > > - clk_disable_unprepare(sai->hclk);
> > > > -
> > > > return 0;
> > >
> > > Are you sure that the runtime PM state there is such that it knows a
> > > reference is held? The driver used pm_runtime_get_noresume() so the
> > > device didn't have RPM_ACTIVE set I think?
> >
> >
> > You are right, pm_runtime_get_noresume() doesn't set RPM_ACTIVE. I
> > think we need to add
> > pm_runtime_set_active() before pm_runtime_enable(). Otherwise, with CONFIG_PM,
> > the pm_runtime_put() at the end of probe() might skip the suspend,
> > since the core still considers
> > the device suspended .
Agreed, this needs fixing. That is an odd behaviour of the PM API.
> >
> > >
> > > The runtime PM API really is a miserable collection of landmines :(
> >
> > Yeah, plenty of landmines indeed :(
> > I checked, and rockchip_spdif.c does use devm_regmap_init_mmio_clk() for hclk,
> > rather than wrapping every register access in pm_runtime_get_sync() /
> > pm_runtime_put()
> > the way rockchip_sai does.
> >
> > Best regards,
> > Phuc
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
2026-07-21 12:08 ` Nicolas Frattaroli
@ 2026-07-22 11:50 ` Bui Duc Phuc
0 siblings, 0 replies; 6+ messages in thread
From: Bui Duc Phuc @ 2026-07-22 11:50 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Mark Brown, Heiko Stuebner, Liam Girdwood, Krzysztof Kozlowski,
Jaroslav Kysela, Takashi Iwai, linux-sound, linux-rockchip,
linux-arm-kernel, linux-kernel
Hi Nicolas,
Thanks for confirming and for the detailed feedback.
> > Regarding the case where PM configuration is not enabled, with the old
> > source code, I suspect there is an unbalanced clk_disable_unprepare()
> > call on hclk when the driver is unbound after a successful probe under
> > CONFIG_PM=n.
>
> If "old source code" refers to what's currently in the tree with the
> devm_clk_get_enabled, then yes. There's the manual resume function
> call which isn't balanced.
>
> I think your follow-up patch does make sense in light of that.
>
> > I noticed that Nicolas tested and ACKed the use of devm_clk_get_enabled(),
> > so I'm not sure whether that testing included the CONFIG_PM=n configuration.
>
> Nope, I basically never build with PM/RPM disabled.
>
> > > You are right, pm_runtime_get_noresume() doesn't set RPM_ACTIVE. I
> > > think we need to add
> > > pm_runtime_set_active() before pm_runtime_enable(). Otherwise, with CONFIG_PM,
> > > the pm_runtime_put() at the end of probe() might skip the suspend,
> > > since the core still considers
> > > the device suspended .
>
> Agreed, this needs fixing. That is an odd behaviour of the PM API.
>
I'll update the commit message accordingly and include the runtime PM state fix
in the next revision.
Best regards,
Phuc
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-07-22 11:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-06-22 0:56 [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM phucduc.bui
2026-06-22 13:04 ` Mark Brown
2026-06-23 10:53 ` Bui Duc Phuc
2026-06-24 2:37 ` Bui Duc Phuc
2026-07-21 12:08 ` Nicolas Frattaroli
2026-07-22 11:50 ` Bui Duc Phuc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®