Tony,
I am re-sending three patches rebased on the 2.6.32-rc4 mainline for the merge.
You have already seen these on linux-omap mailing list. Second patch is spilt
because it has two independent fixes.
These patches are boot tested on
- OMAP3430 SDP
- OMAP3 beagle
-
This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw oops in omap_serial_init().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-By: Tony Lindgren t...@atomide.com
Reviewed-By: Kevin Hilman khil...@deeprootsystems.com
---
This patch removes the unnecessary UART4 platform which is under
data is wrong because of this
There is a separate platform structure for UART4
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-By: Tony Lindgren t...@atomide.com
Reviewed-By: Kevin Hilman
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
On Tue, Oct 13, 2009 at 06:25:17PM +0200, ext Kevin Hilman wrote:
Eduardo Valentin eduardo.valen...@nokia.com writes:
Hello Amit,
On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote:
Hi,
I am testing twl4030 script optimisations on the current PM branch. But I
am
Christopher,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Christopher Friedt
Sent: Tuesday, October 13, 2009 5:03 PM
To: linux-omap@vger.kernel.org
Subject: patch: add omap730 / omap850 rtc support
Christopher
The following patches add support for CompuLab CM-T35 board.
--
v2 changes:
remove EHCI-related code
move usb_musb_init to cm_t35_init
--
Changes since commit 2caa731819a633bec5a56736e64c562b7e193666:
Linus Torvalds (1):
Merge branch 'for-linus' of
This patch adds basic support for CompuLab CM-T35 module.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-cm-t35.c | 459
3 files
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/configs/cm_t35_defconfig | 1733 +
1 files changed, 1733 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/cm_t35_defconfig
diff --git a/arch/arm/configs/cm_t35_defconfig
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091013 10:00]:
This patch adds basic support for CompuLab CM-T35 module.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
snip
+static struct ehci_hcd_omap_platform_data ehci_pdata = {
+
+.port_mode[0] =
This patch adds support for EHCI on CM-T35.
It depends on basic CM-T35 board support ([1]) and EHCI updates
in the linux-omap tree.
[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/24938
---
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 17
On Wed, Oct 14, 2009 at 9:11 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
Any advantage of using both enum and register offsets?
You can have only register offset macros instead of enum.
This was the appproach proposed by Tony in response to Alistair's
original query. Tony originally cited
Ok, I will resubmit in few minuts
Thanks,
Enric
2009/10/13 Tony Lindgren t...@atomide.com:
* Enric Balletbò i Serra eballe...@gmail.com [091009 09:18]:
This patch adds minimal IGEP v2 support.
Can you please move the defconfig into a separate patch
when you resubmit? It makes it easier
This patch adds minimal IGEP v2 support.
The IGEP v2 board is a low-cost, fan-less and industrial temperature
range single board computer that unleashes laptop-like performance and
expandability without the bulk, expense, or noise of typical desktop
machines. Its architecture shares much in
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/configs/igep0020_defconfig | 1432 +++
1 files changed, 1432 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/igep0020_defconfig
diff --git
Hi,
I'm looking for an stable omap kernel,
for an gumstix board. I tried the 2.6.30
and 2.6.31 git heads, but they both
resulted in an unbootable system.
Any advices, on which version to take ?
Greetings
J. Machowinski
P.S.: Please answer directly to me, as I am not subscribed to the list
--
omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access
McBSP registers as 16-bit registers.
The McBSP registers (DRR_REG and DXR_REG) are limited to
32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is
not allowed and can corrupt register content.
This patch modifies
On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote:
On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren t...@atomide.com wrote:
* Kevin Hilman khil...@deeprootsystems.com [091013 12:09]:
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:
From: De-Schrijver Peter
On Wed, Oct 14, 2009 at 9:11 AM, G, Manjunath Kondaiah
manj...@ti.com wrote:
Any advantage of using both enum and register offsets?
You can have only register offset macros instead of enum.
This was the appproach proposed by Tony in response to Alistair's
original query. Tony
On Wed, Oct 14, 2009 at 3:00 PM, ch...@ti.com wrote:
omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access
McBSP registers as 16-bit registers.
The McBSP registers (DRR_REG and DXR_REG) are limited to
32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is
not allowed and can
Charu,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charu Latha
Sent: Wednesday, October 14, 2009 3:00 PM
To: linux-omap@vger.kernel.org
Cc: Varadarajan, Charu Latha; Syed, Rafiuddin
Subject: [PATCH]
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of vimal singh
Sent: Wednesday, October 14, 2009 3:23 PM
To: Varadarajan, Charu Latha
Cc: linux-omap@vger.kernel.org; Syed, Rafiuddin
Subject: Re: [PATCH] OMAP3: Fix
Koskinen,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ilkka Koskinen
Sent: Thursday, September 24, 2009 9:24 PM
To: linux-ker...@vger.kernel.org; sa...@linux.intel.com
Cc: linux-omap@vger.kernel.org;
-Original Message-
From: G, Manjunath Kondaiah
Sent: Wednesday, October 14, 2009 4:01 PM
To: 'vimal singh'; Varadarajan, Charu Latha
Cc: linux-omap@vger.kernel.org; Syed, Rafiuddin
Subject: RE: [PATCH] OMAP3: Fix McBSP poll read and write for
32bit reg access
-Original
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
Sent: Tuesday, October 13, 2009 5:33 PM
To: Russell King - ARM Linux
Cc: linux-omap@vger.kernel.org;
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, October 14, 2009 1:02 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 0/3] OMAP3: PM: Make PRM setup times and
CPUidle latencies/threshold board specific
Nayak,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Enric
Balletbò i Serra
Sent: Wednesday, October 14, 2009 3:32 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 1/2] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, October 14, 2009 1:05 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/3] OMAP3: PM: Configure PRM setup times
from board files
Rajendra Nayak rna...@ti.com writes:
Eduardo Valentin eduardo.valen...@nokia.com writes:
On Tue, Oct 13, 2009 at 06:25:17PM +0200, ext Kevin Hilman wrote:
Eduardo Valentin eduardo.valen...@nokia.com writes:
Hello Amit,
On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote:
Hi,
I am testing twl4030 script
Nayak, Rajendra rna...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 2242d23..6f2fb51 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1084,6 +1084,9 @@ int omap3_pm_set_suspend_state(struct
powerdomain
On Wed, Oct 14, 2009 at 03:06:41PM +0200, ext Kevin Hilman wrote:
Eduardo Valentin eduardo.valen...@nokia.com writes:
On Tue, Oct 13, 2009 at 06:25:17PM +0200, ext Kevin Hilman wrote:
Eduardo Valentin eduardo.valen...@nokia.com writes:
Hello Amit,
On Mon, Oct 12, 2009 at
/* I2C WE wakeup enable register */
-#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakup */
+#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakeup */
#define OMAP_I2C_WE_RDR_WE (1 13) /* RX drain wakeup */
+#define OMAP_I2C_WE_ROVR_WE (1 11)
On Wed, Oct 14, 2009 at 11:52 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
You can acheive the same using only enum with following:
#define OMAP_RTC_REGISTER_SIZE (cpu_is_omap7xx()?1:4)
#define rtc_read(reg)
omap_readb(OMAP_RTC_BASE + (reg * OMAP_RTC_REGISTER_SIZE))
That was my
There is no newer u-boot from TI available. There is a SDK 02.01.03.11
but it contains the same uboot 2008.10 with the only addition of the second
generation of EVM boards with another network chip.
So I checked the uboot from git, but this doesn't support Microns NAND Flash
anymore. It is
I decided on using 31 because
=
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 0587d53..cc25f4f 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -22,6 +22,7 @@
#include linux/platform_device.h
-Original Message-
From: Christopher Friedt [mailto:chrisfri...@gmail.com]
Sent: Wednesday, October 14, 2009 6:58 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org
Subject: Re: patch: add omap730 / omap850 rtc support
On Wed, Oct 14, 2009 at 11:52 AM, G, Manjunath
On Wed, Oct 14, 2009 at 4:09 PM, Christopher Friedt
chrisfri...@gmail.com wrote:
I decided on using 31 because
sorry, that should read '' because 1/32768 is between 30 and 31
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Wed, Oct 7, 2009 at 10:47 AM, Tony Lindgren t...@atomide.com wrote:
* Kevin Hilman khil...@deeprootsystems.com [091006 15:18]:
Menon, Nishanth n...@ti.com writes:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of
Hi,
From: ext G, Manjunath Kondaiah [mailto:manj...@ti.com]
Sent: 14 October, 2009 13:51
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ilkka Koskinen
Sent: Thursday, September 24, 2009 9:24 PM
To:
Mem clock is both times 166MHz. I don't know whether are differences in cycle
access and timing, but memclock is fine.
Following Siarhei hints of initialize the buffers (around 1.2 MByte each)
I get different results in 22kernel for use of
malloc alone
memcpy = 473.764, loop4 = 448.430,
From: e...@gmx.de [mailto:e...@gmx.de]
Sent: Wednesday, October 14, 2009 9:49 AM
To: Woodruff, Richard; linux-omap@vger.kernel.org; Premi, Sanjeev
Subject: Re: RE: RE: Memory performance / Cache problem
Mem clock is both times 166MHz. I don't know whether are differences in cycle
access
From: Pandita, Vikram
Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx
Thanks to all the community members for taking time for this discussion.
This will aid upsteaming of 35xx/36xx/44xx in coming future.
Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, Rajendra,
-Original Message-
From: Cousson, Benoit
Sent: Wednesday, October 14, 2009 11:06 AM
To: Pandita, Vikram; linux-omap@vger.kernel.org
From: Pandita, Vikram
Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx
Thanks to all the community members for taking time for this
* Tony Lindgren t...@atomide.com [091013 17:21]:
From: Roel Kluin roel.kl...@gmail.com
The closing parenthesis was not on the right location.
Looks like this one is in the -mm now, so dropping from
mine.
Tony
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Tony Lindgren
* Santosh Shilimkar santosh.shilim...@ti.com [091013 23:14]:
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used
in linking scenario. This patch fixes the same.
To me it looks like this will break things for omap1 as the DMA channel
interrupt is not disabled first. I
* Mark Brown broo...@opensource.wolfsonmicro.com [091012 02:18]:
On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote:
I'm afraid using dev_name is not that easy. The mmc driver generates device
name at runtime. That's why this board file setups .dev at runtime as well.
Mem clock is both times 166MHz. I don't know whether are differences in
cycle
access and timing, but memclock is fine.
How did you physically verify this?
Oszi show 166MHz, also the kernel message about freq are in both kernels the
same.
Following Siarhei hints of initialize the
-Original Message-
From: Menon, Nishanth
-Original Message-
From: Cousson, Benoit
Sent: Wednesday, October 14, 2009 11:06 AM
To: Pandita, Vikram; linux-omap@vger.kernel.org
From: Pandita, Vikram
Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx
Thanks to
* Janosch Machowinski sco...@tzi.de [091014 01:48]:
Hi,
I'm looking for an stable omap kernel,
for an gumstix board. I tried the 2.6.30
and 2.6.31 git heads, but they both
resulted in an unbootable system.
Any advices, on which version to take ?
Starting with 2.6.31, the stable omap kernel
From: e...@gmx.de [mailto:e...@gmx.de]
Sent: Wednesday, October 14, 2009 12:23 PM
To: Woodruff, Richard; Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: Re: RE: RE: RE: Memory performance / Cache problem
Yes aligned buffers can make a difference. But probably more so for small
On Wednesday 14 October 2009 17:48:39 ext e...@gmx.de wrote:
Mem clock is both times 166MHz. I don't know whether are differences in
cycle access and timing, but memclock is fine.
Following Siarhei hints of initialize the buffers (around 1.2 MByte each)
I get different results in 22kernel for
Tony Lindgren schrieb:
* Janosch Machowinski sco...@tzi.de [091014 01:48]:
Hi,
I'm looking for an stable omap kernel,
for an gumstix board. I tried the 2.6.30
and 2.6.31 git heads, but they both
resulted in an unbootable system.
Any advices, on which version to take ?
Starting with
From: Siarhei Siamashka [mailto:siarhei.siamas...@nokia.com]
Sent: Wednesday, October 14, 2009 12:37 PM
To: ext e...@gmx.de
What you see is just a (fake) performance boost because you have a single
physical page shared between all the virtual pages in the source buffer. So
you get no cache
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Wednesday, October 14, 2009 11:12 AM
I think we should as well change the naming and use the less confusing
naming we are using on OMAP3630/4430.
OPPs are now named using
* Janosch Machowinski sco...@tzi.de [091014 10:40]:
Tony Lindgren schrieb:
* Janosch Machowinski sco...@tzi.de [091014 01:48]:
Hi,
I'm looking for an stable omap kernel,
for an gumstix board. I tried the 2.6.30
and 2.6.31 git heads, but they both
resulted in an unbootable system.
Any
Reposting the full series for review. Assuming this is all OK would it
be a good idea to merge the config variables into a single
CONFIG_ARCH_OMAP7XX? There doesn't seem to be any reason to have both.
Original description follows.
Hello from the Linwizard project,
We have been working on
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
This fixes a bug which prevents IRQs from being enabled on omap850 due to
a missing
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
This file had no omap850 specific code. Original omap850 support in Linwizard
was done
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
This file had no omap850 specific code. Initial clock support was done in
the
This patch is part of a series which unifies all duplicated code between
omap730 and omap850. All cpu checks are converted to cpu_is_omap7xx() and
CONFIG_ARCH_OMAP850 is added to all CONFIG_ARCH_OMAP730 checks.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure
This patch is part of a series which removes references to omap730 in code
which is shared with omap850, replacing them with references to omap7xx.
This include file is intended to replace omap730.h and omap850.h
All values defined herein are identical to those in both the old files.
This patch is part of a series which removes references to omap730 in code
which is shared with omap850, replacing them with references to omap7xx.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure z...@lurian.net
---
arch/arm/mach-omap1/board-fsample.c
This patch is part of a series which removes references to omap730 in code
which is shared with omap850, replacing them with references to omap7xx.
Turns INT_730_* to INT_7XX_* for definitions in irqs.h and all users.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C.
This patch is part of a series which removes references to omap730 in code
which is shared with omap850, replacing them with references to omap7xx.
This updates all the remaining omap730 references in miscellaneous local
variables, macros and similar.
Signed-off-by: Alistair Buxton
This also replaces CPU checks with cpu_is_omap7xx()
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure z...@lurian.net
---
drivers/spi/omap_uwire.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/omap_uwire.c
These clocks are required for booting.
Signed-off-by: Angelo Arrifano mik...@gmail.com
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
Reviewed-by: Zebediah C. McClure z...@lurian.net
---
arch/arm/mach-omap1/clock.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
This just makes the same warning be printed on omap850 and omap730.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
---
arch/arm/mach-omap1/pm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
index 0f20aed..56a6479
This adds the OMAP850 JTAG ID to the IDs checked by OMAP uncompress.h putc.
Without this putc hangs up trying to check the uarts and zImage crashes.
Signed-off-by: Alistair Buxton a.j.bux...@gmail.com
---
arch/arm/plat-omap/include/mach/uncompress.h |3 ++-
1 files changed, 2 insertions(+),
Tony Lindgren schrieb:
Hi Tony,
the 2.6.30 head booted fine until the point where it
waited for the SD-Card to get ready. There it just hung
forever.
Hmm, 2.6.30 may not have all the core stuff in it yet.
the 2.6.31 head crashed instantly after the uncompression
of the kernel
On Wed, Oct 14, 2009 at 04:56:18PM +0530, Shilimkar, Santosh wrote:
Here is the patch I used to fix this BUG.
Patch is good. Could you send it to the patch system. Please note that
the patch system now almost accepts standard patch submissions (in other
words, it no longer requires the PATCH
* Alistair Buxton a.j.bux...@gmail.com [091014 13:03]:
Reposting the full series for review. Assuming this is all OK would it
be a good idea to merge the config variables into a single
CONFIG_ARCH_OMAP7XX? There doesn't seem to be any reason to have both.
Original description follows.
Yeah,
Hi all,
Here is a series for the merge window after 2.6.32 to reorganize
the omap headers as suggested by Russell earlier at [1].
Basically we currently have everything under a single mach directory:
arch/arm/plat-omap/include/mach
This series creates the common plat, and separate mach
This is to prepare for moving hardware.h to live under plat
instead of mach.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/mach/hardware.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git
This also creates the include/mach subdirectories under
mach-omap1 and mach-omap2.
REVISIT: Remove OMAP-730 only parts in mach-omap2 version
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/include/mach/debug-macro.S | 45 +++
Split entry-macro.S for mach-omap1 and mach-omap2
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/include/mach/entry-macro.S | 58
arch/arm/mach-omap2/include/mach/entry-macro.S | 122 +
arch/arm/plat-omap/include/mach/entry-macro.S | 172
These registers are omap1 specific.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/include/mach/mtd-xip.h | 61
arch/arm/plat-omap/include/mach/mtd-xip.h | 61
2 files changed, 61 insertions(+), 61
Create the headers needed for compiling under
mach-omap1/include/mach and mach-omap2/include/mach.
This was done with the following script:
#!/bin/bash
mach_files=clkdev.h gpio.h hardware.h io.h irqs.h memory.h \
smp.h system.h timex.h uncompress.h vmalloc.h
omaps=mach-omap1 mach-omap2
This series adds the base off-mode support to the OMAP3 PM core.
The code originates from the OMAP PM branch[1] and has been tested
broadly on a variety of OMAP3 platforms.
It is currently based on Tony's for-next branch since it depends
on the IO address space rework series.
This series is also
From: Rajendra Nayak rna...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/irq.c | 66
arch/arm/plat-omap/include/mach/irqs.h |5 ++
2 files changed, 71
From: Rajendra Nayak rna...@ti.com
Additional registers (CM_CLKSEL4, CM_CLKEN, CM_CLKEN2) added by Tero
Kristo.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/prcm.c
From: Rajendra Nayak rna...@ti.com
This patch populates the scratchpad contents as expected by the
bootROM code.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/control.c | 203 +
From: Rajendra Nayak rna...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 64 +++--
1 files changed, 54 insertions(+), 10 deletions(-)
diff --git
From: Rajendra Nayak rna...@ti.com
During the MMU restoration on the restore path from MPU OFF, the page
table entry for the page consisting of the code being executed is
modified to make MMU return VA=PA.
The MMU is then enabled and the original entry is being stored in
scratchpad. This patch
From: Tero Kristo tero.kri...@nokia.com
For HS/EMU devices, these additional features are also used:
- DMA interrupt disable routine added
- Added DMA controller reset to DMA context restore
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
From: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/control.c |8 -
arch/arm/mach-omap2/pm.h|3 ++
arch/arm/mach-omap2/pm34xx.c| 44
From: Tero Kristo tero.kri...@nokia.com
Fix for ES3.0 bug: SDRC not sending auto-refresh when OMAP wakes-up from OFF
mode (warning for HS devices.)
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 29
From: Juha Yrjola juha.yrj...@solidboot.com
The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.
Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
From: Tero Kristo tero.kri...@nokia.com
Errata: ES3.0 SDRC not sending auto-refresh when OMAP wakes-up from OFF mode
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/control.c |8 ++-
From: Aaro Koskinen aaro.koski...@nokia.com
Wrong index was used for ILR.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/irq.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Rajendra Nayak rna...@ti.com
This patch adds the System control module context save/restore
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/control.c | 151 +
From: Rajendra Nayak rna...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 10 +++---
arch/arm/plat-omap/include/mach/sram.h |1 +
arch/arm/plat-omap/sram.c |6
Allow enable/disable of low-power states during idle. To
enable low-power idle:
echo 1 /debug/pm_debug/sleep_while_idle
to disable:
echo 0 /debug/pm_debug/sleep_while_idle
Also allow enable/disable of OFF-mode. To enable:
echo 1 /debug/pm_debug/enable_off_mode
to disable:
From: Rajendra Nayak rna...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/gpio.c | 93
arch/arm/plat-omap/include/mach/gpio.h |3 +-
2 files changed, 95
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This patch improves the wakeup SRAM code polling the SDRC to become ready
instead of just waiting for a fixed amount of time.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman
From: Rajendra Nayak rna...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 73 +++-
arch/arm/plat-omap/include/mach/sram.h |1 +
2 files changed, 73
1 - 100 of 127 matches
Mail list logo
