ARM: OMAP: Couple of misc fixes for 3.3
Subsystems (3)
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
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
@@ -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
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
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
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
Tony Lindgren
maintainerPATCH 1/2 ARM: OMAP: Get rid of reset for system timer
In reply to Santosh ShilimkarQuoted 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
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.
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
Tony Lindgren
maintainerPATCH 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
PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
In reply to Santosh Shilimkararm_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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Tony Lindgren
maintainerPATCH 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
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
4d1ea22985adfe458275b9ae3e00edc6e41a267fMon 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
@@ -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
@@ -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
@@ -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
@@ -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>
PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
Quoted 9 lines · Santosh Shilimkar
Quoted 1 line
From
4d1ea22985adfe458275b9ae3e00edc6e41a267fMon Sep 17 00:00:00 2001From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barriermemboclk_steal()as part of reserve callbackCommit 716a3dc{ARM: Add
arm_memblock_steal()to allocate memory away from the kernel} introducedarm_memblock_steal()which lead toOMAP4_ERRATA_I688to 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
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Santosh Shilimkar
Quoted 1 line
From
4d1ea22985adfe458275b9ae3e00edc6e41a267fMon Sep 17 00:00:00 2001From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barriermemboclk_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} introducedarm_memblock_steal()which lead toOMAP4_ERRATA_I688to 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
Tony Lindgren
maintainerPATCH 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
4d1ea22985adfe458275b9ae3e00edc6e41a267fMon Sep 17 00:00:00 2001From: Santosh Shilimkar <[email protected]>
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barriermemboclk_steal()as part of reserve callbackQuoted 7 lines
Quoted 3 lines
Commit 716a3dc{ARM: Add
arm_memblock_steal()to allocate memory away from the kernel} introducedarm_memblock_steal()which lead toOMAP4_ERRATA_I688to 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
PATCH 2/2 ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
In reply to Tony LindgrenQuoted 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.
cover ARM: OMAP: Couple of misc fixes for 3.3
In reply to Santosh ShilimkarTony,
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 timerSantosh Shilimkar (1):
?ARM: OMAP4: Move the barriermemboclk_steal()as part of reserve ? ?callback
Can you please queue these two fixes if you are ok with them ?
Regards
Santosh