Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: > Kevin, > > On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman <khilman@xxxxxx> wrote: >> Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: >> >>> Implement the devices wake-up latency constraints using the global >>> device PM QoS notification handler which applies the constraints to the >>> underlying layer by calling the corresponding function at hwmod level. >>> >>> Note: the bus throughput function is implemented but currently is >>> a no-op. A new PM QoS class for the bus throughput needs to be >>> added. >>> >>> Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up >>> latency constraints on MPU, CORE and PER. >>> >>> Signed-off-by: Jean Pihet <j-pihet@xxxxxx> >> >> This patch does 2 things. >> >> 1) removes the MPU lat stuff from the OMAP PM layer (since it's now >> available in a generic form >> 2) implements device wake-up latency constraints >> >> This should be broken up into two parts. >> >> Also, this patch seems to remove a bunch of stuff that was just added in >> patch 2/8. Probably best to create the new OMAP PM layer after remving >> the unused stuff. >> >> It think the code using the new per-device PM QoS API should also live >> outside the OMAP PM layer, since it's not related, and we want to get >> rid of the OMAP PM layer eventually. >> >> Speaking of which..., the more I think about it, the more I think we >> should take this opportunity to clean and/or remove the OMAP PM layer >> completely. > > > I agree completely, the OMAP PM 'plugin' layer is useless and anyway > an empty implementation for now. Great, let's wait for Paul's view on this since he's the maintainer of the OMAP PM layer. >> With your work, other than the no-op bus throughput API, it's basically >> unused. I think that rather than creating a new OMAP PM layer just to >> have a a no-op bus throughput function here, I think it's time >> to remove OMAP PM completely. > > Ok. The only useful code is to register a PM QoS notifier in order to > apply the constraints to the power domains. > Are you suggesting to move this code to e.g. pmxxx.c? Yes, or simply pm-constraints.c since I guess it should be SoC-independent. Kevin -- 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
