Re: [PATCH 2/8] ARM: OMAP2+: PM: introduce power domains functional states

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 13, 2012 at 2:18 AM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux