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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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
ea61bc46 ("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: NGreg Ungerer <gerg@uclinux.org>

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
ea61bc46 ("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: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

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: NGeert Uytterhoeven <geert@linux-m68k.org>

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: NGeert Uytterhoeven <geert@linux-m68k.org>

Add watchdog driver for MCF548x.
Signed-off-by: NPhilippe De Muyter <phdm@macqel.be>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

and saner do_signal() arguments, while we are at it
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Since commit 31c91132 ("mm: check the argument
of kunmap on architectures without highmem"), we get lots of warnings like

arch/m68k/kernel/sys_m68k.c:508: warning: passing argument 1 of ‘kunmap’ from incompatible pointer type

As m68k doesn't support highmem anyway, open code the calls to kmap() and
kunmap() (the latter is a no-op) to kill the warnings, like is done on most
other architectures without CONFIG_HIGHPTE.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Sam Creasey <sammy@sammy.net>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

The empty __iounmap() function is not used on m68knommu at all.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NGreg Ungerer <gerg@uclinux.org>

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: NPhilippe De Muyter <phdm@macqel.be>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

__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: NPhilippe De Muyter <phdm@macqel.be>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>