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>
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>
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>
Currently, mem-buf suppliers can only provide a consumer with a memory
buffer if the consumer requests for the memory buffer, in which case
the supplier has no control over the contents of the buffer that is
given to the consumer. This is not ideal in cases where the supplier
virtual machine (VM) may have data that is of interest to the consumer,
which can be shared using a memory buffer.
Introduce a new IOCTL command which allows a client to specify a
dma-buf that they would like to share with a consumer VM, as well
as the access control rules that should be applied to the buffer.
Change-Id: I1e4ec1205ad4e69039ec0ab26b4209512896a354
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The current rules for determining if a buffer can or cannot be mapped
to depend on how a buffer was allocated. This is restrictive
in environments where the security state of a buffer can change
dynamically, as the accessibility of the buffer has to change with
respect to the security state of the buffer.
Thus, add support to track the number of userspace mappings associated
with an ION buffer, as well as an interface to allow drivers to lock
and unlock a buffer. In this context, locking a buffer means that the
buffer will no longer be mappable, and the buffer does not
have any outstanding mappings at the time the buffer is locked.
Unlocking the buffer means that the buffer can be mapped again.
Change-Id: I6aa73b9ac7c301b12106ad3d3bcb4c2aac959e55
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The priv_virt field can be useful for storing other meta-data
associated with a buffer besides the pointer to the struct page
associated with the buffer. Additionally, the struct page
pointer can be derived by looking at the sg-list structure for
the buffer. Thus, use the sg-list structure to derive the struct
page pointer for a CMA buffer, instead of the priv_virt field.
Change-Id: I1740ac56c4268ece315144fb2c3d8f48d9608c41
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Certain functions in the mem-buf code assume that they will
operate on a particular type of structure that houses all of
the information that they need. This becomes restrictive
when attempting to use those functions without the housing
data structure. Thus, to improve the modularity of these
functions, change their signatures so that they require
only the necessary pieces of information as inputs.
Change-Id: I93c988f700fed3db5a5ccf8702cb8ac100f8f428
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Add tracepoints for the mem-buf driver to collect a sequence of
events, as well as state to ascertain how much progress the
allocation process makes.
Change-Id: Icc8884d66655e21dd704266e7bc06264858bf527
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
When releasing memory, notify the owner of the memory that it
can be reclaimed only if the recipient VM has successfully
released the memory. There is also no reason to continue
to hold onto the mem-buf descriptor memory if a failure
occurs when relinquishing the memory, so free those structures
as well, independent of the result of the relinquish operation.
While we're here, touch up some of the error logging in the
error paths as well.
Change-Id: I29bb1774507fd75f206c0537b6007182b4d6cb48
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The state of memory--with respect to access control--is unknown
when a hyp_assign() call fails because the underlying SCM call
fails. In these cases, it is not safe to access the memory, so
we should not free it back to the system.
Change-Id: I992225cdd5f26fbba60d2966d051d026326cd593
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The allocation code hot-adds the memory from another VM through
the memory hotplug code to create the S1 CPU MMU mappings. The memory
hotplug code can only add memory at a subsection granule, meaning
that all memory requests must be subsection size aligned. Thus,
enforce all allocation requests to be subsection size aligned.
Change-Id: Ia4d3294e36265f0bd956fa42670f2ac8d6974908
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
EUD HUB functionality is relevant into USB device mode only. Hence when
using USB host mode, continue performing reset and initialization
functionality with HSPHY even though EUD is enable. If EUD is enable
while starting host mode, re-enable EUD whie exiting host mode.
Change-Id: Ifc2a105d8a02511dd2fc58be5fbc788d46546ba0
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Currently usb speed override functionality doesn't work as expected
when usb role switch based notification is used. Hence move usb speed
override functionality out side edev check within dwc3_resume_work()
API. Also update maximum_speed as max hw supported speed out side
edev check.
Change-Id: I69b066721490277b77333d2caf820b6c87703501
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
cpu_isolated_mask can only be used when SCHED_WALT is enabled. The
addition of the cpu_isolated_mask causes ABI to break. Thus, compile
references to cpu_isolated_mask only when SCHED_WALT is enabled.
Change-Id: I0982f6431abca807168dbabc4aca74771819565c
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
The FORCE_MEM_CORE_ON bits default to 0 and this is fine for most use
cases. However, USB needs FORCE_MEM_CORE_ON=1 to properly retain its
memories when USB APM switches from CX to MX. This can't just be a
one-time setting since the FORCE_MEM_CORE_ON bits need to be set/cleared
upon USB cable connect/disconnect for power optimization. Add fake
clocks to allow the USB client to control them.
Change-Id: Ic7aac944feaa6a956a8892e0cf1f4dd465659302
Signed-off-by: Mike Tipton <mdtipton@codeaurora.org>
Add clock bindings to control the USB FORCE_MEM_CORE_ON bits.
Change-Id: I406e98e1be5b4d6702636c3bfdf738ae9ff12198
Signed-off-by: Mike Tipton <mdtipton@codeaurora.org>
