Hi Amit,
I'm not sure that using the trip index for setting the state of a
cooling device is a generic solution because you are adding a
dependency between the trip index and the cooling device state that
might be difficult to handle. This dependency implies that a cooling
device like
On Fri, Dec 16, 2011 at 06:30:59PM +0800, Richard Zhao wrote:
+
+ if (higher cpu_reg)
+ regulator_set_voltage(cpu_reg,
+ cpu_volts[index], cpu_volts[index]);
This is really bad, you're only supporting the configuration of a
specific voltage which
On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote:
It support single core and multi-core ARM SoCs. But currently it assume
all cores share the same frequency and voltage.
My comments on the previous version of the patch still apply:
- The voltage ranges being set need to be
On 12/19/2011 07:59 PM, Richard Zhao wrote:
On Mon, Dec 19, 2011 at 09:00:44AM -0600, Rob Herring wrote:
On 12/19/2011 08:39 AM, Jamie Iles wrote:
On Mon, Dec 19, 2011 at 10:19:29PM +0800, Richard Zhao wrote:
On Mon, Dec 19, 2011 at 10:05:12AM +, Jamie Iles wrote:
Hi Richard,
On Mon,
On Tuesday 20 December 2011, Richard Zhao wrote:
+Generic cpufreq driver
+
+Required properties in /cpus/cpu@0:
+- compatible : generic-cpufreq
I'm not convinced this is the best way to do this. By requiring a
generic-cpufreq compatible string we're encoding Linux driver
On Tuesday 20 December 2011, Andy Green wrote:
but your suggestion is more elegant. I'm unsure of the ramifications of
the 2G / 2G scheme so I'll give it a try later.
WFIW, the main reason why people don't want the 2G/2G split is to allow
user space application to grow to 3GB instead of
On Tue, 20 Dec 2011, peter green wrote:
Joseph S. Myers wrote:
The most obvious users of these definitions would be (native) GDB and
gdbserver - do those still build OK (i.e. include the correct headers to get
the definitions they need and not rely on any definitions that were removed)
On Tue, 2011-12-20 at 15:44 +0800, Andy Green wrote:
but your suggestion is more elegant. I'm unsure of the ramifications of
the 2G / 2G scheme so I'll give it a try later.
Android requires a 3G/1G split. (That may, or may not be relevent.)
--
Tixy
Hello,
On Tuesday, December 20, 2011 4:45 PM Arnd Bergmann wrote:
On Tuesday 20 December 2011, Andy Green wrote:
but your suggestion is more elegant. I'm unsure of the ramifications of
the 2G / 2G scheme so I'll give it a try later.
WFIW, the main reason why people don't want the 2G/2G
where does it mandate 3G/1G in Android?
we're planning to use 2G/2G split as well, but I'm unaware of the
3G/1G requirement in Android, seems odd to me.
Thanks,
Xianghua
On Tue, Dec 20, 2011 at 10:48 AM, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2011-12-20 at 15:44 +0800, Andy Green
On Tue, 2011-12-20 at 12:45 -0600, Xianghua Xiao wrote:
where does it mandate 3G/1G in Android?
we're planning to use 2G/2G split as well, but I'm unaware of the
3G/1G requirement in Android, seems odd to me.
I think there are some user libraries (bionic?, dalvik?) which are hard
coded to
在 2011-12-20 下午11:22，Arnd Bergmann a...@arndb.de写道：
On Tuesday 20 December 2011, Richard Zhao wrote:
+Generic cpufreq driver
+
+Required properties in /cpus/cpu@0:
+- compatible : generic-cpufreq
I'm not convinced this is the best way to do this. By requiring a
在 2011-12-20 下午11:13，Rob Herring robherri...@gmail.com写道：
On 12/19/2011 07:59 PM, Richard Zhao wrote:
On Mon, Dec 19, 2011 at 09:00:44AM -0600, Rob Herring wrote:
On 12/19/2011 08:39 AM, Jamie Iles wrote:
On Mon, Dec 19, 2011 at 10:19:29PM +0800, Richard Zhao wrote:
On Mon, Dec 19, 2011
On Tue, Dec 20, 2011 at 07:16:56PM +, Jon Medhurst (Tixy) wrote:
On Tue, 2011-12-20 at 12:45 -0600, Xianghua Xiao wrote:
where does it mandate 3G/1G in Android?
we're planning to use 2G/2G split as well, but I'm unaware of the
3G/1G requirement in Android, seems odd to me.
I think
On Tue, Dec 20, 2011 at 02:59:04PM +, Mark Brown wrote:
On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote:
It support single core and multi-core ARM SoCs. But currently it assume
all cores share the same frequency and voltage.
My comments on the previous version of the patch
On Wed, Dec 21, 2011 at 07:27:03AM +0800, Richard Zhao wrote:
On Tue, Dec 20, 2011 at 02:59:04PM +, Mark Brown wrote:
My comments on the previous version of the patch still apply:
- The voltage ranges being set need to be specified as ranges.
cpu normally need strict voltages. and
Joseph S. Myers wrote:
The most obvious users of these definitions would be (native) GDB and
gdbserver - do those still build OK (i.e. include the correct headers to
get the definitions they need and not rely on any definitions that were
removed) after this patch?
I have built the debian
Hi Mark,
On Tue, Dec 20, 2011 at 11:48:45PM +, Mark Brown wrote:
On Wed, Dec 21, 2011 at 07:27:03AM +0800, Richard Zhao wrote:
On Tue, Dec 20, 2011 at 02:59:04PM +, Mark Brown wrote:
My comments on the previous version of the patch still apply:
- The voltage ranges being set
On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote:
On Tue, Dec 20, 2011 at 11:48:45PM +, Mark Brown wrote:
Note also that not all hardware specifies things in terms of a fixed set
of operating points, sometimes only the minimum voltage specification is
varied with frequency
On Wed, Dec 21, 2011 at 01:32:21AM +, Mark Brown wrote:
On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote:
On Tue, Dec 20, 2011 at 11:48:45PM +, Mark Brown wrote:
Note also that not all hardware specifies things in terms of a fixed set
of operating points, sometimes
On Wed, Dec 21, 2011 at 10:24:53AM +0800, Richard Zhao wrote:
On Wed, Dec 21, 2011 at 01:32:21AM +, Mark Brown wrote:
That's not the point - the point is that you may do something like
specify a defined set of frequencies and just drop the minimum supported
voltage without altering the
On Wed, Dec 21, 2011 at 02:33:36AM +, Mark Brown wrote:
On Wed, Dec 21, 2011 at 10:24:53AM +0800, Richard Zhao wrote:
On Wed, Dec 21, 2011 at 01:32:21AM +, Mark Brown wrote:
That's not the point - the point is that you may do something like
specify a defined set of frequencies
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cufreq. But this has to
be done again in cooling devices so to make the cooling devices generic and
to avoid the temperature comparision again
Hi Vincent,
Thanks for the review.
Well actually your are correct that current temperature and last
temperature can be used to increase or decrease the cpu frequency. But
this has to be done again in cooling devices so to make the cooling
devices generic and to avoid the temperature comparison
From e4db974edb5c46360465462518a88b83f1bdedf6 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov dmitry.anti...@linaro.org
Date: Wed, 21 Dec 2011 10:57:08 +0400
Subject: [PATCH] omap: use usleep_range() instead of mdelay()/udelay()
---
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
From 00753f3d48c4b6c45c1778c3e37bc9949ed79e77 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov dmitry.anti...@linaro.org
Date: Wed, 21 Dec 2011 11:01:42 +0400
Subject: [PATCH] regulator: use usleep_range() instead of mdelay()/udelay()
---
drivers/regulator/core.c |7 +--
1 files changed, 1
From ac60fe289eef3d81009f2b14a12acbac3e71878b Mon Sep 17 00:00:00 2001
From: Dmitry Antipov dmitry.anti...@linaro.org
Date: Wed, 21 Dec 2011 11:05:27 +0400
Subject: [PATCH] ohci-hcd: use usleep_range() instead of mdelay()
---
drivers/usb/host/ohci-hcd.c |4 +++-
1 files changed, 3
27 matches
Mail list logo
