arm: mm: restrict kernel memory permissions if CONFIG_STRICT_MEMORY_RWX set

If CONFIG_STRICT_MEMORY_RWX is set, make kernel text RX,
kernel data/stack RW and rodata RO so that writing
on kernel text, executing kernel data or stack, or
writing on or executing read-only data is prohibited.

Change-Id: Ib2242c20dabddb63ef3f5655d5794fe418cb6287
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
(cherry picked from commit 5a5305e90d4204fdf0586fbbd9a19b92181e74ea)

Conflicts:

	arch/arm/mm/mmu.c
msm: improve handling of DONT_MAP_HOLE_AFTER_MEMBANK0

The code to avoid mapping the hole after memory bank 0
located the start and size of this hole after running
generic initialization code which needed to convert
physical addresses to virtual ones and vice-versa
beyond this hole.

While this didn't prevent the kernel from booting, this
isn't clean, and in fact it was giving us more vmalloc
space than the config file specified (and as a result
there was less lowmem than expected).

The code to locate the hole now runs before this
initialization code.

Change-Id: Id67d8b9ea489b6d6a2c20151b0fc9a9d7b5b662d
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
(cherry picked from commit 31a949b5c5004f017e4adfa86f4a136025acdcd4)

Conflicts:

	arch/arm/mach-msm/include/mach/memory.h
	arch/arm/mm/init.c
	arch/arm/mm/mmu.c
ARM: integrate CMA with DMA-mapping subsystem

This patch adds support for CMA to dma-mapping subsystem for ARM
architecture. By default a global CMA area is used, but specific devices
are allowed to have their private memory areas if required (they can be
created with dma_declare_contiguous() function during board
initialisation).

Contiguous memory areas reserved for DMA are remapped with 2-level page
tables on boot. Once a buffer is requested, a low memory kernel mapping
is updated to to match requested memory access type.

GFP_ATOMIC allocations are performed from special pool which is created
early during boot. This way remapping page attributes is not needed on
allocation time.

CMA has been enabled unconditionally for ARMv6+ systems.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
CC: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Rob Clark <rob.clark@linaro.org>
Tested-by: Ohad Ben-Cohen <ohad@wizery.com>
Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Tested-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

Conflicts:

	arch/arm/include/asm/mach/map.h
	arch/arm/mm/init.c
	arch/arm/mm/mm.h
	arch/arm/mm/mmu.c

Change-Id: I85e3b43a9fa1e3c4d33cbc85fff6dee1b815041d
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: c79095092834a18ae74cfc08def1a5a101dc106c
ARM: dma-mapping: remove unconditional dependency on CMA

CMA has been enabled unconditionally on all ARMv6+ systems to solve the
long standing issue of double kernel mappings for all dma coherent
buffers. This however created a dependency on CONFIG_EXPERIMENTAL for
the whole ARM architecture what should be really avoided. This patch
removes this dependency and lets one use old, well-tested dma-mapping
implementation also on ARMv6+ systems without the need to use
EXPERIMENTAL stuff.

Change-Id: I17831dd98204dd8598fc469ae93f0ceb2c7c84c3
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[lauraa: Fixed conflicts in dma-mapping.c]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: f1ae98da8525c6b8b1c301c3a2b0bd2b6515cca2

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: use dma_mmap_from_coherent()

Change-Id: Ibc4086c0f48272356187966fce416a57160fab76
[lauraa: context conflicts]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 47142f07eea32e9c108f548a4b06c28bec7df6e4

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: use pr_* instread of printk

Replace all calls to printk with pr_* functions family.

Change-Id: Id03dee8797cd736529ede3ef525a930b90a04042
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 6b6f770b573903f8a7d1cfab1fc662685653f413
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: introduce DMA_ERROR_CODE constant

Replace all uses of ~0 with DMA_ERROR_CODE, what should make the code
easier to read.

Change-Id: I6c0fff904d8df3a9d2a8a727e62faf000a55c1b5
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 553ac78877242b6d8b591323731df304140d0f99
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: remove offset parameter to prepare for generic dma_ops

This patch removes the need for the offset parameter in dma bounce
functions. This is required to let dma-mapping framework on ARM
architecture to use common, generic dma_map_ops based dma-mapping
helpers.

Background and more detailed explaination:

dma_*_range_* functions are available from the early days of the dma
mapping api. They are the correct way of doing a partial syncs on the
buffer (usually used by the network device drivers). This patch changes
only the internal implementation of the dma bounce functions to let
them tunnel through dma_map_ops structure. The driver api stays
unchanged, so driver are obliged to call dma_*_range_* functions to
keep code clean and easy to understand.

