Hi Kevin, On 05/08/2012 04:28 PM, Kevin Hilman wrote: > Jon Hunter <jon-hunter@xxxxxx> writes: > >> On 05/08/2012 11:18 AM, Kevin Hilman wrote: >>> "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. >> >> 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 -- 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
