Re: [PATCH] m68k: coldfire: Include the GPIO driver header

[Greg Ungerer]

Hi Geert, Linus,

On 21/8/19 10:50 pm, Geert Uytterhoeven wrote:

On Wed, Aug 21, 2019 at 2:22 PM Greg Ungerer  wrote:

On 21/8/19 5:19 pm, Geert Uytterhoeven wrote:

CC Greg (coldfire)


Thanks Geert.
I am happy to take it via the m68knommu tree if you prefer?


Sounds most logical to me.
Thanks!


Pushed to the for-next branch of the m68knommu git tree.

Regards
Greg




On Wed, Aug 21, 2019 at 9:09 AM Linus Walleij  wrote:

The Coldfire GPIO driver needs to explicitly incldue the
GPIO driver header since it is providing a driver.

Cc: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
---
Geert can you pick this up for m68k?
---
   arch/m68k/coldfire/gpio.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/arch/m68k/coldfire/gpio.c b/arch/m68k/coldfire/gpio.c
index a83898426127..ca26de257871 100644
--- a/arch/m68k/coldfire/gpio.c
+++ b/arch/m68k/coldfire/gpio.c
@@ -9,6 +9,7 @@
   #include 
   #include 
   #include 
+#include 

   #include 
   #include 


Gr{oetje,eeting}s,

 Geert

Re: [PATCH] m68k: coldfire: Include the GPIO driver header

[Greg Ungerer]

On 21/8/19 5:19 pm, Geert Uytterhoeven wrote:

CC Greg (coldfire)


Thanks Geert.
I am happy to take it via the m68knommu tree if you prefer?

Regards
Greg




On Wed, Aug 21, 2019 at 9:09 AM Linus Walleij  wrote:

The Coldfire GPIO driver needs to explicitly incldue the
GPIO driver header since it is providing a driver.

Cc: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
---
Geert can you pick this up for m68k?
---
  arch/m68k/coldfire/gpio.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/m68k/coldfire/gpio.c b/arch/m68k/coldfire/gpio.c
index a83898426127..ca26de257871 100644
--- a/arch/m68k/coldfire/gpio.c
+++ b/arch/m68k/coldfire/gpio.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
--
2.21.0

Re: [PATCH] m68k: fix ColdFire with MMU compile warnings

[Greg Ungerer]

Hi Finn,

On 31/7/19 9:46 pm, Finn Thain wrote:

On Wed, 31 Jul 2019, Geert Uytterhoeven wrote:


On Wed, Jul 31, 2019 at 9:47 AM Finn Thain  wrote:

On Wed, 31 Jul 2019, Greg Ungerer wrote:

No, not sufficient. You still get the following warnings after
just moving that include of atarihw.h:

   CC  arch/m68k/kernel/setup.o
In file included from arch/m68k/kernel/setup_mm.c:48:0,
  from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data'
declared inside parameter list
  extern void mac_irq_enable(struct irq_data *data);
^
./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this
definition or declaration, which is probably not what you want
./arch/m68k/include/asm/macintosh.h:20:36: warning: 'struct irq_data'
declared inside parameter list
  extern void mac_irq_disable(struct irq_data *data);



The warning can be resolved with,

diff --git a/arch/m68k/include/asm/macintosh.h 
b/arch/m68k/include/asm/macintosh.h
index d9a08bed4b12..f653b60f2afc 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@

  #include 
  #include 
+#include 

  #include 

so that macintosh.h could be unconditionally included to avoid some
#ifdefs. That's just BTW. I don't object to your solution.



The MACH_IS_ATARI is not guaranteed to be compile time constant,
depending on what target options you have configured.



Actually, MACH_IS_ATARI is a compile-time constant when CONFIG_ATARI=n.

When I build that file with mac_defconfig and gcc 6.4, the C preprocessor
generates this:

if ((0))
 unknown = amiga_parse_bootinfo(record);
else if ((0))
 unknown = atari_parse_bootinfo(record);
else if ((1))
 unknown = mac_parse_bootinfo(record);
else if ((0))
 unknown = q40_parse_bootinfo(record);
else if ((0))
 unknown = bvme6000_parse_bootinfo(record);
else if ((0))
 unknown = mvme16x_parse_bootinfo(record);
else if ((0))
 unknown = mvme147_parse_bootinfo(record);
else if ((0))
 unknown = hp300_parse_bootinfo(record);
else if ((0))
 unknown = apollo_parse_bootinfo(record);
else
 unknown = 1;

We don't get that "implicit declaration" warning because the function
prototypes are all declared unconditionally at the top of the same file.

Anyway, the warning we were discussing was this one:

arch/m68k/kernel/setup_mm.c: In function 'm68k_nvram_get_size':
arch/m68k/kernel/setup_mm.c:605:10: error: implicit declaration of
function 'atari_nvram_get_size' [-Werror=implicit-function-declaration]
return atari_nvram_get_size();

This warning is the reason why commit d3b41b6bb49e ("m68k: Dispatch
nvram_ops calls to Atari or Mac functions") unconditionally included
atarihw.h.

It's annoying that we can't unconditionally include atarihw.h but I don't
have a solution for that.


The real issue is  including , right?



I take it you meant to write  not .


At first sight, the only reason for that is:

 #define atari_readb   raw_inb
 #define atari_writeb  raw_outb

 #define atari_inb_p   raw_inb
 #define atari_outb_p  raw_outb

Note that the first definition is unused, and the other 3 have only a handful
users.

At second sight, the  include can just be removed, an Atari
kernel still builds fine...

Would that fix the issue?



Yes, it seems so. Thanks.

Here's the patch I tested.

diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 533008262b69..ba1889c1a933 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -22,7 +22,6 @@
  
  #include 

  #include 
-#include 
  #include 
  
  extern u_long atari_mch_cookie;

diff --git a/arch/m68k/include/asm/macintosh.h 
b/arch/m68k/include/asm/macintosh.h
index d9a08bed4b12..f653b60f2afc 100644
--- a/arch/m68k/include/asm/macintosh.h
+++ b/arch/m68k/include/asm/macintosh.h
@@ -4,6 +4,7 @@
  
  #include 

  #include 
+#include 
  
  #include 
  
I built 4 configurations - coldfire (mmu), atari, mac, atari + mac.


It's hard to imagine that removing those extra #defines would be a problem
given that doing so doesn't lead to compiler warnings or errors. The atari
build booted up okay in aranym.


Works for me too. I prefer this solution.

Do you want to resend that patch with commit message and signed-off-by?

Regards
Greg

Re: [PATCH] m68k: fix ColdFire with MMU compile warnings

[Greg Ungerer]

Hi Finn,

On 31/7/19 3:36 pm, Finn Thain wrote:

On Mon, 29 Jul 2019,g...@kernel.org  wrote:


From: Greg Ungerer

Commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari
or Mac functions") causes a number of compile time warnings
to be generated if compiling for a ColdFire MMU enabled target:

In file included from ./arch/m68k/include/asm/atarihw.h:25:0,
  from arch/m68k/kernel/setup_mm.c:41,
  from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined
  #define __raw_readb in_8
  ^
In file included from ./arch/m68k/include/asm/io.h:6:0,
  from arch/m68k/kernel/setup_mm.c:36,
  from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the 
previous definition
  #define __raw_readb(addr) \
  ^
...


It appears that I neglected to build test that patch for coldfire. Sorry
about that.


:-)



The most strait forward fix is to conditionaly include only
those headers actually required, and to only check for
machine types that are configured/enabled into this build.

Signed-off-by: Greg Ungerer
---
  arch/m68k/kernel/setup_mm.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 528484feff80..04853f68f7a8 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -38,14 +38,16 @@
  #ifdef CONFIG_AMIGA
  #include 
  #endif
-#include 
  #ifdef CONFIG_ATARI
+#include 
  #include 
  #endif

Is that change not sufficient to avoid the new warnings?


No, not sufficient. You still get the following warnings after
just moving that include of atarihw.h:

  CC  arch/m68k/kernel/setup.o
In file included from arch/m68k/kernel/setup_mm.c:48:0,
 from arch/m68k/kernel/setup.c:3:
./arch/m68k/include/asm/macintosh.h:19:35: warning: ‘struct irq_data’ declared 
inside parameter list
 extern void mac_irq_enable(struct irq_data *data);
   ^
./arch/m68k/include/asm/macintosh.h:19:35: warning: its scope is only this 
definition or declaration, which is probably not what you want
./arch/m68k/include/asm/macintosh.h:20:36: warning: ‘struct irq_data’ declared 
inside parameter list
 extern void mac_irq_disable(struct irq_data *data);
^



  #ifdef CONFIG_SUN3X
  #include 
  #endif
+#ifdef CONFIG_MAC
  #include 
+#endif
  #include 
  
  #if !FPSTATESIZE || !NR_IRQS

Can we avoid this ifdef?


This ifdef fixes the warnings I listed above.



@@ -602,10 +604,14 @@ static long m68k_nvram_initialize(void)
  
  static ssize_t m68k_nvram_get_size(void)

  {
+#ifdef CONFIG_ATARI
if (MACH_IS_ATARI)
return atari_nvram_get_size();
-   else if (MACH_IS_MAC)
+#endif
+#ifdef CONFIG_MAC
+   if (MACH_IS_MAC)
return mac_pram_get_size();
+#endif

The MACH_IS_ATARI and MACH_IS_MAC macros already appear unconditionally in
this file in m68k_parse_bootinfo(). Can we avoid these ifdefs too?

If the MACH_IS_* macros can no longer be used unconditionally, would it
not be better to find a way to allow this?


It is not the presence of the macros that ends up being the problem.
It is the functions, atari_nvram_get_size() and mac_pram_get_size().

Without these ifdefs here if you try to compile for the mac_defconfig
you get the following errors at compile time:

  CC  arch/m68k/kernel/setup.o
In file included from arch/m68k/kernel/setup.c:3:0:
arch/m68k/kernel/setup_mm.c: In function ‘m68k_nvram_get_size’:
arch/m68k/kernel/setup_mm.c:608:10: error: implicit declaration of function 
‘atari_nvram_get_size’ [-Werror=implicit-function-declaration]
   return atari_nvram_get_size();
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:273: recipe for target 'arch/m68k/kernel/setup.o' failed
make[1]: *** [arch/m68k/kernel/setup.o] Error 1


The MACH_IS_ATARI is not guaranteed to be compile time constant,
depending on what target options you have configured.

Regards
Greg

Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329

[Greg Ungerer]

Hi Joachim,

On 25/7/19 6:26 am, Joachim Dietrich wrote:

There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is
done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.

Signed-off-by: Joachim Dietrich 
Signed-off-by: Geert Uytterhoeven 
---
I (Geert) am not that super familiar with the
CONFIG_COLDFIRE_SW_A7
handling.  According to Section 3.2.3 ("Supervisor/User Stack
Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have
separate
stack pointers, but they're not USP and SSP, like on classic m68k
and
newer Coldfire parts.

Yes, I know he's right. So my description is probably not correct.
But
I'm a little bit confused about the stack pointer handling of
the v3


The stack pointer handling (or really the presence of A7 and
other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.



coldfire, because in the reference manual of the mcf5329 stands:
"To
support dual stack pointers, the following two supervisor
instructions
are included in the ColdFire instruction set architecture to
load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26,
this
was
the default handling for the mcf5329.


That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact
version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction
set.
(So generally speaking old ColdFire parts don't have them, newer
ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.



Hence mcf5329 differs from e.g. mcf5206[2], which has a single
unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed
for.
I don't know if this applies to all mcf532x variants.

It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution
for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?

Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.


The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.

The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.

So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see
arch/m68k/include/asm/m53xxacr.h).

Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?

OK. I will do that. But at first glance everything looks right (in
the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.


Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.

The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.

Can you try the patch below?

I did it,


It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.

but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:

Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.

With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: huh, entered softirq 3 NET_RX (ptrval) with

Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329

[Greg Ungerer]

Hi Joachim,

On 10/7/19 5:04 am, Joachim Dietrich wrote:

On 4/7/19 4:37 am, Joachim Dietrich wrote:

There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is
done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.

Signed-off-by: Joachim Dietrich 
Signed-off-by: Geert Uytterhoeven 
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling.  According to Section 3.2.3 ("Supervisor/User Stack
Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k
and
newer Coldfire parts.

Yes, I know he's right. So my description is probably not correct.
But
I'm a little bit confused about the stack pointer handling of the v3


The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.



coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor
instructions
are included in the ColdFire instruction set architecture to
load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this
was
the default handling for the mcf5329.


That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.



Hence mcf5329 differs from e.g. mcf5206[2], which has a single
unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.

It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution
for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?

Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.


The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.

The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.

So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see
arch/m68k/include/asm/m53xxacr.h).

Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?

OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.


Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.

The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.

Can you try the patch below?

I did it,


It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.

but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:

Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.

With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: 

Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329

[Greg Ungerer]

Hi Joachim,

On 4/7/19 4:37 am, Joachim Dietrich wrote:

There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a
wrong
stack pointer.

Signed-off-by: Joachim Dietrich 
Signed-off-by: Geert Uytterhoeven 
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling.  According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.

Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3


The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.



coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this
was
the default handling for the mcf5329.


That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting
instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones
do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.



Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.

It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs.
OTHER_A7?

Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15)
fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.


The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.

The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.

So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).

Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?

OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.


Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.

The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.

Can you try the patch below?

I did it,


It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.

but for me it looks as if the patch has fixed only the described
problem, but the handling doesn't seem to work quite yet. But let me
explained this in more detail:

Without your patch, the kernel starts until the first user process. Let
this be a simple "Hello World", which prints the argv[0] and argv. In
this case usp points to a wrong address; the user process has no
arguments. No chance to start an init process.

With the new patch, the (same "Hello World") usp seems to points to a
correct address. The arguments are correct. So, I guess the EUSP Bit in
CACR is set.
But when I want to start the BusyBox init then I get a trap:
---
...
[2.78] This architecture does not have kernel memory protection.
[2.78] Run /sbin/init as init process
init started: BusyBox v1.29.3 (2019-06-04 13:30:06 CEST)
[3.31] softirq: huh, entered softirq 3 NET_RX (ptrval) with
preempt_count 01fa, exited with 01f9?
[3.32] softirq: huh, entered softirq 3 NET_RX (ptrval) with

Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329

[Greg Ungerer]

Hi Joachim,

On 3/7/19 5:43 am, Joachim Dietrich wrote:

thank you for your explanations.


From: Joachim Dietrich 

There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.

Signed-off-by: Joachim Dietrich 
Signed-off-by: Geert Uytterhoeven 
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling.  According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.

Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3


The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.



coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this was
the default handling for the mcf5329.


That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.



Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.

It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?

Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15) fails at
rdusp() and wdusp() in processor.h and my first user process has a
wrong sp.


The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.

The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.

So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).

Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?

OK. I will do that. But at first glance everything looks right (in the
code). I'm afraid I'm going to need more analysis on the behavior.
I'll get back to you.


Looking into this further I think I can see at least one problem -
directly related to v3 core cache handling. And this could be
what you are seeing.

The CACR register also has bits to invalidate and flush the caches.
And we use that in the cache control functions in 
arch/m68k/include/asm/cacheflush_no.h
For the v3 cores with the definitions set the way they are we
will be over-writing the CACR value - loosing the EUSP bit setting.

Can you try the patch below?

It will maintain the CACR value while flushing caches.
The most widely used v3 core, the 5307, won't be effected since it
does not support separate A7 registers. The handling of this for
other version cores (v2 and v4) does it correctly already.

Regards
Greg

diff --git a/arch/m68k/include/asm/m53xxacr.h b/arch/m68k/include/asm/m53xxacr.h
index 9138a624c5c8..25b144495234 100644
--- a/arch/m68k/include/asm/m53xxacr.h
+++ b/arch/m68k/include/asm/m53xxacr.h
@@ -89,9 +89,9 @@
  * coherency though in all cases. And for copyback caches we will need
  * to push cached data as well.
  */
-#define CACHE_INIT	  CACR_CINVA
-#define CACHE_INVALIDATE  CACR_CINVA
-#define CACHE_INVALIDATED CACR_CINVA
+#define CACHE_INIT(CACHE_MODE + CACR_CINVA)
+#define CACHE_INVALIDATE  (CACHE_MODE + CACR_CINVA)
+#define CACHE_INVALIDATED (CACHE_MODE + CACR_CINVA)
 
 #define ACR0_MODE	((CONFIG_RAMBASE & 0xff00) + \
 			 (0x000f) + \

Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329

[Greg Ungerer]

Hi Joachim,

On 2/7/19 4:49 am, Joachim Dietrich wrote:

let me add a few remarks.


From: Joachim Dietrich 

There are no separate supervisor and user stack pointers on older
Coldfire CPUs such as the mcf5329.
We, therefore, must enable the use of software copies which is done by
selecting CONFIG_COLDFIRE_SW_A7, else the first user process has a wrong
stack pointer.

Signed-off-by: Joachim Dietrich 
Signed-off-by: Geert Uytterhoeven 
---
I (Geert) am not that super familiar with the CONFIG_COLDFIRE_SW_A7
handling.  According to Section 3.2.3 ("Supervisor/User Stack Pointers
(A7 and OTHER_A7)") of MCF5329RM.pdf[1], mcf5329 does have separate
stack pointers, but they're not USP and SSP, like on classic m68k and
newer Coldfire parts.

Yes, I know he's right. So my description is probably not correct. But
I'm a little bit confused about the stack pointer handling of the v3


The stack pointer handling (or really the presence of A7 and other-A7)
can't be determined only by knowing the version core. There are v3
cores that don't have both A7 registers and some that do.



coldfire, because in the reference manual of the mcf5329 stands: "To
support dual stack pointers, the following two supervisor instructions
are included in the ColdFire instruction set architecture to load/store
the USP:
move.l Ay,USP;move to USP
move.l USP,Ax;move from USP"
And that's what the CONFIG_COLDFIRE_SW_A7 code does in entry.h.
Furthermore, in earlier versions of uclinux, e.g kernel 2.6.26, this was
the default handling for the mcf5329.


That was certainly true of older kernels. I added support for using
both A7 registers in later kernels (I don't remember the exact version
I included it). The addition of 2 A7 registers and supporting instructions
was introduced in the ColdFire ISA_A+ version of the instruction set.
(So generally speaking old ColdFire parts don't have them, newer ones do).
That support introduced the CONFIG_COLDFIRE_SW_A7 define.



Hence mcf5329 differs from e.g. mcf5206[2], which has a single unified
stack pointer, which is what CONFIG_COLDFIRE_SW_A7 is designed for.
I don't know if this applies to all mcf532x variants.

It's quite possible CONFIG_COLDFIRE_SW_A7 is the correct solution for
mcf5329, or perhaps it needs some special handling for A7 vs. OTHER_A7?

Perhaps there's a better or more correct handling for the stack
pointers, but without CONFIG_COLDFIRE_SW_A7 my kernel (4.19.15) fails at
rdusp() and wdusp() in processor.h and my first user process has a wrong sp.


The 5329 supports ColdFire ISA_A+ so it definitely has the A7
and other-A7 support. And is is implemented the same on all ColdFire
parts that support it.

The trick with the dual A7 support is that you have to enable it
in the Cache Control Register (CACR), the EUSP bit. Otherwise you
get traps on those move to and from USP instructions - like what
you are seeing.

So my guess is that CACR is not being setup properly. It is set via
the startup code in arch/m68k/coldfire/head.S - based on whether
CONFIG_COLDFIRE_SW_A7 is defined (see arch/m68k/include/asm/m53xxacr.h).

Can you double check that the CACR register is being set with
the EUSP bit (bit 4) set?

(*) I haven't checked the errata for the 5329, but I assume there
is no known bugs in the silicon in this area.

Regards
Greg




Thanks!

[1] https://www.nxp.com/docs/en/reference-manual/MCF5329RM.pdf
[2] https://www.nxp.com/docs/en/data-sheet/MCF5206UM.pdf
---
  arch/m68k/Kconfig.cpu | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 60ac1cd8b96fb868..e41e74cd1125b8de 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -239,6 +239,7 @@ config M532x
  depends on !MMU
  select M53xx
  select HAVE_CACHE_CB
+    select COLDFIRE_SW_A7
  help
    Freescale (Motorola) ColdFire 532x processor support.



Thanks!
/joachim

Re: [PATCH] m68k: io: Fix io{read,write}{16,32}be() for Coldfire peripherals

[Greg Ungerer]

Hi Angelo,

On 3/6/19 10:26 pm, Angelo Dureghello wrote:

couldn't seen any follow up on this patch. I tested it and at least
for mcf5441x it works properly and solves all issues.

Do you think it may be accepted as an initial fix ?


I'll add it to the m68knommu git tree.
Seeing as you wrote it Geert I assume you have no problem with that?  :-)

Regards
Greg



On Mon, Apr 29, 2019 at 10:19:37AM +0200, Geert Uytterhoeven wrote:

The generic definitions of mmio_{read,write}{16,32}be() in lib/iomap.c
assume that the {read,write}[wl]() I/O accessors always use little
endian accesses, and swap the result.

However, the Coldfire versions of the {read,write}[wl]() I/O accessors are
special, in that they use native big endian instead of little endian for
accesses to the on-SoC peripheral block, thus violating the assumption.

Fix this by providing our own variants, using the raw accessors,
reinstating the old behavior.  This is fine on m68k, as no special
barriers are needed, and also avoids swapping data twice.

Reported-by: Angelo Dureghello 
Fixes: aecc787c06f4300f ("iomap: Use non-raw io functions for 
io{read|write}XXbe")
Signed-off-by: Geert Uytterhoeven 
---
This can be reverted later, after this oddity of the Coldfire I/O
support has been fixed, and drivers have been updated.
---
  arch/m68k/include/asm/io.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index aabe6420ead2a599..d47e7384681ab1cd 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -8,6 +8,12 @@
  #include 
  #endif
  
+#define mmio_read16be(addr)		__raw_readw(addr)

+#define mmio_read32be(addr)__raw_readl(addr)
+
+#define mmio_write16be(val, port)  __raw_writew((val), (port))
+#define mmio_write32be(val, port)  __raw_writel((val), (port))
+
  #include 
  
  #endif /* _M68K_IO_H */

--
2.17.1

Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM

[Greg Ungerer]

Hi Mike,

On 28/5/19 11:24 pm, Mike Rapoport wrote:

Hi,

Any comments on this?

On Thu, May 16, 2019 at 09:03:18AM +0300, Mike Rapoport wrote:

Hi,

These pacthes replace DISCONTIGMEM with SPARSEMEM on m68k for systems with
!SINGLE_MEMORY_CHUNK set.

With SPARSEMEM there is a single node for the entire physical memory and to
cope with holes in the physical address space it is divided to sections of
up to 16M.

Each section has it's own memory map which size depends on actual populated
memory.

The section size of 16M was chosen pretty much arbitrarily as I couldn't
find specs for systems with e.g. Zorro memory extensions.

For the systems with ST-RAM and FastRAM, the switch to SPARSEMEM does not
change the limitation that if the kernel is loaded into the FastRam the
ST-RAM remains unmapped. It only ensures that if the kernel is loaded in
ST-RAM, the memory map is allocated from high physical addresses and then
atari/stram.c is able to reserve the frame buffer memory. If the kernel is
loaded to FastRAM, the ST-RAM remains unmapped as with DISCONTIGMEM and the
atari/stram.c maps it as IOMEM.

v2 changes:
* rebase on the current upstream
* make ColdFire MMU select SINGLE_MEMORY_CHUNK in Kconfig.cpu

Mike Rapoport (3):
   m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM
   m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM
   m68k/mm: switch from DISCONTIGMEM to SPARSEMEM

  arch/m68k/Kconfig.cpu   | 14 ++--
  arch/m68k/include/asm/page.h|  2 ++
  arch/m68k/include/asm/page_mm.h |  6 +++-
  arch/m68k/include/asm/sparsemem.h   |  8 +
  arch/m68k/include/asm/virtconvert.h |  2 +-
  arch/m68k/mm/init.c |  8 ++---
  arch/m68k/mm/motorola.c | 64 ++---
  7 files changed, 84 insertions(+), 20 deletions(-)
  create mode 100644 arch/m68k/include/asm/sparsemem.h


Tested again, works on MMU and no-MMU configurations of ColdFire.
So for the whole series:

Tested-by: Greg Ungerer 
Acked-by: Greg Ungerer 

Thanks
Greg

Re: [RFC/RFT PATCH 3/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM

[Greg Ungerer]

Hi Mike,

On 8/5/19 8:09 pm, Mike Rapoport wrote:

Enable SPARSEMEM support for systems with !SINGLE_MEMORY_CHUNK.
With SPARSEMEM there is a single node for the entire physical memory and to
cope with holes in the physical address space it is divided to sections of
up to 16M.

Each section has it's own memory map which size depends on actual populated
memory.

The DISCONTIGMEM is marked BROKEN and will be removed in a couple of
releases.

Signed-off-by: Mike Rapoport 


This worked for me on no-MMU ColdFire targets, but failed to
boot on an MMU enabled M5475 target. I got no console output
at all. I haven't debugged any further yet.

Regards
Greg



---
  arch/m68k/Kconfig.cpu |  8 +
  arch/m68k/include/asm/sparsemem.h |  8 +
  arch/m68k/mm/motorola.c   | 64 ---
  3 files changed, 69 insertions(+), 11 deletions(-)
  create mode 100644 arch/m68k/include/asm/sparsemem.h

diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 6542e7a5997b..1b056d24c554 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -21,6 +21,7 @@ choice
  config M68KCLASSIC
bool "Classic M68K CPU family support"
select NEED_MULTIPLE_NODES if DISCONTIGMEM
+   select SPARSEMEM_STATIC if SPARSEMEM
  
  config COLDFIRE

bool "Coldfire CPU family support"
@@ -381,8 +382,15 @@ config SINGLE_MEMORY_CHUNK
  some operations.  Say N if not sure.
  
  config ARCH_DISCONTIGMEM_ENABLE

+   def_bool no
+   depends on BROKEN && MMU && !SINGLE_MEMORY_CHUNK
+
+config ARCH_SPARSEMEM_ENABLE
def_bool MMU && !SINGLE_MEMORY_CHUNK
  
+config HAVE_ARCH_PFN_VALID

+   def_bool SPARSEMEM
+
  config 060_WRITETHROUGH
bool "Use write-through caching for 68060 supervisor accesses"
depends on ADVANCED && M68060
diff --git a/arch/m68k/include/asm/sparsemem.h 
b/arch/m68k/include/asm/sparsemem.h
new file mode 100644
index ..6645a6420af9
--- /dev/null
+++ b/arch/m68k/include/asm/sparsemem.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_M68K_SPARSEMEM_H_
+#define _ASM_M68K_SPARSEMEM_H_
+
+#define MAX_PHYSMEM_BITS   32
+#define SECTION_SIZE_BITS  24
+
+#endif /* _ASM_M68K_SPARSEMEM_H_ */
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 356601bf96d9..87d09942be5c 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -207,13 +207,63 @@ static void __init map_node(int node)
  #endif
  }
  
+#ifdef CONFIG_SPARSEMEM

+static void m68k_free_area_init(unsigned long max_addr)
+{
+   unsigned long zones_size[MAX_NR_ZONES] = { 0, };
+   unsigned long zholes_size[MAX_NR_ZONES] = { 0, };
+   unsigned long holes_size;
+
+   m68k_setup_node(0);
+
+   /*
+* Make sure the memory map is allocated from top of the
+* memory.
+* Otherwise for systems with both ST-RAM and FastRam, ST-RAM
+* gets filled with the memory map leaving no space for
+* framebuffer
+*/
+   memblock_set_bottom_up(false);
+   memblocks_present();
+   sparse_init();
+   memblock_set_bottom_up(true);
+
+   zones_size[ZONE_DMA] = max_addr >> PAGE_SHIFT;
+   if (m68k_num_memory > 1) {
+   holes_size = max_addr - memblock_phys_mem_size();
+   zholes_size[ZONE_DMA] = holes_size >> PAGE_SHIFT;
+   }
+
+   free_area_init_node(0, zones_size,
+   m68k_memory[0].addr >> PAGE_SHIFT, zholes_size);
+
+   if (node_present_pages(0))
+   node_set_state(0, N_NORMAL_MEMORY);
+}
+
+#else
+static void m68k_free_area_init(unsigned long max_addr)
+{
+   unsigned long zones_size[MAX_NR_ZONES] = { 0, };
+   int i;
+
+   for (i = 0; i < m68k_num_memory; i++) {
+   m68k_setup_node(i);
+   zones_size[ZONE_DMA] = m68k_memory[i].size >> PAGE_SHIFT;
+   free_area_init_node(i, zones_size,
+   m68k_memory[i].addr >> PAGE_SHIFT, NULL);
+   if (node_present_pages(i))
+   node_set_state(i, N_NORMAL_MEMORY);
+   }
+}
+#endif
+
  /*
   * paging_init() continues the virtual memory environment setup which
   * was begun by the code in arch/head.S.
   */
  void __init paging_init(void)
  {
-   unsigned long zones_size[MAX_NR_ZONES] = { 0, };
unsigned long min_addr, max_addr;
unsigned long addr;
int i;
@@ -272,10 +322,8 @@ void __init paging_init(void)
 */
memblock_set_bottom_up(true);
  
-	for (i = 0; i < m68k_num_memory; i++) {

-   m68k_setup_node(i);
+   for (i = 0; i < m68k_num_memory; i++)
map_node(i);
-   }
  
  	flush_tlb_all();
  
@@ -296,12 +344,6 @@ void __init paging_init(void)

  #ifdef DEBUG
printk ("before free_area_init\n");
  #endif
-   for (i = 0; i < m68k_num_memory; i++) {
-   zones_size[ZONE_DMA] = m68k_memory[i].size >> 

Re: [PATCH 3/3] mmc: enabling ColdFire esdhc controller support

[Greg Ungerer]

Hi Angelo,

On 13/5/19 5:41 am, Angelo Dureghello wrote:

Signed-off-by: Angelo Dureghello 
---
  drivers/mmc/host/Kconfig  | 13 +
  drivers/mmc/host/Makefile |  3 +++
  2 files changed, 16 insertions(+)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 0e86340536b6..91007572a097 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -220,6 +220,19 @@ config MMC_SDHCI_CNS3XXX
  
  	  If unsure, say N.
  
+config MMC_SDHCI_ESDHC_MCF

+   tristate "SDHCI support for the Freescale eSDHC ColdFire controller"
+   depends on M5441x
+   depends on MMC_SDHCI_PLTFM
+   select MMC_SDHCI_IO_ACCESSORS
+   help
+ This selects the Freescale eSDHC/uSDHC controller support
+ found on i.MX25, i.MX35 i.MX5x and i.MX6x.


So you copied/pasted this from the entry for the MMC_SDHCI_ESDHC_IMX driver?

I have not looked at the hardware module of the SHDC controller in
the ColdFire parts, but is it in any way similar or the same as
Freescale uses in the iMX families?

Regards
Greg




+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
  config MMC_SDHCI_ESDHC_IMX
tristate "SDHCI support for the Freescale eSDHC/uSDHC i.MX controller"
depends on ARCH_MXC
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 73578718f119..17c3826dfe81 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
  obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o
  obj-$(CONFIG_MMC_SDHCI_CADENCE)   += sdhci-cadence.o
  obj-$(CONFIG_MMC_SDHCI_CNS3XXX)   += sdhci-cns3xxx.o
+obj-$(CONFIG_MMC_SDHCI_ESDHC_MCF)   += sdhci-esdhc-mcf.o
  obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
  obj-$(CONFIG_MMC_SDHCI_DOVE)  += sdhci-dove.o
  obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
@@ -104,3 +105,5 @@ endif
  
  obj-$(CONFIG_MMC_SDHCI_XENON)	+= sdhci-xenon-driver.o

  sdhci-xenon-driver-y  += sdhci-xenon.o sdhci-xenon-phy.o
+
+CFLAGS_sdhci-esdhc-mcf.o := -DDEBUG

Re: [PATCH 1/3] mmc: add Coldfire esdhc support

[Greg Ungerer]

Hi Angelo,

On 13/5/19 5:41 am, Angelo Dureghello wrote:

This driver has been developed as a separate module starting
from the similar sdhci-esdhc-fls.c.
Separation has been mainly driven from change in endianness.

Signed-off-by: Angelo Dureghello 
---
  drivers/mmc/host/sdhci-esdhc-mcf.c  | 432 
  include/linux/platform_data/mmc-esdhc-mcf.h |  17 +
  2 files changed, 449 insertions(+)
  create mode 100644 drivers/mmc/host/sdhci-esdhc-mcf.c
  create mode 100644 include/linux/platform_data/mmc-esdhc-mcf.h

diff --git a/drivers/mmc/host/sdhci-esdhc-mcf.c 
b/drivers/mmc/host/sdhci-esdhc-mcf.c
new file mode 100644
index ..1ba6e0431813
--- /dev/null
+++ b/drivers/mmc/host/sdhci-esdhc-mcf.c
@@ -0,0 +1,432 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Freescale eSDHC ColdFire family controller driver, platform bus.
+ *
+ * Copyright (c) 2019 Sysam, Italy
+ *   Author: Angelo Dureghello 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 


Is this SHDC hardware modules used in ColdFire parts other than
the m5441x?

For most drivers used across different ColdFire family members
you want to include mcfsim.h, which will ultimately include
the appropriate msim.h file.

Regards
Greg



+#include "sdhci-pltfm.h"
+#include "sdhci-esdhc.h"
+
+#defineESDHC_PROCTL_D3CD   0x08
+#define ESDHC_PROCTL_AI0x20
+#define ESDHC_PROCTL_DTW_MASK  (0x3 << 1)
+#define ESDHC_SYS_CTRL_DTOCV_MASK  0x0f
+#define ESDHC_DEFAULT_HOST_CONTROL 0x28
+
+/*
+ * Freescale eSDHC has DMA ERR omn bit 28, not as std spec says, bit 25.
+ */
+#define ESDHC_INT_VENDOR_SPEC_DMA_ERR  (1 << 28)
+
+struct pltfm_mcf_data {
+   struct mcf_esdhc_platform_data plat_data;
+   struct clk *clk_ipg;
+   struct clk *clk_ahb;
+   struct clk *clk_per;
+   int aside;
+   int current_bus_width;
+};
+
+static inline void esdhc_clrset_be(struct sdhci_host *host,
+  u32 mask, u32 val, int reg)
+{
+   void __iomem *base = host->ioaddr + (reg & ~3);
+   u8 shift = (reg & 3) << 3;
+
+   mask <<= shift;
+   val <<= shift;
+
+   if (reg == SDHCI_HOST_CONTROL)
+   val |= ESDHC_PROCTL_D3CD;
+
+   writel((readl(base) & ~mask) | val, base);
+}
+
+/*
+ * Note: mcf is big-endian, single bytes need to be accessed at big endian
+ * offsets.
+ */
+static void esdhc_mcf_writeb_be(struct sdhci_host *host, u8 val, int reg)
+{
+   void __iomem *base = host->ioaddr + (reg & ~3);
+   u8 shift = (reg & 3) << 3;
+   u32 mask = ~(0xff << shift);
+
+   switch (reg) {
+   case SDHCI_HOST_CONTROL:
+   /*
+* Recomposition needed, restore always endianness and
+* keep D3CD and AI, just setting bus width.
+*/
+   writel(ESDHC_DEFAULT_HOST_CONTROL | (val & 0x6),
+  host->ioaddr + SDHCI_HOST_CONTROL);
+   return;
+   }
+
+   writel((readl(base) & mask) | (val << shift), base);
+}
+
+static void esdhc_mcf_writew_be(struct sdhci_host *host, u16 val, int reg)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct pltfm_mcf_data *mcf_data = sdhci_pltfm_priv(pltfm_host);
+   void __iomem *base = host->ioaddr + (reg & ~3);
+   u8 shift = (reg & 3) << 3;
+   u32 mask = ~(0x << shift);
+
+   switch (reg) {
+   case SDHCI_TRANSFER_MODE:
+   mcf_data->aside = val;
+   return;
+   case SDHCI_COMMAND:
+   /*
+* As for the fsl driver,
+* we have to set the mode in a single write here.
+*/
+   writel(val << 16 | mcf_data->aside,
+  host->ioaddr + SDHCI_TRANSFER_MODE);
+   return;
+   }
+
+   writel((readl(base) & mask) | (val << shift), base);
+}
+
+static void esdhc_mcf_writel(struct sdhci_host *host, u32 val, int reg)
+{
+   u32 data;
+
+   if (unlikely(reg == SDHCI_INT_ENABLE || reg == SDHCI_SIGNAL_ENABLE ||
+   reg == SDHCI_INT_STATUS)) {
+   if (val & SDHCI_INT_CARD_INT) {
+   /*
+* eSDHC issue, errata:
+* ECF218: Misses SDIO interrupt when CINT is disabled
+*/
+   data = readl(host->ioaddr + SDHCI_HOST_CONTROL);
+   data &= ~ESDHC_PROCTL_D3CD;
+   writel(data, host->ioaddr + SDHCI_HOST_CONTROL);
+   data |= ESDHC_PROCTL_D3CD;
+   writel(data, host->ioaddr + SDHCI_HOST_CONTROL);
+   }
+   }
+
+   writel(val, host->ioaddr + reg);
+}
+
+static u8 esdhc_mcf_readb_be(struct sdhci_host *host, int reg)
+{
+   u8 __iomem *base = host->ioaddr + (reg & ~3);
+
+   return base[3 - (reg & 3)];
+}
+
+static u16 esdhc_mcf_readw_be(struct sdhci_host 

Re: endianness swapped

[Greg Ungerer]

Hi Arnd,

On 29/4/19 4:44 am, Arnd Bergmann wrote:

On Sun, Apr 28, 2019 at 3:59 PM Greg Ungerer  wrote:

On 28/4/19 7:21 pm, Arnd Bergmann wrote:

On Sun, Apr 28, 2019 at 10:46 AM Geert Uytterhoeven
 wrote:

On Sat, Apr 27, 2019 at 10:22 PM Angelo Dureghello  wrote:

On Sat, Apr 27, 2019 at 05:32:22PM +0200, Angelo Dureghello wrote:


Coldfire makes the behavior of readw()/readl() depend on the
MMIO address, presumably since that was the easiest way to
get drivers working originally, but it breaks the assumption
in the asm-generic code.


Yes, that is right.

There is a number of common hardware modules that Freescale have
used in the ColdFire SoC parts and in their ARM based parts (iMX
families). The ARM parts are pretty much always little endian, and
the ColdFire is always big endian. The hardware registers in those
hardware blocks are always accessed in native endian of the processor.


In later Freescale/NXP ARM SoCs (i.MX and Layerscape), we
also get a lot of devices pulled over from PowerPC, with random
endianess. In some cases, the same device that had big-endian
registers originally ends up in two different ARM products and one of
them uses big-endian while the other one uses little-endian registers.


So the address range checks are to deal with those internal
hardware blocks (i2c, spi, dma, etc), since we know those are
at fixed addresses. That leaves the usual endian swapping in place for
other general (ie external) devices (PCI devices, network chips, etc).


Is there a complete list of coldfire on-chip device drivers?

Looking at some of the drivers:

- drivers/i2c/busses/i2c-imx.c uses only 8-bit accesses and works either way,
   same for drivers/tty/serial/mcf.c
- drivers/spi/spi-coldfire-qspi.c is apparently coldfire-only and could use
   ioread32be for a portable to do big-endian register access.
- edma-common has a wrapper to support both big-endian and little-endian
   configurations in the same kernel image, but the mcf interrupt handler
   is hardcoded to the (normally) little-endian ioread32 function.
- drivers/net/ethernet/freescale/fec_main.c is shared between coldfire
   and i.MX (but not mpc52xx), and is hardcoded to readl/writel, and
   would need the same trick as edma to make it portable.


That matches up with what we list out in arch/m68k/coldfire/devices.c.
I can't think of any other drivers.

There is a lot of use readl/writel and friends in the architecture
specific code too, in arch/m68k/coldfire. At first I used __raw_readl/
__raw_writel to always get native endianess. But quote a few uses of
readl/writel have crept in over the years.

Regards
Greg

Re: endianness swapped

[Greg Ungerer]

On 28/4/19 7:21 pm, Arnd Bergmann wrote:

On Sun, Apr 28, 2019 at 10:46 AM Geert Uytterhoeven
 wrote:

On Sat, Apr 27, 2019 at 10:22 PM Angelo Dureghello  wrote:

On Sat, Apr 27, 2019 at 05:32:22PM +0200, Angelo Dureghello wrote:

as you may know, i am working on mcf5441x.
Sorry for not following carefully all the threads, but from a certain
kernel version (likely 4.19 or near there), seems ioread32be
reads the bytes swapped in endianness (mcf-edma dma driver not working
anymore).

Has there been a change about this in the architecture I/O access ?
How should i proceed now ? Fixing the DMA driver read/write, or what ?



looks like the reason of my ioread32be now swapped is:

https://patchwork.kernel.org/patch/10766673/

Trying to figure out what to do now.


This is commit aecc787c06f4300f ("iomap: Use non-raw io functions for
io{read|write}XXbe"):

--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -65,8 +65,8 @@ static void bad_io_access(unsigned long port, const
char *access)
  #endif

  #ifndef mmio_read16be
-#define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
-#define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read16be(addr) swab16(readw(addr))
+#define mmio_read32be(addr) swab32(readl(addr))
  #endif

  unsigned int ioread8(void __iomem *addr)
@@ -106,8 +106,8 @@ EXPORT_SYMBOL(ioread32be);
  #endif

  #ifndef mmio_write16be
-#define mmio_write16be(val,port) __raw_writew(be16_to_cpu(val),port)
-#define mmio_write32be(val,port) __raw_writel(be32_to_cpu(val),port)
+#define mmio_write16be(val,port) writew(swab16(val),port)
+#define mmio_write32be(val,port) writel(swab32(val),port)

On big endian, the raw accessors are assumed to be non-swapping,
while non-raw accessors are assumed to be swapping.
The latter is not true for Coldfire internal registers, cfr.
arch/m68k/include/asm/io_no.h:


The raw accessors are always assumed to be non-swapping
in the asm-generic code, while the non-raw ones are assumed to
be little-endian in order for them to work with portable drivers.

We have some other cases of big-endian machines that use
a hardware byteswap on their MMIO buses (iirc some mips
and superh parts), but they then need to swap the __raw_*
accessor data words in software to get back to the normal
behavior, as well as swizzle the address for accesses that are
less than 32 bit wide.

Coldfire makes the behavior of readw()/readl() depend on the
MMIO address, presumably since that was the easiest way to
get drivers working originally, but it breaks the assumption
in the asm-generic code.


Yes, that is right.

There is a number of common hardware modules that Freescale have
used in the ColdFire SoC parts and in their ARM based parts (iMX
families). The ARM parts are pretty much always little endian, and
the ColdFire is always big endian. The hardware registers in those
hardware blocks are always accessed in native endian of the processor.

So the address range checks are to deal with those internal
hardware blocks (i2c, spi, dma, etc), since we know those are
at fixed addresses. That leaves the usual endian swapping in place for
other general (ie external) devices (PCI devices, network chips, etc).



static inline u16 readw(const volatile void __iomem *addr)
{
 if (cf_internalio(addr))
 return __raw_readw(addr);
 return __le16_to_cpu(__raw_readw(addr));
}

Orthogonal to how Coldfire's read[wl]() should be fixed, I find it a bit
questionable to swap data twice on big endian architectures.


I would expect that the compiler is capable of detecting a double
swap and optimize it out. Even if it can't, there are not that many
instances of io{read,write}{16,32}be in the kernel, so the increase
in kernel image size from a double swap should be limited to a
few extra instructions, and the runtime overhead should be
negligible compared to the bus access.


Fortunately we can avoid that by defining our own
mmio_{read,write}{16,32}be()...


Makes sense.

Regards
Greg

[git pull] m68knommu fix for v5.1

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

Only a single change to provide platform side support for the eDMA
hardware module on the ColdFire MCF5441X SoC.

Regards
Greg




The following changes since commit 5908e6b738e3357af42c10e1183753c70a0117a9:

  Linux 5.0-rc8 (2019-02-24 16:46:45 -0800)

are available in the Git repository at:

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

for you to fetch changes up to d7e9d01ac2920959b474c6363dba269a868f4db9:

  m68k: add ColdFire mcf5441x eDMA platform support (2019-02-25 11:04:05 +1000)


Angelo Dureghello (1):
  m68k: add ColdFire mcf5441x eDMA platform support

 arch/m68k/coldfire/device.c   | 81 +++
 arch/m68k/coldfire/m5441x.c   |  4 +-
 arch/m68k/include/asm/m5441xsim.h | 15 
 3 files changed, 98 insertions(+), 2 deletions(-)

Re: [PATCH] m68k: add ColdFire mcf5441x eDMA platform support

[Greg Ungerer]

Hi Angelo,

On 5/2/19 1:53 am, Angelo Dureghello wrote:
[snip]

Many thanks.

I think i found an additional non-functional fix is needed:

arch/m68k/coldfire/device.c line 546, edma "id" should be 0 and not 6.

Fixed and tested here, let me know if you can do that too, or i can send
a v2, as you prefer, not a problem.


No problem, I have fixed and re-pushed to m68knommu git tree for-next branch.
Just to double check, the change was this:

--- /tmp/device.c   2019-02-05 11:30:00.875259680 +1000
+++ /home/gerg/src/linux/git/m68knommu/arch/m68k/coldfire/device.c  
2019-02-05 11:32:38.248684394 +1000
@@ -542,7 +542,7 @@
 
 static struct platform_device mcf_edma = {

.name   = "mcf-edma",
-   .id = 6,
+   .id = 0,
.num_resources  = ARRAY_SIZE(mcf_edma_resources),
.resource   = mcf_edma_resources,
.dev = {


Regards
Greg

Re: [PATCH] m68k: add ColdFire mcf5441x eDMA platform support

[Greg Ungerer]

Hi Angelo,

On 20/1/19 6:14 am, Angelo Dureghello wrote:

This patch adds support for ColdFire eDMA platform driver.


Just a couple of minor formatting things.



Signed-off-by: Angelo Dureghello 
---
  arch/m68k/coldfire/device.c   | 81 +++
  arch/m68k/coldfire/m5441x.c   |  4 +-
  arch/m68k/include/asm/m5441xsim.h | 15 ++
  3 files changed, 98 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 908d58347790..b5d73c60d547 100644
--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -14,11 +14,14 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
  #include 
  #include 
+#include 
+#include 
  
  /*

   *All current ColdFire parts contain from 2, 3, 4 or 10 UARTS.
@@ -476,6 +479,81 @@ static struct platform_device mcf_i2c5 = {
  #endif /* MCFI2C_BASE5 */
  #endif /* IS_ENABLED(CONFIG_I2C_IMX) */
  
+#if IS_ENABLED(CONFIG_MCF_EDMA)

+
+static const struct dma_slave_map mcf_edma_map[] = {
+   { "dreq0", "rx-tx", MCF_EDMA_FILTER_PARAM(0) },
+   { "dreq1", "rx-tx", MCF_EDMA_FILTER_PARAM(1) },
+   { "uart.0", "rx", MCF_EDMA_FILTER_PARAM(2) },
+   { "uart.0", "tx", MCF_EDMA_FILTER_PARAM(3) },
+   { "uart.1", "rx", MCF_EDMA_FILTER_PARAM(4) },
+   { "uart.1", "tx", MCF_EDMA_FILTER_PARAM(5) },
+   { "uart.2", "rx", MCF_EDMA_FILTER_PARAM(6) },
+   { "uart.2", "tx", MCF_EDMA_FILTER_PARAM(7) },
+   { "timer0", "rx-tx", MCF_EDMA_FILTER_PARAM(8) },
+   { "timer1", "rx-tx", MCF_EDMA_FILTER_PARAM(9) },
+   { "timer2", "rx-tx", MCF_EDMA_FILTER_PARAM(10) },
+   { "timer3", "rx-tx", MCF_EDMA_FILTER_PARAM(11) },
+   { "fsl-dspi.0", "rx", MCF_EDMA_FILTER_PARAM(12) },
+   { "fsl-dspi.0", "tx", MCF_EDMA_FILTER_PARAM(13) },
+   { "fsl-dspi.1", "rx", MCF_EDMA_FILTER_PARAM(14) },
+   { "fsl-dspi.1", "tx", MCF_EDMA_FILTER_PARAM(15) },
+};
+
+static struct mcf_edma_platform_data mcf_edma_data = {
+   .dma_channels   = 64,
+   .slave_map  = mcf_edma_map,
+   .slavecnt   = ARRAY_SIZE(mcf_edma_map),
+};
+
+static struct resource mcf_edma_resources[] = {
+   {
+   .start  = MCFEDMA_BASE,
+   .end= MCFEDMA_BASE + MCFEDMA_SIZE - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = MCFEDMA_IRQ_INTR0,
+   .end= MCFEDMA_IRQ_INTR0 + 15,
+   .flags  = IORESOURCE_IRQ,
+   .name   = "edma-tx-00-15",
+   },
+   {
+   .start  = MCFEDMA_IRQ_INTR16,
+   .end= MCFEDMA_IRQ_INTR16 + 39,
+   .flags  = IORESOURCE_IRQ,
+   .name   = "edma-tx-16-55",
+   },
+   {
+   .start  = MCFEDMA_IRQ_INTR56,
+   .end= MCFEDMA_IRQ_INTR56,
+   .flags  = IORESOURCE_IRQ,
+   .name   = "edma-tx-56-63",
+   },
+   {
+   .start  = MCFEDMA_IRQ_ERR,
+   .end= MCFEDMA_IRQ_ERR,
+   .flags  = IORESOURCE_IRQ,
+   .name   = "edma-err",
+   },
+};
+
+static u64 mcf_edma_dmamask = DMA_BIT_MASK(32);
+
+static struct platform_device mcf_edma = {
+   .name   = "mcf-edma",
+   .id = 6,
+   .num_resources  = ARRAY_SIZE(mcf_edma_resources),
+   .resource   = mcf_edma_resources,
+   .dev = {
+   .dma_mask = _edma_dmamask,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data  = _edma_data,

  ^^
TAB instead of space (just that it is inconsistent with the field
members before it).



+   }
+};
+
+#endif /* IS_ENABLED(CONFIG_MCF_EDMA) */
+
  static struct platform_device *mcf_devices[] __initdata = {
_uart,
  #if IS_ENABLED(CONFIG_FEC)
@@ -505,6 +583,9 @@ static struct platform_device *mcf_devices[] __initdata = {
_i2c5,
  #endif
  #endif
+#if IS_ENABLED(CONFIG_MCF_EDMA)
+   _edma,
+#endif
  };
  
  /*

diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 55392af845fb..5bd24c9b865d 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -137,6 +137,8 @@ struct clk *mcf_clks[] = {
  
  static struct clk * const enable_clks[] __initconst = {

/* make sure these clocks are enabled */
+   &__clk_0_15, /* dspi.1 */
+   &__clk_0_17, /* eDMA */
&__clk_0_18, /* intc0 */
&__clk_0_19, /* intc0 */
&__clk_0_20, /* intc0 */
@@ -157,8 +159,6 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_8, /* can.0 */
&__clk_0_9, /* can.1 */
&__clk_0_14, /* i2c.1 */
-   &__clk_0_15, /* dspi.1 */
-   &__clk_0_17, /* eDMA 

Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*

[Greg Ungerer]

Hi Christoph,

On 17/12/18 9:59 pm, Christoph Hellwig wrote:

On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote:

Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work
by virtue of the SoC only having an instruction cache (the older V2 cores).


Is there a good an easy case to detect if a core has a cache?  Either
runtime or in Kconfig?


The MMU case is fixable, but I think it will mean changing away from
the fall-back virtual:physical 1:1 mapping it uses for the kernel address
space. So not completely trivial. Either that or a dedicated area of RAM
for coherent allocations that we can mark as non-cachable via the really
course grained and limited ACR registers - not really very appealing.


What about CF_PAGE_NOCACHE?  Reading arch/m68k/include/asm/mcf_pgtable.h
suggest this would cause an uncached mapping, in which case something
like this should work:


http://git.infradead.org/users/hch/misc.git/commitdiff/4b8711d436e8d56edbc5ca19aa2be639705bbfef


No, that won't work.

The current MMU setup for ColdFire relies on a quirk of the cache
control subsystem to map kernel mapping (actually all of RAM when
accessed in supervisor mode).

The effective address calculation by the CPU/MMU firstly checks
the RAMBAR access, then

From the ColdFire 5475 Reference Manual (section 5.5.1):

  If virtual mode is enabled, any normal mode access that does not hit in the 
MMUBAR,
  RAMBARs, ROMBARs, or ACRs is considered a normal mode virtual address request 
and
  generates its access attributes from the MMU. For this case, the default CACR 
address attributes
  are not used.

The MMUBAR is the MMU control registers, the RAMBAR/ROMBAR are the
internal static RAM/ROM regions and the ACR are the cache control
registers. The code in arch/m68k/coldfire/head.S sets up the ACR
registers so that all of RAM is accessible and cached when in supervisor
mode. So kernel code and data accesses will hit this and use the
address for access. User pages won't hit this and will go through to
hit the MMU mappings.

The net out is we don't need page mappings or use TLB entries
for kernel code/data. The problem is we also can't map individual
regions as not cached for coherent allocations... The ACR mapping
means all-or-nothing.

This leads back to what I mentioned earlier about changing the
VM mapping to not use the ACR mapping method and actually page
mapping the kernel space. Not completely trivial and I expect
there will be a performance hit with the extra TLB pressure and
their setup/remapping overhead.



The noMMU case in general is probably limited to something like that same
type of dedicated RAM/ACR register mechamism.

The most commonly used periperal with DMA is the FEC ethernet module,
and it has some "special" (used very loosely) cache flushing for
parts like the 532x family which probably makes it mostly work right.
There is a PCI bus on the 54xx family of parts, and I know general
ethernet cards on it (like e1000's) have problems I am sure are
related to the fact that coherent memory allocations aren't.


If we really just care about FEC we can just switch it do use
DMA_ATTR_NON_CONSISTENT and do explicit cache flushing.  But as far
as I can tell FEC only uses DMA coherent allocations for the TSO
headers anyway, is TSO even used on this SOC?


The FEC is the most commonly used, but not the only. I test generic PCI
NICs on the PCI bus on the ColdFire 5475 - and a lot of those drivers
rely on coherent allocations.

Regards
Greg

Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*

[Greg Ungerer]

On 14/12/18 9:47 pm, Christoph Hellwig wrote:

On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:

-   page = alloc_pages(flag, order);
+   page = alloc_pages(flag | GFP_ZERO, order);
 if (!page)
 return NULL;


There's second implementation below, which calls __get_free_pages() and
does an explicit memset().  As __get_free_pages() calls alloc_pages(), perhaps
it makes sense to replace the memset() by GFP_ZERO, to increase consistency?


It would, but this patch really tries to be minimally invasive to just
provide the zeroing everywhere.  There is plenty of opportunity
to improve the m68k dma allocator if I can get enough reviewers/testers:

  - for one the coldfire/nommu case absolutely does not make sense to
me as there is not work done at all to make sure the memory is
mapped uncached despite the architecture implementing cache
flushing for the map interface.  So this whole implementation
looks broken to me and will need some major work (I had a previous
discussion with Greg on that which needs to be dug out)


Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work
by virtue of the SoC only having an instruction cache (the older V2 cores).

The MMU case is fixable, but I think it will mean changing away from
the fall-back virtual:physical 1:1 mapping it uses for the kernel address
space. So not completely trivial. Either that or a dedicated area of RAM
for coherent allocations that we can mark as non-cachable via the really
course grained and limited ACR registers - not really very appealing.

The noMMU case in general is probably limited to something like that same
type of dedicated RAM/ACR register mechamism.

The most commonly used periperal with DMA is the FEC ethernet module,
and it has some "special" (used very loosely) cache flushing for
parts like the 532x family which probably makes it mostly work right.
There is a PCI bus on the 54xx family of parts, and I know general
ethernet cards on it (like e1000's) have problems I am sure are
related to the fact that coherent memory allocations aren't.

I do plan to have a look at this for the MMU case some time soon.

Regards
Greg





  - the "regular" implementation in this patch should probably be replaced
with the generic remapping helpers that have been added for the 4.21
merge window:


http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/0c3b3171ceccb8830c2bb5adff1b4e9b204c1450

Compile tested only patch below:

--

From ade86dc75b9850daf9111ebf9ce15825a6144f2d Mon Sep 17 00:00:00 2001

From: Christoph Hellwig 
Date: Fri, 14 Dec 2018 12:41:45 +0100
Subject: m68k: use the generic dma coherent remap allocator

This switche to using common code for the DMA allocations, including
potential use of the CMA allocator if configure.  Also add a few
comments where the existing behavior seems to be lacking.

Signed-off-by: Christoph Hellwig 
---
  arch/m68k/Kconfig  |  2 ++
  arch/m68k/kernel/dma.c | 64 --
  2 files changed, 20 insertions(+), 46 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 8a5868e9a3a0..60788cf02fbc 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -2,10 +2,12 @@
  config M68K
bool
default y
+   select ARCH_HAS_DMA_MMAP_PGPROT if MMU && !COLDFIRE
select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_NO_PREEMPT if !COLDFIRE
+   select DMA_DIRECT_REMAP if MMU && !COLDFIRE
select HAVE_IDE
select HAVE_AOUT if MMU
select HAVE_DEBUG_BUGVERBOSE
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index dafe99d08a6a..16da5d96e228 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -18,57 +18,29 @@
  #include 
  
  #if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)

-
-void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
-   gfp_t flag, unsigned long attrs)
+void arch_dma_prep_coherent(struct page *page, size_t size)
  {
-   struct page *page, **map;
-   pgprot_t pgprot;
-   void *addr;
-   int i, order;
-
-   pr_debug("dma_alloc_coherent: %d,%x\n", size, flag);
-
-   size = PAGE_ALIGN(size);
-   order = get_order(size);
-
-   page = alloc_pages(flag | GFP_ZERO, order);
-   if (!page)
-   return NULL;
-
-   *handle = page_to_phys(page);
-   map = kmalloc(sizeof(struct page *) << order, flag & ~__GFP_DMA);
-   if (!map) {
-   __free_pages(page, order);
-   return NULL;
-   }
-   split_page(page, order);
-
-   order = 1 << order;
-   size >>= PAGE_SHIFT;
-   map[0] = page;
-   for (i = 1; i < size; i++)
-   map[i] = page + i;
-   for (; i < order; i++)
-   __free_page(page + i);
-   pgprot = 

Re: [PATCH v6 3/6] m68k: coldfire: Add clk_get_optional() function

[Greg Ungerer]

Hi Christoph,

On 30/11/18 2:32 am, Christoph Hellwig wrote:

On Thu, Nov 29, 2018 at 09:54:37PM +1000, Greg Ungerer wrote:

Hi Phil,

On 17/11/18 12:59 am, Phil Edworthy wrote:

clk_get_optional() returns NULL if not found instead of -ENOENT,
otherwise the behaviour is the same as clk_get().

Signed-off-by: Phil Edworthy 


Acked-by: Greg Ungerer 

Looks good. Do you want me to take this in the m68knommu git tree?
Or is the whole series going through some other tree?


Any chance we could just get coldfire moved over to the common clock
framework?


Sure, I will have a look at it.

Regards
Greg

Re: [PATCH v6 3/6] m68k: coldfire: Add clk_get_optional() function

[Greg Ungerer]

Hi Phil,

On 29/11/18 10:02 pm, Phil Edworthy wrote:

On 29 November 2018 11:55, Greg Ungerer wrote:

On 17/11/18 12:59 am, Phil Edworthy wrote:

clk_get_optional() returns NULL if not found instead of -ENOENT,
otherwise the behaviour is the same as clk_get().

Signed-off-by: Phil Edworthy 


Acked-by: Greg Ungerer 

Looks good. Do you want me to take this in the m68knommu git tree?
Or is the whole series going through some other tree?

This patch is no longer needed as I found a better way to implement this:
[PATCH v8] clk: Add (devm_)clk_get_optional() functions
https://patchwork.kernel.org/patch/10690437/

Apologies for any confusion,


No problem, I'll just drop it then.

Regards
Greg



---
   arch/m68k/coldfire/clk.c | 11 +++
   1 file changed, 11 insertions(+)

diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c index
7bc666e482eb..b221cabc7f54 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -87,6 +87,17 @@ struct clk *clk_get(struct device *dev, const char *id)
   }
   EXPORT_SYMBOL(clk_get);

+struct clk *clk_get_optional(struct device *dev, const char *id) {
+   struct clk *clk = clk_get(dev, id);
+
+   if (clk == ERR_PTR(-ENOENT))
+   clk = NULL;
+
+   return clk;
+}
+EXPORT_SYMBOL(clk_get_optional);
+
   int clk_enable(struct clk *clk)
   {
unsigned long flags;

Re: [PATCH v6 3/6] m68k: coldfire: Add clk_get_optional() function

[Greg Ungerer]

Hi Phil,

On 17/11/18 12:59 am, Phil Edworthy wrote:

clk_get_optional() returns NULL if not found instead of -ENOENT,
otherwise the behaviour is the same as clk_get().

Signed-off-by: Phil Edworthy 


Acked-by: Greg Ungerer 

Looks good. Do you want me to take this in the m68knommu git tree?
Or is the whole series going through some other tree?

Regards
Greg




---
  arch/m68k/coldfire/clk.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 7bc666e482eb..b221cabc7f54 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -87,6 +87,17 @@ struct clk *clk_get(struct device *dev, const char *id)
  }
  EXPORT_SYMBOL(clk_get);
  
+struct clk *clk_get_optional(struct device *dev, const char *id)

+{
+   struct clk *clk = clk_get(dev, id);
+
+   if (clk == ERR_PTR(-ENOENT))
+   clk = NULL;
+
+   return clk;
+}
+EXPORT_SYMBOL(clk_get_optional);
+
  int clk_enable(struct clk *clk)
  {
unsigned long flags;

Re: m68k using deprecated internal APIs?

[Greg Ungerer]

On 17/11/18 5:44 am, Geert Uytterhoeven wrote:

Hi Linus,

On Fri, Nov 16, 2018 at 12:13 PM Linus Walleij  wrote:

On Fri, Nov 16, 2018 at 1:31 AM Finn Thain  wrote:

On Wed, 14 Nov 2018, Linus Walleij wrote:

Apart from this (which is the most important step!) I think the custom
LED heartbeat code in kernel/time.c needs to be replaced with a standard
drivers/leds driver for each LED using the "heartbeat" trigger as is
custom these days.

That should clean out another chunk of legacy time-related code.


Are you referring to LED heartbeat code in arch/m68k/kernel/time.c?


I suppose you are currently keeping the call to timer_interrupt() for
exactly this reason (i.e. keep the heartbeat LED blinking)?


It would be great to have that call inlined, which the compiler can't do
at the moment, because timer_interrupt() is in a different compilation
unit (arch/m68k/kernel/time.c).

Is there some other benefit to eliminating the call to timer_interrupt()
that I've overlooked?


I mean that whole thing should go away by abstracting those LEDs
(for the systems that have them) using the struct led_classdev,
populating a proper platform device for it and instantiate using
a driver in drivers/leds/*, and the function to provide the heartbeat
be replaced with the existing heartbeat trigger in
drivers/leds/trigger/ledtrig-heartbeat.c assigned as default
trigger for that LED.

I think that is WAY out of the focus for your current work (which,
by the way, is a piece of art) but more something for the m68k
maintainers to look into.


Just going with struct led_classdev is probably doable.
Going for the full monty, using leds-gpio, probably requires moving m68k
to DT.  Which would not be that ... uninteresting ;-)


I have been thinking about a move to DT for a while for ColdFire.
There are lots of common hardware device blocks that would fit really
neatly into a DT framework.

Regards
Greg

[git pull] m68knommu fix for v4.20

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

Only a single change to fix an out of bounds array access when
parsing boot command line.

Regards
Greg




The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e:

  Linux 4.19-rc8 (2018-10-15 07:20:24 +0200)

are available in the Git repository at:

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

for you to fetch changes up to 381fdd62c38344a771aed06adaf14aae65c47454:

  m68k: fix command-line parsing when passed from u-boot (2018-10-16 09:46:02 
+1000)


Angelo Dureghello (1):
  m68k: fix command-line parsing when passed from u-boot

 arch/m68k/kernel/uboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: m68k using deprecated internal APIs?

[Greg Ungerer]

Hi Arnd,

On 28/10/18 1:54 am, Arnd Bergmann wrote:

On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven  wrote:


Hi Arnd,

https://lwn.net/Articles/769468/ wrote:

  For example, the m68k architecture uses a number of internal APIs that no 
other
architecture needs at this point; removing that architecture would enable 
removing
the APIs as well


and


Ted Ts'o suggested that an ultimatum could be made: either the m68k architecture
stops using the old, deprecated timer API (for example) within one year or it is
removed from the kernel.


Which APIs are these exactly?


The example I gave was GENERIC_CLOCKEVENTS on m68, which is
supported on most but not all machines there. This is also missing on
a couple of others (ia64 at least, not sure what else). Another one would
be having CLKDEV_LOOKUP without COMMON_CLK. This one is not
a problem for m68k but is for a couple of ARM and MIPS platforms
that have not yet been converted to COMMON_CLK.

There are probably a couple more like this. I don't actually see any that
are /only/ used by m68k, but there are some interfaces that would be
good to stop using overall to keep things simpler.


I have been working on and maintaining parts of m68k for a long time,
and I was not aware that there was a number of problem areas that are
causing real pain. Maybe a friendly email from subsystem maintainers that
see issues would go a long way. At least if the m68k (and other arch)
communities know they can work toward solutions sooner rather than later.

Talk of ultimatums seems a bit heavy handed when only one side seems
to be aware there is a problem.

Regards
Greg

Re: [PATCH v2 0/5] System call table generation support

[Greg Ungerer]

Hi Firoz,

On 21/09/18 01:06, Firoz Khan wrote:

The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.

2. It is easy to unify the system call implementation across all
the architectures.

The system call tables are in different format in all architecture
and it will be difficult to manually add or modify the system calls
in the respective files manually. To make it easy by keeping a script
and which'll generate the header file and syscall table file so this
change will unify them across all architectures.

syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.

Adding a new table entry consisting of:
 - System call number.
 - ABI.
 - System call name.
 - Entry point name.
 - Compat entry name, if required.

ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.

I have done the same support for work for alpha, microblaze, sparc,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/

Added an extra patch to keep __IGNORE* entries in asm/unistd.h.

Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.

Firoz Khan (5):
   m68k: Rename system call table file name
   m68k: Replace NR_syscalls macro from asm/unistd.h
   m68k: Added system call table generation support
   m68k: uapi header and system call table file generation
   m68k: added __IGNORE* entries in asm/unistd.h


Built and tested on a couple of m68k/ColdFire targets,
m520x (no MMU) and m5475 (with MMU). Load and run on real hardware,
no problems found. So for m68knommu/ColdFire:

Tested-by: Greg Ungerer 

Regards
Greg



  arch/m68k/Makefile  |   3 +
  arch/m68k/include/asm/Kbuild|   1 +
  arch/m68k/include/asm/unistd.h  |  10 +-
  arch/m68k/include/uapi/asm/Kbuild   |   1 +
  arch/m68k/include/uapi/asm/unistd.h | 385 +-
  arch/m68k/kernel/Makefile   |   2 +-
  arch/m68k/kernel/syscall_table.S|  14 ++
  arch/m68k/kernel/syscalls/Makefile  |  37 +++
  arch/m68k/kernel/syscalls/syscall.tbl   | 369 +
  arch/m68k/kernel/syscalls/syscallhdr.sh |  39 
  arch/m68k/kernel/syscalls/syscalltbl.sh |  28 +++
  arch/m68k/kernel/syscalltable.S | 403 
  12 files changed, 502 insertions(+), 790 deletions(-)
  create mode 100644 arch/m68k/kernel/syscall_table.S
  create mode 100644 arch/m68k/kernel/syscalls/Makefile
  create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
  create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
  create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
  delete mode 100644 arch/m68k/kernel/syscalltable.S

Re: [PATCH v2] m68k: fix command-line parsing when passed from u-boot

[Greg Ungerer]

Hi Angelo,

On 07/09/18 22:44, Angelo Dureghello wrote:

This patch fixes command_line array zero-terminated
one byte over the end of the array, causing boot to hang.

Signed-off-by: Angelo Dureghello 


Thanks, that looks like that might be it.
Pushed to the for-next branch of the m68knommu git tree.

Regards
Greg



---
  arch/m68k/kernel/uboot.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/kernel/uboot.c b/arch/m68k/kernel/uboot.c
index b29c3b241e1b..107082877064 100644
--- a/arch/m68k/kernel/uboot.c
+++ b/arch/m68k/kernel/uboot.c
@@ -102,5 +102,5 @@ __init void process_uboot_commandline(char *commandp, int 
size)
}
  
  	parse_uboot_commandline(commandp, len);

-   commandp[size - 1] = 0;
+   commandp[len - 1] = 0;
  }

Re: [PATCH] m68k: fix command-line parsing when passed from u-boot

[Greg Ungerer]

Hi Angelo,

On 05/09/18 05:41, Angelo Dureghello wrote:

please drop this patch.
Issue is not related to additional spaces in the command
line, nor to init.data initializaitons.

It seems qiute hard to track down, issue disappears if i
just add some lines of code in uboot.c or setup.c.


Thanks for the update. Will do.

Regards
Greg



Continuing on this.

Regards,
Angelo Dureghello


On Sat, Sep 01, 2018 at 03:16:21AM +0200, Angelo Dureghello wrote:

Without MMU, when CONFIG_UBOOT is set, and CONFIG_BOOTPARAM
is not set, a wrong command-line was produced (boot hangs,
no console), due to an initial erroneus space appended to the
command line in process_uboot_commandline().

In MMU mode, the m68k_command_line array was not initially
terminated to zero, and process_uboot_commandline() was still
producing an invalid command-line (boot hangs, no console).

Signed-off-by: Angelo Dureghello 
---
  arch/m68k/kernel/setup_mm.c |  1 +
  arch/m68k/kernel/setup_no.c |  2 ++
  arch/m68k/kernel/uboot.c| 16 ++--
  3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 5d3596c180f9..8fc2999f11fe 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -265,6 +265,7 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long)_edata;
init_mm.brk = (unsigned long)_end;
  
+	m68k_command_line[0] = 0;

  #if defined(CONFIG_BOOTPARAM)
strncpy(m68k_command_line, CONFIG_BOOTPARAM_STRING, CL_SIZE);
m68k_command_line[CL_SIZE - 1] = 0;
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index cfd5475bfc31..d65bb433583c 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -94,6 +94,8 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) &_edata;
init_mm.brk = (unsigned long) 0;
  
+	command_line[0] = 0;

+
config_BSP(_line[0], sizeof(command_line));
  
  #if defined(CONFIG_BOOTPARAM)

diff --git a/arch/m68k/kernel/uboot.c b/arch/m68k/kernel/uboot.c
index b29c3b241e1b..c4045bbe0a8c 100644
--- a/arch/m68k/kernel/uboot.c
+++ b/arch/m68k/kernel/uboot.c
@@ -92,13 +92,17 @@ __init void process_uboot_commandline(char *commandp, int 
size)
  {
int len, n;
  
+	len = size;

+
n = strnlen(commandp, size);
-   commandp += n;
-   len = size - n;
-   if (len) {
-   /* Add the whitespace separator */
-   *commandp++ = ' ';
-   len--;
+   if (n) {
+   commandp += n;
+   len -= n;
+   if (len) {
+   /* Add the whitespace separator */
+   *commandp++ = ' ';
+   len--;
+   }
}
  
  	parse_uboot_commandline(commandp, len);

--
2.18.0

Re: [PATCH] m68k: fix early memory reservation for ColdFire MMU systems

[Greg Ungerer]

Hi Geert, Mike,

On 21/08/18 22:16, Geert Uytterhoeven wrote:

Hi Mike,

On Mon, Aug 20, 2018 at 7:25 AM Mike Rapoport  wrote:

The bootmem to memblock conversion introduced by the commit 1008a11590b9
("m68k: switch to MEMBLOCK + NO_BOOTMEM") made reservation of kernel code
and data to start from a wrong address.

Fix it.


Thanks for fixing this!


Signed-off-by: Mike Rapoport 
Tested-by: Angelo Dureghello 


Reviewed-by: Geert Uytterhoeven 

Greg: Do you plan to take this?


Yes, I will take this via the m68knommu tree.
Once the merge window closes I will push it into the for-linus and for-next 
branches.

Regards
Greg

[git pull] m68knommu fixes for v4.19

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

Only two changes. One cleans up warnings in the ColdFire DMA code,
the other stubs out (with warnings) ColdFire clock api functions not
normally used.

Regards
Greg



The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:

  Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 58064e1f46b174e108c11323c2b1011064fd3efe:

  m68knommu: Fix typos in Coldfire 5272 DMA debug code (2018-07-30 09:15:01 
+1000)


Geert Uytterhoeven (2):
  m68k: coldfire: Normalize clk API
  m68knommu: Fix typos in Coldfire 5272 DMA debug code

 arch/m68k/coldfire/clk.c| 29 +
 arch/m68k/include/asm/dma.h |  4 ++--
 2 files changed, 31 insertions(+), 2 deletions(-)

Re: [PATCH 0/5] m68k: IO Fixes and Cleanups

[Greg Ungerer]

Hi Geert,

On 09/07/18 19:30, Geert Uytterhoeven wrote:

Hi all,

This patch series contains fixes and cleanups for I/O accessors on m68k
platforms (with MMU).

The first patch contains small fixes without any dependencies.
Patches 2 and 3 make small adjustments to drivers that are dependencies
for further cleanup.
Patch 4 and 5 complete the cleanup.

Changes compared to v1:
   - Move ARCH_HAS_IOREMAP_WT to fix "ioremap_wt redefined" warnings with
 m5475evb defconfig,
   - Add Acked-by.

Given the dependencies, I think it's easiest if the respective
maintainers would provide their Acked-by, so all patches can go in
through the m68k tree.


Retested on ColdFire 5475, looks good.
For the whole series:

Acked-by: Greg Ungerer 

Regards
Greg




Thanks!

Geert Uytterhoeven (5):
   m68k/io: Add missing ioremap define guards, fix typo
   net: mac8390: Use standard memcpy_{from,to}io()
   Input: hilkbd - Add casts to HP9000/300 I/O accessors
   m68k/io: Move mem*io define guards to 
   m68k/io: Switch mmu variant to 

  arch/m68k/include/asm/io.h  |  7 +
  arch/m68k/include/asm/io_mm.h   | 42 +++--
  arch/m68k/include/asm/io_no.h   | 12 -
  arch/m68k/include/asm/kmap.h|  9 ++-
  drivers/input/keyboard/hilkbd.c |  4 +--
  drivers/net/ethernet/8390/mac8390.c | 20 +++---
  6 files changed, 30 insertions(+), 64 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Greg Ungerer]

Hi Mike,

On 04/07/18 16:28, Mike Rapoport wrote:

These patches switch m68k boot time memory allocators from bootmem to
memblock + no_bootmem.

The first two patches update __ffs() and __va() definitions to be inline
with other arches and asm-generic. This is required to avoid compilation
warnings in mm/memblock.c and mm/nobootmem.c.

The third patch performs the actual switch of the boot time mm. Its
changelog has detailed description of the changes.

I've tested the !MMU version with qemu-system-m68k -M mcf5208evb
and the MMU version with q800 using qemu from [1].

I've also build tested allyesconfig and *_defconfig.

[1] https://github.com/vivier/qemu-m68k.git

v2:
* fix reservation of the kernel text/data/bss for ColdFire MMU


I am happy with all of these, so for me:

Acked-by: Greg Ungerer 

Regards
Greg




Mike Rapoport (3):
   m68k/bitops: convert __ffs to match generic declaration
   m68k/page_no.h: force __va argument to be unsigned long
   m68k: switch to MEMBLOCK + NO_BOOTMEM

  arch/m68k/Kconfig   |  3 +++
  arch/m68k/include/asm/bitops.h  |  8 ++--
  arch/m68k/include/asm/page_no.h |  2 +-
  arch/m68k/kernel/setup_mm.c | 14 --
  arch/m68k/kernel/setup_no.c | 20 
  arch/m68k/mm/init.c |  1 -
  arch/m68k/mm/mcfmmu.c   | 13 +++--
  arch/m68k/mm/motorola.c | 35 +++
  arch/m68k/sun3/config.c |  4 
  9 files changed, 36 insertions(+), 64 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Greg Ungerer]

Hi Mike,

On 04/07/18 14:22, Mike Rapoport wrote:

On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote:

On 04/07/18 11:39, Greg Ungerer wrote:

On 03/07/18 20:29, Mike Rapoport wrote:

In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.

The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.

Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped

Signed-off-by: Mike Rapoport 


This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.

The M5475 is a ColdFire with MMU enabled target.


With some early serial debug trace I see:

Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version 
5.4.0 (GCC)) #5 Wed Jul 4 12:00:03 AEST 2018
On node 0 totalpages: 4096
   DMA zone: 18 pages used for memmap
   DMA zone: 0 pages reserved
   DMA zone: 4096 pages, LIFO batch:0
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping off.  Total pages: 4078
Kernel command line: root=/dev/mtdblock0
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Sorting __ex_table...
Memory: 3032K/32768K available (1489K kernel code, 96K rwdata, 240K rodata, 56K 
init, 77K bss, 29736K reserved, 0K cma-reserved)


  ^^
It seems I was over enthusiastic when I reserved the memory for the kernel.
Can you please try with the below patch:

diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index e9e60e1..18c7bf6 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void)
high_memory = (void *)_ramend;
  
  	/* Reserve kernel text/data/bss */

-   memblock_reserve(memstart, _ramend - memstart);
+   memblock_reserve(memstart, memstart - _rambase);
  
  	m68k_virt_to_node_shift = fls(_ramend - 1) - 6;

module_fixup(NULL, __start_fixup, __stop_fixup);
diff --git a/mm/memblock.c b/mm/memblock.c
index 03d48d8..98661be 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -54,7 +54,7 @@ struct memblock memblock __initdata_memblock = {
.current_limit  = MEMBLOCK_ALLOC_ANYWHERE,
  };
  
-int memblock_debug __initdata_memblock;

+int memblock_debug __initdata_memblock = 1;
  static bool system_has_some_mirror __initdata_memblock = false;
  static int memblock_can_resize __initdata_memblock;
  static int memblock_memory_in_slab __initdata_memblock = 0;


The memblock hunk is needed to see early memblock debug messages as all the
setup happens before parsing of the command line.


Ok, that works, boots all the way up now.

Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version 
5.4.0 (GCC)) #7 Wed Jul 4 14:34:48 AEST 2018
memblock_add: [0x-0x01ff] 0x001ebaa0
memblock_reserve: [0x00332000-0x00663fff] 0x001ebafa
memblock_reserve: [0x01ffe000-0x01ff] 0x001efd38
memblock_reserve: [0x01ff8000-0x01ffdfff] 0x001efd38
memblock_virt_alloc_try_nid_nopanic: 147456 bytes align=0x0 nid=0 from=0x0 
max_addr=0x0 0x00190dea
memblock_reserve: [0x01fd4000-0x01ff7fff] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 4 bytes align=0x0 nid=0 from=0x0 
max_addr=0x0 0x001ee234
memblock_reserve: [0x01fd3ff0-0x01fd3ff3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 
0x001ea488
memblock_reserve: [0x01fd3fd0-0x01fd3fe3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 
0x001ea4a8
memblock_reserve: [0x01fd3fb0-0x01fd3fc3] 0x001f0466
memblock_virt_alloc_try_nid: 20 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 
0x001ea4c0
memblock_reserve: [0x01fd3f90-0x01fd3fa3] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 8192 bytes align=0x2000 nid=-1 from=0x0 
max_addr=0x0 0x001eef30
memblock_reserve: [0x01fd-0x01fd1fff] 0x001f0466
memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x2000 nid=-1 from=0x0 
max_addr=0x0 0x001ef5d6
memblock_reserve: [0x01fc8000-0x01fc] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 
0x001ef2ac
memblock_reserve: [0x01fd3f80-0x01fd3f83] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 
0x001ef2c2
memblock_reserve: [0x01fd3f70-0x01fd3f73] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 
0x001ef2d6
memblock_reserve: [0x01fd3f60-0x01fd3f63] 0x001f0466
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Greg Ungerer]

Hi Mike,

On 04/07/18 11:39, Greg Ungerer wrote:

On 03/07/18 20:29, Mike Rapoport wrote:

In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.

The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.

Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped

Signed-off-by: Mike Rapoport 


This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.

The M5475 is a ColdFire with MMU enabled target.


With some early serial debug trace I see:

Linux version 4.18.0-rc3-3-g109f5e551b18-dirty (gerg@goober) (gcc version 
5.4.0 (GCC)) #5 Wed Jul 4 12:00:03 AEST 2018
On node 0 totalpages: 4096
  DMA zone: 18 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4096 pages, LIFO batch:0
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping off.  Total pages: 4078
Kernel command line: root=/dev/mtdblock0
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Sorting __ex_table...
Memory: 3032K/32768K available (1489K kernel code, 96K rwdata, 240K rodata, 56K 
init, 77K bss, 29736K reserved, 0K cma-reserved)
SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
NR_IRQS: 256
clocksource: slt: mask: 0x max_cycles: 0x, max_idle_ns: 
14370379300 ns
Calibrating delay loop... 264.19 BogoMIPS (lpj=1320960)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
1911260446275 ns
ColdFire: PCI bus initialization...
Coldfire: PCI IO/config window mapped to 0xe000
PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x-0x]
pci_bus :00: root bus resource [mem 0x-0x]
pci_bus :00: root bus resource [bus 00-ff]
pci :00:14.0: [8086:1229] type 00 class 0x02
pci :00:14.0: reg 0x10: [mem 0x-0x0fff]
pci :00:14.0: reg 0x14: [io  0x-0x003f]
pci :00:14.0: reg 0x18: [mem 0x-0x000f]
pci :00:14.0: reg 0x30: [mem 0x-0x000f pref]
pci :00:14.0: supports D1 D2
pci :00:14.0: PME# supported from D0 D1 D2 D3hot
pci :00:14.0: BAR 2: assigned [mem 0xf000-0xf00f]
pci :00:14.0: BAR 6: assigned [mem 0xf010-0xf01f pref]
pci :00:14.0: BAR 0: assigned [mem 0xf020-0xf0200fff]
pci :00:14.0: BAR 1: assigned [io  0x0400-0x043f]
vgaarb: loaded
clocksource: Switched to clocksource slt
PCI: CLS 32 bytes, default 16
workingset: timestamp_bits=27 max_order=9 bucket_order=0
kobject_add_internal failed for slab (error: -12 parent: kernel)
Cannot register slab subsystem.
romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
kobject_add_internal failed for ptyp0 (error: -12 parent: tty)
Kernel panic - not syncing: Couldn't register pty driver
CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc3-3-g109f5e551b18-dirty #5
Stack from 00283ee4:
00283ee4 001bc27a 000287ea 0019075c 0019 001f5390 0018ba36 002c6a00
002c6a80 0014ab82 00148816 001f2c2a 001b948c  001f2ad0 001f6ce8
0002118e 00283f8c 000211b4 0006 0019 001f5390 0018ba36 0007
 001f53cc 00305fb0 0002118e 0003df6a  0006 0006
00305fb0 00305fb5 001ea7f6 001ba406 00305fb0 001d1c58 0019 0006
0006  0003df6a 001ea804 001f2ad0  001e5964 00282001
Call Trace:
[<000287ea>] 0x000287ea
 [<0019075c>] 0x0019075c
 [<0018ba36>] 0x0018ba36
 [<0014ab82>] 0x0014ab82
 [<00148816>] 0x00148816

[<001f2c2a>] 0x001f2c2a
 [<001f2ad0>] 0x001f2ad0
 [<0002118e>] 0x0002118e
 [<000211b4>] 0x000211b4
 [<0018ba36>] 0x0018ba36

[<0002118e>] 0x0002118e
 [<0003df6a>] 0x0003df6a
 [<001ea7f6>] 0x001ea7f6
 [<0003df6a>] 0x0003df6a
 [<001ea804>] 0x001ea804

[<001f2ad0>] 0x001f2ad0
 [<00190bae>] 0x00190bae
 [<00190bb6>] 0x00190bb6
 [<00190bae>] 0x00190bae
 [<00021aac>] 0x00021aac

---[ end Kernel panic - not syncing: Couldn't register pty driver ]---
random: fast init done

Regards
Greg




---
  arch/m68k/Kconfig   |  3 +++
  arch/m68k/kernel/setup_mm.c | 14 --
  arch/m68k/kernel/setup_no.c | 20 ---

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Greg Ungerer]

Hi Mike,

On 03/07/18 20:29, Mike Rapoport wrote:

In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.

The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.

Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock because otherwise we will
attempt to access memory that not yet mapped

Signed-off-by: Mike Rapoport 


This builds cleanly for me with a m5475_defconfig, but it fails
to boot on real hardware. No console, no nothing on startup.
I haven't debugged any further yet.

The M5475 is a ColdFire with MMU enabled target.

Regards
Greg



---
  arch/m68k/Kconfig   |  3 +++
  arch/m68k/kernel/setup_mm.c | 14 --
  arch/m68k/kernel/setup_no.c | 20 
  arch/m68k/mm/init.c |  1 -
  arch/m68k/mm/mcfmmu.c   | 11 +++
  arch/m68k/mm/motorola.c | 35 +++
  arch/m68k/sun3/config.c |  4 
  7 files changed, 29 insertions(+), 59 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 785612b..bd7f38a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -24,6 +24,9 @@ config M68K
select MODULES_USE_ELF_RELA
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+   select HAVE_MEMBLOCK
+   select ARCH_DISCARD_MEMBLOCK
+   select NO_BOOTMEM
  
  config CPU_BIG_ENDIAN

def_bool y
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index f35e3eb..6512955 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -165,6 +166,8 @@ static void __init m68k_parse_bootinfo(const struct 
bi_record *record)
be32_to_cpu(m->addr);
m68k_memory[m68k_num_memory].size =
be32_to_cpu(m->size);
+   memblock_add(m68k_memory[m68k_num_memory].addr,
+m68k_memory[m68k_num_memory].size);
m68k_num_memory++;
} else
pr_warn("%s: too many memory chunks\n",
@@ -224,10 +227,6 @@ static void __init m68k_parse_bootinfo(const struct 
bi_record *record)
  
  void __init setup_arch(char **cmdline_p)

  {
-#ifndef CONFIG_SUN3
-   int i;
-#endif
-
/* The bootinfo is located right after the kernel */
if (!CPU_IS_COLDFIRE)
m68k_parse_bootinfo((const struct bi_record *)_end);
@@ -356,14 +355,9 @@ void __init setup_arch(char **cmdline_p)
  #endif
  
  #ifndef CONFIG_SUN3

-   for (i = 1; i < m68k_num_memory; i++)
-   free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
- m68k_memory[i].size);
  #ifdef CONFIG_BLK_DEV_INITRD
if (m68k_ramdisk.size) {
-   
reserve_bootmem_node(__virt_to_node(phys_to_virt(m68k_ramdisk.addr)),
-m68k_ramdisk.addr, m68k_ramdisk.size,
-BOOTMEM_DEFAULT);
+   memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
initrd_end = initrd_start + m68k_ramdisk.size;
pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index a98af10..3e8d87a 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -86,8 +87,6 @@ void (*mach_power_off)(void);
  
  void __init setup_arch(char **cmdline_p)

  {
-   int bootmap_size;
-
memory_start = PAGE_ALIGN(_ramstart);
memory_end = _ramend;
  
@@ -142,6 +141,8 @@ void __init setup_arch(char **cmdline_p)

pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
 __bss_stop, memory_start, memory_start, memory_end);
  
+	memblock_add(memory_start, memory_end - memory_start);

+
/* Keep a copy of command line */
*cmdline_p = _line[0];
memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
@@ -158,23 +159,10 @@ void __init setup_arch(char **cmdline_p)
min_low_pfn = PFN_DOWN(memory_start);
max_pfn = max_low_pfn = PFN_DOWN(memory_end);
  
-	bootmap_size = init_bootmem_node(

-   NODE_DATA(0),
-   min_low_pfn,/* map goes here */
-   PFN_DOWN(PAGE_OFFSET),
-   max_pfn);
-   /*

Re: [PATCH 0/5] m68k: IO Fixes and Cleanups

[Greg Ungerer]

Hi Geert,

On 02/07/18 23:35, Geert Uytterhoeven wrote:

Hi all,

This patch series contains fixes and cleanups for I/O accessors on m68k
platforms (with MMU).

The first patch contains small fixes without any dependencies.
Patches 2 and 3 make small adjustments to drivers that are dependencies
for further cleanup.
Patch 4 and 5 complete the cleanup.

Given the dependencies, I think it's easiest if the respective
maintainers would provide their Acked-by, so all patches can go in
through the m68k tree.

Thanks for your comments!


I like it alot. If we can just fix up the warnings caused by patch
number 1 I am more than happy to ack.

Regards
Greg



Geert Uytterhoeven (5):
   m68k/io: Add missing ioremap define guards, fix typo
   net: mac8390: Use standard memcpy_{from,to}io()
   Input: hilkbd - Add casts to HP9000/300 I/O accessors
   m68k/io: Move mem*io define guards to 
   m68k/io: Switch mmu variant to 

  arch/m68k/include/asm/io.h  |  7 +
  arch/m68k/include/asm/io_mm.h   | 40 +++--
  arch/m68k/include/asm/io_no.h   | 12 -
  arch/m68k/include/asm/kmap.h|  7 -
  drivers/input/keyboard/hilkbd.c |  4 +--
  drivers/net/ethernet/8390/mac8390.c | 20 +++
  6 files changed, 28 insertions(+), 62 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] m68k/io: Add missing ioremap define guards, fix typo

[Greg Ungerer]

Hi Geert,

On 02/07/18 23:35, Geert Uytterhoeven wrote:

   - Add missing define guard for ioremap_wt(),
   - Fix typo s/ioremap_fillcache/ioremap_fullcache/,
   - Add define guard for iounmap() for consistency with other
 architectures.

Fixes: 9746882f547d2f00 ("m68k: group io mapping definitions and functions")
Signed-off-by: Geert Uytterhoeven 


If I build for the m5475evb defconfig then I get warnings like this:

  CC  init/main.o
In file included from ./include/asm-generic/io.h:19:0,
 from ./arch/m68k/include/asm/io_no.h:147,
 from ./arch/m68k/include/asm/io.h:3,
 from ./include/linux/bio.h:28,
 from ./include/linux/blkdev.h:21,
 from init/main.c:80:
./include/asm-generic/iomap.h:79:0: warning: "ioremap_wt" redefined
 #define ioremap_wt ioremap_nocache
 ^
In file included from ./arch/m68k/include/asm/io_no.h:145:0,
 from ./arch/m68k/include/asm/io.h:3,
 from ./include/linux/bio.h:28,
 from ./include/linux/blkdev.h:21,
 from init/main.c:80:
./arch/m68k/include/asm/kmap.h:37:0: note: this is the location of the previous 
definition
 #define ioremap_wt ioremap_wt
 ^

Regards
Greg



---
  arch/m68k/include/asm/kmap.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
index 84b8333db8ad1987..bf1026def698f21f 100644
--- a/arch/m68k/include/asm/kmap.h
+++ b/arch/m68k/include/asm/kmap.h
@@ -16,6 +16,7 @@
   */
  extern void __iomem *__ioremap(unsigned long physaddr, unsigned long size,
   int cacheflag);
+#define iounmap iounmap
  extern void iounmap(void __iomem *addr);
  extern void __iounmap(void *addr, unsigned long size);
  
@@ -33,13 +34,14 @@ static inline void __iomem *ioremap_nocache(unsigned long physaddr,

  }
  
  #define ioremap_uc ioremap_nocache

+#define ioremap_wt ioremap_wt
  static inline void __iomem *ioremap_wt(unsigned long physaddr,
   unsigned long size)
  {
return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
  }
  
-#define ioremap_fillcache ioremap_fullcache

+#define ioremap_fullcache ioremap_fullcache
  static inline void __iomem *ioremap_fullcache(unsigned long physaddr,
  unsigned long size)
  {


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git pull] m68knommu fixes for v4.18

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-linus branch.

It contains a single fix, for breakage introduced in 4.18-rc1.

Regards
Greg




The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:

  Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)

are available in the Git repository at:

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

for you to fetch changes up to ecd60532e060e45c63c57ecf1c8549b1d656d34d:

  m68k: fix "bad page state" oops on ColdFire boot (2018-07-02 10:05:13 +1000)

----
Greg Ungerer (1):
  m68k: fix "bad page state" oops on ColdFire boot

 arch/m68k/include/asm/mcf_pgalloc.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] m68knommu: Fix typos in Coldfire 5272 DMA debug code

[Greg Ungerer]

Hi Geert,

On 22/06/18 16:35, Geert Uytterhoeven wrote:

On Fri, Jun 22, 2018 at 2:20 AM Greg Ungerer  wrote:

On 22/06/18 06:30, Geert Uytterhoeven wrote:

If DEBUG_DMA is defined:

  include/asm/dma.h: In function ‘set_dma_mode’:
  include/asm/dma.h:393: error: ‘dmabp’ undeclared (first use in this 
function)
  include/asm/dma.h:393: error: (Each undeclared identifier is reported 
only once
  include/asm/dma.h:393: error: for each function it appears in.)
  include/asm/dma.h: In function ‘set_dma_addr’:
  include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this 
function)

Reported-by: kbuild test robot 
Signed-off-by: Geert Uytterhoeven 
Acked-by: Greg Ungerer 


Do you want me to take this via the m68knommu git tree?


Yes please. Thx!


Done!

Regards
Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] m68knommu: Fix typos in Coldfire 5272 DMA debug code