The only drawback from this patch is reduced detection of the dma api
abuse. Let us consider the following code:

dma_addr = dma_map_single(dev, ptr, 64, DMA_TO_DEVICE);
dma_sync_single_range_for_cpu(dev, dma_addr+16, 0, 32, DMA_TO_DEVICE);

Without the patch such code fails, because dma bounce code is unable
to find the bounce buffer for the given dma_address. After the patch
the above sync call will be equivalent to:

dma_sync_single_range_for_cpu(dev, dma_addr, 16, 32, DMA_TO_DEVICE);

which succeeds.

I don't consider this as a real problem, because DMA API abuse should be
caught by debug_dma_* function family. This patch lets us to simplify
the internal low-level implementation without chaning the driver visible
API.

Change-Id: I9a847e30f345bf5e69fded1747ff79057750fb66
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 553ac78877242b6d8b591323731df304140d0f99
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
mm: dma_cache operations for non linearly mapped buffers

dma_cache_*_ops() perform cache maintenance operations on linearly and
non-linearly mapped buffers.

Signed-off-by: Abhijeet Dharmapurikar <adharmap@quicinc.com>
(cherry picked from commit 0732f4d296179ccb5d17d9087e5a91b6046f1862)

Conflicts:

	arch/arm/mm/dma-mapping.c

Change-Id: Ia17993ebd2fcd116b64b070fbdef8b2af2708d19
ARM: dma-mapping: use asm-generic/dma-mapping-common.h

This patch modifies dma-mapping implementation on ARM architecture to
use common dma_map_ops structure and asm-generic/dma-mapping-common.h
helpers.

Change-Id: I574a3b5ac883cd5d9beb79deef8f5cb44fd83296
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
[lauraa: conflicts due to code cruft/context changes]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 2dc6a016bbedf18f18ad73997e5338307d6dbde9

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: implement dma sg methods on top of any generic dma ops

This patch converts all dma_sg methods to be generic (independent of the
current DMA mapping implementation for ARM architecture). All dma sg
operations are now implemented on top of respective
dma_map_page/dma_sync_single_for* operations from dma_map_ops structure.

Before this patch there were custom methods for all scatter/gather
related operations. They iterated over the whole scatter list and called
cache related operations directly (which in turn checked if we use dma
bounce code or not and called respective version). This patch changes
them not to use such shortcut. Instead it provides similar loop over
scatter list and calls methods from the device's dma_map_ops structure.
This enables us to use device dependent implementations of cache related
operations (direct linear or dma bounce) depending on the provided
dma_map_ops structure.

Change-Id: Icbd72d1e4fed6d7478b98bb4ead120c02dd26588
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 2a550e73d3e5f040a3e8eb733c942ab352eafb36
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
dma: barrier api for coherent memory before and after dma

Coherent memory in ARMv6+ could be StronglyOrdered or Normal. On ARMv7
StronglyOrdered guarantees program order execution only within 1KB and
Normal memory could have speculative fetches on them. Hence we need
barrier operations before and after dma for coherent memory.

Signed-off-by: Abhijeet Dharmapurikar <adharmap@quicinc.com>
Change-Id: I33a5f37af7114a7bf13d6b6706c4eca1340b5e41
(cherry picked from commit 32d12f613584053674ed6064a98aa2515aece9a0)
ARM: dma-mapping: move all dma bounce code to separate dma ops structure

This patch removes dma bounce hooks from the common dma mapping
implementation on ARM architecture and creates a separate set of
dma_map_ops for dma bounce devices.

Change-Id: I42d7869b4f74ffa5f36a4a7526bc0c55aaf6bab7
[lauraa: conflicts due to code cruft]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 15237e1f505b3e5c2276f240b01cd2133e110cbc

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: remove redundant code and do the cleanup

This patch just performs a global cleanup in DMA mapping implementation
for ARM architecture. Some of the tiny helper functions have been moved
to the caller code, some have been merged together.

Change-Id: I60b3450bd1180ea007e7326a63762d3a44b3c25d
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 51fde3499b531d4cf278f4d2eaa6c45b2865b16b
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
arm: dma-mapping: Add APIs for other memory types

