summaryrefslogtreecommitdiffstats
path: root/arch/m68knommu/platform/527x/config.c
AgeCommit message (Collapse)Author
2011-03-25m68k: merge m68k and m68knommu arch directoriesGreg Ungerer
There is a lot of common code that could be shared between the m68k and m68knommu arch branches. It makes sense to merge the two branches into a single directory structure so that we can more easily share that common code. This is a brute force merge, based on a script from Stephen King <sfking@fdwdc.com>, which was originally written by Arnd Bergmann <arnd@arndb.de>. > The script was inspired by the script Sam Ravnborg used to merge the > includes from m68knommu. For those files common to both arches but > differing in content, the m68k version of the file is renamed to > <file>_mm.<ext> and the m68knommu version of the file is moved into the > corresponding m68k directory and renamed <file>_no.<ext> and a small > wrapper file <file>.<ext> is used to select between the two version. Files > that are common to both but don't differ are removed from the m68knommu > tree and files and directories that are unique to the m68knommu tree are > moved to the m68k tree. Finally, the arch/m68knommu tree is removed. > > To select between the the versions of the files, the wrapper uses > > #ifdef CONFIG_MMU > #include <file>_mm.<ext> > #else > #include <file>_no.<ext> > #endif On top of this file merge I have done a simplistic merge of m68k and m68knommu Kconfig, which primarily attempts to keep existing options and menus in place. Other than a handful of options being moved it produces identical .config outputs on m68k and m68knommu targets I tested it on. With this in place there is now quite a bit of scope for merge cleanups in future patches. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-03-15m68knommu: remove use of MBAR value for ColdFire 527x peripheral addressingGreg Ungerer
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>
2010-05-17m68knommu: Coldfire QSPI platform supportSteven King
Since Grant has added the coldfire-qspi driver to next-spi, here is the platform support for the parts that have qspi hardware. This sets up gpio to do the spi chip select using the default chip select pins; it should be trivial for boards that require different or additional spi chip selects to use other gpios as needed. Signed-off-by: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-09-16m68knommu: clean up ColdFire 527x interrupt setupGreg Ungerer
With the common intc-2 interrupt controller code in place the ColdFire 527x family startup code can be greatly simplified. Remove all the interrupt masking code, and the per-device interrupt config here. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-06-11m68knommu: move CPU reset code for the 527x ColdFire into its platform codeGreg Ungerer
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-04-22m68knommu: Fixed GPIO pin initialization for CONFIG_M5271 FEC.Richard Retanubun
This processor only have one FEC and its MDIO pins are located at a different offset than the code used for the current CONFIG_M527x. Tesed on M5271EVB eval platform. Without this patch the FEC driver will report no PHY attached if the bootloader does not pre-initialize the PAR_FECI2C GPIO register. Signed-off-by: Richard Retanubun <RichardRetanubun@RuggedCom.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-02-26fec: add FEC platform support to ColdFire CPU's setup codeGreg Ungerer
m68knommu: add FEC platform support to ColdFire CPU's setup code Move the per-CPU FEC driver setup code into the actual platform setup code for each ColdFire CPU varient. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-01m68knommu: platform setup for 527x ColdFire partsGreg Ungerer
Switch to platform style configuration for 527x ColdFire parts. Initial support is for the UARTs. DMA support moved to common code for all ColdFire parts. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-23m68knommu: cleanup m68knommu timer codeGreg Ungerer
Reduce the function pointer mess of the m68knommu timer code by calling directly to the local hardware's timer setup, and expose the local common timer interrupt handler to the lower level hardware timer. Ultimately this will save definitions of all these functions across all the platform code to setup the function pointers (which for any given m68knommu CPU family member can be only one set of hardware timer functions). Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-26m68knommu: remove use of colfire_trap_initGreg Ungerer
The switch to using the generic irq framework removed the coldfire_trap_init() code, so remove all references to it. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-25m68knommu: make BOOTPARAM setup commonGreg Ungerer
Currently most of the m68knommu cpu/board setup files are handling the setup of fixed boot parameters (via CONFIG_BOOTPARAM) themselves. Move all this into the common setup code. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-09[PATCH] m68knommu: use irq_handler_t for passing handler typesGreg Ungerer
Use irq_handler_t for passing clock handler routine around. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!