Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform

Hi, Amit, On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote: > Hi Len/Rui, > > Any comment or feedback from your side about the status of this patch? > Is it merge-able or major re-work is needed? I have fixed most of the > comments in this patchset and currently working on some of the minor >

Re: [PATCH 00/17][V2] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups

Daniel Lezcano writes: > This patchset makes some cleanup on these cpuidle drivers > and consolidate the code across both architecture. Thanks for this really nice cleanup. I have some comments on specific patches, but here's some general comments: Some minor comments: First, please be sure a

Re: [PATCH 10/17][V2] ARM: OMAP3: cpuidle - remove the 'valid' field

Daniel Lezcano writes: > With the previous changes all the states are valid, except > the last state which can be handled by decreasing the number > of states. > > Signed-off-by: Daniel Lezcano > Reviewed-by: Jean Pihet > --- > arch/arm/mach-omap2/cpuidle34xx.c | 12 +++- > 1 files c

Re: [PATCH 11/17][V2] ARM: OMAP3: cpuidle - remove cpuidle_params_table

Daniel Lezcano writes: > We do not longer need the ''cpuidle_params_table' array as > we defined the states in the driver and we checked they are > all valid. > > We also remove the structure definition as it is no longer used. > > Signed-off-by: Daniel Lezcano > Reviewed-by: Jean Pihet > --- >

Re: [PATCH 06/17][V2] ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly

Daniel Lezcano writes: > We are storing the 'omap4_idle_data' in the private data field > of the cpuidle device. As we are using this variable only in this file, > that does not really make sense. Let's use the global variable directly > instead dereferencing pointers in an idle critical loop. D

Re: [PATCH 07/17][V2] ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time

Daniel Lezcano writes: > We initialized it at compile time, no need to do that at boot > time. > > Signed-off-by: Daniel Lezcano > Reviewed-by: Jean Pihet > Reviewed-by: Santosh Shilimkar > --- > arch/arm/mach-omap2/cpuidle44xx.c | 26 +- > 1 files changed, 1 inserti

Re: [PATCH 04/17][V2] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration

Daniel Lezcano writes: > Signed-off-by: Daniel Lezcano > Reviewed-by: Jean Pihet > Reviewed-by: Santosh Shilimkar Missing changelog. Kevin > --- > arch/arm/mach-omap2/cpuidle44xx.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/cpuidle44x

Re: [PATCH 02/17][V2] ARM: OMAP4: cpuidle - Declare the states with the driver declaration

Daniel Lezcano writes: > The cpuidle API allows to declare statically the states in the driver > structure. Let's use it. > We do no longer need the fill_cstate function called at runtime and > by the way adding more instructions at boot time. > > Signed-off-by: Daniel Lezcano > Reviewed-by: Jea

Re: qemu & hardware gfx acceleration

On 9 April 2012 20:13, John Stultz wrote: > So the Google Android team just posted this: > http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html > > Which shows their device emulator running w/ hardware acceleration.  Since I > know they started with

Linaro 12.04 3.4-rc1 based androidization branch is available

I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. You can grab it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4-jstultz-rebase thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists

Re: qemu & hardware gfx acceleration

On 10 April 2012 07:13, John Stultz wrote: > So the Google Android team just posted this: > http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html > > Which shows their device emulator running w/ hardware acceleration.  Since I > know they started wit

qemu & hardware gfx acceleration

So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-with-better-hardware.html Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as

Call for testing Linaro Android 12.04 candidates

We have prepared Linaro Android 12.04 candidates. Spreadsheets have been updated. Please, run the tests that have a 'w' after them. Thanks! Testers, builds and spreadsheets Jon https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc46-armlt-stable

Re: won't someone please think of the users!?

On Fri, Apr 6, 2012 at 2:59 PM, Nicolas Pitre wrote: > On Fri, 6 Apr 2012, Ricardo Salveti wrote: > >> On Fri, Apr 6, 2012 at 6:05 AM, Wookey wrote: >> > The fundamental question really is 'are we a distro or not'? If linaro >> > is not a distro then no-one should be expecting stable releases - w

Re: [RFC] Scheduler recorder and playback

Hi Dmitry, On Apr 9, 2012, at 1:07 PM, Dmitry Antipov wrote: > On 04/04/2012 05:10 PM, Pantelis Antoniou wrote: > >> The reason for the slowdown is that perf sched record default settings is >> tuned for x86 pretty much, and there's a huge amount of data being generated. >> >> perf sched recor

Re: [RFC] Scheduler recorder and playback

On 04/04/2012 05:10 PM, Pantelis Antoniou wrote: The reason for the slowdown is that perf sched record default settings is tuned for x86 pretty much, and there's a huge amount of data being generated. perf sched record is just a wrapper for perf record so try using this script for recording: