Andy,
TI seems to be happy with the cpuidle driver based on Colin's couple C-state work. Santosh has provided a branch at the end of this message that is rebased on top of 3.4-rc2. Can we fold this into the TILT tree for April?
Daniel,
You should provided a consolidated version of your fixes and cleanups to the various LTs too.
/Amit
---------- Forwarded message ---------- From: Santosh Shilimkar santosh.shilimkar@ti.com Date: Mon, Apr 9, 2012 at 10:11 AM Subject: Re: [PATCHv2 0/5] coupled cpuidle state support To: Colin Cross ccross@android.com Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@lists.linux-foundation.org, Kevin Hilman khilman@ti.com, Len Brown len.brown@intel.com, Trinabh Gupta g.trinabh@gmail.com, Arjan van de Ven arjan@linux.intel.com, Deepthi Dharwar deepthi@linux.vnet.ibm.com, Greg Kroah-Hartman gregkh@suse.de, Kay Sievers kay.sievers@vrfy.org, Daniel Lezcano daniel.lezcano@linaro.org, Amit Kucheria < amit.kucheria@linaro.org>, Lorenzo Pieralisi lorenzo.pieralisi@arm.com, Rob Lee rob.lee@linaro.org
On Friday 30 March 2012 06:23 PM, Santosh Shilimkar wrote:
Colin,
On Friday 16 March 2012 05:07 AM, Colin Cross wrote:
On Wed, Mar 14, 2012 at 11:29 AM, Colin Cross ccross@android.com wrote:
[...]
v2:
- removed the coupled lock, replacing it with atomic counters
- added a check for outstanding pokes before beginning the final transition to avoid extra wakeups
- made the cpuidle_coupled struct completely private
- fixed kerneldoc comment formatting
- added a patch with a helper function for resynchronizing cpus after aborting idle
- added a patch (not for merging) to add trace events for verification and performance testing
I forgot to mention, this patch series is on v3.3-rc7, and will conflict with the cpuidle timekeeping patches. If those go in first (which is likely), I will rework this series on top of it. I left it on v3.3-rc7 now to make testing easier.
I have re-based your series against Len Browns next branch [1] which has time keeping and other cpuidle patches. Have also folded the CPU hotplug fix which I posted in the original coupled idle patch.
As you know, we have been playing around this series for OMAP for last few weeks. This version series seems to work as intended and found it pretty stable in my testing. Apart from the cpu hotplug fix and the trace event comment, series looks fine to me.
FWIW, Reviewed-by: Santosh Shilimkar santosh.shilimkar@ti.com Tested-by: Santosh Shilimkar santosh.shilimkar@ti.com
An updated version of this series along with OMAP cpuidle driver updates against 3.4-rc2 is available here [1] in case some body is interested looking at it.
Regards Santosh
[1] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/coupled_cpuidle-rebase
On 04/10/2012 04:54 PM, Somebody in the thread at some point said:
Hi -
TI seems to be happy with the cpuidle driver based on Colin's couple C-state work. Santosh has provided a branch at the end of this message that is rebased on top of 3.4-rc2. Can we fold this into the TILT tree for April?
In the new tree the plan is that topic owners will provide us updates tracking topics. Although that is definitely the preferred way forward, right now we don't have anything past v3.3.
Assuming we do get new pieces soon, it'll probably be Santosh giving us the core and pm topic content against v3.4-rc1, presumably that will be including this and anything else that looks useful.
However unlike until now where I sat down and rebased our stuff randomly and continuously on Linus HEAD, this is now a more collaborative approach that means I am stuck until I get new topic content on an arranged basis from hopefully a number of contributors. And I think each time lots of it will be new content compared to old way of dragging aging stuff along while daubing fresh makeup on it.
So we're both far more empowered and integrated to TI topic domain expertise with this scheme and less fluid to the point I can't predict when we have 3.4-rc1 build to offer.
On the plus side though, v3.3 stuff we do have is in very good shape now.
-Andy