[Greg Ungerer]

Hi Geert,

On 22/06/18 06:30, Geert Uytterhoeven wrote:

If DEBUG_DMA is defined:

 include/asm/dma.h: In function ‘set_dma_mode’:
 include/asm/dma.h:393: error: ‘dmabp’ undeclared (first use in this 
function)
 include/asm/dma.h:393: error: (Each undeclared identifier is reported only 
once
 include/asm/dma.h:393: error: for each function it appears in.)
 include/asm/dma.h: In function ‘set_dma_addr’:
 include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this 
function)

Reported-by: kbuild test robot 
Signed-off-by: Geert Uytterhoeven 
Acked-by: Greg Ungerer 


Do you want me to take this via the m68knommu git tree?

Regards
Greg



---
v2:
   - Add Acked-by.
---
  arch/m68k/include/asm/dma.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/include/asm/dma.h b/arch/m68k/include/asm/dma.h
index b0978a23bad1d7ee..ae2021964e32d36f 100644
--- a/arch/m68k/include/asm/dma.h
+++ b/arch/m68k/include/asm/dma.h
@@ -390,7 +390,7 @@ static __inline__ void set_dma_mode(unsigned int dmanr, 
char mode)
  
  #ifdef DEBUG_DMA

printk("%s(%d): dmanr=%d DMR[%x]=%x DIR[%x]=%x\n", __FILE__, __LINE__,
- dmanr, (int) [MCFDMA_DMR], dmabp[MCFDMA_DMR],
+dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
 (int) [MCFDMA_DIR], dmawp[MCFDMA_DIR]);
  #endif
  }
