Re: SDHI clock imbalance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux