Make all definitions of the ColdFire Interrupt Mask and Pending registers
absolute addresses. Currently some are relative to the MBAR peripheral region.

The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are relative to peripheral regions
which can be mapped at different address ranges (such as the MBAR and IPSBAR
registers). We don't want to deal with this in the code when we are
accessing these registers, so make all register definitions the absolute
address - factoring out whether it is an offset into a peripheral region.

This makes them all consistently defined, and reduces the occasional bugs
caused by inconsistent definition of the register addresses.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

DRAGEN2 should obviously be CONFIG_DRAGEN2, but the screen.h entry it
triggers only references files that are nowhere to be found in the
current tree. Besides, nothing uses screen.h. So just drop all that.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The managed clk functions are currently only available when the generic clk
lookup framework is build. But the managed clk functions are merely wrappers
around clk_get and clk_put and do not depend on any specifics of the generic
lookup functions and there are still quite a few custom implementations of the
clk API. So make the managed functions available whenever the clk API is
implemented.

The patch also removes the custom implementation of devm_clk_get for the
coldfire platform.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The ColdFire M54xx SoC family have a traditional PCI bus interface.
Add the core support code to access and use this bus on these parts.
This code provides all the config space access functions and IO access
functions. It also carries out the PCI bus initialization and hooks into
the kernel PCI subsystem.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Quite a few of Freescale's older ColdFire development boards used an NS8390
based ethernet interface. Add a platform definition for the resources used
by these devices so we can use it on these boards.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The 532x has individually controllable clocks for it peripherals.  Add clk
definitions for these and add default initialization of either enabled or
disabled.
Signed-off-by: NSteven King <sfking@fdwdc.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The 520x has individually controllable clocks for its peripherals.  Add clk
definitions for these and add default initialization of either enabled or
disabled for all of the clocks.
Signed-off-by: NSteven King <sfking@fdwdc.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Add definitions for the m5441x rtc device and an init_BSP function to the
m5441x device code.
Signed-off-by: NSteven King <sfking@fdwdc.com>

Add support for the Coldfire 5441x (54410/54415/54416/54417/54418).  Currently
we only support noMMU mode.  It requires the PIT patch posted previously as it
uses the PIT instead of the dma timer as a clock source so we can get all that
GENERIC_CLOCKEVENTS goodness.  It also adds some simple clk definitions and
very simple minded power management.  The gpio code is tweeked and some
additional devices are added to devices.c.  The Makefile uses -mv4e as
apparently, the only difference a v4m (m5441x) and a v4e is the later has a
FPU, which I don't think should matter to us in the kernel.
Signed-off-by: NSteven King <sfking@fdwdc.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

use MCF_IRQ_PIT1 instead of MCFINT_VECBASE + MCFINT_PIT1 so we can support
those parts that have the pit1 interrupt on other than the first interrupt
controller.
Signed-off-by: NSteven King <sfking@fdwdc.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Basic support for the Coldfire 5251/5253.
Signed-off-by: NSteven king <sfking@fdwdc.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we're not connecting external GPIO extenders via i2c or spi or whatever, we
probably don't need GPIOLIB.  If we provide an alternate implementation of
the GPIOLIB functions to use when only on-chip GPIO is needed, we can change
ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB so that GPIOLIB becomes
optional.

The downside is that in the GPIOLIB=n case, we lose all error checking done by
gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so that the
only checking that can be done is if we reference a gpio on an external part.
Targets that need the extra error checking can still select GPIOLIB=y.

For the case where GPIOLIB=y, we can simplify the table of gpio chips to use a
single chip, eliminating the tables of chips in the 5xxx.c files.  The
original motivation for the definition of multiple chips was to match the way
many of the Coldfire variants defined their gpio as a spare array in memory.
However, all this really gains us is some error checking when we request a
gpio, gpiolib can check that it doesn't fall in one of the holes.  If thats
important, I think we can still come up with a better way of accomplishing
that.

Also in this patch is some general cleanup and reorganizing of the gpio header
files (I'm sure I must have had a reason why I sometimes used a prefix of
mcf_gpio and other times mcfgpio but for the life of me I can't think of it
now).
Signed-off-by: NSteven King <sfking@fdwdc.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

BSS_SECTION() provides the __bss_{start,stop} symbols, so there's no need
to wrap our own _[se]bss around it.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer<gerg@uclinux.org>

Commit f4d40de3 ("net fec: do not depend
on grouped clocks") breaks compilation of the FEC driver for non iMX
platforms in linux-3.5-rc1. For example when compiling for ColdFire I get:

      LD      vmlinux
    drivers/built-in.o: In function `fec_probe':
    fec.c:(.devinit.text+0x1e0): undefined reference to `devm_clk_get'

Define a simple devm_clk_get() function for the m68knommu architecture.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Compiling for 68360 based targets fails with:

    arch/m68k/platform/68360/config.c: In function ‘hw_tick’:
    arch/m68k/platform/68360/config.c:55:2: error: implicit declaration of function ‘arch_timer_interrupt’
    arch/m68k/platform/68360/config.c: At top level:
    arch/m68k/platform/68360/config.c:64:6: error: conflicting types for ‘hw_timer_init’
    arch/m68k/include/asm/machdep.h:36:13: note: previous declaration of ‘hw_timer_init’ was here

Changes made to hw_timer_init() didn't get updated in the 68328 timer code.
So process and call the "handler" arg that is now passed into that
hw_timer_init() function.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Compiling for 68328 based targets fails with:

    arch/m68k/platform/68328/timers.c: In function ‘hw_tick’:
    arch/m68k/platform/68328/timers.c:65:2: error: implicit declaration of function ‘arch_timer_interrupt’
    arch/m68k/platform/68328/timers.c: At top level:
    arch/m68k/platform/68328/timers.c:102:6: error: conflicting types for ‘hw_timer_init’
    arch/m68k/include/asm/machdep.h:36:13: note: previous declaration of ‘hw_timer_init’ was here

Changes made to hw_timer_init() didn't get updated in the 68328 timer code.
So process and call the "handler" arg that is now passed into that
hw_timer_init() function.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

TIF_NOTIFY_RESUME added (as bit 5).  That way nommu glue needs no changes at
all; mmu one needs just to replace jmi do_signal_return to jne do_signal_return
There we have flags shifted up, until bit 6 (SIGPENDING) is in MSBit; instead
of checking that MSBit is set (jmi) we check that MSBit or something below it
is set (jne); bits 0..4 are never set, so that's precisely "bit 6 or bit 5 is
set".

Usual handling of NOTIFY_RESUME/SIGPENDING is done in do_notify_resume(); glue
calls it instead of do_signal().
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The GPIO data struct setup is now the only remaining code in the platform
gpio.c file. So move it to the platform config.c code and remove the gpio.c
file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

The code that adds each ColdFire platforms GPIO signals is duplicated in
each platforms specific code. Remove it from each platforms code and put
a single version in the existing ColdFire gpio subsystem init code.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>

Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NSteven King <sfking@fdwdc.com>