Hi Ulf,
On Thu, Oct 16, 2014 at 3:06 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>> +
>> + ret = pm_clk_create(dev);
>> + if (ret) {
>> + dev_err(dev, "pm_clk_create failed %d\n", ret);
>> + return;
>> + };
>> +
>> + while ((clk = of_clk_get(dev->of_node, i++)) && !IS_ERR(clk)) {
>> + ret = pm_clk_add_clk(dev, clk);
>> + if (ret) {
>> + dev_err(dev, "pm_clk_add_clk failed %d\n", ret);
>> + goto clk_err;
>> + };
>> + }
>> +
>> + if (!IS_ENABLED(CONFIG_PM_RUNTIME)) {
>
> Could you elaborate on why you need to do this check here?
If runtime PM is enabled, the clocks are managed by runtime PM, and will
be enabled/disabled later when needed.
If runtime PM is disabled, the clocks are not managed by runtime PM,
so they should be enabled at initialization time.
Grygorii and I do the same thing for keystone resp. pm-rmobile.
> When I see a check for IS_ENABLED(CONFIG_PM_RUNTIME), that indicates
> to me that we actually have an another issue, perhaps in the PM clk
> API.
Good point. Perhaps this can be handled in pm_clk_add() instead?
Gr{oetje,eeting}s,
Geert
--
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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
