> The driver calls pm_runtime_set_active() during ->probe(), which means > genpd's ->runtime_resume() callback isn't invoked during that point. > In other words, the clocks managed by the clock domain isn't enabled > during ->probe() as genpd's doesn't get to run pm_clk_resume() from > its ->runtime_resume() callback. Unless I am missing something. :-) So, in my words: in that case, the device is not really active since the clocks are not enabled? > I think this is the reason to the following problems. How to fix it? > > The driver needs to call pm_runtime_get_sync() instead of > pm_runtime_set_active(), however that may requires some careful > changes if one wants the driver to be able to enable clocks also when > CONFIG_PM is unset. We have tmio_mmc_clk_enable() already for that, I'd think. Or am I misunderstanding? > Add a "init" flag to host struct, and set that flag before calling > pm_runtime_get_sync() in ->probe(). When the driver's > ->runtime_resume() callbacks get called when the "init" flag is set, > just do an early return 0, as t means ->probe() is running and has > already taken care of the enabling the clock. When probe is done, and > before dropping runtime usage count with pm_runtime_put(), reset the > "init" flag. Welllll... I hope we can avoid this ;) Thanks for your thoughts, Ulf. And thanks to Geert for bringing up the issue which I can reproduce here. We need to do a bigger PM re-evaluation anyhow, I'll add it to the list...
Attachment:
signature.asc
Description: PGP signature
