Hi,
I have one pandboard (4430), however, it's said the audio and
audiohw not supported in the Linaro android release 11.11 or 11.12,
so is there one way to add the support manually ? if yes, where to
begin ? I am also interested in enabling the video hw support for the
board, but no idea unt
From ac60fe289eef3d81009f2b14a12acbac3e71878b Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
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 insertions(+), 1 deletions(-)
diff
From 00753f3d48c4b6c45c1778c3e37bc9949ed79e77 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
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 insertions(+), 6 deletion
From e4db974edb5c46360465462518a88b83f1bdedf6 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
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 +-
arch/arm/mach-omap2/vc.c
From f447d78db65c6675e69466e8ed08364ff065ac08 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Wed, 21 Dec 2011 10:51:03 +0400
Subject: [PATCH] mmc: use usleep_range() in mmc_delay()
---
drivers/mmc/core/core.h |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/d
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 ag
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 thi
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 freq
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 alteri
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, so
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 freq
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
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 gdb
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. a
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
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.
>
在 2011-12-20 下午11:13，"Rob Herring" 写道：
>
> 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 1
在 2011-12-20 下午11:22，"Arnd Bergmann" 写道：
>
> 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
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
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) wrote:
> On Tue, 2011-12-20 at 15:44 +0800, Andy Green wrote:
>> but yo
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
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
___
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 remove
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 limi
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 compatibl
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, 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 specif
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 w
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 cpufreq_cool
29 matches
Mail list logo
