"Cousson, Benoit" <b-cousson@xxxxxx> writes: > On 5/8/2012 4:00 PM, Kevin Hilman wrote: >> Jean Pihet<jean.pihet@xxxxxxxxxxxxxx> writes: >> >> [...] >> >>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The >>>>>> flags describe what the HW is capable of, and the EMU CD can support >>>>>> HW_AUTO >>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid >>>>>> next >>>>>> power state is OFF, meaning that no retention mode is supported. So any >>>>>> transition to idle will go to OFF and lead to a reset upon wakeup. >>>>>> >>>>>> That being said, being able to transition to OFF during idle is a >>>>>> perfectly >>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to >>>>>> restore from OFF mode smoothly. >>>>>> >>>>>> It looks to me that what is missing here is *just* a restore path in the >>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue >>>>>> :-) >>>>> >>>>> Although it is perfectly feasible to have a seamless transition of the >>>>> EMU power domain, I think the PMU counters will not be accurate >>>>> anymore since they stop counting events when going to OFF and re-start >>>>> after the state restore. >>>> >>>> >>>> Good point, but I think the PMU might still works fine because located >>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is >>>> going to OFF and thus will be reset. >>> >>> Ever better point ;p Thanks for the precision. >>> In any case my point was: can we allow the EMU CD to go OFF or prevent >>> it from doing so? We need to answer that question first. >>> >> >> The idea I've suggested is to use runtime PM for this. As long as the >> PMU is in use, it will be runtime PM enabled (and not allowed to go into >> HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and >> then be reset. The next time it is needed, the runtime resume will need >> to do a full re-init. > > Oh, but does that mean that this driver is not pm_runtime adapted yet? > Actually, it is. Ming Lei has done it. Currently, Will has collected this[1] and is waiting (patiently) for us to produce a real fix that doesn't kill PM in the process. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 -- 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
