[PATCH 0/2] ARM: OMAP: Couple of misc fixes for 3.3

[PATCH 0/2] ARM: OMAP: Couple of misc fixes for 3.3

[Santosh Shilimkar]

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(-)

-- 
1.7.4.1

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

[Santosh Shilimkar]

From: Rajendra Nayak <rnayak@ti.com>

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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/timer.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 6eeff0e..ccd2d6a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -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);
-- 
1.7.4.1

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

[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.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41e6612..ac6b1d3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..7e9338e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -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
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3f174d5..f64aa79 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -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
 
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 40a8fbc..ebc5950 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -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)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..4de7d1e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -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)
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h b/arch/arm/plat-omap/include/plat/omap-secure.h
index 64f9d1c..0f14fb7 100644
--- a/arch/arm/plat-omap/include/plat/omap-secure.h
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -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__ */
-- 
1.7.4.1

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

[Kevin Hilman]

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> From: Rajendra Nayak <rnayak@ti.com>
>
> 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

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

[Shilimkar, Santosh]

On Fri, Feb 3, 2012 at 12:10 AM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> From: Rajendra Nayak <rnayak@ti.com>
>>
>> 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

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

[Kevin Hilman]

"Shilimkar, Santosh" <santosh.shilimkar@ti.com> writes:

> On Fri, Feb 3, 2012 at 12:10 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> From: Rajendra Nayak <rnayak@ti.com>
>>>
>>> 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.

Great, thanks for testing on OMAP2/3.

Kevin

[PATCH 0/2] ARM: OMAP: Couple of misc fixes for 3.3

[Shilimkar, Santosh]

Tony,

On Thu, Feb 2, 2012 at 7:33 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> 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
>
Can you please queue these two fixes if you are ok
with them ?

Regards
Santosh

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

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [120202 05:33]:
> From: Rajendra Nayak <rnayak@ti.com>
> 
> 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

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

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [120202 05:33]:
> 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

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

[Rajendra Nayak]

On Saturday 11 February 2012 12:48 AM, Tony Lindgren wrote:
> * Santosh Shilimkar<santosh.shilimkar@ti.com>  [120202 05:33]:
>> >  From: Rajendra Nayak<rnayak@ti.com>
>> >
>> >  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.

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

[Shilimkar, Santosh]

On Tue, Feb 14, 2012 at 10:44 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Saturday 11 February 2012 12:48 AM, Tony Lindgren wrote:
>>
>> * Santosh Shilimkar<santosh.shilimkar@ti.com> ?[120202 05:33]:
>>>
>>> > ?From: Rajendra Nayak<rnayak@ti.com>
>>> >
>>> > ?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.
>
I second Rajendra's comment.

Regards
Santosh

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

[Santosh Shilimkar]

On Saturday 11 February 2012 12:49 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [120202 05:33]:
>> 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

>From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
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.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d965da4..e20c8ab 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..7e9338e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -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
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index eb50c29..fb11b44 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -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

diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 40a8fbc..ebc5950 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -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)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..4de7d1e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -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)
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
index 64f9d1c..0f14fb7 100644
--- a/arch/arm/plat-omap/include/plat/omap-secure.h
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -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__ */
-- 
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>

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

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 11:19:26AM -0800, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [120202 05:33]:
> > 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.

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

[Russell King - ARM Linux]

On Tue, Feb 14, 2012 at 02:19:41PM +0530, Santosh Shilimkar wrote:
> >From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 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.

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

[Shilimkar, Santosh]

On Tue, Feb 14, 2012 at 4:44 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 14, 2012 at 02:19:41PM +0530, Santosh Shilimkar wrote:
>> >From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
>> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> 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.

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

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

[Tony Lindgren]

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120214 02:58]:
> On Tue, Feb 14, 2012 at 4:44 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Feb 14, 2012 at 02:19:41PM +0530, Santosh Shilimkar wrote:
> >> >From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
> >> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> 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.
> 
> 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.

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

Regards,

Tony

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

[Tony Lindgren]

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [120213 22:44]:
> On Tue, Feb 14, 2012 at 10:44 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> > On Saturday 11 February 2012 12:48 AM, Tony Lindgren wrote:
> >>
> >> * Santosh Shilimkar<santosh.shilimkar@ti.com> ?[120202 05:33]:
> >>>
> >>> > ?From: Rajendra Nayak<rnayak@ti.com>
> >>> >
> >>> > ?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.
> >
> I second Rajendra's comment.

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

Tony