Skip to contentSkip to conversation

ARM: OMAP: Couple of misc fixes for 3.3

PATCH New Santosh Shilimkar 5 participants 17 messages Feb 2, 2012 – Feb 14, 2012

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover ARM: OMAP: Couple of misc fixes for 3.3

Patches are tested on OMAP4430 SDP.

The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:

Linux 3.3-rc2 (2012-01-31 13:31:54 -0800)

Rajendra Nayak (1):
ARM: OMAP: Get rid of reset for system timer

Santosh Shilimkar (1):
ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve
callback

 arch/arm/mach-omap2/Kconfig                   |    4 ++--
 arch/arm/mach-omap2/common.h                  |    1 +
 arch/arm/mach-omap2/io.c                      |    1 +
 arch/arm/mach-omap2/omap4-common.c            |   25 ++++++++++++++++---------
 arch/arm/mach-omap2/timer.c                   |    1 -
 arch/arm/plat-omap/common.c                   |    1 +
 arch/arm/plat-omap/include/plat/omap-secure.h |    6 ++++++
 7 files changed, 27 insertions(+), 12 deletions(-)
Signature · 1 line
1.7.4.1
#1 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

From: Rajendra Nayak <[email protected]>

hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code.

---
 arch/arm/mach-omap2/timer.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/timer.c +0 -1
index 6eeff0e..ccd2d6a 100644
@@ -195,7 +195,6 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
 		}
 	}
 	__omap_dm_timer_init_regs(timer);
-	__omap_dm_timer_reset(timer, 1, 1);
 	timer->posted = 1;
 
 	timer->rate = clk_get_rate(timer->fclk);
Signature · 1 line
1.7.4.1
#2 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

Quoted 5 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code.

That is true for OMAP4, but have you verified if this is indeed a duplicate reset on OMAP2/3?

Kevin

#3 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

Quoted 11 lines · Kevin Hilman
Quoted 5 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code.

That is true for OMAP4, but have you verified if this is indeed a duplicate reset on ?OMAP2/3?

Yes. It is duplicate for OMAP2 and OMAP3 devices as well. Actually this should have been fixed when the driver was hwmod converted but some how got missed. We noticed an issue on OMAP5, when timer interrupts stopped firing when always on clock domain was allowed to idle. This was because this reset was clearing the correctly set sysc value by hwmod.

The patch is also tested on ZOOM3 ( OMAP3630)
and OMAP2430SDP.

Regards
Santosh

#4 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

Quoted 19 lines · Santosh
Quoted 11 lines · Kevin Hilman
Quoted 5 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code.

That is true for OMAP4, but have you verified if this is indeed a duplicate reset on ?OMAP2/3?

Yes. It is duplicate for OMAP2 and OMAP3 devices as well. Actually this should have been fixed when the driver was hwmod converted but some how got missed. We noticed an issue on OMAP5, when timer interrupts stopped firing when always on clock domain was allowed to idle. This was because this reset was clearing the correctly set sysc value by hwmod.

Quoted 2 lines

The patch is also tested on ZOOM3 ( OMAP3630)
and OMAP2430SDP.

Great, thanks for testing on OMAP2/3.

Kevin

maintainer
#5 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

In reply to Santosh Shilimkar
Quoted 5 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code.

If we want this queued as a fix, it should also describe what actually breaks? Timer? PM?

If this is regression, then it should also have the usuual commit 123abc (blah blah blah) caused blah blah..

Regards,

Tony

#6 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

Quoted 9 lines · Tony Lindgren
Quoted 5 lines · Santosh Shilimkar
Quoted 5 lines

From: Rajendra Nayak<[email protected]>

hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code.

If we want this queued as a fix, it should also describe what actually breaks? Timer? PM?

It only fixes the redundant reset and overriding the smartidle-wakeup OCP setting (done by hwmod) with the smartidle in the driver. Doing this doesn't really break anything as yet in mainline, but will cause timer wakeup issues once OFF mode is in place for OMAP4. On OMAP5 however this was causing more issues as the softreset bit position is different than on OMAP2/3/4.
So it should be ok to queue this in for 3.4 considering neither OMAP4 OFF, not OMAP5 support is in mainline yet.

