Re: [PATCH] m68k: coldfire: Include the GPIO driver header
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
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
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
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
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
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
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 p
Re: [PATCH] m68knommu: Add SW_A7 support to mcf5329
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
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
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
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
Hi Mike, On 13/5/19 3:20 pm, Mike Rapoport wrote: On Mon, May 13, 2019 at 02:59:52PM +1000, Greg Ungerer wrote: 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. The ColdFire configs do not seem to enable SINGLE_MEMORY_CHUNK: config SINGLE_MEMORY_CHUNK bool "Use one physical chunk of memory only" if ADVANCED && !SUN3 depends on MMU default y if SUN3 When SINGLE_MEMORY_CHUNK=n, Kconfig enables SPARSEMEM as the only memory model. Is it possible for ColdFile to have more than a single memory bank? I don't know of any that do. Theoretically you could have a DRAM bank and a bank for the internal SRAM - but in practice I don't think anybody ever did that. If not, the patch below should fix ColdFire boot: Yep, that does fix it. Regards Greg diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index 1b056d24c554..2a547c927578 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -375,7 +375,7 @@ config RMW_INSNS config SINGLE_MEMORY_CHUNK bool "Use one physical chunk of memory only" if ADVANCED && !SUN3 depends on MMU - default y if SUN3 + default y if SUN3 || MMU_COLDFIRE help Ignore all but the first contiguous chunk of physical memory for VM purposes. This will save a few bytes kernel size and may speed up 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)) + n
Re: mcf5441x, mmu boot not working anymore
Hi Angelo, On 12/5/19 5:59 pm, Angelo Dureghello wrote: Hi all, resending this in the proper mailing (sent to lkml for error). Just rebased to master right now, so @ > 5.1.1, nommu boot works, mmu boot hangs without any message. Before rebase i was near 5.1-rc1 but lost the log, unfortunately. I am booting linux passing a ramfs address of a ramfs loaded in memory from u-boot. After some investigations, just found this: - without passing the ramfs, kernel boots. - with ramfs, adding some low level traces, i get: 5Linux version 5.1.0stmark2-001-09826-gd881126bf3f8-dirty (angelo@box) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #221 Sun May 12 00:31:57 CEST 2019 initrd at 0x47d33000:0x47d85e44 overlap at 1073741889 for chunk 0 overlap at 1073746160 for chunk 0 overlap at 1073746719 for chunk 0 overlap at 1073746720 for chunk 0 overlap at 1073746721 for chunk 0 overlap at 1073746722 for chunk 0 Can you git bisect to find which commit breaks it? Regards Greg
Re: [RFC/RFT PATCH 3/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM
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 >> PAGE_S
Re: [PATCH 3/3] mmc: enabling ColdFire esdhc controller support
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
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
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
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
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
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
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 = &mcf_edma_dmamask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &mcf_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 = { &mcf_uart, #if IS_ENABLED(CONFIG_FEC) @@ -505,6 +583,9 @@ static struct platform_device *mcf_devices[] __initdata = { &mcf_i2c5, #endif #endif +#if IS_ENABLED(CONFIG_MCF_EDMA) + &mcf_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 */ - &_
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
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_*
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 = __pgpro
Re: [PATCH v6 3/6] m68k: coldfire: Add clk_get_optional() function
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
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
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?
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
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?
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
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
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; }
[git pull] m68knommu fix for v4.19
Hi Linus, Can you please pull the m68knommu git tree, for-linus branch. A single change to fix booting on ColdFire platforms that have RAM starting at a non-0 address. Regards Greg The following changes since commit 57361846b52bc686112da6ca5368d11210796804: Linux 4.19-rc2 (2018-09-02 14:37:30 -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 c90bbce9eedd14f9428388d9442b5b3e98a2a6dd: m68k: fix early memory reservation for ColdFire MMU systems (2018-09-03 10:19:36 +1000) Mike Rapoport (1): m68k: fix early memory reservation for ColdFire MMU systems arch/m68k/mm/mcfmmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH] m68k: fix command-line parsing when passed from u-boot
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(&command_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
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
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
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
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
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 n
Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
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
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 = &command_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
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
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
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
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
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) &dmalp[MCFDMA_DMR], dmabp[MCFDMA_DMR], +dmanr, (int) &dmalp[MCFDMA_DMR], dmalp[MCFDMA_DMR], (int) &dmawp[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) &dmawp[MCFDMA_DMR], dmawp[MCFDMA_DMR], + __FILE__, __LINE__, dmanr, (int) &dmalp[MCFDMA_DMR], dmalp[MCFDMA_DMR], (int) &dmalp[MCFDMA_DSAR], dmalp[MCFDMA_DSAR], (int) &dmalp[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
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
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 &m68k_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
Re: coldfire/m68knommu dma coherency
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
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(&mste_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(&dma_wd.fdc_speed) && hwreg_write(&dma_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(&val); -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(&val); -} -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, sa
Re: coldfire/m68knommu dma coherency
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
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
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
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
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
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
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
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
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
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
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 = &pdev->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
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 > Signed-off-by: Finn Thain > --- > 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 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()
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 http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/14] m68k: fix and improve IO access — Linux M68K Devel
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 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 >> --- >> 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
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 Signed-off-by: Greg Ungerer Reviewed-by: Angelo Dureghello --- 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
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 --- 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
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 Reviewed-by: Angelo Dureghello --- 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
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 Reviewed-by: Angelo Dureghello --- 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
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 Reviewed-by: Angelo Dureghello --- 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 outsw(a,b,l) io_outsw(a,b,l) -#define outsl(a,b,l) io
[PATCHv2 05/14] m68k: group io mapping definitions and functions
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 --- 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, unsigned long
[PATCHv2 10/14] m68k: fix read/write multi-byte IO for PCI on ColdFire
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 PCI 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 --- arch/m68k/include/asm/io_no.h | 99 --- 1 file changed, 84 insertions(+), 15 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 42d61d4..ccb8c31 100644 --- a/arch/m68k/include/asm/io_no.h +++ b/arch/m68k/include/asm/io_no.h @@ -18,16 +18,95 @@ #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) +#if 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. + * For ColdFire platforms we may need to do some extra checks for what + * type of address range we are accessing. Include the ColdFire platform + * definitions so we can figure out if need to do something special. */ #include #include #include +#endif /* CONFIG_COLDFIRE */ + +#if defined(IOMEMBASE) +/* + * 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. This check logic + * applies just the same of there is no MMU but something like a PCI bus + * is present. + */ +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 PCI 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 +#define readw __raw_readw +#define readl __raw_readl +#define writeb __raw_writeb +#define writew __raw_writew +#define writel __raw_writel +#endif /* IOMEMBASE */ + +#if defined(CONFIG_PCI) +/* + * 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. + */ #define PCI_MEM_PA 0xf000 /* Host physical address */ #define PCI_MEM_BA 0xf000 /* Bus physical address */ #define PCI_MEM_SIZE 0x0800 /* 128 MB */ @@ -44,17 +123,7 @@ #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 -#define writeb __raw_writeb -#define writew __raw_writew -#define writel __raw_writel - -#endif /* CONFIG_PCI && CONFIG_COLDFIRE */ +#endif /* CONFIG_PCI */ /* * These are defined in kma
[PATCHv2 01/14] m68k: move *_relaxed macros into io_no.h and io_mm.h
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 Reviewed-by: Geert Uytterhoeven Reviewed-by: Angelo Dureghello --- 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
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 --- 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
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 Reviewed-by: Angelo Dureghello --- 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
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 Signed-off-by: Greg Ungerer Reviewed-by: Angelo Dureghello --- 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
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 Reviewed-by: Geert Uytterhoeven Reviewed-by: Angelo Dureghello --- 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
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 Reviewed-by: Angelo Dureghello --- 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
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 Reviewed-by: Angelo Dureghello --- 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 len); -void mcf_pci_insl(u32 addr, u32 *buf, u32
[PATCHv2 04/14] m68k: rework raw access macros for the non-MMU case
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 Reviewed-by: Angelo Dureghello --- 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
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 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 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()
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
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 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 >> --- >> 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
On 12/04/18 04:50, Geert Uytterhoeven wrote: On Wed, Apr 11, 2018 at 2:54 PM, 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 Reviewed-by: Geert Uytterhoeven 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
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 --- 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
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 --- 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
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 --- 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 DTCN0 (MCF_IPSBAR + DMA_
[PATCH 12/15] m68k: allow ColdFire PCI bus on MMU and non-MMU configuration
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 --- 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
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 Signed-off-by: Greg Ungerer --- 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
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 --- 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
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 --- 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 v, u32 addr); -void
[PATCH 09/15] m68k: don't redefine access functions if we have PCI
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 --- 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
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 --- 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 __iomem *ioremap_wt(unsigned long
[PATCH 04/15] m68k: rework raw access macros for the non-MMU case
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 --- 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
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 Signed-off-by: Greg Ungerer --- 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
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 --- 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 02/15] m68k: put definition guards around virt_to_phys and phys_to_virt
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 --- 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
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 --- 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 03/15] m68k: use asm-generic/io.h for non-MMU io access functions
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 --- 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,l) -#define insl(a,b,l) io_insl
[PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h
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 --- 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
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
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 do