Hi Rajendra,
On Wed, Apr 29, 2015 at 11:49 AM, Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> 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@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-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
