oprofile and ARM A9 hardware counter

[Kevin Hilman]

Jon Hunter <jon-hunter at ti.com> writes:

> On 05/08/2012 11:18 AM, Kevin Hilman wrote:
>> "Cousson, Benoit" <b-cousson at ti.com> writes:
>> 
>>> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>>>> Jean Pihet<jean.pihet at newoldbits.com>  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.)

Kevin