oprofile and ARM A9 hardware counter

[Cousson, Benoit]

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?

Benoit