@@ -421,7 +421,7 @@ static __inline__ void set_dma_addr(unsigned int dmanr, 
unsigned int a)
  
  #ifdef DEBUG_DMA

printk("%s(%d): dmanr=%d DMR[%x]=%x SAR[%x]=%08x DAR[%x]=%08x\n",
-   __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmawp[MCFDMA_DMR],
+   __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DSAR], dmalp[MCFDMA_DSAR],
(int) [MCFDMA_DDAR], dmalp[MCFDMA_DDAR]);
  #endif


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: coldfire/m68knommu dma coherency

[Greg Ungerer]

On 20/06/18 18:27, Christoph Hellwig wrote:

On Wed, Jun 20, 2018 at 05:04:00PM +1000, Greg Ungerer wrote:

The fec drivers uses dma_alloc_coherent for the TX descriptors,
but I don't really see any manual cache maintainance in it.
What do I miss?


No, your right, I missed that. I don't see anything in the ColdFire
doco that indicates that there is any coherency on the FEC module
on the more advanced parts with cache. So I suspect that is a real
problem (not one that anyone has reported in practice yet though...)


Or these devices always hit the

if (((unsigned long)bufaddr) & fep->tx_align ||
 fep->quirks & FEC_QUIRK_SWAP_FRAME) {

case?


Possibly also that in no-MMU mode the normal cache mode on
ColdFire is write-through, so no real need for a cache flush.

There is also at least one odd looking flush on the receive path:

#ifdef CONFIG_M532x
flush_cache_all();
#endif

And the general cache flushing support functions are not really
very fine grained for ColdFire anyway.

Regards
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] m68k: use generic dma_noncoherent_ops

[Greg Ungerer]

On 20/06/18 18:19, Christoph Hellwig wrote:

Switch to the generic noncoherent direct mapping implementation.

Signed-off-by: Christoph Hellwig 


Reviewed for and tested on m68k/ColdFire targets, no problems found.
So from me:

Reviewed-by: Greg Ungerer 
Tested-by: Greg Ungerer 

Regards
Greg




---
  arch/m68k/Kconfig   |  2 +
  arch/m68k/include/asm/Kbuild|  1 +
  arch/m68k/include/asm/dma-mapping.h | 12 -
  arch/m68k/kernel/dma.c  | 68 -
  4 files changed, 11 insertions(+), 72 deletions(-)
  delete mode 100644 arch/m68k/include/asm/dma-mapping.h

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 785612b576f7..3f61327da2d5 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -2,6 +2,7 @@
  config M68K
bool
default y
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select HAVE_IDE
@@ -24,6 +25,7 @@ config M68K
select MODULES_USE_ELF_RELA
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+   select DMA_NONCOHERENT_OPS if HAS_DMA
  
  config CPU_BIG_ENDIAN

def_bool y
diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
index 4d8d68c4e3dd..a4b8d3331a9e 100644
--- a/arch/m68k/include/asm/Kbuild
+++ b/arch/m68k/include/asm/Kbuild
@@ -1,6 +1,7 @@
  generic-y += barrier.h
  generic-y += compat.h
  generic-y += device.h
+generic-y += dma-mapping.h
  generic-y += emergency-restart.h
  generic-y += exec.h
  generic-y += extable.h
diff --git a/arch/m68k/include/asm/dma-mapping.h 
b/arch/m68k/include/asm/dma-mapping.h
deleted file mode 100644
index e3722ed04fbb..
--- a/arch/m68k/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _M68K_DMA_MAPPING_H
-#define _M68K_DMA_MAPPING_H
-
-extern const struct dma_map_ops m68k_dma_ops;
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
-return _dma_ops;
-}
-
-#endif  /* _M68K_DMA_MAPPING_H */
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index 463572c4943f..e3c57d6b 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -6,7 +6,7 @@
  
  #undef DEBUG
  
-#include 

+#include 
  #include 
  #include 
  #include 
@@ -19,7 +19,7 @@
  
  #if defined(CONFIG_MMU) && !defined(CONFIG_COLDFIRE)
  
-static void *m68k_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,

+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
gfp_t flag, unsigned long attrs)
  {
struct page *page, **map;
@@ -62,7 +62,7 @@ static void *m68k_dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
return addr;
  }
  
-static void m68k_dma_free(struct device *dev, size_t size, void *addr,

+void arch_dma_free(struct device *dev, size_t size, void *addr,
dma_addr_t handle, unsigned long attrs)
  {
pr_debug("dma_free_coherent: %p, %x\n", addr, handle);
@@ -73,8 +73,8 @@ static void m68k_dma_free(struct device *dev, size_t size, 
void *addr,
  
  #include 
  
-static void *m68k_dma_alloc(struct device *dev, size_t size,

-   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   gfp_t gfp, unsigned long attrs)
  {
void *ret;
  
@@ -89,7 +89,7 @@ static void *m68k_dma_alloc(struct device *dev, size_t size,

return ret;
  }
  
-static void m68k_dma_free(struct device *dev, size_t size, void *vaddr,

+void arch_dma_free(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle, unsigned long attrs)
  {
free_pages((unsigned long)vaddr, get_order(size));
@@ -97,8 +97,8 @@ static void m68k_dma_free(struct device *dev, size_t size, 
void *vaddr,
  
  #endif /* CONFIG_MMU && !CONFIG_COLDFIRE */
  
-static void m68k_dma_sync_single_for_device(struct device *dev,

-   dma_addr_t handle, size_t size, enum dma_data_direction dir)
+void arch_sync_dma_for_device(struct device *dev, phys_addr_t handle,
+   size_t size, enum dma_data_direction dir)
  {
switch (dir) {
case DMA_BIDIRECTIONAL:
@@ -115,58 +115,6 @@ static void m68k_dma_sync_single_for_device(struct device 
*dev,
}
  }
  
-static void m68k_dma_sync_sg_for_device(struct device *dev,

-   struct scatterlist *sglist, int nents, enum dma_data_direction 
dir)
-{
-   int i;
-   struct scatterlist *sg;
-
-   for_each_sg(sglist, sg, nents, i) {
-   dma_sync_single_for_device(dev, sg->dma_address, sg->length,
-  dir);
-   }
-}
-
-static dma_addr_t m68k_dma_map_page(struct device *dev, struct page *page,
-   unsigned long offset, size_t s

Re: coldfire/m68knommu dma coherency

[Greg Ungerer]

Hi Christoph,

On 20/06/18 00:21, Christoph Hellwig wrote:

On Tue, Jun 19, 2018 at 11:06:19PM +1000, Greg Ungerer wrote:

For the nommu case there is no magic because there is no underlying
pages or page table entries to set any control bits for. There is no
fine grained control, just a couple of cache enabled regions (such as
all of RAM) and some bulk control (such as invalidate and clear).

But it does still require cache maintenance for dma operations. For
example the drivers/net/ethernet/freescale/fec_main.c driver is
common on ColdFire SoC parts and it needs to do all the appropriate
dma operations to work right. Though on some of the older simpler
parts (5752 for example) there ins only instruction cache and you
don't have to do dma operations on it.


Well, if there is no data cache everything is coherent.  For those
parts we should be using dma_direct_ops.  If there is a data cache
dma_alloc_coherent needs to make sure we bypass it.  If we can't
do that we need to fail normal coherent request and only allow
allocations with the DMA_ATTR_NON_CONSISTENT flag.


Ok, yep. That is going to be the case for some ColdFire parts.
That wasn't added to that alloc code when we started supporting
ColdFire parts with more advanced caching mechanisms. Outside of
the FEC driver there has not been a lot of devices that use DMA
on these platforms.



The fec drivers uses dma_alloc_coherent for the TX descriptors,
but I don't really see any manual cache maintainance in it.
What do I miss?


No, your right, I missed that. I don't see anything in the ColdFire
doco that indicates that there is any coherency on the FEC module
on the more advanced parts with cache. So I suspect that is a real
problem (not one that anyone has reported in practice yet though...)

Regards
Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] m68k: remove unused set_clock_mmss() helpers

[Greg Ungerer]

Hi Arnd,

On 19/06/18 00:05, Arnd Bergmann wrote:

Commit 397ac99c6cef ("m68k: remove dead timer code") removed set_rtc_mmss()
because it was unused in 2012. However, this was itself the only user of the
mach_set_clock_mmss() callback and the many implementations of that callback,
which are equally unused.

This removes all of those as well.

Signed-off-by: Arnd Bergmann 


This looks good to me:

Acked-by: Greg Ungerer 

Regards
Greg



---
  arch/m68k/apollo/config.c   |  8 --
  arch/m68k/atari/config.c|  5 
  arch/m68k/atari/time.c  | 63 -
  arch/m68k/bvme6000/config.c | 45 -
  arch/m68k/include/asm/machdep.h |  1 -
  arch/m68k/kernel/setup_mm.c |  1 -
  arch/m68k/kernel/setup_no.c |  1 -
  arch/m68k/mac/config.c  |  2 --
  arch/m68k/mac/misc.c| 16 ---
  arch/m68k/mvme147/config.c  |  7 -
  arch/m68k/mvme16x/config.c  |  8 --
  arch/m68k/q40/config.c  | 30 
  12 files changed, 187 deletions(-)

diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index b2a6bc63f8cd..aef8d42e078d 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -31,7 +31,6 @@ extern void dn_sched_init(irq_handler_t handler);
  extern void dn_init_IRQ(void);
  extern u32 dn_gettimeoffset(void);
  extern int dn_dummy_hwclk(int, struct rtc_time *);
-extern int dn_dummy_set_clock_mmss(unsigned long);
  extern void dn_dummy_reset(void);
  #ifdef CONFIG_HEARTBEAT
  static void dn_heartbeat(int on);
@@ -156,7 +155,6 @@ void __init config_apollo(void)
arch_gettimeoffset   = dn_gettimeoffset;
mach_max_dma_address = 0x;
mach_hwclk   = dn_dummy_hwclk; /* */
-   mach_set_clock_mmss  = dn_dummy_set_clock_mmss; /* */
mach_reset   = dn_dummy_reset;  /* */
  #ifdef CONFIG_HEARTBEAT
mach_heartbeat = dn_heartbeat;
@@ -240,12 +238,6 @@ int dn_dummy_hwclk(int op, struct rtc_time *t) {
  
  }
  
-int dn_dummy_set_clock_mmss(unsigned long nowtime)

-{
-   pr_info("set_clock_mmss\n");
-   return 0;
-}
-
  void dn_dummy_reset(void) {
  
dn_serial_print("The end !\n");

diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index 565c6f06ab0b..bd96702a1ad0 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -81,9 +81,6 @@ extern void atari_sched_init(irq_handler_t);
  extern u32 atari_gettimeoffset(void);
  extern int atari_mste_hwclk (int, struct rtc_time *);
  extern int atari_tt_hwclk (int, struct rtc_time *);
-extern int atari_mste_set_clock_mmss (unsigned long);
-extern int atari_tt_set_clock_mmss (unsigned long);
-
  
  /* ++roman: This is a more elaborate test for an SCC chip, since the plain

   * Medusa board generates DTACK at the SCC's standard addresses, but a SCC
@@ -362,13 +359,11 @@ void __init config_atari(void)
ATARIHW_SET(TT_CLK);
pr_cont(" TT_CLK");
mach_hwclk = atari_tt_hwclk;
-   mach_set_clock_mmss = atari_tt_set_clock_mmss;
}
if (hwreg_present(_rtc.sec_ones)) {
ATARIHW_SET(MSTE_CLK);
pr_cont(" MSTE_CLK");
mach_hwclk = atari_mste_hwclk;
-   mach_set_clock_mmss = atari_mste_set_clock_mmss;
}
if (!MACH_IS_MEDUSA && hwreg_present(_wd.fdc_speed) &&
hwreg_write(_wd.fdc_speed, 0)) {
diff --git a/arch/m68k/atari/time.c b/arch/m68k/atari/time.c
index c549b48174ec..9cca64286464 100644
--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -285,69 +285,6 @@ int atari_tt_hwclk( int op, struct rtc_time *t )
  return( 0 );
  }
  
-

-int atari_mste_set_clock_mmss (unsigned long nowtime)
-{
-short real_seconds = nowtime % 60, real_minutes = (nowtime / 60) % 60;
-struct MSTE_RTC val;
-unsigned char rtc_minutes;
-
-mste_read();
-rtc_minutes= val.min_ones + val.min_tens * 10;
-if ((rtc_minutes < real_minutes
- ? real_minutes - rtc_minutes
- : rtc_minutes - real_minutes) < 30)
-{
-val.sec_ones = real_seconds % 10;
-val.sec_tens = real_seconds / 10;
-val.min_ones = real_minutes % 10;
-val.min_tens = real_minutes / 10;
-mste_write();
-}
-else
-return -1;
-return 0;
-}
-
-int atari_tt_set_clock_mmss (unsigned long nowtime)
-{
-int retval = 0;
-short real_seconds = nowtime % 60, real_minutes = (nowtime / 60) % 60;
-unsigned char save_control, save_freq_select, rtc_minutes;
-
-save_control = RTC_READ (RTC_CONTROL); /* tell the clock it's being set */
-RTC_WRITE (RTC_CONTROL, save_control | RTC_SET);
-
-save_freq_select = RTC_READ (RTC_FREQ_SELECT); /* stop and reset prescaler 
*/
-RTC_WRITE (RTC_FREQ_SELECT, save_freq_select | RTC_DIV_RESET2);
-
-rtc_m

Re: coldfire/m68knommu dma coherency

[Greg Ungerer]

Hi Christoph,

On 19/06/18 17:07, Christoph Hellwig wrote:

m68 is normally not dma cache coherent, and thus requires invalidating
or writing back caches in DMA, which is handled in the
m68k_dma_sync_single_for_device routine.  For coherent mappings the
code sets up a non-cachable mapping in m68k_dma_alloc.

Except that for the nommu or coldfire code it doesn't and just does
a plain old page allocation without any caching magic.  Does this
mean coldfire and the nommu case in general do not actually require
cache coherency and don't need the cache maintainance on the dma
mapping operations either?


For the nommu case there is no magic because there is no underlying
pages or page table entries to set any control bits for. There is no
fine grained control, just a couple of cache enabled regions (such as
all of RAM) and some bulk control (such as invalidate and clear).

But it does still require cache maintenance for dma operations. For
example the drivers/net/ethernet/freescale/fec_main.c driver is
common on ColdFire SoC parts and it needs to do all the appropriate
dma operations to work right. Though on some of the older simpler
parts (5752 for example) there ins only instruction cache and you
don't have to do dma operations on it.

For the ColdFire with MMU enabled case I am not entirely sure
now why we don't go through something similar in m68k_dma_alloc()
as the classic m68k CPUs do.

Regards
Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] m68k: fix "bad page state" oops on ColdFire boot

[Greg Ungerer]

Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):

 BUG: Bad page state in process sh  pfn:01ce2
 page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
 flags: 0x0()
 raw:    fbff  0100 0200 
 raw: 039c4000
 page dumped because: nonzero mapcount
 Modules linked in:
 CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13

Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.

Note that I had to change the type of pte_free() to be static from
extern. Otherwise you get a lot of warnings like this:

./arch/m68k/include/asm/mcf_pgalloc.h:80:2: warning: ‘pgtable_page_dtor’ is 
static but used in inline function ‘pte_free’ which is not static
  pgtable_page_dtor(page);
  ^

And making it static is consistent with our use of this in the other
m68k pgalloc definitions of pte_free().

Signed-off-by: Greg Ungerer 
CC: Matthew Wilcox 
---
 arch/m68k/include/asm/mcf_pgalloc.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

v2: add a call to pgtable_page_dtor() in pte_free() as well

diff --git a/arch/m68k/include/asm/mcf_pgalloc.h 
b/arch/m68k/include/asm/mcf_pgalloc.h
index 8b707c249026..12fe700632f4 100644
--- a/arch/m68k/include/asm/mcf_pgalloc.h
+++ b/arch/m68k/include/asm/mcf_pgalloc.h
@@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned 
long address)
 static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
  unsigned long address)
 {
+   pgtable_page_dtor(page);
__free_page(page);
 }
 
@@ -74,8 +75,9 @@ static inline struct page *pte_alloc_one(struct mm_struct *mm,
return page;
 }
 
-extern inline void pte_free(struct mm_struct *mm, struct page *page)
+static inline void pte_free(struct mm_struct *mm, struct page *page)
 {
+   pgtable_page_dtor(page);
__free_page(page);
 }
 
-- 
2.17.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mcf54415, mmu issues with last 4.18.0

[Greg Ungerer]

Hi Angelo,

On 19/06/18 08:19, Angelo Dureghello wrote:

after rebasing to master today, i am experiencing the following
issue:

[2.66] mcfuart.0: ttyS3 at MMIO 0xfc06c000 (irq = 93, base_baud = 
750) is a ColdFire UART
[2.70] m25p80 spi0.1: is25lp128 (16384 Kbytes)
[2.71] Creating 3 MTD partitions on "is25lp128":
[2.71] 0x-0x0010 : "U-Boot (1024K)"
[2.73] 0x0010-0x0080 : "Kernel+initramfs (7168K)"
[2.76] 0x0080-0x0100 : "Flash Free Space (8192K)"
[2.79] Freeing unused kernel memory: 328K
[2.80] This architecture does not have kernel memory protection.
[2.97] BUG: Bad page state in process mount  pfn:23dff
[2.97] page:402f97dc count:0 mapcount:-1024 mapping: index:0x0
[2.97] flags: 0x0()
[2.97] raw:  0100 0200    
fbff 
[2.97] raw: 47bfe000
[2.97] page dumped because: nonzero mapcount


See patch at:

https://www.spinics.net/lists/linux-m68k/msg11810.html

That fix may be improved yet, but it should fix this specific issue.

Regards
Greg



[2.97] CPU: 0 PID: 17 Comm: mount Not tainted 
4.18.0-rc1stmark2-001-00030-g2a657c5c91d9 #721
[2.97] Stack from 47bf9de8:
[2.97] 47bf9de8 401a1644 4003e154 402128a8 40302b74 4003e176 
4003e1c8 402f97dc
[2.97] 40192255  0002 4003e450 402f97dc  
082e 
[2.97] 0007bfc0 c000 c000 402f97b8 40302b74 402f97e0 
bfff 4005d0d4
[2.97] 47bf9f32 402729b4 402729b4 4003edbe 402128a8 0003 
40302b68 2000
[2.97] c000 402f97b8 47bfabfc bfff 4003f6ec 402f97b8 
bfc0 47bf9f32
[2.97] 4005501a 402f97b8  40054e8c bffde000 4005dddc 
400591bc 47be1670
[2.97] Call Trace: [<4003e154>] bad_page+0xee/0x110
[2.97]  [<4003e176>] free_pages_check_bad+0x0/0x5a
[2.97]  [<4003e1c8>] free_pages_check_bad+0x52/0x5a
[2.97]  [<4003e450>] free_pcppages_bulk+0x226/0x2aa
[2.97]  [<4005d0d4>] anon_vma_chain_free+0x0/0x14
[2.97]  [<4003edbe>] free_unref_page_commit.isra.13+0x80/0x8e
[2.97]  [<4003f6ec>] free_unref_page+0x6e/0x78
[2.97]  [<4005501a>] free_pgd_range+0x18e/0x1ac
[2.97]  [<40054e8c>] free_pgd_range+0x0/0x1ac
[2.97]  [<4005dddc>] unlink_anon_vmas+0x0/0x168
[2.97]  [<400591bc>] unlink_file_vma+0x0/0x52
[2.97]  [<4005dddc>] unlink_anon_vmas+0x0/0x168
[2.97]  [<400591bc>] unlink_file_vma+0x0/0x52
[2.97]  [<400550bc>] free_pgtables+0x84/0x94
[2.97]  [<40151114>] down_read+0x0/0x6
[2.97]  [<40021208>] up_read+0x0/0x6
[2.97]  [<40058da8>] remove_vma+0x0/0x4c
[2.97]  [<4005a332>] exit_mmap+0xac/0x138
[2.97]  [<40005e0a>] mmput+0x18/0x72
[2.97]  [<40008efe>] do_exit+0x224/0x668
[2.97]  [<4000935c>] sys_exit+0x0/0x14
[2.97]  [<40085f84>] sys_mount+0x1a/0x20
[2.97]  [<40009370>] do_group_exit+0x0/0x76
[2.97]  [<40005190>] system_call+0x54/0x96
[2.97] Disabling lock debugging due to kernel taint

And several seems equal issues just after.
Btw, i can reach the prompt.
Any idea of what could cause those oops ?

Thanks,
Angelo
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] m68k: fix "bad page state" oops on ColdFire boot

[Greg Ungerer]

Hi Geert,

On 18/06/18 16:58, Geert Uytterhoeven wrote:

Hi Greg,

On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer  wrote:

Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):

  BUG: Bad page state in process sh  pfn:01ce2
  page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
  flags: 0x0()
  raw:    fbff  0100 0200 
  raw: 039c4000
  page dumped because: nonzero mapcount
  Modules linked in:
  CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13

Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.

Signed-off-by: Greg Ungerer 
CC: Matthew Wilcox 
---
  arch/m68k/include/asm/mcf_pgalloc.h | 1 +
  1 file changed, 1 insertion(+)

Matthew: I came across this thread at https://lkml.org/lkml/2018/6/17/163
  about a similar problem with openrisc. Based on that I came up
  with this fix for m68k/ColdFire. Fixes the issue for me.

diff --git a/arch/m68k/include/asm/mcf_pgalloc.h 
b/arch/m68k/include/asm/mcf_pgalloc.h
index 8b707c249026..8c441eb57b80 100644
--- a/arch/m68k/include/asm/mcf_pgalloc.h
+++ b/arch/m68k/include/asm/mcf_pgalloc.h
@@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned 
long address)
  static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
   unsigned long address)
  {
+   pgtable_page_dtor(page);
 __free_page(page);
  }


Do you need a call to pgtable_page_dtor() in pte_free(), too?
On x86 (and motorola_pgalloc.h and sun3_pgalloc.h FWIW), both functions
call pgtable_page_dtor().


I am thinking yes, looking at those other examples.

Regards
Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] m68k: fix "bad page state" oops on ColdFire boot

[Greg Ungerer]

Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):

 BUG: Bad page state in process sh  pfn:01ce2
 page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
 flags: 0x0()
 raw:    fbff  0100 0200 
 raw: 039c4000
 page dumped because: nonzero mapcount
 Modules linked in:
 CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13

Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.

Signed-off-by: Greg Ungerer 
CC: Matthew Wilcox 
---
 arch/m68k/include/asm/mcf_pgalloc.h | 1 +
 1 file changed, 1 insertion(+)

Matthew: I came across this thread at https://lkml.org/lkml/2018/6/17/163
 about a similar problem with openrisc. Based on that I came up
 with this fix for m68k/ColdFire. Fixes the issue for me.

diff --git a/arch/m68k/include/asm/mcf_pgalloc.h 
b/arch/m68k/include/asm/mcf_pgalloc.h
index 8b707c249026..8c441eb57b80 100644
--- a/arch/m68k/include/asm/mcf_pgalloc.h
+++ b/arch/m68k/include/asm/mcf_pgalloc.h
@@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned 
long address)
 static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
  unsigned long address)
 {
+   pgtable_page_dtor(page);
__free_page(page);
 }
 
-- 
2.17.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] m68k: coldfire: Normalize clk API

[Greg Ungerer]

Hi Geert,

On 12/06/18 17:31, Geert Uytterhoeven wrote:

On Tue, Jun 12, 2018 at 9:27 AM Greg Ungerer  wrote:

On 11/06/18 18:44, Geert Uytterhoeven wrote:

Coldfire still provides its own variant of the clk API rather than using
the generic COMMON_CLK API.  This generally works, but it causes some
link errors with drivers using the clk_round_rate(), clk_set_rate(),
clk_set_parent(), or clk_get_parent() functions when a platform lacks
those interfaces.

This adds empty stub implementations for each of them, and I don't even
try to do something useful here but instead just print a WARN() message
to make it obvious what is going on if they ever end up being called.

The drivers that call these won't be used on these platforms (otherwise
we'd get a link error today), so the added code is harmless bloat and
will warn about accidental use.

Based on commit bd7fefe1f06ca6cc ("ARM: w90x900: normalize clk API").

Signed-off-by: Geert Uytterhoeven 


I am fine with this for ColdFire, so

Acked-by: Greg Ungerer 


Thanks!


Are you going to take this/these via your m68k git tree?


I''m fine delagating this to you.


No problem. I'll add it to the m68knommu git tree (for-next branch)
when the merge window closes.

Thanks
Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] m68k: coldfire: Normalize clk API

[Greg Ungerer]

Hi Geert,

On 11/06/18 18:44, Geert Uytterhoeven wrote:

Coldfire still provides its own variant of the clk API rather than using
the generic COMMON_CLK API.  This generally works, but it causes some
link errors with drivers using the clk_round_rate(), clk_set_rate(),
clk_set_parent(), or clk_get_parent() functions when a platform lacks
those interfaces.

This adds empty stub implementations for each of them, and I don't even
try to do something useful here but instead just print a WARN() message
to make it obvious what is going on if they ever end up being called.

The drivers that call these won't be used on these platforms (otherwise
we'd get a link error today), so the added code is harmless bloat and
will warn about accidental use.

Based on commit bd7fefe1f06ca6cc ("ARM: w90x900: normalize clk API").

Signed-off-by: Geert Uytterhoeven 


I am fine with this for ColdFire, so

Acked-by: Greg Ungerer 

Are you going to take this/these via your m68k git tree?

Regards
Greg



---
  arch/m68k/coldfire/clk.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 849cd208e2ed99e6..7bc666e482ebe82f 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -129,4 +129,33 @@ unsigned long clk_get_rate(struct clk *clk)
  }
  EXPORT_SYMBOL(clk_get_rate);
  
+/* dummy functions, should not be called */

+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+   WARN_ON(clk);
+   return 0;
+}
+EXPORT_SYMBOL(clk_round_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+   WARN_ON(clk);
+   return 0;
+}
+EXPORT_SYMBOL(clk_set_rate);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   WARN_ON(clk);
+   return 0;
+}
+EXPORT_SYMBOL(clk_set_parent);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+   WARN_ON(clk);
+   return NULL;
+}
+EXPORT_SYMBOL(clk_get_parent);
+
  /***/


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git pull] m68knommu changes for v4.18

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

These changes all relate to converting the IO access functions for the
ColdFire (and all other non-MMU m68k) platforms to use asm-generic IO
instead. This makes the IO support the same on all ColdFire (regardless
of MMU enabled or not) and means we can now support PCI in non-MMU mode.
As a bonus these changes remove more code than they add.

Regards
Greg



The following changes since commit b04e217704b7f879c6b91222b066983a44a7a09f:

  Linux 4.17-rc7 (2018-05-27 13:01:47 -0700)

are available in the Git repository at:

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

for you to fetch changes up to 082f55c459845088c3fee99c3a88ee117c148218:

  m68k: fix ColdFire PCI config reads and writes (2018-05-28 09:45:27 
+1000)



Greg Ungerer (14):
  m68k: move *_relaxed macros into io_no.h and io_mm.h
  m68k: put definition guards around virt_to_phys and phys_to_virt
  m68k: use asm-generic/io.h for non-MMU io access functions
  m68k: rework raw access macros for the non-MMU case
  m68k: group io mapping definitions and functions
  m68k: setup PCI support code in io_no.h
  m68k: use io_no.h for MMU and non-MMU enabled ColdFire
  m68k: remove old ColdFire IO access support code
  m68k: don't redefine access functions if we have PCI
  m68k: fix read/write multi-byte IO for PCI on ColdFire
  m68k: fix ioremapping for internal ColdFire peripherals
  m68k: allow ColdFire PCI bus on MMU and non-MMU configuration
  m68k: introduce iomem() macro for __iomem conversions
  m68k: fix ColdFire PCI config reads and writes

 arch/m68k/Kconfig.bus   |   8 +-
 arch/m68k/coldfire/pci.c| 114 +---
 arch/m68k/include/asm/atarihw.h |   1 +
 arch/m68k/include/asm/io.h  |  10 +-
 arch/m68k/include/asm/io_mm.h   |  98 ++
 arch/m68k/include/asm/io_no.h   | 253 
+++-

 arch/m68k/include/asm/kmap.h|  80 
 arch/m68k/include/asm/nubus.h   |   1 +
 arch/m68k/include/asm/q40_master.h  |   2 +-
 arch/m68k/include/asm/raw_io.h  |  14 --
 arch/m68k/include/asm/vga.h |   9 ++
 arch/m68k/include/asm/virtconvert.h |   2 +
 arch/m68k/include/asm/zorro.h   |   1 +
 arch/m68k/mm/kmap.c |   8 ++
 14 files changed, 230 insertions(+), 371 deletions(-)
 create mode 100644 arch/m68k/include/asm/kmap.h
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

[Greg Ungerer]

Hi Geert,

On 31/05/18 05:55, Geert Uytterhoeven wrote:

On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer  wrote:

On 28/05/18 20:15, Geert Uytterhoeven wrote:

On Mon, May 28, 2018 at 7:26 AM, Finn Thain 
wrote:

On Mon, 28 May 2018, Michael Schmitz wrote:

Am 27.05.2018 um 17:49 schrieb Finn Thain:

On Sun, 27 May 2018, Michael Schmitz wrote:

That should have fixed the warning already ...


It's still not fixed (hence my "acked-by" for Geunter's patch).


Odd - does link order still matter even though the
arch_setup_dev_archdata() function from the core platform code is
declared as a weak symbol?

I'll see what I can find out on elgar ...


Any one of the numerous patches/rfcs/suggestions that I sent will avoid
the WARN splat.

When I said "it's still not fixed", what I meant to say was, "it's still
not fixed in mainline and no proposed fix was accepted to the best of my
knowledge".


Indeed.

Do we have a consensus on the way forward? The merge window for
v4.18 will open soon.


For whatever it is worth I thought Finn's patch was the best approach
(https://lkml.org/lkml/2018/5/17/333, "m68k: Set default dma mask for
platform device").


FTR: done.


Feel free to add my acked by if you like:

Acked-by: Greg Ungerer 

Regards
Greg



We seem to be hitting quite a few places (within m68k) that otherwise
need individual fixes. There is no immediate need to revert existing
changes that have already been applied if we use this now either
(like my FEC fix, commit f61e64310b75 "m68k: set dma and coherent
masks for platform FEC ethernets").


Indeed.

Gr{oetje,eeting}s,

 Geert


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

[Greg Ungerer]

Hi Geert,

On 28/05/18 20:15, Geert Uytterhoeven wrote:

On Mon, May 28, 2018 at 7:26 AM, Finn Thain  wrote:

On Mon, 28 May 2018, Michael Schmitz wrote:

Am 27.05.2018 um 17:49 schrieb Finn Thain:

On Sun, 27 May 2018, Michael Schmitz wrote:


That should have fixed the warning already ...


It's still not fixed (hence my "acked-by" for Geunter's patch).



Odd - does link order still matter even though the
arch_setup_dev_archdata() function from the core platform code is
declared as a weak symbol?

I'll see what I can find out on elgar ...



Any one of the numerous patches/rfcs/suggestions that I sent will avoid
the WARN splat.

When I said "it's still not fixed", what I meant to say was, "it's still
not fixed in mainline and no proposed fix was accepted to the best of my
knowledge".


Indeed.

Do we have a consensus on the way forward? The merge window for
v4.18 will open soon.


For whatever it is worth I thought Finn's patch was the best approach
(https://lkml.org/lkml/2018/5/17/333, "m68k: Set default dma mask for
platform device").

We seem to be hitting quite a few places (within m68k) that otherwise
need individual fixes. There is no immediate need to revert existing
changes that have already been applied if we use this now either
(like my FEC fix, commit f61e64310b75 "m68k: set dma and coherent
masks for platform FEC ethernets").

Regards
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] m68k: Set up dma mask for platform devices

[Greg Ungerer]

Hi Finn,

On 13/05/18 11:00, Finn Thain wrote:

This avoids a WARNING splat when loading the macsonic or macmace driver.
Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask").

This implementation of arch_setup_pdev_archdata() differs from the one
in arch/powerpc in that this one avoids clobbering an existing dma mask.
For example, this approach preserves the mask set by the initializer for
struct platform_device mcf_fec0.

Note that either approach would make that initializer redundant and
commit f61e64310b75 ("m68k: set dma and coherent masks for platform
FEC ethernets") could be reverted.


Seems reasonable to me. I would be happy to do this and the back out
commit f61e64310b75 ("m68k: set dma and coherent masks for platform
FEC ethernets").

Regards
Greg



---
  arch/m68k/kernel/dma.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index c01b9b8f97bf..463572c4943f 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -165,3 +166,12 @@ const struct dma_map_ops m68k_dma_ops = {
.sync_sg_for_device = m68k_dma_sync_sg_for_device,
  };
  EXPORT_SYMBOL(m68k_dma_ops);
+
+void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+   if (pdev->dev.coherent_dma_mask == DMA_MASK_NONE &&
+   pdev->dev.dma_mask == NULL) {
+   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   pdev->dev.dma_mask = >dev.coherent_dma_mask;
+   }
+}


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] m68k: Fix calendar month regression on M68328

[Greg Ungerer]

Hi Finn,

On 27/04/18 11:12, Finn Thain wrote:
> My earlier fix for read_persistent_clock() neglected to cover
> m68328_hwclk(). Correct this oversight.
> 
> Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
> Signed-off-by: Finn Thain <fth...@telegraphics.com.au>
> ---
> Greg, the read_persistent_clock() change has already been queued
> by Geert. Should this patch be pushed together with that one
> (presuming your ack)? Sorry for the inconvenience.

If Geert is happy to add it to his tree that would seem to make sense.
Otherwise I can take it via the m68knommu tree. Either way:

  Acked-by: Greg Ungerer <g...@linux-m68k.org>

Regards
Greg


> ---
>  arch/m68k/68000/timers.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/m68k/68000/timers.c b/arch/m68k/68000/timers.c
> index 252455bce144..71ddb4c98726 100644
> --- a/arch/m68k/68000/timers.c
> +++ b/arch/m68k/68000/timers.c
> @@ -125,7 +125,9 @@ int m68328_hwclk(int set, struct rtc_time *t)
>  {
>   if (!set) {
>   long now = RTCTIME;
> - t->tm_year = t->tm_mon = t->tm_mday = 1;
> + t->tm_year = 1;
> + t->tm_mon = 0;
> + t->tm_mday = 1;
>   t->tm_hour = (now >> 24) % 24;
>   t->tm_min = (now >> 16) % 60;
>   t->tm_sec = now % 60;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] m68k: Remove read_persistent_clock()

[Greg Ungerer]

On 23/04/18 21:47, Arnd Bergmann wrote:

On Mon, Apr 23, 2018 at 11:47 AM, Geert Uytterhoeven
 wrote:

Hi Arnd,

On Mon, Apr 23, 2018 at 11:28 AM, Arnd Bergmann  wrote:

On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven
 wrote:

On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann  wrote:

On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang  wrote:

The read_persistent_clock() uses a timespec, which is not year 2038 safe
on 32bit systems. Moreover on m68k architecture, we have implemented generic
RTC drivers that can be used to compensate the system suspend time. So
we can remove the obsolete read_persistent_clock().

Signed-off-by: Baolin Wang 


I'm not sure about this one: it's still possible to turn off
CONFIG_RTC_DRV_GENERIC
on M68KCLASSIC, and in that case we still need a read_persistent_clock64()
implementation. Or we use your patch but make CONFIG_RTC_DRV_GENERIC
mandatory.


Typically (in the defconfigs) CONFIG_RTC_DRV_GENERIC is either "m",
or not set.

And in both cases, a platform-specific RTC class driver may or may not be
builtin or loaded. We have them for some Amigas (RTC_DRV_MSM6242 or
RTC_DRV_RP5C01).

I've never been an expert of timekeeping code...


Some extra background on this:

read_persistent_clock64/read_persistent_clock is primarily needed when you
have a real time source that is better than the one exposed in the RTC class
driver.  For platforms doing suspend/resume, the timekeeping code will
first try calling read_persistent_clock64() but fall back to the RTC
if that fails.
On only a few architectures like m68k, read_persistent_clock64() falls
back to reading the RTC hardware, which means it will still work even if
the RTC_DRV_GENERIC driver is not loaded. Removing that code will
still work correctly as long as the generic RTC driver does get loaded
before suspend. On platforms without suspend/resume, none of this matters.


M68k-with-MMU[*] does not support suspend/resume.

[*] Probably the PM dependency should be updated for Coldfire with MMU?


Ok, so for the suspend case on m68k, can can totally ignore
read_persistent_clock64(): classic doesn't have suspend and
coldfire doesn't implement mach_hwclock() callbacks, right?


Yep, that is right, no ColdFire platforms use it.

Regards
Greg



For reference, this is the set of machines implementing mach_hwclk:

arch/m68k/68000/m68328.c:  mach_hwclk = m68328_hwclk;
arch/m68k/68000/m68EZ328.c:  mach_hwclk = m68328_hwclk;
arch/m68k/68000/m68VZ328.c: mach_hwclk = m68328_hwclk;
arch/m68k/apollo/config.c:  mach_hwclk   = dn_dummy_hwclk; /* */
arch/m68k/atari/config.c:   mach_hwclk = atari_tt_hwclk;
arch/m68k/atari/config.c:   mach_hwclk = atari_mste_hwclk;
arch/m68k/bvme6000/config.c:mach_hwclk   = bvme6000_hwclk;
arch/m68k/hp300/config.c:   mach_hwclk   = hp300_hwclk;
arch/m68k/mac/config.c: mach_hwclk = mac_hwclk;
arch/m68k/mvme147/config.c: mach_hwclk  = mvme147_hwclk;
arch/m68k/mvme16x/config.c:mach_hwclk   = mvme16x_hwclk;
arch/m68k/q40/config.c: mach_hwclk = q40_hwclk;
arch/m68k/sun3/config.c:mach_hwclk   =  sun3_hwclk;
arch/m68k/sun3x/config.c:   mach_hwclk   = sun3x_hwclk;


The other user of read_persistent_clock() is to set the initial time at boot.
This again can be done by the RTC subsystem if the correct RTC driver
is built-in and CONFIG_RTC_HCTOSYS is set. Alexandre is planning
to remove that option and instead force early user space to load the
RTC driver and then sync it manually using the sysfs knob for it.

If you have ancient user space that doesn't do this, you might still
rely on read_persistent_clock() to set the boot time.


Yeah, we have some ancient userspace (old ramdisk from just after the
a.out to ELF switch ;-), which worked fine last time I tried ;-)

But this should not be considered a dependency, as most people will
run e.g. Debian/ports, which I assume is a modern userspace.


Ok. In that case, a possible cleanup for the old time handling
could be to move each of the hwclk implementations over to use
their own RTC driver instead of a mach_hwclk function with
generic_rtc.

It seems that the mach_set_ss and nach_set_mmss
callbacks can simply get removed already, they are
never called. Similarly, the mach_get_rtc_pll() and
mach_get_rtc_pll() callbacks are only used on q40, and
could be removed after changing the q40 over to using
its own RTC driver, or registering the ioctl operation itself.

   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCHv2 00/14] m68k: fix and improve IO access — Linux M68K Devel

[Greg Ungerer]

Hi Angelo,

On 20/04/18 08:23, Angelo Dureghello wrote:
> it works as before with dspi driver + MMU.
> It builds fine.
> 
> Tested-by: Angelo Dureghello <ang...@sysam.it>

Fantastic, thanks for that.

Regards
Greg


> On Fri, Apr 20, 2018 at 12:05:48AM +0200, linux-m68k@vger.kernel.org wrote:
>> Convert the ColdFire IO access functions to use asm-generic/io.h.
>>
>> The motivation for these changes is to fix IO access problems found by
>> Angelo Dureghello during his work on ColdFire 5441x when running with
>> MMU enabled. It also bought to light problems with ColdFire systems that
>> have PCI bus support and their ability to access both the internal
>> peripherals and PCI bus peripherals.
>>
>> Along with the fixes I improved the ColdFire PCI support so that it works
>> with the MMU disabled on the ColdFire 5475. Previously PCI bus support was
>> only allowed when building with the MMU enabled. Now you can enable and
>> use the PCI bus in any configuration - MMU enabled or disabled.
>>
>> These changes force all ColdFire platforms to use the same IO access
>> family of functions. The existing code differentiated between systems
>> built with MMU enabled and MMU disabled - and there is really no reason
>> to do that. Ultimately it does result in the include/asm/io_no.h file
>> now being somewhat misnamed. Perhpas I should change that it?
>>
>> All in all the changes result in a net removal of ~140 lines, so that is
>> a good thing too.
>>
>> This version 2 of the patch set drops the bulk addition of iomem() macro
>> use to the local read/write calls using constant addresses. That was a
>> single huge patch that really needs to be broken up to more managable
>> chunks for review. As it was it resulted in a number of new compilation
>> warnings (as expected) where address types were not "void __iomem *" clean.
>> I'll create a new patch series to deal with that.
>>
>> Signed-off-by: Greg Ungerer <gerg@xx>
>> ---
>>  Kconfig.bus   |8 -
>>  coldfire/pci.c|  114 --
>>  include/asm/atarihw.h |1
>>  include/asm/io.h  |   10 -
>>  include/asm/io_mm.h   |  102 +
>>  include/asm/io_no.h   |  359 
>> --
>>  include/asm/kmap.h|   80 ++
>>  include/asm/nubus.h   |1
>>  include/asm/q40_master.h  |2
>>  include/asm/raw_io.h  |   14 -
>>  include/asm/vga.h |9 +
>>  include/asm/virtconvert.h |2
>>  include/asm/zorro.h   |1
>>  mm/kmap.c |8 +
>>  14 files changed, 285 insertions(+), 426 deletions(-)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@xxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 11/14] m68k: fix ioremapping for internal ColdFire peripherals

[Greg Ungerer]

The ColdFire SoC internal peripherals are mapped into virtual address
space using the ACR registers of the cache control unit. This means we
are using a 1:1 physical:virtual mapping for them that does not rely on
page table mappings. We can quickly determine if we are accessing an
internal peripheral device given the physical or vitrual address using
the same range check.

The implications of this mapping is that an ioremap should return the
physical address as the virtual mapping __iomem cookie as well. So fix
ioremap() to deal with this on ColdFire. Of course you need to take
care of this in the iounmap() path as well.

Reported-by: Angelo Dureghello <ang...@sysam.it>
Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/mm/kmap.c | 8 
 1 file changed, 8 insertions(+)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/mm/kmap.c b/arch/m68k/mm/kmap.c
index c2a3832..411a308 100644
--- a/arch/m68k/mm/kmap.c
+++ b/arch/m68k/mm/kmap.c
@@ -125,6 +125,10 @@ void __iomem *__ioremap(unsigned long physaddr, unsigned 
long size, int cachefla
return (void __iomem *)physaddr;
}
 #endif
+#ifdef CONFIG_COLDFIRE
+   if (__cf_internalio(physaddr))
+   return (void __iomem *) physaddr;
+#endif
 
 #ifdef DEBUG
printk("ioremap: 0x%lx,0x%lx(%d) - ", physaddr, size, cacheflag);
@@ -235,6 +239,10 @@ void iounmap(void __iomem *addr)
 ((unsigned long)addr > 0x6000)))
free_io_area((__force void *)addr);
 #else
+#ifdef CONFIG_COLDFIRE
+   if (cf_internalio(addr))
+   return;
+#endif
free_io_area((__force void *)addr);
 #endif
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 13/14] m68k: introduce iomem() macro for __iomem conversions

[Greg Ungerer]

A lot of the ColdFire internal peripherals (clocks, timers, interrupt
controllers, etc) are addressed using constants. The only problem with
that is they are not type clean when used with __raw_read/__raw_write
and read/write - they should be of type "void __iomem". This isn't
a problem currently because the IO access functions are local macros.

To switch to using the asm-generic implementations of these we need to
clean up the types. Otherwise you get warnings like this:

In file included from ./arch/m68k/include/asm/mcfsim.h:24:0,
 from arch/m68k/coldfire/intc-simr.c:20:
arch/m68k/coldfire/intc-simr.c: In function ‘init_IRQ’:
./arch/m68k/include/asm/m520xsim.h:40:29: warning: passing argument 2 of 
‘__raw_writeb’ makes pointer from integer without a cast [-Wint-conversion]
 #define MCFINTC0_SIMR   (MCFICM_INTC0 + MCFINTC_SIMR)
 ^
arch/m68k/coldfire/intc-simr.c:182:21: note: in expansion of macro 
‘MCFINTC0_SIMR’
  __raw_writeb(0xff, MCFINTC0_SIMR);
 ^
In file included from ./arch/m68k/include/asm/io_no.h:120:0,
 from ./arch/m68k/include/asm/io.h:3,
 from ./include/linux/io.h:25,
 from ./include/linux/irq.h:25,
 from ./include/asm-generic/hardirq.h:13,
 from ./arch/m68k/include/asm/hardirq.h:25,
 from ./include/linux/hardirq.h:9,
 from ./include/linux/interrupt.h:13,
 from arch/m68k/coldfire/intc-simr.c:16:
./include/asm-generic/io.h:71:22: note: expected ‘volatile void *’ but 
argument is of type ‘unsigned int’
 #define __raw_writeb __raw_writeb
  ^
./include/asm-generic/io.h:72:20: note: in expansion of macro ‘__raw_writeb’
 static inline void __raw_writeb(u8 value, volatile void __iomem *addr)
^

To start this clean up process introduce a macro, iomem(), that converts
a constant address to the correct "void __iomem *" type.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 6 ++
 1 file changed, 6 insertions(+)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index ccb8c31..83a0a6d 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -3,6 +3,12 @@
 #define _M68KNOMMU_IO_H
 
 /*
+ * Convert a physical memory address into a IO memory address.
+ * For us this is trivially a type cast.
+ */
+#define iomem(a)   ((void __iomem *) (a))
+
+/*
  * The non-MMU m68k and ColdFire IO and memory mapped hardware access
  * functions have always worked in CPU native endian. We need to define
  * that behavior here first before we include asm-generic/io.h.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 14/14] m68k: fix ColdFire PCI config reads and writes

[Greg Ungerer]

The ColdFire PCI configuration space access functions swap addressing
regions to do their work. Just letting the read/write cycles exit
the CPU core (via the ColdFire "nop" instruction) is not enough to
guarantee that the address region remapping has actually completed.
Insert a read back of the mapping register to be absolutely sure
that the remapping has completed.

This fixes an occasional boot hang during the ColdFire PCI initialization
phase.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/coldfire/pci.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
index db709ad..62b0eb6 100644
--- a/arch/m68k/coldfire/pci.c
+++ b/arch/m68k/coldfire/pci.c
@@ -46,13 +46,6 @@
0, 69, 69, 71, 71,
 };
 
-
-static inline void syncio(void)
-{
-   /* The ColdFire "nop" instruction waits for all bus IO to complete */
-   __asm__ __volatile__ ("nop");
-}
-
 /*
  * Configuration space access functions. Configuration space access is
  * through the IO mapping window, enabling it via the PCICAR register.
@@ -74,9 +67,9 @@ static int mcf_pci_readconfig(struct pci_bus *bus, unsigned 
int devfn,
return PCIBIOS_SUCCESSFUL;
}
 
-   syncio();
addr = mcf_mk_pcicar(bus->number, devfn, where);
__raw_writel(PCICAR_E | addr, PCICAR);
+   __raw_readl(PCICAR);
addr = iospace + (where & 0x3);
 
switch (size) {
@@ -91,8 +84,8 @@ static int mcf_pci_readconfig(struct pci_bus *bus, unsigned 
int devfn,
break;
}
 
-   syncio();
__raw_writel(0, PCICAR);
+   __raw_readl(PCICAR);
return PCIBIOS_SUCCESSFUL;
 }
 
@@ -106,9 +99,9 @@ static int mcf_pci_writeconfig(struct pci_bus *bus, unsigned 
int devfn,
return PCIBIOS_SUCCESSFUL;
}
 
-   syncio();
addr = mcf_mk_pcicar(bus->number, devfn, where);
__raw_writel(PCICAR_E | addr, PCICAR);
+   __raw_readl(PCICAR);
addr = iospace + (where & 0x3);
 
switch (size) {
@@ -123,8 +116,8 @@ static int mcf_pci_writeconfig(struct pci_bus *bus, 
unsigned int devfn,
break;
}
 
-   syncio();
__raw_writel(0, PCICAR);
+   __raw_readl(PCICAR);
return PCIBIOS_SUCCESSFUL;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 12/14] m68k: allow ColdFire PCI bus on MMU and non-MMU configuration

[Greg Ungerer]

Up to now we have only had support for the PCI bus when running the
ColdFire CPU family with the MMU enabled. The only reason for this was
the incomplete state of the IO remapping and access functions when
running with the MMU disabled.

Recent fixes and improvements to the ColdFire IO access code means we
can now support the PCI bus when running non-MMU enabled as well.
So modify the configuration support to allow it to be selected no matter
what choice of MMU mode is used.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/Kconfig.bus | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
index d5e66ec..aef698f 100644
--- a/arch/m68k/Kconfig.bus
+++ b/arch/m68k/Kconfig.bus
@@ -59,6 +59,10 @@ config ATARI_ROM_ISA
 config GENERIC_ISA_DMA
def_bool ISA
 
+source "drivers/zorro/Kconfig"
+
+endif
+
 config PCI
bool "PCI support"
depends on M54xx
@@ -66,10 +70,8 @@ config PCI
  Enable the PCI bus. Support for the PCI bus hardware built into the
  ColdFire 547x and 548x processors.
 
+if PCI
 source "drivers/pci/Kconfig"
-
-source "drivers/zorro/Kconfig"
-
 endif
 
 if !MMU
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 03/14] m68k: use asm-generic/io.h for non-MMU io access functions

[Greg Ungerer]

There is nothing really special about the non-MMU m68k IO access functions.
So we can easily switch to using the asm-generic/io.h functions.

The only thing we do need to handle is that historically the m68k IO access
functions for readw/readl/writew/writel use native CPU endian ordering. So
for us on m68k/ColdFire that means they are big-endian. Leave the existing
set of _raw_read/__raw_write and read/write macros in place to deal with
them. (They are ripe for later cleanup, but that is for another patch).

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/io_no.h | 179 ++
 1 file changed, 5 insertions(+), 174 deletions(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index ffe567e..acd0498 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -2,40 +2,11 @@
 #ifndef _M68KNOMMU_IO_H
 #define _M68KNOMMU_IO_H
 
-#ifdef __KERNEL__
-
-#define ARCH_HAS_IOREMAP_WT
-
-#include 
-#include 
-
 /*
- * These are for ISA/PCI shared memory _only_ and should never be used
- * on any other type of memory, including Zorro memory. They are meant to
- * access the bus in the bus byte order which is little-endian!.
- *
- * readX/writeX() are used to access memory mapped devices. On some
- * architectures the memory mapped IO stuff needs to be accessed
- * differently. On the m68k architecture, we just read/write the
- * memory location directly.
- */
-/* ++roman: The assignments to temp. vars avoid that gcc sometimes generates
- * two accesses to memory, which may be undesirable for some devices.
+ * The non-MMU m68k and ColdFire IO and memory mapped hardware access
+ * functions have always worked in CPU native endian. We need to define
+ * that behavior here first before we include asm-generic/io.h.
  */
