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