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. 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
