All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] m68knommu: fix cpu optimization conditionals
@ 2011-06-03  6:43 gerg
  2011-06-03  6:43 ` gerg
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: gerg @ 2011-06-03  6:43 UTC (permalink / raw)
  To: linux-m68k, uclinux-dev


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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 0/2] m68knommu: fix cpu optimization conditionals
  2011-06-03  6:43 [PATCH 0/2] m68knommu: fix cpu optimization conditionals gerg
@ 2011-06-03  6:43 ` gerg
  2011-06-03  6:43 ` [PATCH 1/2] m68knommu: create config options for CPU classes gerg
  2011-06-03  6:43 ` [PATCH 2/2] m68k: use kernel processor defines for conditional optimizations gerg
  2 siblings, 0 replies; 9+ messages in thread
From: gerg @ 2011-06-03  6:43 UTC (permalink / raw)
  To: linux-m68k, uclinux-dev

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 1/2] m68knommu: create config options for CPU classes
  2011-06-03  6:43 [PATCH 0/2] m68knommu: fix cpu optimization conditionals gerg
  2011-06-03  6:43 ` gerg
@ 2011-06-03  6:43 ` gerg
  2011-06-03 11:15   ` Geert Uytterhoeven
  2011-06-03  6:43 ` [PATCH 2/2] m68k: use kernel processor defines for conditional optimizations gerg
  2 siblings, 1 reply; 9+ messages in thread
From: gerg @ 2011-06-03  6:43 UTC (permalink / raw)
  To: linux-m68k, uclinux-dev; +Cc: Greg Ungerer

From: Greg Ungerer <gerg@uclinux.org>

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 <gerg@uclinux.org>
---
 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 || M527x || M5272 || M528x || M5307 || M532x || M5407 || M54xx)
-	select GENERIC_GPIO
-	select ARCH_REQUIRE_GPIOLIB
-	default y
-
 config CLOCK_SET
 	bool "Enable setting the CPU clock frequency"
 	default n
-- 
1.7.0.4

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH 2/2] m68k: use kernel processor defines for conditional optimizations
  2011-06-03  6:43 [PATCH 0/2] m68knommu: fix cpu optimization conditionals gerg
  2011-06-03  6:43 ` gerg
  2011-06-03  6:43 ` [PATCH 1/2] m68knommu: create config options for CPU classes gerg
@ 2011-06-03  6:43 ` gerg
  2 siblings, 0 replies; 9+ messages in thread
From: gerg @ 2011-06-03  6:43 UTC (permalink / raw)
  To: linux-m68k, uclinux-dev; +Cc: Greg Ungerer

From: Greg Ungerer <gerg@uclinux.org>

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 <gerg@uclinux.org>
---
 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)),					\
+             "dmi" ((USItype)(v)))
+
 #endif
 
 #define __umulsidi3(u, v) \
-- 
1.7.0.4

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] m68knommu: create config options for CPU classes
  2011-06-03  6:43 ` [PATCH 1/2] m68knommu: create config options for CPU classes gerg
@ 2011-06-03 11:15   ` Geert Uytterhoeven
  2011-06-06  1:49     ` Greg Ungerer
                       ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2011-06-03 11:15 UTC (permalink / raw)
  To: gerg; +Cc: linux-m68k, uclinux-dev, Greg Ungerer

On Fri, Jun 3, 2011 at 08:43,  <gerg@snapgear.com> wrote:
> From: Greg Ungerer <gerg@uclinux.org>
>
> 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)

derivative ... and without bitfield instructions.

> . 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.

I'm wondering whether it would help to have Kconfig symbols for the
instruction capabilities as well.
Then you have to document these capabilities in the kconfig definition only,
and can use single (e.g.) #ifdef CONFIG_CPU_HAS_BITFIELDS tests everywhere
else, instead of duplicating the logic at every #ifdef.

> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
> ---
>  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

without bitfield instructions.

> +         System-On-Chip parts, and does not contain a paging MMU.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] m68knommu: create config options for CPU classes
  2011-06-03 11:15   ` Geert Uytterhoeven
@ 2011-06-06  1:49     ` Greg Ungerer
  2011-06-10  3:56     ` Greg Ungerer
  2011-06-23  1:35     ` Greg Ungerer
  2 siblings, 0 replies; 9+ messages in thread
From: Greg Ungerer @ 2011-06-06  1:49 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linux-m68k, uclinux-dev, Greg Ungerer

Hi Geert,

On 03/06/11 21:15, Geert Uytterhoeven wrote:
> On Fri, Jun 3, 2011 at 08:43,<gerg@snapgear.com>  wrote:
>> From: Greg Ungerer<gerg@uclinux.org>
>>
>> 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)
>
> derivative ... and without bitfield instructions.

My spelling never was too good :-)
I'll fix up the comment and add mention of bitfields.


