[PATCH 03/12] PM / Domains: Add notifier support for power domain transitions

amit daniel kachhap amit.daniel at samsung.com
Mon Nov 3 22:44:12 PST 2014


On Mon, Nov 3, 2014 at 11:53 PM, Kevin Hilman <khilman at kernel.org> wrote:
> +Mike Turquette
>
> Hi Amit,
>
> "Rafael J. Wysocki" <rjw at rjwysocki.net> writes:
>
>> CC: Kevin, Ulf, Geert.
>>
>> On Monday, November 03, 2014 09:23:01 AM Amit Daniel Kachhap wrote:
>>> These power domain transition notifiers will assist in carrying
>>> out some activity associated with domain power on/off such as
>>> some registers which may lose its contents and need save/restore
>>> across domain power off/on.
>
> The runtime PM framework already provides callbacks that are useful for
> context save/restore for devices.  Could you please describe in more
> detail which registers in which kind of devices need to be
> saved/restored, and why they cannot be saved/restored using existing
> mechanisms.
Basically the requirement is mandated by exynos7 manual. It tells that
before turning off the power domain, some clock registers need to saved
and should be restored just after turning the power domain. These clock
registers are not necessarily gate clocks but could be mux clocks etc.
The driver may not have all information of these clocks also. I suppose
these are Soc specific changes but drivers should work across Socs.
This behavior is almost similar to suspend/resume case where a whole
list of clock registers are saved/restored.

Even earlier post by Sylwester (https://lkml.org/lkml/2014/8/5/182) also points
to the need of this feature.
>
> Personally, I'm uncomfortable with notifiers like this because it
> suggests that underlying frameworks are not doing the right thing, or
> are not being used.  (I also don't like the implementation here where a
> single global notifier list is maintained by the core, but the notifiers
> are actually triggered by SoC specific code.)
Yes right the global notifier block can be moved to per genpd structure.
Also SoC trigger can be moved to core files.
>
> IIUC, the usage in this series seems to be that certain clock related
> registers need to be saved/restored across a power domain transition.
>
> Wouldn't an alternative solution be to add a feature to the clock driver
> such that the state of each clock is saved when the clock is disabled,
> and restored when the clock is enabled?   That would allow any clock
> context to survive any power domain transtion also, correct?
I also thought about same. But the trigger point for this would be
driver calling
clk disable/enable and not the power domain. so this will lead to lot of
save/restore for each power domain child.
>
> I have some issues with the implementaion as well, but I think we need
> to first sort out the real need for this before going into those
> details.
right :( may be I should have posted this as RFC
Thanks for the review.

Regards,
Amit D
>
> Kevin
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



More information about the linux-arm-kernel mailing list