[...] > > Fourth & final question: I'm under the impression that pm runtime calls > be be nested and re-enter, but I want to make sure (Ulf?). For instance > it is highly likely that this new feature would cause something like: > > pm_runtime_get() - called by random driver > -> clk_prepare_enable() - genpd enables functioal clocks > -> pm_runtime_get() - called by clk_pm_runtime_get in clk core > -> clk_prepare_enable() - genpd enables interface or bus clocks > > I guess this is safe from the pm_runtime_get/genpd perspective, but want > to make sure first. I noticed Marek's reply, which perhaps is sufficient. However, to clarify also from genpd and runtime PM point of view the re-entrant issue is safe and it is already quite commonly used. For example, from a random driver's ->runtime_resume() callback clk_prepare_enable() is called. When such clock is managed behind a i2c interface the i2c controller also needs to be runtime resumed, meaning its driver calls pm_runtime_get_sync(), before it can serve the request and ungate the clock. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |