omap3517 and omap3505 belong to OMAP3 architecture, so the cpu_is_omap34xx
will be true. Therefore, if the cpu omap3517 is a exception, we should check
whether it is omap3517 before check whether it is omap34xx.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
I've reported this issue earlier this month, unfortunately I have no clue what
is happening.
When you telnet (or ssh) to the board via Ethernet-LAN you can see that the
board is suspending
and resuming. Output to the serial console works fine. If you do:
echo Hello /dev/console
from the
Remove extra return statement in omapdss_default_get_recommended_bpp
from overlay.c
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/display.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
omap3505/omap3517 don't have the bit OMAP3430_EN_IO and the bit
OMAP3430_EN_IO_CHAIN in the register PM_WKEN_WKUP. When the system
suspend, the following messages will be printed:
Wake up daisy chain activation failed.
Now fix it by adding if (!cpu_is_omap3505() !cpu_is_omap3517()).
On Mon, 21 Jun 2010, ext Zygo Blaxell wrote:
On Mon, Jun 21, 2010 at 04:34:33PM +0300, Grazvydas Ignotas wrote:
(CC Tomi)
On Thu, Jun 17, 2010 at 12:43 AM, Zygo Blaxell
vger-linux-omap-esightc...@mailtoo.hungrycats.org wrote:
The TRM and the OMAP FB driver have different ideas about the
Kevin Hilman wrote:
Peter Tseng tsenpe...@gmail.com writes:
I am seeing some discrepancies between the Overo (I believe I have a
Water) and the Beagleboard (I have a Rev. B5) when resuming after a
suspend to RAM.
Not that it is much comfort, but I have the same problem on Overo but
don't see
* Tony Lindgren t...@atomide.com [100621 16:45]:
The TLS register is only available on ARM1136 r1p0 and later.
Set HWCAP_TLS flags if hardware TLS is available.
Note that we now use 0x0ff4 for flagging software TLS to
__kuser_get_tls, and 0x0ff8 for storing the software TLS value.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Rapoport
Sent: Tuesday, June 22, 2010 10:56 AM
To: Kevin Hilman
Cc: Peter Tseng; linux-omap@vger.kernel.org; Han Wang
Subject: Re: Overo serial problems after
Op 21 jun 2010, om 23:31 heeft Zygo Blaxell het volgende geschreven:
On Mon, Jun 21, 2010 at 04:34:33PM +0300, Grazvydas Ignotas wrote:
(CC Tomi)
On Thu, Jun 17, 2010 at 12:43 AM, Zygo Blaxell
vger-linux-omap-esightc...@mailtoo.hungrycats.org wrote:
The TRM and the OMAP FB driver have
Generation of 1ms granular GPTIMER events using 32KHz or system
clocks as inputs does not have whole number count value to load
into the register. This inaccurate count value with respect to 1ms
period leads to time drift subsequently. OMAP3 and later silicons
have dedicated registers for
Hi,
On Mon, 21 Jun 2010, ext Archit Taneja wrote:
In the case of a dispc framedone timeout, we should set the LCD_EN
bit in DISPC_CONTROL to 0 and reset the dsi tx fifo so that the next
panel update call goes through cleanly.
With the new way of handling dispc framedone interrupts, since
Benoit/Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 8:29 PM
To: Kalliguddi, Hema
Cc: Cousson, Benoit; Basak, Partha; p...@pwsan.com; Nayak, Rajendra;
linux-omap@vger.kernel.org
Subject: Re: On the APIs for Enabling
Hi!
(ok, so I'm little late to the party).
Nonsense, if we want to push the system into suspend from the idle
state we can do that. It's just not implemented and we've never tried
to do it as it requires a non trivial amount of work, but I have done
it on an ARM two years ago as a prove
On Sat, May 8, 2010 at 5:25 AM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, May 06, 2010 10:31 AM
To: Madhusudhan
Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org;
linux-...@vger.kernel.org
-Original Message-
From: zhangfei gao [mailto:zhangfei@gmail.com]
Sent: Tuesday, June 22, 2010 4:51 PM
To: Chikkature Rajashekar, Madhusudhan
Cc: Tony Lindgren; Menon, Nishanth; Ghorai, Sukumar; linux-
o...@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH]
From: Senthilvadivu Guruswamy svad...@ti.com
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/plat-omap/include/plat/vrfb.h | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff
From: Senthilvadivu Guruswamy svad...@ti.com
Force def_vrfb to 0 for non omap2, omap3 devices
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git
config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/omapfb/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/Kconfig
b/drivers/video/omap2/omapfb/Kconfig
From: Senthilvadivu Guruswamy svad...@ti.com
Please ignore the previous v3 and consider v4.
The changelog till v4 are:
- Address Multi-omap build issue
- Added a check to warn the wrong usage of vrfb
in non-vrfb omap devices.
- The patch subject is as per the
-Original Message-
From: Guruswamy, Senthilvadivu
Sent: Monday, June 21, 2010 2:52 PM
To: Hiremath, Vaibhav; Tomi Valkeinen
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
t...@atomide.com
Subject: RE: [PATCH v3 2/3] OMAP: DSS2: OMAPFB: make VRFB
depends on OMAP2,3
On Mon, 2010-06-21 at 14:51 +0100, Tony Lindgren wrote:
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 315a540..19ba626 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -549,10 +549,14 @@ static int __init vfp_init(void)
/*
* Catalin Marinas catalin.mari...@arm.com [100622 15:53]:
On Mon, 2010-06-21 at 14:51 +0100, Tony Lindgren wrote:
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 315a540..19ba626 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -549,10
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 17, 2010 10:13 PM
To: Varadarajan, Charulatha
Cc: Cousson, Benoit; davi...@pacbell.net;
broo...@opensource.wolfsonmicro.com;
a...@linux-foundation.org; linux-omap@vger.kernel.org;
-Original Message-
From: Guruswamy, Senthilvadivu
Sent: Tuesday, June 22, 2010 5:29 PM
To: Guruswamy, Senthilvadivu; Hiremath, Vaibhav; Tomi Valkeinen
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; t...@atomide.com
Subject: RE: [PATCH v3 2/3] OMAP: DSS2: OMAPFB: make
On Fri, Jun 18, 2010 at 11:53 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Govindraj.R govindraj.r...@ti.com writes:
Changes from v1:
* Incorporated : OMAP clock: Add uart4_ick/fck definitions for 3630
* using omap_mux_request_signal
Mike Rapoport m...@compulab.co.il writes:
Kevin Hilman wrote:
Peter Tseng tsenpe...@gmail.com writes:
I am seeing some discrepancies between the Overo (I believe I have a
Water) and the Beagleboard (I have a Rev. B5) when resuming after a
suspend to RAM.
Not that it is much comfort, but I
Varadarajan, Charulatha ch...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 17, 2010 10:13 PM
To: Varadarajan, Charulatha
Cc: Cousson, Benoit; davi...@pacbell.net;
broo...@opensource.wolfsonmicro.com;
Govindraj govindraj...@gmail.com writes:
On Fri, Jun 18, 2010 at 11:53 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Govindraj.R govindraj.r...@ti.com writes:
Changes from v1:
* Incorporated : OMAP clock: Add uart4_ick/fck definitions
This patch introduces platform_data structure for GPIO
so that GPIO module can be implemented in platform device model.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/plat-omap/include/plat/gpio.h | 20
1 files changed,
This patch populates omap24xx.h, omap34xx.h and omap44xx.h files
with SoC specific GPIO base addresses. This would be later used
while creating GPIO hwmod structures.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
This patch adds support for handling OMAP15xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c | 105
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init() does
the module init by clearing the
This patch adds support for handling OMAP7xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/gpio7xx.c | 278
Add hwmod structures for GPIO module on OMAP243X
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 279
1 files changed, 279 insertions(+), 0 deletions(-)
diff --git
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access gpio APIs.
Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
This patch makes GPIO to use runtime APIs.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before machine_init. Therefore
GPIO device
This patch removes the usage of omap_gpio_init() from all
omap board files since omap_gpio_init() does nothing, after gpio
is implemented as a platform device.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/board-ams-delta.c |
This patch adds support for handling OMAP16xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/gpio16xx.c | 212
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also corrects the gpio .main_clk and .clk fields in gpio hwmod structures.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 31
Add hwmod structures for GPIO module on OMAP242X
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 228
1 files changed, 228 insertions(+), 0 deletions(-)
diff --git
Add hwmod structures for GPIO module on OMAP3
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 366
1 files changed, 366 insertions(+),
Hi,
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Tuesday, June 22, 2010 3:54 PM
To: Taneja, Archit
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v2] OMAP: DSS2: DSI: disable manager on framedone
timeout
Hi,
On Mon, 21 Jun 2010, ext
Govindraj govindraj...@gmail.com writes:
On Fri, Jun 18, 2010 at 3:15 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY
Charulatha V ch...@ti.com writes:
On 'origin/pm-wip/hwmods-omap4' branch, fix the following
compilation error:
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c:218:
error: 'omap34xx_sr1_hwmod' undeclared here (not in a function)
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c:219:
error:
On 18/06/10 08:04 +0200, Doyu Hiroshi (Nokia-D/Helsinki) wrote:
Hi,
This is another version of kmemleak: Fix false positive, which
introduces another alias tree to keep track of all alias address of
each objects, based on the discussion(*1)
You can also find the previous one(*2), which
Stanley.Miao stanley.m...@windriver.com writes:
First, the subject needs to be more descriptive:
OMAP3: AM3505/3517 do not have IO wakeup capability
omap3505/omap3517 don't have the bit OMAP3430_EN_IO and the bit
OMAP3430_EN_IO_CHAIN in the register PM_WKEN_WKUP. When the system
suspend, the
Paul Walmsley wrote:
Generally it is helpful if you have a patch for a subsystem that I
maintain, to cc me directly.
Will do. Thanks.
- Anand
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Tony Lindgren wrote:
__kuser_get_tls: @ 0x0fe0
-
-#if !defined(CONFIG_HAS_TLS_REG) !defined(CONFIG_TLS_REG_EMUL)
- ldr r0, [pc, #(16 - 8)] @ TLS stored at 0x0ff0
-#else
- mrc p15, 0, r0, c13, c0, 3 @ read TLS register
Hi all,
I can't get to boot the latest mainline kernel on ZOOM2 (using
omap_zoom2_defconfig).
It just hangs after u-boot is saying loading kernel
I know that my setup is ok, because if I use TI kernel sources from my
BSP it boots fine..
Any idea what is the problem ?
Maybe I need to use
Kevin,
On Thu, Jun 17, 2010 at 4:06 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kevin.Hillman.01 | drop device_* calls
Kevin.Hillman.01 | use runtime PM API
I don't see the runtime PM API used anywere in this series.
I have not implemented runtime pm yet... will do on top of
Charu, Kevin,
On Thu, Jun 17, 2010 at 4:08 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Varadarajan, Charulatha ch...@ti.com writes:
[...]
+
+ oh = omap_hwmod_lookup(oh_name);
Use omap_hwmod_for_each_by_class() instead of lookup by name.
Yes.
how about handling all keypad data
Let mailbox users set the callback pointer via the
omap_mbox_get API, instead of having users directly
manipulating the mailbox structures.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
I can also be contacted at ohadb at ti dot com
arch/arm/plat-omap/include/plat/mailbox.h |2 +-
We currently maintain only a single mailbox receiver callback.
To prevent multiple receivers race scenarios (in which receivers
will end up overwriting each other's callback pointers), we make
sure that mailbox instances cannot be taken by more than
one receiver at the same time.
Signed-off-by:
mbox_configured is global and therefore does not support
concurrent usage of multiple mailbox instances.
Instead of fixing this, we can just eliminate mbox_configured
(and its locking) entirely, since any given mailbox instance
can only be taken by a single receiver now.
Signed-off-by: Ohad
use mailbox API to set rx callback
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
I can also be contacted at ohadb at ti dot com
drivers/dsp/bridge/core/tiomap3430.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/core/tiomap3430.c
On Wed, Jun 16, 2010 at 8:50 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Ohad Ben-Cohen o...@wizery.com
Thanks, I'll prepare them and resubmit
You can use the following branch which has accumulateed unmerged
mailbox patches.
git://gitorious.org/~doyu/lk/mainline.git
With OMAP4 we have the need to have SOC independent features
handling. This makes sense from a long run as other OMAP4
derivatives gets generated in parallel to OMAP3 generation
of chips.
V1: http://marc.info/?l=linux-omapm=127458581708411w=2
V2 incorporates additional patches which were posted
introduce generic features for omap2. omap2 uses mbx, not sgx, and
it still has a dsp, though not iva2 as omap3 uses..
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
add a minimalist feature - l2cache for omap1.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap1/id.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c
index 91dbb71..b98a17f 100644
---
introduce basic omap4 feature framework
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 01555b6..e3f5994 100644
---
Replace OMAP3_HAS_FEATURE with OMAP_HAS_FEATURE allowing
us to support multiple chip features
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi
Introduce a single omap generic check_revision that routes the
request to the right revision of check_revision.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
omap24xx_check_revision, omap3_check_features,
omap3_check_revision, omap4_check_revision, omap3_cpuinfo
are not used elsewhere, it should be static
Also fixes the following sparse warnings:
arch/arm/mach-omap2/id.c:105:13: warning: symbol 'omap24xx_check_revision' was
not declared. Should it be
change OMAP3_SHOW_FEATURE into OMAP_SHOW_FEATURE to make the usage
generic.
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc: Alistair Buxton a.j.bux...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Sanjeev Premi pr...@ti.com
Cc:
sgx, iva, l2cache, sgx, neon, isp are generic features, make
them generic features, current OMAP3 detection mechanism
is still retained. 192Mhz is more specific OMAP3 feature
so it is retained as is
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure
Rename omap_check_revision to omap1_check_revision to make it
evident that this is omap1 features to check. This will allow
us to introduce a omap generic check feature capability
Cc: Tony Lindgren t...@atomide.com
Cc: Angelo Arrifano mik...@gmail.com
Cc: Zebediah C. McClure z...@lurian.net
Cc:
Initialization of pointer should be done with NULL. Removes sparse
warnings:
arch/arm/mach-omap2/serial.c:566:17: warning: Using plain integer as NULL
pointer
arch/arm/mach-omap2/serial.c:567:17: warning: Using plain integer as NULL
pointer
Cc: Deepak K deepa...@ti.com
Cc: Govindraj R
Remove the following sparse warnings by declaring attr as static:
arch/arm/mach-omap2/serial.c:627:1: warning: symbol 'dev_attr_sleep_timeout'
was not declared. Should it be static?
Cc: Deepak K deepa...@ti.com
Cc: Govindraj R govindraj.r...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
introduce silicon specific quirks as a errata handling mechanism
as a start UART_ERRATA_FIFO_FULL_ABORT is used to handle the override
for fifo full condition for rx and tx.
Cc: Deepak K deepa...@ti.com
Cc: Govindraj R govindraj.r...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tero
From: Deepak K deepa...@ti.com
Original patch:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c
Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6):
UART module MDR1 register access can cause a dummy underrun
condition which could result in a freeze in
From: Govindraj R govindraj.r...@ti.com
Ref:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=c74952c3077e4b19e649b5b48c785c01f73ab9d4
Adds context save/restore for mcr register as state of mcr register
is lost after core off.
Cc: Deepak K deepa...@ti.com
Cc: Kevin Hilman
V1:
http://marc.info/?l=linux-omapm=127074926903371w=2
The patch for Errata i202 went through a series of discussions
ending in
V3:
http://marc.info/?l=linux-omapm=127109794814030w=2
This series introduces an errata variable, does a few sparse cleanups
and provides fix for an new errata.
Deepak
DISPC DMA optimization has been enabled and vrfb calls changed as required.
Optimization reduces the memory traffic (DDR memory) when rotation is set
to 90- and 270- degree and SMS-VRFB rotation engine is used.
With this change,
L3 interconnect traffic is reduced by a factor 2x for YUV422 UYVY
Kevin Hilman wrote:
Mike Rapoport m...@compulab.co.il writes:
Kevin Hilman wrote:
Peter Tseng tsenpe...@gmail.com writes:
I am seeing some discrepancies between the Overo (I believe I have a
Water) and the Beagleboard (I have a Rev. B5) when resuming after a
suspend to RAM.
Not that it is
74 matches
Mail list logo