Currently, the only attributes supported for DMA memory are
writecombine and coherent. Both of these allow speculative
prefetches to occur. For certain use cases (e.g. content
protection) there are requirements to disallow prefetching.
Relatedly, there may be cases where buffering is not enough
for high performance use cases and the full cache should
be used. Add appropriate APIs for the strongly ordered and
cached memory types for the needed use cases.

Change-Id: Ibe17b3d002f9615e2cb34183f47f6d1bcd045611
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: dma-mapping: use alloc, mmap, free from dma_ops

This patch converts dma_alloc/free/mmap_{coherent,writecombine}
functions to use generic alloc/free/mmap methods from dma_map_ops
structure. A new DMA_ATTR_WRITE_COMBINE DMA attribute have been
introduced to implement writecombine methods.

Change-Id: I2709e3ffc97546df2f505d555b29c3bb8148daec
[lauraa: context conflicts]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: f99d60341238fe73fc514129cd9ae4e44e1b2c47

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: add support for IOMMU mapper

This patch add a complete implementation of DMA-mapping API for
devices which have IOMMU support.

This implementation tries to optimize dma address space usage by remapping
all possible physical memory chunks into a single dma address space chunk.

DMA address space is managed on top of the bitmap stored in the
dma_iommu_mapping structure stored in device->archdata. Platform setup
code has to initialize parameters of the dma address space (base address,
size, allocation precision order) with arm_iommu_create_mapping() function.
To reduce the size of the bitmap, all allocations are aligned to the
specified order of base 4 KiB pages.

dma_alloc_* functions allocate physical memory in chunks, each with
alloc_pages() function to avoid failing if the physical memory gets
fragmented. In worst case the allocated buffer is composed of 4 KiB page
chunks.

dma_map_sg() function minimizes the total number of dma address space
chunks by merging of physical memory chunks into one larger dma address
space chunk. If requested chunk (scatter list entry) boundaries
match physical page boundaries, most calls to dma_map_sg() requests will
result in creating only one chunk in dma address space.

dma_map_page() simply creates a mapping for the given page(s) in the dma
address space.

All dma functions also perform required cache operation like their
counterparts from the arm linear physical memory mapping version.

This patch contains code and fixes kindly provided by:
- Krishna Reddy <vdumpa@nvidia.com>,
- Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
- Hiroshi DOYU <hdoyu@nvidia.com>

Change-Id: I4a9b155bef4d5f2b8a8dfe87751d82960b09b253
[lauraa: context conflicts]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-By: Subash Patel <subash.ramaswamy@linaro.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 4ce63fcd919c32d22528e54dcd89506962933719

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: use PMD size for section unmap

The dma_contiguous_remap() function clears existing section maps using
the wrong size (PGDIR_SIZE instead of PMD_SIZE).  This is a bug which
does not affect non-LPAE systems, where PGDIR_SIZE and PMD_SIZE are the same.
On LPAE systems, however, this bug causes the kernel to hang at this point.

This fix has been tested on both LPAE and non-LPAE kernel builds.

Change-Id: I63650057864907f1a2d8eed7257665cb2f648bbb
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 61f6c7a47a2f84b7ba4b65240ffe9247df772b06
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: Add missing static storage class specifier

Fixes the following sparse warnings:
arch/arm/mm/dma-mapping.c:231:15: warning: symbol 'consistent_base' was not
declared. Should it be static?
arch/arm/mm/dma-mapping.c:326:8: warning: symbol 'coherent_pool_size' was not
declared. Should it be static?

Change-Id: I90e2ccdc4d132a37ebcd8ae7a8441ad3fede55bf
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 593f47355467b9ef44293698817e2bdb347e2d11
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: dma-mapping: fix buffer chunk allocation order

IOMMU-aware dma_alloc_attrs() implementation allocates buffers in
power-of-two chunks to improve performance and take advantage of large
page mappings provided by some IOMMU hardware. However current code, due
to a subtle bug, allocated those chunks in the smallest-to-largest
order, what completely killed all the advantages of using larger than
page chunks. If a 4KiB chunk has been mapped as a first chunk, the
consecutive chunks are not aligned correctly to the power-of-two which
match their size and IOMMU drivers were not able to use internal
mappings of size other than the 4KiB (largest common denominator of
alignment and chunk size).

This patch fixes this issue by changing to the correct largest-to-smallest
chunk size allocation sequence.

Change-Id: I5cc9c12322e832951faf3bba6387946c890e0ed4
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Patch-mainline: v3.5
Git-commit: 593f47355467b9ef44293698817e2bdb347e2d11
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>