#7 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

Quoted 16 lines · Rajendra Nayak
Quoted 5 lines · Tony Lindgren
Quoted 3 lines · Santosh Shilimkar
Quoted 3 lines

?From: Rajendra Nayak<[email protected]>

Quoted 8 lines
Quoted 3 lines
Quoted 3 lines

?hwmod setup already does a reset and sets the OCP sysconfig ?registers appropriately. Avoid doing a reset again and overriding ?the OCP sysconfig settings in the system timer init code.

If we want this queued as a fix, it should also describe what actually breaks? Timer? PM?

Quoted 9 lines

It only fixes the redundant reset and overriding the smartidle-wakeup OCP setting (done by hwmod) with the smartidle in the driver. Doing this doesn't really break anything as yet in mainline, but will cause timer wakeup issues once OFF mode is in place for OMAP4. On OMAP5 however this was causing more issues as the softreset bit position is different than on OMAP2/3/4.
So it should be ok to queue this in for 3.4 considering neither OMAP4 OFF, not OMAP5 support is in mainline yet.

I second Rajendra's comment.

Regards
Santosh

maintainer
#8 lore raw

PATCH 1/2 ARM: OMAP: Get rid of reset for system timer

Quoted 26 lines · Shilimkar, Santosh
Quoted 16 lines · Rajendra Nayak
Quoted 5 lines · Tony Lindgren
Quoted 3 lines · Santosh Shilimkar
Quoted 3 lines

?From: Rajendra Nayak<[email protected]>

Quoted 8 lines
Quoted 3 lines
Quoted 3 lines

?hwmod setup already does a reset and sets the OCP sysconfig ?registers appropriately. Avoid doing a reset again and overriding ?the OCP sysconfig settings in the system timer init code.

If we want this queued as a fix, it should also describe what actually breaks? Timer? PM?

Quoted 9 lines

It only fixes the redundant reset and overriding the smartidle-wakeup OCP setting (done by hwmod) with the smartidle in the driver. Doing this doesn't really break anything as yet in mainline, but will cause timer wakeup issues once OFF mode is in place for OMAP4. On OMAP5 however this was causing more issues as the softreset bit position is different than on OMAP2/3/4.
So it should be ok to queue this in for 3.4 considering neither OMAP4 OFF, not OMAP5 support is in mainline yet.

Quoted 1 line

I second Rajendra's comment.

OK thanks, will apply into fixes-non-critical.

Tony

#9 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

In reply to Santosh Shilimkar

arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken.

Move the allocation as part of ->reserve callback to fix the it.

---
 arch/arm/mach-omap2/Kconfig                   |    4 ++--
 arch/arm/mach-omap2/common.h                  |    1 +
 arch/arm/mach-omap2/io.c                      |    1 +
 arch/arm/mach-omap2/omap4-common.c            |   25 ++++++++++++++++---------
 arch/arm/plat-omap/common.c                   |    1 +
 arch/arm/plat-omap/include/plat/omap-secure.h |    6 ++++++
 6 files changed, 27 insertions(+), 11 deletions(-)
arch/arm/mach-omap2/Kconfig +2 -2
index 41e6612..ac6b1d3 100644
@@ -365,8 +365,8 @@ config OMAP3_SDRC_AC_TIMING
 	  going on could result in system crashes;
 
 config OMAP4_ERRATA_I688
-	bool "OMAP4 errata: Async Bridge Corruption (BROKEN)"
-	depends on ARCH_OMAP4 && BROKEN
+	bool "OMAP4 errata: Async Bridge Corruption"
+	depends on ARCH_OMAP4
 	select ARCH_HAS_BARRIERS
 	help
 	  If a data is stalled inside asynchronous bridge because of back
arch/arm/mach-omap2/common.h +1 -0
index febffde..7e9338e 100644
@@ -132,6 +132,7 @@ void omap3_map_io(void);
 void am33xx_map_io(void);
 void omap4_map_io(void);
 void ti81xx_map_io(void);
