[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

This set of patches, along with some other patches under
discussion on alkml, should enable omap3 and omap4 kernels to be
built with CONFIG_THUMB2_KERNEL.

This patch set builds on recent cleanup done by the omap
maintainers.

It is also more aggressive than my last post: all affected
low-level code is now built in Thumb-2.  At least some of this
code definitely works, but whether the Secure firmware can talk
to Thumb-2 code properly is unproven:
in particular, I could use some help/advice from the omap
community for validating that the low-level power management
interactions actually work with this patch set.

I've done simple "does it boot?" testing by building a single
kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
which works on Beagle xM A2 and Panda A1.

Details below.

Cheers,
Dave


The patches can be found, along with a buildable working tree,
in the following repo:

git://git.linaro.org/people/dmart/linux-2.6-arm.git

 * arm/omap-thumb2: has the patches proposed here
 * arm/omap-thumb2+merged: additionally has some patches cherry-
        picked from other trees which are needed in order for the
        patches on arm/omap-thumb2 to work usefully.
 * dirty/arm/omap-thumb2+merged: buildable test tree, which adds
        2 local patches to work around a toolchain bug.

A working kernel config for this tree is here:
http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config :

  CONFIG_SMP_ON_UP=y
  CONFIG_THUMB2_KERNEL=y
  CONFIG_SERIAL_OMAP=n (to avoid garbage on xM; for Panda use console=ttyS2)

(The config is derived from the linaro omap config and so turns on
loads of modules -- don't feel you have to build them all...)


Cherry-picked patches originated from Russell's devel tree
and Tony Lindgren's omap-testing tree:

http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing


Dave Martin (5):
  ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL
  ARM: omap4: Convert END() to ENDPROC() for correct linkage with
    CONFIG_THUMB2_KERNEL
  ARM: omap3: Remove hand-encoded SMC instructions
  ARM: omap3: Thumb-2 compatibility for sram34xx.S
  ARM: omap3: Thumb-2 compatibility for sleep34xx.S

 arch/arm/mach-omap2/include/mach/omap4-common.h |    5 ++
 arch/arm/mach-omap2/omap-headsmp.S              |    2 +-
 arch/arm/mach-omap2/omap44xx-smc.S              |    8 ++--
 arch/arm/mach-omap2/sleep34xx.S                 |   56 ++++++++++++++++-------
 arch/arm/mach-omap2/sram34xx.S                  |   28 ++++++++---
 5 files changed, 69 insertions(+), 30 deletions(-)

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

This set of patches, along with some other patches under
discussion on alkml, should enable omap3 and omap4 kernels to be
built with CONFIG_THUMB2_KERNEL.

This patch set builds on recent cleanup done by the omap
maintainers.

It is also more aggressive than my last post: all affected
low-level code is now built in Thumb-2.  At least some of this
code definitely works, but whether the Secure firmware can talk
to Thumb-2 code properly is unproven:
in particular, I could use some help/advice from the omap
community for validating that the low-level power management
interactions actually work with this patch set.

I've done simple "does it boot?" testing by building a single
kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
which works on Beagle xM A2 and Panda A1.

Details below.

Cheers,
Dave


The patches can be found, along with a buildable working tree,
in the following repo:

git://git.linaro.org/people/dmart/linux-2.6-arm.git

 * arm/omap-thumb2: has the patches proposed here
 * arm/omap-thumb2+merged: additionally has some patches cherry-
        picked from other trees which are needed in order for the
        patches on arm/omap-thumb2 to work usefully.
 * dirty/arm/omap-thumb2+merged: buildable test tree, which adds
        2 local patches to work around a toolchain bug.

A working kernel config for this tree is here:
http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config :

  CONFIG_SMP_ON_UP=y
  CONFIG_THUMB2_KERNEL=y
  CONFIG_SERIAL_OMAP=n (to avoid garbage on xM; for Panda use console=ttyS2)

(The config is derived from the linaro omap config and so turns on
loads of modules -- don't feel you have to build them all...)


Cherry-picked patches originated from Russell's devel tree
and Tony Lindgren's omap-testing tree:

http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing


Dave Martin (5):
  ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL
  ARM: omap4: Convert END() to ENDPROC() for correct linkage with
    CONFIG_THUMB2_KERNEL
  ARM: omap3: Remove hand-encoded SMC instructions
  ARM: omap3: Thumb-2 compatibility for sram34xx.S
  ARM: omap3: Thumb-2 compatibility for sleep34xx.S

 arch/arm/mach-omap2/include/mach/omap4-common.h |    5 ++
 arch/arm/mach-omap2/omap-headsmp.S              |    2 +-
 arch/arm/mach-omap2/omap44xx-smc.S              |    8 ++--
 arch/arm/mach-omap2/sleep34xx.S                 |   56 ++++++++++++++++-------
 arch/arm/mach-omap2/sram34xx.S                  |   28 ++++++++---
 5 files changed, 69 insertions(+), 30 deletions(-)

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Dave Martin]

For the Thumb-2 case, the "wfi" mnemonic is used, since in this
case the tools will necessarily be new enough to support it.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 5b0270b..68ce058 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -17,8 +17,13 @@
  * wfi used in low power code. Directly opcode is used instead
  * of instruction to avoid mulit-omap build break
  */
+#ifdef CONFIG_THUMB2_KERNEL
+#define do_wfi()			\
+		__asm__ __volatile__ ("wfi" : : : "memory")
+#else
 #define do_wfi()			\
 		__asm__ __volatile__ (".word	0xe320f003" : : : "memory")
+#endif
 
 #ifdef CONFIG_CACHE_L2X0
 extern void __iomem *l2cache_base;
-- 
1.7.1

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Dave Martin]

For the Thumb-2 case, the "wfi" mnemonic is used, since in this
case the tools will necessarily be new enough to support it.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 5b0270b..68ce058 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -17,8 +17,13 @@
  * wfi used in low power code. Directly opcode is used instead
  * of instruction to avoid mulit-omap build break
  */
+#ifdef CONFIG_THUMB2_KERNEL
+#define do_wfi()			\
+		__asm__ __volatile__ ("wfi" : : : "memory")
+#else
 #define do_wfi()			\
 		__asm__ __volatile__ (".word	0xe320f003" : : : "memory")
+#endif
 
 #ifdef CONFIG_CACHE_L2X0
 extern void __iomem *l2cache_base;
-- 
1.7.1

[PATCH v2 2/5] ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL

[Dave Martin]

Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.

ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/omap-headsmp.S |    2 +-
 arch/arm/mach-omap2/omap44xx-smc.S |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 6ae937a..4ee6aec 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -45,5 +45,5 @@ hold:	ldr	r12,=0x103
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-END(omap_secondary_startup)
+ENDPROC(omap_secondary_startup)
 
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S b/arch/arm/mach-omap2/omap44xx-smc.S
index 1980dc3..e69d37d 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -29,7 +29,7 @@ ENTRY(omap_smc1)
 	dsb
 	smc	#0
 	ldmfd   sp!, {r2-r12, pc}
-END(omap_smc1)
+ENDPROC(omap_smc1)
 
 ENTRY(omap_modify_auxcoreboot0)
 	stmfd   sp!, {r1-r12, lr}
@@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
 	dsb
 	smc	#0
 	ldmfd   sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
+ENDPROC(omap_modify_auxcoreboot0)
 
 ENTRY(omap_auxcoreboot_addr)
 	stmfd   sp!, {r2-r12, lr}
@@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
 	dsb
 	smc	#0
 	ldmfd   sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
+ENDPROC(omap_auxcoreboot_addr)
 
 ENTRY(omap_read_auxcoreboot0)
 	stmfd   sp!, {r2-r12, lr}
@@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
 	smc	#0
 	mov	r0, r0, lsr #9
 	ldmfd   sp!, {r2-r12, pc}
-END(omap_read_auxcoreboot0)
+ENDPROC(omap_read_auxcoreboot0)
-- 
1.7.1

[PATCH v2 2/5] ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL

[Dave Martin]

Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.

ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/omap-headsmp.S |    2 +-
 arch/arm/mach-omap2/omap44xx-smc.S |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 6ae937a..4ee6aec 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -45,5 +45,5 @@ hold:	ldr	r12,=0x103
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-END(omap_secondary_startup)
+ENDPROC(omap_secondary_startup)
 
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S b/arch/arm/mach-omap2/omap44xx-smc.S
index 1980dc3..e69d37d 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -29,7 +29,7 @@ ENTRY(omap_smc1)
 	dsb
 	smc	#0
 	ldmfd   sp!, {r2-r12, pc}
-END(omap_smc1)
+ENDPROC(omap_smc1)
 
 ENTRY(omap_modify_auxcoreboot0)
 	stmfd   sp!, {r1-r12, lr}
@@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
 	dsb
 	smc	#0
 	ldmfd   sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
+ENDPROC(omap_modify_auxcoreboot0)
 
 ENTRY(omap_auxcoreboot_addr)
 	stmfd   sp!, {r2-r12, lr}
@@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
 	dsb
 	smc	#0
 	ldmfd   sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
+ENDPROC(omap_auxcoreboot_addr)
 
 ENTRY(omap_read_auxcoreboot0)
 	stmfd   sp!, {r2-r12, lr}
@@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
 	smc	#0
 	mov	r0, r0, lsr #9
 	ldmfd   sp!, {r2-r12, pc}
-END(omap_read_auxcoreboot0)
+ENDPROC(omap_read_auxcoreboot0)
-- 
1.7.1

[PATCH v2 3/5] ARM: omap3: Remove hand-encoded SMC instructions

[Dave Martin]

For various reasons, Linux now only officially supports being built
with tools which are new enough to understand the SMC instruction.

Replacing the hand-encoded instructions when the mnemonic also
allows for correct assembly in Thumb-2 (otherwise, the result is
random data in the middle of the code).

The Makefile already ensures that this file is built with a high
enough gcc -march= flag (armv7-a).

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/sleep34xx.S |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 98d8232..4032a8e 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context)
 	mov	r6, #0xff
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 	nop
 	nop
 	nop
@@ -408,7 +408,7 @@ skipl2dis:
 	adr	r3, l2_inv_api_params	@ r3 points to dummy parameters
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 	/* Write to Aux control register to set some bits */
 	mov	r0, #42			@ set service ID for PPA
 	mov	r12, r0			@ copy secure Service ID in r12
