Delete obsoleted stuff from arch Makefile and rename
constants.h to asm-offsets.h
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Patch from Timothy Baldwin

All data aborts are treated as read accesses. The existing code updates the wrong bit of r1, also the comments are wrong in that the sense of the L bit is inverted.
Signed-off-by: NTimothy E. Baldwin <T.E.Baldwin99@members.leeds.ac.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NSteve Longerbeam <stevel@mwwireless.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NSean Lee <beginner2arm@eyou.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

ARMv6 introduces memory types into the page tables.  Mark devices
mappings with the "shared device" memory type.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Catalin Marinas

This patch fixes a broken comment in the proc-arm1020.S file which
prevents the file compilation
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NWolfgang Wander <wwc@rentec.com>
Credit-to: "Richard Purdie" <rpurdie@rpsys.net>
Signed-off-by: NKen Chen <kenneth.w.chen@intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu> (partly)
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the remaining zero byte file left over from the Xscale
fixes.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>

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: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRussell King <rmk@arm.linux.org.uk>
Checked-by: Richard Purdie

Mainline kernels don't have VECTORS_HIGH nor COPYPAGE_MINICACHE yet.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>

Patch from Nicolas Pitre

Not all ARMv6 processors implement the TLS register.

Signed-off-by: Nicolas Pitre
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Nicolas Pitre

Signed-off-by: Nicolas Pitre
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add cache flushing support for aliased V6 caches to
flush_dcache_page.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>

Remove needless page table walking for v6 page operations.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>

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: NRussell King <rmk@arm.linux.org.uk>