+void omap_barriers_init(void);
 
 /**
  * omap_test_timeout - busy-loop, testing a condition
arch/arm/mach-omap2/io.c +1 -0
index 3f174d5..f64aa79 100644
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
 void __init omap44xx_map_common_io(void)
 {
 	iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+	omap_barriers_init();
 }
 #endif
 
arch/arm/mach-omap2/omap4-common.c +16 -9
index 40a8fbc..ebc5950 100644
@@ -24,6 +24,7 @@
 
 #include <plat/irqs.h>
 #include <plat/sram.h>
+#include <plat/omap-secure.h>
 
 #include <mach/hardware.h>
 #include <mach/omap-wakeupgen.h>
@@ -43,6 +44,9 @@ static void __iomem *sar_ram_base;
 
 void __iomem *dram_sync, *sram_sync;
 
+static phys_addr_t paddr;
+static u32 size;
+
 void omap_bus_sync(void)
 {
 	if (dram_sync && sram_sync) {
@@ -52,18 +56,20 @@ void omap_bus_sync(void)
 	}
 }
 
-static int __init omap_barriers_init(void)
+/* Steal one page physical memory for barrier implementation */
+int __init omap_barrier_reserve_memblock(void)
 {
-	struct map_desc dram_io_desc[1];
-	phys_addr_t paddr;
-	u32 size;
-
-	if (!cpu_is_omap44xx())
-		return -ENODEV;
 
 	size = ALIGN(PAGE_SIZE, SZ_1M);
 	paddr = arm_memblock_steal(size, SZ_1M);
 
+	return 0;
+}
+
+void __init omap_barriers_init(void)
+{
+	struct map_desc dram_io_desc[1];
+
 	dram_io_desc[0].virtual = OMAP4_DRAM_BARRIER_VA;
 	dram_io_desc[0].pfn = __phys_to_pfn(paddr);
 	dram_io_desc[0].length = size;
@@ -75,9 +81,10 @@ static int __init omap_barriers_init(void)
 	pr_info("OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n",
 		(long long) paddr, dram_io_desc[0].virtual);
 
-	return 0;
 }
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{}
 #endif
 
 void __init gic_init_irq(void)
arch/arm/plat-omap/common.c +1 -0
index 06383b5..4de7d1e 100644
@@ -69,6 +69,7 @@ void __init omap_reserve(void)
 	omap_vram_reserve_sdram_memblock();
 	omap_dsp_reserve_sdram_memblock();
 	omap_secure_ram_reserve_memblock();
+	omap_barrier_reserve_memblock();
 }
 
 void __init omap_init_consistent_dma_size(void)
arch/arm/plat-omap/include/plat/omap-secure.h +6 -0
index 64f9d1c..0f14fb7 100644
@@ -10,4 +10,10 @@ static inline void omap_secure_ram_reserve_memblock(void)
 { }
 #endif
 
+#ifdef CONFIG_OMAP4_ERRATA_I688
+extern int omap_barrier_reserve_memblock(void);
+#else
+static inline void omap_barrier_reserve_memblock(void)
+{ }
+#endif
 #endif /* __OMAP_SECURE_H__ */
Signature · 1 line
1.7.4.1
maintainer
#10 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 5 lines · Santosh Shilimkar

arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken.

Move the allocation as part of ->reserve callback to fix the it.

Please update this to mention again commit that changed things around for arm_memblock_steal() so it's clear why this is needed as a fix.

Regards,

Tony

#11 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 10 lines · Tony Lindgren
Quoted 5 lines · Santosh Shilimkar

arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken.

Move the allocation as part of ->reserve callback to fix the it.

Please update this to mention again commit that changed things around for arm_memblock_steal() so it's clear why this is needed as a fix.

Sure. Patch with updated change log below.

Regards,
Santosh

Quoted 1 line

From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001

From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away from the kernel} introduced arm_memblock_steal() which lead to OMAP4_ERRATA_I688 to be broken and needed to be fixed.

arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken.

Move the allocation as part of ->reserve callback to fix the it.

---
 arch/arm/mach-omap2/Kconfig                   |    4 ++--
 arch/arm/mach-omap2/common.h                  |    1 +
 arch/arm/mach-omap2/io.c                      |    1 +
 arch/arm/mach-omap2/omap4-common.c            |   25
++++++++++++++++---------
 arch/arm/plat-omap/common.c                   |    1 +
 arch/arm/plat-omap/include/plat/omap-secure.h |    6 ++++++
 6 files changed, 27 insertions(+), 11 deletions(-)
arch/arm/mach-omap2/Kconfig +2 -2
index d965da4..e20c8ab 100644
@@ -364,8 +364,8 @@ config OMAP3_SDRC_AC_TIMING
 	  going on could result in system crashes;
 
 config OMAP4_ERRATA_I688
-	bool "OMAP4 errata: Async Bridge Corruption (BROKEN)"
-	depends on ARCH_OMAP4 && BROKEN
+	bool "OMAP4 errata: Async Bridge Corruption"
+	depends on ARCH_OMAP4
 	select ARCH_HAS_BARRIERS
 	help
 	  If a data is stalled inside asynchronous bridge because of back
arch/arm/mach-omap2/common.h +1 -0
index febffde..7e9338e 100644
@@ -132,6 +132,7 @@ void omap3_map_io(void);
 void am33xx_map_io(void);
 void omap4_map_io(void);
 void ti81xx_map_io(void);
+void omap_barriers_init(void);
 
 /**
  * omap_test_timeout - busy-loop, testing a condition
arch/arm/mach-omap2/io.c +1 -0
index eb50c29..fb11b44 100644
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
 void __init omap44xx_map_common_io(void)
 {
 	iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+	omap_barriers_init();
 }
 #endif
 
(quoted diff) +0 -0

b/arch/arm/mach-omap2/omap4-common.c
index 40a8fbc..ebc5950 100644

arch/arm/mach-omap2/omap4-common.c +16 -9
@@ -24,6 +24,7 @@
 
 #include <plat/irqs.h>
 #include <plat/sram.h>
+#include <plat/omap-secure.h>
 
 #include <mach/hardware.h>
 #include <mach/omap-wakeupgen.h>
@@ -43,6 +44,9 @@ static void __iomem *sar_ram_base;
 
 void __iomem *dram_sync, *sram_sync;
 
+static phys_addr_t paddr;
+static u32 size;
+
 void omap_bus_sync(void)
 {
 	if (dram_sync && sram_sync) {
@@ -52,18 +56,20 @@ void omap_bus_sync(void)
 	}
 }
 
-static int __init omap_barriers_init(void)
+/* Steal one page physical memory for barrier implementation */
+int __init omap_barrier_reserve_memblock(void)
 {
-	struct map_desc dram_io_desc[1];
-	phys_addr_t paddr;
-	u32 size;
-
-	if (!cpu_is_omap44xx())
-		return -ENODEV;
 
 	size = ALIGN(PAGE_SIZE, SZ_1M);
 	paddr = arm_memblock_steal(size, SZ_1M);
 
+	return 0;
+}
+
+void __init omap_barriers_init(void)
+{
+	struct map_desc dram_io_desc[1];
+
 	dram_io_desc[0].virtual = OMAP4_DRAM_BARRIER_VA;
 	dram_io_desc[0].pfn = __phys_to_pfn(paddr);
 	dram_io_desc[0].length = size;
@@ -75,9 +81,10 @@ static int __init omap_barriers_init(void)
 	pr_info("OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n",
 		(long long) paddr, dram_io_desc[0].virtual);
 
-	return 0;
 }
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{}
 #endif
 
 void __init gic_init_irq(void)
arch/arm/plat-omap/common.c +1 -0
index 06383b5..4de7d1e 100644
@@ -69,6 +69,7 @@ void __init omap_reserve(void)
 	omap_vram_reserve_sdram_memblock();
 	omap_dsp_reserve_sdram_memblock();
 	omap_secure_ram_reserve_memblock();
