Remove DMA autoload stuff
ARM: 6378/1: Allow lazy cache flushing via PG_arch_1 for highmem pages

Commit d73cd42 forced non-lazy cache flushing of highmem pages in
flush_dcache_page(). This isn't needed since __flush_dcache_page()
(called lazily from update_mmu_cache) can handle highmem pages (fixed by
commit 7e5a69e).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6379/1: Assume new page cache pages have dirty D-cache

There are places in Linux where writes to newly allocated page cache
pages happen without a subsequent call to flush_dcache_page() (several
PIO drivers including USB HCD). This patch changes the meaning of
PG_arch_1 to be PG_dcache_clean and always flush the D-cache for a newly
mapped page in update_mmu_cache().

The patch also sets the PG_arch_1 bit in the DMA cache maintenance
function to avoid additional cache flushing in update_mmu_cache().

Tested-by: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches

On SMP systems, there is a small chance of a PTE becoming visible to a
different CPU before the current cache maintenance operations in
update_mmu_cache(). To avoid this, cache maintenance must be handled in
set_pte_at() (similar to IA-64 and PowerPC).

This patch provides a unified VIPT cache handling mechanism and
implements the __sync_icache_dcache() function for ARMv6 onwards
architectures. It is called from set_pte_at() and replaces the
update_mmu_cache(). The latter is still used on VIVT hardware where a
vm_area_struct is required.

Tested-by: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arm: mm: Don't free prohibited memmap entries

The VM subsystem assumes that there are valid memmap entries to
the bank end aligned to MAX_ORDER_NR_PAGES. It will try and read
these page structs, and so we cannot free any memmap entries that
it may inspect.

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
ARM: mm: enforce pageblock alignment when freeing memmap entries at init

On some machines, the nodes do not always start on pageblock
boundaries. In these cases it is possible for free_unused_memmap
to free mappings for pages inside a pageblock with otherwise
valid pages. This presents problems for page migration since it
operates on whole pageblocks at a time.

Round down bank_start to pageblock boundary so that whole
pageblocks always have valid mappings.

Change-Id: Ie6588a274fc2fe9832cf47da31549ae3d004c118
Signed-off-by: Dima Zavin <dima@android.com>
Remove compiler warnings for gcc 4.5.0

init/main.c:734:10: warning: 'calltime.tv64' may be used uninitialized in
	this function
kernel/async.c:127:10: warning: 'calltime.tv64' may be used uninitialized in
	this function
kernel/async.c:283:10: warning: 'starttime.tv64' may be used uninitialized in
	this function
drivers/base/power/main.c:305:10: warning: 'calltime.tv64' may be used uninitialized
	in this function
drivers/base/power/main.c:305:10: warning: 'calltime.tv64' may be used uninitialized
	in this function
fs/eventpoll.c:1118:7: warning: 'slack' may be used uninitialized in this function
drivers/md/dm.c:1118:3: warning: statement with no effect
drivers/md/dm.c:1146:3: warning: statement with no effect
drivers/md/dm-table.c:1065:2: warning: statement with no effect
drivers/md/dm-table.c:1071:2: warning: statement with no effect
net/ipv4/netfilter/nf_nat_standalone.c:118:2: warning: case value '4' not
	in enumerated type 'enum ip_conntrack_info'
net/netfilter/nf_conntrack_netlink.c:762:11: warning: comparison between
	'enum ctattr_tuple' and 'enum ctattr_type'
lib/decompress_bunzip2.c:511:1: warning: the frame size of 1872 bytes is
	larger than 1024 bytes
drivers/regulator/core.c:2606:17: warning: 'err_ptr' may be used uninitialized
	in this function
drivers/media/video/gspca/gspca.c:1508:2: warning: case value '7' not in
	enumerated type 'enum v4l2_memory'

Change-Id: I72bd4784836c1f18d643b0747a296a2660106fa9
Signed-off-by: Ezra Godfrey <egodfrey@codeaurora.org>
Signed-off-by: scotthartbti <scott@ubuntu.com>

Conflicts:

	arch/arm/mm/Makefile
	drivers/regulator/core.c

Conflicts:
	fs/Makefile
kmap_atomic: make kunmap_atomic() harder to misuse

kunmap_atomic() is currently at level -4 on Rusty's "Hard To Misuse"
list[1] ("Follow common convention and you'll get it wrong"), except in
some architectures when CONFIG_DEBUG_HIGHMEM is set[2][3].

kunmap() takes a pointer to a struct page; kunmap_atomic(), however, takes
takes a pointer to within the page itself.  This seems to once in a while
trip people up (the convention they are following is the one from
kunmap()).

Make it much harder to misuse, by moving it to level 9 on Rusty's list[4]
("The compiler/linker won't let you get it wrong").  This is done by
refusing to build if the type of its first argument is a pointer to a
struct page.

The real kunmap_atomic() is renamed to kunmap_atomic_notypecheck()
(which is what you would call in case for some strange reason calling it
with a pointer to a struct page is not incorrect in your code).

The previous version of this patch was compile tested on x86-64.

[1] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
[2] In these cases, it is at level 5, "Do it right or it will always
    break at runtime."
[3] At least mips and powerpc look very similar, and sparc also seems to
    share a common ancestor with both; there seems to be quite some
    degree of copy-and-paste coding here. The include/asm/highmem.h file
    for these three archs mention x86 CPUs at its top.
[4] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
[5] As an aside, could someone tell me why mn10300 uses unsigned long as
    the first parameter of kunmap_atomic() instead of void *?

Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
Cc: Russell King <linux@arm.linux.org.uk> (arch/arm)
Cc: Ralf Baechle <ralf@linux-mips.org> (arch/mips)
Cc: David Howells <dhowells@redhat.com> (arch/frv, arch/mn10300)
Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> (arch/mn10300)
Cc: Kyle McMartin <kyle@mcmartin.ca> (arch/parisc)
Cc: Helge Deller <deller@gmx.de> (arch/parisc)
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> (arch/parisc)
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> (arch/powerpc)
Cc: Paul Mackerras <paulus@samba.org> (arch/powerpc)
Cc: "David S. Miller" <davem@davemloft.net> (arch/sparc)
Cc: Thomas Gleixner <tglx@linutronix.de> (arch/x86)
Cc: Ingo Molnar <mingo@redhat.com> (arch/x86)
Cc: "H. Peter Anvin" <hpa@zytor.com> (arch/x86)
Cc: Arnd Bergmann <arnd@arndb.de> (include/asm-generic)
Cc: Rusty Russell <rusty@rustcorp.com.au> ("Hard To Misuse" list)
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arm: Turn off generic lockbreak when using ticket spinlocks - CAF

CONFIG_GENERIC_LOCKBREAK can still cause livelocks in some situations,
even when using ticket spinlocks.
ARM: 6385/1: setup: detect aliasing I-cache when D-cache is non-aliasing

Currently, the Kernel assumes that if a CPU has a non-aliasing D-cache
then the I-cache is also non-aliasing. This may not be true on ARM cores
from v6 onwards, which may have aliasing I-caches but non-aliasing
D-caches.

This patch adds a cpu_has_aliasing_icache function, which is called from
cacheid_init and adds CACHEID_VIPT_I_ALIASING to the cacheid when
appropriate. A utility macro, icache_is_vipt_aliasing(), is also
provided.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: cache: detect VIPT aliasing I-cache on ARMv6

    The current cache detection code does not check for an aliasing
    I-cache if the D-cache is found to be VIPT aliasing.

    This patch fixes the problem by always checking for an aliasing
    I-cache on v6 and later.

    Signed-off-by: Will Deacon <will.deacon@arm.com>