[PATCH v4 0/2] ARM: PJ4B: fix for 3.10-rc

[PATCH v4 0/2] ARM: PJ4B: fix for 3.10-rc

[Gregory CLEMENT]

Hello,

This path set allows to fix one errata for PJ4B CPUs.

Without this the Armada 370 based board can't boot anymore since
3.10-rc1. So this one really need to be applied on 3.10-rc.

As they were pending question for the second one, I preferred to keep
it apart awaiting the answers from the Marvell engineer.

Both of the patches of this series are needed to fix the issue. Indeed
if the CPU is not recognized as a PJ4B then the fix is not applied.

Thanks,

Changelog:
V1 -> V2;
 - Fixed various coding style and typo issues
 - Replaced the "mcr p15, 0, r0, c7, c10, 4" by  "dsb"

V2 -> v3:
 - As suggested by Russell, the first errata is now applied
   dynamically according to the processor type

v3->4
 - Moved the glob_equ maco into proc-macro.S
 - Split the patch in 2 parts, one for fixing the ID and mask of the
   PJ4B and the second for fixing the errata itself

Gregory CLEMENT (2):
  ARM: PJ4B: Fix the CPU ID and the mask associated to the PJ4B
  ARM PJ4B: Add support for errata 4742

 arch/arm/Kconfig                 | 13 +++++++++++++
 arch/arm/include/asm/glue-proc.h |  9 +++++++++
 arch/arm/mm/proc-macros.S        |  5 +++++
 arch/arm/mm/proc-v7.S            | 34 +++++++++++++++++++++++++++++-----
 4 files changed, 56 insertions(+), 5 deletions(-)

-- 
1.8.1.2

[PATCH v4 1/2] ARM: PJ4B: Fix the CPU ID and the mask associated to the PJ4B

[Gregory CLEMENT]

This commit fixes the ID and mask for the PJ4B which was too
restrictive and didn't match the CPU of the Armada 370 SoC.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/mm/proc-v7.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 2c73a73..fe3a9d3 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -409,8 +409,8 @@ __v7_ca9mp_proc_info:
 	 */
 	.type   __v7_pj4b_proc_info, #object
 __v7_pj4b_proc_info:
-	.long	0x562f5840
-	.long	0xfffffff0
+	.long   0x560f5800
+	.long	0xff0fff00
 	__v7_proc __v7_pj4b_setup
 	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
 
-- 
1.8.1.2

[PATCH v4 2/2] ARM PJ4B: Add support for errata 4742

[Gregory CLEMENT]

