msm: display: Add pipe type selection in overlay request

Allow user to specify the type when requesting an overlay pipe.
If field is set the pipe type indication in the flags will be
ignored.
Change-Id: Iee51d24b96c7a2a987dc70a439342e6548dfc8fa
Signed-off-by: Vineet Bajaj <vbajaj@codeaurora.org>
iommu: msm: always use 32-bit physical addresses

TZ expects the physical address of the destination dump buffer to be
32-bits, even on LPAE targets. Always send a 32-bit integer. This
requires truncating the top 4 bytes of a 64-bit physical address, but
this shouldn't be a problem on current targets since all physical
addresses should be <4GB.

Change-Id: I486ed39e132be46ebfc80335024cb8d31d7ac1c2
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
ion: chunk_heap: fix leak in allocated counter

buffer->size is controlled by the outer ion layer, don't modify it
inside the heap.  Instead, compute the rounded up allocated size
on demand.

Change-Id: I288ffc1221ce96cfe2591468502ac3279065bde4
Signed-off-by: Colin Cross <ccross@android.com>
Git-commit: f526a55b400d166dafc6062e5818a2410555ef39
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: mdss: Allocate fb memory under 4GB physical address space

Linux kernel framework of framebuffer APIs do not support LPAE systems.
These APIs are using "unsigned long" data type instead of "phys_addr_t"
for physical addresses which doesn't work with LPAE systems. Until
framebuffer APIs are fixed, allocate fb memory on MSM chip-sets using
dma_alloc_coherent and GFP_KERNEL to get the memory from below 4GB
physical address space.

Conflicts:
	Documentation/devicetree/bindings/fb/mdss-mdp.txt

Change-Id: Ieca41cae21c956a8b4cf1d5729d287bb0bb30f8d
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>

Conflicts:
	arch/arm/boot/dts/msm8974-mdss.dtsi
mm/compaction: Break out of loop on !PageBuddy in isolate_freepages_block

We received several reports of bad page state when freeing CMA pages
previously allocated with alloc_contig_range:

 BUG: Bad page state in process Binder_A  pfn:63202
 page:d21130b0 count:0 mapcount:1 mapping:  (null) index:0x7dfbf
 page flags: 0x40080068(uptodate|lru|active|swapbacked)

Based on the page state, it looks like the page was still in use. The page
flags do not make sense for the use case though. Further debugging showed
that despite alloc_contig_range returning success, at least one page in the
range still remained in the buddy allocator.

There is an issue with isolate_freepages_block. In strict mode (which CMA
uses), if any pages in the range cannot be isolated,
isolate_freepages_block should return failure 0. The current check keeps
track of the total number of isolated pages and compares against the size
of the range:

        if (strict && nr_strict_required > total_isolated)
                total_isolated = 0;

After taking the zone lock, if one of the pages in the range is not
in the buddy allocator, we continue through the loop and do not
increment total_isolated. If in the last iteration of the loop we isolate
more than one page (e.g. last page needed is a higher order page), the
check for total_isolated may pass and we fail to detect that a page was
skipped. The fix is to bail out if the loop immediately if we are in
strict mode. There's no benfit to continuing anyway since we need all
pages to be isolated. Additionally, drop the error checking based on
nr_strict_required and just check the pfn ranges. This matches with
what isolate_freepages_range does.

Change-Id: I2a8bc4d381ae35aa15a4d2a2424f0c2de801d9ba
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

Conflicts:
	mm/compaction.c
iommu: msm: Use dma memory for secure pagetable

Linux allocates memory for secure page tables which is passed to the secure
world. This memory is later protected from reads/writes from Linux. Using
kmalloc for this memory may allow speculative accesses to occur to
secured memory. Avoid speculative faults by using dma_alloc_coherent
with the NO_KERNEL_MAPPING attribute to avoid a non-secure mapping.

Change-Id: I3fcd82b2a1e5b82442641961c70306560ee778d8
CRs-Fixed: 621723
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

Conflicts:
	drivers/iommu/msm_iommu_sec.c