aboutsummaryrefslogtreecommitdiff
path: root/arch/sh/kernel/cf-enabler.c
AgeCommit message (Collapse)Author
2008-12-22sh: Kill off cf-enabler with extreme prejudice.Paul Mundt
Now that the rest of the boards that were using cf-enabler "generically" have switched to setting up their mappings on their own, only the mach-se boards were left using it. All of the cf-enabler using mach-se boards use a special initialization of the MRSHPC windows rather than going through the special PTE as other SH-4 platforms do. This consolidates the MRSHPC setup logic, hooks it up on the boards that care, and gets rid of any and all remaining references to cf-enabler. This has been long overdue, as cf-enabler has been the bane of arch/sh/kernel for the last 7 years. Good riddance. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-07-29sh: Move out the solution engine headers to arch/sh/include/mach-se/Paul Mundt
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-07-28sh/kernel/ cleanupsAdrian Bunk
This patch contains the following cleanups: - make the following needlessly global code static: - cf-enabler.c: cf_init() - cpu/clock.c: __clk_enable() - cpu/clock.c: __clk_disable() - process_32.c: default_idle() - time_32.c: struct clocksource_sh - timers/timer-tmu.c: struct tmu_timer_ops - remove the following unused functions (no CONFIG_BLK_DEV_FD on sh): - process_{32,64}.c: disable_hlt() - process_{32,64}.c: enable_hlt() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2008-04-18sh: Add support for Solution Engine SH7721 boardYoshihiro Shimoda
Add support for Solution Engine SH7721 board(MS7721RP01). Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-06-08sh: Rip out special unknown machvec.Paul Mundt
This kills off the BareCPU board as a "special" machvec, rather, we leave this as a default for when no other vector is available, or when we want to use it in combination with other vectors for testing with generic ops. As sh_mv is copied out anyways (or overloaded when an alternate vector is explicitly selected), this doesn't consume any additional memory. The generic machvec can be forcibly selected with sh_mv=generic, or by not having any other boards enabled. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-05-31sh: trivial build cleanups.Evgeniy Polyakov
Several errors were spotted during building for custom config (SMP included). Although SMP still does not compile (no ipi and __smp_call_function) and does not work, this looks a bit cleaner. Some other errors obtained via gcc-4.1.0 build. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-05-21spelling fixes: arch/sh/Simon Arlott
Spelling fixes in arch/sh/. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-05-07sh: Solution Engine 7722 board support.Ryusuke Sakato
This adds more full-featured support for the SH7722 Solution Engine. Previously this was using the generic board, and lacked most of the peripheral support. Signed-off-by: Ryusuke Sakato <sakato.ryusuke@renesas.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-09-27sh: Board updates for I/O routine rework.Paul Mundt
This updates the various boards for some of the recent I/O routine updates. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-09-27sh: ioremap() overhaul.Paul Mundt
ioremap() overhaul. Add support for transparent PMB mapping, get rid of p3_ioremap(), etc. Also drop ioremap() and iounmap() routines from the machvec, as everyone can use the generic ioremap() API instead. For PCI memory apertures and other special cases, use the pci_iomap() API, as boards are already required to get the mapping right there. Signed-off-by: Paul Mundt <lethal@linux-sh.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-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!