This commit fixes the regression on Armada 370 (the kernal hang during
boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".

When coming out of either a Wait for Interrupt (WFI) or a Wait for
Event (WFE) IDLE states, a specific timing sensitivity exists between
the retiring WFI/WFE instructions and the newly issued subsequent
instructions. This sensitivity can result in a CPU hang scenario.  The
workaround is to insert either a Data Synchronization Barrier (DSB) or
Data Memory Barrier (DMB) command immediately after the WFI/WFE
instruction.

This commit was based on the work of Lior Amsalem, but heavily
modified to apply the errata fix dynamically according to the
processor type thanks to the suggestions of Russell King and Nicolas
Pitre.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/Kconfig                 | 13 +++++++++++++
 arch/arm/include/asm/glue-proc.h |  9 +++++++++
 arch/arm/mm/proc-macros.S        |  5 +++++
 arch/arm/mm/proc-v7.S            | 30 +++++++++++++++++++++++++++---
 4 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49d993c..95cbe9d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1087,6 +1087,19 @@ if !MMU
 source "arch/arm/Kconfig-nommu"
 endif
 
+config PJ4B_ERRATA_4742
+	bool "PJ4B Errata 4742: IDLE Wake Up Commands can Cause the CPU Core to Cease Operation"
+	depends on CPU_PJ4B && MACH_ARMADA_370
+	help
+	  When coming out of either a Wait for Interrupt (WFI) or a Wait for
+	  Event (WFE) IDLE states, a specific timing sensitivity exists between
+	  the retiring WFI/WFE instructions and the newly issued subsequent
+	  instructions.  This sensitivity can result in a CPU hang scenario.
+	  Workaround:
+	  The software must insert either a Data Synchronization Barrier (DSB)
+	  or Data Memory Barrier (DMB) command immediately after the WFI/WFE
+	  instruction
+
 config ARM_ERRATA_326103
 	bool "ARM errata: FSR write bit incorrect on a SWP to read-only memory"
 	depends on CPU_V6
diff --git a/arch/arm/include/asm/glue-proc.h b/arch/arm/include/asm/glue-proc.h
index ac1dd54..8017e94 100644
--- a/arch/arm/include/asm/glue-proc.h
+++ b/arch/arm/include/asm/glue-proc.h
@@ -230,6 +230,15 @@
 # endif
 #endif
 
+#ifdef CONFIG_CPU_PJ4B
+# ifdef CPU_NAME
+#  undef  MULTI_CPU
+#  define MULTI_CPU
+# else
+#  define CPU_NAME cpu_pj4b
+# endif
+#endif
+
 #ifndef MULTI_CPU
 #define cpu_proc_init			__glue(CPU_NAME,_proc_init)
 #define cpu_proc_fin			__glue(CPU_NAME,_proc_fin)
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index f9a0aa7..e3c48a3 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -333,3 +333,8 @@ ENTRY(\name\()_tlb_fns)
 	.endif
 	.size	\name\()_tlb_fns, . - \name\()_tlb_fns
 .endm
+
+.macro globl_equ x, y
+	.globl	\x
+	.equ	\x, \y
+.endm
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index fe3a9d3..95d463e 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -342,6 +342,29 @@ __v7_setup:
 	mov	pc, lr				@ return to head.S:__ret
 ENDPROC(__v7_setup)
 
+#ifdef CONFIG_CPU_PJ4B
+	globl_equ	cpu_pj4b_switch_mm,     cpu_v7_switch_mm
+	globl_equ	cpu_pj4b_set_pte_ext,	cpu_v7_set_pte_ext
+	globl_equ	cpu_pj4b_proc_init,	cpu_v7_proc_init
+	globl_equ	cpu_pj4b_proc_fin, 	cpu_v7_proc_fin
+	globl_equ	cpu_pj4b_reset,	   	cpu_v7_reset
+#ifdef CONFIG_PJ4B_ERRATA_4742
+ENTRY(cpu_pj4b_do_idle)
+	dsb					@ WFI may enter a low-power mode
+	wfi
+	dsb					@barrier
+	mov	pc, lr
+ENDPROC(cpu_pj4b_do_idle)
+#else
+	globl_equ	cpu_pj4b_do_idle,  	cpu_v7_do_idle
+#endif
+	globl_equ	cpu_pj4b_dcache_clean_area,	cpu_v7_dcache_clean_area
+	globl_equ	cpu_pj4b_do_suspend,	cpu_v7_do_suspend
+	globl_equ	cpu_pj4b_do_resume,	cpu_v7_do_resume
+	globl_equ	cpu_pj4b_suspend_size,	cpu_v7_suspend_size
+
+#endif
+
 	.align	2
 __v7_setup_stack:
 	.space	4 * 11				@ 11 registers
@@ -350,6 +373,7 @@ __v7_setup_stack:
 
 	@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
 	define_processor_functions v7, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
+	define_processor_functions pj4b, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
 
 	.section ".rodata"
 
@@ -362,7 +386,7 @@ __v7_setup_stack:
 	/*
 	 * Standard v7 proc info content
 	 */
-.macro __v7_proc initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0
+.macro __v7_proc initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions
 	ALT_SMP(.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
 			PMD_SECT_AF | PMD_FLAGS_SMP | \mm_mmuflags)
 	ALT_UP(.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
@@ -375,7 +399,7 @@ __v7_setup_stack:
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_FAST_MULT | \
 		HWCAP_EDSP | HWCAP_TLS | \hwcaps
 	.long	cpu_v7_name
-	.long	v7_processor_functions
+	.long	\proc_fns
 	.long	v7wbi_tlb_fns
 	.long	v6_user_fns
 	.long	v7_cache_fns
@@ -411,7 +435,7 @@ __v7_ca9mp_proc_info:
 __v7_pj4b_proc_info:
 	.long   0x560f5800
 	.long	0xff0fff00
-	__v7_proc __v7_pj4b_setup
+	__v7_proc __v7_pj4b_setup, proc_fns = pj4b_processor_functions
 	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
 
 	/*
-- 
1.8.1.2

[PATCH v4 2/2] ARM PJ4B: Add support for errata 4742

[Nicolas Pitre]

On Fri, 7 Jun 2013, Gregory CLEMENT wrote:

> This commit fixes the regression on Armada 370 (the kernal hang during
> boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
> TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".
> 
> When coming out of either a Wait for Interrupt (WFI) or a Wait for
> Event (WFE) IDLE states, a specific timing sensitivity exists between
> the retiring WFI/WFE instructions and the newly issued subsequent
> instructions. This sensitivity can result in a CPU hang scenario.  The
> workaround is to insert either a Data Synchronization Barrier (DSB) or
> Data Memory Barrier (DMB) command immediately after the WFI/WFE
> instruction.
> 
> This commit was based on the work of Lior Amsalem, but heavily
> modified to apply the errata fix dynamically according to the
> processor type thanks to the suggestions of Russell King and Nicolas
> Pitre.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Acked-by: Nicolas Pitre <nico@linaro.org>

> ---
>  arch/arm/Kconfig                 | 13 +++++++++++++
>  arch/arm/include/asm/glue-proc.h |  9 +++++++++
>  arch/arm/mm/proc-macros.S        |  5 +++++
>  arch/arm/mm/proc-v7.S            | 30 +++++++++++++++++++++++++++---
>  4 files changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 49d993c..95cbe9d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1087,6 +1087,19 @@ if !MMU
>  source "arch/arm/Kconfig-nommu"
>  endif
>  
> +config PJ4B_ERRATA_4742
> +	bool "PJ4B Errata 4742: IDLE Wake Up Commands can Cause the CPU Core to Cease Operation"
> +	depends on CPU_PJ4B && MACH_ARMADA_370
> +	help
> +	  When coming out of either a Wait for Interrupt (WFI) or a Wait for
> +	  Event (WFE) IDLE states, a specific timing sensitivity exists between
> +	  the retiring WFI/WFE instructions and the newly issued subsequent
> +	  instructions.  This sensitivity can result in a CPU hang scenario.
> +	  Workaround:
> +	  The software must insert either a Data Synchronization Barrier (DSB)
> +	  or Data Memory Barrier (DMB) command immediately after the WFI/WFE
> +	  instruction
> +
>  config ARM_ERRATA_326103
>  	bool "ARM errata: FSR write bit incorrect on a SWP to read-only memory"
>  	depends on CPU_V6
> diff --git a/arch/arm/include/asm/glue-proc.h b/arch/arm/include/asm/glue-proc.h
> index ac1dd54..8017e94 100644
> --- a/arch/arm/include/asm/glue-proc.h
> +++ b/arch/arm/include/asm/glue-proc.h
> @@ -230,6 +230,15 @@
>  # endif
>  #endif
>  
> +#ifdef CONFIG_CPU_PJ4B
> +# ifdef CPU_NAME
> +#  undef  MULTI_CPU
> +#  define MULTI_CPU
> +# else
> +#  define CPU_NAME cpu_pj4b
> +# endif
> +#endif
> +
>  #ifndef MULTI_CPU
>  #define cpu_proc_init			__glue(CPU_NAME,_proc_init)
>  #define cpu_proc_fin			__glue(CPU_NAME,_proc_fin)
> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> index f9a0aa7..e3c48a3 100644
> --- a/arch/arm/mm/proc-macros.S
> +++ b/arch/arm/mm/proc-macros.S
> @@ -333,3 +333,8 @@ ENTRY(\name\()_tlb_fns)
>  	.endif
>  	.size	\name\()_tlb_fns, . - \name\()_tlb_fns
>  .endm
> +
> +.macro globl_equ x, y
> +	.globl	\x
> +	.equ	\x, \y
> +.endm
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index fe3a9d3..95d463e 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -342,6 +342,29 @@ __v7_setup:
>  	mov	pc, lr				@ return to head.S:__ret
>  ENDPROC(__v7_setup)
>  
> +#ifdef CONFIG_CPU_PJ4B
> +	globl_equ	cpu_pj4b_switch_mm,     cpu_v7_switch_mm
> +	globl_equ	cpu_pj4b_set_pte_ext,	cpu_v7_set_pte_ext
> +	globl_equ	cpu_pj4b_proc_init,	cpu_v7_proc_init
> +	globl_equ	cpu_pj4b_proc_fin, 	cpu_v7_proc_fin
> +	globl_equ	cpu_pj4b_reset,	   	cpu_v7_reset
> +#ifdef CONFIG_PJ4B_ERRATA_4742
> +ENTRY(cpu_pj4b_do_idle)
> +	dsb					@ WFI may enter a low-power mode
> +	wfi
> +	dsb					@barrier
> +	mov	pc, lr
> +ENDPROC(cpu_pj4b_do_idle)
> +#else
> +	globl_equ	cpu_pj4b_do_idle,  	cpu_v7_do_idle
> +#endif
> +	globl_equ	cpu_pj4b_dcache_clean_area,	cpu_v7_dcache_clean_area
> +	globl_equ	cpu_pj4b_do_suspend,	cpu_v7_do_suspend
> +	globl_equ	cpu_pj4b_do_resume,	cpu_v7_do_resume
> +	globl_equ	cpu_pj4b_suspend_size,	cpu_v7_suspend_size
> +
> +#endif
> +
>  	.align	2
>  __v7_setup_stack:
>  	.space	4 * 11				@ 11 registers
> @@ -350,6 +373,7 @@ __v7_setup_stack:
>  
>  	@ define struct processor (see <asm/proc-fns.h> and proc-macros.S)
>  	define_processor_functions v7, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
> +	define_processor_functions pj4b, dabort=v7_early_abort, pabort=v7_pabort, suspend=1
>  
>  	.section ".rodata"
>  
> @@ -362,7 +386,7 @@ __v7_setup_stack:
>  	/*
>  	 * Standard v7 proc info content
>  	 */
> -.macro __v7_proc initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0
> +.macro __v7_proc initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions
>  	ALT_SMP(.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
>  			PMD_SECT_AF | PMD_FLAGS_SMP | \mm_mmuflags)
>  	ALT_UP(.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
> @@ -375,7 +399,7 @@ __v7_setup_stack:
>  	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_FAST_MULT | \
>  		HWCAP_EDSP | HWCAP_TLS | \hwcaps
>  	.long	cpu_v7_name
> -	.long	v7_processor_functions
> +	.long	\proc_fns
>  	.long	v7wbi_tlb_fns
>  	.long	v6_user_fns
>  	.long	v7_cache_fns
> @@ -411,7 +435,7 @@ __v7_ca9mp_proc_info:
>  __v7_pj4b_proc_info:
>  	.long   0x560f5800
>  	.long	0xff0fff00
> -	__v7_proc __v7_pj4b_setup
> +	__v7_proc __v7_pj4b_setup, proc_fns = pj4b_processor_functions
>  	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
>  
>  	/*
> -- 
> 1.8.1.2
> 

[PATCH v4 2/2] ARM PJ4B: Add support for errata 4742

[Russell King - ARM Linux]

On Fri, Jun 07, 2013 at 10:09:09PM -0400, Nicolas Pitre wrote:
> On Fri, 7 Jun 2013, Gregory CLEMENT wrote:
> 
> > This commit fixes the regression on Armada 370 (the kernal hang during
> > boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
> > TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".
> > 
> > When coming out of either a Wait for Interrupt (WFI) or a Wait for
> > Event (WFE) IDLE states, a specific timing sensitivity exists between
> > the retiring WFI/WFE instructions and the newly issued subsequent
> > instructions. This sensitivity can result in a CPU hang scenario.  The
> > workaround is to insert either a Data Synchronization Barrier (DSB) or
> > Data Memory Barrier (DMB) command immediately after the WFI/WFE
> > instruction.
> > 
> > This commit was based on the work of Lior Amsalem, but heavily
> > modified to apply the errata fix dynamically according to the
> > processor type thanks to the suggestions of Russell King and Nicolas
> > Pitre.
> > 
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> 
> Acked-by: Nicolas Pitre <nico@linaro.org>

Dropped-by: Me.  This causes build regression on anything using ARMv7 CPUs.

Doing this kind of thing conditionally is only of any use if you ensure
that _all_ the places you are using the new symbols you conditionally
define are also appropriately conditionalised, which in this patch they
aren't.

[PATCH v4 0/2] ARM: PJ4B: fix for 3.10-rc

[Will Deacon]

On Fri, Jun 07, 2013 at 11:04:18AM +0100, Gregory CLEMENT wrote:
> Hello,
> 
> This path set allows to fix one errata for PJ4B CPUs.
> 
> Without this the Armada 370 based board can't boot anymore since
> 3.10-rc1. So this one really need to be applied on 3.10-rc.
> 
> As they were pending question for the second one, I preferred to keep
> it apart awaiting the answers from the Marvell engineer.
> 
> Both of the patches of this series are needed to fix the issue. Indeed
> if the CPU is not recognized as a PJ4B then the fix is not applied.

Reviewed-by: Will Deacon <will.deacon@arm.com>

Does this need a CC stable as well? I know that my TLB patch tickled it, but
that's not to say it couldn't occur with particular configurations of older
kernels.

Will

[PATCH v4 0/2] ARM: PJ4B: fix for 3.10-rc

[Gregory CLEMENT]

On 06/07/2013 12:12 PM, Will Deacon wrote:
> On Fri, Jun 07, 2013 at 11:04:18AM +0100, Gregory CLEMENT wrote:
>> Hello,
>>
>> This path set allows to fix one errata for PJ4B CPUs.
>>
>> Without this the Armada 370 based board can't boot anymore since
>> 3.10-rc1. So this one really need to be applied on 3.10-rc.
>>
>> As they were pending question for the second one, I preferred to keep
>> it apart awaiting the answers from the Marvell engineer.
>>
>> Both of the patches of this series are needed to fix the issue. Indeed
>> if the CPU is not recognized as a PJ4B then the fix is not applied.
> 
> Reviewed-by: Will Deacon <will.deacon@arm.com>
> 

Thanks for your review.

> Does this need a CC stable as well? I know that my TLB patch tickled it, but
> that's not to say it couldn't occur with particular configurations of older
> kernels.

Well according to stable_kernel_rules.txt " It must fix a real bug
that bothers people (not a, "This could be a problem..." type thing)."

So I am not sure that it should go to stable. But it is arguable.
Then I will add the Cc: <stable@vger.kernel.org> flag to the patches
when I will submit them to Russell pacth system.

Gregory