km: disable active power management
Change-Id: Ice8dbd675dbe3e2adf1f9bdff063932c3e2e5f54
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Change-Id: Ice8dbd675dbe3e2adf1f9bdff063932c3e2e5f54
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
km: Coverity defect fix for RESOURCE_LEAK in error handling
* When buffer_manager.c invokes the MMU_Initialise,
it passes the 2nd parameter in the MMU_Initialise
(&pBMContext->psMMUContext)
* Within the MMU_Initialise, 2nd parameter is MMU_CONTEXT
**ppsMMUContext, and never be used.
* A local variable MMU_CONTEXT *psMMUContext is what got
the allocated pointer.
* Subsequently after this the next error return
PVRSRV_ERROR_FAILED_TO_ALLOC_PAGES, the psMMUContext
is not assigned to ppsMMUContext, until later in the function.
* So psMMUContext variable is out of scope resulting in a leak
And getting back to BM_DestroyContextCallBack, and MMU_Finalise,
it will not free the pointer in question.
IMG Ticket reference: 99482
Change-Id: Iccab33a63a608ae7924411cd16ec3b0934e0b749
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
* When buffer_manager.c invokes the MMU_Initialise,
it passes the 2nd parameter in the MMU_Initialise
(&pBMContext->psMMUContext)
* Within the MMU_Initialise, 2nd parameter is MMU_CONTEXT
**ppsMMUContext, and never be used.
* A local variable MMU_CONTEXT *psMMUContext is what got
the allocated pointer.
* Subsequently after this the next error return
PVRSRV_ERROR_FAILED_TO_ALLOC_PAGES, the psMMUContext
is not assigned to ppsMMUContext, until later in the function.
* So psMMUContext variable is out of scope resulting in a leak
And getting back to BM_DestroyContextCallBack, and MMU_Finalise,
it will not free the pointer in question.
IMG Ticket reference: 99482
Change-Id: Iccab33a63a608ae7924411cd16ec3b0934e0b749
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
km: Handle scenarios for kmalloc failure
There are a few instances of kmalloc calls that are not checking
for the NULL return value. Looking at some of the recent logs,
this situation is likely in Low Memory cases. This patch
addresses those scenarios
Change-Id: I96e4f5192b93cf80a17c6880d2e5b68fc3149a64
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
There are a few instances of kmalloc calls that are not checking
for the NULL return value. Looking at some of the recent logs,
this situation is likely in Low Memory cases. This patch
addresses those scenarios
Change-Id: I96e4f5192b93cf80a17c6880d2e5b68fc3149a64
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
km: Coverity defect fix for RESOURCE_LEAK
There is a RESOURCE_LEAK where in the variable "pages" is going out of scope
and leaks storage pointing to it.
Change-Id: Idfed645a5261aed24d1a1c26cebae6b331b21f3a
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
There is a RESOURCE_LEAK where in the variable "pages" is going out of scope
and leaks storage pointing to it.
Change-Id: Idfed645a5261aed24d1a1c26cebae6b331b21f3a
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
km: fix use of freed gem object in UnwrapExtMemoryCallBack()
UnwrapExtMemoryCallBack() first frees the drm_gem_object via
FreeMemCallBackCommon(), and then continues using the drm_gem_object by
calling omap_gem_put_paddr(). This leads to omap_gem_put_paddr()
accessing freed memory.
Change the call order to first call omap_gem_put_paddr() and only then
call FreeMemCallBackCommon().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
UnwrapExtMemoryCallBack() first frees the drm_gem_object via
FreeMemCallBackCommon(), and then continues using the drm_gem_object by
calling omap_gem_put_paddr(). This leads to omap_gem_put_paddr()
accessing freed memory.
Change the call order to first call omap_gem_put_paddr() and only then
call FreeMemCallBackCommon().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
km: Disable debug options in the release build
Change-Id: I7726cfb4a92568c85054d4ac56ed9c756d469547
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
Change-Id: I7726cfb4a92568c85054d4ac56ed9c756d469547
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
km : handle multiple GEM handle per memarea
When ImportGEM is called from multiple applications, more
than one GEM handle is created per LinuxMemArea.
It is necessary that all the handles are stored and freed up
when the GEM is unmapped, and map data is released.
Change-Id: I417655470764ebe63b8e2c2db10bbc14d317e49b
Signed-off-by: Subhajit Paul <a0132170@ti.com>
When ImportGEM is called from multiple applications, more
than one GEM handle is created per LinuxMemArea.
It is necessary that all the handles are stored and freed up
when the GEM is unmapped, and map data is released.
Change-Id: I417655470764ebe63b8e2c2db10bbc14d317e49b
Signed-off-by: Subhajit Paul <a0132170@ti.com>
km: fix mutex lock during SGX H/W recovery with lockdep enabled
Change-Id: If9eb390d9b2df85295c60fcbff109c85a8ef0886
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
Change-Id: If9eb390d9b2df85295c60fcbff109c85a8ef0886
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
km: fix recursive mutex lock problem when debug options are enabled
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
km: enable traces when the SGX recovers from error
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
km: close GEM vm using DRM API.
It is cleaner to use drm API drm_vm_close as it serves
both the purposes of unreferencing and closing the vm_area
for this GEM object.
Change-Id: I0dd1d16877d6c911fad47ff2317581a59a9ba8a6
Signed-off-by: Subhajit Paul <a0132170@ti.com>
It is cleaner to use drm API drm_vm_close as it serves
both the purposes of unreferencing and closing the vm_area
for this GEM object.
Change-Id: I0dd1d16877d6c911fad47ff2317581a59a9ba8a6
Signed-off-by: Subhajit Paul <a0132170@ti.com>
km: Fix array-OOB issue in create_gem_wrapper
The number of pages allocated at NewAllocPagesLinuxMemArea
[eurasia_km/services4/srvkm/env/linux/mm.c] is stored in
psLinuxMemArea->ui32ByteSize.
However, the number of pages required is not at times the
same as calculated in BM_GetVirtualSize.
Its ok to allocate a bigger array of pages, but let's not
try to access the source array beyond the array bounds.
Signed-off-by: Subhajit Paul <a0132170@ti.com>
The number of pages allocated at NewAllocPagesLinuxMemArea
[eurasia_km/services4/srvkm/env/linux/mm.c] is stored in
psLinuxMemArea->ui32ByteSize.
However, the number of pages required is not at times the
same as calculated in BM_GetVirtualSize.
Its ok to allocate a bigger array of pages, but let's not
try to access the source array beyond the array bounds.
Signed-off-by: Subhajit Paul <a0132170@ti.com>
Truncate the SGX HW recovery traces
SGX HW recovery indicates that GPU has undergone an error in its operations and
has recovered through reset. The traces printed during HW recovery slows down
the system and is required only for in-depth debugging.
By default, disable the dumping of HW recovery traces.
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
SGX HW recovery indicates that GPU has undergone an error in its operations and
has recovered through reset. The traces printed during HW recovery slows down
the system and is required only for in-depth debugging.
By default, disable the dumping of HW recovery traces.
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Enable voluntary kernel preemption option in the SGX driver
SGX driver uses work queues which requires full kernel preemption. Allow SGX
driver to be built with voluntary kernel preemption.
Note that kernel scheduling with voluntary preemption is substantially
different from full kernel preemption. Selection of preemption mode must be
done by the system integrator based on the required use cases.
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
SGX driver uses work queues which requires full kernel preemption. Allow SGX
driver to be built with voluntary kernel preemption.
Note that kernel scheduling with voluntary preemption is substantially
different from full kernel preemption. Selection of preemption mode must be
done by the system integrator based on the required use cases.
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
km: fix GEM handle memory leak
When memory handles are mapped, a dummy GEM handle is created so that it can be
accepted by DRM. However, when the memory handle is unmaped, there is no
corresponding delete of the GEM handle.
Given that each GEM handle is 4K bytes, this will result in a memory leak that
will result in application crash over time. This is not catastrophic to the
system since DRM/GEM core will cleanup the GEM handles allocated as part of the
proces when it exit.
This patch addresses the GEM handle leak in SGX driver.
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
When memory handles are mapped, a dummy GEM handle is created so that it can be
accepted by DRM. However, when the memory handle is unmaped, there is no
corresponding delete of the GEM handle.
Given that each GEM handle is 4K bytes, this will result in a memory leak that
will result in application crash over time. This is not catastrophic to the
system since DRM/GEM core will cleanup the GEM handles allocated as part of the
proces when it exit.
This patch addresses the GEM handle leak in SGX driver.
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
km: removed extra character from trace message
This string concatenation caused compilation errors when trace was enabled.
Change-Id: I1de6870a22fe223496483e3e8b7281cf1dbeb7a2
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
This string concatenation caused compilation errors when trace was enabled.
Change-Id: I1de6870a22fe223496483e3e8b7281cf1dbeb7a2
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
K3.14: Changed compatibility to omap4-gpu as per the new DT
Change-Id: If81be34700c99ce938eb9ad4c440b075403bfd4c
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Change-Id: If81be34700c99ce938eb9ad4c440b075403bfd4c
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Use omap_gem APIs for accessing private data
The current code accesses the private buffer from DRM object directly. Instead,
use the APIs defined in omap_gem to access the private data.
Change-Id: Ibd6c0bd9c4dfe7df4926e55ca0f28b917cbc262d
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
The current code accesses the private buffer from DRM object directly. Instead,
use the APIs defined in omap_gem to access the private data.
Change-Id: Ibd6c0bd9c4dfe7df4926e55ca0f28b917cbc262d
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
K3.14: API changes for ioremap
ioremap_cached is redefined as ioremap_cache in k3.14
Change-Id: Ie539ef5da4109e1bd2d5cc589c026d833858c849
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
ioremap_cached is redefined as ioremap_cache in k3.14
Change-Id: Ie539ef5da4109e1bd2d5cc589c026d833858c849
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Revert "Add support for a segmented register memory map for SGX"
This reverts commit 70bbb856e74feba2007ba0645ca975730afc9bd6.
Anand: K3.14 DTS file has the SGX register map defined as a single continuous
region. For K3.8/K3.12, the register map was broken down for individual
submodules of SGX
This reverts commit 70bbb856e74feba2007ba0645ca975730afc9bd6.
Anand: K3.14 DTS file has the SGX register map defined as a single continuous
region. For K3.8/K3.12, the register map was broken down for individual
submodules of SGX
K3.12 mmap support for sync data
mmap support by creating in-kernel private handles was
incorporated in a previous patch. However, handles were
created only for memory allocated inside the mmap function.
If the mmap request is made on an existing memory, create a
handle as well.
Change-Id: I3a44db65700bc0f8e08ddc438d305bf2911817fb
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
mmap support by creating in-kernel private handles was
incorporated in a previous patch. However, handles were
created only for memory allocated inside the mmap function.
If the mmap request is made on an existing memory, create a
handle as well.
Change-Id: I3a44db65700bc0f8e08ddc438d305bf2911817fb
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
K3.12 create a dummy gem handle for every gem allocation
K3.12 GEM vma features ensure that mmap on a gem is called
only if a handle is created for it. This serves the purpose
of authentication.
Since SGX creates GEM areas in KM using omap_gem_new_ext and
therefore no handles are created, mmap fails.
Lets just create a dummy handle for each gem object. Dont
bother to free it. drm_release will take care if it.
Change-Id: I2415a9a8aaf4001e558b824821a05904a2934005
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
K3.12 GEM vma features ensure that mmap on a gem is called
only if a handle is created for it. This serves the purpose
of authentication.
Since SGX creates GEM areas in KM using omap_gem_new_ext and
therefore no handles are created, mmap fails.
Lets just create a dummy handle for each gem object. Dont
bother to free it. drm_release will take care if it.
Change-Id: I2415a9a8aaf4001e558b824821a05904a2934005
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
K3.12 fix for SGX modifying return value after gem_new
SGX modifies the value of buffer size after gem is created
to align it to page size. In 3.12 kernel, if gem allocation
size and vaddr start and end do not match, a mmap cannot
be done.
So why not determine how much will be the return size and
allocate a big enough gem area. Makes both parties happy.
Change-Id: I5fb99d7a479f53048ddb77bda001bf516bec5d06
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
SGX modifies the value of buffer size after gem is created
to align it to page size. In 3.12 kernel, if gem allocation
size and vaddr start and end do not match, a mmap cannot
be done.
So why not determine how much will be the return size and
allocate a big enough gem area. Makes both parties happy.
Change-Id: I5fb99d7a479f53048ddb77bda001bf516bec5d06
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
K3.12 update DRM_IOCTLs to reflect argument size
In the 3.12 kernel, the ioctls expect the argument size
to be present in the ioctl definition.
Change-Id: I74d0d3ecb4207f17031d5bb0636513affc036803
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
In the 3.12 kernel, the ioctls expect the argument size
to be present in the ioctl definition.
Change-Id: I74d0d3ecb4207f17031d5bb0636513affc036803
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
K3.12: Disable the warning for missing prototypes
* In K3.12, missing-prototypes warning causes compilation errors for NOP cache
* operations.
* Disable this warning
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
* In K3.12, missing-prototypes warning causes compilation errors for NOP cache
* operations.
* Disable this warning
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
K3.12: Update the driver for changes in ProcFS APIs
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Changed the DT compatibility to omap5 instead of omap4
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
memory leak fix for external GEM buffers
The drm_gem_objects mmaped should be dereferenced by the
respective vm_close function.
Since the DRM GEM core is not responsible for freeing up any
memory attached to the external GEM buffers, the pages array
needs to be freed up in the PVR core, after the GEM object
has been released.
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
The drm_gem_objects mmaped should be dereferenced by the
respective vm_close function.
Since the DRM GEM core is not responsible for freeing up any
memory attached to the external GEM buffers, the pages array
needs to be freed up in the PVR core, after the GEM object
has been released.
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
DDK changes for GLSDK 6.02
* Add the paths for omapdrm header files in Kbuild
* Add support for a segmented register memory map for SGX
* Change the module from platform driver model to DT model
Signed-off by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
* Add the paths for omapdrm header files in Kbuild
* Add support for a segmented register memory map for SGX
* Change the module from platform driver model to DT model
Signed-off by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Reversing the K3.8 patch
* this commit has gone through review comments and needs to be updated
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
* this commit has gone through review comments and needs to be updated
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Updated README with build instructions and version information
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Merge branch 'master' of git.ti.com:graphics/omap5-sgx-ddk-linux
Added an eurasia_km directory to maintain the directory structure
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
porting to Linux-3.8.y
Linux upstream has stopped supporting platform data
In this case, the platform driver calls probe if a
compatible platform driver is found.
This patch modifies the driver to be based entirely
on DT.
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Linux upstream has stopped supporting platform data
In this case, the platform driver calls probe if a
compatible platform driver is found.
This patch modifies the driver to be based entirely
on DT.
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Installation for kernel modules
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Ensure that Linux kernel has been built with preemptible kernel
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Updated readme to reflect OMAP5 build steps
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Added a git ignore
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
DDK 1.9 kernel module
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>