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?
Benoit
--
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
