sh: prefetch early exception data on sh3/sh4/sh4a
PATCH 4/4 sh: prefetch early exception data on sh3/sh4/sh4a
From: Magnus Damm <[email protected]>
Prefetch early exception data. There is unused space in our exception handler cache line anyway, so this is almost free.
---
arch/sh/kernel/cpu/sh3/entry.S | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
arch/sh/kernel/cpu/sh3/entry.S +5 -2
@@ -463,9 +463,11 @@ tlb_miss: sts pr, k3 ! save original pr value in k3 handle_exception: + mova exception_data, k0 + ! Setup stack and save DSP context (k0 contains original r15 on return) bsr prepare_stack_save_dsp - nop + pref @k0 ! Save registers / Switch to bank 0 mov.l 5f, k2 ! vector register address
@@ -556,10 +558,11 @@ ENTRY(handle_interrupt) 11: #endif /* defined(CONFIG_KGDB) */ sts pr, k3 ! save original pr value in k3 + mova exception_data, k0 ! Setup stack and save DSP context (k0 contains original r15 on return) bsr prepare_stack_save_dsp - nop + pref @k0 ! Save registers / Switch to bank 0 bsr save_regs ! needs original pr value in k3
Quoted 5 lines · Magnus Damm
From: Magnus Damm <[email protected]>
Prefetch early exception data. There is unused space in our exception handler cache line anyway, so this is almost free.
Hmm, this won't work, 'pref' doesn't exist on SH-3. The binutils opcode table defines it as arch_sh2a_nofpu_or_sh4_nommu_nofpu_up, which excludes SH-3. mova is ok, though.
This does show how often SH-3 gets tested though, as asm/processor_32.h happily defines prefetch() for SH-3 when it shouldn't. I'll tidy this up and drop in a PREF() macro.
Quoted 6 lines · Paul Mundt
Quoted 5 lines · Magnus Damm
From: Magnus Damm <[email protected]>
Prefetch early exception data. There is unused space in our exception handler cache line anyway, so this is almost free.
Quoted 7 lines
Hmm, this won't work, 'pref' doesn't exist on SH-3. The binutils opcode table defines it as
arch_sh2a_nofpu_or_sh4_nommu_nofpu_up, which excludes SH-3. mova is ok, though.This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.
Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
/ magnus
Quoted 11 lines · Magnus Damm
Quoted 10 lines · Paul Mundt
Quoted 5 lines · Magnus Damm
From: Magnus Damm <[email protected]>
Prefetch early exception data. There is unused space in our exception handler cache line anyway, so this is almost free.
Hmm, this won't work, 'pref' doesn't exist on SH-3. The binutils opcode table defines it as
arch_sh2a_nofpu_or_sh4_nommu_nofpu_up, which excludes SH-3. mova is ok, though.
Quoted 6 lines
Quoted 3 lines
This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
The fact that that didn't blow up on the opcode is likely because the toolchain you were using had no idea about SH-3 ISA tuning, and so fell back on an anything-goes tuning policy. If you are building for exotic combinations, always do a single run with V=1 to make sure that the CFLAGS are sticking and doing what you think they are doing.
There are far more people building SH-3 targetted kernels with an SH-4+ specific toolchain than there are actual SH-3 users, the latter of which tend to only provide feedback a few times a year. This unfortunately means that these sorts of bugs can be long lived and tedious to bisect at a later point in time, but there is not much that can be done about that.
Quoted 9 lines · Magnus Damm
Quoted 8 lines · Paul Mundt
Quoted 7 lines · Magnus Damm
Quoted 3 lines · Paul Mundt
This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
Quoted 9 lines
Quoted 5 lines
The fact that that didn't blow up on the opcode is likely because the toolchain you were using had no idea about SH-3 ISA tuning, and so fell back on an anything-goes tuning policy. If you are building for exotic combinations, always do a single run with V=1 to make sure that the CFLAGS are sticking and doing what you think they are doing.
Hm, what about extending the makefiles to check for SH-3 support? Or maybe that's impossible or takes too long time to implement.
I don't think you fully appreciate the sheer amount of work we do in the kernel Makefiles to work around GCC's stupidity. Give arch/sh/Makefile a read first.
Quoted 6 lines · Paul Mundt
Quoted 5 lines · Magnus Damm
Quoted 3 lines · Paul Mundt
This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.
Quoted 7 lines
Quoted 2 lines
Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
The fact that that didn't blow up on the opcode is likely because the toolchain you were using had no idea about SH-3 ISA tuning, and so fell back on an anything-goes tuning policy. If you are building for exotic combinations, always do a single run with V=1 to make sure that the CFLAGS are sticking and doing what you think they are doing.
Hm, what about extending the makefiles to check for SH-3 support? Or maybe that's impossible or takes too long time to implement.
Quoted 5 lines
There are far more people building SH-3 targetted kernels with an SH-4+ specific toolchain than there are actual SH-3 users, the latter of which tend to only provide feedback a few times a year. This unfortunately means that these sorts of bugs can be long lived and tedious to bisect at a later point in time, but there is not much that can be done about that.
I guess that checking for CFLAGS in the makefiles is out of the question then..
/ magnus
Quoted 16 lines · Paul Mundt
Quoted 15 lines · Magnus Damm
Quoted 13 lines · Paul Mundt
Quoted 7 lines · Magnus Damm
Quoted 3 lines · Paul Mundt
This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
The fact that that didn't blow up on the opcode is likely because the toolchain you were using had no idea about SH-3 ISA tuning, and so fell back on an anything-goes tuning policy. If you are building for exotic combinations, always do a single run with V=1 to make sure that the CFLAGS are sticking and doing what you think they are doing.
Quoted 6 lines
Quoted 3 lines
Hm, what about extending the makefiles to check for SH-3 support? Or maybe that's impossible or takes too long time to implement.
I don't think you fully appreciate the sheer amount of work we do in the kernel Makefiles to work around GCC's stupidity. Give
arch/sh/Makefilea read first.
Ok, ok. We do a lot of magic already. I've seen more hairy stuff elsewhere though. I'll shut up. =)
/ magnus
Quoted 24 lines · On Mon, 2 Mar 2009 11:30:13 +0900 Paul Mundt <[email protected]> wrote:
Quoted 11 lines · Magnus Damm
Quoted 10 lines · Paul Mundt
Quoted 5 lines · Magnus Damm
From: Magnus Damm <[email protected]>
Prefetch early exception data. There is unused space in our exception handler cache line anyway, so this is almost free.
Hmm, this won't work, 'pref' doesn't exist on SH-3. The binutils opcode table defines it as
arch_sh2a_nofpu_or_sh4_nommu_nofpu_up, which excludes SH-3. mova is ok, though.Quoted 6 lines
Quoted 3 lines
This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
The fact that that didn't blow up on the opcode is likely because the toolchain you were using had no idea about SH-3 ISA tuning, and so fell back on an anything-goes tuning policy. If you are building for exotic combinations, always do a single run with V=1 to make sure that the CFLAGS are sticking and doing what you think they are doing.
Quoted 6 lines
There are far more people building SH-3 targetted kernels with an SH-4+ specific toolchain than there are actual SH-3 users, the latter of which tend to only provide feedback a few times a year. This unfortunately means that these sorts of bugs can be long lived and tedious to bisect at a later point in time, but there is not much that can be done about that. --
I usually build a couple of kernels per month for the hp6xx (sh3) so the biggest stuff kernel wise usually gets caught there. I however use an old sh3 toolchain so gcc stuff often runs me by. Lack of time to fix the hd64461 mfd driver is probably the main reason why hp6xx isnt more in sync currently.
If theres anything specific you want to test just shout. I keep an close eye on the mailinglists even if I dont say much :)
Quoted 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Kristoffer Ericson <[email protected]>
Quoted 11 lines · Kristoffer Ericson
Quoted 9 lines · On Mon, 2 Mar 2009 11:30:13 +0900 Paul Mundt <[email protected]> wrote:
Quoted 7 lines · Magnus Damm
Quoted 3 lines · Paul Mundt
This does show how often SH-3 gets tested though, as
asm/processor_32.hhappily definesprefetch()for SH-3 when it shouldn't. I'll tidy this up and drop in aPREF()macro.Right, I do recall building for hp6xx at some point. Thanks for fixing it up.
[snip]
Quoted 6 lines
Quoted 5 lines
There are far more people building SH-3 targetted kernels with an SH-4+ specific toolchain than there are actual SH-3 users, the latter of which tend to only provide feedback a few times a year. This unfortunately means that these sorts of bugs can be long lived and tedious to bisect at a later point in time, but there is not much that can be done about that.
Quoted 7 lines
I usually build a couple of kernels per month for the hp6xx (sh3) so the biggest stuff kernel wise usually gets caught there. I however use an old sh3 toolchain so gcc stuff often runs me by. Lack of time to fix the hd64461 mfd driver is probably the main reason why hp6xx isnt more in sync currently.
If theres anything specific you want to test just shout. I keep an close eye on the mailinglists even if I dont say much :)
The entire purpose of this thread is to show that _building_ is not the issue, as various SH-3 targets are built daily by multiple people with multiple compilers and multiple trees. The issue is with testing. The platforms with a close to single user userbase suffer from the problem that the only time we get any feedback is when something has broken, usually months after the fact. There is no easy way to solve this issue though, it is just something to be aware of. When issues do pop up, they will be fixed in turn, but are not likely to be prioritized. Jumping in when things are being worked on and integrated early on gaurantees that those issues are fixed immediately.