[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4E7C686F.30608@linux.vnet.ibm.com>
Date: Fri, 23 Sep 2011 16:37:27 +0530
From: Deepthi Dharwar <deepthi@...ux.vnet.ibm.com>
To: Kevin Hilman <khilman@...com>
CC: venki@...gle.com, ak@...ux.intel.com, len.brown@...el.com,
peterz@...radead.org, santosh.shilimkar@...com,
arjan@...ux.intel.com, lenb@...nel.org, linux-sh@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-pm@...ts.linux-foundation.org, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, rmk@....linux.org.uk
Subject: Re: [RFC PATCH V6 0/4] cpuidle: Global registration of idle states
with per-cpu statistics
On Friday 23 September 2011 01:15 AM, Kevin Hilman wrote:
> Deepthi Dharwar <deepthi@...ux.vnet.ibm.com> writes:
>
>> The following patch series implements global registration of cpuidle
>> states, and also has the necessary data structure changes to
>> accommodate the per-cpu writable members of the cpuidle_states
>> structure.
>
> I reviewed earlier versions of the series, and this version still looks
> good to me. Any reason it is still RFC?
>
> Reviewed-by: Kevin Hilman <khilman@...com>
>
> and for the OMAP-specific parts,
>
> Acked-by: Kevin Hilman <khilman@...com>
>
> Kevin
>
Hi Kevin,
Thanks for reviewing the patch.
This was posted as an RFC, as there were
a couple of ToDos listed in this patch series
which I thought needed additional review before
I could ask for inclusion.
To Do :
======
1. Russell King pointed out that in (V5 1/4) of this patch in
arch/arm/mach-at91/cpuidle.c, AT91 pieces may be broken.
In at91_enter_idle() routine, folks need to fix the two
consecutive asm() statements by combining
it to one as per the GCC reference manual.
Reference:
https://lkml.org/lkml/2011/6/6/273
2. In (V6 4/4), handle the case when idle states may change at run time
and acpi_processor_cst_has_changed() routine is called in a
better way than the current solution in this patch.
In this current solution where global registration is implemented,
the boot cpu on x86 would disable all the devices, repopulate the
states and later enable all the devices, irrespective of the cpu
that would receive the notification first.
Reference:
https://lkml.org/lkml/2011/4/25/83
Thanks & Regards,
-Deepthi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists