gpu: ion: Request highmem pages for IOMMU heap

When allocating pages for IOMMU heap it is advantageous
to try to allocate pages from highmem in addition to
lowmem since clients using the IOMMU heap can use
either highmem or lowmem.

CRs-fixed: 430457
Change-Id: Ifc794fc344c67dd53d8f7cebf86536ab9d44ed6c
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: Use writecombine for uncached mappings

When we map ion buffers as uncached we want to map them as
uncached but still be able to use buffering of transactions
since turning off buffering has a severe performance impact.

Change-Id: I5a09ac34bd3ce3f001d10d9efd71d140f632564d
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: replace __GFP_ZERO with manual zero'ing

As a performance optimization, omit the __GFP_ZERO flag when
allocating individual pages and, instead, zero out all of the pages in
one fell swoop.

CRs-Fixed: 449035
Change-Id: Ieb9a895d8792727a8a40b1e27cb1bbeae098f581
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: allocate huge pages in iommu heap

As a performance optimization, use higher-order page allocations if
possible. This can reduce TLB misses and the total number of page
structures.

CRs-Fixed: 449035
Change-Id: I6b76ec69599a100fd7209161c4286284ae347be0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: handle allocation error during heap protection in CP heap

Return error and do not increment ref count in case of failure to
protect the CP heap.
CRs-Fixed: 445400

Change-Id: Ia615773fe2c52386d9522de7a182edd633a66e1c
Signed-off-by: Praveen Chavan <pchava@codeaurora.org>
gpu: ion: suppress excessive logging for expected failure cases

We expect alloc_pages to fail for high-order pages under stressed
memory conditions. It should then fall back to lower-order page
allocations but due to excessive logging the system crashes. Use
__GFP_NOWARN for high-order allocations to avoid excessive logging.

(cherry picked from commit ff6ea62fe0687e754ddb64492e77fd75ad85fa02)

CRs-Fixed: 454877
Change-Id: Ie18c2dddd6810038abad9b06c7838ff4a0844b6d
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: Align va address to biggest buffer size

Align the virtual address to the max buffer size to
allow IOMMU mappings at the biggest buffer size.

Change-Id: I74ba665c1782e2f0631274766c5caeeb192224e0
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: Minimize allocation fallback delay

When we allocate from iommu heap we first try to allocate 1M pages. If
that fails we try 64K pages, which falls back to 4K pages. However,
we don't want to incur too much overhead when allocating with fallbacks
so we don't want the higher order page allocation to retry, perform
reclaim, or run memory compaction.

Configure the GFP flags to ensure that when we allocate pages greater
than order 0 we don't try to do any retries, reclaim, access emergency
pools, or run memory compaction. This will ensure lower memory allocation
latency for applications.

CRs-Fixed: 470389
Change-Id: Ibb3483dddbedbc733a1f7968821e7bc47bedffcd
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: enable the kmalloc heap

There are some Ion clients who would like to use the kmalloc
heap. Enable it.

Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: Add support for ION Flushing without virtual address

Video has very large buffers to be flushed. Due to lack of
vmalloc space, ion_map_kernel cannot be called on each of
the video buffers. With this change the ion handle can be
flushed without the need of the kernel mapping.

Change-Id: If026f21e44a2cce6c2b8c232fc80a69d0dabcd14
Signed-off-by: Neeti Desai <neetid@codeaurora.org>

Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
gpu: ion: Use correct type for variables

Use correct type for variables to prevent overflow of signed
type when assiging from an unsigned type.

Change-Id: I0055d35c7310d111de590db3798950fd98f1b298
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: Do fallback when allocating large sizes

The preferred allocation of memory for kernel data structures in
ION is to use kmalloc. This is mainly for performance reasons. However,
we are not guaranteed to be able to allocate large sizes. So to keep
the code performing well and at the same time allow for larger allocations,
implement a fallback mechanism for allocation of memory for ION kernel data
structures.

CRs-Fixed: 488521
Change-Id: I8c6a13ad74cce69f590920d28c01a58f7a540fd2
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[Resolved merge conflict]
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>

Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
gpu: ion: Free the sgtable for CMA based heaps

When an sgtable is allocated with sg_alloc_table, the table needs
to be destroyed in addition to being freed. Destroy the sgtable
when freeing the associated memory.

Change-Id: Iedba81146ba453070790f071848f86826f7eec9c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Merge branch 'kk-ion' into android-msm-3.4-kk