Hi Ulf, Tomasz, On Fri, May 2, 2014 at 10:13 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>>> +static int of_clk_register(struct device *dev, struct clk *clk) >>>> +{ >>>> + int error; >>>> + >>>> + if (!dev->pm_domain) { >>>> + error = pm_clk_create(dev); >>>> + if (error) >>>> + return error; >>>> + >>>> + dev->pm_domain = &of_clk_pm_domain; >>> >>> >>> I am concerned about how this will work in conjunction with the >>> generic power domain. >>> >>> A device can't reside in more than one pm_domain; thus I think it >>> would be better to always use the generic power domain and not have a >>> specific one for clocks. Typically the genpd should invoke >>> pm_clk_resume|suspend from it's runtime PM callbacks. >> >> I'm not sure about this. A typical use case would be to gate clocks ASAP and >> then wait until device is idle long enough to consider turning off the power >> domain worthwhile. Also sometimes we may want to gate the clocks, but >> prevent power domain from being powered off to retain hardware state (e.g. >> because there is no way to read it and restore later). > > So, in principle you prefer to have driver's handle clock gating to > save power from their runtime PM callbacks, instead of from the power > domain, right? Just to clarify, that's my view as well. If there's both a gate clock and a power domain, and the driver's Runtime PM callbacks handle clock gating, who's handling the power domain? Gr{oetje,eeting}s, Geert (still trying to fit all pieces of the puzzle together) -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html