Hi Kevin,

On 05/08/2012 04:28 PM, Kevin Hilman wrote:

Jon Hunter [off-list ref] writes:

quoted

On 05/08/2012 11:18 AM, Kevin Hilman wrote:

quoted

"Cousson, Benoit" [off-list ref] writes:

quoted

On 5/8/2012 4:00 PM, Kevin Hilman wrote:

quoted

Jean Pihet[off-list ref]  writes:

[...]

quoted

quoted

quoted

quoted

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.

I had to make a couple mods to Ming's patches but I do have something
working now that _should_ not break PM. However, per my previous email
(in response to Benoit's) I am struggling with the definition of the
CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this.

I was going to send out my patches, but I wanted to get some more
feedback on this first.

While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and
CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle
transition (and reset.)

Unfortunately, not. By setting CAN_HWSUP, the EMU CD will be put back
into HW_AUTO state when it is enabled. The hwmod _enable() function will
first put the CD into SW_WKUP (because CAN_FORCE_WAKEUP is set), but
because it was previously in HW_AUTO state AND CAN_ENABLE_AUTO is set it
will be be put back into HW_AUTO again. Hence, we are back where we begun!

CAN_ENABLE_AUTO is causing me a headache, because whenever you call
clkdm_allow_idle, it will allow it to idle and this happens during the
_enable() sequence :-(

Does this make sense?

Cheers
Jon