summaryrefslogtreecommitdiffstats
path: root/arch/m68k/include
Commit message (Collapse)AuthorAgeFilesLines
* remove dma64_addr_tFUJITA Tomonori2011-03-231-6/+0
| | | | | | | | | | | | | There is no user now. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: David Miller <davem@davemloft.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* bitops: remove minix bitops from asm/bitops.hAkinobu Mita2011-03-232-32/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | minix bit operations are only used by minix filesystem and useless by other modules. Because byte order of inode and block bitmaps is different on each architecture like below: m68k: big-endian 16bit indexed bitmaps h8300, microblaze, s390, sparc, m68knommu: big-endian 32 or 64bit indexed bitmaps m32r, mips, sh, xtensa: big-endian 32 or 64bit indexed bitmaps for big-endian mode little-endian bitmaps for little-endian mode Others: little-endian bitmaps In order to move minix bit operations from asm/bitops.h to architecture independent code in minix filesystem, this provides two config options. CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k. CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu, m32r, mips, sh, xtensa). The architectures which always use little-endian bitmaps do not select these options. Finally, we can remove minix bit operations from asm/bitops.h for all architectures. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Ungerer <gerg@uclinux.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: "David S. Miller" <davem@davemloft.net> Cc: Hirokazu Takata <takata@linux-m32r.org> Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Paul Mundt <lethal@linux-sh.org> Cc: Chris Zankel <chris@zankel.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* m68k: remove inline asm from minix_find_first_zero_bitAkinobu Mita2011-03-231-7/+3
| | | | | | | | | | | | | As a preparation for moving minix bit operations from asm/bitops.h to architecture independent code in minix filesystem, this removes inline asm from minix_find_first_zero_bit() for m68k. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* bitops: remove ext2 non-atomic bitops from asm/bitops.hAkinobu Mita2011-03-232-14/+0
| | | | | | | | | | | | As the result of conversions, there are no users of ext2 non-atomic bit operations except for ext2 filesystem itself. Now we can put them into architecture independent code in ext2 filesystem, and remove from asm/bitops.h for all architectures. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* m68knommu: introduce little-endian bitopsAkinobu Mita2011-03-231-10/+27
| | | | | | | | | | | | | | | | | Introduce little-endian bit operations by renaming native ext2 bit operations. The ext2 bit operations are kept as wrapper macros using little-endian bit operations to maintain bisectability until the conversions are finished. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Greg Ungerer <gerg@uclinux.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* m68k: introduce little-endian bitopsAkinobu Mita2011-03-231-26/+67
| | | | | | | | | | | | | | | Introduce little-endian bit operations by renaming native ext2 bit operations and changing find_*_bit_le() to take a "void *". The ext2 bit operations are kept as wrapper macros using little-endian bit operations to maintain bisectability until the conversions are finished. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* asm-generic: rename generic little-endian bitops functionsAkinobu Mita2011-03-232-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | As a preparation for providing little-endian bitops for all architectures, This renames generic implementation of little-endian bitops. (remove "generic_" prefix and postfix "_le") s/generic_find_next_le_bit/find_next_bit_le/ s/generic_find_next_zero_le_bit/find_next_zero_bit_le/ s/generic_find_first_zero_le_bit/find_first_zero_bit_le/ s/generic___test_and_set_le_bit/__test_and_set_bit_le/ s/generic___test_and_clear_le_bit/__test_and_clear_bit_le/ s/generic_test_le_bit/test_bit_le/ s/generic___set_le_bit/__set_bit_le/ s/generic___clear_le_bit/__clear_bit_le/ s/generic_test_and_set_le_bit/test_and_set_bit_le/ s/generic_test_and_clear_le_bit/test_and_clear_bit_le/ Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Greg Ungerer <gerg@uclinux.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* add the common dma_addr_t typedef to include/linux/types.hFUJITA Tomonori2011-03-221-3/+0
| | | | | | | | | | | | | | | | | | | | | | All architectures can use the common dma_addr_t typedef now. We can remove the arch specific dma_addr_t. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Matt Turner <mattst88@gmail.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'for-linus' of ↵Linus Torvalds2011-03-162-0/+24
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k/block: amiflop - Remove superfluous amiga_chip_alloc() cast m68k/atari: ARAnyM - Add support for network access m68k/atari: ARAnyM - Add support for console access m68k/atari: ARAnyM - Add support for block access m68k/atari: Initial ARAnyM support m68k: Kconfig - Remove unneeded "default n" m68k: Makefiles - Change to new flags variables m68k/amiga: Reclaim Chip RAM for PPC exception handlers m68k: Allow all kernel traps to be handled via exception fixups m68k: Use base_trap_init() to initialize vectors m68k: Add helper function handle_kernel_fault()
| * m68k/atari: Initial ARAnyM supportPetr Stehlik2011-03-161-0/+22
| | | | | | | | | | | | | | | | | | | | | | Add improved support for running under the ARAnyM emulator (Atari Running on Any Machine - http://aranym.org/). [michael, geert: Cleanups and updates] Signed-off-by: Petr Stehlik <pstehlik@sophics.cz> Signed-off-by: Michael Schmitz <schmitz@debian.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
| * m68k: Add helper function handle_kernel_fault()Roman Zippel2011-03-161-0/+2
| | | | | | | | | | | | | | | | Add helper function handle_kernel_fault() in signal.c, so frame_extra_sizes can become static, and to avoid future code duplication. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
* | m68knommu: external interrupt support to ColdFire intc-simr controllerGreg Ungerer2011-03-151-0/+3
| | | | | | | | | | | | | | | | | | | | The EDGE Port module of some ColdFire parts using the intc-simr interrupt controller provides support for 7 external interrupts. These interrupts go off-chip (that is they are not for internal peripherals). They need some special handling and have some extra setup registers. Add code to support them. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: external interrupt support to ColdFire intc-2 controllerGreg Ungerer2011-03-153-0/+16
| | | | | | | | | | | | | | | | | | | | The EDGE Port module of some ColdFire parts using the intc-2 interrupt controller provides support for 7 external interrupts. These interrupts go off-chip (that is they are not for internal peripherals). They need some special handling and have some extra setup registers. Add code to support them. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove ColdFire CLOCK_DIV config optionGreg Ungerer2011-03-1512-5/+15
| | | | | | | | | | | | | | | | | | | | The reality is that you do not need the abiltity to configure the clock divider for ColdFire CPUs. It is a fixed ratio on any given ColdFire family member. It is not the same for all ColdFire parts, but it is always the same in a model range. So hard define the divider for each supported ColdFire CPU type and remove the Kconfig option. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: make ColdFire internal peripheral region configurableGreg Ungerer2011-03-151-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | Most ColdFire CPUs have an internal peripheral set that can be mapped at a user selectable address. Different ColdFire parts either use an MBAR register of an IPSBAR register to map the peripheral region. Most boards use the Freescale default mappings - but not all. Make the setting of the MBAR or IPSBAR register configurable. And only make the selection available on the appropriate ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: clean up definitions of ColdFire peripheral base registersGreg Ungerer2011-03-151-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | Different ColdFire CPUs have different ways of defining where their internal peripheral registers sit in their address space. Some use an MBAR register, some use and IPSBAR register, some have a fixed mapping. Now that most of the peripheral address definitions have been cleaned up we can clean up the setting of the MBAR and IPSBAR defines to limit them to just where they are needed (and where they actually exist). Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: clean up use of MBAR for DRAM registers on ColdFire startGreg Ungerer2011-03-157-46/+46
| | | | | | | | | | | | | | | | | | | | | | | | In some of the RAM size autodetection code on ColdFire CPU startup we reference DRAM registers relative to the MBAR register. Not all of the supported ColdFire CPUs have an MBAR, and currently this works because we fake an MBAR address on those registers. In an effort to clean this up, and eventually remove the fake MBAR setting make the DRAM register address definitions actually contain the MBAR (or IPSBAR as appropriate) value as required. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove use of MBAR in old-style ColdFire timerGreg Ungerer2011-03-157-24/+35
| | | | | | | | | | | | | | | | | | Not all ColdFire CPUs that use the old style timer hardware module use an MBAR set peripheral region. Move the TIMER base address defines to the per-CPU header files where we can set it correctly based on how the peripherals are mapped - instead of using a fake MBAR for some platforms. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: move ColdFire DMA register addresses to per-cpu headersGreg Ungerer2011-03-159-23/+54
| | | | | | | | | | | | | | | | | | | | | | The base addresses of the ColdFire DMA unit registers belong with all the other address definitions in the per-cpu headers. The current definitions assume they are relative to an MBAR register. Not all ColdFire CPUs have an MBAR register. A clean address define can only be acheived in the per-cpu headers along with all the other chips peripheral base addresses. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove use of MBAR value for ColdFire 528x peripheral addressingGreg Ungerer2011-03-151-3/+9
| | | | | | | | | | | | | | | | The ColdFire 528x family of CPUs does not have an MBAR register, so don't define its peripheral addresses relative to one. Its internal peripherals are relative to the IPSBAR register, so make sure to use that. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove use of MBAR value for ColdFire 527x peripheral addressingGreg Ungerer2011-03-151-3/+11
| | | | | | | | | | | | | | | | The ColdFire 527x family of CPUs does not have an MBAR register, so don't define its peripheral addresses relative to one. Its internal peripherals are relative to the IPSBAR register, so make sure to use that. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove use of MBAR value for ColdFire 523x peripheral addressingGreg Ungerer2011-03-151-3/+12
| | | | | | | | | | | | | | | | The ColdFire 523x family of CPUs does not have an MBAR register, so don't define its peripheral addresses relative to one. Its internal peripherals are relative to the IPSBAR register, so make sure to use that. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove MBAR and IPSBAR hacks for the ColdFire 520x CPUsGreg Ungerer2011-03-152-23/+24
| | | | | | | | | | | | | | | | | | | | The ColdFire 5207 and 5208 CPUs have fixed peripheral addresses. They do not use the setable peripheral address registers like the MBAR and IPSBAR used on many other ColdFire parts. Don't use fake values of MBAR and IPSBAR when using peripheral addresses for them, there is no need to. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: move ColdFire PIT timer base addressesGreg Ungerer2011-03-155-19/+31
| | | | | | | | | | | | | | | | | | | | | | | | The PIT hardware timer module used in some ColdFire CPU's is not always addressed relative to an IPSBAR register. Parts like the ColdFire 5207 and 5208 have fixed peripheral addresses. So lets not define the register addresses of the PIT relative to an IPSBAR definition. Move the base address definitions into the per-part headers. This is a lot more consistent since all the other peripheral base addresses are defined in the per-part header files already. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove bogus definition of MBAR for ColdFire 532x familyGreg Ungerer2011-03-151-3/+0
| | | | | | | | | | | | | | | | | | | | | | Remove the bogus definition of the MBAR register for the ColdFire 532x family. It doesn't have an MBAR register, its peripheral registers are at fixed addresses and are not relative to a settable base. All the code that relyed on this definition existing has been cleaned up. The register address definitions now include the base as required. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: remove kludge seting of MCF_IPSBAR for ColdFire 54xxGreg Ungerer2011-03-155-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ColdFire 54xx family shares the same interrupt controller used on the 523x, 527x and 528x ColdFire parts, but it isn't offset relative to the IPSBAR register. The 54xx doesn't have an IPSBAR register. By including the base address of the peripheral registers in the register definitions (MCFICM_INTC0 and MCFICM_INTC1 in this case) we can avoid having to define a fake IPSBAR for the 54xx. And this makes the register address definitions of these more consistent, the majority of the other register address defines include the peripheral base address already. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | m68knommu: move ColdFire 5249 MBAR2 definitionGreg Ungerer2011-03-152-1/+5
|/ | | | | | | The MBAR2 register is only used on the ColdFire 5249 part, so move its definition out of the common coldfire.h and into the 5249 support header. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: add optimize memmove() functionGreg Ungerer2011-02-161-1/+1
| | | | | | | | | | | | | | | Add an m68k/coldfire optimized memmove() function for the m68knommu arch. This is the same function as used by m68k. Simple speed tests show this is faster once buffers are larger than 4 bytes, and significantly faster on much larger buffers (4 times faster above about 100 bytes). This also goes part of the way to fixing a regression caused by commit ea61bc461d09e8d331a307916530aaae808c72a2 ("m68k/m68knommu: merge MMU and non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is the 68x328 and 68360 families). They currently have no memmove() fucntion defined, since there was none in the m68knommu/lib functions. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68k: remove arch specific non-optimized memcmp()Greg Ungerer2011-02-161-3/+1
| | | | | | | | | | | | | | | The m68k arch implements its own memcmp() function. It is not optimized in any way (it is the most strait forward coding of memcmp you can get). Remove it and use the kernels standard memcmp() implementation. This also goes part of the way to fixing a regression caused by commit ea61bc461d09e8d331a307916530aaae808c72a2 ("m68k/m68knommu: merge MMU and non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is the 68x328 and 68360 families). They currently have no memcmp() function defined, since there is none in the m68knommu/lib functions. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68k/atari: Rename "scc" to "atari_scc"Geert Uytterhoeven2011-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a way too generic name for a global #define and conflicts with a variable with the same name, causing build errors like: | drivers/staging/brcm80211/brcmfmac/../util/siutils.c: In function ‘_si_clkctl_cc’: | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected identifier or ‘(’ before ‘volatile’ | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected ‘)’ before ‘(’ token | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1421: error: incompatible types in assignment | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1422: error: invalid operands to binary & | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1423: error: invalid operands to binary & | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1424: error: invalid operands to binary | | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: incompatible type for argument 4 of ‘bcmsdh_reg_write’ | drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1428: error: invalid operands to binary & | make[8]: *** [drivers/staging/brcm80211/brcmfmac/../util/siutils.o] Error 1 Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68k: Uninline strchr()Geert Uytterhoeven2011-01-221-12/+0
| | | | | | | | | | | | | | | | | | | Some versions of gcc replace calls to strstr() with single-character "needle" string parameters by calls to strchr() behind our back. If strchr() is defined as an inline function, this causes linking errors like ERROR: "strchr" [drivers/target/target_core_mod.ko] undefined! As m68k is the only architecture that has an inline strchr() and this inline version is not an optimized asm version, uninline strchr() and use the standard out-of-line C version in lib/string.c instead. This also decreases the defconfig/allmodconfig kernel image sizes by a few hundred bytes. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
* Merge branch 'for-linus' of ↵Linus Torvalds2011-01-1824-380/+515
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: (25 commits) m68knommu: fix broken setting of irq_chip and handler m68knommu: switch to using -mcpu= flags for ColdFire targets m68knommu: arch/m68knommu/Kconfig whitespace cleanup m68knommu: create optimal separate instruction and data cache for ColdFire m68knommu: support ColdFire caches that do copyback and write-through m68knommu: support version 2 ColdFire split cache m68knommu: make cache push code ColdFire generic m68knommu: clean up ColdFire cache control code m68knommu: move inclusion of ColdFire v4 cache registers m68knommu: merge bit definitions for version 3 ColdFire cache controller m68knommu: create bit definitions for the version 2 ColdFire cache controller m68knommu: remove empty __iounmap() it is no used m68knommu: remove kernel_map() code, it is not used m68knommu: remove do_page_fault(), it is not used m68knommu: use user stack pointer hardware on some ColdFire cores m68knommu: remove command line printing DEBUG m68knommu: remove fasthandler interrupt code m68knommu: move UART addressing to part specific includes m68knommu: fix clock rate value reported for ColdFire 54xx parts m68knommu: move ColdFire CPU names into their headers ...
| * m68knommu: create optimal separate instruction and data cache for ColdFireGreg Ungerer2011-01-054-20/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | Create separate functions to deal with instruction and data cache flushing. This way we can optimize them for the vairous cache types and arrangements used across the ColdFire family. For example the unified caches in the version 3 cores means we don't need to flush the instruction cache. For the version 2 cores that do not do data cacheing (or where we choose instruction cache only) we don't need to do any data flushing. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: support ColdFire caches that do copyback and write-throughGreg Ungerer2011-01-052-1/+11
| | | | | | | | | | | | | | | | The version 3 and version 4 ColdFire cache controllers support both write-through and copy-back modes on the data cache. Allow for Kconfig time configuration of this, and set the cache mode appropriately. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: support version 2 ColdFire split cacheGreg Ungerer2011-01-051-14/+16
| | | | | | | | | | | | | | | | | | | | The newer version 2 ColdFire CPU cores support a configurable cache arrangement. The cache memory can be used as all instruction cache, all data cache, or split in half for both instruction and data caching. Support this setup via a Kconfig time menu that allows a kernel builder to choose the arrangement they want to use. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: make cache push code ColdFire genericGreg Ungerer2011-01-052-38/+7
| | | | | | | | | | | | | | | | | | | | | | | | Currently the code to push cache lines is only available to version 4 cores. Version 3 cores may also need to use this if we support copy- back caches on them. Move this code to make it more generic, and useful for all version ColdFire cores. With this in place we can now have a single cache_flush_all() code path that does all the right things on all version cores. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: clean up ColdFire cache control codeGreg Ungerer2011-01-055-187/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cache control code for the ColdFire CPU's is a big ugly mess of "#ifdef"ery liberally coated with bit constants. Clean it up. The cache controllers in the various ColdFire parts are actually quite similar. Just differing in some bit flags and options supported. Using the header defines now in place it is pretty easy to factor out the small differences and use common setup and flush/invalidate code. I have preserved the cache setups as they where in the old code (except where obviously wrong - like in the case of the 5249). Following from this it should be easy now to extend the possible setups used on the CACHE controllers that support split cacheing or copy-back or write through options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: move inclusion of ColdFire v4 cache registersGreg Ungerer2011-01-054-5/+5
| | | | | | | | | | | | | | | | | | Move the inclusion of the version 4 cache controller registers so that it is with all the other register bit flag definitions. This makes it consistent with the other version core inclusion points, and means we don't need "#ifdef"ery in odd-ball places for these definitions. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: merge bit definitions for version 3 ColdFire cache controllerGreg Ungerer2011-01-053-54/+56
| | | | | | | | | | | | | | | | | | All version 3 based ColdFire CPU cores have a similar cache controller. Merge all the exitsing definitions into a single file, and make them similar in style and naming to the existing version 2 and version 4 cache controller definitions. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: create bit definitions for the version 2 ColdFire cache controllerGreg Ungerer2011-01-058-0/+72
| | | | | | | | | | | | | | | | The version 2 ColdFire CPU based cores all contain a similar cache controller unit. Create a set of bit flag definitions for the supporting registers. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: remove empty __iounmap() it is no usedGreg Ungerer2011-01-051-1/+0
| | | | | | | | | | | | The empty __iounmap() function is not used on m68knommu at all. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: use user stack pointer hardware on some ColdFire coresGreg Ungerer2011-01-055-35/+52
| | | | | | | | | | | | | | | | | | The more modern ColdFire parts (even if based on older version cores) have separate user and supervisor stack pointers (a7 register). Modify the ColdFire CPU setup and exception code to enable and use this on parts that have it. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: move UART addressing to part specific includesGreg Ungerer2011-01-0512-45/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | The ColdFire UART base addresses varies between the different ColdFire family members. Instead of keeping the base addresses with the UART definitions keep them with the other addresses definitions for each ColdFire part. The motivation for this move is so that when we add new ColdFire part definitions, they are all in a single file (and we shouldn't normally need to modify the UART definitions in mcfuart.h at all). Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: fix clock rate value reported for ColdFire 54xx partsGreg Ungerer2011-01-0511-12/+23
| | | | | | | | | | | | | | | | | | | | | | The instruction timings of the ColdFire 54xx family parts are different to other version 4 parts (or version 2 or 3 parts for that matter too). Move the instruction timing setting into the ColdFire part specific headers, and set the 54xx value appropriately. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: move ColdFire CPU names into their headersGreg Ungerer2011-01-0511-0/+19
| | | | | | | | | | | | | | | | | | | | Move the ColdFire CPU names out of setup.c and into their repsective headers. That way when we add new ones we won't need to modify setup.c any more. Add the missing 548x CPU name. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: make Coldfire 548x support more genericGreg Ungerer2011-01-059-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | The ColdFire 547x family of processors is very similar to the ColdFire 548x series. Almost all of the support for them is the same. Make the code supporting the 548x more gneric, so it will be capable of supporting both families. For the most part this is a renaming excerise to make the support code more obviously apply to both families. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: Use symbolic constants for cache operations on M54xxPhilippe De Muyter2011-01-053-17/+65
| | | | | | | | | | | | | | | | | | | | | | | | Now that we have meaningfull symbolic constants for bit definitions of the cache registers of m5407 and m548x chips, use them to improve readability, portability and efficiency of the cache operations. This also fixes __flush_cache_all for m548x chips : implicit DCACHE_SIZE was exact for m5407, but wrong for m548x. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: Move __flush_cache_all definition for m54xx in m54xxacr.hPhilippe De Muyter2011-01-052-23/+36
| | | | | | | | | | | | | | | | | | __flush_cache_all for m54xx is intrinsically related to the bit definitions in m54xxacr.h. Move it there from cacheflush_no.h, for easier maintenance. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
| * m68knommu: Create new m54xxacr.h from m5407sim.h subpartPhilippe De Muyter2011-01-052-34/+43
| | | | | | | | | | | | | | | | | | | | | | The MCF548x have the same cache control registers as the MCF5407. Extract the bit definitions for the ACR and CACR registers from m5407sim.h and move them to a new file m54xxacr.h. Those definitions are not used anywhere yet, so no other file is involved. This is a preparation for m54xx cache support cleanup. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* | watchdog: Add MCF548x watchdog driver.Philippe De Muyter2011-01-121-0/+2
| | | | | | | | | | | | | | | | Add watchdog driver for MCF548x. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
OpenPOWER on IntegriCloud