[RFC/RFT 2/6] clk: qcom: Add runtime support to handle clocks using PM clocks

Geert Uytterhoeven geert at linux-m68k.org
Wed Apr 29 04:30:02 PDT 2015


Hi Rajendra,

On Wed, Apr 29, 2015 at 11:49 AM, Rajendra Nayak <rnayak at codeaurora.org> wrote:
>>> I guess I can also control the rest of the devices the same way, just
>>> that the genpd on/off for them would do nothing.
>>> That way I don't have to use pm_clk_add_notifier() and can also
>>> associate the power domain (with no on/off control) to devices
>>> through DT (and there isn;t any duplication of code in the drivers)
>>
>>
>> That looks similar to what we have on R-Mobile: some devices are in
>> controllable power areas, other are in an "always on" power area. All
>> (most)
>> devices have controllable clocks, which we also control through the PM
>> domain. "git grep sysc-rmobile" will point you to the related code and
>> DTS.
>
> Geert, thanks, I was wondering how you handle the !CONFIG_PM case for
> rmobile. I mean who turns the clocks on for the devices when you build
> with CONFIG_PM disabled?

We still use pm_clk_add_notifier() in drivers/sh/pm_runtime.c if
CONFIG_PM_GENERIC_DOMAINS_OF=n. Hence the second instance of
pm_clk_notify() will enable the clocks at driver binding time.
Hardware power domains are assumed enabled by reset state/the boot
loader.

Given the amount of PM infrastructure involved when hardware power and
clock domains are involved, I think at one point we'll have to start restricting
our builds to CONFIG_PM=y.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

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



More information about the linux-arm-kernel mailing list