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>

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>

... 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>

Move platform independent header files to arch/arm/include/asm, leaving
those in asm/arch* and asm/plat* alone.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Claim the initrd memory exclusively, and order other memory
reservations beforehand.  This allows us to determine whether
the initrd memory was overwritten, and disable the initrd in
that case.

This avoids a 'bad page state' bug.
Tested-by: NRalph Siemsen <ralphs@netwinder.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

(20072fd0 lost most of its changes
somehow, came from a mbox archive applied with git-am.  No idea
what happened.  This puts back the missing bits.  --rmk)

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: NLothar WaÃ&lt;9f&gt;mann <LW@KARO-electronics.de>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It seems this small label was lost in the last merge. Without it
no CPU type is selected for the MX2 family of processors. And a build
will fail badly...
Signed-off-by: NJuergen Beisert <j.beisert@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The shared mmap code works fine for the test case, which only checked
for two shared maps of the same file.  However, three shared maps
result in one mapping remaining cached, resulting in stale data being
visible via that mapping.  Fix this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

free_area_init_node() gets passed in the node id as well as the node
descriptor.  This is redundant as the function can trivially get the node
descriptor itself by means of NODE_DATA() and the node's id.

I checked all the users and NODE_DATA() seems to be usable everywhere
from where this function is called.
Signed-off-by: NJohannes Weiner <hannes@saeurebad.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are a lot of places that define either a single bootmem descriptor or an
array of them.  Use only one central array with MAX_NUMNODES items instead.
Signed-off-by: NJohannes Weiner <hannes@saeurebad.de>
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Kyle McMartin <kyle@parisc-linux.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC.

AT91sam9g20 is an evolution of the at91sam9260 with a faster clock
speed.
We created a new board for this device but based the chip support
directly on 9260 files with little updates.
Here is the chip page on Atmel wabsite:
http://atmel.com/dyn/products/product_card.asp?part_id=4337Signed-off-by: NSedji Gaouaou <sedji.gaouaou@atmel.com>
Signed-off-by: NJustin Waters <justin.waters@timesys.com>
Acked-by: NAndrew Victor <linux@maxim.org.za>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NLothar WaÃ&lt;9f&gt;mann <LW@KARO-electronics.de>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On Feroceon platforms that have a branch prediction unit, bit 11 of the
cp15 control register controls the BPU.  This patch keeps the old value
of this bit instead of always clearing it.
Signed-off-by: NSaeed Bishara <saeed@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

This patch adds basic mach support for the mx2 processor family, based
on the original freescale code and adapted to mainline kernel coding
style.

This part adds the global build only.
Signed-off-by: NJuergen Beisert <j.beisert@pengutronix.de>

This patch adds the I-cache invalidation in update_mmu_cache if the
corresponding vma is marked as executable. It also invalidates the
I-cache if a thread migrates to a CPU it never ran on.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The Marvell Discovery Duo (MV78xx0) is a family of ARM SoCs featuring
(depending on the model) one or two Feroceon CPU cores with 512K of L2
cache and VFP coprocessors running at (depending on the model) between
800 MHz and 1.2 GHz, and features a DDR2 controller, two PCIe
interfaces that can each run either in x4 or quad x1 mode, three USB
2.0 interfaces, two 3Gb/s SATA II interfaces, a SPI interface, two
TWSI interfaces, a crypto accelerator, IDMA/XOR engines, a SPI
interface, four UARTs, and depending on the model, two or four gigabit
ethernet interfaces.

This patch adds basic support for the platform, and allows booting
on the MV78x00 development board, with functional UARTs, SATA, PCIe,
GigE and USB ports.
Signed-off-by: NStanislav Samsonov <samsonov@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

Add support for the Feroceon 88fr571-vd CPU core as found in e.g.
the Marvell Discovery Duo family of ARM SoCs.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

The Marvell Kirkwood (88F6000) is a family of ARM SoCs based on a
Shiva CPU core, and features a DDR2 controller, a x1 PCIe interface,
a USB 2.0 interface, a SPI controller, a crypto accelerator, a TS
interface, and IDMA/XOR engines, and depending on the model, also
features one or two Gigabit Ethernet interfaces, two SATA II
interfaces, one or two TWSI interfaces, one or two UARTs, a
TDM/SLIC interface, a NAND controller, an I2S/SPDIF interface, and
an SDIO interface.

This patch adds supports for the Marvell DB-88F6281-BP Development
Board and the RD-88F6192-NAS and the RD-88F6281 Reference Designs,
enabling support for the PCIe interface, the USB interface, the
ethernet interfaces, the SATA interfaces, the TWSI interfaces, the
UARTs, and the NAND controller.
Signed-off-by: NSaeed Bishara <saeed@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

Add support for the Shiva 88fr131 CPU core as found in e.g. the
Marvell Kirkwood family of ARM SoCs.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

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: NLennert Buytenhek <buytenh@marvell.com>

This patch adds support for the L1 D cache range operations that
are supported by the Marvell Discovery Duo and Marvell Kirkwood
ARM SoCs.
Signed-off-by: NStanislav Samsonov <samsonov@marvell.com>
Acked-by: NSaeed Bishara <saeed@marvell.com>
Reviewed-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

The Marvell Loki (88RC8480) is an ARM SoC based on a Feroceon CPU
core running at between 400 MHz and 1.0 GHz, and features a 64 bit
DDR controller, 512K of internal SRAM, two x4 PCI-Express ports,
two Gigabit Ethernet ports, two 4x SAS/SATA controllers, two UARTs,
two TWSI controllers, and IDMA/XOR engines.

This patch adds support for the Marvell LB88RC8480 Development
Board, enabling the use of the PCIe interfaces, the ethernet
interfaces, the TWSI interfaces and the UARTs.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

There are a couple more Feroceon-based SoCs out in the field that use
different Variant and Architecture fields in their Main ID registers
-- this patch tweaks the processor match/mask in proc-feroceon.S to
catch those SoCs as well.
Signed-off-by: NKe Wei <kewei@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

Flushing the L1 D cache with a test/clean/invalidate loop is very
easy in software, but it is not the quickest way of doing it, as
there is a lot of overhead involved in re-scanning the cache from
the beginning every time we hit a dirty line.

This patch makes proc-feroceon.S use "clean+invalidate by set/way"
loops according to possible cache configuration of Feroceon CPUs
(either direct-mapped or 4-way set associative).
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>

Annotate the entries for the 88fr531-vd CPU core in
arch/arm/boot/compressed/head.S and arch/arm/mm/proc-feroceon.S
with the full name of the core.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Acked-by: NRussell King <linux@arm.linux.org.uk>

More cosmetic cleanup:
- Replace 8-space indents by proper tab indents.
- In structure initialisers, use a trailing comma for every member.
- Collapse "},\n{" in structure initialiers to "}, {".
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Acked-by: NRussell King <linux@arm.linux.org.uk>

The CPU's dma_flush_range() operation needs to clean+invalidate the
given memory area if the cache is in writeback mode, or do just the
invalidate part if the cache is in writethrough mode, but the current
proc-arm{925,926,940,946} (incorrectly) do a cache clean in the
latter case.  This patch fixes that.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Almost all implementations of pci_iomap() in the kernel, including the generic
lib/iomap.c one, copies the content of a struct resource into unsigned long's
which will break on 32 bits platforms with 64 bits resources.

This fixes all definitions of pci_iomap() to use resource_size_t.  I also
"fixed" the 64bits arch for consistency.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NLennert Buytenhek <buytenh@marvell.com>
Tested-by: NSylver Bruneau <sylver.bruneau@googlemail.com>
Tested-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>