[uClinux-dev] [PATCH 1/2] m68knommu: reorganize the no-MMU cache flushing to match m68k
From: Greg Ungerer g...@uclinux.org
Introduce cache_push() and cache_clear() functions for the non-MMU m68k
devices. With these in place we can more easily merge some of the common
m68k arch code.
In particular by reorganizing the __flush_caceh_all() code and separating
the cache push and clear functions it becomes trivial to implement the
new cache_push() and cache_clear() functions.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/cacheflush_no.h | 32
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/include/asm/cacheflush_no.h
b/arch/m68k/include/asm/cacheflush_no.h
index cb88aa9..7cafb53 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -30,11 +30,8 @@
void mcf_cache_push(void);
-static inline void __flush_cache_all(void)
+static inline void __clear_cache_all(void)
{
-#ifdef CACHE_PUSH
- mcf_cache_push();
-#endif
#ifdef CACHE_INVALIDATE
__asm__ __volatile__ (
movel %0, %%d0\n\t
@@ -44,6 +41,14 @@ static inline void __flush_cache_all(void)
#endif
}
+static inline void __flush_cache_all(void)
+{
+#ifdef CACHE_PUSH
+ mcf_cache_push();
+#endif
+ __clear_cache_all();
+}
+
/*
* Some ColdFire parts implement separate instruction and data caches,
* on those we should just flush the appropriate cache. If we don't need
@@ -76,4 +81,23 @@ static inline void __flush_dcache_all(void)
__asm__ __volatile__ ( nop );
#endif
}
+
+/*
+ * Push cache entries at supplied address. We want to write back any dirty
+ * data and the invalidate the cache lines associated with this address.
+ */
+static inline void cache_push(unsigned long paddr, int len)
+{
+ __flush_cache_all();
+}
+
+/*
+ * Clear cache entries at supplied address (that is don't write back any
+ * dirty data).
+ */
+static inline void cache_clear(unsigned long paddr, int len)
+{
+ __clear_cache_all();
+}
+
#endif /* _M68KNOMMU_CACHEFLUSH_H */
--
1.7.0.4
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 00/02] m68k: clean up and merge arch dma code
m68k: clean up and merge arch dma code Much of the common m68k architecture dma code is the same for the MMU and non-MMU cases. With a little cleanup of the m68knommu dma code first we can then merge the two to end up with a single arch dma.c. I have only tested a small number of ColdFire platforms so far, and they all seem to check out as before. There should be no functional change for MMU m68k systems. --- arch/m68k/kernel/dma_mm.c | 131 - arch/m68k/kernel/dma_no.c | 75 -- b/arch/m68k/include/asm/cacheflush_no.h | 32 +- b/arch/m68k/kernel/dma.c| 165 +++- 4 files changed, 190 insertions(+), 213 deletions(-) ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 2/2] m68k: merge the MMU and non-MMU versions of the arch dma code
From: Greg Ungerer g...@uclinux.org
The majority of the m68k architecture dma code is the same, so merge the
current separated files dma_no.c and dma_mm.c back into a single dma.c
The main alloc and free routines are a little different, so we keep a
single #ifdef based on CONFIG_MMU for them. All the other support functions
are now identical.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/kernel/{dma_mm.c = dma.c} | 35 +++-
arch/m68k/kernel/dma_no.c| 75 --
2 files changed, 34 insertions(+), 76 deletions(-)
rename arch/m68k/kernel/{dma_mm.c = dma.c} (83%)
delete mode 100644 arch/m68k/kernel/dma_no.c
diff --git a/arch/m68k/kernel/dma_mm.c b/arch/m68k/kernel/dma.c
similarity index 83%
rename from arch/m68k/kernel/dma_mm.c
rename to arch/m68k/kernel/dma.c
index a3c471b..f6daf6e 100644
--- a/arch/m68k/kernel/dma_mm.c
+++ b/arch/m68k/kernel/dma.c
@@ -16,6 +16,8 @@
#include asm/pgalloc.h
+#ifdef CONFIG_MMU
+
void *dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *handle, gfp_t flag)
{
@@ -58,7 +60,6 @@ void *dma_alloc_coherent(struct device *dev, size_t size,
return addr;
}
-EXPORT_SYMBOL(dma_alloc_coherent);
void dma_free_coherent(struct device *dev, size_t size,
void *addr, dma_addr_t handle)
@@ -66,6 +67,38 @@ void dma_free_coherent(struct device *dev, size_t size,
pr_debug(dma_free_coherent: %p, %x\n, addr, handle);
vfree(addr);
}
+
+#else
+
+#include asm/cacheflush.h
+
+void *dma_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp)
+{
+ void *ret;
+ /* ignore region specifiers */
+ gfp = ~(__GFP_DMA | __GFP_HIGHMEM);
+
+ if (dev == NULL || (*dev-dma_mask 0x))
+ gfp |= GFP_DMA;
+ ret = (void *)__get_free_pages(gfp, get_order(size));
+
+ if (ret != NULL) {
+ memset(ret, 0, size);
+ *dma_handle = virt_to_phys(ret);
+ }
+ return ret;
+}
+
+void dma_free_coherent(struct device *dev, size_t size,
+void *vaddr, dma_addr_t dma_handle)
+{
+ free_pages((unsigned long)vaddr, get_order(size));
+}
+
+#endif /* CONFIG_MMU */
+
+EXPORT_SYMBOL(dma_alloc_coherent);
EXPORT_SYMBOL(dma_free_coherent);
void dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
diff --git a/arch/m68k/kernel/dma_no.c b/arch/m68k/kernel/dma_no.c
deleted file mode 100644
index f1dc3fc..000
--- a/arch/m68k/kernel/dma_no.c
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * Dynamic DMA mapping support.
- *
- * We never have any address translations to worry about, so this
- * is just alloc/free.
- */
-
-#include linux/types.h
-#include linux/gfp.h
-#include linux/mm.h
-#include linux/device.h
-#include linux/dma-mapping.h
-#include linux/export.h
-#include asm/cacheflush.h
-
-void *dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp)
-{
- void *ret;
- /* ignore region specifiers */
- gfp = ~(__GFP_DMA | __GFP_HIGHMEM);
-
- if (dev == NULL || (*dev-dma_mask 0x))
- gfp |= GFP_DMA;
- ret = (void *)__get_free_pages(gfp, get_order(size));
-
- if (ret != NULL) {
- memset(ret, 0, size);
- *dma_handle = virt_to_phys(ret);
- }
- return ret;
-}
-
-void dma_free_coherent(struct device *dev, size_t size,
-void *vaddr, dma_addr_t dma_handle)
-{
- free_pages((unsigned long)vaddr, get_order(size));
-}
-
-void dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
- size_t size, enum dma_data_direction dir)
-{
- switch (dir) {
- case DMA_TO_DEVICE:
- flush_dcache_range(handle, size);
- break;
- case DMA_FROM_DEVICE:
- /* Should be clear already */
- break;
- default:
- if (printk_ratelimit())
- printk(dma_sync_single_for_device: unsupported dir
%u\n, dir);
- break;
- }
-}
-
-EXPORT_SYMBOL(dma_sync_single_for_device);
-dma_addr_t dma_map_single(struct device *dev, void *addr, size_t size,
- enum dma_data_direction dir)
-{
- dma_addr_t handle = virt_to_phys(addr);
- flush_dcache_range(handle, size);
- return handle;
-}
-EXPORT_SYMBOL(dma_map_single);
-
-dma_addr_t dma_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir)
-{
- dma_addr_t handle = page_to_phys(page) + offset;
- dma_sync_single_for_device(dev, handle, size, dir);
- return handle;
-}
-EXPORT_SYMBOL(dma_map_page);
--
1.7.0.4
___
uClinux-dev mailing list
Re: [uClinux-dev] [PATCH 1/1] 68000 code integration
Hi Greg, On Fri, May 4, 2012 at 7:53 AM, Greg Ungerer g...@snapgear.com wrote: Hi Luis, On 01/05/12 06:42, Luis Alves wrote: Here is my second attempt for the 68000 code integration. What I have done: Merged all 68000 based cpu's in platform/68000 and deleted 68*328 subdirs. Modified respective Makefile's to correctly build each target. Added support for my board/cpu in Kconfig's Merged all head.S files into one. Overall this is starting to look really good. I like the common 68000 platform directory. That has worked out well. Did you send this to the m68k-linux list as well? I don't see it in the CC list. Yes, but in two separated emails (I had some headache with google smtp server). This is a big patch on its own though. Do you think there is any way you can break it up, into logical but smaller pieces? Something like firstly a patch that reorgs the directories for current 68x328 targets. Then follow on patches that add your board support. Oh, and another suggestion :-) Did you use git to generate this? If you use git format-patch with the -B and -M options it will handle moves and renames a little better, producing much smaller patches for email list review. It will collapse those pesky bootlogo.h files in this patch for example. And it also makes it much easier to see any changes made to moved files that are otherwise no obvious. Yes, I've used git with Linus kernel as base, but I've just started using git and don't know all the available options and features. I'll try out the referred options. Oh, sorry, another suggestion as well :-) If you run this patch through the kernels scripts/checkpatch.pl checker it will list out any formating issues. It would be good to fix those up as well. Your suggestions are always welcome :) I'll run that script. An observation from the patch, the 68000/entry-*.S files all look quite similar. Is there any way they can be merged into a single file? I'm just noticed that accidentally I've added the 'entry-68000.S'! This file should be removed. About merging, yes I plan to do it later. The thing is that in my first attempt of running this kernel in the 68000 the entry code from the 68328 had a strange behavior (you should remember debugging this with me - lots of softlocks). Then I've used the entry.S from coldfire sources as base and it worked smooth. Also, the existing trap exception code doesn't work with 68000 cpu's since they don't provide the vector in the stack. Thanks for doing this, it is looking really nice. The pleasure is all mine :) Regards, Luis Regards Greg In future iterations, more code can/will be merged. For the 68000 (and my board) the code is working fine. I have a fast and stable kernel running in the old 68000. It would be nice if someone could test the 68[xx]328 target code and eventually fix any bugs. The exception code for the 68000 is not yet completed (not having the exception vector on the stack is boring). I plan to send future updates for the 68000 (and the code for my board drivers, not included in this patch) Regards, Luis Alves --- arch/m68k/Kconfig.cpu | 2 +- arch/m68k/Kconfig.machine | 6 + arch/m68k/Makefile | 6 +- arch/m68k/include/asm/alce68k.h | 136 ++ arch/m68k/kernel/setup_no.c | 3 + arch/m68k/platform/68000/Makefile | 26 + arch/m68k/platform/68000/bootlogo-vz.h | 3204 + arch/m68k/platform/68000/bootlogo.h | 270 +++ arch/m68k/platform/68000/config-alce68k.c | 179 ++ arch/m68k/platform/68000/config-ez.c | 76 + arch/m68k/platform/68000/config-vz.c | 188 ++ arch/m68k/platform/68000/config.c | 55 + arch/m68k/platform/68000/entry-68000.S | 463 + arch/m68k/platform/68000/entry-alce68k.S | 453 arch/m68k/platform/68000/entry.S | 261 +++ arch/m68k/platform/68000/head.S | 310 +++ arch/m68k/platform/68000/ints-alce68k.c | 387 arch/m68k/platform/68000/ints.c | 186 ++ arch/m68k/platform/68000/romvec.S | 35 + arch/m68k/platform/68000/timers-alce68k.c | 112 + arch/m68k/platform/68000/timers.c | 135 ++ arch/m68k/platform/68328/Makefile | 21 - arch/m68k/platform/68328/bootlogo.h | 270 --- arch/m68k/platform/68328/config.c | 55 - arch/m68k/platform/68328/entry.S | 261 --- arch/m68k/platform/68328/head-de2.S | 128 -- arch/m68k/platform/68328/head-pilot.S | 207 -- arch/m68k/platform/68328/head-ram.S | 141 -- arch/m68k/platform/68328/head-rom.S | 105 - arch/m68k/platform/68328/ints.c | 186 -- arch/m68k/platform/68328/romvec.S | 35 - arch/m68k/platform/68328/timers.c | 135 -- arch/m68k/platform/68EZ328/Makefile | 5 - arch/m68k/platform/68EZ328/config.c
[uClinux-dev] rrdtool: crashing when rendering graphics (m68k target)
Hi, I've tried the 'rrdtool' included in the latest uClinux dist (20120401). Creating the database, inserting and fetching values work fine, but when I try to create a .png chart it do one of these two things: 1) Crash the kernel (I'm almost sure it writes in bad memory locations) 2) Give an 'Address Error' trap. Before I start to dig the code to find the issue (if I ever get time to do it), has anyone used this tool in a m68k target? If yes, does it work good? What about in other nommu targets? Thanks, Luis ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] rrdtool: crashing when rendering graphics (m68k target)
Thanks a lot Greg! Increased the stack size and it works now! By default it is set to the 4k default. Always learning! Thanks and Regards, Luis Alves No dia 4 de Mai de 2012 14:41, Greg Ungerer g...@snapgear.co Hi Luis, On 05/04/2012 07:58 PM, Luis Alves wrote: I've tried the 'rrdtool' included in the latest uClinux dist (20120401). Creating the database, inserting and fetching values work fine, but when I try to create a .png chart it do one of these two things: 1) Crash the kernel (I'm almost sure it writes in bad memory locations) 2) Give an 'Address Error' trap. Before I start to dig the code to find the issue (if I ever get time to do it), has anyone used this tool in a m68k target? If yes, does it work good? What about in other nommu targets? I haven't used rrdtool on uClinux, so I can't verify that it works. But when you see these sorts of odd crashes the first thing I try is to increase the stack size of the app. Its all too easy to overrun your app stack. If you grep for FLTFLAGS in user/*/Makefile you will see how to set a larger stack size. Regards Greg --**--** Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
