Kevin, On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman <khil...@ti.com> wrote: > Jean Pihet <jean.pi...@newoldbits.com> 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-pi...@ti.com> > > 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. > 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? > This might also give some incentive > for a PM QoS bus throughput constraint as well. Sure the tput constraints should be implemented as well. > > Of course, Paul can make the final decision there whether to remove it > now, but I think it's time. > > Just to prove it's usefulness (or lack thereof), Here's a hack that > combined with your patch 1/8 shows that it is pretty easy to remove. > > Kevin Thanks! Jean -- 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
