Re: [PATCH v4 7/8] qcom: cpuidle: Add cpuidle driver for QCOM cpus

[Lina Iyer <lina.iyer@linaro.org>]

On Wed, Aug 27, 2014 at 10:31:26AM -0700, Kevin Hilman wrote:
>Lina Iyer <lina.iyer@linaro.org> writes:
>
>> On Thu, Aug 21, 2014 at 03:24:44AM +0200, Daniel Lezcano wrote:
>>>On 08/20/2014 12:15 AM, Lina Iyer wrote:
>
>[...]
>
>>>
>>> So IIUC, if you specify the index 1, that means the state[0] will be
>>> the default WFI. But you override the callback below in the loop.
>>>
>>> I recommend you use the default arm wfi callback but you implement
>>> the cpu_do_idle for your platform.
>>
>> Yes, it was intended. I dont want to define two WFI states. The
>> architectural WFI does not buy us enough compared to WFI that SoC can
>> do. L2 can go into low power modes when the core is in WFI and for that
>> I would like to have all WFI's enter SoC framework.
>
>If the L2 is going into low-power, that means there will be higher
>latency coming out compared to the architectural WFI, correct?
>
Thats right. Architecturally L2 deeper sleep modes (which include L2
logic off) may reset the core. So L2 deeper sleep modes with cores in
WFI is not a suggested possibility.

>If you have both, and the latency/residency numbers are accurate, the
>governor is then left to pick the right one.  So, what's wrong with
>having both?
I agree, but there is very little benefit to doing architectural WFI vs
platform WFI in most cases. The residencies are too close and almost the
same, doesnt warrant a separate functions for that. There is no thing
wrong, just dint see a lot of benefit, thats all. What do you think?

>
>Kevin
>