[PATCH 2/8] ARM: OMAP2+: PM: introduce power domains functional states
Menon, Nishanth
nm at ti.com
Fri Jul 13 03:27:49 EDT 2012
On Fri, Jul 13, 2012 at 2:18 AM, Jean Pihet <jean.pihet at newoldbits.com> wrote:
[..]
>> Santosh pointed me to the thread offline. This is indeed a much better
>> approach IMHO than having 3 conflicting options inside powerdomain
>> framework.
> After looking at the code and having sent my comments, I like it ...
> mainly because it is really similar to my proposal ;-p
> Can you elaborate more on 'having 3 conflicting options inside
> powerdomain framework'?
Current code has:
a) PWRDM_POWER_XYZ -> describe power state
b) PWRSTS_XYZ ->meant to describe supported states for each pwrdm
this patch introduces:
a) PWRDM_POWER_XYZ -> describe power state (only for powerdomain*.[ch])
b) PWRSTS_XYZ ->meant to describe supported states for each pwrdm
c) PWRDM_FUNC_XYZ -> for files other than powerdomain*.[ch]
https://patchwork.kernel.org/patch/1160431/
maintains
a) PWRDM_POWER_XYZ -> describe power state
b) PWRSTS_XYZ ->meant to describe supported states for each pwrdm
i) reduces code churn
ii) supports logic pwr handling within existing framework
iii) no conflicting usage beyond known definition and usage. (though
personally, I;d like to see PWRSTS_XYZ dissappear into private
header..
> Here are the main differences in the implementation:
> - the RFC code provides a _private header file, which forces the
> external users (cpuidle, pmXXXX.c etc.),
That is one of the reasons I like it. I need to have a code which will
be maintained beyond the original code creators - reduced ability to
mess up the code by "not-well-informed" developers is paramount
importance for me.
> - the RFC code still uses the same function names while my code
> renames them to '*_func_*'. This makes the code look more complicated
> than it really is.
True. But, it paves the way to move all functions that is not intended
to be used beyond powerdomain files to a private power domain header -
which achieves the same objective without code churn.
Regards,
Nishanth Menon
More information about the linux-arm-kernel
mailing list