Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
And adds local header file, common.h in arch/arm/mach-s3c2410/ and
arch/arm/mach-s3c2440/ directories.
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
S3C2412/S3C2416/S3C2443 use a special register to signal the reset to
the processor and used therefore the s3c24xx_reset_hook mechanism in the
s3c24xx-specific arch reset.
This patch introduces restart functions for these architectures,
moves the board files to them and removes the s3c24xx_reset_hook
infrastructure, as all users are gone.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Reviewed-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather than
using arch_reset().
In addition, convert calls to arm_machine_restart() to orion5x_restart()
to ensure that they continue to work as intended.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather than
using arch_reset().
Acked-by: Nicolas pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the arm_pm_restart hook rather
than using arch_reset().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather than
using arch_reset().
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Krzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
In doing so, we split out the ixdp2351 restart code into its own
platform file.
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
In doing so, we split out the IXDP2401, IXDP2801 and IXDP2805 platform
specific restart code into their own platform files.
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the arm_pm_restart hook rather
than using arch_reset().
In doing so, we split out the n2100 platform specific restart handler
into the n2100 platform file.
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
[kgene.kim@samsung.com: according to local header, updated]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather than
using arch_reset().
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook the EBSA110 platform restart code into the new restart hook rather
than using arch_reset().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather than
using arch_reset().
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rather than using DaVinci specific davinci_soc_info based
restart hook, use the restart hook available in the machine
descriptor instead.
Tested on DM365 and AM18x EVMs.
v2:
Changed to use restart hook in machine descriptor
per Russell's comment.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hook these platforms restart code into the new restart hook rather
than using arch_reset().
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rather than using a private function pointer, use the existing
arm_pm_restart function pointer instead. We no longer need to enable
the I-cache in at91sam9_alt_reset() as the caches will now be on when
this function is called.
Update the function names to use the 'restart' terminology rather than
the 'reboot' terminology.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Remove the s3c24xx restart handler, which is trying to work around
a chip bug by keeping caches on but flushed. As we now only disable
caches when performing a soft reboot, there doesn't need to be a
work-around to do that.
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The Telechips ARM architecture is being removed. This patch
deletes the arch/arm/plat-tcc/ folder.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Harry Sievers <hsievers@csselectronic.com>
Signed-off-by: Hans J. Koch <hjk@hansjkoch.de>
The Telechips ARM architecture is being removed. This patch
deletes the arch/arm/mach-tcc8k/ folder.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Harry Sievers <hsievers@csselectronic.com>
Signed-off-by: Hans J. Koch <hjk@hansjkoch.de>
The Telechips subarchitecture is being completely removed.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Harry Sievers <hsievers@csselectronic.com>
Signed-off-by: Hans J. Koch <hjk@hansjkoch.de>
Fix the following build error:
CC [M] fs/udf/balloc.o
In file included from /home/fabio/next/linux-next/arch/arm/include/asm/prom.h:16,
from include/linux/of.h:140,
from include/asm-generic/gpio.h:7,
from arch/arm/plat-mxc/include/mach/irqs.h:14,
from /home/fabio/next/linux-next/arch/arm/include/asm/irq.h:4,
from /home/fabio/next/linux-next/arch/arm/include/asm/hardirq.h:6,
from include/linux/hardirq.h:7,
from include/linux/highmem.h:8,
from include/linux/pagemap.h:10,
from include/linux/buffer_head.h:13,
from fs/udf/udfdecl.h:11,
from fs/udf/balloc.c:22:
/home/fabio/next/linux-next/arch/arm/include/asm/setup.h:146: error: redefinition of 'struct tag'
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
[grant.likely: fix build failure on drivers/of/fdt.c]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Current linux-next compiled with mpc85xx_defconfig causes this:
arch/powerpc/platforms/85xx/p1010rdb.c:41:14: error: 'np' undeclared (first use in this function)
arch/powerpc/platforms/85xx/p1023_rds.c:102:14: error: 'np' undeclared (first use in this function)
Introduced in:
commit 996983b75c
Author: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Date: Fri Dec 2 06:28:02 2011 +0000
powerpc/mpic: Search for open-pic device-tree node if NULL
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Current linux-next compiled with mpc85xx_smp_defconfig causes this:
arch/powerpc/platforms/85xx/p1023_rds.c: In function 'mpc85xx_rds_pic_init':
arch/powerpc/platforms/85xx/p1023_rds.c:102:14: error: 'np' undeclared (first use in this function)
arch/powerpc/platforms/85xx/p1023_rds.c:102:14: note: each undeclared identifier is reported only once for each function it appears in
Introduced in:
commit 996983b75c
Author: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Date: Fri Dec 2 06:28:02 2011 +0000
powerpc/mpic: Search for open-pic device-tree node if NULL
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Add support for vmpic-msi nodes to the fsl_msi driver. The MSI is
virtualized by the hypervisor, so the vmpic-msi does not contain a 'reg'
property. Instead, the driver uses hcalls.
Add support for the "msi-address-64" property to the fsl_pci driver.
The Freescale hypervisor typically puts the virtualized MSIIR register
in the page after the end of DDR, so we extend the DDR ATMU to cover it.
Any other location for MSIIR is not supported, for now.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
rmu needs to be freed before leaving the function in an error case.
A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)
// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
x->f1
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Integrated Flash Controller supports various flashes like NOR, NAND
and other devices using NOR, NAND and GPCM Machine available on it.
IFC supports four chip selects.
Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The Freescale serial port's are pretty much a 16550, however there are
some FSL specific bugs and features. Add a "fsl,ns16550" compatiable
string to allow code to handle those FSL specific issues.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
PCI ranges, localbus reg and localbus chip-select 2 range do not match
the memory map setup by bootloader.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Commit 7c4b2f09 (powerpc: Update mpc85xx/corenet 32-bit defconfigs)
accidentally disabled the ePAPR byte channel driver in the defconfig for
Freescale CoreNet platforms.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Systems which use the fsl_pq_mdio driver need to specify an
address for TBI PHY transactions such that the address does
not conflict with any PHYs on the bus (all transactions to
that address are directed to the onboard TBI PHY). The driver
used to scan for a free address if no address was specified,
however this ran into issues when the PHY Lib was fixed so
that all MDIO transactions were protected by a mutex. As it
is, the code was meant to serve as a transitional tool until
the device trees were all updated to specify the TBI address.
The best fix for the mutex issue was to remove the scanning code,
but it turns out some of the newer SoCs have started to omit
the tbi-phy node when SGMII is not being used. As such, these
devices will now fail unless we add a tbi-phy node to the first
mdio controller.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The commit 883c2cfc8b:
"fix of_flat_dt_is_compatible() to match the full compatible string"
causes silent boot death on the sbc8349 board because it was
just looking for 8349 and not 8349E -- as originally there
were non-E (no SEC/encryption) chips available. Just add the
E to the board detection string since all boards I've seen
were manufactured with the E versions.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
There is an issue on FSL-BookE 64-bit devices (P5020) in which PCIe
devices that are capable of doing 64-bit DMAs (like an Intel e1000) do
not function and crash the kernel if we have >4G of memory in the system.
The reason is that the existing code only sets up one inbound window for
access to system memory across PCIe. That window is limited to a 32-bit
address space. So on systems we'll end up utilizing SWIOTLB for dma
mappings. However SWIOTLB dma ops implement dma_alloc_coherent() as
dma_direct_alloc_coherent(). Thus we can end up with dma addresses that
are not accessible because of the inbound window limitation.
We could possibly set the SWIOTLB alloc_coherent op to
swiotlb_alloc_coherent() however that does not address the issue since
the swiotlb_alloc_coherent() will behave almost identical to
dma_direct_alloc_coherent() since the devices coherent_dma_mask will be
greater than any address allocated by swiotlb_alloc_coherent() and thus
we'll never bounce buffer it into a range that would be dma-able.
The easiest and best solution is to just make it so that a 64-bit
capable device is able to DMA to any internal system address.
We accomplish this by opening up a second inbound window that maps all
of memory above the internal SoC address width so we can set it up to
access all of the internal SoC address space if needed.
We than fixup the dma_ops and dma_offset for PCIe devices with a dma
mask greater than the maximum internal SoC address.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
It appears about all functions in arch/x86/lib/atomic64_cx8_32.S
are wrong in case cmpxchg8b must be restarted, because
LOCK_PREFIX macro defines a label "1" clashing with other local
labels :
1:
some_instructions
LOCK_PREFIX
cmpxchg8b (%ebp)
jne 1b / jumps to beginning of LOCK_PREFIX !
A possible fix is to use a magic label "672" in LOCK_PREFIX asm
definition, similar to the "671" one we defined in
LOCK_PREFIX_HERE.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1325608540.2320.103.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Just like the per-CPU ones they had several
problems/shortcomings:
Only the first memory operand was mentioned in the asm()
operands, and the 2x64-bit version didn't have a memory clobber
while the 2x32-bit one did. The former allowed the compiler to
not recognize the need to re-load the data in case it had it
cached in some register, while the latter was overly
destructive.
The types of the local copies of the old and new values were
incorrect (the types of the pointed-to variables should be used
here, to make sure the respective old/new variable types are
compatible).
The __dummy/__junk variables were pointless, given that local
copies of the inputs already existed (and can hence be used for
discarded outputs).
The 32-bit variant of cmpxchg_double_local() referenced
cmpxchg16b_local().
At once also:
- change the return value type to what it really is: 'bool'
- unify 32- and 64-bit variants
- abstract out the common part of the 'normal' and 'local' variants
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/4F01F12A020000780006A19B@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
both callers of device_get_devnode() are only interested in lower 16bits
and nobody tries to return anything wider than 16bit anyway.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Move invalidate_bdev, block_sync_page into fs/block_dev.c. Export
kill_bdev as well, so brd doesn't have to open code it. Reduce
buffer_head.h requirement accordingly.
Removed a rather large comment from invalidate_bdev, as it looked a bit
obsolete to bother moving. The small comment replacing it says enough.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Seeing that just about every destructor got that INIT_LIST_HEAD() copied into
it, there is no point whatsoever keeping this INIT_LIST_HEAD in inode_init_once();
the cost of taking it into inode_init_always() will be negligible for pipes
and sockets and negative for everything else. Not to mention the removal of
boilerplate code from ->destroy_inode() instances...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fixes this build error:
arch/arm/mach-sa1100/nanoengine.c:75:11: error: 'PAGE_SHIFT' undeclared here (not in a function)
CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Now that irq_domain_simple_ops are available for non-DT users, use them
in the VIC driver so that we don't get a NULL dereference in
irq_domain_to_irq() when registering the domain.
Cc: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When a request has finished successfully and we are about to call its
callback, remove its pointer from the corresponding pl330_thread .
This prevents the core driver from calling its callback again if
pl330_release_channel() is called without first flushing the device.
When pl330_update() returns, the driver is allowed to free the pointer
to pl330_req so the core driver shouldn't be able to access it again.
Reference: <CAJe_ZhftO+481BfL0ErEcM_brfmSuTXkTEniLRYxxM2T7OM2QA@mail.gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch introduces common.[ch] which are used only in the
arch/arm/mach-exynos/ directory. The common.c file merges
the cpu.c, init.c, irq-combiner.c and irq-eint.c files which
are used commonly on EXYNOS SoCs and the common.h file replaces
with plat/exynos4.h file.
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The 158MiB memory area was used to support HD
resolution multimedia workloads using the same
legacy memory allocating solution as on SH.
There are no in-tree kernel dependencies on the
158MiB setting, and future development should
reserve and allocate memory using some other
method like for instance CMA.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Unpaired calling of probe_hcall_entry and probe_hcall_exit might happen
as following, which could cause incorrect preempt count.
__trace_hcall_entry => trace_hcall_entry -> probe_hcall_entry =>
get_cpu_var => preempt_disable
__trace_hcall_exit => trace_hcall_exit -> probe_hcall_exit =>
put_cpu_var => preempt_enable
where:
A => B and A -> B means A calls B, but
=> means A will call B through function name, and B will definitely be
called.
-> means A will call B through function pointer, so B might not be
called if the function pointer is not set.
So error happens when only one of probe_hcall_entry and probe_hcall_exit
get called during a hcall.
This patch tries to move the preempt count operations from
probe_hcall_entry and probe_hcall_exit to its callers.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
CC: stable@kernel.org [v2.6.32+]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Commit 2a95ea6c0d ("procfs: do not overflow get_{idle,iowait}_time
for nohz") did not take into account that one some architectures jiffies
and cputime use different units.
This causes get_idle_time() to return numbers in the wrong units, making
the idle time fields in /proc/stat wrong.
Instead of converting the usec value returned by
get_cpu_{idle,iowait}_time_us to units of jiffies, use the new function
usecs_to_cputime64 to convert it to the correct unit of cputime64_t.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "Artem S. Tashkinov" <t.artem@mailcity.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The ColdFire 547x and 548x CPUs have internal MMU hardware. All code
to support this is now in, so we can build kernels with it enabled.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
While you can build multiplatform kernels for machines with classic
m68k processors, you cannot mix support for classic m68k and coldfire
processors. To avoid such hybrid kernels, introduce CONFIG_M68KCLASSIC
as an antipole for CONFIG_COLDFIRE, and make all specific processor
support depend on one of them.
All classic m68k machine support also needs to depend on this.
The defaults (CONFIG_M68KCLASSIC if MMU, CONFIG_COLDFIRE if !MMU) are
chosen such to make most of the existing configs build and work.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire has similar setup requirements to the SUN3 code, so we
use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
The ColdFire CPUs have their own startup and interrupt code (in the
platform/coldfire directory), and do not use the general m68k startup and
interrupt code. In fact the use of the arch/m68k/kernel/head.o is not about
CONFIG_MMU or not, it is really about the machine type we are compiling for.
Modify the selection and use of head.o to be based on the machine type.
Only select the local ints.o and vectors.o code if we are using the classic
68k CPU types (that use the conventional Morotola MMU or SUN3 MMU).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
The V4e ColdFire CPU family also has an integrated FPU (as well as the MMU).
So add code to support this hardware along side the existing m68k FPU code.
The ColdFire FPU is of course different to all previous 68k FP units. It is
close in operation to the 68060, but not completely compatible. The biggest
issue to deal with is that the ColdFire FPU multi-move instructions are
different. It does not support multi-moving the FP control registers, and
the multi-move of the FP data registers uses a different instruction
mnemonic.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
The exception return stack adjustment required by ColdFire when running
with the MMU enabled is not completely identical to 680x0 processors.
Specifically the format type 4 stack frame doesn't need any stack
adjustment on exception return. And the ColdFire always must return with
a frame type of 4, not 0.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
Use the non-MMU linker script for ColdFire builds when we are building
for MMU enabled. The image layout is correct for loading on existing
ColdFire dev boards. The only addition required to the current non-MMU
linker script is to add support for the fixup section.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
We want to use the same timer support code for ColdFire CPU's when
running with MMU enabled or not. So use the same time_no.c code even
when the MMU is enabled for ColdFire. This also means we do not want
CONFIG_ARCH_USES_GETTIMEOFFSET set, since that code is only in time_mm.c.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
We use the same setup code for ColdFire MMU enabled platforms as
standard m68k. So add support for it to setup our 54xx ColdFire
platforms. They do not support the same bootinfo parsing as other
m68k platforms.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
No matter whether we are configured for non-MMU or MMU enabled if we are
compiling for ColdFire CPU we always use the entry_no.S code.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
