Hi Philippe,

On 05/11/10 07:26, Philippe De Muyter wrote:
On Thu, Nov 04, 2010 at 02:50:16PM +1000, Greg Ungerer wrote:
This is a request for testing (and comment) on a patch that will
use the separate kernel/user stack pointer hardware that the more
modern ColdFire cores have. This has a performance benefit when
used, the exception entry and exit paths are quite a few instructions
shorter.

Yeah, the mcf548x will benefit from that :)

Yep :-)
I have it running here on a 5475EVB, seems to run nicely.

So far I have tried it on a 5208 and 5475. I hope to try a few
others out today (at least a 5275, and any other boards I can
find here that still work).


Currently the parts I know can use it are the 520[78], 523x, 527[12],
527[45], 523x (and 547x/548x).

The use of the separate stack pointer is based on a config option
(CONFIG_COLDFIRE_SW_A7) that is automatically selected based on
ColdFure CPU selection. This may well not be the best way to do this.
Maybe the selection should be based on the compiler define
__mcfisaaplus__. I didn't use this because only more modern toolchains
support it. My 4.2.4 based toolchain doesn't.

I prefer to keep the choice explicit in kernel sources than
to rely on gcc's defines.

I guess that gives us the option of not using separate stack
pointers (or maybe even making it config time configurable) -
though I am not sure why you would want to do that in practice.


The older toolchain also required one more ugly hack. Pre 4.3 gcc
won't generate the "move usp" instructions required for this when
compiling for ColdFire. So I have had to hard code the opcode values
in place for these instructions for now.

Technically, it is not gcc's job but gas's job.  But it's not
a problem to have some hex constants as long as they are documented.

True. Maybe I could put "#ifdef"'s and use proper instructions
when newer enough gas is available and fall back to constants
when it isn't.


Maybe we need to bite the bullet and just not support this using
older toolchains... Thoughts?

The patch below is against 2.6.36. If you prefer living on the edge,
you can pull this from from the for-linus branch of ther m68knommu
git tree (along with a bunch of other updates):

git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-linus

Regards
Greg


---
[PATCH] m68knommu: use user stack pointer hardware on some ColdFire cores

The more modern ColdFire parts (even if based on older version cores)
have separate user and supervisor stack pointers (a7 register).
Modify the ColdFire CPU setup and exception code to enable and use
this on parts that have it.

Signed-off-by: Greg Ungerer<g...@uclinux.org>
---
  m68k/include/asm/cacheflush_no.h    |    4 +-
  m68k/include/asm/entry_no.h         |   59 
++++++++++++++++++++----------------
  m68k/include/asm/mcfcache.h         |    6 +--
  m68k/include/asm/processor.h        |   13 ++++---
  m68knommu/Kconfig                   |   11 ++++++
  m68knommu/platform/coldfire/entry.S |   56 ++++++----------------------------
  6 files changed, 68 insertions(+), 81 deletions(-)

diff -Naurp linux-2.6.36/arch/m68k/include/asm/cacheflush_no.h 
linux-2.6.36.eusp/arch/m68k/include/asm/cacheflush_no.h
--- linux-2.6.36/arch/m68k/include/asm/cacheflush_no.h  2010-10-21 
06:30:22.000000000 +1000
+++ linux-2.6.36.eusp/arch/m68k/include/asm/cacheflush_no.h     2010-11-04 
14:32:46.491869598 +1000
@@ -54,7 +54,7 @@ static inline void __flush_cache_all(voi
  #endif /* CONFIG_M5407 */
  #if defined(CONFIG_M523x) || defined(CONFIG_M527x)
        __asm__ __volatile__ (
-               "movel     #0x81400100, %%d0\n\t"
+               "movel     #0x81400110, %%d0\n\t"

Some symbolic constants would not hurt and would be easier for consistency
with mcfcache.h.

I am working on cleaning up the cache code here right now.
But that is for another patch :-)


                "movec     %%d0, %%CACR\n\t"
                "nop\n\t"
                : : : "d0" );
@@ -82,7 +82,7 @@ static inline void __flush_cache_all(voi
  #endif /* CONFIG_M5249 */
  #ifdef CONFIG_M532x
        __asm__ __volatile__ (
-               "movel     #0x81000200, %%d0\n\t"
+               "movel     #0x81000210, %%d0\n\t"
                "movec     %%d0, %%CACR\n\t"
                "nop\n\t"
                : : : "d0" );
diff -Naurp linux-2.6.36/arch/m68k/include/asm/entry_no.h 
linux-2.6.36.eusp/arch/m68k/include/asm/entry_no.h
--- linux-2.6.36/arch/m68k/include/asm/entry_no.h       2010-10-21 
06:30:22.000000000 +1000
+++ linux-2.6.36.eusp/arch/m68k/include/asm/entry_no.h  2010-11-04 
14:32:46.491869598 +1000
@@ -52,12 +52,16 @@ LENOSYS = 38
   */

  #ifdef CONFIG_COLDFIRE
+#ifdef CONFIG_COLDFIRE_SW_A7

It would have been better to have a new positive define for the new
functionality.

Interesting. I actually consider this a positive define.
That is that you are choosing to use a single, software driven
stack pointer. The benefit is that going forward I expect that
no new ColdFire parts will need to use this - so we will never
need to remember to enable this switch for any newer parts.

I am not really tied to it in this sense though.
A define either way is ok by me.


  /*
- * This is made a little more tricky on the ColdFire. There is no
- * separate kernel and user stack pointers. Need to artificially
+ * This is made a little more tricky on older ColdFires. There is no
+ * separate supervisor and user stack pointers. Need to artificially
   * construct a usp in software... When doing this we need to disable
- * interrupts, otherwise bad things could happen.
+ * interrupts, otherwise bad things will happen.
   */

Thanks
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     g...@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to