aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mm/Makefile
Commit message (Collapse)AuthorAge
* Merge branch 'for-rmk/hugepages' of ↵Russell King2013-06-18
|\ | | | | | | | | | | | | | | | | | | git://git.linaro.org/people/stevecapper/linux into devel-stable These changes bring both HugeTLB support and Transparent HugePage (THP) support to ARM. Only long descriptors (LPAE) are supported in this series. The code has been tested on an Arndale board (Exynos 5250).
| * ARM: mm: HugeTLB support for LPAE systems.Catalin Marinas2013-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for hugetlbfs based on the x86 implementation. It allows mapping of 2MB sections (see Documentation/vm/hugetlbpage.txt for usage). The 64K pages configuration is not supported (section size is 512MB in this case). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> [steve.capper@linaro.org: symbolic constants replace numbers in places. Split up into multiple files, to simplify future non-LPAE support, removed huge_pmd_share code, as this is very rarely executed, Added PROT_NONE support]. Signed-off-by: Steve Capper <steve.capper@linaro.org> Reviewed-by: Will Deacon <will.deacon@arm.com>
* | Merge branch 'for-next' of git://git.pengutronix.de/git/ukl/linux into ↵Russell King2013-05-22
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | devel-stable Pull ARM-v7M support from Uwe Kleine-König: "All but the last patch were in next since next-20130418 without issues. The last patch fixes a problem in combination with 8164f7a (ARM: 7680/1: Detect support for SDIV/UDIV from ISAR0 register) which triggers a WARN_ON without an implemented read_cpuid_ext. The branch merges fine into v3.10-rc1 and I'd be happy if you pulled it for 3.11-rc1. The only missing piece to be able to run a Cortex-M3 is the irqchip driver that will go in via Thomas Gleixner and platform specific stuff."
| * ARM: ARMv7-M: Allow the building of new kernel portUwe Kleine-König2013-04-17
| | | | | | | | | | | | | | | | | | | | This patch modifies the required Kconfig and Makefile files to allow the building of kernel for Cortex-M3. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Jonathan Austin <jonathan.austin@arm.com> Tested-by: Jonathan Austin <jonathan.austin@arm.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
* | ARM: cache: remove ARMv3 support codeWill Deacon2013-03-26
|/ | | | | | | | | | | | | This is only used by 740t, which is a v4 core and (by my reading of the datasheet for the CPU) ignores CRm for the cp15 cache flush operation, making the v4 cache implementation in cache-v4.S sufficient for this CPU. Tested with 740T core-tile on Integrator/AP baseboard. Acked-by: Hyok S. Choi <hyok.choi@samsung.com> Acked-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
* ARM: 7644/1: vmregion: remove vmregion code entirelyJoonsoo Kim2013-02-16
| | | | | | | | | | Now, there is no user for vmregion. So remove it. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: Remove support for ARMv3 ARM610 and ARM710 CPUsRussell King2012-05-05
| | | | | | | | | | | | This patch removes support for ARMv3 CPUs, which haven't worked properly for quite some time (see the FIXME comment in arch/arm/mm/fault.c). The only V3 parts left is the cache model for ARMv3, which is needed for some odd reason by ARM740T CPUs, and being able to build with -march=armv3, which is required for the RiscPC platform due to its bus structure. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: v6k: introduce CPU_V6K optionRussell King2011-02-02
| | | | | | | | | | | | | | | | Introduce a CPU_V6K configuration option for platforms to select if they have a V6K CPU core. This allows us to identify whether we need to support ARMv6 CPUs without the V6K SMP extensions at build time. Currently CPU_V6K is just an alias for CPU_V6, and all places which reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K). Select CPU_V6K from platforms which are known to be V6K-only. Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Sourav Poddar <sourav.poddar@ti.com> Tested-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: pgtable: collect up identity mapping functionsRussell King2010-12-22
| | | | | | | | | We have two places where we create identity mappings - one when we bring secondary CPUs online, and one where we setup some mappings for soft- reboot. Combine these two into a single implementation. Also collect the identity mapping deletion function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: Remove DISCONTIGMEM supportRussell King2010-07-16
| | | | | | | Everything should now be using sparsemem rather than discontigmem, so remove the code supporting discontigmem from ARM. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: Ensure ARMv6/7 mm files are built using appropriate assembler optionsRussell King2010-01-12
| | | | | | | | A kernel with both ARMv6 and ARMv7 selected results in build errors. Fix this by specifying the proper architectures for these assembly files. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Merge branch 'devel-stable' into develRussell King2009-12-05
|\
| * ARM: Add Tauros2 L2 cache controller supportLennert Buytenhek2009-11-27
| | | | | | | | | | | | | | | | | | Support for the Tauros2 L2 cache controller as used with the PJ1 and PJ4 CPUs. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Saeed Bishara <saeed@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* | ARM: dma-mapping: split out vmregion code from dma coherent mapping codeRussell King2009-11-24
|/ | | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Ungerer <gerg@uclinux.org>
* ARM: 5727/1: Pass IFSR register to do_PrefetchAbort()Kirill A. Shutemov2009-10-02
| | | | | | | | | | | | | | | | | Instruction fault status register, IFSR, was introduced on ARMv6 to provide status information about the last insturction fault. It needed for proper prefetch abort handling. Now we have three prefetch abort model: * legacy - for CPUs before ARMv6. They doesn't provide neither IFSR nor IFAR. We simulate IFSR with section translation fault status for them to generalize code; * ARMv6 - provides IFSR, but not IFAR; * ARMv7 - provides both IFSR and IFAR. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Merge branch 'for-rmk' of git://gitorious.org/linux-gemini/mainline into develRussell King2009-03-26
|\ | | | | | | | | | | | | Conflicts: arch/arm/mm/Kconfig Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * ARM: Add support for FA526 v2Paulius Zaleckas2009-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for Faraday FA526 core. This core is used at least by: Cortina Systems Gemini and Centroid family Cavium Networks ECONA family Grain Media GM8120 Pixelplus ImageARM Prolific PL-1029 Faraday IP evaluation boards v2: - move TLB_BTB to separate patch - update copyrights Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
* | Merge branch 'highmem' into develRussell King2009-03-24
|\ \
| * | [ARM] kmap supportNicolas Pitre2009-03-15
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kmap virtual area borrows a 2MB range at the top of the 16MB area below PAGE_OFFSET currently reserved for kernel modules and/or the XIP kernel. This 2MB corresponds to the range covered by 2 consecutive second-level page tables, or a single pmd entry as seen by the Linux page table abstraction. Because XIP kernels are unlikely to be seen on systems needing highmem support, there shouldn't be any shortage of VM space for modules (14 MB for modules is still way more than twice the typical usage). Because the virtual mapping of highmem pages can go away at any moment after kunmap() is called on them, we need to bypass the delayed cache flushing provided by flush_dcache_page() in that case. The atomic kmap versions are based on fixmaps, and __cpuc_flush_dcache_page() is used directly in that case. Signed-off-by: Nicolas Pitre <nico@marvell.com>
* / [ARM] pxa: add base support for Marvell's PXA168 processor lineEric Miao2009-03-22
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | """The Marvell® PXA168 processor is the first in a family of application processors targeted at mass market opportunities in computing and consumer devices. It balances high computing and multimedia performance with low power consumption to support extended battery life, and includes a wealth of integrated peripherals to reduce overall BOM cost .... """ See http://www.marvell.com/featured/pxa168.jsp for more information. 1. Marvell Mohawk core is a hybrid of xscale3 and its own ARM core, there are many enhancements like instructions for flushing the whole D-cache, and so on 2. Clock reuses Russell's common clkdev, and added the basic support for UART1/2. 3. Devices are a bit different from the 'mach-pxa' way, the platform devices are now dynamically allocated only when necessary (i.e. when pxa_register_device() is called). Description for each device are stored in an array of 'struct pxa_device_desc'. Now that: a. this array of device description is marked with __initdata and can be freed up system is fully up b. which means board code has to add all needed devices early in his initializing function c. platform specific data can now be marked as __initdata since they are allocated and copied by platform_device_add_data() 4. only the basic UART1/2/3 are added, more devices will come later. Signed-off-by: Jason Chagas <chagas@marvell.com> Signed-off-by: Eric Miao <eric.miao@marvell.com>
* [ARM] dma: rename consistent.c to dma-mapping.cRussell King2008-09-25
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Merge branch 'pxa' into develRussell King2008-07-13
|\ | | | | | | | | | | | | Conflicts: arch/arm/configs/em_x270_defconfig arch/arm/configs/xm_x270_defconfig
| * [ARM] pxa: add support for L2 outer cache on XScale3Eric Miao2008-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial patch from Lothar, and Lennert make it into a cleaner one, modified and tested on PXA320 by Eric Miao. This patch moves the L2 cache operations out of proc-xsc3.S into dedicated outer cache support code. CACHE_XSC3L2 can be deselected so no L2 cache specific code will be linked in, and that L2 enable bit will not be set, this applies to the following cases: a. _only_ PXA300/PXA310 support included and no L2 cache wanted b. PXA320 support included, but want L2 be disabled So the enabling of L2 depends on two things: - CACHE_XSC3L2 is selected - and L2 cache is present Where the latter is only a safeguard (previous testing shows it works OK even when this bit is turned on). IXP series of processors with XScale3 cannot disable L2 cache for the moment since they depend on the L2 cache for its coherent memory, so IXP may always select CACHE_XSC3L2. Other L2 relevant bits are always turned on (i.e. the original code enclosed by #if L2_CACHE_ENABLED .. #endif), as they showed no side effects. Specifically, these bits are: - OC bits in TTBASE register (table walk outer cache attributes) - LLR Outer Cache Attributes (OC) in Auxiliary Control Register Signed-off-by: Lothar WaÃ<9f>mann <LW@KARO-electronics.de> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | [ARM] Feroceon: L2 cache supportLennert Buytenhek2008-06-22
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
* [ARM] Feroceon: Feroceon-specific WA-cache compatible {copy,clear}_user_page()Lennert Buytenhek2008-04-28
| | | | | | | | | | | | | | | This patch implements a set of Feroceon-specific {copy,clear}_user_page() routines that perform more optimally than the generic implementations. This also deals with write-allocate caches (Feroceon can run L1 D in WA mode) which otherwise prevents Linux from booting. [nico: optimized the code even further] Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Tested-by: Sylver Bruneau <sylver.bruneau@googlemail.com> Tested-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
* [ARM] Marvell Feroceon CPU core supportAssaf Hoffman2008-01-26
| | | | | | | | | | | | | | | | The Feroceon is a family of independent ARMv5TE compliant CPU core implementations, supporting a variable depth pipeline and out-of-order execution. The Feroceon is configurable with VFP support, and the later models in the series are superscalar with up to two instructions per clock cycle. This patch adds the initial low-level cache/TLB handling for this core. Signed-off-by: Assaf Hoffman <hoffman@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 4394/1: ARMv7: Add the TLB range operationsCatalin Marinas2007-05-30
| | | | | | | | | We are currently using the ARMv6 operations but need to duplicate some of the code because of the introduction of the new CPU barrier instructions in ARMv7. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] armv7: add Makefile and Kconfig entriesCatalin Marinas2007-05-09
| | | | | | | | This patch adds the necessary lines to the Makefile and Kconfig files for enabling the compilation of the ARMv7 CPU support. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 4135/1: Add support for the L210/L220 cache controllersCatalin Marinas2007-02-11
| | | | | | | | | This patch adds the support for the L210/L220 (outer) cache controller. The cache range operations are done by index/way since L2 cache controller only accepts physical addresses. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: abort handler fixup for !CPU_CP15_MMU cores.Hyok S. Choi2006-09-28
| | | | | | | | | | There is no FSR/FAR register on no-CP15 or MPU cores. This patch adds a dummy abort handler which returns zero for the base restored Data Abort model !CPU_CP15_MMU cores. The abort-lv4t.S is still used with the fix-up for the base updated Data Abort model cores. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM946E-S core supportHyok S. Choi2006-09-27
| | | | | | | | | | | This patch adds ARM946E-S core support which has typically 8KB I&D cache. It has a MPU and supports ARMv5TE instruction set. Because the ARM946E-S core can be synthesizable with various cache size, CONFIG_CPU_DCACHE_SIZE is defined for vendor specific configurations. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM940T core supportHyok S. Choi2006-09-27
| | | | | | | | This patch adds ARM940T core support which has 4KB D-cache, 4KB I-cache and a MPU. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM9TDMI core supportHyok S. Choi2006-09-27
| | | | | | | | This patch adds ARM9TDMI core support which has no cache and no CP15 register(no memory control unit). Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM740T core supportHyok S. Choi2006-09-27
| | | | | | | This patch adds ARM740T core support which has a MPU and 4KB or 8KB cache. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM7TDMI core supportHyok S. Choi2006-09-27
| | | | | | | | This patch adds ARM7TDMI core support which has no cache and no CP15 register(no memory control unit). Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Rename mm-armv.c to pgd.cRussell King2006-09-27
| | | | | | | mm-armv.c now only contains the pgd allocation/freeing code, so rename it to have a more sensible filename. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Split ARM MM initialisation for !mmuRussell King2006-09-27
| | | | | | | Move the MMU specific code from init.c into mmu.c, and add nommu fixups to nommu.c Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Move mmu.c out of the wayRussell King2006-09-20
| | | | | | | Rename mmu.c to context.c - it's the ARMv6 ASID context handling code rather than generic "mmu" handling code. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: remove fault-armv, mmap and mm-armv files from nommu buildRussell King2006-06-28
| | | | | | | | | | | | | | Remove fault-armv.o, mmap.o and mm-armv.o from uclinux builds - these are concerned with MMU-ful operations, and as such are redundant for uclinux. Since this also removes iotable_init() and iotable_init() is used extensively in the platform support files, just make it a no-op. Based upon a couple of patches by Hyok. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: Provide a simple flush_dcache_page implementationRussell King2006-06-28
| | | | | | | | nommu doesn't require a complex flush_dcache_page implementation like the MMU-ful CPUs do, so provide a simplified version in nommu.c and omit flush.c from the build as appropriate. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add stubs for ioremap and friendsRussell King2006-06-28
| | | | | | | | | | | nommu doesn't have any form of remapping support, so ioremap, etc become stubs which just return the casted address, doing nothing else. Move ioport_map(), ioport_unmap(), pci_iomap(), pci_iounmap() into a separate file which is always built. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 3377/2: add support for intel xsc3 coreLennert Buytenhek2006-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch from Lennert Buytenhek This patch adds support for the new XScale v3 core. This is an ARMv5 ISA core with the following additions: - L2 cache - I/O coherency support (on select chipsets) - Low-Locality Reference cache attributes (replaces mini-cache) - Supersections (v6 compatible) - 36-bit addressing (v6 compatible) - Single instruction cache line clean/invalidate - LRU cache replacement (vs round-robin) I attempted to merge the XSC3 support into proc-xscale.S, but XSC3 cores have separate errata and have to handle things like L2, so it is simpler to keep it separate. L2 cache support is currently a build option because the L2 enable bit must be set before we enable the MMU and there is no easy way to capture command line parameters at this point. There are still optimizations that can be done such as using LLR for copypage (in theory using the exisiting mini-cache code) but those can be addressed down the road. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 3168/1: Update ARM signal delivery and maskingDaniel Jacobowitz2005-11-19
| | | | | | | | | | | | | | | | | Patch from Daniel Jacobowitz After delivering a signal (creating its stack frame) we must check for additional pending unblocked signals before returning to userspace. Otherwise signals may be delayed past the next syscall or reschedule. Once that was fixed it became obvious that the ARM signal mask manipulation was broken. It was a little bit broken before the recent SA_NODEFER changes, and then very broken after them. We must block the requested signals before starting the handler or the same signal can be delivered again before the handler even gets a chance to run. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: Fix Xscale copy_page implementationRussell King2005-06-08
| | | | | | | | | | The ARM copypage changes in 2.6.12-rc4-git1 removed the preempt locking from the copypage functions which broke the XScale implementation. This patch fixes the locking on XScale and removes the now unneeded minicache code. Signed-off-by: Russell King <rmk@arm.linux.org.uk> Checked-by: Richard Purdie
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-24 00:04:18 -0500