Hi, * Tero Kristo <t-kristo@xxxxxx> [181130 09:21]: > On 30/11/2018 09:57, Stephen Boyd wrote: > > No that is not preferred. Can the omap2_clk_deny_idle() function be > > integrated closer into the clk framework in some way that allows it to > > be part of the clk_ops structure? And then have that take a clk_hw > > structure instead of a struct clk? I haven't looked at this in any > > detail whatsoever so I may be way off right now. > > It could be added under the main clk_ops struct, however this would > introduce two new func pointers to it which are not used by anything else > but OMAP. Are you aware of any other platforms requiring similar feature? >From consumer usage point of view, I'm still wondering about the relationship of clk_deny_idle() and clkdm_deny_idle(). It seems that we need to allow reset control drivers call clk_deny_idle() for the duration of reset. And it seems the clk_deny_idle() should propagate to also up to the related clock domain driver to do clkdm_deny_idle(). So maybe clk_deny_idle() is could just be something like: dev = clk_get_device(clk); ... error = pm_runtime_get(dev); ... pm_runtime_put(dev); ... And that way it would just propagate to the parent clock domain driver and the clock framework does not need to know about clockdomains. A clockdomain could be just a genpd domain. Or do you guys have better ideas? Regards, Tony
