Jean, On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> wrote: > > Here is a re-spin after some comments and suggestions after review. > > Implement the functional states for the power domains: > - unify the API to use the functional states. pwrdm_set_next_fpwrst > now is the function to control the power domains power and logic > states, > - reorganize the powerdomain API in internal and external parts, > in powerdomain.h [1] > - protect the power domain state change by a lock in > pwrdm_set_next_fpwrst, > - introduce the functional states for power domains power states and > logic power states, and the conversion functions between the > functional and internal states, > - program the logic power state of power domains from the functional > states, in pwrdm_set_next_fpwrst > - convert the OMAP2/3/4 PM code to use the updated API, > - provide the power domains statistics by functional states, > - provide ftrace tracepoints with the functional state, > - provide error logs in critical code, which makes the development > easier. > > Note: [1] the physical split of internal and external APIs into > different header files is not part of this series, it comes as > a separate patch set. > > > Based on mainline kernel 3.6.0-rc1. > > Tested on OMAP3 Beagleboard, with suspend and cpuidle in RET and > OFF modes. > I didn't find any mention here about why are we going in this path and not in the direction proposed in another RFC [1] I have already given my comments[2] against the introduction of another PD layer which can be avoided easily as demonstrated by the RFC[1]. The comments are still applicable for this series too. We really need to reduce OMAP specific framework overhead and move towards more generic PM frameworks. For me, this series is a step back-ward from that direction. Am really sorry for being critical again but I remain unconvinced about this series and the problem it is trying to solve. May be you have valid reasons not to follow the approach in [1] and in that case, it will be good to clarify that so that some of us get to know your rationale. Regards Santosh [1] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg71732.html [2] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg69081.html -- 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
