Re: [uClinux-dev] [PATCH] m68k: merge the MMU and non-MMU signal.c code
On Tue, Apr 3, 2012 at 6:44 AM, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org The MMU (signal_mm.c) and non-MMU (signal_no.c) versions of the m68k architecture signal handling code are very similar. Most of there code is the same. Merge the two back into a single signal.c, and move some of the code around inside the file to minimize the number of #ifdefs required. Specificially we can group out the CONFIG_FPU and the CONFIG_MMU code. We end up needing a few other #ifdef CONFIG_MMU as well, but not too many. Signed-off-by: Greg Ungerer g...@uclinux.org A bit late, but still Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 2/2] m68k: merge the MMU and non-MMU versions of the arch dma code
On Fri, May 4, 2012 at 8:50 AM, g...@snapgear.com wrote: 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 Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 1/2] m68knommu: reorganize the no-MMU cache flushing to match m68k
On Fri, May 4, 2012 at 8:50 AM, g...@snapgear.com wrote: In particular by reorganizing the __flush_caceh_all() code and separating __flush_cache_all() Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH v2 2/3] m68k: use jbsr to call functions instead of bsrl
On Fri, May 18, 2012 at 6:22 AM, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org There is a few places that the m68k entry code uses the bsrl instruction to call other functions. That instruction is only supported on 68020 and higher CPU types. If we use jbsr instead the code will be clean for all 68k and ColdFire CPU types. Signed-off-by: Greg Ungerer g...@uclinux.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH v2 1/3] m68k: use some direct calls to ret_from_exception in entry code
On Fri, May 18, 2012 at 6:22 AM, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org The ret_from_excption code is referenced by its function name, or by a label set at the start of its code. The non-MMU code can share some of this code if we make direct calls to ret_from_exception instead of the associated label. The effected function paths are: buserr, trap and ret_from_fork. So change these to branch directly to ret_from_exception. Signed-off-by: Greg Ungerer g...@uclinux.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH v2 3/3] m68k: merge the MMU and non-MMU versions of the entry.S code
On Fri, May 18, 2012 at 6:22 AM, g...@snapgear.com wrote: From: Greg Ungerer g...@uclinux.org Some of the entry.S code is common to both MMU and non-MMU builds. So merge the entry_no.S and entry_mm.S files back into a single file. With a little code movement we only need a single #ifdef. Signed-off-by: Greg Ungerer g...@uclinux.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 1/2] m68knommu: reorganize the no-MMU cache flushing to match m68k
Hi Geert, On 05/20/2012 07:07 PM, Geert Uytterhoeven wrote: On Fri, May 4, 2012 at 8:50 AM,g...@snapgear.com wrote: In particular by reorganizing the __flush_caceh_all() code and separating __flush_cache_all() I'll fix that up. Thanks for all the other acks too, I'll update the patches. 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