Ensure that only allocations which include __GFP_OFFLINABLE can be
satisfied from zone Movable. This restriction helps reduces the
likelihood of a page in the movable zone being pinned which would prevent
memory from being offlined.
In the past we allowed all __GFP_CMA allocations to be satisfied from
Movable zone but now add support to differentiate between __GFP_CMA
allocations and __GFP_OFFLINABLE allocations so that we can target certain
allocations at CMA regions and certain allocations at the Movable zone.
Change-Id: If2a9381b6d677f825ad53af9cd64f206d41da211
Signed-off-by: Liam Mark <lmark@codeaurora.org>
For voice usecases, while opening the slimbus
slave ports, currently data format LPCM(1) is used.
SB master uses data format as unspecified(0). SB master's
data format overwrites the slave side configuration.
In the rare cases, this mismatch may lead to pop sound
in SCO Tx(BT FW->LPASS) at the very beginning when
voice is switched from speaker/handset to BT from call UI.
To fix this, use the data format as unspecified during
opening of the slimbus slave ports for voice cases.
CRs-Fixed: 2710472
Change-Id: Ia9b1d23cbf04d1b8056d7b7f7c84a066437e1682
Signed-off-by: Satish Kodishala <skodisha@codeaurora.org>
AB voting is done in multiples of BW_STEP. Using a big
BW_STEP can result in AB overvoting because of roundup.
Use BW_STEP as 50 instead of 160. This will reduce AB
overvoting and will improve power.
Change-Id: Ieff338685be9650218fd7accc4ed3bcf0d2756ec
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
Add support for the non-secure CMA heap for sharing display
configuration information with display hardware.
Change-Id: Idcc1a8233872cffe890ccd74c956bc666c34cd82
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Supplier virtual machines (VMs) support exporting dma-bufs to
a consumer VM. However, consumers do not support importing dma-bufs
into their VMs, so add an IOCTL command to import a dma-buf into
a consumer VM.
The client must provide a memory parcel handle that corresponds to a
dma-buf that has been shared with the consumer VM, as well as an
access control list that is used for validating the access control
rules for the buffer. Upon success, the client is given a dma-buf
fd, which they can use to map the buffer and access it from both
the CPU, and peripherals.
Change-Id: I548e004e73543421b932430fbd9f84ad76658ef8
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Memory that goes through mem-buf is always transferred back to
the owner when the owner invokes hyp_assign() to regain access to
the memory. This means that if the owner did not have access to
the memory throughout the time the memory was lent to another VMID,
hyp_assign() will clear the memory before returning it to the owner.
Memory that is hyp_assigned through mem-buf creates a memparcel in the
resource manager(RM), when the memory is lent to another VMID, and
destroys the memparcel when the memory is reclaimed by the owner.
However, during the reclaim step, hyp_assign() is used, which clears the
memory, but the RM is unaware of the hyp_assign() policies, so it will
only clear the memory if the VM that released the memory asked for it
to be cleared, which is what mem-buf does. This results in clearing
a memory region twice, which is sub-optimal, so remove the explicit
request to sanitize the memory when the mem-buf driver releases a
memparcel.
Change-Id: I637f2305bf34d839db4f15f152b0bfcbb7b7052e
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
