On Wed, Mar 21, 2012 at 4:13 PM, Daniel Lezcano daniel.lezcano@linaro.org wrote:
On 03/21/2012 10:56 AM, Santosh Shilimkar wrote:
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano daniel.lezcano@linaro.org wrote:
This patchset is a proposition to improve a bit the code. The changes are code cleanup and does not change the behavior of the driver itself.
Thanks. Will have a look at your series.
Cool, thanks.
A couple a things call my intention. Why the cpuidle device is set for cpu0 only
Because the mainline code CPUIDLE is supported along with CPUhotplug. This is going to change though with Couple CPUIDLE and corresponding OMAP updates.
Ok, thanks for the information. I will look deeper. What happens to cpu1 when it is online and has nothing to do ?
and why the WFI is not used ?
I didn't get this question. Do you mean the generic WFI?
I execute default idle loop.
So is it not possible to add a cpuidle device for cpu1 and define only one state for the 'wfi-for-omap' ?
That's how my post was handling it. But after the review Kevin suggested me to drop the CPU1 shallow state since it was same as default idle.
yes.
If yes, then, it's mainly because OMAP need additional custom barriers.
Ah, ok. I am not sure if it is possible but that may be cool if we can call cpu_do_idle instead with additional barrier.
There is no need. Since code around WFI is customised, it make no sense to call cpu_do_idle(0 ofr only that instruction sake.
For my personal information, why the WFI is customised for omap4 ?
OMAP4 silicon has couple of hardware issues around interconnect and needs to drain the axi buffers with strongly order writes to ensure that data reaches to peripherals and not get stuck. That lead to have custom function. Note that, the wfi instruction itself is same.