oprofile and ARM A9 hardware counter

[Jon Hunter]

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.

Cheers
Jon