aboutsummaryrefslogtreecommitdiff
path: root/arch/m68k/platform
AgeCommit message (Collapse)Author
2013-09-09Merge branch 'for-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu Pull m68knommu fixes from Greg Ungerer: "Just a small collection of cleanups and fixes this time, no big changes. The most interresting are to make the m68k and m68knommu consistently use CONFIG_IOMAP, clean out some unused board config options and flush the cache on signal stack creation" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: remove 16 unused boards in Kconfig.machine m68k: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not m68knommu: user generic iomap to support ioread*/iowrite* m68k/coldfire: flush cache when creating the signal stack frame m68knommu: Mark functions only called from setup_arch() __init
2013-08-26m68knommu: Mark functions only called from setup_arch() __initGeert Uytterhoeven
Some functions that are only called (indirectly) from setup_arch() lack __init annotations. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2013-07-25PCI: Delay enabling bridges until they're neededYinghai Lu
We currently enable PCI bridges after scanning a bus and assigning resources. This is often done in arch code. This patch changes this so we don't enable a bridge until necessary, i.e., until we enable a PCI device behind the bridge. We do this in the generic pci_enable_device() path, so this also removes the arch-specific code to enable bridges. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-06-14m68k/PCI: Remove redundant call of pci_bus_add_devices()Jiang Liu
pci_scan_bus() has called pci_bus_add_devices() already, so remove the redundant call of pci_bus_add_devices(). subsys_init() callbacks will be invoked before device_init() callbacks, so it should be safe to remove the redundant calls. [bhelgaas: split unicore32 into a separate patch] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Ungerer <gerg@uclinux.org>
2013-04-29m68knommu: enable Timer on coldfire 532xGreg Ungerer
This patch enables the initial Timer on coldfire 532x systems. Without this, the scheduler will not be triggered and the system hangs, after all sequential code is executed. It should also apply on later kernel versions. Signed-off-by: Christian Gieseler <christiangieseler@yahoo.de> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2013-04-29m68knommu: make ColdFire M532x platform support more v3 genericGreg Ungerer
The M532x CPU platform support can be used on more ColdFire CPU families than just the 532x types. So rename and reconfigure it to reflect that. The ColdFire 537x family has virtualy identical internals to the 532x, and so it will be able to share this code when we add support for them. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2013-04-29m68knommu: create and use a common M53xx ColdFire class of CPUsGreg Ungerer
The current CONFIG_M532x support definitions are actually common to a larger set of version 3 ColdFire CPU types. In the future we want to add support for the 537x family. It is very similar to the 532x internally, and will be able to use most of the same definitions. Create a CONFIG_M53xx option that is enabled to support any of the common 532x and 537x CPU types. Convert the current users of CONFIG_M532x to use CONFIG_M53xx instead. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2013-03-04m68knommu: fix misnamed GPIO pin definition for ColdFire 528x CPUGreg Ungerer
Compiling for a ColdFire 528x CPU will result in: arch/m68k/platform/coldfire/m528x.c: In function ‘m528x_uarts_init’: arch/m68k/platform/coldfire/m528x.c:72: error: ‘MCF5282_GPIO_PUAPAR’ undeclared (first use in this function) arch/m68k/platform/coldfire/m528x.c:72: error: (Each undeclared identifier is reported only once arch/m68k/platform/coldfire/m528x.c:72: error: for each function it appears in.) The MCF5282_GPIO_PUAPAR definition changed names in the ColdFire definitions cleanup. It is now MCFGPIO_PUAPAR, so change it. Not sure how this one got missed, 2 lines below it is the correct use of this definition. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: modify clock code so it can be used by all ColdFire CPU typesGreg Ungerer
The existing clk.c code for ColdFire CPUs has one set of functions to support those CPU types that have selectable clocks (those with a PPMCR register), and a duplicate simpler set for those with static clocks. Modify the clk.c code so there is just one set of support functions. All CPU types now define a list of clocks (in "struct clk"s), so we only need a single set of clock functions. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 54xx ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 54xx ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 5407 ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 5407 ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 5307 ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 5307 ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 528x ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 528x ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 527x ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 527x ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 5272 ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 5272 ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 525x ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 525x ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 5249 ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 5249 ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 523x ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 523x ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: add clock definitions for 5206 ColdFire CPU typesGreg Ungerer
Add a base set of clocks for the 5206 ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: merge ColdFire 5249 and 525x definitionsGreg Ungerer
The ColdFire 5249 and 525x family of SoCs are very similar. Most of the internals are the same, and are mapped the same. We can use a single set of peripheral definitions for all of them. So merge the current m5249sim.h and m525xsim.h definitions into a single file. The 5249 is now obsolete, and the 525x parts are current, so I have chosen to move everything into the existing m525xsim.h file. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05m68knommu: platform code merge for 68000 core cpusLuis Alves
This patch merges all 68000 core cpus into one directory. There is a lot of common code in the 68328, 68EZ328 and 68VZ328 directories. This will also facilitate easy development of support for original stand alone MC68000 CPU machines. Signed-off-by: Luis Alves <ljalvs@gmail.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: clean up ColdFire 54xx General Timer definitionsGreg Ungerer
Convert the ColdFire 54xx CPU General Timer register address definitions to include the MCF_MBAR peripheral region offset. This makes them consistent with all other 54xx address register definitions (in m54xxsim.h). The goal is to reduce different definitions used (some including offsets and others not) causing bugs when used incorrectly. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: clean up Pin Assignment definitions for the 54xx ColdFire CPUGreg Ungerer
The Pin Assignment register definitions for the ColdFire 54xx CPU family are inconsistently named and defined compared to the other ColdFire part definitions. Rename them with the same prefix as used on other parts, MCFGPIO_PAR_, and make their definitions include the MCF_MBAR periphperal region offset. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: fix multi-function pin setup for FEC module on ColdFire 523xGreg Ungerer
The multi-function pin setup code for the FEC ethernet module is using just plain wrong. Looks like it was cut-and-pasted from other init code. It has hard coded register addresses that are incorrect for the 523x, and it is manipulating bits that don't make sense. Add proper register definitions for the Pin Assignment registers of the 532x, and then use them to fix the setup code for the FEC hardware module. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: move ColdFire slice timer address defiens to 54xx headerGreg Ungerer
Move the base address defines of the ColdFire 54xx CPU slice timers into the 54xx specific header (m54xxsim.h). They are CPU specific, and belong with the CPU specific defines. Also make them relative to the MBAR peripheral region, making the define the absolute address. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: use read/write IO access functions in ColdFire m532x setup codeGreg Ungerer
Get rid of the use of local IO access macros and switch to using the standard read*/write* family of access functions for the ColdFire m532x setup code. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: modify ColdFire 532x GPIO register definitions to be consistentGreg Ungerer
The ColdFire 532x CPU register definitions for the multi-function setup pins are inconsistently defined compared with other ColdFire parts. Modify the register defintions to be just the addresses, not pointers. This also fixes the erroneous use in one case of using these values in the UART setup code for the 532x. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: use definitions for the ColdFire 528x FEC multi-function pinsGreg Ungerer
Currently the setup code for the FEC multi-function pins on the ColdFire 528x has the addresses hard coded in the code. Use the register defines that already exist for this. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: remove address offsets relative to IPSBAR for ColdFire 527xGreg Ungerer
Remove the last address definitions relative to the IPSBAR peripheral region for the ColdFire 527x family. This involved cleaning up some magic numbers used in the code part, and making them proper register definitions in the 527x specific header. This is part of the process of cleaning up the ColdFire register definitions to make them consistently use absolute addresses for the primary registers. This will reduce the occasional bugs caused by inconsistent definition of the register addresses. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: fix wrong register offsets used for ColdFire 5272 multi-function pinsGreg Ungerer
The registers used to configure and set the multifunction pins on the 5272 ColdFire are defined as absolute addresses. So the use of them does not need to be offset relative to the peripheral region address. Fix two cases of incorrect usage of these addresses. Both affect UART initialization, one in the common UART pin setup code, the other in the NETtel board specific UART signal handling. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make ColdFire 5249 MBAR2 register definitions absolute addressesGreg Ungerer
Make the ColdFire 5249 MBAR peripheral register definitions absolute addresses, instead of offsets into the 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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make remaining ColdFire 5272 register definitions absolute addressesGreg Ungerer
Make the remaining definitions of the 5272 ColdFire 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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make ColdFire Chip Select register definitions absolute addressesGreg Ungerer
Make all definitions of the ColdFire Chip Select 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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make ColdFire Interrupt Source register definitions absolute ↵Greg Ungerer
addresses Make all definitions of the ColdFire Interrupt Source 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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make ColdFire watchdog register definitions absolute addressesGreg Ungerer
Make all definitions of the ColdFire Software watchdog 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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make ColdFire SYPCR and RSR register definitions absolute addressesGreg Ungerer
Make all definitions of the ColdFire Reset and System 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 abolsute 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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68knommu: make ColdFire IMR and IPR register definitions absolute addressesGreg Ungerer
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: Greg Ungerer <gerg@uclinux.org>
2012-09-27m68k: drop unused parts of 68VZ328 MakefilePaul Bolle
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: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-09-15ARM: 7534/1: clk: Make the managed clk functions generically availableLars-Peter Clausen
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: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-03Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k updates from Geert Uytterhoeven. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k: Make sys_atomic_cmpxchg_32 work on classic m68k m68k/apollo: Rename "timer" to "apollo_timer" zorro: Remove unused zorro_bus.devices m68k: Remove never used asm/shm.h m68k/sun3: Remove unselectable code in prom_init() m68k: Use asm-generic version of <asm/sections.h> m68k: Replace m68k-specific _[se]bss by generic __bss_{start,stop} mtd/uclinux: Use generic __bss_stop instead of _ebss m68knommu: Allow ColdFire CPUs to use unaligned accesses m68k: Remove five unused headers m68k: CPU32 does not support unaligned accesses m68k: Introduce config option CPU_HAS_NO_UNALIGNED m68k: delay, muldi3 - Use CONFIG_CPU_HAS_NO_MULDIV64 m68k: Move CPU_HAS_* config options m68k: Remove duplicate FPU config option m68knommu: Clean up printing of sections m68k: Use asm-generic version of <asm/types.h> m68k: Use Kbuild logic to import asm-generic headers
2012-07-17m68k: add PCI bus code support for the ColdFire M54xx SoC familyGreg Ungerer
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: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: platform support for 8390 based ethernet used on some boardsGreg Ungerer
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: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: Add clk definitions for m532x.Steven King
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: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: Add clk definitions for m520x.Steven King
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: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: Add rtc device for m5441x.Steven King
Add definitions for the m5441x rtc device and an init_BSP function to the m5441x device code. Signed-off-by: Steven King <sfking@fdwdc.com>
2012-07-16m68knommu: Add support for the Coldfire m5441x.Steven King
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: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: use MCF_IRQ_PIT1 instead of MCFINT_VECBASE + MCFINT_PIT1Steven King
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: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: Add support for the Coldfire 5251/5253Steven King
Basic support for the Coldfire 5251/5253. Signed-off-by: Steven king <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate ↵Steven King
mcf_gpio_chips. 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: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-06-27m68k: Replace m68k-specific _[se]bss by generic __bss_{start,stop}Geert Uytterhoeven
BSS_SECTION() provides the __bss_{start,stop} symbols, so there's no need to wrap our own _[se]bss around it. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer<gerg@uclinux.org>