-
-/*
- * swap functions are sometimes needed to interface little-endian hardware
- */
-static inline unsigned short _swapw(volatile unsigned short v)
-{
-return ((v << 8) | (v >> 8));
-}
-
-static inline unsigned int _swapl(volatile unsigned long v)
-{
-return ((v << 24) | ((v & 0xff00) << 8) | ((v & 0xff) >> 8) | (v >> 
24));
-}
-
 #define readb(addr) \
 ({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
 #define readw(addr) \
@@ -54,147 +25,7 @@ static inline unsigned int _swapl(volatile unsigned long v)
 #define __raw_writew writew
 #define __raw_writel writel
 
-static inline void io_outsb(unsigned int addr, const void *buf, int len)
-{
-   volatile unsigned char *ap = (volatile unsigned char *) addr;
-   unsigned char *bp = (unsigned char *) buf;
-   while (len--)
-   *ap = *bp++;
-}
-
-static inline void io_outsw(unsigned int addr, const void *buf, int len)
-{
-   volatile unsigned short *ap = (volatile unsigned short *) addr;
-   unsigned short *bp = (unsigned short *) buf;
-   while (len--)
-   *ap = _swapw(*bp++);
-}
-
-static inline void io_outsl(unsigned int addr, const void *buf, int len)
-{
-   volatile unsigned int *ap = (volatile unsigned int *) addr;
-   unsigned int *bp = (unsigned int *) buf;
-   while (len--)
-   *ap = _swapl(*bp++);
-}
-
-static inline void io_insb(unsigned int addr, void *buf, int len)
-{
-   volatile unsigned char *ap = (volatile unsigned char *) addr;
-   unsigned char *bp = (unsigned char *) buf;
-   while (len--)
-   *bp++ = *ap;
-}
-
-static inline void io_insw(unsigned int addr, void *buf, int len)
-{
-   volatile unsigned short *ap = (volatile unsigned short *) addr;
-   unsigned short *bp = (unsigned short *) buf;
-   while (len--)
-   *bp++ = _swapw(*ap);
-}
-
-static inline void io_insl(unsigned int addr, void *buf, int len)
-{
-   volatile unsigned int *ap = (volatile unsigned int *) addr;
-   unsigned int *bp = (unsigned int *) buf;
-   while (len--)
-   *bp++ = _swapl(*ap);
-}
-
-#define mmiowb()
-
-/*
- * make the short names macros so specific devices
- * can override them as required
- */
-
-#define memset_io(a,b,c)   memset((void *)(a),(b),(c))
-#define memcpy_fromio(a,b,c)   memcpy((a),(void *)(b),(c))
-#define memcpy_toio(a,b,c) memcpy((void *)(a),(b),(c))
-
-#define inb(addr)readb(addr)
-#define inw(addr)readw(addr)
-#define inl(addr)readl(addr)
-#define outb(x,addr) ((void) writeb(x,addr))
-#define outw(x,addr) ((void) writew(x,addr))
-#define outl(x,addr) ((void) writel(x,addr))
-
-#define inb_p(addr)inb(addr)
-#define inw_p(addr)inw(addr)
-#define inl_p(addr)inl(addr)
-#define outb_p(x,addr) outb(x,addr)
-#define outw_p(x,addr) outw(x,addr)
-#define outl_p(x,addr) outl(x,addr)
-
-#define outsb(a,b,l) io_outsb(a,b,l)
-#define out

[PATCHv2 05/14] m68k: group io mapping definitions and functions

[Greg Ungerer]

Create a new header file, kmap.h, that groups all the definitions and
functions associated with the io mapping and remapping.

Currently the functions are spread across raw_io.h and io_mm.h. And in
the future we will want to use these in io_no.h as well. So it makes
sense to move them all together into a single header file.

It is named after the arch/m68k/mm/kmap.c file that actually implements
many of the exported functions.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/atarihw.h|  1 +
 arch/m68k/include/asm/io_mm.h  | 43 +---
 arch/m68k/include/asm/io_no.h  | 12 ++
 arch/m68k/include/asm/kmap.h   | 80 ++
 arch/m68k/include/asm/nubus.h  |  1 +
 arch/m68k/include/asm/q40_master.h |  2 +-
 arch/m68k/include/asm/raw_io.h | 14 ---
 arch/m68k/include/asm/vga.h|  1 +
 arch/m68k/include/asm/zorro.h  |  1 +
 9 files changed, 98 insertions(+), 57 deletions(-)
 create mode 100644 arch/m68k/include/asm/kmap.h

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 972c8f3..9000b24 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u_long atari_mch_cookie;
 extern u_long atari_mch_type;
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 22e778e..21fba26 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -461,39 +462,6 @@ static inline void isa_delay(void)
 
 #define mmiowb()
 
-static inline void __iomem *ioremap(unsigned long physaddr, unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
-}
-static inline void __iomem *ioremap_nocache(unsigned long physaddr, unsigned 
long size)
-{
-   return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
-}
-#define ioremap_uc ioremap_nocache
-static inline void __iomem *ioremap_wt(unsigned long physaddr,
-unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
-}
-static inline void __iomem *ioremap_fullcache(unsigned long physaddr,
- unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_FULL_CACHING);
-}
-
-static inline void memset_io(volatile void __iomem *addr, unsigned char val, 
int count)
-{
-   __builtin_memset((void __force *) addr, val, count);
-}
-static inline void memcpy_fromio(void *dst, const volatile void __iomem *src, 
int count)
-{
-   __builtin_memcpy(dst, (void __force *) src, count);
-}
-static inline void memcpy_toio(volatile void __iomem *dst, const void *src, 
int count)
-{
-   __builtin_memcpy((void __force *) dst, src, count);
-}
-
 #ifndef CONFIG_SUN3
 #define IO_SPACE_LIMIT 0x
 #else
@@ -515,15 +483,6 @@ static inline void memcpy_toio(volatile void __iomem *dst, 
const void *src, int
  */
 #define xlate_dev_kmem_ptr(p)  p
 
-static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
-{
-   return (void __iomem *) port;
-}
-
-static inline void ioport_unmap(void __iomem *p)
-{
-}
-
 #define readb_relaxed(addr)readb(addr)
 #define readw_relaxed(addr)readw(addr)
 #define readl_relaxed(addr)readl(addr)
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 5095693..e9c70f7 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -25,6 +25,18 @@
 #define writew __raw_writew
 #define writel __raw_writel
 
+/*
+ * These are defined in kmap.h as static inline functions. To maintain
+ * previous behavior we put these define guards here so io_mm.h doesn't
+ * see them.
+ */
+#ifdef CONFIG_MMU
+#define memset_io memset_io
+#define memcpy_fromio memcpy_fromio
+#define memcpy_toio memcpy_toio
+#endif
+
+#include 
 #include 
 #include 
 
diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
new file mode 100644
index 000..84b8333
--- /dev/null
+++ b/arch/m68k/include/asm/kmap.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _KMAP_H
+#define _KMAP_H
+
+#ifdef CONFIG_MMU
+
+/* Values for nocacheflag and cmode */
+#define IOMAP_FULL_CACHING 0
+#define IOMAP_NOCACHE_SER  1
+#define IOMAP_NOCACHE_NONSER   2
+#define IOMAP_WRITETHROUGH 3
+
+/*
+ * These functions exported by arch/m68k/mm/kmap.c.
+ * Only needed on MMU enabled systems.
+ */
+extern void __iomem *__ioremap(unsigned long physaddr, unsigned long size,
+  int cacheflag);
+extern void iounmap(void __iomem *addr);
+extern void __iounmap(void *addr, unsigned long size);
+
+#define ioremap ioremap
+static inline void __iomem *ioremap(unsigned long physaddr, un

[PATCHv2 01/14] m68k: move *_relaxed macros into io_no.h and io_mm.h

[Greg Ungerer]

Move a copy of the definitions of the *_relaxed() macros into io_no.h
and io_mm.h. This precedes a change to the io_no.h file to use
asm-generic/io.h. They will be removed from io_no.h at that point.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/io.h| 8 
 arch/m68k/include/asm/io_mm.h | 8 
 arch/m68k/include/asm/io_no.h | 8 
 3 files changed, 16 insertions(+), 8 deletions(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index 756089c..00b4515 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -4,11 +4,3 @@
 #else
 #include 
 #endif
-
-#define readb_relaxed(addr)readb(addr)
-#define readw_relaxed(addr)readw(addr)
-#define readl_relaxed(addr)readl(addr)
-
-#define writeb_relaxed(b, addr)writeb(b, addr)
-#define writew_relaxed(b, addr)writew(b, addr)
-#define writel_relaxed(b, addr)writel(b, addr)
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index ed5333e..22e778e 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -524,4 +524,12 @@ static inline void ioport_unmap(void __iomem *p)
 {
 }
 
+#define readb_relaxed(addr)readb(addr)
+#define readw_relaxed(addr)readw(addr)
+#define readl_relaxed(addr)readl(addr)
+
+#define writeb_relaxed(b, addr)writeb(b, addr)
+#define writew_relaxed(b, addr)writew(b, addr)
+#define writel_relaxed(b, addr)writel(b, addr)
+
 #endif /* _IO_H */
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 86f45b4..ffe567e 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -189,4 +189,12 @@ static inline void ioport_unmap(void __iomem *p)
 
 #endif /* __KERNEL__ */
 
+#define readb_relaxed(addr)readb(addr)
+#define readw_relaxed(addr)readw(addr)
+#define readl_relaxed(addr)readl(addr)
+
+#define writeb_relaxed(b, addr)writeb(b, addr)
+#define writew_relaxed(b, addr)writew(b, addr)
+#define writel_relaxed(b, addr)writel(b, addr)
+
 #endif /* _M68KNOMMU_IO_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 00/14] m68k: fix and improve IO access

[Greg Ungerer]

Convert the ColdFire IO access functions to use asm-generic/io.h.

The motivation for these changes is to fix IO access problems found by
Angelo Dureghello during his work on ColdFire 5441x when running with
MMU enabled. It also bought to light problems with ColdFire systems that
have PCI bus support and their ability to access both the internal
peripherals and PCI bus peripherals.

Along with the fixes I improved the ColdFire PCI support so that it works
with the MMU disabled on the ColdFire 5475. Previously PCI bus support was
only allowed when building with the MMU enabled. Now you can enable and
use the PCI bus in any configuration - MMU enabled or disabled.

These changes force all ColdFire platforms to use the same IO access
family of functions. The existing code differentiated between systems
built with MMU enabled and MMU disabled - and there is really no reason
to do that. Ultimately it does result in the include/asm/io_no.h file
now being somewhat misnamed. Perhpas I should change that it?

All in all the changes result in a net removal of ~140 lines, so that is
a good thing too.

This version 2 of the patch set drops the bulk addition of iomem() macro
use to the local read/write calls using constant addresses. That was a
single huge patch that really needs to be broken up to more managable
chunks for review. As it was it resulted in a number of new compilation
warnings (as expected) where address types were not "void __iomem *" clean.
I'll create a new patch series to deal with that.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 Kconfig.bus   |8 -
 coldfire/pci.c|  114 --
 include/asm/atarihw.h |1
 include/asm/io.h  |   10 -
 include/asm/io_mm.h   |  102 +
 include/asm/io_no.h   |  359 --
 include/asm/kmap.h|   80 ++
 include/asm/nubus.h   |1
 include/asm/q40_master.h  |2
 include/asm/raw_io.h  |   14 -
 include/asm/vga.h |9 +
 include/asm/virtconvert.h |2
 include/asm/zorro.h   |1
 mm/kmap.c |8 +
 14 files changed, 285 insertions(+), 426 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 06/14] m68k: setup PCI support code in io_no.h

[Greg Ungerer]

Ultimately we want the ColdFire IO access support to be consisent no matter
whether it is configured with MMU enabled or disabled. To acheive that we
need to get all the ColdFire IO access support code together in one place,
in this case io_no.h. The last big piece not in io_no.h is the PCI bus
support functions.

Define the IO mapping addresses required to use the asm-generic IO
access functions. They can provide everything we need - no need for us
to duplicate or have local in/out or read/write access functions.
Note that this support is not active yet, since we haven't done the
full switch over to using the asm-generic functions yet. And also note
that we do not yet remove the old PCI functions from io_mm.h yet.

Consolodating all this IO access support in a single place will make
it easier in the future to enable PCI bus support for non-MMU enabled
ColdFire (which we currently cannot do).

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/io_no.h | 31 +++
 1 file changed, 31 insertions(+)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index e9c70f7..42d61d4 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -18,6 +18,35 @@
 #define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) = 
(b))
 #define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
 
+#if defined(CONFIG_PCI) && defined(CONFIG_COLDFIRE)
+/*
+ * Support for PCI bus access uses the asm-generic access functions.
+ * We need to supply the base address and masks for the normal memory
+ * and IO address space mappings.
+ */
+#include 
+#include 
+#include 
+
+#define PCI_MEM_PA 0xf000  /* Host physical address */
+#define PCI_MEM_BA 0xf000  /* Bus physical address */
+#define PCI_MEM_SIZE   0x0800  /* 128 MB */
+#define PCI_MEM_MASK   (PCI_MEM_SIZE - 1)
+
+#define PCI_IO_PA  0xf800  /* Host physical address */
+#define PCI_IO_BA  0x  /* Bus physical address */
+#define PCI_IO_SIZE0x0001  /* 64k */
+#define PCI_IO_MASK(PCI_IO_SIZE - 1)
+
+#define HAVE_ARCH_PIO_SIZE
+#define PIO_OFFSET 0
+#define PIO_MASK   0x
+#define PIO_RESERVED   0x1
+#define PCI_IOBASE ((void __iomem *) PCI_IO_PA)
+#define PCI_SPACE_LIMITPCI_IO_MASK
+
+#else
+
 #define readb __raw_readb
 #define readw __raw_readw
 #define readl __raw_readl
@@ -25,6 +54,8 @@
 #define writew __raw_writew
 #define writel __raw_writel
 
+#endif /* CONFIG_PCI && CONFIG_COLDFIRE */
+
 /*
  * These are defined in kmap.h as static inline functions. To maintain
  * previous behavior we put these define guards here so io_mm.h doesn't
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 07/14] m68k: use io_no.h for MMU and non-MMU enabled ColdFire

[Greg Ungerer]

Use the io_no.h IO access support for all ColdFire systems, no matter
whether configured with MMU enabled or disabled. Previously there was
subtle differences in IO access functions used in both cases, and these
resulted in broken behavior for some drivers.

As observed and reported by Angelo when using MMU enabled systems the
read/write family of functions was using little endian access, while the
non-MMU enabled systems were using native endian. This results in drivers
that are shared across Freescale processors (for some of the common
internal SoC peripherals) not working - since they are wired up for native
endian access.

This problem brings to light issues with PCI bus access and local
peripheral access - but these are not addressed with this fix.

Reported-by: Angelo Dureghello <ang...@sysam.it>
Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index 00b4515..ca2849a 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifdef __uClinux__
+#if defined(__uClinux__) || defined(CONFIG_COLDFIRE)
 #include 
 #else
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 02/14] m68k: put definition guards around virt_to_phys and phys_to_virt

[Greg Ungerer]

The non-MMU and ColdFire IO access functions will be moving to using the
asm-generic/io.h in the near future. To make that possible we need define
guards around the m68k specific virt_to_phys() and phys_to_virt()
functions.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/virtconvert.h | 2 ++
 1 file changed, 2 insertions(+)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/virtconvert.h 
b/arch/m68k/include/asm/virtconvert.h
index 4aea6be..dfe4308 100644
--- a/arch/m68k/include/asm/virtconvert.h
+++ b/arch/m68k/include/asm/virtconvert.h
@@ -16,11 +16,13 @@
 /*
  * Change virtual addresses to physical addresses and vv.
  */
+#define virt_to_phys virt_to_phys
 static inline unsigned long virt_to_phys(void *address)
 {
return __pa(address);
 }
 
+#define phys_to_virt phys_to_virt
 static inline void *phys_to_virt(unsigned long address)
 {
return __va(address);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 09/14] m68k: don't redefine access functions if we have PCI

[Greg Ungerer]

Some ColdFire platforms do have real PCI buses, so we should not be
re-defining or otherwise mangling the IO access functions for them.
So when CONFIG_PCI is true use the real io.h support.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/vga.h | 8 
 1 file changed, 8 insertions(+)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/vga.h b/arch/m68k/include/asm/vga.h
index 819d46d..4742e6b 100644
--- a/arch/m68k/include/asm/vga.h
+++ b/arch/m68k/include/asm/vga.h
@@ -2,6 +2,13 @@
 #ifndef _ASM_M68K_VGA_H
 #define _ASM_M68K_VGA_H
 
+/*
+ * Some ColdFire platforms do in fact have a PCI bus. So for those we want
+ * to use the real IO access functions, don't fake them out or redirect them
+ * for that case.
+ */
+#ifndef CONFIG_PCI
+
 #include 
 #include 
 
@@ -26,4 +33,5 @@
 #define writeb raw_outb
 #define writew raw_outw
 
+#endif /* CONFIG_PCI */
 #endif /* _ASM_M68K_VGA_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 08/14] m68k: remove old ColdFire IO access support code

[Greg Ungerer]

All the ColdFire IO access support code has been moved to io_no.h.
This means that all ColdFire support is at least now consistent no
matter whether the MMU is enabled or not for them.

Now that io_mm.h has reverted to only support the traditional m68k MMU
enabled processors we can remove the ColdFire specific definitions.

We can also remove the old ColdFire PCI bus IO access functions.
The new io_no.h uses asm-generic/io.h to provide all the basic support.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/coldfire/pci.c  | 99 ++-
 arch/m68k/include/asm/io_mm.h | 51 +-
 2 files changed, 5 insertions(+), 145 deletions(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
index 3097fa2..db709ad 100644
--- a/arch/m68k/coldfire/pci.c
+++ b/arch/m68k/coldfire/pci.c
@@ -23,20 +23,10 @@
 
 /*
  * Memory and IO mappings. We use a 1:1 mapping for local host memory to
- * PCI bus memory (no reason not to really). IO space doesn't matter, we
- * always use access functions for that. The device configuration space is
- * mapped over the IO map space when we enable it in the PCICAR register.
+ * PCI bus memory (no reason not to really). IO space is mapped in its own
+ * separate address region. The device configuration space is mapped over
+ * the IO map space when we enable it in the PCICAR register.
  */
-#definePCI_MEM_PA  0xf000  /* Host physical 
address */
-#definePCI_MEM_BA  0xf000  /* Bus physical address 
*/
-#definePCI_MEM_SIZE0x0800  /* 128 MB */
-#definePCI_MEM_MASK(PCI_MEM_SIZE - 1)
-
-#definePCI_IO_PA   0xf800  /* Host physical 
address */
-#definePCI_IO_BA   0x  /* Bus physical address 
*/
-#definePCI_IO_SIZE 0x0001  /* 64k */
-#definePCI_IO_MASK (PCI_IO_SIZE - 1)
-
 static struct pci_bus *rootbus;
 static unsigned long iospace;
 
@@ -144,89 +134,6 @@ static int mcf_pci_writeconfig(struct pci_bus *bus, 
unsigned int devfn,
 };
 
 /*
- * IO address space access functions. Pretty strait forward, these are
- * directly mapped in to the IO mapping window. And that is mapped into
- * virtual address space.
- */
-u8 mcf_pci_inb(u32 addr)
-{
-   return __raw_readb(iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_inb);
-
-u16 mcf_pci_inw(u32 addr)
-{
-   return le16_to_cpu(__raw_readw(iospace + (addr & PCI_IO_MASK)));
-}
-EXPORT_SYMBOL(mcf_pci_inw);
-
-u32 mcf_pci_inl(u32 addr)
-{
-   return le32_to_cpu(__raw_readl(iospace + (addr & PCI_IO_MASK)));
-}
-EXPORT_SYMBOL(mcf_pci_inl);
-
-void mcf_pci_insb(u32 addr, u8 *buf, u32 len)
-{
-   for (; len; len--)
-   *buf++ = mcf_pci_inb(addr);
-}
-EXPORT_SYMBOL(mcf_pci_insb);
-
-void mcf_pci_insw(u32 addr, u16 *buf, u32 len)
-{
-   for (; len; len--)
-   *buf++ = mcf_pci_inw(addr);
-}
-EXPORT_SYMBOL(mcf_pci_insw);
-
-void mcf_pci_insl(u32 addr, u32 *buf, u32 len)
-{
-   for (; len; len--)
-   *buf++ = mcf_pci_inl(addr);
-}
-EXPORT_SYMBOL(mcf_pci_insl);
-
-void mcf_pci_outb(u8 v, u32 addr)
-{
-   __raw_writeb(v, iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_outb);
-
-void mcf_pci_outw(u16 v, u32 addr)
-{
-   __raw_writew(cpu_to_le16(v), iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_outw);
-
-void mcf_pci_outl(u32 v, u32 addr)
-{
-   __raw_writel(cpu_to_le32(v), iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_outl);
-
-void mcf_pci_outsb(u32 addr, const u8 *buf, u32 len)
-{
-   for (; len; len--)
-   mcf_pci_outb(*buf++, addr);
-}
-EXPORT_SYMBOL(mcf_pci_outsb);
-
-void mcf_pci_outsw(u32 addr, const u16 *buf, u32 len)
-{
-   for (; len; len--)
-   mcf_pci_outw(*buf++, addr);
-}
-EXPORT_SYMBOL(mcf_pci_outsw);
-
-void mcf_pci_outsl(u32 addr, const u32 *buf, u32 len)
-{
-   for (; len; len--)
-   mcf_pci_outl(*buf++, addr);
-}
-EXPORT_SYMBOL(mcf_pci_outsl);
-
-/*
  * Initialize the PCI bus registers, and scan the bus.
  */
 static struct resource mcf_pci_mem = {
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 21fba26..fe485f4 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -86,53 +86,7 @@
 #endif /* ATARI_ROM_ISA */
 
 
-#if defined(CONFIG_PCI) && defined(CONFIG_COLDFIRE)
-
-#define HAVE_ARCH_PIO_SIZE
-#define PIO_OFFSET 0
-#define PIO_MASK   0x
-#define PIO_RESERVED   0x1
-
-u8 mcf_pci_inb(u32 addr);
-u16 mcf_pci_inw(u32 addr);
-u32 mcf_pci_inl(u32 addr);
-void mcf_pci_insb(u32 addr, u8 *buf, u32 len);
-void mcf_pci_insw(u32 addr, u16 *buf, u32

[PATCHv2 04/14] m68k: rework raw access macros for the non-MMU case

[Greg Ungerer]

The primary and fundamental access macros are really the __raw versions.
So make them the actual implementation for access, and not the read/write
access macros. The read/write macros and functions are built on top of
the raw access (with byte swapping or other actions as required).

This in itself causes no functional change right now. But it will make it
easier to fix and resolve problems with PCI bus access in the future.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
Reviewed-by: Angelo Dureghello <ang...@sysam.it>
---
 arch/m68k/include/asm/io_no.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

v2: rebase to v4.17-rc1
fix compilation warnings
drop read/write iomem() conversions

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index acd0498..5095693 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -7,23 +7,23 @@
  * functions have always worked in CPU native endian. We need to define
  * that behavior here first before we include asm-generic/io.h.
  */
-#define readb(addr) \
+#define __raw_readb(addr) \
 ({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
-#define readw(addr) \
+#define __raw_readw(addr) \
 ({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
-#define readl(addr) \
+#define __raw_readl(addr) \
 ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
 
-#define writeb(b,addr) (void)((*(volatile unsigned char *) (addr)) = (b))
-#define writew(b,addr) (void)((*(volatile unsigned short *) (addr)) = (b))
-#define writel(b,addr) (void)((*(volatile unsigned int *) (addr)) = (b))
+#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) = 
(b))
+#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) = 
(b))
+#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
 
-#define __raw_readb readb
-#define __raw_readw readw
-#define __raw_readl readl
-#define __raw_writeb writeb
-#define __raw_writew writew
-#define __raw_writel writel
+#define readb __raw_readb
+#define readw __raw_readw
+#define readl __raw_readl
+#define writeb __raw_writeb
+#define writew __raw_writew
+#define writel __raw_writel
 
 #include 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h

[Greg Ungerer]

Hi Angelo,

On 19/04/18 06:27, Angelo Dureghello wrote:

On Wed, Apr 18, 2018 at 10:01:34AM +1000, Greg Ungerer wrote:

On 18/04/18 06:53, Angelo Dureghello wrote:

[snip]

Is it ok to test the patch now in my mcf54415 based board ?


Yes, please do. I expect it should fix the the issues you found,
but lets confirm that is really the case.

I will be issuing a v2 of the series - to fix the problems found by
the autobuilder. But they are minor changes, and I would like to
know that they actually fix your problems first.



Ok i tested it.

* applied all 15 patches
* enabled MMU
* compilied, there was 1 error

   LDS arch/m68k/kernel/vmlinux.lds
   CC  arch/m68k/mm/init.o
   CC  arch/m68k/mm/cache.o
   CC  arch/m68k/mm/fault.o
   CC  arch/m68k/mm/kmap.o
arch/m68k/mm/kmap.c: In function '__ioremap':
arch/m68k/mm/kmap.c:129:6: error: implicit declaration of function 
'__cf_internalio' [-Werror=implicit-function-declaration]
   if (__cf_internalio(physaddr))
   ^
arch/m68k/mm/kmap.c: In function 'iounmap':
arch/m68k/mm/kmap.c:243:6: error: implicit declaration of function 
'cf_internalio' [-Werror=implicit-function-declaration]
   if (cf_internalio(addr))
   ^
cc1: some warnings being treated as errors
scripts/Makefile.build:312: set di istruzioni per l'obiettivo 
"arch/m68k/mm/kmap.o" non riuscito
make[1]: *** [arch/m68k/mm/kmap.o] Errore 1
Makefile:1060: set di istruzioni per l'obiettivo "arch/m68k/mm" non riuscito
make: *** [arch/m68k/mm] Errore 2

Just to pass over the issue i changed line 20 of

from
#if defined(CONFIG_PCI) && defined(CONFIG_COLDFIRE)
to
#if defined(CONFIG_PCI) || defined(CONFIG_COLDFIRE)

Then it built fine.
So my dspi driver works fine with MMU enabled.

Tested-by: Angelo Dureghello <ang...@sysam.it>


Thats great, thanks for taking the time to debug and test that.

I'll fix it in a slightly different way, but I see what the source
of the problem is.

I have a v2 ready and will send here soon.

Thanks
Greg




Reviewed-by: Angelo Dureghello <ang...@sysam.it>


Thanks for that. I will add that in.

Regards
Greg




Regards,
Angelo



--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] m68k: fix return value check in mcf_pci_init()

[Greg Ungerer]

Hi Wei,

On 18/04/18 23:57, Wei Yongjun wrote:
> In case of error, the function ioremap() returns NULL pointer not
> ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
> 
> Fixes: bf114d773167 ("m68k: force use of __raw_read/__raw_write address to be 
> iomem")
> Signed-off-by: Wei Yongjun 

Thanks for the patch. I plan on dropping that commit completely
from next soon. Autobuilder has shown it is missing some conversions
that it was intended to cover.

Regards
Greg


> ---
>  arch/m68k/coldfire/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
> index 9d6342c..a7c2332 100644
> --- a/arch/m68k/coldfire/pci.c
> +++ b/arch/m68k/coldfire/pci.c
> @@ -218,7 +218,7 @@ static int __init mcf_pci_init(void)
>  
>   /* Keep a virtual mapping to IO/config space active */
>   iospace = ioremap(PCI_IO_PA, PCI_IO_SIZE);
> - if (IS_ERR(iospace))
> + if (!iospace)
>   return -ENODEV;
>   pr_info("Coldfire: PCI IO/config window mapped to 0x%p\n", iospace);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h

[Greg Ungerer]

Hi Angelo,

On 18/04/18 06:53, Angelo Dureghello wrote:
> thanks for this great job.

:-)


> On patch 10, PIC is PCI, right ?

Yes, typo on my part. I even managed to get it wrong twice!
I'll fix that.


> In case you hae some time,  am interested in understanding how those
> guards
> 
> #define xxx xxx
> 
> works.

In this particular case it is to allow local architecture code to
have its own version of a function or macro and for the common
kernel code to define it if it is not otherwise defined.

Consider this example, in our local arch code we want an optimized
"readb" function. If we just had:

  static inline u8 readb(void __iomem *addr)
  { ... }

and the common code (such as include/asm-generic/io.h) had the
common readb in a similar fashion:

  static inline u8 readb(void __iomem *addr)
  { ... }

On compilation you are going to get readb multiply defined.
If instead the common code had:

  #ifndef read
  #define readb readb
  static inline u8 readb(void __iomem *addr)
  { ... }
  #endif

Then all we need to do in our local arch code is define "readb".
If we defined it as a macro, then no problem that would just work.
If we want it as a real function (preferable) then we just need to
make sure that "readb" is somehow defined, so the simplest way is
to just define it to be itself:

  #define read readb

Obviously our local arch code has to be included first.


> Is it ok to test the patch now in my mcf54415 based board ?

Yes, please do. I expect it should fix the the issues you found,
but lets confirm that is really the case.

I will be issuing a v2 of the series - to fix the problems found by
the autobuilder. But they are minor changes, and I would like to
know that they actually fix your problems first.


> Reviewed-by: Angelo Dureghello <ang...@sysam.it>

Thanks for that. I will add that in.

Regards
Greg


> On Wed, Apr 11, 2018 at 10:54:14PM +1000, Greg Ungerer wrote:
>> Move a copy of the definitions of the *_relaxed() macros into io_no.h
>> and io_mm.h. This precedes a change to the io_no.h file to use
>> asm-generic/io.h. They will be removed from io_no.h at that point.
>>
>> Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
>> ---
>>  arch/m68k/include/asm/io.h| 8 
>>  arch/m68k/include/asm/io_mm.h | 8 
>>  arch/m68k/include/asm/io_no.h | 8 
>>  3 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
>> index 756089c..00b4515 100644
>> --- a/arch/m68k/include/asm/io.h
>> +++ b/arch/m68k/include/asm/io.h
>> @@ -4,11 +4,3 @@
>>  #else
>>  #include 
>>  #endif
>> -
>> -#define readb_relaxed(addr) readb(addr)
>> -#define readw_relaxed(addr) readw(addr)
>> -#define readl_relaxed(addr) readl(addr)
>> -
>> -#define writeb_relaxed(b, addr) writeb(b, addr)
>> -#define writew_relaxed(b, addr) writew(b, addr)
>> -#define writel_relaxed(b, addr) writel(b, addr)
>> diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
>> index ed5333e..22e778e 100644
>> --- a/arch/m68k/include/asm/io_mm.h
>> +++ b/arch/m68k/include/asm/io_mm.h
>> @@ -524,4 +524,12 @@ static inline void ioport_unmap(void __iomem *p)
>>  {
>>  }
>>  
>> +#define readb_relaxed(addr) readb(addr)
>> +#define readw_relaxed(addr) readw(addr)
>> +#define readl_relaxed(addr) readl(addr)
>> +
>> +#define writeb_relaxed(b, addr) writeb(b, addr)
>> +#define writew_relaxed(b, addr) writew(b, addr)
>> +#define writel_relaxed(b, addr) writel(b, addr)
>> +
>>  #endif /* _IO_H */
>> diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
>> index 86f45b4..ffe567e 100644
>> --- a/arch/m68k/include/asm/io_no.h
>> +++ b/arch/m68k/include/asm/io_no.h
>> @@ -189,4 +189,12 @@ static inline void ioport_unmap(void __iomem *p)
>>  
>>  #endif /* __KERNEL__ */
>>  
>> +#define readb_relaxed(addr) readb(addr)
>> +#define readw_relaxed(addr) readw(addr)
>> +#define readl_relaxed(addr) readl(addr)
>> +
>> +#define writeb_relaxed(b, addr) writeb(b, addr)
>> +#define writew_relaxed(b, addr) writew(b, addr)
>> +#define writel_relaxed(b, addr) writel(b, addr)
>> +
>>  #endif /* _M68KNOMMU_IO_H */
>> -- 
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h

[Greg Ungerer]

On 12/04/18 04:50, Geert Uytterhoeven wrote:

On Wed, Apr 11, 2018 at 2:54 PM, Greg Ungerer <g...@linux-m68k.org> wrote:

Move a copy of the definitions of the *_relaxed() macros into io_no.h
and io_mm.h. This precedes a change to the io_no.h file to use
asm-generic/io.h. They will be removed from io_no.h at that point.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>


Reviewed-by: Geert Uytterhoeven <ge...@linux-m68k.org>


Thanks for the feedback Geert, much appreciated.

Regards
Greg


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 14/15] m68k: remove local __raw_read/__raw_write macros for non-MMU

[Greg Ungerer]

Now that all the local ColdFire and non-MMU m68k use of __raw_read
and __raw_write has been made type clean we can switch to using the
asm-generic/io.h versions.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 95e70b5..de4b16d 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -10,19 +10,12 @@
 
 /*
  * The non-MMU m68k and ColdFire IO and memory mapped hardware accesses
- * functions have always worked in CPU native endian. We need to define
- * that behavior here first before we include asm-generic/io.h.
+ * functions have always worked in CPU native endian. We need to preserve
+ * that behavior - even though we are using asm-generioc/io.h now.
+ * We can rely on asm-generic/io.h for the __raw functions, they are
+ * always defined to be CPU native endian. The PCI bus case is a little
+ * more complicated - due to it being little-endian.
  */
-#define __raw_readb(addr) \
-({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
-#define __raw_readw(addr) \
-({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
-#define __raw_readl(addr) \
-({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
-
-#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) = 
(b))
-#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) = 
(b))
-#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
 
 #if defined(CONFIG_PCI) && defined(CONFIG_COLDFIRE)
 /*
@@ -69,6 +62,15 @@ static int cf_internalio(const volatile void __iomem *addr)
 }
 
 /*
+ * We need these forward declarations here first so that we can use them
+ * for our local readw/readl/writew/writel.
+ */
+static inline u16 __raw_readw(const volatile void __iomem *addr);
+static inline u32 __raw_readl(const volatile void __iomem *addr);
+static inline void __raw_writew(u16 value, volatile void __iomem *addr);
+static inline void __raw_writel(u32 value, volatile void __iomem *addr);
+
+/*
  * We need to treat built-in peripherals and bus based address ranges
  * differently. Local built-in peripherals (and the ColdFire SoC parts
  * have quite a lot of them) are always native endian - which is big
@@ -111,10 +113,12 @@ static inline void writel(u32 value, volatile void 
__iomem *addr)
 
 #else
 
-#define readb __raw_readb
+/*
+ * Preserve CPU native endian ordering for multi-byte IO access.
+ * (So we can ignore readb and writeb).
+ */
 #define readw __raw_readw
 #define readl __raw_readl
-#define writeb __raw_writeb
 #define writew __raw_writew
 #define writel __raw_writel
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 15/15] m68k: fix ColdFire PCI config reads and write

[Greg Ungerer]

The ColdFire PCI configuration space access functions swap addressing
regions to do their work. Just letting the read/write cycles exit
the CPU core (via the ColdFire "nop" instruction) is not enough to
guarantee that the address region remapping has actually completed.
Insert a read back of the mapping register to be absolutely sure
that the remapping has completed.

This fixes an occasional boot hang during the ColdFire PCI initialization
phase.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/coldfire/pci.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
index dc6d125..9d6342c 100644
--- a/arch/m68k/coldfire/pci.c
+++ b/arch/m68k/coldfire/pci.c
@@ -46,13 +46,6 @@
0, 69, 69, 71, 71,
 };
 
-
-static inline void syncio(void)
-{
-   /* The ColdFire "nop" instruction waits for all bus IO to complete */
-   __asm__ __volatile__ ("nop");
-}
-
 /*
  * Configuration space access functions. Configuration space access is
  * through the IO mapping window, enabling it via the PCICAR register.
@@ -75,9 +68,9 @@ static int mcf_pci_readconfig(struct pci_bus *bus, unsigned 
int devfn,
return PCIBIOS_SUCCESSFUL;
}
 
-   syncio();
offset = mcf_mk_pcicar(bus->number, devfn, where);
__raw_writel(PCICAR_E | offset, iomem(PCICAR));
+   __raw_readl(iomem(PCICAR));
addr = iospace + (where & 0x3);
 
switch (size) {
@@ -92,8 +85,8 @@ static int mcf_pci_readconfig(struct pci_bus *bus, unsigned 
int devfn,
break;
}
 
-   syncio();
__raw_writel(0, iomem(PCICAR));
+   __raw_readl(iomem(PCICAR));
return PCIBIOS_SUCCESSFUL;
 }
 
@@ -108,9 +101,9 @@ static int mcf_pci_writeconfig(struct pci_bus *bus, 
unsigned int devfn,
return PCIBIOS_SUCCESSFUL;
}
 
-   syncio();
offset = mcf_mk_pcicar(bus->number, devfn, where);
__raw_writel(PCICAR_E | offset, iomem(PCICAR));
+   __raw_readl(iomem(PCICAR));
addr = iospace + (where & 0x3);
 
switch (size) {
@@ -125,8 +118,8 @@ static int mcf_pci_writeconfig(struct pci_bus *bus, 
unsigned int devfn,
break;
}
 
-   syncio();
__raw_writel(0, iomem(PCICAR));
+   __raw_readl(iomem(PCICAR));
return PCIBIOS_SUCCESSFUL;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/15] m68k: force use of __raw_read/__raw_write address to be iomem

[Greg Ungerer]

The __raw_read/__raw_write and read/write families of IO access functions
normally take address arguments of type "void __iomem *". The legacy
macros we are still using for ColdFire and non-MMU m68k don't really care,
they cast to volatile unsigned pointers of appropriate size to do their
work.

There is a lot of places in amongst the ColdFire and non-MMU m68k code
that we use direct constants as addresses with the read/write IO macros.
To convert to using the asm-generic/io.h version fo the __raw_ read/write
functions then we will need to be type clean. Otherwise we are going to
get _lots_ of warnings of the form:

In file included from ./arch/m68k/include/asm/mcfsim.h:24:0,
 from arch/m68k/coldfire/intc-simr.c:20:
arch/m68k/coldfire/intc-simr.c: In function ‘init_IRQ’:
./arch/m68k/include/asm/m520xsim.h:40:29: warning: passing argument 2 of 
‘__raw_writeb’ makes pointer from integer without a cast [-Wint-conversion]
 #define MCFINTC0_SIMR   (MCFICM_INTC0 + MCFINTC_SIMR)
 ^
arch/m68k/coldfire/intc-simr.c:182:21: note: in expansion of macro 
‘MCFINTC0_SIMR’
  __raw_writeb(0xff, MCFINTC0_SIMR);
 ^
In file included from ./arch/m68k/include/asm/io_no.h:120:0,
 from ./arch/m68k/include/asm/io.h:3,
 from ./include/linux/io.h:25,
 from ./include/linux/irq.h:25,
 from ./include/asm-generic/hardirq.h:13,
 from ./arch/m68k/include/asm/hardirq.h:25,
 from ./include/linux/hardirq.h:9,
 from ./include/linux/interrupt.h:13,
 from arch/m68k/coldfire/intc-simr.c:16:
./include/asm-generic/io.h:71:22: note: expected ‘volatile void *’ but 
argument is of type ‘unsigned int’
 #define __raw_writeb __raw_writeb
  ^
./include/asm-generic/io.h:72:20: note: in expansion of macro ‘__raw_writeb’
 static inline void __raw_writeb(u8 value, volatile void __iomem *addr)
^

Introduce a macro, iomem(),  that converts a constant address to the
correct "void __iomem *" type.

Most conversions are simple and strait forward. A couple of cases in
pci.c required a little more work, since the address is also used as a
value to be read and written to a register.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/coldfire/clk.c|  8 +++---
 arch/m68k/coldfire/dma_timer.c  | 20 +++
 arch/m68k/coldfire/intc-2.c | 36 +--
 arch/m68k/coldfire/intc-simr.c  | 38 ++--
 arch/m68k/coldfire/intc.c   | 28 ++---
 arch/m68k/coldfire/m520x.c  | 26 +--
 arch/m68k/coldfire/m5272.c  | 16 ++--
 arch/m68k/coldfire/m528x.c  | 29 +++---
 arch/m68k/coldfire/m5441x.c |  8 +++---
 arch/m68k/coldfire/m54xx.c  | 20 ---
 arch/m68k/coldfire/pci.c| 55 +
 arch/m68k/coldfire/pit.c|  2 +-
 arch/m68k/coldfire/reset.c  |  4 +--
 arch/m68k/coldfire/sltimers.c   |  4 +--
 arch/m68k/coldfire/stmark2.c| 12 -
 arch/m68k/coldfire/timers.c |  6 ++---
 arch/m68k/include/asm/io_no.h   |  6 +
 arch/m68k/include/asm/mcfgpio.h | 12 -
 18 files changed, 170 insertions(+), 160 deletions(-)

diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 849cd20..ceda70a 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -42,12 +42,12 @@ void __clk_init_disabled(struct clk *clk)
 
 static void __clk_enable0(struct clk *clk)
 {
-   __raw_writeb(clk->slot, MCFPM_PPMCR0);
+   __raw_writeb(clk->slot, iomem(MCFPM_PPMCR0));
 }
 
 static void __clk_disable0(struct clk *clk)
 {
-   __raw_writeb(clk->slot, MCFPM_PPMSR0);
+   __raw_writeb(clk->slot, iomem(MCFPM_PPMSR0));
 }
 
 struct clk_ops clk_ops0 = {
@@ -58,12 +58,12 @@ struct clk_ops clk_ops0 = {
 #ifdef MCFPM_PPMCR1
 static void __clk_enable1(struct clk *clk)
 {
-   __raw_writeb(clk->slot, MCFPM_PPMCR1);
+   __raw_writeb(clk->slot, iomem(MCFPM_PPMCR1));
 }
 
 static void __clk_disable1(struct clk *clk)
 {
-   __raw_writeb(clk->slot, MCFPM_PPMSR1);
+   __raw_writeb(clk->slot, iomem(MCFPM_PPMSR1));
 }
 
 struct clk_ops clk_ops1 = {
diff --git a/arch/m68k/coldfire/dma_timer.c b/arch/m68k/coldfire/dma_timer.c
index cbb2894..afcde3d2 100644
--- a/arch/m68k/coldfire/dma_timer.c
+++ b/arch/m68k/coldfire/dma_timer.c
@@ -20,12 +20,12 @@
 #define DMA_TIMER_2(0x80)
 #define DMA_TIMER_3(0xc0)
 
-#define DTMR0  (MCF_IPSBAR + DMA_TIMER_0 + 0x400)
-#define DTXMR0 (MCF_IPSBAR + DMA_TIMER_0 + 0x402)
-#define DTER0  (MCF_IPSBAR + DMA_TIMER_0 + 0x403)
-#define DTRR0  (MCF_IPSBAR + DMA_TIMER_0 + 0x404)
-#define DTCR0  (MCF_IPSBAR + DMA_TIMER_0 + 0x408)
-#define 

[PATCH 12/15] m68k: allow ColdFire PCI bus on MMU and non-MMU configuration

[Greg Ungerer]

Up to now we have only had support for the PCI bus when running the
ColdFire CPU family with the MMU enabled. The only reason for this was
the incomplete state of the IO remapping and access functions when
running with the MMU disabled.

Recent fixes and improvements to the ColdFire IO access code means we
can now support the PCI bus when running non-MMU enabled as well.
So modify the configuration support to allow it to be selected no matter
what choice of MMU mode is used.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/Kconfig.bus | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
index d5e66ec..aef698f 100644
--- a/arch/m68k/Kconfig.bus
+++ b/arch/m68k/Kconfig.bus
@@ -59,6 +59,10 @@ config ATARI_ROM_ISA
 config GENERIC_ISA_DMA
def_bool ISA
 
+source "drivers/zorro/Kconfig"
+
+endif
+
 config PCI
bool "PCI support"
depends on M54xx
@@ -66,10 +70,8 @@ config PCI
  Enable the PCI bus. Support for the PCI bus hardware built into the
  ColdFire 547x and 548x processors.
 
+if PCI
 source "drivers/pci/Kconfig"
-
-source "drivers/zorro/Kconfig"
-
 endif
 
 if !MMU
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/15] m68k: fix ioremapping for internal ColdFire peripherals

[Greg Ungerer]

The ColdFire SoC internal peripherals are mapped into virtual address
space using the ACR registers of the cache control unit. This means we
are using a 1:1 physical:virtual mapping for them that does not rely on
page table mappings. We can quickly determine if we are accessing an
internal peripheral device given the physical or vitrual address using
the same range check.

The implications of this mapping is that an ioremap should return the
physical address as the virtual mapping __iomem cookie as well. So fix
ioremap() to deal with this on ColdFire. Of course you need to take
care of this in the iounmap() path as well.

Reported-by: Angelo Dureghello <ang...@sysam.it>
Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/mm/kmap.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/m68k/mm/kmap.c b/arch/m68k/mm/kmap.c
index c2a3832..411a308 100644
--- a/arch/m68k/mm/kmap.c
+++ b/arch/m68k/mm/kmap.c
@@ -125,6 +125,10 @@ void __iomem *__ioremap(unsigned long physaddr, unsigned 
long size, int cachefla
return (void __iomem *)physaddr;
}
 #endif
+#ifdef CONFIG_COLDFIRE
+   if (__cf_internalio(physaddr))
+   return (void __iomem *) physaddr;
+#endif
 
 #ifdef DEBUG
printk("ioremap: 0x%lx,0x%lx(%d) - ", physaddr, size, cacheflag);
@@ -235,6 +239,10 @@ void iounmap(void __iomem *addr)
 ((unsigned long)addr > 0x6000)))
free_io_area((__force void *)addr);
 #else
+#ifdef CONFIG_COLDFIRE
+   if (cf_internalio(addr))
+   return;
+#endif
free_io_area((__force void *)addr);
 #endif
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/15] m68k: fix read/write multi-byte IO for PCI on ColdFire

[Greg Ungerer]

We need to treat built-in peripherals and bus based address ranges
differently. Local built-in peripherals (and the ColdFire SoC parts
have quite a lot of them) are always native endian - which is big
endian on m68k/ColdFire. Bus based address ranges, like the PIC bus,
are accessed little endian - so we need to byte swap those.

So implement readw/writew and readl/writel functions to deal with
memory mapped accesses correctly based on the address range being
accessed.

This fixes readw/writew and readl/writel so that they can be used in
drivers for native SoC hardware modules (many of which are shared with
other architectures (ARM in Freescale SoC parts for example). And also
drivers for PCI devices.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index a3d23e8..4fe743f 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -45,6 +45,64 @@
 #define PCI_IOBASE ((void __iomem *) PCI_IO_PA)
 #define PCI_SPACE_LIMITPCI_IO_MASK
 
+/*
+ * The ColdFire SoC internal peripherals are mapped into virtual address
+ * space using the ACR registers of the cache control unit. This means we
+ * are using a 1:1 physical:virtual mapping for them. We can quickly
+ * determine if we are accessing an internal peripheral device given the
+ * physical or vitrual address using the same range check.
+ */
+static int __cf_internalio(unsigned long addr)
+{
+   return (addr >= IOMEMBASE) && (addr <= IOMEMBASE + IOMEMSIZE - 1);
+}
+
+static int cf_internalio(const volatile void __iomem *addr)
+{
+   return __cf_internalio((unsigned long) addr);
+}
+
+/*
+ * We need to treat built-in peripherals and bus based address ranges
+ * differently. Local built-in peripherals (and the ColdFire SoC parts
+ * have quite a lot of them) are always native endian - which is big
+ * endian on m68k/ColdFire. Bus based address ranges, like the PIC bus,
+ * are accessed little endian - so we need to byte swap those.
+ */
+#define readw readw
+static inline u16 readw(const volatile void __iomem *addr)
+{
+   if (cf_internalio(addr))
+   return __raw_readw(addr);
+   return __le16_to_cpu(__raw_readw(addr));
+}
+
+#define readl readl
+static inline u32 readl(const volatile void __iomem *addr)
+{
+   if (cf_internalio(addr))
+   return __raw_readl(addr);
+   return __le32_to_cpu(__raw_readl(addr));
+}
+
+#define writew writew
+static inline void writew(u16 value, volatile void __iomem *addr)
+{
+   if (cf_internalio(addr))
+   __raw_writew(value, addr);
+   else
+   __raw_writew(__cpu_to_le16(value), addr);
+}
+
+#define writel writel
+static inline void writel(u32 value, volatile void __iomem *addr)
+{
+   if (cf_internalio(addr))
+   __raw_writel(value, addr);
+   else
+   __raw_writel(__cpu_to_le32(value), addr);
+}
+
 #else
 
 #define readb __raw_readb
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/15] m68k: remove old ColdFire IO access support code

[Greg Ungerer]

All the ColdFire IO access support code has been moved to io_no.h.
This means that all ColdFire support is at least now consistent no
matter whether the MMU is enabled or not for them.

Now that io_mm.h has reverted to only support the traditional m68k MMU
enabled processors we can remove the ColdFire specific definitions.

We can also remove the old ColdFire PCI bus IO access functions.
The new io_no.h uses asm-generic/io.h to provide all the basic support.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/coldfire/pci.c  | 99 ++-
 arch/m68k/include/asm/io_mm.h | 51 +-
 2 files changed, 5 insertions(+), 145 deletions(-)

diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
index 3097fa2..db709ad 100644
--- a/arch/m68k/coldfire/pci.c
+++ b/arch/m68k/coldfire/pci.c
@@ -23,20 +23,10 @@
 
 /*
  * Memory and IO mappings. We use a 1:1 mapping for local host memory to
- * PCI bus memory (no reason not to really). IO space doesn't matter, we
- * always use access functions for that. The device configuration space is
- * mapped over the IO map space when we enable it in the PCICAR register.
+ * PCI bus memory (no reason not to really). IO space is mapped in its own
+ * separate address region. The device configuration space is mapped over
+ * the IO map space when we enable it in the PCICAR register.
  */
-#definePCI_MEM_PA  0xf000  /* Host physical 
address */
-#definePCI_MEM_BA  0xf000  /* Bus physical address 
*/
-#definePCI_MEM_SIZE0x0800  /* 128 MB */
-#definePCI_MEM_MASK(PCI_MEM_SIZE - 1)
-
-#definePCI_IO_PA   0xf800  /* Host physical 
address */
-#definePCI_IO_BA   0x  /* Bus physical address 
*/
-#definePCI_IO_SIZE 0x0001  /* 64k */
-#definePCI_IO_MASK (PCI_IO_SIZE - 1)
-
 static struct pci_bus *rootbus;
 static unsigned long iospace;
 
@@ -144,89 +134,6 @@ static int mcf_pci_writeconfig(struct pci_bus *bus, 
unsigned int devfn,
 };
 
 /*
- * IO address space access functions. Pretty strait forward, these are
- * directly mapped in to the IO mapping window. And that is mapped into
- * virtual address space.
- */
-u8 mcf_pci_inb(u32 addr)
-{
-   return __raw_readb(iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_inb);
-
-u16 mcf_pci_inw(u32 addr)
-{
-   return le16_to_cpu(__raw_readw(iospace + (addr & PCI_IO_MASK)));
-}
-EXPORT_SYMBOL(mcf_pci_inw);
-
-u32 mcf_pci_inl(u32 addr)
-{
-   return le32_to_cpu(__raw_readl(iospace + (addr & PCI_IO_MASK)));
-}
-EXPORT_SYMBOL(mcf_pci_inl);
-
-void mcf_pci_insb(u32 addr, u8 *buf, u32 len)
-{
-   for (; len; len--)
-   *buf++ = mcf_pci_inb(addr);
-}
-EXPORT_SYMBOL(mcf_pci_insb);
-
-void mcf_pci_insw(u32 addr, u16 *buf, u32 len)
-{
-   for (; len; len--)
-   *buf++ = mcf_pci_inw(addr);
-}
-EXPORT_SYMBOL(mcf_pci_insw);
-
-void mcf_pci_insl(u32 addr, u32 *buf, u32 len)
-{
-   for (; len; len--)
-   *buf++ = mcf_pci_inl(addr);
-}
-EXPORT_SYMBOL(mcf_pci_insl);
-
-void mcf_pci_outb(u8 v, u32 addr)
-{
-   __raw_writeb(v, iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_outb);
-
-void mcf_pci_outw(u16 v, u32 addr)
-{
-   __raw_writew(cpu_to_le16(v), iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_outw);
-
-void mcf_pci_outl(u32 v, u32 addr)
-{
-   __raw_writel(cpu_to_le32(v), iospace + (addr & PCI_IO_MASK));
-}
-EXPORT_SYMBOL(mcf_pci_outl);
-
-void mcf_pci_outsb(u32 addr, const u8 *buf, u32 len)
-{
-   for (; len; len--)
-   mcf_pci_outb(*buf++, addr);
-}
-EXPORT_SYMBOL(mcf_pci_outsb);
-
-void mcf_pci_outsw(u32 addr, const u16 *buf, u32 len)
-{
-   for (; len; len--)
-   mcf_pci_outw(*buf++, addr);
-}
-EXPORT_SYMBOL(mcf_pci_outsw);
-
-void mcf_pci_outsl(u32 addr, const u32 *buf, u32 len)
-{
-   for (; len; len--)
-   mcf_pci_outl(*buf++, addr);
-}
-EXPORT_SYMBOL(mcf_pci_outsl);
-
-/*
  * Initialize the PCI bus registers, and scan the bus.
  */
 static struct resource mcf_pci_mem = {
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 21fba26..fe485f4 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -86,53 +86,7 @@
 #endif /* ATARI_ROM_ISA */
 
 
-#if defined(CONFIG_PCI) && defined(CONFIG_COLDFIRE)
-
-#define HAVE_ARCH_PIO_SIZE
-#define PIO_OFFSET 0
-#define PIO_MASK   0x
-#define PIO_RESERVED   0x1
-
-u8 mcf_pci_inb(u32 addr);
-u16 mcf_pci_inw(u32 addr);
-u32 mcf_pci_inl(u32 addr);
-void mcf_pci_insb(u32 addr, u8 *buf, u32 len);
-void mcf_pci_insw(u32 addr, u16 *buf, u32 len);
-void mcf_pci_insl(u32 addr, u32 *buf, u32 len);
-
-void mcf_pci_outb(u8 v, u32 addr);
-void mcf_pci_outw(u16 v, u32 addr);
-void mcf_pci_outl(u32

[PATCH 09/15] m68k: don't redefine access functions if we have PCI

[Greg Ungerer]

Some ColdFire platforms do have real PCI buses, so we should not be
re-defining or otherwise mangling the IO access functions for them.
So when CONFIG_PCI is true use the real io.h support.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/vga.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/m68k/include/asm/vga.h b/arch/m68k/include/asm/vga.h
index 819d46d..4742e6b 100644
--- a/arch/m68k/include/asm/vga.h
+++ b/arch/m68k/include/asm/vga.h
@@ -2,6 +2,13 @@
 #ifndef _ASM_M68K_VGA_H
 #define _ASM_M68K_VGA_H
 
+/*
+ * Some ColdFire platforms do in fact have a PCI bus. So for those we want
+ * to use the real IO access functions, don't fake them out or redirect them
+ * for that case.
+ */
+#ifndef CONFIG_PCI
+
 #include 
 #include 
 
@@ -26,4 +33,5 @@
 #define writeb raw_outb
 #define writew raw_outw
 
+#endif /* CONFIG_PCI */
 #endif /* _ASM_M68K_VGA_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/15] m68k: group io mapping definitions and functions

[Greg Ungerer]

Create a new header file, kmap.h, that groups all the definitions and
functions associated with the io mapping and remapping.

Currently the functions are spread across raw_io.h and io_mm.h. And in
the future we will want to use these in io_no.h as well. So it makes
sense to move them all together into a single header file.

It is named after the arch/m68k/mm/kmap.c file that actually implements
many of the exported functions.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/atarihw.h|  1 +
 arch/m68k/include/asm/io_mm.h  | 43 +---
 arch/m68k/include/asm/io_no.h  |  1 +
 arch/m68k/include/asm/kmap.h   | 83 ++
 arch/m68k/include/asm/nubus.h  |  1 +
 arch/m68k/include/asm/q40_master.h |  2 +-
 arch/m68k/include/asm/raw_io.h | 14 ---
 arch/m68k/include/asm/vga.h|  1 +
 arch/m68k/include/asm/zorro.h  |  1 +
 9 files changed, 90 insertions(+), 57 deletions(-)
 create mode 100644 arch/m68k/include/asm/kmap.h

diff --git a/arch/m68k/include/asm/atarihw.h b/arch/m68k/include/asm/atarihw.h
index 972c8f3..9000b24 100644
--- a/arch/m68k/include/asm/atarihw.h
+++ b/arch/m68k/include/asm/atarihw.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern u_long atari_mch_cookie;
 extern u_long atari_mch_type;
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 22e778e..21fba26 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -461,39 +462,6 @@ static inline void isa_delay(void)
 
 #define mmiowb()
 
-static inline void __iomem *ioremap(unsigned long physaddr, unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
-}
-static inline void __iomem *ioremap_nocache(unsigned long physaddr, unsigned 
long size)
-{
-   return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
-}
-#define ioremap_uc ioremap_nocache
-static inline void __iomem *ioremap_wt(unsigned long physaddr,
-unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
-}
-static inline void __iomem *ioremap_fullcache(unsigned long physaddr,
- unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_FULL_CACHING);
-}
-
-static inline void memset_io(volatile void __iomem *addr, unsigned char val, 
int count)
-{
-   __builtin_memset((void __force *) addr, val, count);
-}
-static inline void memcpy_fromio(void *dst, const volatile void __iomem *src, 
int count)
-{
-   __builtin_memcpy(dst, (void __force *) src, count);
-}
-static inline void memcpy_toio(volatile void __iomem *dst, const void *src, 
int count)
-{
-   __builtin_memcpy((void __force *) dst, src, count);
-}
-
 #ifndef CONFIG_SUN3
 #define IO_SPACE_LIMIT 0x
 #else
@@ -515,15 +483,6 @@ static inline void memcpy_toio(volatile void __iomem *dst, 
const void *src, int
  */
 #define xlate_dev_kmem_ptr(p)  p
 
-static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
-{
-   return (void __iomem *) port;
-}
-
-static inline void ioport_unmap(void __iomem *p)
-{
-}
-
 #define readb_relaxed(addr)readb(addr)
 #define readw_relaxed(addr)readw(addr)
 #define readl_relaxed(addr)readl(addr)
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index a84f756..c97c281 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -25,6 +25,7 @@
 #define writew __raw_writew
 #define writel __raw_writel
 
+#include 
 #include 
 #include 
 
diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
new file mode 100644
index 000..50b05f5
--- /dev/null
+++ b/arch/m68k/include/asm/kmap.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _KMAP_H
+#define _KMAP_H
+
+#ifdef CONFIG_MMU
+
+/* Values for nocacheflag and cmode */
+#define IOMAP_FULL_CACHING 0
+#define IOMAP_NOCACHE_SER  1
+#define IOMAP_NOCACHE_NONSER   2
+#define IOMAP_WRITETHROUGH 3
+
+/*
+ * These functions exported by arch/m68k/mm/kmap.c.
+ * Only needed on MMU enabled systems.
+ */
+extern void __iomem *__ioremap(unsigned long physaddr, unsigned long size,
+  int cacheflag);
+extern void iounmap(void __iomem *addr);
+extern void __iounmap(void *addr, unsigned long size);
+
+#define ioremap ioremap
+static inline void __iomem *ioremap(unsigned long physaddr, unsigned long size)
+{
+   return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
+}
+
+#define ioremap_nocache ioremap_nocache
+static inline void __iomem *ioremap_nocache(unsigned long physaddr,
+   unsigned long size)
+{
+   return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
+}
+
+#define ioremap_uc ioremap_nocache
+static inline void _

[PATCH 04/15] m68k: rework raw access macros for the non-MMU case

[Greg Ungerer]

The primary and fundamental access macros are really the __raw versions.
So make them the actual implementation for access, and not the read/write
access macros. The read/write macros and functions are built on top of
the raw access (with byte swapping or other actions as required).

This in itself causes no functional change right now. But it will make it
easier to fix and resolve problems with PCI bus access in the future.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 825cd51..a84f756 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -7,23 +7,23 @@
  * functions have always worked in CPU native endian. We need to define
  * that behavior here first before we include asm-generic/io.h.
  */
-#define readb(addr) \
+#define __raw_readb(addr) \
 ({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
-#define readw(addr) \
+#define __raw_readw(addr) \
 ({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
-#define readl(addr) \
+#define __raw_readl(addr) \
 ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
 
-#define writeb(b,addr) (void)((*(volatile unsigned char *) (addr)) = (b))
-#define writew(b,addr) (void)((*(volatile unsigned short *) (addr)) = (b))
-#define writel(b,addr) (void)((*(volatile unsigned int *) (addr)) = (b))
+#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) = 
(b))
+#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) = 
(b))
+#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
 
-#define __raw_readb readb
-#define __raw_readw readw
-#define __raw_readl readl
-#define __raw_writeb writeb
-#define __raw_writew writew
-#define __raw_writel writel
+#define readb __raw_readb
+#define readw __raw_readw
+#define readl __raw_readl
+#define writeb __raw_writeb
+#define writew __raw_writew
+#define writel __raw_writel
 
 #include 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/15] m68k: use io_no.h for MMU and non-MMU enabled ColdFire

[Greg Ungerer]

Use the io_no.h IO access support for all ColdFire systems, no matter
whether configured with MMU enabled or disabled. Previously there was
subtle differences in IO access functions used in both cases, and these
resulted in broken behavior for some drivers.

As observed and reported by Angelo when using MMU enabled systems the
read/write family of functions was using little endian access, while the
non-MMU enabled systems were using native endian. This results in drivers
that are shared across Freescale processors (for some of the common
internal SoC peripherals) not working - since they are wired up for native
endian access.

This problem brings to light issues with PCI bus access and local
peripheral access - but these are not addressed with this fix.

Reported-by: Angelo Dureghello <ang...@sysam.it>
Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index 00b4515..ca2849a 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifdef __uClinux__
+#if defined(__uClinux__) || defined(CONFIG_COLDFIRE)
 #include 
 #else
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/15] m68k: setup PCI support code in io_no.h

[Greg Ungerer]

Ultimately we want the ColdFire IO access support to be consisent no matter
whether it is configured with MMU enabled or disabled. To acheive that we
need to get all the ColdFire IO access support code together in one place,
in this case io_no.h. The last big piece not in io_no.h is the PCI bus
support functions.

Define the IO mapping addresses required to use the asm-generic IO
access functions. They can provide everything we need - no need for us
to duplicate or have local in/out or read/write access functions.
Note that this support is not active yet, since we haven't done the
full switch over to using the asm-generic functions yet. And also note
that we do not yet remove the old PCI functions from io_mm.h yet.

Consolodating all this IO access support in a single place will make
it easier in the future to enable PCI bus support for non-MMU enabled
ColdFire (which we currently cannot do).

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index c97c281..a3d23e8 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -18,6 +18,35 @@
 #define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) = 
(b))
 #define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
 
+#if defined(CONFIG_PCI) && defined(CONFIG_COLDFIRE)
+/*
+ * Support for PCI bus access uses the asm-generic access functions.
+ * We need to supply the base address and masks for the normal memory
+ * and IO address space mappings.
+ */
+#include 
+#include 
+#include 
+
+#define PCI_MEM_PA 0xf000  /* Host physical address */
+#define PCI_MEM_BA 0xf000  /* Bus physical address */
+#define PCI_MEM_SIZE   0x0800  /* 128 MB */
+#define PCI_MEM_MASK   (PCI_MEM_SIZE - 1)
+
+#define PCI_IO_PA  0xf800  /* Host physical address */
+#define PCI_IO_BA  0x  /* Bus physical address */
+#define PCI_IO_SIZE0x0001  /* 64k */
+#define PCI_IO_MASK(PCI_IO_SIZE - 1)
+
+#define HAVE_ARCH_PIO_SIZE
+#define PIO_OFFSET 0
+#define PIO_MASK   0x
+#define PIO_RESERVED   0x1
+#define PCI_IOBASE ((void __iomem *) PCI_IO_PA)
+#define PCI_SPACE_LIMITPCI_IO_MASK
+
+#else
+
 #define readb __raw_readb
 #define readw __raw_readw
 #define readl __raw_readl
@@ -25,6 +54,8 @@
 #define writew __raw_writew
 #define writel __raw_writel
 
+#endif /* CONFIG_PCI && CONFIG_COLDFIRE */
+
 #include 
 #include 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/15] m68k: use asm-generic/io.h for non-MMU io access functions

[Greg Ungerer]

There is nothing really special about the non-MMU m68k IO access functions.
So we can easily switch to using the asm-generic/io.h functions.

The only thing we do need to handle is that historically the m68k IO access
functions for readw/readl/writew/writel use native CPU endian ordering. So
for us on m68k/ColdFire that means they are big-endian. Leave the existing
set of _raw_read/__raw_write and read/write macros in place to deal with
them. (They are ripe for later cleanup, but that is for another patch).

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io_no.h | 179 ++
 1 file changed, 5 insertions(+), 174 deletions(-)

diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index ffe567e..825cd51 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -2,40 +2,11 @@
 #ifndef _M68KNOMMU_IO_H
 #define _M68KNOMMU_IO_H
 
-#ifdef __KERNEL__
-
-#define ARCH_HAS_IOREMAP_WT
-
-#include 
-#include 
-
 /*
- * These are for ISA/PCI shared memory _only_ and should never be used
- * on any other type of memory, including Zorro memory. They are meant to
- * access the bus in the bus byte order which is little-endian!.
- *
- * readX/writeX() are used to access memory mapped devices. On some
- * architectures the memory mapped IO stuff needs to be accessed
- * differently. On the m68k architecture, we just read/write the
- * memory location directly.
- */
-/* ++roman: The assignments to temp. vars avoid that gcc sometimes generates
- * two accesses to memory, which may be undesirable for some devices.
+ * The non-MMU m68k and ColdFire IO and memory mapped hardware accesses
+ * functions have always worked in CPU native endian. We need to define
+ * that behavior here first before we include asm-generic/io.h.
  */
-
-/*
- * swap functions are sometimes needed to interface little-endian hardware
- */
-static inline unsigned short _swapw(volatile unsigned short v)
-{
-return ((v << 8) | (v >> 8));
-}
-
-static inline unsigned int _swapl(volatile unsigned long v)
-{
-return ((v << 24) | ((v & 0xff00) << 8) | ((v & 0xff) >> 8) | (v >> 
24));
-}
-
 #define readb(addr) \
 ({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
 #define readw(addr) \
@@ -54,147 +25,7 @@ static inline unsigned int _swapl(volatile unsigned long v)
 #define __raw_writew writew
 #define __raw_writel writel
 
-static inline void io_outsb(unsigned int addr, const void *buf, int len)
-{
-   volatile unsigned char *ap = (volatile unsigned char *) addr;
-   unsigned char *bp = (unsigned char *) buf;
-   while (len--)
-   *ap = *bp++;
-}
-
-static inline void io_outsw(unsigned int addr, const void *buf, int len)
-{
-   volatile unsigned short *ap = (volatile unsigned short *) addr;
-   unsigned short *bp = (unsigned short *) buf;
-   while (len--)
-   *ap = _swapw(*bp++);
-}
-
-static inline void io_outsl(unsigned int addr, const void *buf, int len)
-{
-   volatile unsigned int *ap = (volatile unsigned int *) addr;
-   unsigned int *bp = (unsigned int *) buf;
-   while (len--)
-   *ap = _swapl(*bp++);
-}
-
-static inline void io_insb(unsigned int addr, void *buf, int len)
-{
-   volatile unsigned char *ap = (volatile unsigned char *) addr;
-   unsigned char *bp = (unsigned char *) buf;
-   while (len--)
-   *bp++ = *ap;
-}
-
-static inline void io_insw(unsigned int addr, void *buf, int len)
-{
-   volatile unsigned short *ap = (volatile unsigned short *) addr;
-   unsigned short *bp = (unsigned short *) buf;
-   while (len--)
-   *bp++ = _swapw(*ap);
-}
-
-static inline void io_insl(unsigned int addr, void *buf, int len)
-{
-   volatile unsigned int *ap = (volatile unsigned int *) addr;
-   unsigned int *bp = (unsigned int *) buf;
-   while (len--)
-   *bp++ = _swapl(*ap);
-}
-
-#define mmiowb()
-
-/*
- * make the short names macros so specific devices
- * can override them as required
- */
-
-#define memset_io(a,b,c)   memset((void *)(a),(b),(c))
-#define memcpy_fromio(a,b,c)   memcpy((a),(void *)(b),(c))
-#define memcpy_toio(a,b,c) memcpy((void *)(a),(b),(c))
-
-#define inb(addr)readb(addr)
-#define inw(addr)readw(addr)
-#define inl(addr)readl(addr)
-#define outb(x,addr) ((void) writeb(x,addr))
-#define outw(x,addr) ((void) writew(x,addr))
-#define outl(x,addr) ((void) writel(x,addr))
-
-#define inb_p(addr)inb(addr)
-#define inw_p(addr)inw(addr)
-#define inl_p(addr)inl(addr)
-#define outb_p(x,addr) outb(x,addr)
-#define outw_p(x,addr) outw(x,addr)
-#define outl_p(x,addr) outl(x,addr)
-
-#define outsb(a,b,l) io_outsb(a,b,l)
-#define outsw(a,b,l) io_outsw(a,b,l)
-#define outsl(a,b,l) io_outsl(a,b,l)
-
-#define insb(a,b,l) io_insb(a,b,l)
-#define insw(a,b,l) io_insw(a,b

[PATCH 02/15] m68k: put definition guards around virt_to_phys and phys_to_virt

[Greg Ungerer]

The non-MMU and ColdFire IO access functions will be moving to using the
asm-generic/io.h in the near future. To make that possible we need define
guards around the m68k specific virt_to_phys() and phys_to_virt()
functions.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/virtconvert.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/m68k/include/asm/virtconvert.h 
b/arch/m68k/include/asm/virtconvert.h
index 4aea6be..dfe4308 100644
--- a/arch/m68k/include/asm/virtconvert.h
+++ b/arch/m68k/include/asm/virtconvert.h
@@ -16,11 +16,13 @@
 /*
  * Change virtual addresses to physical addresses and vv.
  */
+#define virt_to_phys virt_to_phys
 static inline unsigned long virt_to_phys(void *address)
 {
return __pa(address);
 }
 
+#define phys_to_virt phys_to_virt
 static inline void *phys_to_virt(unsigned long address)
 {
return __va(address);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/15] m68k: fix and improve IO access

[Greg Ungerer]

Convert the ColdFire IO access functions to use asm-generic/io.h.

The motivation for these changes is to fix IO access problems found by
Angelo Dureghello during his work on ColdFire 5441x when running with
MMU enabled. It also bought to light problems with ColdFire systems that
have PCI bus support and their ability to access both the internal
peripherals and PCI bus peripherals.

Along with the fixes I improved the ColdFire PCI support so that it works
with the MMU disabled on the ColdFire 5475. Previously PCI bus support was
only allowed when building with the MMU enabled. Now you can enable and
use the PCI bus in any configuration - MMU enabled or disabled.

These changes force all ColdFire platforms to use the same IO access
family of functions. The existing code differentiated between systems
built with MMU enabled and MMU disabled - and there is really no reason
to do that. Ultimately it does result in the include/asm/io_no.h file
now being somewhat misnamed. Perhpas I should change that it?

All in all the changes result in a net removal of ~150 lines, so that is
a good thing too.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/Kconfig.bus   |8
 arch/m68k/coldfire/clk.c|8
 arch/m68k/coldfire/dma_timer.c  |   20 +-
 arch/m68k/coldfire/intc-2.c |   36 +--
 arch/m68k/coldfire/intc-simr.c  |   38 ++--
 arch/m68k/coldfire/intc.c   |   28 +-
 arch/m68k/coldfire/m520x.c  |   26 +-
 arch/m68k/coldfire/m5272.c  |   16 -
 arch/m68k/coldfire/m528x.c  |   29 +--
 arch/m68k/coldfire/m5441x.c |8
 arch/m68k/coldfire/m54xx.c  |   20 +-
 arch/m68k/coldfire/pci.c|  169 +++--
 arch/m68k/coldfire/pit.c|2
 arch/m68k/coldfire/reset.c  |4
 arch/m68k/coldfire/sltimers.c   |4
 arch/m68k/coldfire/stmark2.c|   12 -
 arch/m68k/coldfire/timers.c |6
 arch/m68k/include/asm/atarihw.h |1
 arch/m68k/include/asm/io.h  |   10 -
 arch/m68k/include/asm/io_mm.h   |  102 +-
 arch/m68k/include/asm/io_no.h   |  339 ++--
 arch/m68k/include/asm/kmap.h|   83 
 arch/m68k/include/asm/mcfgpio.h |   12 -
 arch/m68k/include/asm/nubus.h   |1
 arch/m68k/include/asm/q40_master.h  |2
 arch/m68k/include/asm/raw_io.h  |   14 -
 arch/m68k/include/asm/vga.h |9
 arch/m68k/include/asm/virtconvert.h |2
 arch/m68k/include/asm/zorro.h   |1
 arch/m68k/mm/kmap.c |8
 30 files changed, 433 insertions(+), 585 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h

[Greg Ungerer]

Move a copy of the definitions of the *_relaxed() macros into io_no.h
and io_mm.h. This precedes a change to the io_no.h file to use
asm-generic/io.h. They will be removed from io_no.h at that point.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/include/asm/io.h| 8 
 arch/m68k/include/asm/io_mm.h | 8 
 arch/m68k/include/asm/io_no.h | 8 
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index 756089c..00b4515 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -4,11 +4,3 @@
 #else
 #include 
 #endif
-
-#define readb_relaxed(addr)readb(addr)
-#define readw_relaxed(addr)readw(addr)
-#define readl_relaxed(addr)readl(addr)
-
-#define writeb_relaxed(b, addr)writeb(b, addr)
-#define writew_relaxed(b, addr)writew(b, addr)
-#define writel_relaxed(b, addr)writel(b, addr)
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index ed5333e..22e778e 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -524,4 +524,12 @@ static inline void ioport_unmap(void __iomem *p)
 {
 }
 
+#define readb_relaxed(addr)readb(addr)
+#define readw_relaxed(addr)readw(addr)
+#define readl_relaxed(addr)readl(addr)
+
+#define writeb_relaxed(b, addr)writeb(b, addr)
+#define writew_relaxed(b, addr)writew(b, addr)
+#define writel_relaxed(b, addr)writel(b, addr)
+
 #endif /* _IO_H */
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 86f45b4..ffe567e 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -189,4 +189,12 @@ static inline void ioport_unmap(void __iomem *p)
 
 #endif /* __KERNEL__ */
 
+#define readb_relaxed(addr)readb(addr)
+#define readw_relaxed(addr)readw(addr)
+#define readl_relaxed(addr)readl(addr)
+
+#define writeb_relaxed(b, addr)writeb(b, addr)
+#define writew_relaxed(b, addr)writew(b, addr)
+#define writel_relaxed(b, addr)writel(b, addr)
+
 #endif /* _M68KNOMMU_IO_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git pull] m68knommu changes for v4.17

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

Only a single fix to set the DMA masks in the ColdFire FEC platform
data structure. Stops the warning from dma-mapping.h coming out at
boot time.

Regards
Greg



The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274:

  Linux 4.16-rc7 (2018-03-25 12:44:30 -1000)

are available in the git repository at:

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

for you to fetch changes up to f61e64310b75733d782e930d1fb404b84699eed6:

  m68k: set dma and coherent masks for platform FEC ethernets (2018-03-28 
22:27:09 +1000)


Greg Ungerer (1):
  m68k: set dma and coherent masks for platform FEC ethernets

 arch/m68k/coldfire/device.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] m68k: mmu: fix IO access endianness for ColdFire family

[Greg Ungerer]

Hi Angelo,

On 06/03/18 22:56, Greg Ungerer wrote:
> On 06/03/18 09:13, Angelo Dureghello wrote:
>> On Mon, Mar 05, 2018 at 11:30:32PM +1000, Greg Ungerer wrote:
>>> On 02/03/18 22:24, Angelo Dureghello wrote:
>>>> On Fri, Mar 02, 2018 at 09:28:57AM +1000, Greg Ungerer wrote:
>>>>> On 01/03/18 22:32, Angelo Dureghello wrote:
>>>>>> This patch fixes IO access endianness, that should be big endian.
>>>>>> If any little endian peripheral may be connected, bytes should
>>>>>> be swapped in hardware.
>>>>>
>>>>> I am not sure I follow your meaning here. In many cases peripheral
>>>>> devices will be hooked up and they are inherently little endian
>>>>> but there is no hardware in between that will translate the endian.
>>>>> It is just something that has to be dealt with at the software driver
>>>>> level.
>>>>>
>>>>> So do you need to make this change for specific devices you are
>>>>> working with?
>>>>>
>>>>
>>>> Ok, well, i add some story to this patch. I was stuck from months
>>>> since  kernel was hanging silently when SPI driver was enabled in
>>>> conjunction with mmu enbabled (no issues in spi + nommu).
>>>> After hard debugging, i finally found the issue to be related to
>>>> a wrong ioremap, and, together (so a double issue), peripheral
>>>> registers was wrongly accessed as "little" endian.
>>>>
>>>> This was resulting in never getting any reply from SPI device, and
>>>> kernel hanging silently in a wait loop. So, in mmu mode (io_mm.h),
>>>> the mcf5441x IO peripheral address area (0xe000 to 0x)
>>>> needs to be accessed as "big endian".
>>>
>>> That kind of makes sense, the m68k/ColdFire is big-endian. And looking
>>> at the IO access for the non-MMU case that is what it does - just direct
>>> access. (So in other words they are native endianess access).
>>>
>>>
>>>> So to have mmu working on mcf5441x both patches are needed.
>>>>
>>>> As suggester by Geert, i isolated ioread/write to be big endian
>>>> for mcf5441x *only*.
>>>
>>> That for me is a big red flag. The 5441x is not special, so to need
>>> to have something specific for it doesn't really make sense.
>>>
>>>
>>
>> With MMU we have 5441x, 5445x, 547x and 548x. If i am not wrong,
>> 5441x is the only family without PCI, so this was the reason why
>> i isolated it, since looks like PCI access must be "litte endian".
> 
> The presence of a PCI bus in this case is a total red herring though.
> All the builtin peripherals are native endian - and that is the same
> across all ColdFire.
> 
> 
> [snip]
>>> But that is probably a moot point here, because you are talking about
>>> the SPI module that is part of the 5441x SoC right?
>>
>> Yes.
>>
>>> Its bus interface can't be changed. And of course it works when
>>> configured non-MMU.
>>>
>>> I would think that perhaps making then readl/writel native endian for
>>> all ColdFire builds (like non-MMU) makes more sense - its internal
>>> peripherals will certainly always be that.
>>>
>>> A consolidation of the all io access functions/macros so that ColdFire
>>> used the same definitions (irrespective of MMU/non-MMU) would make
>>> sense. That could lead to fixing PCI access in all modes as well.
>>>
>>
>> Ok. So if i understand i could create an include io_cf.h (mmu + nommu)
>> or similar name, with raw io access always as big endian for all. But
>> how to manage the PCI accesses, where the access shoud be little endian ?
> 
> We already have raw access routines that are native endian (so big-endian
> for us) in arch/m68k/include/asm/raw_io.h. And those are used by the
> timer support code (in arch/m68k/coldfire/) and this has sort of
> hidden the problem that you have now found. So that is not really
> the answer here - you probably won't be able to change the readl/write/etc
> used by the SPI driver.
> 
> What your are seeing also exposes a problem with the current PCI
> access code for ColdFire. It just treats all readl/writel/etc as
> little endian - which you can see is not true for internal peripherals.
> 
> The readl/writel/etc functions could check the physical access address
> and do the right thing (so if in the PCI mapped range then byte swap,
> otherwise don't. That feels

Re: [PATCH] net: fec: set dma_coherent_mask

[Greg Ungerer]

Hi Geert,

On 28/03/18 17:57, Geert Uytterhoeven wrote:
[skip]

[PATCH] m68k: set dma and coherent masks for platform FEC ethernets

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
 41833dd8 40259c53 40025534 40279e26 0003  4004e514 41827000
 400255de 40244e42 0204 40159e20 0009   4024531d
 40159e20 40244e42 0204    0007 
  40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
 7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 4013e71c
 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
Call Trace:
 [<40025534>] 0x40025534
  [<4004e514>] 0x4004e514
  [<400255de>] 0x400255de
  [<40159e20>] 0x40159e20
  [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
  arch/m68k/coldfire/device.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 84938fd..f93e0e5 100644
--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -130,12 +130,18 @@
 },
  };

+static u64 mcf_dma_mask = DMA_BIT_MASK(32);
+
  static struct platform_device mcf_fec0 = {
 .name   = FEC_NAME,
 .id = 0,
 .num_resources  = ARRAY_SIZE(mcf_fec0_resources),
 .resource   = mcf_fec0_resources,
-   .dev.platform_data  = FEC_PDATA,
+   .dev = {
+   .dma_mask   = _dma_mask,


Can you make this _fec0.dev.coherent_dma_mask, removing the need for
mcf_dma_mask, or doesn't C allow that?


Yes, sure can. Looks like some other architectures do that too.
I'll change it. Thanks.

Regards
Greg




+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = FEC_PDATA,
+   }
  };

  #ifdef MCFFEC_BASE1
@@ -167,7 +173,11 @@
 .id = 1,
 .num_resources  = ARRAY_SIZE(mcf_fec1_resources),
 .resource   = mcf_fec1_resources,
-   .dev.platform_data  = FEC_PDATA,
+   .dev = {
+   .dma_mask   = _dma_mask,


Likewise.


+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = FEC_PDATA,
+   }


Gr{oetje,eeting}s,

 Geert



--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: fec: set dma_coherent_mask

[Greg Ungerer]

Hi Geert,

On 27/03/18 22:59, Geert Uytterhoeven wrote:
> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <g...@linux-m68k.org> wrote:
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the Freescale FEC driver is issuing the following
>> warning on driver initialization on ColdFire systems:
>>
>> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
>> Stack from 41833dd8:
>> 41833dd8 40259c53 40025534 40279e26 0003  4004e514 
>> 41827000
>> 400255de 40244e42 0204 40159e20 0009   
>> 4024531d
>> 40159e20 40244e42 0204    0007 
>> 
>>  40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 
>> 41833ef8
>> 7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 
>> 4013e71c
>> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
>> 
>> Call Trace:
>> [<40025534>] 0x40025534
>>  [<4004e514>] 0x4004e514
>>  [<400255de>] 0x400255de
>>  [<40159e20>] 0x40159e20
>>  [<40159e20>] 0x40159e20
>>
>> It is not fatal, the driver and the system continue to function normally.
>>
>> As per the warning the coherent_dma_mask is not set on this device.
>> There is nothing special about the DMA memory coherency on this hardware
>> so we can just set the mask to 32bits during probe.
>>
>> Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
> 
> Thanks for your patch!
> 
>> ---
>>  drivers/net/ethernet/freescale/fec_main.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> Is this the best way to handle this problem?
>> Comments welcome...
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
>> b/drivers/net/ethernet/freescale/fec_main.c
>> index d4604bc..3cb130a 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device 
>> *ndev)
>> int ret = 0;
>> struct fec_enet_priv_tx_q *txq;
>>
>> +   dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(32));
>> +
>> for (i = 0; i < fep->num_tx_queues; i++) {
>> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
>> if (!txq) {
> 
> As per your other email, this does not trigger on iMX systems using DT.
> Hence I'm wondering if the Coldfire platform code shouldn't just do the
> same what drivers/of/device.c does, cfr.
> https://www.spinics.net/lists/linux-m68k/msg10929.html?

I had been thinking that all along, but I couldn't see how to set this when
there was no real bus involved that would have configured this. Turns out
for platform devices you can set it as part of the platform setup. So now
the patch becomes specific to the ColdFire and FEC ethernet devices.

Regards
Greg

---

[PATCH] m68k: set dma and coherent masks for platform FEC ethernets

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 0003  4004e514 41827000
400255de 40244e42 0204 40159e20 0009   4024531d
40159e20 40244e42 0204    0007 
 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
Call Trace:
[<40025534>] 0x40025534
 [<4004e514>] 0x4004e514
 [<400255de>] 0x400255de
 [<40159e20>] 0x40159e20
 [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/coldfire/device.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 84938fd

Re: Coherent DMA mask warning

[Greg Ungerer]

Hi Michael,

On 26/02/18 14:42, Michael Schmitz wrote:

the driver in question must use dma_alloc_coherent without good reason,
then ...

The line that triggers it in my case is

 esp->command_block = dma_alloc_coherent(esp->dev, 16,
 >command_block_dma,
 GFP_KERNEL);

Am I reading the DMA API documentation correctly if I conclude DMA
addressable main memory on the m68k architecture is always consistent or
coherent (some semantic confusion about the two), regardless of the need
for processor cache maintenance on most processors?


It turned out that it was the freescale FEC ethernet driver in my case.
(https://www.spinics.net/lists/linux-m68k/msg3.html)

I don't think there is any doubt that it is using dma_alloc_coherent()
correctly. And I haven't seen any reports of this warning triggering
on ARM platforms that use this driver (iMX family). Things is they all
use devicetree whereas the ColdFire uses the old style platform driver
setup.

Regards
Greg



Geert: I suppose ARAnyM uses no driver that would do DMA. The SCSI
driver might go through the motions and register DMA accessible memory
for use as dribble buffer, but it does not use the DMA API for that
(needs to access ST-RAM from either pool set aside at boot right after
the end of kernel code, or from ioremapped ST-RAM if the kernel runs in
FastRAM).

Cheers,

Michael




Am 26.02.2018 um 12:50 schrieb Greg Ungerer:

On 25/02/18 20:47, Geert Uytterhoeven wrote:

Hi Michael,

On Sat, Feb 24, 2018 at 10:40 PM, Michael Schmitz <schmitz...@gmail.com> wrote:

I just the saw a coherent DMA warning triggered by zorro_esp after
updating to 4.16-rc2 (commit 205e1b7f51e4af2643eb1d61a6503e415cd1e014).
What DMA mask should Zorro devices use? The full 32 bit address space
can be used by the Amiga DMA engines, right?

Are DMA engines on m68k at all coherent? We do use explicit cache push
or invalidate on the address range programmed for DMA, so no coherent  DMA?


Greg reported a similar issue.
https://lkml.org/lkml/2018/2/23/1336

Haven't looked into it myself yet (it doesn't trigger on ARAnyM ;-)


Funny thing is that platform I see it on doesn't use DMA at all...

Regards
Greg




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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html







--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: fec: set dma_coherent_mask

[Greg Ungerer]

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 0003  4004e514 41827000
400255de 40244e42 0204 40159e20 0009   4024531d
40159e20 40244e42 0204    0007 
 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
Call Trace:
[<40025534>] 0x40025534
 [<4004e514>] 0x4004e514
 [<400255de>] 0x400255de
 [<40159e20>] 0x40159e20
 [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits during probe.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 ++
 1 file changed, 2 insertions(+)

Is this the best way to handle this problem?
Comments welcome...

diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc..3cb130a 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
int ret = 0;
struct fec_enet_priv_tx_q *txq;
 
+   dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(32));
+
for (i = 0; i < fep->num_tx_queues; i++) {
txq = kzalloc(sizeof(*txq), GFP_KERNEL);
if (!txq) {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html