ARM: omap[34]: Thumb-2 compatibility fixes
Subsystems (3)
v5 cover 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.
At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome.
In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so.
* ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL
* ARM: omap3: Thumb-2 compatibility for sram34xx.S
* ARM: omap3: Thumb-2 compatibility for sleep34xx.S
Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled on Beagle xM A2 and Panda A1.
Thanks also to Santosh Shilimkar and Kevin Hilman for their help with testing so far.
v3:
* make SMC instruction syntax more consistent
* remove do_wfi() in favour of the generic wfi() macro
v4:
* revert to the OMAP-specific do_wfi() implementation, pending discussion of how generic macros can/should be provided
v5:
* use ARM for low-level code in mach-omap2/*34xx.S, for correct interoperation with non-Thumb-capable firmware.
I've stripped the Acked/Tested-bys from the major patches to mach-omap2/*34xx.S, since the reversion to ARM constitutes a significant change -- I would be grateful if people could re- test / re-review if they have the chance.
For best future compatibility, I've left the changes which avoid architecturally deprecated features.
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=y (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
This series also depends on one un-merged patch to generic-ise the wfi() macro:
git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro
Dave Martin (5):
ARM: omap4: Provide do_wfi() for Thumb-2
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 | 4 ++ arch/arm/mach-omap2/omap-headsmp.S | 2 +- arch/arm/mach-omap2/omap44xx-smc.S | 8 ++-- arch/arm/mach-omap2/sleep34xx.S | 62 ++++++++++++++++++---- arch/arm/mach-omap2/sram34xx.S | 36 ++++++++++--- 5 files changed, 87 insertions(+), 25 deletions(-)
PATCH v5 1/5 ARM: omap4: Provide do_wfi() for Thumb-2
For CONFIG_THUMB2_KERNEL, the existing definition of do_wfi() will insert invalid code into the instruction stream.
Any assembler which can assemble Thumb-2 is guaranteed to accept the "wfi" mnemonic, so for the Thumb-2 case, just use the mnemonic.
The ARM case is left as-is.
--- arch/arm/mach-omap2/include/mach/omap4-common.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/include/mach/omap4-common.h +4 -0
@@ -17,8 +17,12 @@* 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;
Signature · 1 line
1.7.1
PATCH v5 2/5 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL
In reply to Dave MartinCode 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.
--- arch/arm/mach-omap2/omap-headsmp.S | 2 +- arch/arm/mach-omap2/omap44xx-smc.S | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/omap-headsmp.S +1 -1
@@ -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)
arch/arm/mach-omap2/omap44xx-smc.S +4 -4
@@ -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)
Signature · 1 line
1.7.1
PATCH v5 3/5 ARM: omap3: Remove hand-encoded SMC instructions
In reply to Dave MartinFor 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).
--- arch/arm/mach-omap2/sleep34xx.S | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-)
arch/arm/mach-omap2/sleep34xx.S +7 -7
@@ -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
Signature · 1 line
1.7.1
PATCH v5 4/5 ARM: omap3: Thumb-2 compatibility for sram34xx.S
In reply to Dave Martin* Build unconditionally as ARM for correct interoperation with OMAP firmware.
* Remove deprecated PC-relative stores
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words
--- arch/arm/mach-omap2/sram34xx.S | 36 ++++++++++++++++++++++++++++-------- 1 files changed, 28 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/sram34xx.S +28 -8
@@ -34,6 +34,12 @@ #include "sdrc.h" #include "cm2xxx_3xxx.h" +/* + * This file needs be built unconditionally as ARM to interoperate correctly + * with non-Thumb-2-capable firmware. + */ + .arm + .text /* r1 parameters */
@@ -116,24 +122,36 @@ ENTRY(omap3_sram_configure_core_dpll) @ pull the extra args off the stack @ and store them in SRAM + +/* + * PC-relative stores are deprecated in ARMv7 and 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 +289,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 +338,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
Signature · 1 line
1.7.1
PATCH v5 5/5 ARM: omap3: Thumb-2 compatibility for sleep34xx.S
In reply to Dave Martin* Build unconditionally as ARM for correct interoperation with OMAP firmware.
* Fix an out-of-range ADR when building for ARM.
* Remove deprecated PC-relative stores.
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words.
* Handle non-interworking return from v7_flush_dcache_all.
--- arch/arm/mach-omap2/sleep34xx.S | 48 ++++++++++++++++++++++++++++++++++---- 1 files changed, 43 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/sleep34xx.S +43 -5
@@ -64,6 +64,11 @@ #define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) +/* + * This file needs be built unconditionally as ARM to interoperate correctly + * with non-Thumb-2-capable firmware. + */ + .arm /* * API functions
@@ -82,6 +87,8 @@ ENTRY(get_restore_pointer) stmfd sp!, {lr} @ save registers on stack adr r0, restore ldmfd sp!, {pc} @ restore regs and return +ENDPROC(get_restore_pointer) + .align ENTRY(get_restore_pointer_sz) .word . - get_restore_pointer
@@ -91,6 +98,8 @@ ENTRY(get_omap3630_restore_pointer) stmfd sp!, {lr} @ save registers on stack adr r0, 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
@@ -100,6 +109,8 @@ ENTRY(get_es3_restore_pointer) stmfd sp!, {lr} @ save registers on stack adr r0, 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 +124,10 @@ 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 + adrl r2, l2dis_3630 @ may be too distant for plain adr + 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 +152,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 +294,18 @@ clean_l2: * - 'might' have to copy address, load and jump to it */ ldr r1, kernel_flush - mov lr, pc - bx r1 + blx r1 + /* + * The kernel doesn't interwork: v7_flush_dcache_all in particluar will + * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. + * This sequence switches back to ARM. Note that .align may insert a + * nop: bx pc needs to be word-aligned in order to work. + */ + THUMB( .thumb ) + THUMB( .align ) + THUMB( bx pc ) + THUMB( nop ) + .arm omap3_do_wfi: ldr r4, sdrc_power @ read the SDRC_POWER register
@@ -438,6 +463,7 @@ skipl2dis: #endif b logic_l1_restore + .align l2_inv_api_params: .word 0x1, 0x00 l2_inv_gp:
@@ -607,6 +633,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 +661,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 +676,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 +711,12 @@ 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 +724,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 +754,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 +800,7 @@ kick_counter: .word 0 wait_dll_lock_counter: .word 0 +ENDPROC(omap34xx_cpu_suspend) ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend
Signature · 1 line
1.7.1
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
In reply to Dave MartinQuoted 11 lines · 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.
At least some of this code definitely works, most features have been tested successfully. ?Further testing, especially of Thumb-2 behaviour, is still welcome.
Quoted 7 lines
In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so.
?* ARM: omap3: Convert
END()toENDPROC()for correct linkage withCONFIG_THUMB2_KERNEL?* ARM: omap3: Thumb-2 compatibility forsram34xx.S
?* ARM: omap3: Thumb-2 compatibility forsleep34xx.S
Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ...
The one patch I currently have no feedback on is this one:
* ARM: omap4: Provide do_wfi() for Thumb-2
Cheers
---Dave
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
Dave,
Quoted 32 lines
-----Original Message-----
From: Dave Martin [mailto:dave.martin at linaro.org]
Sent: Friday, March 04, 2011 11:05 PM
To: linux-arm-kernel at lists.infradead.org
Cc: patches at linaro.org; Tony Lindgren; Santosh Shilimkar; Jean Pihet; Kevin Hilman; linux-omap at vger.kernel.org; Nicolas Pitre; linaro-dev at lists.linaro.org
Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixesQuoted 11 lines · 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.
At least some of this code definitely works, most features have been tested successfully. ?Further testing, especially of Thumb-2 behaviour, is still welcome.
Quoted 5 lines
In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so.
?* ARM: omap3: Convert
END()toENDPROC()for correct linkage with
CONFIG_THUMB2_KERNELQuoted 2 lines
?* ARM: omap3: Thumb-2 compatibility for
sram34xx.S?* ARM: omap3: Thumb-2 compatibility forsleep34xx.S
Quoted 8 lines
Following up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...The one patch I currently have no feedback on is this one:
* ARM: omap4: Provide
do_wfi()for Thumb-2
You can drop this one since do_wfi() won't be needed anymore after my recent series.
Tony Lindgren
maintainerv5 cover ARM: omap[34]: Thumb-2 compatibility fixes
Quoted 4 lines · Santosh Shilimkar
Quoted 4 lines
Following up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...
To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code.
Or if Kevin wants to take the series, here's my ack for the series:
Regards,
Tony
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
Quoted 6 lines · Tony Lindgren
Quoted 4 lines · Santosh Shilimkar
Quoted 4 lines
Following up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...
Quoted 6 lines
To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code.
Or if Kevin wants to take the series, here's my ack for the series:
Acked-by Tony Lindgren <[email protected]>
Thanks -- I'll wait for Kevin to comment also.
Cheers
---Dave
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
Quoted 7 lines · Dave Martin
Quoted 6 lines · Tony Lindgren
Quoted 4 lines · Santosh Shilimkar
Quoted 4 lines
Following up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...
Quoted 6 lines
Quoted 6 lines
To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code.
Or if Kevin wants to take the series, here's my ack for the series:
Acked-by Tony Lindgren <[email protected]>
Yeah, I'll queue this series.
Quoted 1 line
Thanks -- I'll wait for Kevin to comment also.
I have to give one more round of sanity testing to this series, but otherwise I have no outstanding issues. I also need to coordinate with Santosh on this because he has an additional cleanup series that touches the same code.
Dave, just to confirm something The outstanding toolchain bugs only affect compiling in Thumb-2 mode, right? IOW, if I merge just this series (without having the other toolchain workaround patches) we should still be able to compile/run fine in ARM mode, correct?
Kevin
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
Quoted 4 lines · Kevin Hilman
Dave, just to confirm something The outstanding toolchain bugs only affect compiling in Thumb-2 mode, right? IOW, if I merge just this series (without having the other toolchain workaround patches) we should still be able to compile/run fine in ARM mode, correct?
Correct.
Nicolas
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
In reply to Kevin HilmanQuoted 25 lines · Kevin Hilman
Quoted 7 lines · Dave Martin
Quoted 6 lines · Tony Lindgren
Quoted 4 lines · Santosh Shilimkar
Quoted 4 lines
Following up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...Quoted 6 lines
Quoted 6 lines
To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code.
Or if Kevin wants to take the series, here's my ack for the series:
Acked-by Tony Lindgren <[email protected]>Yeah, I'll queue this series.
Quoted 1 line
Thanks -- I'll wait for Kevin to comment also.
I have to give one more round of sanity testing to this series, but otherwise I have no outstanding issues. ?I also need to coordinate with Santosh on this because he has an additional cleanup series that touches the same code.
Quoted 4 lines
Dave, just to confirm something The outstanding toolchain bugs only affect compiling in Thumb-2 mode, right? ?IOW, if I merge just this series (without having the other toolchain workaround patches) we should still be able to compile/run fine in ARM mode, correct?
Yes, that's right.
Cheers
---Dave
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
In reply to Santosh ShilimkarQuoted 37 lines · Santosh Shilimkar
Dave,
Quoted 36 lines
-----Original Message-----
From: Dave Martin [mailto:dave.martin at linaro.org]
Sent: Friday, March 04, 2011 11:05 PM
To: linux-arm-kernel at lists.infradead.org
Cc: patches at linaro.org; Tony Lindgren; Santosh Shilimkar; Jean Pihet; Kevin Hilman; linux-omap at vger.kernel.org; Nicolas Pitre; linaro-dev at lists.linaro.org
Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixesQuoted 11 lines · 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.
At least some of this code definitely works, most features have been tested successfully. ?Further testing, especially of Thumb-2 behaviour, is still welcome.
Quoted 5 lines
In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so.
?* ARM: omap3: Convert
END()toENDPROC()for correct linkage with
CONFIG_THUMB2_KERNELQuoted 2 lines
?* ARM: omap3: Thumb-2 compatibility for
sram34xx.S?* ARM: omap3: Thumb-2 compatibility forsleep34xx.SFollowing up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...
Quoted 8 lines
Quoted 4 lines
The one patch I currently have no feedback on is this one:
* ARM: omap4: Provide
do_wfi()for Thumb-2You can drop this one since
do_wfi()won't be needed anymore after my recent series.
Santosh,
I'm planning to queue/merge Dave's series as-is for 2.6.39, since it has already received significan review & testing.
When you update your OMAP4 series, feel free to drop it as needed.
Kevin
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
Quoted 62 lines
-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Tuesday, March 08, 2011 3:05 AM
To: Santosh Shilimkar
Cc: Dave Martin; linux-arm-kernel at lists.infradead.org; patches at linaro.org; Tony Lindgren; Jean Pihet-XID; linux- omap at vger.kernel.org; Nicolas Pitre; linaro-dev at lists.linaro.org
Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixesQuoted 12 lines · Santosh Shilimkar
Dave,
Quoted 11 lines
-----Original Message-----
From: Dave Martin [mailto:dave.martin at linaro.org]
Sent: Friday, March 04, 2011 11:05 PM
To: linux-arm-kernel at lists.infradead.org
Cc: patches at linaro.org; Tony Lindgren; Santosh Shilimkar; Jean Pihet; Kevin Hilman; linux-omap at vger.kernel.org; Nicolas Pitre; linaro-dev at lists.linaro.org
Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixesOn Fri, Mar 4, 2011 at 3:33 PM, Dave Martin
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines · wrote:
This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to
be
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
built with
CONFIG_THUMB2_KERNEL.This patch set builds on recent cleanup done by the omap maintainers.
At least some of this code definitely works, most features have been tested successfully. ?Further testing, especially of
Thumb-2
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
behaviour, is still welcome.
In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so.
?* ARM: omap3: Convert
END()toENDPROC()for correct linkagewith
Quoted 8 lines
Quoted 8 lines
CONFIG_THUMB2_KERNELQuoted 2 lines
?* ARM: omap3: Thumb-2 compatibility for
sram34xx.S?* ARM: omap3: Thumb-2 compatibility forsleep34xx.SFollowing up on this, it looks like I have some locally-recorded acks
which didn't make it into my posting ...Quoted 8 lines
Quoted 4 lines
The one patch I currently have no feedback on is this one:
* ARM: omap4: Provide
do_wfi()for Thumb-2You can drop this one since
do_wfi()won't be needed anymore after my recent series.
Quoted 8 lines
Santosh,
I'm planning to queue/merge Dave's series as-is for 2.6.39, since it has
already received significan review & testing.When you update your OMAP4 series, feel free to drop it as needed.
Fine with me.
Regards,
Santosh
v5 cover ARM: omap[34]: Thumb-2 compatibility fixes
In reply to Dave MartinQuoted 11 lines · 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.
At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome.
Quoted 7 lines
In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so.
* ARM: omap3: Convert
END()toENDPROC()for correct linkage withCONFIG_THUMB2_KERNEL
* ARM: omap3: Thumb-2 compatibility forsram34xx.S
* ARM: omap3: Thumb-2 compatibility forsleep34xx.S
Jean Pihet and I have now done both retention and off-mode testing of these, so I'll add a Tested-by for the last two for Jean and queue these for 2.6.39 in my PM queue
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_2.6.39/pm-misc
If you want to do sanity checking with all the other OMAP PM stuff that is queued for 2.6.39, feel free to test with my pm-core branch in the tree above. This has all OMAP PM related changes that will be queued for 2.6.39 integrated.
FWIW, I also tested on 3430/n900 (retention and off-mode) and 3630/Zoom3 (retention-only, since the Si rev have has off-mode errata.)
Kevin
Quoted 84 lines
Seems to work with
CONFIG_SMP_ON_UPandCONFIG_THUMB2_KERNELenabled on Beagle xM A2 and Panda A1.Thanks also to Santosh Shilimkar and Kevin Hilman for their help with testing so far.
v3:
* make SMC instruction syntax more consistent
* removedo_wfi()in favour of the genericwfi()macrov4:
* revert to the OMAP-specificdo_wfi()implementation, pending discussion of how generic macros can/should be providedv5:
* use ARM for low-level code inmach-omap2/*34xx.S, for correct interoperation with non-Thumb-capable firmware.I've stripped the Acked/Tested-bys from the major patches to
mach-omap2/*34xx.S, since the reversion to ARM constitutes a significant change -- I would be grateful if people could re- test / re-review if they have the chance.For best future compatibility, I've left the changes which avoid architecturally deprecated features.
Details below.
Cheers,
DaveThe 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=y(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.gitomap-testingThis series also depends on one un-merged patch to generic-ise the
wfi()macro:
git://git.linaro.org/people/dmart/linux-2.6-arm.gitarm/wfi-macroDave Martin (5):
ARM: omap4: Providedo_wfi()for Thumb-2
ARM: omap4: ConvertEND()toENDPROC()for correct linkage with
CONFIG_THUMB2_KERNEL
ARM: omap3: Remove hand-encoded SMC instructions
ARM: omap3: Thumb-2 compatibility forsram34xx.S
ARM: omap3: Thumb-2 compatibility forsleep34xx.Sarch/arm/mach-omap2/include/mach/omap4-common.h | 4 ++ arch/arm/mach-omap2/omap-headsmp.S | 2 +- arch/arm/mach-omap2/omap44xx-smc.S | 8 ++-- arch/arm/mach-omap2/sleep34xx.S | 62 ++++++++++++++++++---- arch/arm/mach-omap2/sram34xx.S | 36 ++++++++++--- 5 files changed, 87 insertions(+), 25 deletions(-)