aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2005-09-01[ARM] Fix ARMv6 page table bitsRussell King1-1/+1
We weren't explicitly setting the page table bits we desired in user_prot in the protection table, which resulted in the user mappings for v6 CPUs being marked global. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-01[ARM] Simplify setup_mm_for_reboot()Russell King1-9/+9
No point checking what CPU architecture level we have each time within the loop, so precompute the base PMD flags outside the loop. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-01[ARM] Convert open-coded __pmd_populate to use inline functionRussell King1-5/+1
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-31[ARM] 2867/2: unaligned ldrd/strd fixupsSteve Longerbeam1-14/+56
Patch from Steve Longerbeam Adds an implementation of unaligned LDRD and STRD fixups. Also fixes a bug where do_alignment() would misinterpret and fixup an unaligned LDRD/STRD as LDRH/STRH, causing memory corruption. This is the same as Patch #2867/1, but with minor whitespace and comments changes, plus a check for arch-level >= v5TE before printing ai_dword count in proc_alignment_read(). Signed-off-by: Steve Longerbeam <stevel@mwwireless.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-29[ARM] 2853/1: Make alloc_init_supersection() work with 36-bit mappingsDeepak Saxena1-3/+1
Patch from Deepak Saxena Working on adding support for 36-bit static mappings for ARMv6 and Intel's XSC3 core and noticed that alloc_init_supersection currently increments the phys addr by 1MB on each of the 16 iterations and then forces alignment to supersection size (16MB). This is really uneeded b/c we have already forced the phys address to be 16MB aligned in create_mapping(). Furthermore, this breaks 36-bit addressing b/c bits [23:20] of the PMD contain bits [35:32] of the physical address and the masking causes us to loose those bits thus ending up with an incorrect virt -> phys translation. The other option is to have an alloc_init_supersection36. Tested on Intel IXP2350 CPU with 36-bit static I/O mappings. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-17[ARM] 2852/1: Correct the mistake in arch/arm/mm/Kconfig fileSean Lee1-1/+1
Patch from Sean Lee In the arch/arm/mm/Kconfig file, the CPU_DCACHE_WRITETHROUGH option is depend on the CPU_DISABLE_DCACHE, but the "Disable D-Cache" option is configured as CPU_DCACHE_DISABLE. The CPU_DISABLE_DCACHE should be CPU_DCACHE_DISABLE Signed-off-by: Sean Lee <beginner2arm@eyou.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-15[ARM] Remove extraneous whitespace introduced in previous ARMv6 patchRussell King1-1/+1
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-10[ARM] Control v6 'global' bit via Linux PTE entriesRussell King2-5/+16
Unfortunately, we can't use the "user" bit in the page tables to control whether a page table entry is "global" or "asid" specific, since the vector page is mapped as "user" accessible but is not process specific. Therefore, give direct control of the ARMv6 "nG" (not global) bit to the mm layers. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-10[ARM] Use #defined constants for manipulating v6 hardware PTE bitsRussell King1-13/+7
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-04[PATCH] ARM: Fix ARM fault handler for get_user_pages() fixes.Russell King1-3/+3
The ARM fault handler is optimised to make the fast path, err, fast. The renumbering of the VM_FAULT_* codes broke this because numbers were used instead of the definitions. Fix this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-03[PATCH] ARM: 2839/1: Remove XScale cache and TLB locking codeDeepak Saxena1-136/+0
Patch from Deepak Saxena The XScale locking code is not something that has been validated on 2.6 and needs to be replaced with a more generic API to use with other ARMs that support locking features. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-07-26[PATCH] ARM SMP: Mark device mappings as "device" in ARMv6 parlanceRussell King1-0/+3
ARMv6 introduces memory types into the page tables. Mark devices mappings with the "shared device" memory type. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-07-10[PATCH] ARM: 2798/1: OMAP update 2/11: Change ARM Kconfig to support omap1 and omap2Tony Lindgren1-1/+1
Patch from Tony Lindgren This patch by Paul Mundt and other OMAP developers modifies ARM specific Kconfig to allow sharing code between OMAP1 and OMAP2 architectures. In order to share code between OMAP1 and OMAP2, all OMAP1 specific code is moved into mach-omap1 directory in the following patch. A new mach-omap2 directory will be added later on. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-07-10[PATCH] ARM: 2796/1: Fix ARMv5[TEJ] check in MMU initalizationDeepak Saxena1-2/+2
Patch from Deepak Saxena The code in mm-armv.c checks for the condition (cpu_architecture()<= ARMv5) in a few places but should be checking for ARMv5TEJ as the MMU is shared across all v5 variations. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-07-06[PATCH] ARM: 2789/1: Enable access to both CP10 and CP11 on ARMv6Catalin Marinas1-1/+1
Patch from Catalin Marinas The VFP instructions trigger undefined exceptions because the access to CP11 is disabled (only CP10 is currently enabled by the kernel). The patch fixes this problem. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-07-03[PATCH] ARM: 2784/1: Fix the block cache flush operation rangeCatalin Marinas1-1/+2
Patch from Catalin Marinas The range for the ARMv6 block cache operations is inclusive but the kernel doesn't re-calculate the end address, causing a page fault when used (this only happens with support for cache aliasing, otherwise the blk_flush_kern_dcache_page() is not called). This patch subtracts L1_CACHE_BYTES from the end address. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-30[PATCH] ARM: 2779/1: Fix the V bit setting for the ARM1020x CPUsCatalin Marinas2-4/+4
Patch from Catalin Marinas This patch fixes the V bit setting for the ARM1020x processors. At reset, this bit is automatically set to the value of the HIVECSINIT input signal which just happened to be 1 but it is not mandatory. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-30[PATCH] ARM: 2777/1: Fix broken comment arch/arm/mm/proc-arm1020.SCatalin Marinas1-1/+1
Patch from Catalin Marinas This patch fixes a broken comment in the proc-arm1020.S file which prevents the file compilation Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-30[PATCH] ARM: Don't try to send a signal to pid0Russell King1-35/+40
If we receive an unrecognised abort during boot, don't try to send a signal to pid0, but instead report the current state. This leads to less confusing debug reports. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-28[PATCH] ARM SMP: Use local_flush_tlb* where we really want to be localRussell King2-2/+2
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-27[PATCH] ARM: Move memmap freeing into init.cRussell King2-78/+65
It doesn't make sense for this to be in mm-armv.c now that 26-bit ARM support is no longer integrated into arch/arm. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-27[PATCH] ARM: Move PGD kernel page table initialisationRussell King1-8/+7
It doesn't make sense to have the PGD kernel pointers initialisation separate from the PGD user pointers, especially when we clean the data cache over the whole range. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-24[PATCH] ARM: 2698/1: Enable kernel r/w access to user pages on ARMv6Catalin Marinas1-3/+3
Patch from Catalin Marinas cpu_v6_set_pte() sets the kernel access rights to r/o for user pages (L_PTE_USER) when neither L_PTE_WRITE nor L_PTE_DIRTY are set. This causes a kernel data abort when writing the TLS value in the 0xffff0000 page. This patch enables the kernel r/w access. Signed-off-by: Catalin Marinas Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-22[PATCH] ARM: Remove explicit page-alignments in memory initRussell King1-13/+6
Since meminfo.bank[] array contains page-aligned start/size, we no longer need to explicitly round up/down the addresses when converting to PFNs. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-21[PATCH] Avoiding mmap fragmentationWolfgang Wander1-1/+9
Ingo recently introduced a great speedup for allocating new mmaps using the free_area_cache pointer which boosts the specweb SSL benchmark by 4-5% and causes huge performance increases in thread creation. The downside of this patch is that it does lead to fragmentation in the mmap-ed areas (visible via /proc/self/maps), such that some applications that work fine under 2.4 kernels quickly run out of memory on any 2.6 kernel. The problem is twofold: 1) the free_area_cache is used to continue a search for memory where the last search ended. Before the change new areas were always searched from the base address on. So now new small areas are cluttering holes of all sizes throughout the whole mmap-able region whereas before small holes tended to close holes near the base leaving holes far from the base large and available for larger requests. 2) the free_area_cache also is set to the location of the last munmap-ed area so in scenarios where we allocate e.g. five regions of 1K each, then free regions 4 2 3 in this order the next request for 1K will be placed in the position of the old region 3, whereas before we appended it to the still active region 1, placing it at the location of the old region 2. Before we had 1 free region of 2K, now we only get two free regions of 1K -> fragmentation. The patch addresses thes issues by introducing yet another cache descriptor cached_hole_size that contains the largest known hole size below the current free_area_cache. If a new request comes in the size is compared against the cached_hole_size and if the request can be filled with a hole below free_area_cache the search is started from the base instead. The results look promising: Whereas 2.6.12-rc4 fragments quickly and my (earlier posted) leakme.c test program terminates after 50000+ iterations with 96 distinct and fragmented maps in /proc/self/maps it performs nicely (as expected) with thread creation, Ingo's test_str02 with 20000 threads requires 0.7s system time. Taking out Ingo's patch (un-patch available per request) by basically deleting all mentions of free_area_cache from the kernel and starting the search for new memory always at the respective bases we observe: leakme terminates successfully with 11 distinctive hardly fragmented areas in /proc/self/maps but thread creating is gringdingly slow: 30+s(!) system time for Ingo's test_str02 with 20000 threads. Now - drumroll ;-) the appended patch works fine with leakme: it ends with only 7 distinct areas in /proc/self/maps and also thread creation seems sufficiently fast with 0.71s for 20000 threads. Signed-off-by: Wolfgang Wander <wwc@rentec.com> Credit-to: "Richard Purdie" <rpurdie@rpsys.net> Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> (partly) Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-20[PATCH] ARM: 2686/2: AAEC-2000 Core supportBellido Nicolas1-1/+1
Patch from Bellido Nicolas Core support for AAEC-2000 based platforms. This is an updated version of the previous patch, and takes into account Russell's comments. AAED-2000 default configuration will follow as soon as some problems with the bootloader are sorted out... Signed-off-by: Nicolas Bellido Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20[PATCH] ARM: Add iomap support for ARMRussell King1-0/+47
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20[PATCH] ARM: Add common CACHE_COLOUR macroRussell King1-4/+2
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20[PATCH] ARM: Fix delayed dcache flush for ARMv6 non-aliasing cachesRussell King2-46/+29
flush_dcache_page() did nothing for these caches, but since they suffer from I/D cache coherency issues, we need to ensure that data is written back to RAM. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-09[PATCH] ARM: Remove zero-byte sized fileRussell King1-0/+0
Remove the remaining zero byte file left over from the Xscale fixes. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-06-08[PATCH] ARM: 2664/2: add support for atomic ops on pre-ARMv6 SMP systemsNicolas Pitre1-0/+8
Patch from Nicolas Pitre Not that there might be many of them on the planet, but at least RMK apparently has one. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-08[PATCH] ARM: Fix Xscale copy_page implementationRussell King5-195/+131
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
2005-05-16[PATCH] ARM: Fix build errorRussell King2-4/+4
Mainline kernels don't have VECTORS_HIGH nor COPYPAGE_MINICACHE yet. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-12[PATCH] ARM: 2680/1: refine TLS reg availability some more againNicolas Pitre1-11/+10
Patch from Nicolas Pitre Not all ARMv6 processors implement the TLS register. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-05-10[PATCH] ARM: 2663/2: I can't typeNicolas Pitre1-2/+2
Patch from Nicolas Pitre Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-05-10[PATCH] ARM: Add V6 aliasing cache flushRussell King1-2/+35
Add cache flushing support for aliased V6 caches to flush_dcache_page. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-10[PATCH] ARM: Use top_pmd for V6 copy/clear user_pageRussell King1-22/+6
Remove needless page table walking for v6 page operations. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-10[PATCH] ARM: Move copy/clear user_page locking into implementationRussell King2-80/+111
Move the locking for copy_user_page() and clear_user_page() into the implementations which require locking. For simple memcpy/ memset based implementations, the locking is extra overhead which is not necessary, and prevents preemption occuring. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-10[PATCH] ARM: Add top_pmd, which points at the top-most page tableRussell King1-0/+4
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-09[PATCH] ARM: Add inline functions to find the pmd from virtual addressRussell King1-8/+15
Add pmd_off() and pmd_off_k() to obtain the pmd pointer for a virtual address, and use them throughout the mm initialisation. Signed-off-by: Russell King <rmk@arm.linux.org.uk>
2005-05-05[PATCH] ARM: 2663/1: straightify TLS register emulation a bit moreNicolas Pitre1-9/+15
Patch from Nicolas Pitre This better express things, and should cover RMK's weird SMP toys. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-05-03[PATCH] ARM: 2662/1: missing "default y" for CONFIG_HAS_TLS_REGNicolas Pitre1-0/+1
Patch from Nicolas Pitre Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29[PATCH] ARM: 2656/1: Access permission bits are wrong for kernel XIP sections on ARMv6George G. Davis1-2/+3
Patch from George G. Davis This patch is required for kernel XIP support on ARMv6 machines. It ensures that the access permission bits for kernel XIP section descriptors are APX=1 and AP[1:0]=01, which is Kernel read-only/User no access permissions. Prior to this change, kernel XIP section descriptor access permissions were set to Kernel no access/User no access on ARMv6 machines and the kernel would therefore hang upon entry to userspace when set_fs(USER_DS) was executed. Signed-off-by: Steve Longerbeam Signed-off-by: George G. Davis Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29[PATCH] ARM: 2651/3: kernel helpers for NPTL supportNicolas Pitre1-0/+14
Patch from Nicolas Pitre This patch entirely reworks the kernel assistance for NPTL on ARM. In particular this provides an efficient way to retrieve the TLS value and perform atomic operations without any instruction emulation nor special system call. This even allows for pre ARMv6 binaries to be forward compatible with SMP systems without any penalty. The problematic and performance critical operations are performed through segment of kernel provided user code reachable from user space at a fixed address in kernel memory. Those fixed entry points are within the vector page so we basically get it for free as no extra memory page is required and nothing else may be mapped at that location anyway. This is different from (but doesn't preclude) a full blown VDSO implementation, however a VDSO would prevent some assembly tricks with constants that allows for efficient branching to those code segments. And since those code segments only use a few cycles before returning to user code, the overhead of a VDSO far call would add a significant overhead to such minimalistic operations. The ARM_NR_set_tls syscall also changed number. This is done for two reasons: 1) this patch changes the way the TLS value was previously meant to be retrieved, therefore we ensure whatever library using the old way gets fixed (they only exist in private tree at the moment since the NPTL work is still progressing). 2) the previous number was allocated in a range causing an undefined instruction trap on kernels not supporting that syscall and it was determined that allocating it in a range returning -ENOSYS would be much nicer for libraries trying to determine if the feature is present or not. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29[PATCH] ARM: 2655/1: ARM1136 SWP instruction abort handler fixGeorge G. Davis1-0/+16
Patch from George G. Davis As noted in http://www.arm.com/linux/patch-2.6.9-arm1.gz, the "Faulty SWP instruction on 1136 doesn't set bit 11 in DFSR." So the v6_early_abort handler does not report the correct rd/wr direction for the SWP instruction which may result in SEGVS or hangs. In order to work around this problem, this patch merely updates the fix contained in the ARM Ltd. patch to use the macroised abort handler fixups. Signed-off-by: George G. Davis Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16[PATCH] arm: add comment about max_low_pfn/max_pfnakpm@osdl.org1-0/+3
) From: Russell King <rmk+lkml@arm.linux.org.uk> Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, rather than the maximum PFN on ARM. This doesn't seem to cause any problems, so just add a note about it. Signed-off-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] arm: fix SIGBUS handlingakpm@osdl.org1-44/+36
) From: Russell King <rmk+lkml@arm.linux.org.uk> ARM wasn't raising a SIGBUS with a siginfo structure. Fix __do_user_fault() to allow us to use it for SIGBUS conditions, and arrange for the sigbus path to use this. We need to prevent the siginfo code being called if we do not have a user space context to call it, so consolidate the "user_mode()" tests. Thanks to Ian Campbell who spotted this oversight. Signed-off-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds56-0/+13340
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!