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>
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>
Debugfs is used for bringup support and debug. Ignore debugfs
setup failure if it is not supported in kernel config.
Change-Id: I07a56a0ce4adf53e0aa5b00ce73310d0c7ed2f6a
Signed-off-by: Manikandan Mohan <manikand@codeaurora.org>
Use Vmax from play effect in haptics_set_gain() only if the effect
is valid. Otherwise, use Vmax from the haptics configuration instead.
Change-Id: I7ec0f8c869096bccb26f7fda0057e3db3a51225d
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Debugfs support for loopback is obsolete. This is
not supported on current or future platforms.
Remove it from debugfs to prevent any security issues
as it allows to access DDR.
Change-Id: I499588e9e28430c4358d2d8e2364430c1acab82e
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
ignore lahaina-qgki-consolidate_defconfig file generated
by GKI scripts as this file auto-generated at build time.
Change-Id: I3edbbbf90b581642da81993a49fdc5264a4324a3
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
consolidate fragment contains the all the debug features
on top of qgki fragment for regular debugging and debug
fragment contains memory debug features. Add support for
fragement merging support in the both generate_defconfig.sh
and fragement_menuconfig.sh scripts.
Change-Id: Iea90997eca060fdf86cd9da08106e7cf11460b21
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
Add initial consolidate defconfig fragment for the lahaina SoC.
Consolidate fragement contains all debug features needed on
top of lahaina_QGKI.config fragement and these flags should not
show significant performance impact. lahaina_debug.config fragment
contains memory debug features, which shows the performance
impact. This enables intenal testing to use the images based on
lahaina-qgki-consoldiate_defconfig defconfig instead of
lahaina-qgki_defconfig defconfig.
Change-Id: I3982e84dbe77abaf3afd741426f6f74ab2db1544
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Enable IFPC in A660 target features. IFPC stands for
Inter-Frame Power Collapse which is power saving feature.
Change-Id: I13ec90a09df5e974ff2f4c7e989cc49c6f8082f8
Signed-off-by: Nitheesh Muthuraj <nmuthuraj@codeaurora.org>
Add support to assign static GPII0 for I2C LA Touch usecase on Lahaina.
Change-Id: Ib0ea811626796825e280bf77f04ef68ab5f833a8
Signed-off-by: Vipin Deep Kaur <vkaur@codeaurora.org>
Certain configs that are enabled in genericarmv8-64 are not
required for the usecases that the kernel is supposed to cater.
For example, IOMMU support is not required for genericarmv8-64,
yet, the drivers for it are built into the kernel image. This
leads to a bloated kernel image with a larger memory footprint,
as well as larger runtime memory footprint, as certain drivers
may allocate data structures that go by unused. Remove certain
extraneous configs.
Change-Id: Iefe8dd2a35a4a29ed97338ec5fea5c147da14eda
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Ftracing has been seen to take up a lot of memory (~16 MB).
On certain environments where the amount of memory is scarce,
this is not ideal as it can contribute to memory pressure,
so disable it for genericarmv8-64 for the time being.
Change-Id: I9a8cc66e70caadc53a5cf63a39842c9548fddf25
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