>> . 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.
>
> I'm wondering whether it would help to have Kconfig symbols for the
> instruction capabilities as well.
> Then you have to document these capabilities in the kconfig definition only,
> and can use single (e.g.) #ifdef CONFIG_CPU_HAS_BITFIELDS tests everywhere
> else, instead of duplicating the logic at every #ifdef.

Yes, that sounds like a reasonable idea. I won't add them in this patch
though. I'll add it to the bitops.h merge patch - which is the only
one that would be effected/helped by a bitfield Kconfig option right
now.

Thanks
Greg


>> Signed-off-by: Greg Ungerer<gerg@uclinux.org>
>> ---
>> á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
>
> without bitfield instructions.
>
>> + á á á á System-On-Chip parts, and does not contain a paging MMU.
>
> Gr{oetje,eeting}s,
>
> á á á á á á á á á á á á Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
>
>
>


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] m68knommu: create config options for CPU classes
  2011-06-03 11:15   ` Geert Uytterhoeven
  2011-06-06  1:49     ` Greg Ungerer
@ 2011-06-10  3:56     ` Greg Ungerer
  2011-06-12  9:36       ` Geert Uytterhoeven
  2011-06-23  1:35     ` Greg Ungerer
  2 siblings, 1 reply; 9+ messages in thread
From: Greg Ungerer @ 2011-06-10  3:56 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linux-m68k, uclinux-dev, Greg Ungerer


Hi Geert,

Are you happy enough with these patches the way they are?

The 3 files they directly touch (arch/m68k/lib/memset.c,
memcpy.c and muldi3.c) are not changes based on presence of
bitfield instructions. They should resolve the problem of
building with older compilers.

I have these 2 and the vmlinux.lds_no.S fix to send to
Linus real soon, for 3.0.0.

Regards
Greg



On 03/06/11 21:15, Geert Uytterhoeven wrote:
> On Fri, Jun 3, 2011 at 08:43,<gerg@snapgear.com>  wrote:
>> From: Greg Ungerer<gerg@uclinux.org>
>>
>> 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)
>
> derivative ... and without bitfield instructions.
>
>> . 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.
>
> I'm wondering whether it would help to have Kconfig symbols for the
> instruction capabilities as well.
> Then you have to document these capabilities in the kconfig definition only,
> and can use single (e.g.) #ifdef CONFIG_CPU_HAS_BITFIELDS tests everywhere
> else, instead of duplicating the logic at every #ifdef.
>
>> Signed-off-by: Greg Ungerer<gerg@uclinux.org>
>> ---

------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] m68knommu: create config options for CPU classes
  2011-06-10  3:56     ` Greg Ungerer
@ 2011-06-12  9:36       ` Geert Uytterhoeven
  0 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2011-06-12  9:36 UTC (permalink / raw)
  To: Greg Ungerer; +Cc: linux-m68k, uclinux-dev, Greg Ungerer

Hi Greg.

On Fri, Jun 10, 2011 at 05:56, Greg Ungerer <gerg@snapgear.com> wrote:
> Are you happy enough with these patches the way they are?

Yep.

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] m68knommu: create config options for CPU classes
  2011-06-03 11:15   ` Geert Uytterhoeven
  2011-06-06  1:49     ` Greg Ungerer
  2011-06-10  3:56     ` Greg Ungerer
@ 2011-06-23  1:35     ` Greg Ungerer
  2 siblings, 0 replies; 9+ messages in thread
From: Greg Ungerer @ 2011-06-23  1:35 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linux-m68k, uclinux-dev, Greg Ungerer

Hi Geert,

On 03/06/11 21:15, Geert Uytterhoeven wrote:
> On Fri, Jun 3, 2011 at 08:43,<gerg@snapgear.com>  wrote:
>> From: Greg Ungerer<gerg@uclinux.org>
>>
>> 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)
>
> derivative ... and without bitfield instructions.
>
>> . 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.
>
> I'm wondering whether it would help to have Kconfig symbols for the
> instruction capabilities as well.
> Then you have to document these capabilities in the kconfig definition only,
> and can use single (e.g.) #ifdef CONFIG_CPU_HAS_BITFIELDS tests everywhere
> else, instead of duplicating the logic at every #ifdef.

I have just posted a modified version of the bitops.h merge that
creates and uses a CONFIG_CPU_HAS_BITFIELDS option. The patch is
otherwise the same in terms of changes, just uses this define
for the ifdefs.

If you/others prefer this we can run with this one.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-06-23  1:36 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-03  6:43 [PATCH 0/2] m68knommu: fix cpu optimization conditionals gerg
2011-06-03  6:43 ` gerg
2011-06-03  6:43 ` [PATCH 1/2] m68knommu: create config options for CPU classes gerg
2011-06-03 11:15   ` Geert Uytterhoeven
2011-06-06  1:49     ` Greg Ungerer
2011-06-10  3:56     ` Greg Ungerer
2011-06-12  9:36       ` Geert Uytterhoeven
2011-06-23  1:35     ` Greg Ungerer
2011-06-03  6:43 ` [PATCH 2/2] m68k: use kernel processor defines for conditional optimizations gerg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.