+	omap_barrier_reserve_memblock();
 }
 
 void __init omap_init_consistent_dma_size(void)
(quoted diff) +0 -0

b/arch/arm/plat-omap/include/plat/omap-secure.h
index 64f9d1c..0f14fb7 100644

arch/arm/plat-omap/include/plat/omap-secure.h +6 -0
@@ -10,4 +10,10 @@ static inline void omap_secure_ram_reserve_memblock(void)
 { }
 #endif
 
+#ifdef CONFIG_OMAP4_ERRATA_I688
+extern int omap_barrier_reserve_memblock(void);
+#else
+static inline void omap_barrier_reserve_memblock(void)
+{ }
+#endif
 #endif /* __OMAP_SECURE_H__ */
Signature · 9 lines
1.7.4.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-OMAP4-Move-the-barrier-memboclk_steal-as-part-of.patch
Type: text/x-patch
Size: 4978 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120214/3be0f2a6/attachment.bin>
#12 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 9 lines · Santosh Shilimkar
Quoted 1 line

From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001

From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away from the kernel} introduced arm_memblock_steal() which lead to OMAP4_ERRATA_I688 to be broken and needed to be fixed.

That is misleading. Please don't attribute blame for this breakage to that patch, which has nothing to do with introducing the breakage. The errata was broken right from the start.

#13 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Santosh Shilimkar
Quoted 1 line

From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001

From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 7 lines
Quoted 3 lines

Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away from the kernel} introduced arm_memblock_steal() which lead to OMAP4_ERRATA_I688 to be broken and needed to be fixed.

That is misleading. ?Please don't attribute blame for this breakage to that patch, which has nothing to do with introducing the breakage. ?The errata was broken right from the start.

That's right and I didn't mean that way.
This was the same reason, first patch I just mentioned what was wrong in the code
rather than mention of any commit.

Tony,
Let me know if you want to add any commit history to the change since the issue was actually existing without 'arm_memblock_stea()' commit. I think, first change log was good enough from the fix point of view.

Regards
Santosh

maintainer
#14 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 22 lines · Shilimkar, Santosh
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Santosh Shilimkar
Quoted 1 line

From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001

From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

Quoted 7 lines
Quoted 3 lines

Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away from the kernel} introduced arm_memblock_steal() which lead to OMAP4_ERRATA_I688 to be broken and needed to be fixed.

That is misleading. ?Please don't attribute blame for this breakage to that patch, which has nothing to do with introducing the breakage. ?The errata was broken right from the start.

That's right and I didn't mean that way.
This was the same reason, first patch I just mentioned what was wrong in the code
rather than mention of any commit.

Quoted 4 lines

Tony,
Let me know if you want to add any commit history to the change since the issue was actually existing without 'arm_memblock_stea()' commit. I think, first change log was good enough from the fix point of view.

OK, makes sense. I'll apply it into fixes as is then.

Regards,

Tony

#15 lore raw

PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback

In reply to Tony Lindgren
Quoted 10 lines · Tony Lindgren
Quoted 5 lines · Santosh Shilimkar

arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken.

Move the allocation as part of ->reserve callback to fix the it.

Please update this to mention again commit that changed things around for arm_memblock_steal() so it's clear why this is needed as a fix.

It's more the case that this whole errata fix was broken right from the start, and the change to arm_memblock_steal() just enforced correct usage of the APIs.

So, really the arm_memblock_steal() change has nothing to do with this.

#16 lore raw

cover ARM: OMAP: Couple of misc fixes for 3.3

In reply to Santosh Shilimkar

Tony,

Quoted 4 lines · Santosh Shilimkar

Patches are tested on OMAP4430 SDP.

The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:

Quoted 9 lines

?Linux 3.3-rc2 (2012-01-31 13:31:54 -0800)

Rajendra Nayak (1):
?ARM: OMAP: Get rid of reset for system timer

Santosh Shilimkar (1):
?ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve ? ?callback

Can you please queue these two fixes if you are ok with them ?

Regards
Santosh