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>
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>
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>
Create a config symbol to enable when using a ColdFire MMU. We then
use that to only compile the necessary arch mm files.
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 different ColdFire V4e MMU requires its own dedicated paging init
code, and a TLB miss handler for its software driven TLB.
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 MMU has separate read and write bits, unlike the Motorola
m68k MMU which has a single read-only bit.
Define a _PAGE_READWRITE value for the Motorola MMU, which is 0, so we
can unconditionaly include that in the page table entry bits when setting
up ioremapped pages.
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>
The cache push and clear code only need to flush the branch cache on
the write-through cache setup of the ColdFire V4e with MMU 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>
The existing ColdFire code (which is all non-mmu) for system call entry
and exit uses the more modern tracehook_report_syscall_entry()/exit()
into the ptrace code. Now that we are supporting ColdFire with MMU we
need the same hooks for these.
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>
Add code to manage the context's of the ColdFire V4e MMU. This code is
mostly taken from the Freescale 2.6.35 kernel BSP for MMU enabled ColdFire.
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>
Like the SUN3 hardware MMU the ColdFire MMU uses 8k pages. So we want
our ELF page size alingment to also be 8k. Modify the ELF alignment
setting.
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 use the ColdFire V4e MMU page size of 8KiB. Define PAGE_SHIFT
appropriately.
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 CPU configurations need PAGE_OFFSET_RAW set to the base of
their RAM. It doesn't matter if they are running with the MMU enabled or
disabled, it is always set to the base of RAM.
We can keep the choices simple here and key of CONFIG_RAMBASE. If it is
defined we are on a plaftorm (ColdFire or other non-MMU systems) which
have a configurable RAM base, just use it.
Reported-by: Alexander Stein <alexander.stein@systec-electronic.com>
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>
The ColdFire V4e MMU is unlike any of the other m68k MMU hardware.
It needs its own TLB flush support 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>
Modify the cache setup for the ColdFire 54xx parts when running with
the MMU enabled.
We want to map the peripheral register space (MBAR region) as non
cacheable. And create an identity mapping for all of RAM for the
kernel.
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>
Add code to deal with instruction, data and branch caches of the V4e
ColdFire cores when they are running with the MMU enabled.
This code is loosely based on Freescales changes for the caches of the
V4e ColdFire in the 2.6.25 kernel BSP. That code was originally by
Kurt Mahan <kmahan@freescale.com> (now <kmahan@xmission.com>).
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>
Add code to traps.c to handle MMU exceptions for the ColdFire.
Most of this code is from the 2.6.25 kernel BSP code released by
Freescale.
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>
Define the page table size and attributes for the ColdFire V4e MMU.
Also setup the vmalloc and kmap regions we will use.
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 V4e MMU is nothing like any of the other m68k MMU's.
So we need to create a set of definitions and support routines
for the kernels paging functions.
This is largely taken from Freescales BSP code for this (though it
was a 2.6.25 kernel). I have cleaned it up alot from the original.
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>
Virtual memory m68k systems build with register a2 dedicated to being the
current proc pointer (non-MMU don't do this). Add code to the ColdFire
interrupt and exception processing to set this on entry, and at context
switch time. We use the same GET_CURRENT() macro that MMU enabled code
uses - modifying it so that the assembler is ColdFire clean.
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>
Add code to the 54xx ColdFire CPU init to setup memory ready for the m68k
paged memory start up.
Some of the RAM variables that were specific to the non-mmu code paths
now need to be used during this setup, so when CONFIG_MMU is enabled.
Move these out of page_no.h and into page.h.
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>
The 54xx ColdFire CPU family has an internal MMU. Up to now though we
have only supported running on them with the MMU disabled.
Add code to the 54xx ColdFire init sequence to initialize the bootmem
used by the usual MMU m68k code for paging init.
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 CPU family, and the original 68000, do not support separate
address spaces like the other 680x0 CPU types. Modify the set_fs()/get_fs()
functions and macros to use a thread_info addr_limit for address space
checking. This is pretty much what all other architectures that do not
support separate setable address spaces do.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
Modify the user space access functions to support the ColdFire V4e cores
running with MMU enabled.
The ColdFire processors do not support the "moves" instruction used by
the traditional 680x0 processors for moving data into and out of another
address space. They only support the notion of a single address space,
and you use the usual "move" instruction to access that.
Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
CPU types that support separate address spaces, and thus also support
the sfc/dfc registers and the "moves" instruction that go along with that.
The code is almost identical for user space access, so lets just use a
define to choose either the "move" or "moves" in the assembler code.
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>
The interrupt handling support defines and code is not so much conditional
on an MMU being present (CONFIG_MMU), as it is on which type of CPU we are
building for. So make the code conditional on the CPU types instead. The
current irq.h is mostly specific to the interrupt code for the 680x0 CPUs,
so it should only be used for them.
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>
Basic register level definitions to support the internal MMU of the
V4e ColdFire cores.
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>
