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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
