[PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer

[Cousson, Benoit]

On 6/8/2012 9:10 PM, Hiremath, Vaibhav wrote:
> On Fri, Jun 08, 2012 at 01:33:46, Paul Walmsley wrote:
>> Hi
>>
>> On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
>>
>>> I couldn't finish my testing today, got into continuous meetings.
>>
>> No worries, I understand.
>>
>>> Tomorrow, I will test it and update you on this.
>>
>> That would be great.
>>
>> I took a look at SPRUH73F and sure enough, at least one module (CONTROL)
>> doesn't support smart-idle -- per Table 14-217 "CONTROL Register Field
>> Descriptions".  I'd guess that the PRCM won't idle-req this IP block until
>> the kernel is not running, so we might be able to get away with the
>> existing approach; but the TRM also says:
>>
>> "By definition, initiator may generate read/write transaction as long as
>> it is out of IDLE state."
>>
>> Which pretty much matches my understanding too of the implicit interface
>> contract here.
>>
>> So I think we'd better go back to the flag approach as implemented in this
>> patch:
>>
>> http://www.spinics.net/lists/arm-kernel/msg176836.html
>>
>> The WBU 32k sync timer's behavior is what relies on quirks of the
>> integration that are hard to identify via other means, so it seems to be
>> safest to tag it explicitly.
>>
>
> Paul,
>
> I tested it on AM335x platform just now, it booted up to the Linux prompt,
> but I am sure it is going to impact low power state usecases on AM33xx.

Why are you sure about that? As explained to Paul, using the force-idle 
will do the same as smart-idle most of the time.

So what power impact are you expecting?

> So, I also feel that, flag based approach should be used here.

Why? Why adding a new flag to detect a condition that is already 
captured somewhere else?

Regards,
Benoit