Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
Bui Duc Phuc <[email protected]>
| Newsgroups | org.infradead.lists.linux-rockchip,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound |
|---|---|
| Message-ID | <CAABR9nEbm2UdqdE6hCrW0RJOqp26=A8CPPSfCTxDHy7=zx_jFw@mail.gmail.com> |
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 _______________________________________________ Linux-rockchip mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-rockchip