ARM: iwmmxt/pj4 fixes for v7/Thumb-2

Because gcc/gas have no sane way to turn on individual CPU extensions from the command-line, iwmmxt.S was previously built with -mcpu=iwmmxt. Unfortunately, this also downgrades the CPU to v5, with the result that this file fails to build for a Thumb-2 kernel.

New versions of the tools support -march=<base arch>+iwmmxt, and it seems reasonable to require up-to-date tools when building in Thumb-2. So, this patch uses -march=armv7-a+iwmmxt for CONFIG_THUMB2_KERNEL=y.

Signed-off-by Dave Martin <[email protected]>

Quoted 11 lines · Dave Martin

Because gcc/gas have no sane way to turn on individual CPU extensions from the command-line, iwmmxt.S was previously built with -mcpu=iwmmxt. Unfortunately, this also downgrades the CPU to v5, with the result that this file fails to build for a Thumb-2 kernel.

New versions of the tools support -march=<base arch>+iwmmxt, and it seems reasonable to require up-to-date tools when building in Thumb-2. So, this patch uses -march=armv7-a+iwmmxt for CONFIG_THUMB2_KERNEL=y.

Quoted 1 line

Signed-off-by Dave Martin <[email protected]>

Ok. More complex than I would have liked, but this definitely does the right thing in every case, as far as I can tell.

Acked-by Arnd Bergmann <[email protected]>

Because gcc/gas have no sane way to turn on individual CPU extensions from the command-line, iwmmxt.S was previously built with -mcpu=iwmmxt. Unfortunately, this also downgrades the CPU to v5, with the result that this file fails to build for a Thumb-2 kernel.

New versions of the tools support -march=<base arch>+iwmmxt, and it seems reasonable to require up-to-date tools when building in Thumb-2. So, this patch uses -march=armv7-a+iwmmxt for CONFIG_THUMB2_KERNEL=y.

Signed-off-by Dave Martin <[email protected]>

---
 arch/arm/kernel/Makefile |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

arch/arm/kernel/Makefile +12 -0

index f7887dc..e03691e 100644
@@ -66,6 +66,18 @@ obj-$(CONFIG_IWMMXT)		+= iwmmxt.o
 obj-$(CONFIG_CPU_HAS_PMU)	+= pmu.o
 obj-$(CONFIG_HW_PERF_EVENTS)	+= perf_event.o
 AFLAGS_iwmmxt.o			:= -Wa,-mcpu=iwmmxt
+ifdef CONFIG_CPU_V7
+AFLAGS_iwmmxt.o			:= $(call cc-option,-Wa$(comma)-march=armv7-a+iwmmxt,-DIWMMXT_LEGACY_ASSEMBLER)
+ifeq ($(AFLAGS_iwmmxt.o),-DIWMMXT_LEGACY_ASSEMBLER)
+ifdef CONFIG_THUMB2_KERNEL
+$(error Newer binutils is needed to build iwmmxt support for Thumb-2 kernels.)
+else
+$(warning Warning: Building legacy pre-v7 iwmmxt code for a v7 target.\
+  This is inadvisable.  Please upgrade to newer binutils.)
+AFLAGS_iwmmxt.o			+= -Wa,-mcpu=iwmmxt
+endif
+endif
+endif # CONFIG_CPU_V7
 
 ifneq ($(CONFIG_ARCH_EBSA110),y)
   obj-y		+= io.o

Signature · 7 lines

1.7.4.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Signed-off-by Dave Martin <[email protected]>

---
 arch/arm/kernel/iwmmxt.S |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
?arch/arm/kernel/iwmmxt.S | ? ?9 +++++++++
?1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
 arch/arm/kernel/iwmmxt.S |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Maybe it'll be much simpler to have something like below:

arch/arm/kernel/iwmmxt.S +0 -0

index a087838..5998f7d 100644

Quoted 26 lines · Eric Miao

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
?arch/arm/kernel/iwmmxt.S | ? ?9 +++++++++
?1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Maybe it'll be much simpler to have something like below:

arch/arm/kernel/iwmmxt.S +0 -0

