Re: oprofile and ARM A9 hardware counter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?

To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux