[uClinux-dev] [PATCH] m68k: merge mmu and non-mmu bitops.h

2011-06-02 Thread gerg
From: Greg Ungerer 

The following patch merges the mmu and non-mmu versions of the m68k
bitops.h files. Now there is a good deal of difference between the two
files, but none of it is actually an mmu specific difference. It is
all about the specific m68k/coldfire varient we are targeting. So it
makes an awful lot of sense to merge these into a single bitops.h.

This is more an RFC than anything else. There is a number of ways I
can see to factor this code. The approach in this first attempt is to
keep the various versions of each macro/function type together. But
this means that there is some ifdefery with each to handle each CPU
type. The ifdefs could be grouped - but this will move the macro
definitions away from the inline functions they reference.

I have added some comments in a couple of appropriate places to try
and make it clear what the differences we are dealing with are.
Specifically the instruction and addressing mode differences we have
to deal with.

The merged form keeps the same underlying optimizations for each CPU
type for all the general bit clear/set/change and find bit operations.
It does switch to using the generic le operations though, instead of
any local varients.

Build tested on ColdFire, 68328, 68360 (which is cpu32) and 68020+.
Run tested on ColdFire and ARAnyM.

Signed-off-by: Greg Ungerer 
---
 arch/m68k/include/asm/bitops.h|  522 -
 arch/m68k/include/asm/bitops_mm.h |  501 ---
 arch/m68k/include/asm/bitops_no.h |  333 ---
 3 files changed, 519 insertions(+), 837 deletions(-)
 delete mode 100644 arch/m68k/include/asm/bitops_mm.h
 delete mode 100644 arch/m68k/include/asm/bitops_no.h

diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
index ce163ab..3596e56 100644
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -1,5 +1,521 @@
-#ifdef __uClinux__
-#include "bitops_no.h"
+#ifndef _M68K_BITOPS_H
+#define _M68K_BITOPS_H
+/*
+ * Copyright 1992, Linus Torvalds.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
+#include 
+
+/*
+ * Bit access functions vary a across the ColdFire and 68k families.
+ * So we will break them out here, and then macro in the ones we want.
+ *
+ * ColdFire - supports standard bset/bclr/bchg with register operand only
+ * 68000- supports standard bset/bclr/bchg with memory operand
+ *  >= 68020 - also supports the bfset/bfclr/bfchg instructions 
+ *
+ * Although it is possible to use only the bset/bclr/bchg with register
+ * operands on all platforms you end up with larger generated code.
+ * So we use the best form possible on a given platform.
+ */
+
+static inline void bset_reg_set_bit(int nr, volatile unsigned long *vaddr)
+{
+char *p = (char *)vaddr + (nr ^ 31) / 8;
+
+__asm__ __volatile__ ("bset %1,(%0)"
+   :
+   : "a" (p), "di" (nr & 7)
+   : "memory");
+}
+
+static inline void bset_mem_set_bit(int nr, volatile unsigned long *vaddr)
+{
+   char *p = (char *)vaddr + (nr ^ 31) / 8;
+
+   __asm__ __volatile__ ("bset %1,%0"
+   : "+m" (*p)
+   : "di" (nr & 7));
+}
+
+static inline void bfset_mem_set_bit(int nr, volatile unsigned long *vaddr)
+{
+   __asm__ __volatile__ ("bfset %1{%0:#1}"
+   :
+   : "d" (nr ^ 31), "o" (*vaddr)
+   : "memory");
+}
+
+#if defined(CONFIG_COLDFIRE)
+#defineset_bit(nr,vaddr)   bset_reg_set_bit(nr,vaddr)
+#elif defined(CONFIG_M68000) || defined(CONFIG_MCPU32)
+#defineset_bit(nr,vaddr)   bset_mem_set_bit(nr,vaddr)
+#else
+#define set_bit(nr,vaddr)  (__builtin_constant_p(nr) ? \
+   bset_mem_set_bit(nr,vaddr) : \
+   bfset_mem_set_bit(nr,vaddr))
+#endif
+
+#define __set_bit(nr,vaddr)set_bit(nr,vaddr)
+
+
+/*
+ * clear_bit() doesn't provide any barrier for the compiler.
+ */
+#define smp_mb__before_clear_bit() barrier()
+#define smp_mb__after_clear_bit()  barrier()
+
+static inline void bclr_reg_clear_bit(int nr, volatile unsigned long *vaddr)
+{
+char *p = (char *)vaddr + (nr ^ 31) / 8;
+
+__asm__ __volatile__ ("bclr %1,(%0)"
+   :
+   : "a" (p), "di" (nr & 7)
+   : "memory");
+}
+
+static inline void bclr_mem_clear_bit(int nr, volatile unsigned long *vaddr)
+{
+   char *p = (char *)vaddr + (nr ^ 31) / 8;
+
+   __asm__ __volatile__ ("bclr %1,%0"
+   : "+m" (*p)
+   : "di" (nr & 7));
+}
+
+static inline void bfclr_mem_clear_bit(int nr, volatile unsigned long *vaddr)
+{
+   __asm__ __volatile__ ("bfclr %1{%0:#1}"
+   :
+   

[uClinux-dev] [PATCH 2/2] m68k: use kernel processor defines for conditional optimizations

2011-06-02 Thread gerg
From: Greg Ungerer 

Older m68k-linux compilers will include pre-defined symbols that
confuse what processor it is being targeted for. For example gcc-4.1.2
will pre-define __mc68020__ even if you specify the target processor
as -m68000 on the gcc command line. Newer versions of gcc have this
corrected.

In a few places the m68k code uses defined(__mc68020__) for optimizations
that include instructions that are specific to the CPU 68020 and above.
When compiling with older compilers this will be true even when we have
selected to compile for the older 68000 processors.

Switch to using the kernel processor defines, CONFIG_M68020 and friends.

Signed-off-by: Greg Ungerer 
---
 arch/m68k/kernel/m68k_ksyms.c |3 +--
 arch/m68k/lib/memcpy.c|9 -
 arch/m68k/lib/memset.c|9 -
 arch/m68k/lib/muldi3.c|   21 ++---
 4 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/arch/m68k/kernel/m68k_ksyms.c b/arch/m68k/kernel/m68k_ksyms.c
index 33f8276..1b7a14d 100644
--- a/arch/m68k/kernel/m68k_ksyms.c
+++ b/arch/m68k/kernel/m68k_ksyms.c
@@ -14,8 +14,7 @@ EXPORT_SYMBOL(__ashrdi3);
 EXPORT_SYMBOL(__lshrdi3);
 EXPORT_SYMBOL(__muldi3);
 
-#if !defined(__mc68020__) && !defined(__mc68030__) && \
-!defined(__mc68040__) && !defined(__mc68060__) && !defined(__mcpu32__)
+#if defined(CONFIG_M68000) || defined(CONFIG_COLDFIRE)
 /*
  * Simpler 68k and ColdFire parts also need a few other gcc functions.
  */
diff --git a/arch/m68k/lib/memcpy.c b/arch/m68k/lib/memcpy.c
index 62182c8..0648893 100644
--- a/arch/m68k/lib/memcpy.c
+++ b/arch/m68k/lib/memcpy.c
@@ -34,8 +34,10 @@ void *memcpy(void *to, const void *from, size_t n)
if (temp) {
long *lto = to;
const long *lfrom = from;
-#if defined(__mc68020__) || defined(__mc68030__) || \
-defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
+#if defined(CONFIG_M68000) || defined(CONFIG_COLDFIRE)
+   for (; temp; temp--)
+   *lto++ = *lfrom++;
+#else
asm volatile (
"   movel %2,%3\n"
"   andw  #7,%3\n"
@@ -56,9 +58,6 @@ void *memcpy(void *to, const void *from, size_t n)
"   jpl   4b"
: "=a" (lfrom), "=a" (lto), "=d" (temp), "=&d" (temp1)
: "0" (lfrom), "1" (lto), "2" (temp));
-#else
-   for (; temp; temp--)
-   *lto++ = *lfrom++;
 #endif
to = lto;
from = lfrom;
diff --git a/arch/m68k/lib/memset.c b/arch/m68k/lib/memset.c
index f649e6a..8a7639f 100644
--- a/arch/m68k/lib/memset.c
+++ b/arch/m68k/lib/memset.c
@@ -32,8 +32,10 @@ void *memset(void *s, int c, size_t count)
temp = count >> 2;
if (temp) {
long *ls = s;
-#if defined(__mc68020__) || defined(__mc68030__) || \
-defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
+#if defined(CONFIG_M68000) || defined(CONFIG_COLDFIRE)
+   for (; temp; temp--)
+   *ls++ = c;
+#else
size_t temp1;
asm volatile (
"   movel %1,%2\n"
@@ -55,9 +57,6 @@ void *memset(void *s, int c, size_t count)
"   jpl   1b"
: "=a" (ls), "=d" (temp), "=&d" (temp1)
: "d" (c), "0" (ls), "1" (temp));
-#else
-   for (; temp; temp--)
-   *ls++ = c;
 #endif
s = ls;
}
diff --git a/arch/m68k/lib/muldi3.c b/arch/m68k/lib/muldi3.c
index 079bafc..79e928a 100644
--- a/arch/m68k/lib/muldi3.c
+++ b/arch/m68k/lib/muldi3.c
@@ -19,17 +19,7 @@ along with GNU CC; see the file COPYING.  If not, write to
 the Free Software Foundation, 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  */
 
-#if defined(__mc68020__) || defined(__mc68030__) || \
-defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
-
-#define umul_ppmm(w1, w0, u, v) \
-  __asm__ ("mulu%.l %3,%1:%0"  \
-   : "=d" ((USItype)(w0)), \
- "=d" ((USItype)(w1))  \
-   : "%0" ((USItype)(u)),  \
- "dmi" ((USItype)(v)))
-
-#else
+#if defined(CONFIG_M68000) || defined(CONFIG_COLDFIRE)
 
 #define SI_TYPE_SIZE 32
 #define __BITS4 (SI_TYPE_SIZE / 4)
@@ -61,6 +51,15 @@ Boston, MA 02111-1307, USA.  */
 (w0) = __ll_lowpart (__x1) * __ll_B + __ll_lowpart (__x0); \
   } while (0)
 
+#else
+
+#define umul_ppmm(w1, w0, u, v) \
+  __asm__ ("mulu%.l %3,%1:%0"  \
+   : "=d" ((USItype)(w0)), \
+ "=d" ((USItype)(w1))  \
+   : "%0" ((USItype)(u)),   

[uClinux-dev] [PATCH 0/2] m68knommu: fix cpu optimization conditionals

2011-06-02 Thread gerg
The next 2 patches improve the conditional checks for portions of cpu
optimized code. Older versions of gcc compiler can incorrectly define
CPU symbols. By using our own local CPU family defines we can also
make the optimizations safe in case of a kernel being compiled for
multiple CPU targets.

___
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


[uClinux-dev] [PATCH 1/2] m68knommu: create config options for CPU classes

2011-06-02 Thread gerg
From: Greg Ungerer 

There are 3 families of CPU core types that we support in the m68knommu
architecture branch. They are

. traditional 68000
. CPU32 (which is a 68020 core derivitive without MMU)
. ColdFire

It will be useful going forward to have a CONFIG_ option defined for
each type. We already have one for ColdFire (CONFIG_COLDFIRE), so add
for the other 2 families, CONFIG_M68000 and CONFIG_MCPU32.

Signed-off-by: Greg Ungerer 
---
 arch/m68k/Kconfig.nommu |   52 --
 1 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/arch/m68k/Kconfig.nommu b/arch/m68k/Kconfig.nommu
index fc98f9b..b004dc1 100644
--- a/arch/m68k/Kconfig.nommu
+++ b/arch/m68k/Kconfig.nommu
@@ -14,6 +14,33 @@ config GENERIC_CLOCKEVENTS
bool
default n
 
+config M68000
+   bool
+   help
+ The Freescale (was Motorola) 68000 CPU is the first generation of
+ the well known M68K family of processors. The CPU core as well as
+ being available as a stand alone CPU was also used in many
+ System-On-Chip devices (eg 68328, 68302, etc). It does not contain
+ a paging MMU.
+
+config MCPU32
+   bool
+   help
+ The Freescale (was then Motorola) CPU32 is a CPU core that is
+ based on the 68020 processor. For the most part it is used in
+ System-On-Chip parts, and does not contain a paging MMU.
+
+config COLDFIRE
+   bool
+   select GENERIC_GPIO
+   select ARCH_REQUIRE_GPIOLIB
+   help
+ The Freescale ColdFire family of processors is a modern derivitive
+ of the 68000 processor family. They are mainly targeted at embedded
+ applications, and are all System-On-Chip (SOC) devices, as opposed
+ to stand alone CPUs. They implement a subset of the original 68000
+ processor instruction set.
+
 config COLDFIRE_SW_A7
bool
default n
@@ -36,26 +63,31 @@ choice
 
 config M68328
bool "MC68328"
+   select M68000
help
  Motorola 68328 processor support.
 
 config M68EZ328
bool "MC68EZ328"
+   select M68000
help
  Motorola 68EX328 processor support.
 
 config M68VZ328
bool "MC68VZ328"
+   select M68000
help
  Motorola 68VZ328 processor support.
 
 config M68360
bool "MC68360"
+   select MCPU32
help
  Motorola 68360 processor support.
 
 config M5206
bool "MCF5206"
+   select COLDFIRE
select COLDFIRE_SW_A7
select HAVE_MBAR
help
@@ -63,6 +95,7 @@ config M5206
 
 config M5206e
bool "MCF5206e"
+   select COLDFIRE
select COLDFIRE_SW_A7
select HAVE_MBAR
help
@@ -70,6 +103,7 @@ config M5206e
 
 config M520x
bool "MCF520x"
+   select COLDFIRE
select GENERIC_CLOCKEVENTS
select HAVE_CACHE_SPLIT
help
@@ -77,6 +111,7 @@ config M520x
 
 config M523x
bool "MCF523x"
+   select COLDFIRE
select GENERIC_CLOCKEVENTS
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
@@ -85,6 +120,7 @@ config M523x
 
 config M5249
bool "MCF5249"
+   select COLDFIRE
select COLDFIRE_SW_A7
select HAVE_MBAR
help
@@ -92,6 +128,7 @@ config M5249
 
 config M5271
bool "MCF5271"
+   select COLDFIRE
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
help
@@ -99,6 +136,7 @@ config M5271
 
 config M5272
bool "MCF5272"
+   select COLDFIRE
select COLDFIRE_SW_A7
select HAVE_MBAR
help
@@ -106,6 +144,7 @@ config M5272
 
 config M5275
bool "MCF5275"
+   select COLDFIRE
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
help
@@ -113,6 +152,7 @@ config M5275
 
 config M528x
bool "MCF528x"
+   select COLDFIRE
select GENERIC_CLOCKEVENTS
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
@@ -121,6 +161,7 @@ config M528x
 
 config M5307
bool "MCF5307"
+   select COLDFIRE
select COLDFIRE_SW_A7
select HAVE_CACHE_CB
select HAVE_MBAR
@@ -129,12 +170,14 @@ config M5307
 
 config M532x
bool "MCF532x"
+   select COLDFIRE
select HAVE_CACHE_CB
help
  Freescale (Motorola) ColdFire 532x processor support.
 
 config M5407
bool "MCF5407"
+   select COLDFIRE
select COLDFIRE_SW_A7
select HAVE_CACHE_CB
select HAVE_MBAR
@@ -143,6 +186,7 @@ config M5407
 
 config M547x
bool "MCF547x"
+   select COLDFIRE
select HAVE_CACHE_CB
select HAVE_MBAR
help
@@ -150,6 +194,7 @@ config M547x
 
 config M548x
bool "MCF548x"
+   select COLDFIRE
select HAVE_CACHE_CB
select HAVE_MBAR
help
@@ -168,13 +213,6 @@ config M54xx
depends on (M548x || M547x)
default y
 
-config COLDFIRE
-   bool
-   depends on (M5206 || M5206e || M520x || M523x || M5249

[uClinux-dev] [PATCH 0/2] m68knommu: fix cpu optimization conditionals

2011-06-02 Thread gerg

The next 2 patches improve the conditional checks for portions of cpu
optimized code. Older versions of gcc compiler can incorrectly define
CPU symbols. By using our own local CPU family defines we can also
make the optimizations safe in case of a kernel being compiled for
multiple CPU targets.

These are generated agains linux-3.0.0-rc1.

___
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


[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation

2011-06-02 Thread Greg Ungerer


Hi Geert,

On 02/06/11 17:43, Geert Uytterhoeven wrote:

On Thu, Jun 2, 2011 at 07:18, Greg Ungerer  wrote:

On 26/05/11 16:38, Geert Uytterhoeven wrote:

I was more thinking along the lines of !CONFIG_M68000&&  á!CONFIG_M68010
&&  á!CONFIG_.


Or in this case (and probably most cases) we could just switch
to using the same positive logic. So what I had as:

#if defined(__mc68020__) || defined(__mc68030__) || \
á ádefined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)

becomes

#if defined(CONFIG_M68020) || defined(CONFIG_M68030) || \
á ádefined(CONFIG_M68040) || defined(CONFIG_M68060) || \
á ádefined(CONFIG_MCPU32)

There currently isn't a CONFIG_MCPU32, but I could easily add
that (we only have one CPU in that class currently supported,
the 68360).

The compiler setting won't matter, only what we configured.
Sam will probably like this better, he suggested using the
kernel configs initially, in
http://www.spinics.net/lists/linux-m68k/msg03609.html


Pure positive logic won't work in the (currently stil pathological) case you're
building a multi-platform kernel, and have both CONFIG_M68020 and a lesser
one that doesn't support cpu32 instructions selected.


True. Though we could re-arrange the code blocks to keep the
logic positive. So for the memcpy.c case something like:

#if defined(CONFIG_COLDFIRE) || defined(CONFIG_M68000) || \
defined(CONFIG_MCPU32)
/* the simple code */
#else
/* the real 68020+ code */
#endif

Now the code doesn't yet have the defines CONFIG_M68000 and
CONFIG_MCPU32. But I have a patch ready to send that introduces
them :-)

Regards
Greg

___
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


[uClinux-dev] Missed interrupts

2011-06-02 Thread Wooff, David
Hi, I have a number of questions regarding missed interrupts, since I think I 
could be suffering from a problem which may be explained by an occasional 
missed interrupt:
 - How can an interrupt be missed from a GPIO interrupt i.e. if the interrupt 
is level sensitive and is not serviced then could it actually be missed?
 - Is there any kernel logging or debug I can use to prove one way or another 
that this is my problem?
Thanks

___
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

[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation

2011-06-02 Thread Geert Uytterhoeven
On Thu, Jun 2, 2011 at 07:18, Greg Ungerer  wrote:
> On 26/05/11 16:38, Geert Uytterhoeven wrote:
>> I was more thinking along the lines of !CONFIG_M68000&&  !CONFIG_M68010
>> &&  !CONFIG_.
>
> Or in this case (and probably most cases) we could just switch
> to using the same positive logic. So what I had as:
>
> #if defined(__mc68020__) || defined(__mc68030__) || \
>    defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
>
> becomes
>
> #if defined(CONFIG_M68020) || defined(CONFIG_M68030) || \
>    defined(CONFIG_M68040) || defined(CONFIG_M68060) || \
>    defined(CONFIG_MCPU32)
>
> There currently isn't a CONFIG_MCPU32, but I could easily add
> that (we only have one CPU in that class currently supported,
> the 68360).
>
> The compiler setting won't matter, only what we configured.
> Sam will probably like this better, he suggested using the
> kernel configs initially, in
> http://www.spinics.net/lists/linux-m68k/msg03609.html

Pure positive logic won't work in the (currently stil pathological) case you're
building a multi-platform kernel, and have both CONFIG_M68020 and a lesser
one that doesn't support cpu32 instructions selected.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
___
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