index a087838..5998f7d 100644
@@ -319,8 +319,9 @@ ENTRY(iwmmxt_task_switch)
 ? ? ? ? PJ4(eor r1, r1, #0xf)
 ? ? ? ? PJ4(mcr p15, 0, r1, c1, c0, 2)
 

arch/arm/kernel/iwmmxt.S ENTRY(iwmmxt_task_switch) · line 324

Quoted 5 lines

arch/arm/kernel/iwmmxt.S +3 -2

- ? ? ? mrc ? ? p15, 0, r1, c2, c0, 0
- ? ? ? sub ? ? pc, lr, r1, lsr #32 ? ? ? ? ? ? @ cpwait and return
+ ? ? ? XSC(mrc p15, 0, r1, c2, c0, 0)
+ ? ? ? PJ4(isb)
+ ? ? ? mov ? ? pc, lr ? ? ? ? ? ? ? ? ? ? ? ? ?@ cpwait and return

Don't we still need "sub pc, lr, r1, lsr #32" in the XSC case? I had assumed this was to introduce a data dependency. I.e. PC depends on value of R1 which is loaded by the MRC, so it can't complete until that has.

Quoted 26 lines · Eric Miao

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
 arch/arm/kernel/iwmmxt.S |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Maybe it'll be much simpler to have something like below:

arch/arm/kernel/iwmmxt.S +0 -0

index a087838..5998f7d 100644
@@ -319,8 +319,9 @@ ENTRY(iwmmxt_task_switch)
        PJ4(eor r1, r1, #0xf)
        PJ4(mcr p15, 0, r1, c1, c0, 2)
 

arch/arm/kernel/iwmmxt.S ENTRY(iwmmxt_task_switch) · line 324

Quoted 5 lines

arch/arm/kernel/iwmmxt.S +3 -2

-       mrc     p15, 0, r1, c2, c0, 0
-       sub     pc, lr, r1, lsr #32             @ cpwait and return
+       XSC(mrc p15, 0, r1, c2, c0, 0)
+       PJ4(isb)
+       mov     pc, lr                          @ cpwait and return

Don't we still need "sub pc, lr, r1, lsr #32" in the XSC case? I had assumed this was to introduce a data dependency. I.e. PC depends on value of R1 which is loaded by the MRC, so it can't complete until that has.

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
?arch/arm/kernel/iwmmxt.S | ? ?9 +++++++++
?1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Maybe it'll be much simpler to have something like below:

arch/arm/kernel/iwmmxt.S +0 -0

index a087838..5998f7d 100644

Quoted 23 lines · Eric Miao

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
?arch/arm/kernel/iwmmxt.S | ? ?9 +++++++++
?1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Maybe it'll be much simpler to have something like below:

arch/arm/kernel/iwmmxt.S +0 -0

index a087838..5998f7d 100644

arch/arm/kernel/iwmmxt.S ENTRY(iwmmxt_task_switch) · line 324

Quoted 8 lines

arch/arm/kernel/iwmmxt.S +3 -2

@@ -319,8 +319,9 @@ ENTRY(iwmmxt_task_switch)
        PJ4(eor r1, r1, #0xf)
        PJ4(mcr p15, 0, r1, c1, c0, 2)
 
-       mrc     p15, 0, r1, c2, c0, 0
-       sub     pc, lr, r1, lsr #32             @ cpwait and return
+       XSC(mrc p15, 0, r1, c2, c0, 0)
+       PJ4(isb)
+       mov     pc, lr                          @ cpwait and return

This won't allow the building of this code for a v7 ARM kernel with current tools.

I think this is likely to be too much dirsuption: requiring really new tools for Thumb-2 is unavoidable, but we should allow people using existing tools to build this to carry on with the current situation for the time being. This is because of the fact that not all current tools can support "isb" and the iwmmxt mnemonics in the same file.

One thing we could do is to code the ISB using .long, since we only need this for Thumb kernels.

This would allow us to get rid of the Makefile warning, since the generated code would be the preferred v7 code in that case.

Quoted 26 lines · Eric Miao

Quoted 7 lines · Arnd Bergmann

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one for Thumb-2 kernels.

Quoted 7 lines

Quoted 4 lines

Signed-off-by Dave Martin <[email protected]>

---
?arch/arm/kernel/iwmmxt.S | ? ?9 +++++++++
?1 files changed, 9 insertions(+), 0 deletions(-)

Acked-by Arnd Bergmann <[email protected]>

Maybe it'll be much simpler to have something like below:

arch/arm/kernel/iwmmxt.S +0 -0

index a087838..5998f7d 100644
@@ -319,8 +319,9 @@ ENTRY(iwmmxt_task_switch)
 ? ? ? ? PJ4(eor r1, r1, #0xf)
 ? ? ? ? PJ4(mcr p15, 0, r1, c1, c0, 2)
 

arch/arm/kernel/iwmmxt.S ENTRY(iwmmxt_task_switch) · line 324

Quoted 5 lines

arch/arm/kernel/iwmmxt.S +3 -2

- ? ? ? mrc ? ? p15, 0, r1, c2, c0, 0
- ? ? ? sub ? ? pc, lr, r1, lsr #32 ? ? ? ? ? ? @ cpwait and return
+ ? ? ? XSC(mrc p15, 0, r1, c2, c0, 0)
+ ? ? ? PJ4(isb)
+ ? ? ? mov ? ? pc, lr ? ? ? ? ? ? ? ? ? ? ? ? ?@ cpwait and return

This won't allow the building of this code for a v7 ARM kernel with current tools.

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 5 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

Quoted 7 lines

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

Quoted 14 lines · Jon Medhurst (Tixy)

Quoted 12 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 6 lines

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

But isn't the first insn unavailable with Thumb2?

Maybe something like:

	sub	r1, r1, r1
	add	pc, lr, r1

Quoted 14 lines · Jon Medhurst (Tixy)

Quoted 5 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

Quoted 7 lines

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 6 lines

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

But isn't the first insn unavailable with Thumb2?

Maybe something like:

	sub	r1, r1, r1
	add	pc, lr, r1

Quoted 27 lines · Nicolas Pitre

Quoted 14 lines · Jon Medhurst (Tixy)

Quoted 5 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

Quoted 7 lines

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 6 lines

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

But isn't the first insn unavailable with Thumb2?

Maybe something like:

Quoted 2 lines

	sub	r1, r1, r1
	add	pc, lr, r1

Thumb-2 implies v7, the v7 implies that we have (and need) a real ISB. So for the Thumb-2 case, this should always become

isb

Quoted 34 lines · Dave Martin

Quoted 23 lines · Nicolas Pitre

Quoted 14 lines · Jon Medhurst (Tixy)

Quoted 5 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

Quoted 7 lines

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 6 lines

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

Quoted 6 lines

But isn't the first insn unavailable with Thumb2?

Maybe something like:

	sub	r1, r1, r1
	add	pc, lr, r1

Thumb-2 implies v7, the v7 implies that we have (and need) a real ISB. So for the Thumb-2 case, this should always become

Quoted 1 line

isb

Don't forget that here we are talking about the Marvell implementation. Since I've no doubt that the real isb certainly works, so far the advertized isb has always been implemented with a CP readback with a data dependency. Don't forget that this CPU core can also pretend to be an ARMv6 and they probably didn't duplicate the whole instruction decoder for each modes.

So I really doubt the Marvell implementation would behave any differently if this special isb is expressed in terms of Thumb2 rather than ARM instructions as the backend is certainly common to all the modes. If we can use the same implementation for all modes then we'll just simplify maintenance of this code.

Agreed, but the trouble is that what constitutes a suitable data dependency is completely microarchitecture dependent -- we're relying on side-effects outside the architecture here.

We can't code _exactly_ the same thing in Thumb-2 because of restrictions in the instruction set, so we have to settle for something that "looks similar" -- but there's no guarantee it will work.

Do you feel your judgement on this is authoritative? If so, then we can go ahead with your suggestion; otherwise we might need input from someone else.

Quoted 36 lines · Nicolas Pitre

Quoted 34 lines · Dave Martin

Quoted 23 lines · Nicolas Pitre

Quoted 14 lines · Jon Medhurst (Tixy)

Quoted 5 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

Quoted 7 lines

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 6 lines

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

Quoted 6 lines

But isn't the first insn unavailable with Thumb2?

Maybe something like:

	sub	r1, r1, r1
	add	pc, lr, r1

Thumb-2 implies v7, the v7 implies that we have (and need) a real ISB. So for the Thumb-2 case, this should always become

Quoted 8 lines

Quoted 1 line

isb

Don't forget that here we are talking about the Marvell implementation. Since I've no doubt that the real isb certainly works, so far the advertized isb has always been implemented with a CP readback with a data dependency. Don't forget that this CPU core can also pretend to be an ARMv6 and they probably didn't duplicate the whole instruction decoder for each modes.

If the isb instruction doesn't work for this in v7 mode, I think that would be an architecture violation, but you're right that this may not be available, or may not behave identically, when the CPU is behaving like a v6 part.

Quoted 5 lines

So I really doubt the Marvell implementation would behave any differently if this special isb is expressed in terms of Thumb2 rather than ARM instructions as the backend is certainly common to all the modes. If we can use the same implementation for all modes then we'll just simplify maintenance of this code.

Agreed, but the trouble is that what constitutes a suitable data dependency is completely microarchitecture dependent -- we're relying on side-effects outside the architecture here.

We can't code _exactly_ the same thing in Thumb-2 because of restrictions in the instruction set, so we have to settle for something that "looks similar" -- but there's no guarantee it will work.

Do you feel your judgement on this is authoritative? If so, then we can go ahead with your suggestion; otherwise we might need input from someone else.

Quoted 46 lines · Dave Martin

Quoted 36 lines · Nicolas Pitre

Quoted 34 lines · Dave Martin

Quoted 23 lines · Nicolas Pitre

Quoted 14 lines · Jon Medhurst (Tixy)

Quoted 5 lines · Eric Miao

So the problem is really when compiling this file with existing toolchain, it's downgrading to v5 compatible mode, and the instruction below

sub pc, lr, r1, lsr #32

Quoted 7 lines

wouldn't be encoded when building a THUMB2 kernel. Considering the r1, lsr #32 is actually to create an explicit data dependency of the previous co-processor instruction, would it be one option to rewrite this as something like:

mov r1, r1
mov pc, lr

Quoted 6 lines

That doesn't include a data dependency of PC on R1, so it's possible for MOV PC, LR and subsequent instructions to be executed before MOV R1, R1 has completed. We would want...

add lr, lr, r1, lsr #32
mov pc, lr

Quoted 6 lines

But isn't the first insn unavailable with Thumb2?

Maybe something like:

	sub	r1, r1, r1
	add	pc, lr, r1

Thumb-2 implies v7, the v7 implies that we have (and need) a real ISB. So for the Thumb-2 case, this should always become

Quoted 8 lines

Quoted 1 line

isb

Don't forget that here we are talking about the Marvell implementation. Since I've no doubt that the real isb certainly works, so far the advertized isb has always been implemented with a CP readback with a data dependency. Don't forget that this CPU core can also pretend to be an ARMv6 and they probably didn't duplicate the whole instruction decoder for each modes.

Quoted 4 lines

If the isb instruction doesn't work for this in v7 mode, I think that would be an architecture violation, but you're right that this may not be available, or may not behave identically, when the CPU is behaving like a v6 part.

I'm sure isb is available in ARMv7 mode.

What I'm saying is that the advertised trick for ARMv6 mode certainly must work just as well here in ARMv7 mode.

Quoted 9 lines

Quoted 5 lines

So I really doubt the Marvell implementation would behave any differently if this special isb is expressed in terms of Thumb2 rather than ARM instructions as the backend is certainly common to all the modes. If we can use the same implementation for all modes then we'll just simplify maintenance of this code.

Agreed, but the trouble is that what constitutes a suitable data dependency is completely microarchitecture dependent -- we're relying on side-effects outside the architecture here.

Sure. But what is there now is what is documented by Marvell docs i.e. create a data dependency on the register used to read back the CP value. I've seen a few implementation variations on that theme too.

Quoted 7 lines

We can't code _exactly_ the same thing in Thumb-2 because of restrictions in the instruction set, so we have to settle for something that "looks similar" -- but there's no guarantee it will work.

Do you feel your judgement on this is authoritative? If so, then we can go ahead with your suggestion; otherwise we might need input from someone else.

My suggestion would be what Tixy also proposed:

	mrc	p15, 0, r1, c2, c0, 0
	add	lr, lr, r1, lsr #32
	mov	pc, lr

Running this past people still at Marvell (I'm not anymore) wouldn't hurt of course.

Quoted 11 lines · Dave Martin

? ? ? ? __asm__ __volatile__ (
? ? ? ? ? ? ? ? "mcr ? ?p15, 0, %1, c1, c0, 2\n\t"

(quoted diff) +3 -0

+#ifdef __LINUX_ARM_ARCH__ >= 7
+ ? ? ? ? ? ? ? "isb\n\t"
+#else

? ? ? ? ? ? ? ? "mrc ? ?p15, 0, %0, c1, c0, 2\n\t" ? ? ? ? ? ? ? ? "mov ? ?%0, %0\n\t"
? ? ? ? ? ? ? ? "sub ? ?pc, pc, #4\n\t" +#endif
? ? ? ? ? ? ? ? : "=r" (temp) : "r" (value)); ?}

I thought we had concluded that we don't actually need the #else path because there is no pre-v7 support for pj4 any more.

arch/arm/kernel/pj4-cp0.c static void __init pj4_cp_access_write(u32 value) · line 77

Quoted 11 lines · Dave Martin

        __asm__ __volatile__ (
                "mcr    p15, 0, %1, c1, c0, 2\n\t"

arch/arm/kernel/pj4-cp0.c +4 -0

+#ifdef __LINUX_ARM_ARCH__ >= 7
+               "isb\n\t"
+#else
                "mrc    p15, 0, %0, c1, c0, 2\n\t"
                "mov    %0, %0\n\t"
                "sub    pc, pc, #4\n\t"
+#endif
                : "=r" (temp) : "r" (value));
 }

I thought we had concluded that we don't actually need the #else path because there is no pre-v7 support for pj4 any more.

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one on v7 and above.

Signed-off-by Dave Martin <[email protected]>

Quoted 6 lines · Dave Martin

The iwmmxt code contains some code to implement a pseudo-ISB, but this is not buildable for Thumb-2.

This patch replaces the pseudo-ISB with a real one on v7 and above.

Signed-off-by Dave Martin <[email protected]>

In arch/arm/mm/Kconfig:

config CPU_PJ4
? ? ? ?bool
? ? ? ?select CPU_V7
? ? ? ?select ARM_THUMBEE

So this code may only be ARMv7 aware now.