@@ -419,7 +419,7 @@ skipl2dis:
 	ldr	r3, [r4, #0xBC]		@ r3 points to parameters
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 
 #ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
 	/* Restore L2 aux control register */
@@ -434,7 +434,7 @@ skipl2dis:
 	adds	r3, r3, #8		@ r3 points to parameters
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 #endif
 	b	logic_l1_restore
 
@@ -443,18 +443,18 @@ l2_inv_api_params:
 l2_inv_gp:
 	/* Execute smi to invalidate L2 cache */
 	mov r12, #0x1			@ set up to invalidate L2
-	.word 0xE1600070		@ Call SMI monitor (smieq)
+	smc	0			@ Call SMI monitor (smieq)
 	/* Write to Aux control register to set some bits */
 	ldr	r4, scratchpad_base
 	ldr	r3, [r4,#0xBC]
 	ldr	r0, [r3,#4]
 	mov	r12, #0x3
-	.word	0xE1600070		@ Call SMI monitor (smieq)
+	smc	0			@ Call SMI monitor (smieq)
 	ldr	r4, scratchpad_base
 	ldr	r3, [r4,#0xBC]
 	ldr	r0, [r3,#12]
 	mov	r12, #0x2
-	.word	0xE1600070		@ Call SMI monitor (smieq)
+	smc	0			@ Call SMI monitor (smieq)
 logic_l1_restore:
 	ldr	r1, l2dis_3630
 	cmp	r1, #0x1		@ Test if L2 re-enable needed on 3630
-- 
1.7.1

[PATCH v2 3/5] ARM: omap3: Remove hand-encoded SMC instructions

[Dave Martin]

For various reasons, Linux now only officially supports being built
with tools which are new enough to understand the SMC instruction.

Replacing the hand-encoded instructions when the mnemonic also
allows for correct assembly in Thumb-2 (otherwise, the result is
random data in the middle of the code).

The Makefile already ensures that this file is built with a high
enough gcc -march= flag (armv7-a).

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/sleep34xx.S |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 98d8232..4032a8e 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context)
 	mov	r6, #0xff
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 	nop
 	nop
 	nop
@@ -408,7 +408,7 @@ skipl2dis:
 	adr	r3, l2_inv_api_params	@ r3 points to dummy parameters
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 	/* Write to Aux control register to set some bits */
 	mov	r0, #42			@ set service ID for PPA
 	mov	r12, r0			@ copy secure Service ID in r12
@@ -419,7 +419,7 @@ skipl2dis:
 	ldr	r3, [r4, #0xBC]		@ r3 points to parameters
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 
 #ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
 	/* Restore L2 aux control register */
@@ -434,7 +434,7 @@ skipl2dis:
 	adds	r3, r3, #8		@ r3 points to parameters
 	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
 	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
-	.word	0xE1600071		@ call SMI monitor (smi #1)
+	smc	1			@ call SMI monitor (smi #1)
 #endif
 	b	logic_l1_restore
 
@@ -443,18 +443,18 @@ l2_inv_api_params:
 l2_inv_gp:
 	/* Execute smi to invalidate L2 cache */
 	mov r12, #0x1			@ set up to invalidate L2
-	.word 0xE1600070		@ Call SMI monitor (smieq)
+	smc	0			@ Call SMI monitor (smieq)
 	/* Write to Aux control register to set some bits */
 	ldr	r4, scratchpad_base
 	ldr	r3, [r4,#0xBC]
 	ldr	r0, [r3,#4]
 	mov	r12, #0x3
-	.word	0xE1600070		@ Call SMI monitor (smieq)
+	smc	0			@ Call SMI monitor (smieq)
 	ldr	r4, scratchpad_base
 	ldr	r3, [r4,#0xBC]
 	ldr	r0, [r3,#12]
 	mov	r12, #0x2
-	.word	0xE1600070		@ Call SMI monitor (smieq)
+	smc	0			@ Call SMI monitor (smieq)
 logic_l1_restore:
 	ldr	r1, l2dis_3630
 	cmp	r1, #0x1		@ Test if L2 re-enable needed on 3630
-- 
1.7.1

[PATCH v2 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S

[Dave Martin]

 * Remove deprecated/undefined PC-relative stores
 * Add the required ENDPROC() directive for each ENTRY().
 * .align before data words

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/sram34xx.S |   28 ++++++++++++++++++++--------
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 7f893a2..829d235 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -116,24 +116,34 @@ ENTRY(omap3_sram_configure_core_dpll)
 
 					@ pull the extra args off the stack
 					@  and store them in SRAM
+
+@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
+@ base instead.
+@ Be careful not to clobber r7 when maintaing this file.
+ THUMB(	adr	r7, omap3_sram_configure_core_dpll			)
+	.macro strtext Rt:req, label:req
+ ARM(	str	\Rt, \label						)
+ THUMB(	str	\Rt, [r7, \label - omap3_sram_configure_core_dpll]	)
+	.endm
+
 	ldr	r4, [sp, #52]
-	str     r4, omap_sdrc_rfr_ctrl_0_val
+	strtext	r4, omap_sdrc_rfr_ctrl_0_val
 	ldr	r4, [sp, #56]
-	str     r4, omap_sdrc_actim_ctrl_a_0_val
+	strtext	r4, omap_sdrc_actim_ctrl_a_0_val
 	ldr	r4, [sp, #60]
-	str     r4, omap_sdrc_actim_ctrl_b_0_val
+	strtext	r4, omap_sdrc_actim_ctrl_b_0_val
 	ldr	r4, [sp, #64]
-	str     r4, omap_sdrc_mr_0_val
+	strtext	r4, omap_sdrc_mr_0_val
 	ldr	r4, [sp, #68]
-	str     r4, omap_sdrc_rfr_ctrl_1_val
+	strtext	r4, omap_sdrc_rfr_ctrl_1_val
 	cmp	r4, #0			@ if SDRC_RFR_CTRL_1 is 0,
 	beq	skip_cs1_params		@  do not use cs1 params
 	ldr	r4, [sp, #72]
-	str     r4, omap_sdrc_actim_ctrl_a_1_val
+	strtext	r4, omap_sdrc_actim_ctrl_a_1_val
 	ldr	r4, [sp, #76]
-	str     r4, omap_sdrc_actim_ctrl_b_1_val
+	strtext	r4, omap_sdrc_actim_ctrl_b_1_val
 	ldr	r4, [sp, #80]
-	str     r4, omap_sdrc_mr_1_val
+	strtext	r4, omap_sdrc_mr_1_val
 skip_cs1_params:
 	mrc	p15, 0, r8, c1, c0, 0	@ read ctrl register
 	bic	r10, r8, #0x800		@ clear Z-bit, disable branch prediction
@@ -271,6 +281,7 @@ skip_cs1_prog:
 	ldr	r12, [r11]		@ posted-write barrier for SDRC
 	bx	lr
 
+	.align
 omap3_sdrc_power:
 	.word OMAP34XX_SDRC_REGADDR(SDRC_POWER)
 omap3_cm_clksel1_pll:
@@ -319,6 +330,7 @@ omap3_sdrc_dlla_ctrl:
 	.word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
 core_m2_mask_val:
 	.word 0x07FFFFFF
+ENDPROC(omap3_sram_configure_core_dpll)
 
 ENTRY(omap3_sram_configure_core_dpll_sz)
 	.word	. - omap3_sram_configure_core_dpll
-- 
1.7.1

[PATCH v2 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S

[Dave Martin]

 * Remove deprecated/undefined PC-relative stores
 * Add the required ENDPROC() directive for each ENTRY().
 * .align before data words

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/sram34xx.S |   28 ++++++++++++++++++++--------
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 7f893a2..829d235 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -116,24 +116,34 @@ ENTRY(omap3_sram_configure_core_dpll)
 
 					@ pull the extra args off the stack
 					@  and store them in SRAM
+
+@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
+@ base instead.
+@ Be careful not to clobber r7 when maintaing this file.
+ THUMB(	adr	r7, omap3_sram_configure_core_dpll			)
+	.macro strtext Rt:req, label:req
+ ARM(	str	\Rt, \label						)
+ THUMB(	str	\Rt, [r7, \label - omap3_sram_configure_core_dpll]	)
+	.endm
+
 	ldr	r4, [sp, #52]
-	str     r4, omap_sdrc_rfr_ctrl_0_val
+	strtext	r4, omap_sdrc_rfr_ctrl_0_val
 	ldr	r4, [sp, #56]
-	str     r4, omap_sdrc_actim_ctrl_a_0_val
+	strtext	r4, omap_sdrc_actim_ctrl_a_0_val
 	ldr	r4, [sp, #60]
-	str     r4, omap_sdrc_actim_ctrl_b_0_val
+	strtext	r4, omap_sdrc_actim_ctrl_b_0_val
 	ldr	r4, [sp, #64]
-	str     r4, omap_sdrc_mr_0_val
+	strtext	r4, omap_sdrc_mr_0_val
 	ldr	r4, [sp, #68]
-	str     r4, omap_sdrc_rfr_ctrl_1_val
+	strtext	r4, omap_sdrc_rfr_ctrl_1_val
 	cmp	r4, #0			@ if SDRC_RFR_CTRL_1 is 0,
 	beq	skip_cs1_params		@  do not use cs1 params
 	ldr	r4, [sp, #72]
-	str     r4, omap_sdrc_actim_ctrl_a_1_val
+	strtext	r4, omap_sdrc_actim_ctrl_a_1_val
 	ldr	r4, [sp, #76]
-	str     r4, omap_sdrc_actim_ctrl_b_1_val
+	strtext	r4, omap_sdrc_actim_ctrl_b_1_val
 	ldr	r4, [sp, #80]
-	str     r4, omap_sdrc_mr_1_val
+	strtext	r4, omap_sdrc_mr_1_val
 skip_cs1_params:
 	mrc	p15, 0, r8, c1, c0, 0	@ read ctrl register
 	bic	r10, r8, #0x800		@ clear Z-bit, disable branch prediction
@@ -271,6 +281,7 @@ skip_cs1_prog:
 	ldr	r12, [r11]		@ posted-write barrier for SDRC
 	bx	lr
 
+	.align
 omap3_sdrc_power:
 	.word OMAP34XX_SDRC_REGADDR(SDRC_POWER)
 omap3_cm_clksel1_pll:
@@ -319,6 +330,7 @@ omap3_sdrc_dlla_ctrl:
 	.word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
 core_m2_mask_val:
 	.word 0x07FFFFFF
+ENDPROC(omap3_sram_configure_core_dpll)
 
 ENTRY(omap3_sram_configure_core_dpll_sz)
 	.word	. - omap3_sram_configure_core_dpll
-- 
1.7.1

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Dave Martin]

 * Use BSYM() to get the correct Thumb branch address
   for adr <Rd>, <label>

 * Fix an out-of-range ADR when building for ARM

 * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.

 * Remove deprecated/undefined PC-relative stores

 * Add the required ENDPROC() directive for each ENTRY().

 * .align before data words

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/sleep34xx.S |   42 +++++++++++++++++++++++++++++---------
 1 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 4032a8e..ef73429 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -80,8 +80,10 @@
 /* Function call to get the restore pointer for resume from OFF */
 ENTRY(get_restore_pointer)
 	stmfd	sp!, {lr}	@ save registers on stack
-	adr	r0, restore
+	adr	r0, BSYM(restore)
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(get_restore_pointer)
+	.align
 ENTRY(get_restore_pointer_sz)
 	.word	. - get_restore_pointer
 
@@ -89,8 +91,10 @@ ENTRY(get_restore_pointer_sz)
 /* Function call to get the restore pointer for 3630 resume from OFF */
 ENTRY(get_omap3630_restore_pointer)
 	stmfd	sp!, {lr}	@ save registers on stack
-	adr	r0, restore_3630
+	adr	r0, BSYM(restore_3630)
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(get_omap3630_restore_pointer)
+	.align
 ENTRY(get_omap3630_restore_pointer_sz)
 	.word	. - get_omap3630_restore_pointer
 
@@ -98,8 +102,10 @@ ENTRY(get_omap3630_restore_pointer_sz)
 /* Function call to get the restore pointer for ES3 to resume from OFF */
 ENTRY(get_es3_restore_pointer)
 	stmfd	sp!, {lr}	@ save registers on stack
-	adr	r0, restore_es3
+	adr	r0, BSYM(restore_es3)
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(get_es3_restore_pointer)
+	.align
 ENTRY(get_es3_restore_pointer_sz)
 	.word	. - get_es3_restore_pointer
 
@@ -113,8 +119,11 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
 	stmfd	sp!, {lr}	@ save registers on stack
 	/* Setup so that we will disable and enable l2 */
 	mov	r1, #0x1
-	str	r1, l2dis_3630
+ ARM(	adrl	r2, l2dis_3630	)	@ may be out of range for adr in ARM
+ THUMB(	adr	r2, l2dis_3630	)	@ Thumb has more range, but not adrl
+	str	r1, [r2]
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(enable_omap3630_toggle_l2_on_restore)
 
 	.text
 /* Function to call rom code to save secure ram context */
@@ -139,12 +148,14 @@ ENTRY(save_secure_ram_context)
 	nop
 	nop
 	ldmfd	sp!, {r1-r12, pc}
+	.align
 sram_phy_addr_mask:
 	.word	SRAM_BASE_P
 high_mask:
 	.word	0xffff
 api_params:
 	.word	0x4, 0x0, 0x0, 0x1, 0x1
+ENDPROC(save_secure_ram_context)
 ENTRY(save_secure_ram_context_sz)
 	.word	. - save_secure_ram_context
 
@@ -279,8 +290,7 @@ clean_l2:
 	 *  - 'might' have to copy address, load and jump to it
 	 */
 	ldr	r1, kernel_flush
-	mov	lr, pc
-	bx	r1
+	blx	r1
 
 omap3_do_wfi:
 	ldr	r4, sdrc_power		@ read the SDRC_POWER register
@@ -346,8 +356,8 @@ restore_es3:
 	and	r4, r4, #0x3
 	cmp	r4, #0x0	@ Check if previous power state of CORE is OFF
 	bne	restore
-	adr	r0, es3_sdrc_fix
-	ldr	r1, sram_base
+	adr	r0, es3_sdrc_fix	@ Not using BSYM clears the Thumb bit.
+	ldr	r1, sram_base	@ Must be 8-byte aligned to preserve alignment.
 	ldr	r2, es3_sdrc_fix_sz
 	mov	r2, r2, ror #2
 copy_to_sram:
@@ -356,6 +366,7 @@ copy_to_sram:
 	subs	r2, r2, #0x1	@ num_words--
 	bne	copy_to_sram
 	ldr	r1, sram_base
+ THUMB(	orr	r1, r1, #BSYM(es3_sdrc_fix) & 1 )
 	blx	r1
 	b	restore
 
@@ -438,6 +449,7 @@ skipl2dis:
 #endif
 	b	logic_l1_restore
 
+	.align
 l2_inv_api_params:
 	.word	0x1, 0x00
 l2_inv_gp:
@@ -607,6 +619,7 @@ usettbr0:
 
 /* This function implements the erratum ID i443 WA, applies to 34xx >= ES3.0 */
 	.text
+	.align	3
 ENTRY(es3_sdrc_fix)
 	ldr	r4, sdrc_syscfg		@ get config addr
 	ldr	r5, [r4]		@ get value
@@ -634,6 +647,7 @@ ENTRY(es3_sdrc_fix)
 	str	r5, [r4]		@ kick off refreshes
 	bx	lr
 
+	.align
 sdrc_syscfg:
 	.word	SDRC_SYSCONFIG_P
 sdrc_mr_0:
@@ -648,6 +662,7 @@ sdrc_emr2_1:
 	.word	SDRC_EMR2_1_P
 sdrc_manual_1:
 	.word	SDRC_MANUAL_1_P
+ENDPROC(es3_sdrc_fix)
 ENTRY(es3_sdrc_fix_sz)
 	.word	. - es3_sdrc_fix
 
@@ -682,6 +697,10 @@ wait_sdrc_ready:
 	bic	r5, r5, #0x40
 	str	r5, [r4]
 
+@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
+@ base instead.
+@ Be careful not to clobber r7 when maintaing this code.
+
 is_dll_in_lock_mode:
 	/* Is dll in lock mode? */
 	ldr	r4, sdrc_dlla_ctrl
@@ -689,10 +708,11 @@ is_dll_in_lock_mode:
 	tst	r5, #0x4
 	bxne	lr			@ Return if locked
 	/* wait till dll locks */
+	adr	r7, kick_counter
 wait_dll_lock_timed:
 	ldr	r4, wait_dll_lock_counter
 	add	r4, r4, #1
-	str	r4, wait_dll_lock_counter
+	str	r4, [r7, #wait_dll_lock_counter - kick_counter]
 	ldr	r4, sdrc_dlla_status
 	/* Wait 20uS for lock */
 	mov	r6, #8
@@ -718,9 +738,10 @@ kick_dll:
 	dsb
 	ldr	r4, kick_counter
 	add	r4, r4, #1
-	str	r4, kick_counter
+	str	r4, [r7]		@ kick_counter
 	b	wait_dll_lock_timed
 
+	.align
 cm_idlest1_core:
 	.word	CM_IDLEST1_CORE_V
 cm_idlest_ckgen:
@@ -763,6 +784,7 @@ kick_counter:
 	.word	0
 wait_dll_lock_counter:
 	.word	0
+ENDPROC(omap34xx_cpu_suspend)
 
 ENTRY(omap34xx_cpu_suspend_sz)
 	.word	. - omap34xx_cpu_suspend
-- 
1.7.1

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Dave Martin]

 * Use BSYM() to get the correct Thumb branch address
   for adr <Rd>, <label>

 * Fix an out-of-range ADR when building for ARM

 * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.

 * Remove deprecated/undefined PC-relative stores

 * Add the required ENDPROC() directive for each ENTRY().

 * .align before data words

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/mach-omap2/sleep34xx.S |   42 +++++++++++++++++++++++++++++---------
 1 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 4032a8e..ef73429 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -80,8 +80,10 @@
 /* Function call to get the restore pointer for resume from OFF */
 ENTRY(get_restore_pointer)
 	stmfd	sp!, {lr}	@ save registers on stack
-	adr	r0, restore
+	adr	r0, BSYM(restore)
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(get_restore_pointer)
+	.align
 ENTRY(get_restore_pointer_sz)
 	.word	. - get_restore_pointer
 
@@ -89,8 +91,10 @@ ENTRY(get_restore_pointer_sz)
 /* Function call to get the restore pointer for 3630 resume from OFF */
 ENTRY(get_omap3630_restore_pointer)
 	stmfd	sp!, {lr}	@ save registers on stack
-	adr	r0, restore_3630
+	adr	r0, BSYM(restore_3630)
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(get_omap3630_restore_pointer)
+	.align
 ENTRY(get_omap3630_restore_pointer_sz)
 	.word	. - get_omap3630_restore_pointer
 
@@ -98,8 +102,10 @@ ENTRY(get_omap3630_restore_pointer_sz)
 /* Function call to get the restore pointer for ES3 to resume from OFF */
 ENTRY(get_es3_restore_pointer)
 	stmfd	sp!, {lr}	@ save registers on stack
-	adr	r0, restore_es3
+	adr	r0, BSYM(restore_es3)
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(get_es3_restore_pointer)
+	.align
 ENTRY(get_es3_restore_pointer_sz)
 	.word	. - get_es3_restore_pointer
 
@@ -113,8 +119,11 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
 	stmfd	sp!, {lr}	@ save registers on stack
 	/* Setup so that we will disable and enable l2 */
 	mov	r1, #0x1
-	str	r1, l2dis_3630
+ ARM(	adrl	r2, l2dis_3630	)	@ may be out of range for adr in ARM
+ THUMB(	adr	r2, l2dis_3630	)	@ Thumb has more range, but not adrl
+	str	r1, [r2]
 	ldmfd	sp!, {pc}	@ restore regs and return
+ENDPROC(enable_omap3630_toggle_l2_on_restore)
 
 	.text
 /* Function to call rom code to save secure ram context */
@@ -139,12 +148,14 @@ ENTRY(save_secure_ram_context)
 	nop
 	nop
 	ldmfd	sp!, {r1-r12, pc}
+	.align
 sram_phy_addr_mask:
 	.word	SRAM_BASE_P
 high_mask:
 	.word	0xffff
 api_params:
 	.word	0x4, 0x0, 0x0, 0x1, 0x1
+ENDPROC(save_secure_ram_context)
 ENTRY(save_secure_ram_context_sz)
 	.word	. - save_secure_ram_context
 
@@ -279,8 +290,7 @@ clean_l2:
 	 *  - 'might' have to copy address, load and jump to it
 	 */
 	ldr	r1, kernel_flush
-	mov	lr, pc
-	bx	r1
+	blx	r1
 
 omap3_do_wfi:
 	ldr	r4, sdrc_power		@ read the SDRC_POWER register
@@ -346,8 +356,8 @@ restore_es3:
 	and	r4, r4, #0x3
 	cmp	r4, #0x0	@ Check if previous power state of CORE is OFF
 	bne	restore
-	adr	r0, es3_sdrc_fix
-	ldr	r1, sram_base
+	adr	r0, es3_sdrc_fix	@ Not using BSYM clears the Thumb bit.
+	ldr	r1, sram_base	@ Must be 8-byte aligned to preserve alignment.
 	ldr	r2, es3_sdrc_fix_sz
 	mov	r2, r2, ror #2
 copy_to_sram:
@@ -356,6 +366,7 @@ copy_to_sram:
 	subs	r2, r2, #0x1	@ num_words--
 	bne	copy_to_sram
 	ldr	r1, sram_base
+ THUMB(	orr	r1, r1, #BSYM(es3_sdrc_fix) & 1 )
 	blx	r1
 	b	restore
 
@@ -438,6 +449,7 @@ skipl2dis:
 #endif
 	b	logic_l1_restore
 
+	.align
 l2_inv_api_params:
 	.word	0x1, 0x00
 l2_inv_gp:
@@ -607,6 +619,7 @@ usettbr0:
 
 /* This function implements the erratum ID i443 WA, applies to 34xx >= ES3.0 */
 	.text
+	.align	3
 ENTRY(es3_sdrc_fix)
 	ldr	r4, sdrc_syscfg		@ get config addr
 	ldr	r5, [r4]		@ get value
@@ -634,6 +647,7 @@ ENTRY(es3_sdrc_fix)
 	str	r5, [r4]		@ kick off refreshes
 	bx	lr
 
+	.align
 sdrc_syscfg:
 	.word	SDRC_SYSCONFIG_P
 sdrc_mr_0:
@@ -648,6 +662,7 @@ sdrc_emr2_1:
 	.word	SDRC_EMR2_1_P
 sdrc_manual_1:
 	.word	SDRC_MANUAL_1_P
+ENDPROC(es3_sdrc_fix)
 ENTRY(es3_sdrc_fix_sz)
 	.word	. - es3_sdrc_fix
 
@@ -682,6 +697,10 @@ wait_sdrc_ready:
 	bic	r5, r5, #0x40
 	str	r5, [r4]
 
+@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
+@ base instead.
+@ Be careful not to clobber r7 when maintaing this code.
+
 is_dll_in_lock_mode:
 	/* Is dll in lock mode? */
 	ldr	r4, sdrc_dlla_ctrl
@@ -689,10 +708,11 @@ is_dll_in_lock_mode:
 	tst	r5, #0x4
 	bxne	lr			@ Return if locked
 	/* wait till dll locks */
+	adr	r7, kick_counter
 wait_dll_lock_timed:
 	ldr	r4, wait_dll_lock_counter
 	add	r4, r4, #1
-	str	r4, wait_dll_lock_counter
+	str	r4, [r7, #wait_dll_lock_counter - kick_counter]
 	ldr	r4, sdrc_dlla_status
 	/* Wait 20uS for lock */
 	mov	r6, #8
@@ -718,9 +738,10 @@ kick_dll:
 	dsb
 	ldr	r4, kick_counter
 	add	r4, r4, #1
-	str	r4, kick_counter
+	str	r4, [r7]		@ kick_counter
 	b	wait_dll_lock_timed
 
+	.align
 cm_idlest1_core:
 	.word	CM_IDLEST1_CORE_V
 cm_idlest_ckgen:
@@ -763,6 +784,7 @@ kick_counter:
 	.word	0
 wait_dll_lock_counter:
 	.word	0
+ENDPROC(omap34xx_cpu_suspend)
 
 ENTRY(omap34xx_cpu_suspend_sz)
 	.word	. - omap34xx_cpu_suspend
-- 
1.7.1

RE: [PATCH v2 3/5] ARM: omap3: Remove hand-encoded SMC instructions

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 3/5] ARM: omap3: Remove hand-encoded SMC
> instructions
>
> For various reasons, Linux now only officially supports being built
> with tools which are new enough to understand the SMC instruction.
>
> Replacing the hand-encoded instructions when the mnemonic also
> allows for correct assembly in Thumb-2 (otherwise, the result is
> random data in the middle of the code).
>
> The Makefile already ensures that this file is built with a high
> enough gcc -march= flag (armv7-a).
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

I had a similar patch which was planning to post.
May be you could use "smc #1" for consistency.
Otherwise, patch looks fine to me
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

> ---
>  arch/arm/mach-omap2/sleep34xx.S |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
> omap2/sleep34xx.S
> index 98d8232..4032a8e 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context)
>  	mov	r6, #0xff
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>  	nop
>  	nop
>  	nop
> @@ -408,7 +408,7 @@ skipl2dis:
>  	adr	r3, l2_inv_api_params	@ r3 points to dummy parameters
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>  	/* Write to Aux control register to set some bits */
>  	mov	r0, #42			@ set service ID for PPA
>  	mov	r12, r0			@ copy secure Service ID in r12
> @@ -419,7 +419,7 @@ skipl2dis:
>  	ldr	r3, [r4, #0xBC]		@ r3 points to parameters
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>
>  #ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
>  	/* Restore L2 aux control register */
> @@ -434,7 +434,7 @@ skipl2dis:
>  	adds	r3, r3, #8		@ r3 points to parameters
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>  #endif
>  	b	logic_l1_restore
>
> @@ -443,18 +443,18 @@ l2_inv_api_params:
>  l2_inv_gp:
>  	/* Execute smi to invalidate L2 cache */
>  	mov r12, #0x1			@ set up to invalidate L2
> -	.word 0xE1600070		@ Call SMI monitor (smieq)
> +	smc	0			@ Call SMI monitor (smieq)
>  	/* Write to Aux control register to set some bits */
>  	ldr	r4, scratchpad_base
>  	ldr	r3, [r4,#0xBC]
>  	ldr	r0, [r3,#4]
>  	mov	r12, #0x3
> -	.word	0xE1600070		@ Call SMI monitor (smieq)
> +	smc	0			@ Call SMI monitor (smieq)
>  	ldr	r4, scratchpad_base
>  	ldr	r3, [r4,#0xBC]
>  	ldr	r0, [r3,#12]
>  	mov	r12, #0x2
> -	.word	0xE1600070		@ Call SMI monitor (smieq)
> +	smc	0			@ Call SMI monitor (smieq)
>  logic_l1_restore:
>  	ldr	r1, l2dis_3630
>  	cmp	r1, #0x1		@ Test if L2 re-enable needed on
3630
> --
> 1.7.1

[PATCH v2 3/5] ARM: omap3: Remove hand-encoded SMC instructions

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 3/5] ARM: omap3: Remove hand-encoded SMC
> instructions
>
> For various reasons, Linux now only officially supports being built
> with tools which are new enough to understand the SMC instruction.
>
> Replacing the hand-encoded instructions when the mnemonic also
> allows for correct assembly in Thumb-2 (otherwise, the result is
> random data in the middle of the code).
>
> The Makefile already ensures that this file is built with a high
> enough gcc -march= flag (armv7-a).
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

I had a similar patch which was planning to post.
May be you could use "smc #1" for consistency.
Otherwise, patch looks fine to me
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

> ---
>  arch/arm/mach-omap2/sleep34xx.S |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
> omap2/sleep34xx.S
> index 98d8232..4032a8e 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context)
>  	mov	r6, #0xff
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>  	nop
>  	nop
>  	nop
> @@ -408,7 +408,7 @@ skipl2dis:
>  	adr	r3, l2_inv_api_params	@ r3 points to dummy parameters
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>  	/* Write to Aux control register to set some bits */
>  	mov	r0, #42			@ set service ID for PPA
>  	mov	r12, r0			@ copy secure Service ID in r12
> @@ -419,7 +419,7 @@ skipl2dis:
>  	ldr	r3, [r4, #0xBC]		@ r3 points to parameters
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>
>  #ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
>  	/* Restore L2 aux control register */
> @@ -434,7 +434,7 @@ skipl2dis:
>  	adds	r3, r3, #8		@ r3 points to parameters
>  	mcr	p15, 0, r0, c7, c10, 4	@ data write barrier
>  	mcr	p15, 0, r0, c7, c10, 5	@ data memory barrier
> -	.word	0xE1600071		@ call SMI monitor (smi #1)
> +	smc	1			@ call SMI monitor (smi #1)
>  #endif
>  	b	logic_l1_restore
>
> @@ -443,18 +443,18 @@ l2_inv_api_params:
>  l2_inv_gp:
>  	/* Execute smi to invalidate L2 cache */
>  	mov r12, #0x1			@ set up to invalidate L2
> -	.word 0xE1600070		@ Call SMI monitor (smieq)
> +	smc	0			@ Call SMI monitor (smieq)
>  	/* Write to Aux control register to set some bits */
>  	ldr	r4, scratchpad_base
>  	ldr	r3, [r4,#0xBC]
>  	ldr	r0, [r3,#4]
>  	mov	r12, #0x3
> -	.word	0xE1600070		@ Call SMI monitor (smieq)
> +	smc	0			@ Call SMI monitor (smieq)
>  	ldr	r4, scratchpad_base
>  	ldr	r3, [r4,#0xBC]
>  	ldr	r0, [r3,#12]
>  	mov	r12, #0x2
> -	.word	0xE1600070		@ Call SMI monitor (smieq)
> +	smc	0			@ Call SMI monitor (smieq)
>  logic_l1_restore:
>  	ldr	r1, l2dis_3630
>  	cmp	r1, #0x1		@ Test if L2 re-enable needed on
3630
> --
> 1.7.1

RE: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi()
> for CONFIG_THUMB2_KERNEL
>
> For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> case the tools will necessarily be new enough to support it.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

I guess, we discussed this patch in your previous post.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

> ---
>  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> b/arch/arm/mach-omap2/include/mach/omap4-common.h
> index 5b0270b..68ce058 100644
> --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> @@ -17,8 +17,13 @@
>   * wfi used in low power code. Directly opcode is used instead
>   * of instruction to avoid mulit-omap build break
>   */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define do_wfi()			\
> +		__asm__ __volatile__ ("wfi" : : : "memory")
> +#else
>  #define do_wfi()			\
>  		__asm__ __volatile__ (".word	0xe320f003" : : :
> "memory")
> +#endif
>
>  #ifdef CONFIG_CACHE_L2X0
>  extern void __iomem *l2cache_base;
> --
> 1.7.1

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi()
> for CONFIG_THUMB2_KERNEL
>
> For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> case the tools will necessarily be new enough to support it.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

I guess, we discussed this patch in your previous post.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

> ---
>  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> b/arch/arm/mach-omap2/include/mach/omap4-common.h
> index 5b0270b..68ce058 100644
> --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> @@ -17,8 +17,13 @@
>   * wfi used in low power code. Directly opcode is used instead
>   * of instruction to avoid mulit-omap build break
>   */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define do_wfi()			\
> +		__asm__ __volatile__ ("wfi" : : : "memory")
> +#else
>  #define do_wfi()			\
>  		__asm__ __volatile__ (".word	0xe320f003" : : :
> "memory")
> +#endif
>
>  #ifdef CONFIG_CACHE_L2X0
>  extern void __iomem *l2cache_base;
> --
> 1.7.1

RE: [PATCH v2 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 4/5] ARM: omap3: Thumb-2 compatibility for
> sram34xx.S
>
>  * Remove deprecated/undefined PC-relative stores
>  * Add the required ENDPROC() directive for each ENTRY().
>  * .align before data words
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

OMAP3 core DVFS needs to be tested with this change.

> ---
>  arch/arm/mach-omap2/sram34xx.S |   28 ++++++++++++++++++++--------
>  1 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-
> omap2/sram34xx.S
> index 7f893a2..829d235 100644
> --- a/arch/arm/mach-omap2/sram34xx.S
> +++ b/arch/arm/mach-omap2/sram34xx.S
> @@ -116,24 +116,34 @@ ENTRY(omap3_sram_configure_core_dpll)
>
>  					@ pull the extra args off the
stack
>  					@  and store them in SRAM
> +
> +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a
> r7 as a
> +@ base instead.
> +@ Be careful not to clobber r7 when maintaing this file.
> + THUMB(	adr	r7, omap3_sram_configure_core_dpll
)
> +	.macro strtext Rt:req, label:req
> + ARM(	str	\Rt, \label
)
> + THUMB(	str	\Rt, [r7, \label - omap3_sram_configure_core_dpll]
> 	)
> +	.endm
> +
>  	ldr	r4, [sp, #52]
> -	str     r4, omap_sdrc_rfr_ctrl_0_val
> +	strtext	r4, omap_sdrc_rfr_ctrl_0_val
>  	ldr	r4, [sp, #56]
> -	str     r4, omap_sdrc_actim_ctrl_a_0_val
> +	strtext	r4, omap_sdrc_actim_ctrl_a_0_val
>  	ldr	r4, [sp, #60]
> -	str     r4, omap_sdrc_actim_ctrl_b_0_val
> +	strtext	r4, omap_sdrc_actim_ctrl_b_0_val
>  	ldr	r4, [sp, #64]
> -	str     r4, omap_sdrc_mr_0_val
> +	strtext	r4, omap_sdrc_mr_0_val
>  	ldr	r4, [sp, #68]
> -	str     r4, omap_sdrc_rfr_ctrl_1_val
> +	strtext	r4, omap_sdrc_rfr_ctrl_1_val
>  	cmp	r4, #0			@ if SDRC_RFR_CTRL_1 is 0,
>  	beq	skip_cs1_params		@  do not use cs1 params
>  	ldr	r4, [sp, #72]
> -	str     r4, omap_sdrc_actim_ctrl_a_1_val
> +	strtext	r4, omap_sdrc_actim_ctrl_a_1_val
>  	ldr	r4, [sp, #76]
> -	str     r4, omap_sdrc_actim_ctrl_b_1_val
> +	strtext	r4, omap_sdrc_actim_ctrl_b_1_val
>  	ldr	r4, [sp, #80]
> -	str     r4, omap_sdrc_mr_1_val
> +	strtext	r4, omap_sdrc_mr_1_val
>  skip_cs1_params:
>  	mrc	p15, 0, r8, c1, c0, 0	@ read ctrl register
>  	bic	r10, r8, #0x800		@ clear Z-bit, disable branch
> prediction
> @@ -271,6 +281,7 @@ skip_cs1_prog:
>  	ldr	r12, [r11]		@ posted-write barrier for SDRC
>  	bx	lr
>
> +	.align
>  omap3_sdrc_power:
>  	.word OMAP34XX_SDRC_REGADDR(SDRC_POWER)
>  omap3_cm_clksel1_pll:
> @@ -319,6 +330,7 @@ omap3_sdrc_dlla_ctrl:
>  	.word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
>  core_m2_mask_val:
>  	.word 0x07FFFFFF
> +ENDPROC(omap3_sram_configure_core_dpll)
>
>  ENTRY(omap3_sram_configure_core_dpll_sz)
>  	.word	. - omap3_sram_configure_core_dpll
> --
> 1.7.1

[PATCH v2 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 4/5] ARM: omap3: Thumb-2 compatibility for
> sram34xx.S
>
>  * Remove deprecated/undefined PC-relative stores
>  * Add the required ENDPROC() directive for each ENTRY().
>  * .align before data words
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

OMAP3 core DVFS needs to be tested with this change.

> ---
>  arch/arm/mach-omap2/sram34xx.S |   28 ++++++++++++++++++++--------
>  1 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-
> omap2/sram34xx.S
> index 7f893a2..829d235 100644
> --- a/arch/arm/mach-omap2/sram34xx.S
> +++ b/arch/arm/mach-omap2/sram34xx.S
> @@ -116,24 +116,34 @@ ENTRY(omap3_sram_configure_core_dpll)
>
>  					@ pull the extra args off the
stack
>  					@  and store them in SRAM
> +
> +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a
> r7 as a
> +@ base instead.
> +@ Be careful not to clobber r7 when maintaing this file.
> + THUMB(	adr	r7, omap3_sram_configure_core_dpll
)
> +	.macro strtext Rt:req, label:req
> + ARM(	str	\Rt, \label
)
> + THUMB(	str	\Rt, [r7, \label - omap3_sram_configure_core_dpll]
> 	)
> +	.endm
> +
>  	ldr	r4, [sp, #52]
> -	str     r4, omap_sdrc_rfr_ctrl_0_val
> +	strtext	r4, omap_sdrc_rfr_ctrl_0_val
>  	ldr	r4, [sp, #56]
> -	str     r4, omap_sdrc_actim_ctrl_a_0_val
> +	strtext	r4, omap_sdrc_actim_ctrl_a_0_val
>  	ldr	r4, [sp, #60]
> -	str     r4, omap_sdrc_actim_ctrl_b_0_val
> +	strtext	r4, omap_sdrc_actim_ctrl_b_0_val
>  	ldr	r4, [sp, #64]
> -	str     r4, omap_sdrc_mr_0_val
> +	strtext	r4, omap_sdrc_mr_0_val
>  	ldr	r4, [sp, #68]
> -	str     r4, omap_sdrc_rfr_ctrl_1_val
> +	strtext	r4, omap_sdrc_rfr_ctrl_1_val
>  	cmp	r4, #0			@ if SDRC_RFR_CTRL_1 is 0,
>  	beq	skip_cs1_params		@  do not use cs1 params
>  	ldr	r4, [sp, #72]
> -	str     r4, omap_sdrc_actim_ctrl_a_1_val
> +	strtext	r4, omap_sdrc_actim_ctrl_a_1_val
>  	ldr	r4, [sp, #76]
> -	str     r4, omap_sdrc_actim_ctrl_b_1_val
> +	strtext	r4, omap_sdrc_actim_ctrl_b_1_val
>  	ldr	r4, [sp, #80]
> -	str     r4, omap_sdrc_mr_1_val
> +	strtext	r4, omap_sdrc_mr_1_val
>  skip_cs1_params:
>  	mrc	p15, 0, r8, c1, c0, 0	@ read ctrl register
>  	bic	r10, r8, #0x800		@ clear Z-bit, disable branch
> prediction
> @@ -271,6 +281,7 @@ skip_cs1_prog:
>  	ldr	r12, [r11]		@ posted-write barrier for SDRC
>  	bx	lr
>
> +	.align
>  omap3_sdrc_power:
>  	.word OMAP34XX_SDRC_REGADDR(SDRC_POWER)
>  omap3_cm_clksel1_pll:
> @@ -319,6 +330,7 @@ omap3_sdrc_dlla_ctrl:
>  	.word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
>  core_m2_mask_val:
>  	.word 0x07FFFFFF
> +ENDPROC(omap3_sram_configure_core_dpll)
>
>  ENTRY(omap3_sram_configure_core_dpll_sz)
>  	.word	. - omap3_sram_configure_core_dpll
> --
> 1.7.1

RE: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for
> sleep34xx.S
>
>  * Use BSYM() to get the correct Thumb branch address
>    for adr <Rd>, <label>
>
>  * Fix an out-of-range ADR when building for ARM
>
>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>
>  * Remove deprecated/undefined PC-relative stores
>
>  * Add the required ENDPROC() directive for each ENTRY().
>
>  * .align before data words
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

Change looks ok to me. Will test OFF mode with this tomorrow
but looking at the change it should work.
Will ack this patch after testing the same.

> ---
>  arch/arm/mach-omap2/sleep34xx.S |   42
> +++++++++++++++++++++++++++++---------
>  1 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
> omap2/sleep34xx.S
> index 4032a8e..ef73429 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -80,8 +80,10 @@
>  /* Function call to get the restore pointer for resume from OFF */
>  ENTRY(get_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore
> +	adr	r0, BSYM(restore)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_restore_pointer)
> +	.align
>  ENTRY(get_restore_pointer_sz)
>  	.word	. - get_restore_pointer
>
> @@ -89,8 +91,10 @@ ENTRY(get_restore_pointer_sz)
>  /* Function call to get the restore pointer for 3630 resume from
> OFF */
>  ENTRY(get_omap3630_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_3630
> +	adr	r0, BSYM(restore_3630)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_omap3630_restore_pointer)
> +	.align
>  ENTRY(get_omap3630_restore_pointer_sz)
>  	.word	. - get_omap3630_restore_pointer
>
> @@ -98,8 +102,10 @@ ENTRY(get_omap3630_restore_pointer_sz)
>  /* Function call to get the restore pointer for ES3 to resume from
> OFF */
>  ENTRY(get_es3_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_es3
> +	adr	r0, BSYM(restore_es3)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_es3_restore_pointer)
> +	.align
>  ENTRY(get_es3_restore_pointer_sz)
>  	.word	. - get_es3_restore_pointer
>
> @@ -113,8 +119,11 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
>  	stmfd	sp!, {lr}	@ save registers on stack
>  	/* Setup so that we will disable and enable l2 */
>  	mov	r1, #0x1
> -	str	r1, l2dis_3630
> + ARM(	adrl	r2, l2dis_3630	)	@ may be out of range for
> adr in ARM
> + THUMB(	adr	r2, l2dis_3630	)	@ Thumb has more range,
> but not adrl
> +	str	r1, [r2]
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(enable_omap3630_toggle_l2_on_restore)
>
>  	.text
>  /* Function to call rom code to save secure ram context */
> @@ -139,12 +148,14 @@ ENTRY(save_secure_ram_context)
>  	nop
>  	nop
>  	ldmfd	sp!, {r1-r12, pc}
> +	.align
>  sram_phy_addr_mask:
>  	.word	SRAM_BASE_P
>  high_mask:
>  	.word	0xffff
>  api_params:
>  	.word	0x4, 0x0, 0x0, 0x1, 0x1
> +ENDPROC(save_secure_ram_context)
>  ENTRY(save_secure_ram_context_sz)
>  	.word	. - save_secure_ram_context
>
> @@ -279,8 +290,7 @@ clean_l2:
>  	 *  - 'might' have to copy address, load and jump to it
>  	 */
>  	ldr	r1, kernel_flush
> -	mov	lr, pc
> -	bx	r1
> +	blx	r1
>
>  omap3_do_wfi:
>  	ldr	r4, sdrc_power		@ read the SDRC_POWER register
> @@ -346,8 +356,8 @@ restore_es3:
>  	and	r4, r4, #0x3
>  	cmp	r4, #0x0	@ Check if previous power state of CORE is
> OFF
>  	bne	restore
> -	adr	r0, es3_sdrc_fix
> -	ldr	r1, sram_base
> +	adr	r0, es3_sdrc_fix	@ Not using BSYM clears the Thumb
bit.
> +	ldr	r1, sram_base	@ Must be 8-byte aligned to preserve
> alignment.
>  	ldr	r2, es3_sdrc_fix_sz
>  	mov	r2, r2, ror #2
>  copy_to_sram:
> @@ -356,6 +366,7 @@ copy_to_sram:
>  	subs	r2, r2, #0x1	@ num_words--
>  	bne	copy_to_sram
>  	ldr	r1, sram_base
> + THUMB(	orr	r1, r1, #BSYM(es3_sdrc_fix) & 1 )
>  	blx	r1
>  	b	restore
>
> @@ -438,6 +449,7 @@ skipl2dis:
>  #endif
>  	b	logic_l1_restore
>
> +	.align
>  l2_inv_api_params:
>  	.word	0x1, 0x00
>  l2_inv_gp:
> @@ -607,6 +619,7 @@ usettbr0:
>
>  /* This function implements the erratum ID i443 WA, applies to 34xx
> >= ES3.0 */
>  	.text
> +	.align	3
>  ENTRY(es3_sdrc_fix)
>  	ldr	r4, sdrc_syscfg		@ get config addr
>  	ldr	r5, [r4]		@ get value
> @@ -634,6 +647,7 @@ ENTRY(es3_sdrc_fix)
>  	str	r5, [r4]		@ kick off refreshes
>  	bx	lr
>
> +	.align
>  sdrc_syscfg:
>  	.word	SDRC_SYSCONFIG_P
>  sdrc_mr_0:
> @@ -648,6 +662,7 @@ sdrc_emr2_1:
>  	.word	SDRC_EMR2_1_P
>  sdrc_manual_1:
>  	.word	SDRC_MANUAL_1_P
> +ENDPROC(es3_sdrc_fix)
>  ENTRY(es3_sdrc_fix_sz)
>  	.word	. - es3_sdrc_fix
>
> @@ -682,6 +697,10 @@ wait_sdrc_ready:
>  	bic	r5, r5, #0x40
>  	str	r5, [r4]
>
> +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a
> r7 as a
> +@ base instead.
> +@ Be careful not to clobber r7 when maintaing this code.
> +
>  is_dll_in_lock_mode:
>  	/* Is dll in lock mode? */
>  	ldr	r4, sdrc_dlla_ctrl
> @@ -689,10 +708,11 @@ is_dll_in_lock_mode:
>  	tst	r5, #0x4
>  	bxne	lr			@ Return if locked
>  	/* wait till dll locks */
> +	adr	r7, kick_counter
>  wait_dll_lock_timed:
>  	ldr	r4, wait_dll_lock_counter
>  	add	r4, r4, #1
> -	str	r4, wait_dll_lock_counter
> +	str	r4, [r7, #wait_dll_lock_counter - kick_counter]
>  	ldr	r4, sdrc_dlla_status
>  	/* Wait 20uS for lock */
>  	mov	r6, #8
> @@ -718,9 +738,10 @@ kick_dll:
>  	dsb
>  	ldr	r4, kick_counter
>  	add	r4, r4, #1
> -	str	r4, kick_counter
> +	str	r4, [r7]		@ kick_counter
>  	b	wait_dll_lock_timed
>
> +	.align
>  cm_idlest1_core:
>  	.word	CM_IDLEST1_CORE_V
>  cm_idlest_ckgen:
> @@ -763,6 +784,7 @@ kick_counter:
>  	.word	0
>  wait_dll_lock_counter:
>  	.word	0
> +ENDPROC(omap34xx_cpu_suspend)
>
>  ENTRY(omap34xx_cpu_suspend_sz)
>  	.word	. - omap34xx_cpu_suspend
> --
> 1.7.1

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for
> sleep34xx.S
>
>  * Use BSYM() to get the correct Thumb branch address
>    for adr <Rd>, <label>
>
>  * Fix an out-of-range ADR when building for ARM
>
>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>
>  * Remove deprecated/undefined PC-relative stores
>
>  * Add the required ENDPROC() directive for each ENTRY().
>
>  * .align before data words
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

Change looks ok to me. Will test OFF mode with this tomorrow
but looking at the change it should work.
Will ack this patch after testing the same.

> ---
>  arch/arm/mach-omap2/sleep34xx.S |   42
> +++++++++++++++++++++++++++++---------
>  1 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
> omap2/sleep34xx.S
> index 4032a8e..ef73429 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -80,8 +80,10 @@
>  /* Function call to get the restore pointer for resume from OFF */
>  ENTRY(get_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore
> +	adr	r0, BSYM(restore)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_restore_pointer)
> +	.align
>  ENTRY(get_restore_pointer_sz)
>  	.word	. - get_restore_pointer
>
> @@ -89,8 +91,10 @@ ENTRY(get_restore_pointer_sz)
>  /* Function call to get the restore pointer for 3630 resume from
> OFF */
>  ENTRY(get_omap3630_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_3630
> +	adr	r0, BSYM(restore_3630)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_omap3630_restore_pointer)
> +	.align
>  ENTRY(get_omap3630_restore_pointer_sz)
>  	.word	. - get_omap3630_restore_pointer
>
> @@ -98,8 +102,10 @@ ENTRY(get_omap3630_restore_pointer_sz)
>  /* Function call to get the restore pointer for ES3 to resume from
> OFF */
>  ENTRY(get_es3_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_es3
> +	adr	r0, BSYM(restore_es3)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_es3_restore_pointer)
> +	.align
>  ENTRY(get_es3_restore_pointer_sz)
>  	.word	. - get_es3_restore_pointer
>
> @@ -113,8 +119,11 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
>  	stmfd	sp!, {lr}	@ save registers on stack
>  	/* Setup so that we will disable and enable l2 */
>  	mov	r1, #0x1
> -	str	r1, l2dis_3630
> + ARM(	adrl	r2, l2dis_3630	)	@ may be out of range for
> adr in ARM
> + THUMB(	adr	r2, l2dis_3630	)	@ Thumb has more range,
> but not adrl
> +	str	r1, [r2]
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(enable_omap3630_toggle_l2_on_restore)
>
>  	.text
>  /* Function to call rom code to save secure ram context */
> @@ -139,12 +148,14 @@ ENTRY(save_secure_ram_context)
>  	nop
>  	nop
>  	ldmfd	sp!, {r1-r12, pc}
> +	.align
>  sram_phy_addr_mask:
>  	.word	SRAM_BASE_P
>  high_mask:
>  	.word	0xffff
>  api_params:
>  	.word	0x4, 0x0, 0x0, 0x1, 0x1
> +ENDPROC(save_secure_ram_context)
>  ENTRY(save_secure_ram_context_sz)
>  	.word	. - save_secure_ram_context
>
> @@ -279,8 +290,7 @@ clean_l2:
>  	 *  - 'might' have to copy address, load and jump to it
>  	 */
>  	ldr	r1, kernel_flush
> -	mov	lr, pc
> -	bx	r1
> +	blx	r1
>
>  omap3_do_wfi:
>  	ldr	r4, sdrc_power		@ read the SDRC_POWER register
> @@ -346,8 +356,8 @@ restore_es3:
>  	and	r4, r4, #0x3
>  	cmp	r4, #0x0	@ Check if previous power state of CORE is
> OFF
>  	bne	restore
> -	adr	r0, es3_sdrc_fix
> -	ldr	r1, sram_base
> +	adr	r0, es3_sdrc_fix	@ Not using BSYM clears the Thumb
bit.
> +	ldr	r1, sram_base	@ Must be 8-byte aligned to preserve
> alignment.
>  	ldr	r2, es3_sdrc_fix_sz
>  	mov	r2, r2, ror #2
>  copy_to_sram:
> @@ -356,6 +366,7 @@ copy_to_sram:
>  	subs	r2, r2, #0x1	@ num_words--
>  	bne	copy_to_sram
>  	ldr	r1, sram_base
> + THUMB(	orr	r1, r1, #BSYM(es3_sdrc_fix) & 1 )
>  	blx	r1
>  	b	restore
>
> @@ -438,6 +449,7 @@ skipl2dis:
>  #endif
>  	b	logic_l1_restore
>
> +	.align
>  l2_inv_api_params:
>  	.word	0x1, 0x00
>  l2_inv_gp:
> @@ -607,6 +619,7 @@ usettbr0:
>
>  /* This function implements the erratum ID i443 WA, applies to 34xx
> >= ES3.0 */
>  	.text
> +	.align	3
>  ENTRY(es3_sdrc_fix)
>  	ldr	r4, sdrc_syscfg		@ get config addr
>  	ldr	r5, [r4]		@ get value
> @@ -634,6 +647,7 @@ ENTRY(es3_sdrc_fix)
>  	str	r5, [r4]		@ kick off refreshes
>  	bx	lr
>
> +	.align
>  sdrc_syscfg:
>  	.word	SDRC_SYSCONFIG_P
>  sdrc_mr_0:
> @@ -648,6 +662,7 @@ sdrc_emr2_1:
>  	.word	SDRC_EMR2_1_P
>  sdrc_manual_1:
>  	.word	SDRC_MANUAL_1_P
> +ENDPROC(es3_sdrc_fix)
>  ENTRY(es3_sdrc_fix_sz)
>  	.word	. - es3_sdrc_fix
>
> @@ -682,6 +697,10 @@ wait_sdrc_ready:
>  	bic	r5, r5, #0x40
>  	str	r5, [r4]
>
> +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a
> r7 as a
> +@ base instead.
> +@ Be careful not to clobber r7 when maintaing this code.
> +
>  is_dll_in_lock_mode:
>  	/* Is dll in lock mode? */
>  	ldr	r4, sdrc_dlla_ctrl
> @@ -689,10 +708,11 @@ is_dll_in_lock_mode:
>  	tst	r5, #0x4
>  	bxne	lr			@ Return if locked
>  	/* wait till dll locks */
> +	adr	r7, kick_counter
>  wait_dll_lock_timed:
>  	ldr	r4, wait_dll_lock_counter
>  	add	r4, r4, #1
> -	str	r4, wait_dll_lock_counter
> +	str	r4, [r7, #wait_dll_lock_counter - kick_counter]
>  	ldr	r4, sdrc_dlla_status
>  	/* Wait 20uS for lock */
>  	mov	r6, #8
> @@ -718,9 +738,10 @@ kick_dll:
>  	dsb
>  	ldr	r4, kick_counter
>  	add	r4, r4, #1
> -	str	r4, kick_counter
> +	str	r4, [r7]		@ kick_counter
>  	b	wait_dll_lock_timed
>
> +	.align
>  cm_idlest1_core:
>  	.word	CM_IDLEST1_CORE_V
>  cm_idlest_ckgen:
> @@ -763,6 +784,7 @@ kick_counter:
>  	.word	0
>  wait_dll_lock_counter:
>  	.word	0
> +ENDPROC(omap34xx_cpu_suspend)
>
>  ENTRY(omap34xx_cpu_suspend_sz)
>  	.word	. - omap34xx_cpu_suspend
> --
> 1.7.1

Re: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Russell King - ARM Linux]

On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Dave Martin [mailto:dave.martin@linaro.org]
> > Sent: Thursday, February 03, 2011 11:33 PM
> > To: linux-arm-kernel@lists.infradead.org
> > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> > linux-omap@vger.kernel.org; Nicolas Pitre
> > Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi()
> > for CONFIG_THUMB2_KERNEL
> >
> > For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> > case the tools will necessarily be new enough to support it.
> >
> > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> 
> I guess, we discussed this patch in your previous post.
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 
> > ---
> >  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
> >  1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > index 5b0270b..68ce058 100644
> > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > @@ -17,8 +17,13 @@
> >   * wfi used in low power code. Directly opcode is used instead
> >   * of instruction to avoid mulit-omap build break
> >   */
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define do_wfi()			\
> > +		__asm__ __volatile__ ("wfi" : : : "memory")
> > +#else
> >  #define do_wfi()			\
> >  		__asm__ __volatile__ (".word	0xe320f003" : : :
> > "memory")
> > +#endif

We actually have this:

#if __LINUX_ARM_ARCH__ >= 7 ||          \
        (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
#define sev()   __asm__ __volatile__ ("sev" : : : "memory")
#define wfe()   __asm__ __volatile__ ("wfe" : : : "memory")
#define wfi()   __asm__ __volatile__ ("wfi" : : : "memory")
#endif

in asm/system.h, so maybe it should be using wfe() from asm/system.h ?

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() for CONFIG_THUMB2_KERNEL

[Russell King - ARM Linux]

On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Dave Martin [mailto:dave.martin at linaro.org]
> > Sent: Thursday, February 03, 2011 11:33 PM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> > linux-omap at vger.kernel.org; Nicolas Pitre
> > Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi()
> > for CONFIG_THUMB2_KERNEL
> >
> > For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> > case the tools will necessarily be new enough to support it.
> >
> > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> 
> I guess, we discussed this patch in your previous post.
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 
> > ---
> >  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
> >  1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > index 5b0270b..68ce058 100644
> > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > @@ -17,8 +17,13 @@
> >   * wfi used in low power code. Directly opcode is used instead
> >   * of instruction to avoid mulit-omap build break
> >   */
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define do_wfi()			\
> > +		__asm__ __volatile__ ("wfi" : : : "memory")
> > +#else
> >  #define do_wfi()			\
> >  		__asm__ __volatile__ (".word	0xe320f003" : : :
> > "memory")
> > +#endif

We actually have this:

#if __LINUX_ARM_ARCH__ >= 7 ||          \
        (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
#define sev()   __asm__ __volatile__ ("sev" : : : "memory")
#define wfe()   __asm__ __volatile__ ("wfe" : : : "memory")
#define wfi()   __asm__ __volatile__ ("wfi" : : : "memory")
#endif

in asm/system.h, so maybe it should be using wfe() from asm/system.h ?

RE: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Friday, February 04, 2011 12:38 AM
> To: Santosh Shilimkar
> Cc: Dave Martin; linux-arm-kernel@lists.infradead.org; Tony
> Lindgren; Nicolas Pitre; linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: Re: [PATCH v2 1/5] ARM: omap4: Correct definition of
> do_wfi() forCONFIG_THUMB2_KERNEL
>
> On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Dave Martin [mailto:dave.martin@linaro.org]
> > > Sent: Thursday, February 03, 2011 11:33 PM
> > > To: linux-arm-kernel@lists.infradead.org
> > > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> > > linux-omap@vger.kernel.org; Nicolas Pitre
> > > Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of
> do_wfi()
> > > for CONFIG_THUMB2_KERNEL
> > >
> > > For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> > > case the tools will necessarily be new enough to support it.
> > >
> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> >
> > I guess, we discussed this patch in your previous post.
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >
> > > ---
> > >  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
> > >  1 files changed, 5 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > index 5b0270b..68ce058 100644
> > > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > @@ -17,8 +17,13 @@
> > >   * wfi used in low power code. Directly opcode is used instead
> > >   * of instruction to avoid mulit-omap build break
> > >   */
> > > +#ifdef CONFIG_THUMB2_KERNEL
> > > +#define do_wfi()			\
> > > +		__asm__ __volatile__ ("wfi" : : : "memory")
> > > +#else
> > >  #define do_wfi()			\
> > >  		__asm__ __volatile__ (".word	0xe320f003" : : :
> > > "memory")
> > > +#endif
>
> We actually have this:
>
> #if __LINUX_ARM_ARCH__ >= 7 ||          \
>         (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
> #define sev()   __asm__ __volatile__ ("sev" : : : "memory")
> #define wfe()   __asm__ __volatile__ ("wfe" : : : "memory")
> #define wfi()   __asm__ __volatile__ ("wfi" : : : "memory")
> #endif
>
> in asm/system.h, so maybe it should be using wfe() from asm/system.h
> ?
I assume you mean wfi here.
The problem is, omap2plus build breaks because it builds
CPU_32v6 and CPU_32v7 as well which doesn't support the wfi
instruction. Hence I used opcode directly to keep build
working.

Regards,
Santosh

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Friday, February 04, 2011 12:38 AM
> To: Santosh Shilimkar
> Cc: Dave Martin; linux-arm-kernel at lists.infradead.org; Tony
> Lindgren; Nicolas Pitre; linux-omap at vger.kernel.org; Jean Pihet-XID
> Subject: Re: [PATCH v2 1/5] ARM: omap4: Correct definition of
> do_wfi() forCONFIG_THUMB2_KERNEL
>
> On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Dave Martin [mailto:dave.martin at linaro.org]
> > > Sent: Thursday, February 03, 2011 11:33 PM
> > > To: linux-arm-kernel at lists.infradead.org
> > > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> > > linux-omap at vger.kernel.org; Nicolas Pitre
> > > Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of
> do_wfi()
> > > for CONFIG_THUMB2_KERNEL
> > >
> > > For the Thumb-2 case, the "wfi" mnemonic is used, since in this
> > > case the tools will necessarily be new enough to support it.
> > >
> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> >
> > I guess, we discussed this patch in your previous post.
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >
> > > ---
> > >  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
> > >  1 files changed, 5 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > index 5b0270b..68ce058 100644
> > > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> > > @@ -17,8 +17,13 @@
> > >   * wfi used in low power code. Directly opcode is used instead
> > >   * of instruction to avoid mulit-omap build break
> > >   */
> > > +#ifdef CONFIG_THUMB2_KERNEL
> > > +#define do_wfi()			\
> > > +		__asm__ __volatile__ ("wfi" : : : "memory")
> > > +#else
> > >  #define do_wfi()			\
> > >  		__asm__ __volatile__ (".word	0xe320f003" : : :
> > > "memory")
> > > +#endif
>
> We actually have this:
>
> #if __LINUX_ARM_ARCH__ >= 7 ||          \
>         (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
> #define sev()   __asm__ __volatile__ ("sev" : : : "memory")
> #define wfe()   __asm__ __volatile__ ("wfe" : : : "memory")
> #define wfi()   __asm__ __volatile__ ("wfi" : : : "memory")
> #endif
>
> in asm/system.h, so maybe it should be using wfe() from asm/system.h
> ?
I assume you mean wfi here.
The problem is, omap2plus build breaks because it builds
CPU_32v6 and CPU_32v7 as well which doesn't support the wfi
instruction. Hence I used opcode directly to keep build
working.

Regards,
Santosh

RE: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Santosh Shilimkar]

Dave,
> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
>
> This set of patches, along with some other patches under
> discussion on alkml, should enable omap3 and omap4 kernels to be
> built with CONFIG_THUMB2_KERNEL.
>
> This patch set builds on recent cleanup done by the omap
> maintainers.
>
> It is also more aggressive than my last post: all affected
> low-level code is now built in Thumb-2.  At least some of this
> code definitely works, but whether the Secure firmware can talk
> to Thumb-2 code properly is unproven:
> in particular, I could use some help/advice from the omap
> community for validating that the low-level power management
> interactions actually work with this patch set.
>
> I've done simple "does it boot?" testing by building a single
> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
> which works on Beagle xM A2 and Panda A1.

I have boot tested this series on OMAP3430 and OMAP4430. Also
tested the RETENTION and OFF mode in suspend on OMAP3.
I couldn't test the DVFS because it isn't in mainline yet
but the changes doesn't looks to break anything.

So if you like, you can add
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

>
> The patches can be found, along with a buildable working tree,
> in the following repo:
>
> git://git.linaro.org/people/dmart/linux-2.6-arm.git
>
>  * arm/omap-thumb2: has the patches proposed here
>  * arm/omap-thumb2+merged: additionally has some patches cherry-
>         picked from other trees which are needed in order for the
>         patches on arm/omap-thumb2 to work usefully.
>  * dirty/arm/omap-thumb2+merged: buildable test tree, which adds
>         2 local patches to work around a toolchain bug.
>
> A working kernel config for this tree is here:
> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config :
>
>   CONFIG_SMP_ON_UP=y
>   CONFIG_THUMB2_KERNEL=y
>   CONFIG_SERIAL_OMAP=n (to avoid garbage on xM; for Panda use
> console=ttyS2)
>
> (The config is derived from the linaro omap config and so turns on
> loads of modules -- don't feel you have to build them all...)
>
>
> Cherry-picked patches originated from Russell's devel tree
> and Tony Lindgren's omap-testing tree:
>
> http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-
> arm.git devel
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-
> 2.6.git omap-testing
>
>
> Dave Martin (5):
>   ARM: omap4: Correct definition of do_wfi() for
> CONFIG_THUMB2_KERNEL
>   ARM: omap4: Convert END() to ENDPROC() for correct linkage with
>     CONFIG_THUMB2_KERNEL
>   ARM: omap3: Remove hand-encoded SMC instructions
>   ARM: omap3: Thumb-2 compatibility for sram34xx.S
>   ARM: omap3: Thumb-2 compatibility for sleep34xx.S
>
>  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 ++
>  arch/arm/mach-omap2/omap-headsmp.S              |    2 +-
>  arch/arm/mach-omap2/omap44xx-smc.S              |    8 ++--
>  arch/arm/mach-omap2/sleep34xx.S                 |   56
> ++++++++++++++++-------
>  arch/arm/mach-omap2/sram34xx.S                  |   28 ++++++++---
>  5 files changed, 69 insertions(+), 30 deletions(-)

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Santosh Shilimkar]

Dave,
> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Thursday, February 03, 2011 11:33 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
>
> This set of patches, along with some other patches under
> discussion on alkml, should enable omap3 and omap4 kernels to be
> built with CONFIG_THUMB2_KERNEL.
>
> This patch set builds on recent cleanup done by the omap
> maintainers.
>
> It is also more aggressive than my last post: all affected
> low-level code is now built in Thumb-2.  At least some of this
> code definitely works, but whether the Secure firmware can talk
> to Thumb-2 code properly is unproven:
> in particular, I could use some help/advice from the omap
> community for validating that the low-level power management
> interactions actually work with this patch set.
>
> I've done simple "does it boot?" testing by building a single
> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
> which works on Beagle xM A2 and Panda A1.

I have boot tested this series on OMAP3430 and OMAP4430. Also
tested the RETENTION and OFF mode in suspend on OMAP3.
I couldn't test the DVFS because it isn't in mainline yet
but the changes doesn't looks to break anything.

So if you like, you can add
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

>
> The patches can be found, along with a buildable working tree,
> in the following repo:
>
> git://git.linaro.org/people/dmart/linux-2.6-arm.git
>
>  * arm/omap-thumb2: has the patches proposed here
>  * arm/omap-thumb2+merged: additionally has some patches cherry-
>         picked from other trees which are needed in order for the
>         patches on arm/omap-thumb2 to work usefully.
>  * dirty/arm/omap-thumb2+merged: buildable test tree, which adds
>         2 local patches to work around a toolchain bug.
>
> A working kernel config for this tree is here:
> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config :
>
>   CONFIG_SMP_ON_UP=y
>   CONFIG_THUMB2_KERNEL=y
>   CONFIG_SERIAL_OMAP=n (to avoid garbage on xM; for Panda use
> console=ttyS2)
>
> (The config is derived from the linaro omap config and so turns on
> loads of modules -- don't feel you have to build them all...)
>
>
> Cherry-picked patches originated from Russell's devel tree
> and Tony Lindgren's omap-testing tree:
>
> http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-
> arm.git devel
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-
> 2.6.git omap-testing
>
>
> Dave Martin (5):
>   ARM: omap4: Correct definition of do_wfi() for
> CONFIG_THUMB2_KERNEL
>   ARM: omap4: Convert END() to ENDPROC() for correct linkage with
>     CONFIG_THUMB2_KERNEL
>   ARM: omap3: Remove hand-encoded SMC instructions
>   ARM: omap3: Thumb-2 compatibility for sram34xx.S
>   ARM: omap3: Thumb-2 compatibility for sleep34xx.S
>
>  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 ++
>  arch/arm/mach-omap2/omap-headsmp.S              |    2 +-
>  arch/arm/mach-omap2/omap44xx-smc.S              |    8 ++--
>  arch/arm/mach-omap2/sleep34xx.S                 |   56
> ++++++++++++++++-------
>  arch/arm/mach-omap2/sram34xx.S                  |   28 ++++++++---
>  5 files changed, 69 insertions(+), 30 deletions(-)

Re: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Dave Martin]

On Thu, Feb 3, 2011 at 7:30 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
>> Sent: Friday, February 04, 2011 12:38 AM
>> To: Santosh Shilimkar
>> Cc: Dave Martin; linux-arm-kernel@lists.infradead.org; Tony
>> Lindgren; Nicolas Pitre; linux-omap@vger.kernel.org; Jean Pihet-XID
>> Subject: Re: [PATCH v2 1/5] ARM: omap4: Correct definition of
>> do_wfi() forCONFIG_THUMB2_KERNEL
>>
>> On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
>> > > -----Original Message-----
>> > > From: Dave Martin [mailto:dave.martin@linaro.org]
>> > > Sent: Thursday, February 03, 2011 11:33 PM
>> > > To: linux-arm-kernel@lists.infradead.org
>> > > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
>> > > linux-omap@vger.kernel.org; Nicolas Pitre
>> > > Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of
>> do_wfi()
>> > > for CONFIG_THUMB2_KERNEL
>> > >
>> > > For the Thumb-2 case, the "wfi" mnemonic is used, since in this
>> > > case the tools will necessarily be new enough to support it.
>> > >
>> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
>> >
>> > I guess, we discussed this patch in your previous post.
>> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >
>> > > ---
>> > >  arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++++
>> > >  1 files changed, 5 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > b/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > index 5b0270b..68ce058 100644
>> > > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > @@ -17,8 +17,13 @@
>> > >   * wfi used in low power code. Directly opcode is used instead
>> > >   * of instruction to avoid mulit-omap build break
>> > >   */
>> > > +#ifdef CONFIG_THUMB2_KERNEL
>> > > +#define do_wfi()                 \
>> > > +         __asm__ __volatile__ ("wfi" : : : "memory")
>> > > +#else
>> > >  #define do_wfi()                 \
>> > >           __asm__ __volatile__ (".word    0xe320f003" : : :
>> > > "memory")
>> > > +#endif
>>
>> We actually have this:
>>
>> #if __LINUX_ARM_ARCH__ >= 7 ||          \
>>         (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
>> #define sev()   __asm__ __volatile__ ("sev" : : : "memory")
>> #define wfe()   __asm__ __volatile__ ("wfe" : : : "memory")
>> #define wfi()   __asm__ __volatile__ ("wfi" : : : "memory")
>> #endif
>>
>> in asm/system.h, so maybe it should be using wfe() from asm/system.h
>> ?
> I assume you mean wfi here.
> The problem is, omap2plus build breaks because it builds
> CPU_32v6 and CPU_32v7 as well which doesn't support the wfi
> instruction. Hence I used opcode directly to keep build
> working.

I guess that's right, OMAP2 is ARM1136 and doesn't have the K extensions.

Would it make sense to have the v6 MCR equivalent as an altetnative?
Something like:

#elseif __LINUX_ARM_ARCH__ >= 6
#define wfi()   __asm__ __volatile__ ( \
    "mov     r0, #0\n\t" \
    "mcr     p15, 0, r0, c7, c0, 4\n\t" \
    ::: "r0"
)
#endif

This MCR is a mandatory part of the architecture for v6, but it's not
mandatory for older processors.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Dave Martin]

On Thu, Feb 3, 2011 at 7:30 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>> Sent: Friday, February 04, 2011 12:38 AM
>> To: Santosh Shilimkar
>> Cc: Dave Martin; linux-arm-kernel at lists.infradead.org; Tony
>> Lindgren; Nicolas Pitre; linux-omap at vger.kernel.org; Jean Pihet-XID
>> Subject: Re: [PATCH v2 1/5] ARM: omap4: Correct definition of
>> do_wfi() forCONFIG_THUMB2_KERNEL
>>
>> On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
>> > > -----Original Message-----
>> > > From: Dave Martin [mailto:dave.martin at linaro.org]
>> > > Sent: Thursday, February 03, 2011 11:33 PM
>> > > To: linux-arm-kernel at lists.infradead.org
>> > > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
>> > > linux-omap at vger.kernel.org; Nicolas Pitre
>> > > Subject: [PATCH v2 1/5] ARM: omap4: Correct definition of
>> do_wfi()
>> > > for CONFIG_THUMB2_KERNEL
>> > >
>> > > For the Thumb-2 case, the "wfi" mnemonic is used, since in this
>> > > case the tools will necessarily be new enough to support it.
>> > >
>> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
>> >
>> > I guess, we discussed this patch in your previous post.
>> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >
>> > > ---
>> > > ?arch/arm/mach-omap2/include/mach/omap4-common.h | ? ?5 +++++
>> > > ?1 files changed, 5 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > b/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > index 5b0270b..68ce058 100644
>> > > --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
>> > > @@ -17,8 +17,13 @@
>> > > ? * wfi used in low power code. Directly opcode is used instead
>> > > ? * of instruction to avoid mulit-omap build break
>> > > ? */
>> > > +#ifdef CONFIG_THUMB2_KERNEL
>> > > +#define do_wfi() ? ? ? ? ? ? ? ? \
>> > > + ? ? ? ? __asm__ __volatile__ ("wfi" : : : "memory")
>> > > +#else
>> > > ?#define do_wfi() ? ? ? ? ? ? ? ? \
>> > > ? ? ? ? ? __asm__ __volatile__ (".word ? ?0xe320f003" : : :
>> > > "memory")
>> > > +#endif
>>
>> We actually have this:
>>
>> #if __LINUX_ARM_ARCH__ >= 7 || ? ? ? ? ?\
>> ? ? ? ? (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
>> #define sev() ? __asm__ __volatile__ ("sev" : : : "memory")
>> #define wfe() ? __asm__ __volatile__ ("wfe" : : : "memory")
>> #define wfi() ? __asm__ __volatile__ ("wfi" : : : "memory")
>> #endif
>>
>> in asm/system.h, so maybe it should be using wfe() from asm/system.h
>> ?
> I assume you mean wfi here.
> The problem is, omap2plus build breaks because it builds
> CPU_32v6 and CPU_32v7 as well which doesn't support the wfi
> instruction. Hence I used opcode directly to keep build
> working.

I guess that's right, OMAP2 is ARM1136 and doesn't have the K extensions.

Would it make sense to have the v6 MCR equivalent as an altetnative?
Something like:

#elseif __LINUX_ARM_ARCH__ >= 6
#define wfi()   __asm__ __volatile__ ( \
    "mov     r0, #0\n\t" \
    "mcr     p15, 0, r0, c7, c0, 4\n\t" \
    ::: "r0"
)
#endif

This MCR is a mandatory part of the architecture for v6, but it's not
mandatory for older processors.

Cheers
---Dave

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Dave,
>> -----Original Message-----
>> From: Dave Martin [mailto:dave.martin@linaro.org]
>> Sent: Thursday, February 03, 2011 11:33 PM
>> To: linux-arm-kernel@lists.infradead.org
>> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
>> linux-omap@vger.kernel.org; Nicolas Pitre
>> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
>>
>> This set of patches, along with some other patches under
>> discussion on alkml, should enable omap3 and omap4 kernels to be
>> built with CONFIG_THUMB2_KERNEL.
>>
>> This patch set builds on recent cleanup done by the omap
>> maintainers.
>>
>> It is also more aggressive than my last post: all affected
>> low-level code is now built in Thumb-2.  At least some of this
>> code definitely works, but whether the Secure firmware can talk
>> to Thumb-2 code properly is unproven:
>> in particular, I could use some help/advice from the omap
>> community for validating that the low-level power management
>> interactions actually work with this patch set.
>>
>> I've done simple "does it boot?" testing by building a single
>> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
>> which works on Beagle xM A2 and Panda A1.
>
> I have boot tested this series on OMAP3430 and OMAP4430. Also
> tested the RETENTION and OFF mode in suspend on OMAP3.

Which tree did you use to test this?  It didn't seem to work for me --
sometimes the system wouldn't suspend, complaining about USB suspend
errors; and other times I couldn't bring it out of suspend (by poking
a USB input device).

I might be doing something wrong...

> I couldn't test the DVFS because it isn't in mainline yet
> but the changes doesn't looks to break anything.
>
> So if you like, you can add
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>

Thanks, that's great.

If there some other tree with DVFS working which I could try?  Even if
these patches don't apply, I may be able to test whether the changes
should work.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Dave,
>> -----Original Message-----
>> From: Dave Martin [mailto:dave.martin at linaro.org]
>> Sent: Thursday, February 03, 2011 11:33 PM
>> To: linux-arm-kernel at lists.infradead.org
>> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
>> linux-omap at vger.kernel.org; Nicolas Pitre
>> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
>>
>> This set of patches, along with some other patches under
>> discussion on alkml, should enable omap3 and omap4 kernels to be
>> built with CONFIG_THUMB2_KERNEL.
>>
>> This patch set builds on recent cleanup done by the omap
>> maintainers.
>>
>> It is also more aggressive than my last post: all affected
>> low-level code is now built in Thumb-2. ?At least some of this
>> code definitely works, but whether the Secure firmware can talk
>> to Thumb-2 code properly is unproven:
>> in particular, I could use some help/advice from the omap
>> community for validating that the low-level power management
>> interactions actually work with this patch set.
>>
>> I've done simple "does it boot?" testing by building a single
>> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
>> which works on Beagle xM A2 and Panda A1.
>
> I have boot tested this series on OMAP3430 and OMAP4430. Also
> tested the RETENTION and OFF mode in suspend on OMAP3.

Which tree did you use to test this?  It didn't seem to work for me --
sometimes the system wouldn't suspend, complaining about USB suspend
errors; and other times I couldn't bring it out of suspend (by poking
a USB input device).

I might be doing something wrong...

> I couldn't test the DVFS because it isn't in mainline yet
> but the changes doesn't looks to break anything.
>
> So if you like, you can add
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>

Thanks, that's great.

If there some other tree with DVFS working which I could try?  Even if
these patches don't apply, I may be able to test whether the changes
should work.

Cheers
---Dave

RE: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Friday, February 04, 2011 4:33 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel@lists.infradead.org; Tony Lindgren; Jean Pihet-
> XID; linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> fixes
>
> On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> > Dave,
> >> -----Original Message-----
> >> From: Dave Martin [mailto:dave.martin@linaro.org]
> >> Sent: Thursday, February 03, 2011 11:33 PM
> >> To: linux-arm-kernel@lists.infradead.org
> >> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> >> linux-omap@vger.kernel.org; Nicolas Pitre
> >> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> fixes
> >>
> >> This set of patches, along with some other patches under
> >> discussion on alkml, should enable omap3 and omap4 kernels to be
> >> built with CONFIG_THUMB2_KERNEL.
> >>
> >> This patch set builds on recent cleanup done by the omap
> >> maintainers.
> >>
> >> It is also more aggressive than my last post: all affected
> >> low-level code is now built in Thumb-2.  At least some of this
> >> code definitely works, but whether the Secure firmware can talk
> >> to Thumb-2 code properly is unproven:
> >> in particular, I could use some help/advice from the omap
> >> community for validating that the low-level power management
> >> interactions actually work with this patch set.
> >>
> >> I've done simple "does it boot?" testing by building a single
> >> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
> >> which works on Beagle xM A2 and Panda A1.
> >
> > I have boot tested this series on OMAP3430 and OMAP4430. Also
> > tested the RETENTION and OFF mode in suspend on OMAP3.
>
> Which tree did you use to test this?  It didn't seem to work for me
> --
> sometimes the system wouldn't suspend, complaining about USB suspend
> errors; and other times I couldn't bring it out of suspend (by
> poking
> a USB input device).
>
> I might be doing something wrong...
>
I should have mentioned this.
Used Kevins pm branch to test these features.
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git


> > I couldn't test the DVFS because it isn't in mainline yet
> > but the changes doesn't looks to break anything.
> >
> > So if you like, you can add
> > Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >
>
> Thanks, that's great.
>
> If there some other tree with DVFS working which I could try?  Even
> if
> these patches don't apply, I may be able to test whether the changes
> should work.
>
DVFS support is getting added and one series was posted by Vishwa.
The link for the same is :
http://www.spinics.net/lists/linux-omap/msg44393.html

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Friday, February 04, 2011 4:33 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel at lists.infradead.org; Tony Lindgren; Jean Pihet-
> XID; linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> fixes
>
> On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> > Dave,
> >> -----Original Message-----
> >> From: Dave Martin [mailto:dave.martin at linaro.org]
> >> Sent: Thursday, February 03, 2011 11:33 PM
> >> To: linux-arm-kernel at lists.infradead.org
> >> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> >> linux-omap at vger.kernel.org; Nicolas Pitre
> >> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> fixes
> >>
> >> This set of patches, along with some other patches under
> >> discussion on alkml, should enable omap3 and omap4 kernels to be
> >> built with CONFIG_THUMB2_KERNEL.
> >>
> >> This patch set builds on recent cleanup done by the omap
> >> maintainers.
> >>
> >> It is also more aggressive than my last post: all affected
> >> low-level code is now built in Thumb-2. ?At least some of this
> >> code definitely works, but whether the Secure firmware can talk
> >> to Thumb-2 code properly is unproven:
> >> in particular, I could use some help/advice from the omap
> >> community for validating that the low-level power management
> >> interactions actually work with this patch set.
> >>
> >> I've done simple "does it boot?" testing by building a single
> >> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
> >> which works on Beagle xM A2 and Panda A1.
> >
> > I have boot tested this series on OMAP3430 and OMAP4430. Also
> > tested the RETENTION and OFF mode in suspend on OMAP3.
>
> Which tree did you use to test this?  It didn't seem to work for me
> --
> sometimes the system wouldn't suspend, complaining about USB suspend
> errors; and other times I couldn't bring it out of suspend (by
> poking
> a USB input device).
>
> I might be doing something wrong...
>
I should have mentioned this.
Used Kevins pm branch to test these features.
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git


> > I couldn't test the DVFS because it isn't in mainline yet
> > but the changes doesn't looks to break anything.
> >
> > So if you like, you can add
> > Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >
>
> Thanks, that's great.
>
> If there some other tree with DVFS working which I could try?  Even
> if
> these patches don't apply, I may be able to test whether the changes
> should work.
>
DVFS support is getting added and one series was posted by Vishwa.
The link for the same is :
http://www.spinics.net/lists/linux-omap/msg44393.html

Regards,
Santosh

RE: [PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Friday, February 04, 2011 4:28 PM
> To: Santosh Shilimkar
> Cc: Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org;
> Tony Lindgren; Nicolas Pitre; linux-omap@vger.kernel.org; Jean
> Pihet-XID
> Subject: Re: [PATCH v2 1/5] ARM: omap4: Correct definition of
> do_wfi() forCONFIG_THUMB2_KERNEL
>
> On Thu, Feb 3, 2011 at 7:30 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> >> -----Original Message-----
[....]

> >> We actually have this:
> >>
> >> #if __LINUX_ARM_ARCH__ >= 7 ||          \
> >>         (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
> >> #define sev()   __asm__ __volatile__ ("sev" : : : "memory")
> >> #define wfe()   __asm__ __volatile__ ("wfe" : : : "memory")
> >> #define wfi()   __asm__ __volatile__ ("wfi" : : : "memory")
> >> #endif
> >>
> >> in asm/system.h, so maybe it should be using wfe() from
> asm/system.h
> >> ?
> > I assume you mean wfi here.
> > The problem is, omap2plus build breaks because it builds
> > CPU_32v6 and CPU_32v7 as well which doesn't support the wfi
> > instruction. Hence I used opcode directly to keep build
> > working.
>
> I guess that's right, OMAP2 is ARM1136 and doesn't have the K
> extensions.
>
> Would it make sense to have the v6 MCR equivalent as an altetnative?
> Something like:
>
> #elseif __LINUX_ARM_ARCH__ >= 6
> #define wfi()   __asm__ __volatile__ ( \
>     "mov     r0, #0\n\t" \
>     "mcr     p15, 0, r0, c7, c0, 4\n\t" \
>     ::: "r0"
> )
> #endif
>
> This MCR is a mandatory part of the architecture for v6, but it's
> not
> mandatory for older processors.
>
That should do as well.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Friday, February 04, 2011 4:28 PM
> To: Santosh Shilimkar
> Cc: Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org;
> Tony Lindgren; Nicolas Pitre; linux-omap at vger.kernel.org; Jean
> Pihet-XID
> Subject: Re: [PATCH v2 1/5] ARM: omap4: Correct definition of
> do_wfi() forCONFIG_THUMB2_KERNEL
>
> On Thu, Feb 3, 2011 at 7:30 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> >> -----Original Message-----
[....]

> >> We actually have this:
> >>
> >> #if __LINUX_ARM_ARCH__ >= 7 || ? ? ? ? ?\
> >> ? ? ? ? (__LINUX_ARM_ARCH__ == 6 && defined(CONFIG_CPU_32v6K))
> >> #define sev() ? __asm__ __volatile__ ("sev" : : : "memory")
> >> #define wfe() ? __asm__ __volatile__ ("wfe" : : : "memory")
> >> #define wfi() ? __asm__ __volatile__ ("wfi" : : : "memory")
> >> #endif
> >>
> >> in asm/system.h, so maybe it should be using wfe() from
> asm/system.h
> >> ?
> > I assume you mean wfi here.
> > The problem is, omap2plus build breaks because it builds
> > CPU_32v6 and CPU_32v7 as well which doesn't support the wfi
> > instruction. Hence I used opcode directly to keep build
> > working.
>
> I guess that's right, OMAP2 is ARM1136 and doesn't have the K
> extensions.
>
> Would it make sense to have the v6 MCR equivalent as an altetnative?
> Something like:
>
> #elseif __LINUX_ARM_ARCH__ >= 6
> #define wfi()   __asm__ __volatile__ ( \
>     "mov     r0, #0\n\t" \
>     "mcr     p15, 0, r0, c7, c0, 4\n\t" \
>     ::: "r0"
> )
> #endif
>
> This MCR is a mandatory part of the architecture for v6, but it's
> not
> mandatory for older processors.
>
That should do as well.

Regards,
Santosh

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Fri, Feb 4, 2011 at 11:16 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Dave Martin [mailto:dave.martin@linaro.org]
>> Sent: Friday, February 04, 2011 4:33 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-kernel@lists.infradead.org; Tony Lindgren; Jean Pihet-
>> XID; linux-omap@vger.kernel.org; Nicolas Pitre
>> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
>> fixes
>>
>> On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:
>> > Dave,
>> >> -----Original Message-----
>> >> From: Dave Martin [mailto:dave.martin@linaro.org]
>> >> Sent: Thursday, February 03, 2011 11:33 PM
>> >> To: linux-arm-kernel@lists.infradead.org
>> >> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
>> >> linux-omap@vger.kernel.org; Nicolas Pitre
>> >> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
>> fixes
>> >>
>> >> This set of patches, along with some other patches under
>> >> discussion on alkml, should enable omap3 and omap4 kernels to be
>> >> built with CONFIG_THUMB2_KERNEL.
>> >>
>> >> This patch set builds on recent cleanup done by the omap
>> >> maintainers.
>> >>
>> >> It is also more aggressive than my last post: all affected
>> >> low-level code is now built in Thumb-2.  At least some of this
>> >> code definitely works, but whether the Secure firmware can talk
>> >> to Thumb-2 code properly is unproven:
>> >> in particular, I could use some help/advice from the omap
>> >> community for validating that the low-level power management
>> >> interactions actually work with this patch set.
>> >>
>> >> I've done simple "does it boot?" testing by building a single
>> >> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
>> >> which works on Beagle xM A2 and Panda A1.
>> >
>> > I have boot tested this series on OMAP3430 and OMAP4430. Also
>> > tested the RETENTION and OFF mode in suspend on OMAP3.
>>
>> Which tree did you use to test this?  It didn't seem to work for me
>> --
>> sometimes the system wouldn't suspend, complaining about USB suspend
>> errors; and other times I couldn't bring it out of suspend (by
>> poking
>> a USB input device).
>>
>> I might be doing something wrong...
>>
> I should have mentioned this.
> Used Kevins pm branch to test these features.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
>
>> > I couldn't test the DVFS because it isn't in mainline yet
>> > but the changes doesn't looks to break anything.
>> >
>> > So if you like, you can add
>> > Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >
>>
>> Thanks, that's great.
>>
>> If there some other tree with DVFS working which I could try?  Even
>> if
>> these patches don't apply, I may be able to test whether the changes
>> should work.
>>
> DVFS support is getting added and one series was posted by Vishwa.
> The link for the same is :
> http://www.spinics.net/lists/linux-omap/msg44393.html
>

Thanks, I'll have a play with it.
Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Fri, Feb 4, 2011 at 11:16 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Dave Martin [mailto:dave.martin at linaro.org]
>> Sent: Friday, February 04, 2011 4:33 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-kernel at lists.infradead.org; Tony Lindgren; Jean Pihet-
>> XID; linux-omap at vger.kernel.org; Nicolas Pitre
>> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
>> fixes
>>
>> On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:
>> > Dave,
>> >> -----Original Message-----
>> >> From: Dave Martin [mailto:dave.martin at linaro.org]
>> >> Sent: Thursday, February 03, 2011 11:33 PM
>> >> To: linux-arm-kernel at lists.infradead.org
>> >> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
>> >> linux-omap at vger.kernel.org; Nicolas Pitre
>> >> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
>> fixes
>> >>
>> >> This set of patches, along with some other patches under
>> >> discussion on alkml, should enable omap3 and omap4 kernels to be
>> >> built with CONFIG_THUMB2_KERNEL.
>> >>
>> >> This patch set builds on recent cleanup done by the omap
>> >> maintainers.
>> >>
>> >> It is also more aggressive than my last post: all affected
>> >> low-level code is now built in Thumb-2. ?At least some of this
>> >> code definitely works, but whether the Secure firmware can talk
>> >> to Thumb-2 code properly is unproven:
>> >> in particular, I could use some help/advice from the omap
>> >> community for validating that the low-level power management
>> >> interactions actually work with this patch set.
>> >>
>> >> I've done simple "does it boot?" testing by building a single
>> >> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
>> >> which works on Beagle xM A2 and Panda A1.
>> >
>> > I have boot tested this series on OMAP3430 and OMAP4430. Also
>> > tested the RETENTION and OFF mode in suspend on OMAP3.
>>
>> Which tree did you use to test this? ?It didn't seem to work for me
>> --
>> sometimes the system wouldn't suspend, complaining about USB suspend
>> errors; and other times I couldn't bring it out of suspend (by
>> poking
>> a USB input device).
>>
>> I might be doing something wrong...
>>
> I should have mentioned this.
> Used Kevins pm branch to test these features.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
>
>> > I couldn't test the DVFS because it isn't in mainline yet
>> > but the changes doesn't looks to break anything.
>> >
>> > So if you like, you can add
>> > Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >
>>
>> Thanks, that's great.
>>
>> If there some other tree with DVFS working which I could try? ?Even
>> if
>> these patches don't apply, I may be able to test whether the changes
>> should work.
>>
> DVFS support is getting added and one series was posted by Vishwa.
> The link for the same is :
> http://www.spinics.net/lists/linux-omap/msg44393.html
>

Thanks, I'll have a play with it.
Cheers
---Dave

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Fri, Feb 04, 2011 at 04:46:57PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Dave Martin [mailto:dave.martin@linaro.org]
> > Sent: Friday, February 04, 2011 4:33 PM
> > To: Santosh Shilimkar
> > Cc: linux-arm-kernel@lists.infradead.org; Tony Lindgren; Jean Pihet-
> > XID; linux-omap@vger.kernel.org; Nicolas Pitre
> > Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> > fixes
> >
> > On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> > > Dave,
> > >> -----Original Message-----
> > >> From: Dave Martin [mailto:dave.martin@linaro.org]
> > >> Sent: Thursday, February 03, 2011 11:33 PM
> > >> To: linux-arm-kernel@lists.infradead.org
> > >> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> > >> linux-omap@vger.kernel.org; Nicolas Pitre
> > >> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> > fixes
> > >>
> > >> This set of patches, along with some other patches under
> > >> discussion on alkml, should enable omap3 and omap4 kernels to be
> > >> built with CONFIG_THUMB2_KERNEL.
> > >>
> > >> This patch set builds on recent cleanup done by the omap
> > >> maintainers.
> > >>
> > >> It is also more aggressive than my last post: all affected
> > >> low-level code is now built in Thumb-2.  At least some of this
> > >> code definitely works, but whether the Secure firmware can talk
> > >> to Thumb-2 code properly is unproven:
> > >> in particular, I could use some help/advice from the omap
> > >> community for validating that the low-level power management
> > >> interactions actually work with this patch set.
> > >>
> > >> I've done simple "does it boot?" testing by building a single
> > >> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
> > >> which works on Beagle xM A2 and Panda A1.
> > >
> > > I have boot tested this series on OMAP3430 and OMAP4430. Also
> > > tested the RETENTION and OFF mode in suspend on OMAP3.
> >
> > Which tree did you use to test this?  It didn't seem to work for me
> > --
> > sometimes the system wouldn't suspend, complaining about USB suspend
> > errors; and other times I couldn't bring it out of suspend (by
> > poking
> > a USB input device).
> >
> > I might be doing something wrong...
> >
> I should have mentioned this.
> Used Kevins pm branch to test these features.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

Have you tried this kernel on Beagle xM with CONFIG_SMP and
CONFIG_SMP_ON_UP enabled?  For me it hangs just after
"Uncompressing Linux ... ok, booting the kernel".

I haven't worked out why this happens as yet.

Also, I'm still not sure I'm testing the power management
features correctly.  Do you know what config options I need to poke?
Also, how do I resume after echo mem >/sys/power/state?

Cheers
---Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Fri, Feb 04, 2011 at 04:46:57PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Dave Martin [mailto:dave.martin at linaro.org]
> > Sent: Friday, February 04, 2011 4:33 PM
> > To: Santosh Shilimkar
> > Cc: linux-arm-kernel at lists.infradead.org; Tony Lindgren; Jean Pihet-
> > XID; linux-omap at vger.kernel.org; Nicolas Pitre
> > Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> > fixes
> >
> > On Fri, Feb 4, 2011 at 10:45 AM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> > > Dave,
> > >> -----Original Message-----
> > >> From: Dave Martin [mailto:dave.martin at linaro.org]
> > >> Sent: Thursday, February 03, 2011 11:33 PM
> > >> To: linux-arm-kernel at lists.infradead.org
> > >> Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar; Jean Pihet;
> > >> linux-omap at vger.kernel.org; Nicolas Pitre
> > >> Subject: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> > fixes
> > >>
> > >> This set of patches, along with some other patches under
> > >> discussion on alkml, should enable omap3 and omap4 kernels to be
> > >> built with CONFIG_THUMB2_KERNEL.
> > >>
> > >> This patch set builds on recent cleanup done by the omap
> > >> maintainers.
> > >>
> > >> It is also more aggressive than my last post: all affected
> > >> low-level code is now built in Thumb-2. ?At least some of this
> > >> code definitely works, but whether the Secure firmware can talk
> > >> to Thumb-2 code properly is unproven:
> > >> in particular, I could use some help/advice from the omap
> > >> community for validating that the low-level power management
> > >> interactions actually work with this patch set.
> > >>
> > >> I've done simple "does it boot?" testing by building a single
> > >> kernel with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled
> > >> which works on Beagle xM A2 and Panda A1.
> > >
> > > I have boot tested this series on OMAP3430 and OMAP4430. Also
> > > tested the RETENTION and OFF mode in suspend on OMAP3.
> >
> > Which tree did you use to test this?  It didn't seem to work for me
> > --
> > sometimes the system wouldn't suspend, complaining about USB suspend
> > errors; and other times I couldn't bring it out of suspend (by
> > poking
> > a USB input device).
> >
> > I might be doing something wrong...
> >
> I should have mentioned this.
> Used Kevins pm branch to test these features.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

Have you tried this kernel on Beagle xM with CONFIG_SMP and
CONFIG_SMP_ON_UP enabled?  For me it hangs just after
"Uncompressing Linux ... ok, booting the kernel".

I haven't worked out why this happens as yet.

Also, I'm still not sure I'm testing the power management
features correctly.  Do you know what config options I need to poke?
Also, how do I resume after echo mem >/sys/power/state?

Cheers
---Dave

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

Hi Santosh,

[...]

>> Which tree did you use to test this?  It didn't seem to work for me
>> --
>> sometimes the system wouldn't suspend, complaining about USB suspend
>> errors; and other times I couldn't bring it out of suspend (by
>> poking
>> a USB input device).
>>
>> I might be doing something wrong...
>>
> I should have mentioned this.
> Used Kevins pm branch to test these features.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
>> > I couldn't test the DVFS because it isn't in mainline yet
>> > but the changes doesn't looks to break anything.
>> >
>> > So if you like, you can add
>> > Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >
>>
>> Thanks, that's great.
>>
>> If there some other tree with DVFS working which I could try?  Even
>> if
>> these patches don't apply, I may be able to test whether the changes
>> should work.
>>
> DVFS support is getting added and one series was posted by Vishwa.
> The link for the same is :
> http://www.spinics.net/lists/linux-omap/msg44393.html

I'm still having problems testing basic power management...

I'm using this config:
http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

... and Kevin's pm tree with my patches on top.


However, even building without CONFIG_THUMB2_KERNEL, Beagle xM doesn't
seem to suspend properly:

Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l GNU/Linux

#
# [  302.446228] SysRq : Changing Loglevel
[  302.449951] Loglevel set to 9
echo mem >/sys/power/state &
[1] 545
# [  306.525177] PM: Syncing filesystems ... done.
[  308.989715] mmc0: card 1234 removed
#
#
#
#
#
# jobs
[1]+  Running                 echo mem > /sys/power/state &
#

The SD card gets suspended, but nothing else seems to happen, and I
can't resume the system.

Am I doing something wrong?

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

Hi Santosh,

[...]

>> Which tree did you use to test this? ?It didn't seem to work for me
>> --
>> sometimes the system wouldn't suspend, complaining about USB suspend
>> errors; and other times I couldn't bring it out of suspend (by
>> poking
>> a USB input device).
>>
>> I might be doing something wrong...
>>
> I should have mentioned this.
> Used Kevins pm branch to test these features.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
>> > I couldn't test the DVFS because it isn't in mainline yet
>> > but the changes doesn't looks to break anything.
>> >
>> > So if you like, you can add
>> > Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> >
>>
>> Thanks, that's great.
>>
>> If there some other tree with DVFS working which I could try? ?Even
>> if
>> these patches don't apply, I may be able to test whether the changes
>> should work.
>>
> DVFS support is getting added and one series was posted by Vishwa.
> The link for the same is :
> http://www.spinics.net/lists/linux-omap/msg44393.html

I'm still having problems testing basic power management...

I'm using this config:
http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config

... and Kevin's pm tree with my patches on top.


However, even building without CONFIG_THUMB2_KERNEL, Beagle xM doesn't
seem to suspend properly:

Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l GNU/Linux

#
# [  302.446228] SysRq : Changing Loglevel
[  302.449951] Loglevel set to 9
echo mem >/sys/power/state &
[1] 545
# [  306.525177] PM: Syncing filesystems ... done.
[  308.989715] mmc0: card 1234 removed
#
#
#
#
#
# jobs
[1]+  Running                 echo mem > /sys/power/state &
#

The SD card gets suspended, but nothing else seems to happen, and I
can't resume the system.

Am I doing something wrong?

Cheers
---Dave

RE: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin@linaro.org]
> Sent: Tuesday, February 08, 2011 11:11 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel@lists.infradead.org; Tony Lindgren; Jean Pihet-
> XID; linux-omap@vger.kernel.org; Nicolas Pitre
> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> fixes
>
> Hi Santosh,
>

[...]

> I'm still having problems testing basic power management...
>
> I'm using this config:
> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>
> ... and Kevin's pm tree with my patches on top.
>
>
> However, even building without CONFIG_THUMB2_KERNEL, Beagle xM
> doesn't
> seem to suspend properly:
>
> Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l
> GNU/Linux
>
> #
> # [  302.446228] SysRq : Changing Loglevel
> [  302.449951] Loglevel set to 9
> echo mem >/sys/power/state &
> [1] 545
> # [  306.525177] PM: Syncing filesystems ... done.
> [  308.989715] mmc0: card 1234 removed
> #
> #
> #
> #
> #
> # jobs
> [1]+  Running                 echo mem > /sys/power/state &
> #
>
> The SD card gets suspended, but nothing else seems to happen, and I
> can't resume the system.
>
> Am I doing something wrong?
>
MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing

Regards,
santosh

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Santosh Shilimkar]

> -----Original Message-----
> From: Dave Martin [mailto:dave.martin at linaro.org]
> Sent: Tuesday, February 08, 2011 11:11 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel at lists.infradead.org; Tony Lindgren; Jean Pihet-
> XID; linux-omap at vger.kernel.org; Nicolas Pitre
> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
> fixes
>
> Hi Santosh,
>

[...]

> I'm still having problems testing basic power management...
>
> I'm using this config:
> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>
> ... and Kevin's pm tree with my patches on top.
>
>
> However, even building without CONFIG_THUMB2_KERNEL, Beagle xM
> doesn't
> seem to suspend properly:
>
> Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l
> GNU/Linux
>
> #
> # [  302.446228] SysRq : Changing Loglevel
> [  302.449951] Loglevel set to 9
> echo mem >/sys/power/state &
> [1] 545
> # [  306.525177] PM: Syncing filesystems ... done.
> [  308.989715] mmc0: card 1234 removed
> #
> #
> #
> #
> #
> # jobs
> [1]+  Running                 echo mem > /sys/power/state &
> #
>
> The SD card gets suspended, but nothing else seems to happen, and I
> can't resume the system.
>
> Am I doing something wrong?
>
MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing

Regards,
santosh

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Wed, Feb 9, 2011 at 5:45 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Dave Martin [mailto:dave.martin@linaro.org]
>> Sent: Tuesday, February 08, 2011 11:11 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-kernel@lists.infradead.org; Tony Lindgren; Jean Pihet-
>> XID; linux-omap@vger.kernel.org; Nicolas Pitre
>> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
>> fixes
>>
>> Hi Santosh,
>>
>
> [...]
>
>> I'm still having problems testing basic power management...
>>
>> I'm using this config:
>> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>>
>> ... and Kevin's pm tree with my patches on top.
>>
>>
>> However, even building without CONFIG_THUMB2_KERNEL, Beagle xM
>> doesn't
>> seem to suspend properly:
>>
>> Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l
>> GNU/Linux
>>
>> #
>> # [  302.446228] SysRq : Changing Loglevel
>> [  302.449951] Loglevel set to 9
>> echo mem >/sys/power/state &
>> [1] 545
>> # [  306.525177] PM: Syncing filesystems ... done.
>> [  308.989715] mmc0: card 1234 removed
>> #
>> #
>> #
>> #
>> #
>> # jobs
>> [1]+  Running                 echo mem > /sys/power/state &
>> #
>>
>> The SD card gets suspended, but nothing else seems to happen, and I
>> can't resume the system.
>>
>> Am I doing something wrong?
>>
> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing

Ah, right -- I'll try without MMC.

Thanks
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Wed, Feb 9, 2011 at 5:45 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Dave Martin [mailto:dave.martin at linaro.org]
>> Sent: Tuesday, February 08, 2011 11:11 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-kernel at lists.infradead.org; Tony Lindgren; Jean Pihet-
>> XID; linux-omap at vger.kernel.org; Nicolas Pitre
>> Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility
>> fixes
>>
>> Hi Santosh,
>>
>
> [...]
>
>> I'm still having problems testing basic power management...
>>
>> I'm using this config:
>> http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>>
>> ... and Kevin's pm tree with my patches on top.
>>
>>
>> However, even building without CONFIG_THUMB2_KERNEL, Beagle xM
>> doesn't
>> seem to suspend properly:
>>
>> Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l
>> GNU/Linux
>>
>> #
>> # [ ?302.446228] SysRq : Changing Loglevel
>> [ ?302.449951] Loglevel set to 9
>> echo mem >/sys/power/state &
>> [1] 545
>> # [ ?306.525177] PM: Syncing filesystems ... done.
>> [ ?308.989715] mmc0: card 1234 removed
>> #
>> #
>> #
>> #
>> #
>> # jobs
>> [1]+ ?Running ? ? ? ? ? ? ? ? echo mem > /sys/power/state &
>> #
>>
>> The SD card gets suspended, but nothing else seems to happen, and I
>> can't resume the system.
>>
>> Am I doing something wrong?
>>
> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing

Ah, right -- I'll try without MMC.

Thanks
---Dave

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Kevin Hilman]

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

[...]

>>
>> The SD card gets suspended, but nothing else seems to happen, and I
>> can't resume the system.
>>
>> Am I doing something wrong?
>>
> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing
>

Just to clarify, MMC suspend is not broken.  It's a "feature" the MMC
core.  See the help text of the following Kconfig option, and ensure
that it's enabled:


config MMC_UNSAFE_RESUME
	bool "Assume MMC/SD cards are non-removable (DANGEROUS)"
	help
	  If you say Y here, the MMC layer will assume that all cards
	  stayed in their respective slots during the suspend. The
	  normal behaviour is to remove them at suspend and
	  redetecting them at resume. Breaking this assumption will
	  in most cases result in data corruption.

	  This option is usually just for embedded systems which use
	  a MMC/SD card for rootfs. Most people should say N here.

	  This option sets a default which can be overridden by the
	  module parameter "removable=0" or "removable=1".

Looking at Dave's .config, this option is disabled, so suspend will hang
when rootfs is on MMC.

Kevin

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Kevin Hilman]

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

[...]

>>
>> The SD card gets suspended, but nothing else seems to happen, and I
>> can't resume the system.
>>
>> Am I doing something wrong?
>>
> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing
>

Just to clarify, MMC suspend is not broken.  It's a "feature" the MMC
core.  See the help text of the following Kconfig option, and ensure
that it's enabled:


config MMC_UNSAFE_RESUME
	bool "Assume MMC/SD cards are non-removable (DANGEROUS)"
	help
	  If you say Y here, the MMC layer will assume that all cards
	  stayed in their respective slots during the suspend. The
	  normal behaviour is to remove them at suspend and
	  redetecting them at resume. Breaking this assumption will
	  in most cases result in data corruption.

	  This option is usually just for embedded systems which use
	  a MMC/SD card for rootfs. Most people should say N here.

	  This option sets a default which can be overridden by the
	  module parameter "removable=0" or "removable=1".

Looking at Dave's .config, this option is disabled, so suspend will hang
when rootfs is on MMC.

Kevin

Re: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Kevin Hilman]

Dave Martin <dave.martin@linaro.org> writes:

>  * Use BSYM() to get the correct Thumb branch address
>    for adr <Rd>, <label>
>
>  * Fix an out-of-range ADR when building for ARM
>
>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>
>  * Remove deprecated/undefined PC-relative stores
>
>  * Add the required ENDPROC() directive for each ENTRY().
>
>  * .align before data words
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

I'm attempting to test this series with OMAP PM, but some changes here
don't compile for me.

My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) 

First, I merged your arm/omap-thumb2+merged branch with my pm branch
from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

There were some minor conflicts here, but they looked simple enough and
I just resolved in favor of your branch.

Trying to build with CONFIG_THUMB2_KERNEL=y, I ran into a compile
problem...


> ---
>  arch/arm/mach-omap2/sleep34xx.S |   42 +++++++++++++++++++++++++++++---------
>  1 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> index 4032a8e..ef73429 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -80,8 +80,10 @@
>  /* Function call to get the restore pointer for resume from OFF */
>  ENTRY(get_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore
> +	adr	r0, BSYM(restore)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_restore_pointer)
> +	.align
>  ENTRY(get_restore_pointer_sz)
>  	.word	. - get_restore_pointer
>  
> @@ -89,8 +91,10 @@ ENTRY(get_restore_pointer_sz)
>  /* Function call to get the restore pointer for 3630 resume from OFF */
>  ENTRY(get_omap3630_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_3630
> +	adr	r0, BSYM(restore_3630)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_omap3630_restore_pointer)
> +	.align
>  ENTRY(get_omap3630_restore_pointer_sz)
>  	.word	. - get_omap3630_restore_pointer
>  
> @@ -98,8 +102,10 @@ ENTRY(get_omap3630_restore_pointer_sz)
>  /* Function call to get the restore pointer for ES3 to resume from OFF */
>  ENTRY(get_es3_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_es3
> +	adr	r0, BSYM(restore_es3)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_es3_restore_pointer)
> +	.align
>  ENTRY(get_es3_restore_pointer_sz)
>  	.word	. - get_es3_restore_pointer
>  
> @@ -113,8 +119,11 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
>  	stmfd	sp!, {lr}	@ save registers on stack
>  	/* Setup so that we will disable and enable l2 */
>  	mov	r1, #0x1
> -	str	r1, l2dis_3630
> + ARM(	adrl	r2, l2dis_3630	)	@ may be out of range for adr in ARM
> + THUMB(	adr	r2, l2dis_3630	)	@ Thumb has more range, but not adrl
> +	str	r1, [r2]
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(enable_omap3630_toggle_l2_on_restore)
>  
>  	.text
>  /* Function to call rom code to save secure ram context */
> @@ -139,12 +148,14 @@ ENTRY(save_secure_ram_context)
>  	nop
>  	nop
>  	ldmfd	sp!, {r1-r12, pc}
> +	.align
>  sram_phy_addr_mask:
>  	.word	SRAM_BASE_P
>  high_mask:
>  	.word	0xffff
>  api_params:
>  	.word	0x4, 0x0, 0x0, 0x1, 0x1
> +ENDPROC(save_secure_ram_context)
>  ENTRY(save_secure_ram_context_sz)
>  	.word	. - save_secure_ram_context
>  
> @@ -279,8 +290,7 @@ clean_l2:
>  	 *  - 'might' have to copy address, load and jump to it
>  	 */
>  	ldr	r1, kernel_flush
> -	mov	lr, pc
> -	bx	r1
> +	blx	r1
>  
>  omap3_do_wfi:
>  	ldr	r4, sdrc_power		@ read the SDRC_POWER register
> @@ -346,8 +356,8 @@ restore_es3:
>  	and	r4, r4, #0x3
>  	cmp	r4, #0x0	@ Check if previous power state of CORE is OFF
>  	bne	restore
> -	adr	r0, es3_sdrc_fix
> -	ldr	r1, sram_base
> +	adr	r0, es3_sdrc_fix	@ Not using BSYM clears the Thumb bit.

This fails to compile:

/work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S: Assembler messages:
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:361: Error: invalid immediate for address calculation (value = 0x00000004)

Kevin

> +	ldr	r1, sram_base	@ Must be 8-byte aligned to preserve alignment.
>  	ldr	r2, es3_sdrc_fix_sz
>  	mov	r2, r2, ror #2
>  copy_to_sram:
> @@ -356,6 +366,7 @@ copy_to_sram:
>  	subs	r2, r2, #0x1	@ num_words--
>  	bne	copy_to_sram
>  	ldr	r1, sram_base
> + THUMB(	orr	r1, r1, #BSYM(es3_sdrc_fix) & 1 )
>  	blx	r1
>  	b	restore
>  
> @@ -438,6 +449,7 @@ skipl2dis:
>  #endif
>  	b	logic_l1_restore
>  
> +	.align
>  l2_inv_api_params:
>  	.word	0x1, 0x00
>  l2_inv_gp:
> @@ -607,6 +619,7 @@ usettbr0:
>  
>  /* This function implements the erratum ID i443 WA, applies to 34xx >= ES3.0 */
>  	.text
> +	.align	3
>  ENTRY(es3_sdrc_fix)
>  	ldr	r4, sdrc_syscfg		@ get config addr
>  	ldr	r5, [r4]		@ get value
> @@ -634,6 +647,7 @@ ENTRY(es3_sdrc_fix)
>  	str	r5, [r4]		@ kick off refreshes
>  	bx	lr
>  
> +	.align
>  sdrc_syscfg:
>  	.word	SDRC_SYSCONFIG_P
>  sdrc_mr_0:
> @@ -648,6 +662,7 @@ sdrc_emr2_1:
>  	.word	SDRC_EMR2_1_P
>  sdrc_manual_1:
>  	.word	SDRC_MANUAL_1_P
> +ENDPROC(es3_sdrc_fix)
>  ENTRY(es3_sdrc_fix_sz)
>  	.word	. - es3_sdrc_fix
>  
> @@ -682,6 +697,10 @@ wait_sdrc_ready:
>  	bic	r5, r5, #0x40
>  	str	r5, [r4]
>  
> +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
> +@ base instead.
> +@ Be careful not to clobber r7 when maintaing this code.
> +
>  is_dll_in_lock_mode:
>  	/* Is dll in lock mode? */
>  	ldr	r4, sdrc_dlla_ctrl
> @@ -689,10 +708,11 @@ is_dll_in_lock_mode:
>  	tst	r5, #0x4
>  	bxne	lr			@ Return if locked
>  	/* wait till dll locks */
> +	adr	r7, kick_counter
>  wait_dll_lock_timed:
>  	ldr	r4, wait_dll_lock_counter
>  	add	r4, r4, #1
> -	str	r4, wait_dll_lock_counter
> +	str	r4, [r7, #wait_dll_lock_counter - kick_counter]
>  	ldr	r4, sdrc_dlla_status
>  	/* Wait 20uS for lock */
>  	mov	r6, #8
> @@ -718,9 +738,10 @@ kick_dll:
>  	dsb
>  	ldr	r4, kick_counter
>  	add	r4, r4, #1
> -	str	r4, kick_counter
> +	str	r4, [r7]		@ kick_counter
>  	b	wait_dll_lock_timed
>  
> +	.align
>  cm_idlest1_core:
>  	.word	CM_IDLEST1_CORE_V
>  cm_idlest_ckgen:
> @@ -763,6 +784,7 @@ kick_counter:
>  	.word	0
>  wait_dll_lock_counter:
>  	.word	0
> +ENDPROC(omap34xx_cpu_suspend)
>  
>  ENTRY(omap34xx_cpu_suspend_sz)
>  	.word	. - omap34xx_cpu_suspend

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Kevin Hilman]

Dave Martin <dave.martin@linaro.org> writes:

>  * Use BSYM() to get the correct Thumb branch address
>    for adr <Rd>, <label>
>
>  * Fix an out-of-range ADR when building for ARM
>
>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>
>  * Remove deprecated/undefined PC-relative stores
>
>  * Add the required ENDPROC() directive for each ENTRY().
>
>  * .align before data words
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

I'm attempting to test this series with OMAP PM, but some changes here
don't compile for me.

My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) 

First, I merged your arm/omap-thumb2+merged branch with my pm branch
from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

There were some minor conflicts here, but they looked simple enough and
I just resolved in favor of your branch.

Trying to build with CONFIG_THUMB2_KERNEL=y, I ran into a compile
problem...


> ---
>  arch/arm/mach-omap2/sleep34xx.S |   42 +++++++++++++++++++++++++++++---------
>  1 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> index 4032a8e..ef73429 100644
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -80,8 +80,10 @@
>  /* Function call to get the restore pointer for resume from OFF */
>  ENTRY(get_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore
> +	adr	r0, BSYM(restore)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_restore_pointer)
> +	.align
>  ENTRY(get_restore_pointer_sz)
>  	.word	. - get_restore_pointer
>  
> @@ -89,8 +91,10 @@ ENTRY(get_restore_pointer_sz)
>  /* Function call to get the restore pointer for 3630 resume from OFF */
>  ENTRY(get_omap3630_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_3630
> +	adr	r0, BSYM(restore_3630)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_omap3630_restore_pointer)
> +	.align
>  ENTRY(get_omap3630_restore_pointer_sz)
>  	.word	. - get_omap3630_restore_pointer
>  
> @@ -98,8 +102,10 @@ ENTRY(get_omap3630_restore_pointer_sz)
>  /* Function call to get the restore pointer for ES3 to resume from OFF */
>  ENTRY(get_es3_restore_pointer)
>  	stmfd	sp!, {lr}	@ save registers on stack
> -	adr	r0, restore_es3
> +	adr	r0, BSYM(restore_es3)
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(get_es3_restore_pointer)
> +	.align
>  ENTRY(get_es3_restore_pointer_sz)
>  	.word	. - get_es3_restore_pointer
>  
> @@ -113,8 +119,11 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
>  	stmfd	sp!, {lr}	@ save registers on stack
>  	/* Setup so that we will disable and enable l2 */
>  	mov	r1, #0x1
> -	str	r1, l2dis_3630
> + ARM(	adrl	r2, l2dis_3630	)	@ may be out of range for adr in ARM
> + THUMB(	adr	r2, l2dis_3630	)	@ Thumb has more range, but not adrl
> +	str	r1, [r2]
>  	ldmfd	sp!, {pc}	@ restore regs and return
> +ENDPROC(enable_omap3630_toggle_l2_on_restore)
>  
>  	.text
>  /* Function to call rom code to save secure ram context */
> @@ -139,12 +148,14 @@ ENTRY(save_secure_ram_context)
>  	nop
>  	nop
>  	ldmfd	sp!, {r1-r12, pc}
> +	.align
>  sram_phy_addr_mask:
>  	.word	SRAM_BASE_P
>  high_mask:
>  	.word	0xffff
>  api_params:
>  	.word	0x4, 0x0, 0x0, 0x1, 0x1
> +ENDPROC(save_secure_ram_context)
>  ENTRY(save_secure_ram_context_sz)
>  	.word	. - save_secure_ram_context
>  
> @@ -279,8 +290,7 @@ clean_l2:
>  	 *  - 'might' have to copy address, load and jump to it
>  	 */
>  	ldr	r1, kernel_flush
> -	mov	lr, pc
> -	bx	r1
> +	blx	r1
>  
>  omap3_do_wfi:
>  	ldr	r4, sdrc_power		@ read the SDRC_POWER register
> @@ -346,8 +356,8 @@ restore_es3:
>  	and	r4, r4, #0x3
>  	cmp	r4, #0x0	@ Check if previous power state of CORE is OFF
>  	bne	restore
> -	adr	r0, es3_sdrc_fix
> -	ldr	r1, sram_base
> +	adr	r0, es3_sdrc_fix	@ Not using BSYM clears the Thumb bit.

This fails to compile:

/work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S: Assembler messages:
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:361: Error: invalid immediate for address calculation (value = 0x00000004)

Kevin

> +	ldr	r1, sram_base	@ Must be 8-byte aligned to preserve alignment.
>  	ldr	r2, es3_sdrc_fix_sz
>  	mov	r2, r2, ror #2
>  copy_to_sram:
> @@ -356,6 +366,7 @@ copy_to_sram:
>  	subs	r2, r2, #0x1	@ num_words--
>  	bne	copy_to_sram
>  	ldr	r1, sram_base
> + THUMB(	orr	r1, r1, #BSYM(es3_sdrc_fix) & 1 )
>  	blx	r1
>  	b	restore
>  
> @@ -438,6 +449,7 @@ skipl2dis:
>  #endif
>  	b	logic_l1_restore
>  
> +	.align
>  l2_inv_api_params:
>  	.word	0x1, 0x00
>  l2_inv_gp:
> @@ -607,6 +619,7 @@ usettbr0:
>  
>  /* This function implements the erratum ID i443 WA, applies to 34xx >= ES3.0 */
>  	.text
> +	.align	3
>  ENTRY(es3_sdrc_fix)
>  	ldr	r4, sdrc_syscfg		@ get config addr
>  	ldr	r5, [r4]		@ get value
> @@ -634,6 +647,7 @@ ENTRY(es3_sdrc_fix)
>  	str	r5, [r4]		@ kick off refreshes
>  	bx	lr
>  
> +	.align
>  sdrc_syscfg:
>  	.word	SDRC_SYSCONFIG_P
>  sdrc_mr_0:
> @@ -648,6 +662,7 @@ sdrc_emr2_1:
>  	.word	SDRC_EMR2_1_P
>  sdrc_manual_1:
>  	.word	SDRC_MANUAL_1_P
> +ENDPROC(es3_sdrc_fix)
>  ENTRY(es3_sdrc_fix_sz)
>  	.word	. - es3_sdrc_fix
>  
> @@ -682,6 +697,10 @@ wait_sdrc_ready:
>  	bic	r5, r5, #0x40
>  	str	r5, [r4]
>  
> +@ PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
> +@ base instead.
> +@ Be careful not to clobber r7 when maintaing this code.
> +
>  is_dll_in_lock_mode:
>  	/* Is dll in lock mode? */
>  	ldr	r4, sdrc_dlla_ctrl
> @@ -689,10 +708,11 @@ is_dll_in_lock_mode:
>  	tst	r5, #0x4
>  	bxne	lr			@ Return if locked
>  	/* wait till dll locks */
> +	adr	r7, kick_counter
>  wait_dll_lock_timed:
>  	ldr	r4, wait_dll_lock_counter
>  	add	r4, r4, #1
> -	str	r4, wait_dll_lock_counter
> +	str	r4, [r7, #wait_dll_lock_counter - kick_counter]
>  	ldr	r4, sdrc_dlla_status
>  	/* Wait 20uS for lock */
>  	mov	r6, #8
> @@ -718,9 +738,10 @@ kick_dll:
>  	dsb
>  	ldr	r4, kick_counter
>  	add	r4, r4, #1
> -	str	r4, kick_counter
> +	str	r4, [r7]		@ kick_counter
>  	b	wait_dll_lock_timed
>  
> +	.align
>  cm_idlest1_core:
>  	.word	CM_IDLEST1_CORE_V
>  cm_idlest_ckgen:
> @@ -763,6 +784,7 @@ kick_counter:
>  	.word	0
>  wait_dll_lock_counter:
>  	.word	0
> +ENDPROC(omap34xx_cpu_suspend)
>  
>  ENTRY(omap34xx_cpu_suspend_sz)
>  	.word	. - omap34xx_cpu_suspend

Re: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Kevin Hilman]

Kevin Hilman <khilman@ti.com> writes:

> Dave Martin <dave.martin@linaro.org> writes:
>
>>  * Use BSYM() to get the correct Thumb branch address
>>    for adr <Rd>, <label>
>>
>>  * Fix an out-of-range ADR when building for ARM
>>
>>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>
>>  * Remove deprecated/undefined PC-relative stores
>>
>>  * Add the required ENDPROC() directive for each ENTRY().
>>
>>  * .align before data words
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>
> I'm attempting to test this series with OMAP PM, but some changes here
> don't compile for me.
>
> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) 
>
> First, I merged your arm/omap-thumb2+merged branch with my pm branch
> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

Sorry for the confusion, this patch should've been in reply to your v4
version, since I merged with your 'arm/omap-thumb2+merged' branch from
today.

Kevin

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Kevin Hilman]

Kevin Hilman <khilman@ti.com> writes:

> Dave Martin <dave.martin@linaro.org> writes:
>
>>  * Use BSYM() to get the correct Thumb branch address
>>    for adr <Rd>, <label>
>>
>>  * Fix an out-of-range ADR when building for ARM
>>
>>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>
>>  * Remove deprecated/undefined PC-relative stores
>>
>>  * Add the required ENDPROC() directive for each ENTRY().
>>
>>  * .align before data words
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>
> I'm attempting to test this series with OMAP PM, but some changes here
> don't compile for me.
>
> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) 
>
> First, I merged your arm/omap-thumb2+merged branch with my pm branch
> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

Sorry for the confusion, this patch should've been in reply to your v4
version, since I merged with your 'arm/omap-thumb2+merged' branch from
today.

Kevin

Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Thu, Feb 10, 2011 at 9:38 PM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> [...]
>
>>>
>>> The SD card gets suspended, but nothing else seems to happen, and I
>>> can't resume the system.
>>>
>>> Am I doing something wrong?
>>>
>> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing
>>
>
> Just to clarify, MMC suspend is not broken.  It's a "feature" the MMC
> core.  See the help text of the following Kconfig option, and ensure
> that it's enabled:
>
>
> config MMC_UNSAFE_RESUME
>        bool "Assume MMC/SD cards are non-removable (DANGEROUS)"
>        help
>          If you say Y here, the MMC layer will assume that all cards
>          stayed in their respective slots during the suspend. The
>          normal behaviour is to remove them at suspend and
>          redetecting them at resume. Breaking this assumption will
>          in most cases result in data corruption.
>
>          This option is usually just for embedded systems which use
>          a MMC/SD card for rootfs. Most people should say N here.
>
>          This option sets a default which can be overridden by the
>          module parameter "removable=0" or "removable=1".
>
> Looking at Dave's .config, this option is disabled, so suspend will hang
> when rootfs is on MMC.

Thanks for the clarification.  For simplicity, and since Thumb-2
should be unrelated to the MMC subsystem, I've been testing suspend
from the initramfs instead ... which sidesteps the MMC issue.

Power-off-suspend does still have some weird problems when
CONFIG_THUMB2_KERNEL is enabled; I'm still investigating this.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes

[Dave Martin]

On Thu, Feb 10, 2011 at 9:38 PM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> [...]
>
>>>
>>> The SD card gets suspended, but nothing else seems to happen, and I
>>> can't resume the system.
>>>
>>> Am I doing something wrong?
>>>
>> MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing
>>
>
> Just to clarify, MMC suspend is not broken. ?It's a "feature" the MMC
> core. ?See the help text of the following Kconfig option, and ensure
> that it's enabled:
>
>
> config MMC_UNSAFE_RESUME
> ? ? ? ?bool "Assume MMC/SD cards are non-removable (DANGEROUS)"
> ? ? ? ?help
> ? ? ? ? ?If you say Y here, the MMC layer will assume that all cards
> ? ? ? ? ?stayed in their respective slots during the suspend. The
> ? ? ? ? ?normal behaviour is to remove them at suspend and
> ? ? ? ? ?redetecting them at resume. Breaking this assumption will
> ? ? ? ? ?in most cases result in data corruption.
>
> ? ? ? ? ?This option is usually just for embedded systems which use
> ? ? ? ? ?a MMC/SD card for rootfs. Most people should say N here.
>
> ? ? ? ? ?This option sets a default which can be overridden by the
> ? ? ? ? ?module parameter "removable=0" or "removable=1".
>
> Looking at Dave's .config, this option is disabled, so suspend will hang
> when rootfs is on MMC.

Thanks for the clarification.  For simplicity, and since Thumb-2
should be unrelated to the MMC subsystem, I've been testing suspend
from the initramfs instead ... which sidesteps the MMC issue.

Power-off-suspend does still have some weird problems when
CONFIG_THUMB2_KERNEL is enabled; I'm still investigating this.

Cheers
---Dave

Re: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Dave Martin]

On Thu, Feb 10, 2011 at 10:17 PM, Kevin Hilman <khilman@ti.com> wrote:
> Dave Martin <dave.martin@linaro.org> writes:
>
>>  * Use BSYM() to get the correct Thumb branch address
>>    for adr <Rd>, <label>
>>
>>  * Fix an out-of-range ADR when building for ARM
>>
>>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>
>>  * Remove deprecated/undefined PC-relative stores
>>
>>  * Add the required ENDPROC() directive for each ENTRY().
>>
>>  * .align before data words
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>
> I'm attempting to test this series with OMAP PM, but some changes here
> don't compile for me.
>
> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>
> First, I merged your arm/omap-thumb2+merged branch with my pm branch
> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
> There were some minor conflicts here, but they looked simple enough and
> I just resolved in favor of your branch.

Thanks for giving it a try.

>
> Trying to build with CONFIG_THUMB2_KERNEL=y, I ran into a compile
> problem...
>
>

[...]

>> +     adr     r0, es3_sdrc_fix        @ Not using BSYM clears the Thumb bit.
>
> This fails to compile:
>
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S: Assembler messages:
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:361: Error: invalid immediate for address calculation (value = 0x00000004)

Unfortunately, this is caused by a bug in the assembler.
arch/arm/kernel/relocate_kernel.S also suffers from the same bug when
built with CONFIG_THUMB2_KERNEL.

If you had got as far a linking, it's likely you would hit a
'reference to discarded section problem' error in the linker, due to
discarding of some sections referenced by SMP_ON_UP fixups.

If you merge the 3 extra patches from dirty/arm/omap-thumb2+merged it
should resolve these issues, but how to fix these things upstream is
still under discussion.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Dave Martin]

On Thu, Feb 10, 2011 at 10:17 PM, Kevin Hilman <khilman@ti.com> wrote:
> Dave Martin <dave.martin@linaro.org> writes:
>
>> ?* Use BSYM() to get the correct Thumb branch address
>> ? ?for adr <Rd>, <label>
>>
>> ?* Fix an out-of-range ADR when building for ARM
>>
>> ?* Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>
>> ?* Remove deprecated/undefined PC-relative stores
>>
>> ?* Add the required ENDPROC() directive for each ENTRY().
>>
>> ?* .align before data words
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>
> I'm attempting to test this series with OMAP PM, but some changes here
> don't compile for me.
>
> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>
> First, I merged your arm/omap-thumb2+merged branch with my pm branch
> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
> There were some minor conflicts here, but they looked simple enough and
> I just resolved in favor of your branch.

Thanks for giving it a try.

>
> Trying to build with CONFIG_THUMB2_KERNEL=y, I ran into a compile
> problem...
>
>

[...]

>> + ? ? adr ? ? r0, es3_sdrc_fix ? ? ? ?@ Not using BSYM clears the Thumb bit.
>
> This fails to compile:
>
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S: Assembler messages:
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:361: Error: invalid immediate for address calculation (value = 0x00000004)

Unfortunately, this is caused by a bug in the assembler.
arch/arm/kernel/relocate_kernel.S also suffers from the same bug when
built with CONFIG_THUMB2_KERNEL.

If you had got as far a linking, it's likely you would hit a
'reference to discarded section problem' error in the linker, due to
discarding of some sections referenced by SMP_ON_UP fixups.

If you merge the 3 extra patches from dirty/arm/omap-thumb2+merged it
should resolve these issues, but how to fix these things upstream is
still under discussion.

Cheers
---Dave

Re: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Dave Martin]

On Fri, Feb 11, 2011 at 12:07 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> Dave Martin <dave.martin@linaro.org> writes:
>>
>>>  * Use BSYM() to get the correct Thumb branch address
>>>    for adr <Rd>, <label>
>>>
>>>  * Fix an out-of-range ADR when building for ARM
>>>
>>>  * Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>>
>>>  * Remove deprecated/undefined PC-relative stores
>>>
>>>  * Add the required ENDPROC() directive for each ENTRY().
>>>
>>>  * .align before data words
>>>
>>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>>
>> I'm attempting to test this series with OMAP PM, but some changes here
>> don't compile for me.
>>
>> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>>
>> First, I merged your arm/omap-thumb2+merged branch with my pm branch
>> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
> Sorry for the confusion, this patch should've been in reply to your v4
> version, since I merged with your 'arm/omap-thumb2+merged' branch from
> today.

If you are able to test off mode with CONFIG_THUMB2_KERNEL enabled,
that would be great.

I have some evidence that the resume path may be working in Thumb-2,
but I think I'm being bitten by erratum i583 (I have to disable the
workaround to even attempt to test off mode on Beagle xM)

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S

[Dave Martin]

On Fri, Feb 11, 2011 at 12:07 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> Dave Martin <dave.martin@linaro.org> writes:
>>
>>> ?* Use BSYM() to get the correct Thumb branch address
>>> ? ?for adr <Rd>, <label>
>>>
>>> ?* Fix an out-of-range ADR when building for ARM
>>>
>>> ?* Correctly call es3_sdrc_fix as Thumb when copied to SRAM.
>>>
>>> ?* Remove deprecated/undefined PC-relative stores
>>>
>>> ?* Add the required ENDPROC() directive for each ENTRY().
>>>
>>> ?* .align before data words
>>>
>>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>>
>> I'm attempting to test this series with OMAP PM, but some changes here
>> don't compile for me.
>>
>> My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50)
>>
>> First, I merged your arm/omap-thumb2+merged branch with my pm branch
>> from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
> Sorry for the confusion, this patch should've been in reply to your v4
> version, since I merged with your 'arm/omap-thumb2+merged' branch from
> today.

If you are able to test off mode with CONFIG_THUMB2_KERNEL enabled,
that would be great.

I have some evidence that the resume path may be working in Thumb-2,
but I think I'm being bitten by erratum i583 (I have to disable the
workaround to even attempt to test off mode on Beagle xM)

Cheers
---Dave