Add linux/sched.h because of missing declaration of TASK_NORMAL.
This patch fixes the following error:
drivers/media/video/omap24xxcam.c: In function
'omap24xxcam_vbq_complete':
drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
(first use in this function)
Dave,
-Original Message-
From: Dave Martin [mailto:dave.mar...@linaro.org]
Sent: Friday, February 04, 2011 7:51 PM
To: linux-arm-ker...@lists.infradead.org
Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
linux-omap@vger.kernel.org; Nicolas Pitre; Russell King
Subject:
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Tuesday, February 08, 2011 2:11 PM
To: 'Dave Martin'; 'linux-arm-ker...@lists.infradead.org'
Cc: 'Tony Lindgren'; Jean Pihet-XID; 'linux-omap@vger.kernel.org';
'Nicolas Pitre'; 'Russell King'
Subject:
On Thu, Feb 03, 2011 at 09:15:08AM +0100, Uwe Kleine-König wrote:
Hey Tony,
this patch below is now 4 months old and I didn't get any feedback. (Though I
somehow missed to cc linux-omap@vger.kernel.org before, sorry for that.)
There are two more patches in this thread that are not yet
Check if enable/disable operations are supported for a given
clock node before attempting to call them.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c
Enable hardware gate control for all dpll MX postdividers.
This requires the allow_idle/deny_idle functions to be
populated for all clock nodes (mx post dividers) in
clkops.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.c |5
All OMAP3/4 dpll's support hardware level autogating.
Populate allow_idle/deny_idle function pointers for all
DPLL's in clkops.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.c |8 +++-
arch/arm/mach-omap2/clock.h |1 +
On OMAP4, the dpll post divider outputs (MX outputs)
provide a way to allow/deny hardware level autogating.
Allowing autoidle would mean that the hw would autogate
this clock when there is no dependency for it.
Denying idle would mean that this clock output will be
forced to stay enabled.
Add
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6, wfi() is not defined. If needed, some CPU-
specific wfi() will have to be defined elsewhere.
Signed-off-by: Dave Martin
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6, wfi() is not defined. If needed, some CPU-
specific wfi() will have
On Tue, Feb 08, 2011 at 11:08:08AM +, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Thursday, February 03, 2011 6:37 AM
To: Vishwanath BS
Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Thara Gopinath
Subject: Re: [PATCH 01/13] OMAP: Introduce accessory APIs for DVFS
Vishwanath BS
Hi all,
I have pull the latest git from
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary;.
But couldn't find config file for overo . So I used
omap2plus_defconfig and made sure the overo board is selected.
But the board didn't boot. It stopped after
This Patch frees all the dynamically allocated memory
which couldn't have been released in some error hitting cases.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git
On Tue, Feb 08, 2011 at 04:50:34PM +0530, Mohamed Thalib H wrote:
Hi all,
I have pull the latest git from
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary;.
But couldn't find config file for overo . So I used
omap2plus_defconfig and made sure the overo board is
On Feb 8, 2011, at 3:20 PM, Mohamed Thalib H wrote:
Hi all,
I have pull the latest git from
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary;.
But couldn't find config file for overo . So I used omap2plus_defconfig
and made sure the overo board is selected.
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6,
On Tue, Feb 08, 2011 at 01:11:51PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op
Hi Hans,
Thanks for the review.
On Friday 04 February 2011 12:55:50 Hans Verkuil wrote:
On Thursday, January 27, 2011 13:32:16 Laurent Pinchart wrote:
Hi everybody,
Here's the fifth version of the OMAP3 ISP driver patches, updated to
2.6.37 and the latest changes in the media
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
[...]
On Tue, Feb 08, 2011 at 01:11:51PM +0100, Arnd Bergmann wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so
Hi Elvis and balbi
On Tuesday 08 February 2011 05:34 PM, Elvis Dowson wrote:
On Feb 8, 2011, at 3:20 PM, Mohamed Thalib H wrote:
Hi all,
I have pull the latest git from
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary;. But
couldn't find config file for overo
-Original Message-
From: Dave Martin [mailto:dave.mar...@linaro.org]
Sent: Tuesday, February 08, 2011 5:52 PM
To: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org; Russell King - ARM Linux;
Nicolas Pitre; Tony Lindgren; Santosh Shilimkar; linux-
o...@vger.kernel.org; Jean
It works!
Thanks.
Hi Elvis and balbi
On Tuesday 08 February 2011 05:34 PM, Elvis Dowson wrote:
Hi all,
I have pull the latest git from
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary;.
But couldn't find config file for overo . So I used
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so removing them seems like a good strategy to avoid people from
using them incorrectly.
That's because they've only just been added. See the massive
On Tue, Feb 8, 2011 at 12:53 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so removing them seems like a good strategy to avoid people from
using them incorrectly.
Dave,
-Original Message-
From: Dave Martin [mailto:dave.mar...@linaro.org]
Sent: Tuesday, February 08, 2011 8:16 PM
To: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org; Russell King - ARM Linux;
Nicolas Pitre; Tony Lindgren; Santosh Shilimkar; linux-
o...@vger.kernel.org;
On Tue, Feb 8, 2011 at 2:54 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Dave,
-Original Message-
From: Dave Martin [mailto:dave.mar...@linaro.org]
[...]
I don't like the practice of pre-assembling bits of code with .long,
in order to allow a file to be built with wrong
On Tuesday 08 February 2011, Dave Martin wrote:
I guess there are two problems we're trying to solve here:
1) a lowest-common denominator implementation of things like wfi(),
for use in common code. This must be based on __LINUX_ARM_ARCH__
(which IIUC gives the lowest arch supported by all
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code from that file
could ever get run on other processors. I'm not so sure of the answer
to that..., but perhaps someone else has a better
On Tue, Feb 8, 2011 at 3:15 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
I guess there are two problems we're trying to solve here:
1) a lowest-common denominator implementation of things like wfi(),
for use in common code. This must be based on
On Tuesday 08 February 2011, Dave Martin wrote:
Why not have macros for these cases? (Which kinda brings the
discussion full-circle...)
My immediate concern is that too often, the Thumb-2 case will be
handled incorrectly or not at all ... and the kernel will silently
build without flagging
On Tue, Feb 08, 2011 at 02:45:51PM +, Dave Martin wrote:
If support for a v6K processor is included, we have no way to know
from preprocessor definitions whether a plain v6 processor is also to
be supported.
Yes we do. See the v6 patches I've recently posted to various mailing
lists.
On Tue, Feb 8, 2011 at 3:42 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
Why not have macros for these cases? (Which kinda brings the
discussion full-circle...)
My immediate concern is that too often, the Thumb-2 case will be
handled incorrectly or
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same kind of abstraction that we have for a number of other things
like cache management in
On Tue, Feb 8, 2011 at 4:20 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 08, 2011 at 02:45:51PM +, Dave Martin wrote:
If support for a v6K processor is included, we have no way to know
from preprocessor definitions whether a plain v6 processor is also to
be
On Tue, Feb 8, 2011 at 4:25 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code from that file
could ever get run on other processors. I'm not so sure
Russell,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Tuesday, January 18, 2011 12:51 AM
To: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Subject: [PATCH 00/14] Fix
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same kind of
On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
Have tested this series on OMAP4430 and OMAP3430.
Don't know if it helps to push some of these patches to be part
of rc cycles. At least the SMP specific fixes should get merged
otherwise, builds like omap2plus_defconfig won't
On Tue, Feb 08, 2011 at 05:47:18PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither
On Tuesday 08 February 2011 17:32:29 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, February 08, 2011 10:18 PM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
On
On Tue, Feb 8, 2011 at 4:55 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 08, 2011 at 05:47:18PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that
On Tue, Feb 8, 2011 at 4:58 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011 17:32:29 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o +=
Hi Santosh,
[...]
Which tree did you use to test this? It didn't seem to work for me
--
sometimes the system wouldn't suspend, complaining about USB suspend
errors; and other times I couldn't bring it out of suspend (by
poking
a USB input device).
I might be doing something wrong...
I
Ben Dooks ben-...@fluff.org writes:
On Thu, Jan 27, 2011 at 04:18:41PM -0800, Kevin Hilman wrote:
When runtime PM is enabled, each OMAP i2c device is suspended after
each i2c xfer. However, there are two cases when the static suspend
methods must be used to ensure the devices are suspended:
Hello,
These 2 patches are basically bugfixing to make DVI work again on beagle.
Tested with Beagle-xM and C4.
Changes in v2:
* Properly defining GPIO names and values for DVI reset
* Defining mux configuration for DVI reset pin
Mathieu J. Poirier (1):
omap3: beagle: adding regulator supply
From: Mathieu J. Poirier mathieu.poir...@canonical.com
The omapfb driver couldn't locate its display sink because of
an initialisation error in the DSS subsystem. This error was
caused by a missing 'sdi' entry in the board power regulator list.
BugLink: https://bugs.launchpad.net/bugs/597904
Function beagle_twl_gpio_setup is called after beagle_display_init, what
lets reset_gpio with an invalid value at the time it request the gpio.
As a side effect the DVI reset GPIO is not properly set.
Also removing old code that powers down DVI in a hardcoded way, as it's
not necessary anymore.
On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
I think it's probably going to be better to _purposely_ break the
OMAP build when it covers v6 and v7 CPUs in these kernels as I don't
think it's sanely fixable given where we are.
Agreed. At least making SMP unavailable when both v6 and v7
From: Paul Walmsley p...@pwsan.com
Update the omap2430 hwmod data with the HSMMC info.
Also update the device attribute structure.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by:
Changes involves:
1) Remove controller reset in devices.c which is taken care
by hwmod framework.
2) Removing all base address macro defines.
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device
Update the omap2420 hwmod data with the HSMMC info.
Add a device attribute structure which will be used
by the host driver to find whether the HSMMC controller
supports DUAL VOLT cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 80
From: Paul Walmsley p...@pwsan.com
Update the omap3 hwmod data with the HSMMC info.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
From: Benoit Cousson b-cous...@ti.com
Update the omap4 hwmod data with the HSMMC info.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 339
1 files changed, 339
Adding hwmod data for hsmmc device on OMAP2420/OMAP2430/OMAP3/OMAP4.
Adapting the omap_hsmmc driver to hwmod framework
V2:
---
Updated hwmod data for OMAP2420 OMAP2430.
The patch series is rebased on v2.6.38-rc4 and tested on OMAP4430SDP,
OMAP3430SDP OMAP2430SDP.
For OMAP2430SDP validation,
On Mon, Feb 7, 2011 at 9:38 PM, Balaji T K balaj...@ti.com wrote:
Add regulator VMMC1 used by SD/MMC card slot1 in 2430sdp.
Signed-off-by: Balaji T K balaj...@ti.com
Tested-by: Kishore Kadiyala kishore.kadiy...@ti.com
Regards,
Kishore
---
Tested on OMAP2430 SDP with busybox filesystem
Kishore Kadiyala kishore.kadiy...@ti.com writes:
From: Paul Walmsley p...@pwsan.com
Update the omap3 hwmod data with the HSMMC info.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Kishore Kadiyala kishore.kadiy...@ti.com writes:
Update the omap2420 hwmod data with the HSMMC info.
Add a device attribute structure which will be used
by the host driver to find whether the HSMMC controller
supports DUAL VOLT cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Kishore Kadiyala kishore.kadiy...@ti.com writes:
Changes involves:
1) Remove controller reset in devices.c which is taken care
by hwmod framework.
2) Removing all base address macro defines.
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base
On Wed, 2 Feb 2011, Kishore Kadiyala wrote:
Update the omap2420 hwmod data with the HSMMC info.
Umm, this doesn't look right. OMAP2420 doesn't have an HSMMC block as far
as I know. It also uses a different driver than later OMAPs.
More comments below.
Add a device attribute structure
Kishore,
On Wed, Feb 9, 2011 at 01:23, Kishore Kadiyala kishore.kadiy...@ti.com wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care
by hwmod framework.
2) Removing all base address macro defines.
3) Using omap-device layer to register device and utilizing
* Kishore Kadiyala kishore.kadiy...@ti.com [110208 12:45]:
Adding hwmod data for hsmmc device on OMAP2420/OMAP2430/OMAP3/OMAP4.
Adapting the omap_hsmmc driver to hwmod framework
V2:
---
Updated hwmod data for OMAP2420 OMAP2430.
The patch series is rebased on v2.6.38-rc4 and tested on
Omar Ramirez Luna omar.rami...@ti.com writes:
Mailbox hwmod support for OMAP 2,3,4.
This was tested on OMAP3 (3430, 3630), minor testing
was made on OMAP4.
No testing on OMAP2 since I don't have the hardware.
Reviewed-by: Kevin Hilman khil...@ti.com
But still needs sanity testing on
.
These patches are also added as part of the current integration branch
'integration-2.6.39' of git://git.pwsan.com/linux-integration - a stable
tag with these changes is tag 'integration-2.6.39-20110208-007'.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap
On Mon, 7 Feb 2011, Rajendra Nayak wrote:
Add OMAP4 platform specific implementation to support clkdm
wkup and sleep dependencies a.k.a static dependencies.
Signed-off-by: Rajendra Nayak rna...@ti.com
I made two minor changes to this before merging: one to keep the
formatting of the
On Fri, 2010-12-10 at 20:05 +0530, Hema HK wrote:
Using omap_device_build API instead of platform_device_register for
OMAP2430,OMAP34xx and OMAP4430 musb device registration.
The device specific resources defined in centralized
database will be used.
Signed-off-by: Hema HK hem...@ti.com
On Wed, Feb 9, 2011 at 00:13, Ricardo Salveti de Araujo
ricardo.salv...@canonical.com wrote:
Function beagle_twl_gpio_setup is called after beagle_display_init, what
lets reset_gpio with an invalid value at the time it request the gpio.
As a side effect the DVI reset GPIO is not properly set.
On Fri, 2010-12-10 at 20:05 +0530, Hema HK wrote:
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings.
enable clock, configure no-idle/standby when active and configure force
idle/standby
and disable clock when
* Nicolas Pitre n...@fluxnic.net [110208 12:41]:
On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
I think it's probably going to be better to _purposely_ break the
OMAP build when it covers v6 and v7 CPUs in these kernels as I don't
think it's sanely fixable given where we are.
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Feb 03, 2011 at 11:24:48AM +0530, Hema Kalliguddi wrote:
Any comments?
For me these are ok, Tony/Kevin, do you want me to prepare a pull
request when we're closer to .39 merge window for one of you guys to
pull from and get this part in
Premi, Sanjeev pr...@ti.com writes:
This patch adds support for speed enhanced variant of OMAP35x
processors. These parts allow ARM and IVA running at 720MHz
and 520MHz respectively.
These parts can be detected at runtime by reading contents of
PRODID.SKUID[3:0] at 0x4830A20C [1].
On Thu, 2011-01-27 at 16:41 +0530, Sanjeev Premi wrote:
This patch adds support for speed enhanced variant of OMAP35x
processors. These parts allow ARM and IVA running at 720MHz
and 520MHz respectively.
These parts can be detected at runtime by reading contents of
PRODID.SKUID[3:0] at
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Wednesday, February 09, 2011 5:38 AM
To: Hema HK
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Felipe Balbi; Tony Lindgren; Cousson, Benoit; Paul Walmsley
Subject: Re: [PATCH 5/5 v5] usb: musb: Using
On Thu, Apr 29, 2010 at 1:58 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
What do you expect to gain from suspend-to-disk + snapshot boot that
you don't already get from suspend-to-RAM using off-mode?
On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP
into
-Original Message-
From: Dave Martin [mailto:dave.mar...@linaro.org]
Sent: Tuesday, February 08, 2011 11:11 PM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; Jean Pihet-
XID; linux-omap@vger.kernel.org; Nicolas Pitre
Subject: Re: [PATCH v2 0/5] ARM:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, February 09, 2011 6:06 AM
To: Nicolas Pitre
Cc: Santosh Shilimkar; Russell King - ARM Linux; linux-
o...@vger.kernel.org;
On Fri, Feb 4, 2011 at 6:56 AM, Tony Lindgren t...@atomide.com wrote:
Here are the changes to make omap DEBUG_LL code generic using
the new inituart macro posted in a separate series. This allows
leaving out the dependency to the uncompress code and allows
error messages when trying to boot a
Hi,
I am using the kernel from OMAP git. I got ECC error when writing to a
nand partition. I have tested this in gumsitx overo board.
---Log---
root@overo:/# flash_eraseall -j /dev/mtd4
Erasing 128 Kibyte @ f98 -- 100 % complete.Cleanmarker written at
f96.
root@overo:/# mkdir -p
On Wed, Feb 9, 2011 at 1:13 AM, Ricardo Salveti de Araujo
ricardo.salv...@canonical.com wrote:
Function beagle_twl_gpio_setup is called after beagle_display_init, what
lets reset_gpio with an invalid value at the time it request the gpio.
As a side effect the DVI reset GPIO is not properly set.
Hi,
I am testing pm in overo board. it is a freshly build kernel from OMAP
mainline git.
From the below log, I have doubt whether the OMAP really goes into
suspend to RAM state.
root@overo:~# echo mem /sys/power/state
[ 866.503662] PM: Syncing filesystems ... done.
[ 866.590515]
82 matches
Mail list logo
