Re: oprofile and ARM A9 hardware counter

[Kevin Hilman <khilman@ti.com>]

"Cousson, Benoit" <b-cousson@ti.com> writes:

> On 5/8/2012 4:00 PM, Kevin Hilman wrote:
>> Jean Pihet<jean.pihet@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.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4