A typo caused these values to be swapped leading to incorrect memory
type attributes.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The MSM architecture covers a wider family of chips than just the MSM7X00A.
Move to a more generic name, in perparation for supporting the specific
SoC variants as sub-architectures (ARCH_MSM7X01A, ARCH_MSM722X, etc).  This
gives us ARCH_MSM for the (many) common peripherals.

This also removes the unused/obsolete config item MSM7X00A_IDLE.
Signed-off-by: NBrian Swetland <swetland@google.com>

ARMv4 (ARM720T) cache flush functions are broken in 2.6.19+ kernels.
The issue was introduced by commit f12d0d7c
This patch corrects the CPU_CP15 ifdef statements so that they actually
do something.
Signed-off-by: NAnders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add minimal Beagle board support. Based on earlier patches
by Syed Mohammed Khasim with some fixes from linux-omap tree.
Signed-off-by: NSyed Mohammed Khasim <khasim@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These instructions were placed in the code directly as opcodes because
early compilers didn't support them. Toolchains supporting ARMv7
understand these instructions and the patch puts the mnemonics back.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... including some comments about the ordering required to bring
sparsemem up.  You have to repeatedly guess, test, reguess, try
again and again to work out what the right ordering is.  Many
hours later...
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Provide helpers for getting physical addresses or pfns from the
meminfo array, and use them.  Move for_each_nodebank() to
asm/setup.h alongside the meminfo structure definition.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

asm code really wants asm/hwcap.h, so include that instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As of the previous commit, MT_DEVICE_IXP2000 encodes to the same
PTE bit encoding as MT_DEVICE, so it's now redundant.  Convert
MT_DEVICE_IXP2000 to use MT_DEVICE instead, and remove its aliases.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use 'shared device' mappings for devices, and use the standard
bit combinations for Xscale3.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This member is now redundant; the memory type is encoded in the Linux
PTE bits.
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>

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

Provide L_PTE_MT_xxx definitions to describe the memory types that we
use in Linux/ARM.  These definitions are carefully picked such that:

1. their LSBs match what is required for pre-ARMv6 CPUs.
2. they all have a unique encoding, including after modification
   by build_mem_type_table() (the result being that some have more
   than one combination.)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There are actually only four separate implementations of set_pte_ext.
Use assembler macros to insert code for these into the proc-*.S files.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There's no point scattering this around the tree, the parsing
of the parameter might as well live beside the code which uses
it.  That also means we can make vmalloc_reserve a static
variable.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The newly introduced sanity_check_meminfo() function should be
used to collect all validation of the meminfo array, which we
have in bootmem_init().  Move it there.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

- Make sure that coprocessor instructions for range ops are contiguous
  and not reordered.

- s/invalidate_and_disable_dcache/flush_and_disable_dcache/

- Don't re-enable I/D caches if they were not enabled initially.

- Change some masks to shifts for better generated code.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Acked-by: NLennert Buytenhek <buytenh@marvell.com>

The PTRS_PER_PMD != 1 condition can be evaluated with C code and
optimized at compile time.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As per the dma_unmap_* calls, we don't touch the cache when a DMA
buffer transitions from device to CPU ownership.  Presently, no
problems have been identified with speculative cache prefetching
which in itself is a new feature in later architectures.  We may
have to revisit the DMA API later for these architectures anyway.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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

No point having two of these; dma_map_page() can do all the work
for us.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Feroceon L2 cache can work in eighther write through or write back mode
on Kirkwood. Add the option to configure this mode according to Kconfig.
Signed-off-by: NRonen Shitrit <rshitrit@marvell.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

Update the ARM DMA scatter gather APIs for the scatterlist changes.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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

This patch provides an ARM implementation of ioremap_wc().

We use different page table attributes depending on which CPU we
are running on:

- Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
  possible mapping types (CB=00/01/10/11).  We can't use any of the
  cached memory types (CB=10/11), since that breaks coherency with
  peripheral devices.  Both CB=00 and CB=01 are suitable for _wc, and
  CB=01 (Uncached/Buffered) allows the hardware more freedom than
  CB=00, so we'll use that.

  (The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
  but isn't allowed to merge them, but there is no other mapping type
  we can use that allows the hardware to delay and merge stores, so
  we'll go with CB=01.)

- XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
  difference that on these platforms, CB=01 actually _does_ allow
  merging stores.  (If you want noncoalescing bufferable behavior
  on Xscale v1/v2, you need to use XCB=101.)

- Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
  mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
  in ARMv6 parlance).

  The ARMv6 ARM explicitly says that any accesses to Normal memory can
  be merged, which makes Normal memory more suitable for _wc mappings
  than Device or Strongly Ordered memory, as the latter two mapping
  types are guaranteed to maintain transaction number, size and order.
  We use the Uncached variety of Normal mappings for the same reason
  that we can't use C=1 mappings on ARMv5.

  The xsc3 Architecture Specification documents TEXCB=00100 as being
  Uncacheable and allowing coalescing of writes, which is also just
  what we need.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
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>

... some of which are now in linux/*.h headers.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This quietens some sparse warnings about phys_initrd_start and
phys_initrd_size.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static?

This function isn't used, so can be removed.

arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one
arch/arm/kernel/setup.c:524:6: originally declared here

A function containing two 'len's.

arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static?
arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static?
arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static?

Missing includes.

arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer
arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces)

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

This declaration specifies the "function" type and size for various
assembly functions, mainly needed for generating the correct branch
instructions in Thumb-2.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than pollute asm/cacheflush.h with the cache type definitions,
move them to asm/cachetype.h, and include this new header where
necessary.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add asm/cputype.h, moving functions and definitions from asm/system.h
there.  Convert all users of 'processor_id' to the more efficient
read_cpuid_id() function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... otherwise these fail to build.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch will truncate and/or ignore memory banks if their kernel
direct mappings would (partially) overlap with the vmalloc area or
the mappings between the vmalloc area and the address space top, to
prevent crashing during early boot if there happens to be more RAM
installed than we are expecting.

Since the start of the vmalloc area is not at a fixed address (but
the vmalloc end address is, via the per-platform VMALLOC_END define),
a default area of 128M is reserved for vmalloc mappings, which can
be shrunk or enlarged by passing an appropriate vmalloc= command line
option as it is done on x86.

On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
two 512M RAM banks and vmalloc=128M (the default), this patch gives:

	Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
	Memory: 512MB 352MB = 864MB total

On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
two 256M RAM banks and vmalloc=768M, this patch gives:

	Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
	Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Tested-by: NRiku Voipio <riku.voipio@iki.fi>

This patch performs the equivalent include directory shuffle for
plat-orion, and fixes up all users.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove includes of asm/hardware.h in addition to asm/arch/hardware.h.
Then, since asm/hardware.h only exists to include asm/arch/hardware.h,
update everything to directly include asm/arch/hardware.h and remove
asm/hardware.h.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>