Fix sparse warning:
nvdla.c:40:1: warning: symbol 'attrs' was not declared.
Should it be static?
Bug 200088648
Change-Id: Ic83c46c938fe82d1e8cbdd7c7e2337b39580cc88
Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Reviewed-on: http://git-master/r/1167423
Reviewed-by: Amit Sharma (SW-TEGRA) <amisharma@nvidia.com>
- this adds falcon interrupt support for NvDLA driver.
- Register device for falcon interrupt
- Allocate dump data region and pass dma addr to falcon
after firmware load
- In ISR, read dump data from a allocated dump region and dump
to console
- During engine power off, free dump region
- add dla KMD<->ucode interface header file for cmd communication.
Jira DLA-45
Jira HOSTX-61
Change-Id: I2163c0e50ce8e2231e185d37bcd3ef8e979f7bdf
Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Reviewed-on: http://git-master/r/1160994
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
GVS: Gerrit_Virtual_Submit
- add support to boot falcon through nvhost_nvdla_finalize_poweron() PM API.
- nvhost_nvdla_finalize_poweron() called by nvhost as restore start
dev ops
- nvhost_flcn_finalize_poweron() is API provided by falcon framework to
request firmware, parse ucode and boot falcon.
- Specify firmware name in NvDLA device data, which is required for
request_firmware
- Fix Kconfig to enable TEGRA_GRHOST_NVDLA by default
Jira DLA-16
Change-Id: I14791fc1f97c283ff9e9b1890183033bfc4087aa
Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Reviewed-on: http://git-master/r/1147900
GVS: Gerrit_Virtual_Submit
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
private data element of platform data is set during falcon init time.
So remove setting it probe time.
Jira DLA-33
Change-Id: I9807d4520757e8e708b674a1b8f4f95aa24ad526
Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Reviewed-on: http://git-master/r/1156132
GVS: Gerrit_Virtual_Submit
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
- NvDLA is a fixed function accelerator engine for deep learning in
Tegra. Engine supports various layers such as convolution, fully-connected,
activation, pooling and normalization.
- This patch adds minimal support stub for engine for device
initialization.
Jira DLA-5
Change-Id: Iecdd3963a77a2f20979ae412ff2f9388c57a26b1
Signed-off-by: Shridhar Rasal <srasal@nvidia.com>
Reviewed-on: http://git-master/r/1132605
GVS: Gerrit_Virtual_Submit
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Remove dummy makefile to prepare the nvdla folder
to do driver integrations from kernel/nvidia to
kernel/nvidia-oot.
Bug 4038415
Change-Id: I45d8fffc504ab9530718c1fa4f3960037e909f25
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
When one process is trying to duplicate RO handle while other process is
trying to free the same RO handle, then race can occur and second
process can decrement the dma-buf's refcount and it may reach to 0. The
first process can then call get_dma_buf on it, leading to NULL pointer
dereference and ultimately to kernel panic. Fix this by taking an extra
dma-buf refcount before duplicating the handle and then decrease it once
duplication is completed.
Bug 3991243
Change-Id: I99901ce19d8a5d23c5192cb10a17efd2ebaf9d3a
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2865519
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
When the carveout size is changed to 2GB, mem->size << PAGE_SHIFT will
overflow the int limit and get wrapped to negative value. Hence
during freeing bitmap, one of the comparison condition is not meeting,
resulting into not freeing bitmap. Ultimately the entire bitmap get
consumed even though it is expected to have empty bits. Fix this by
typecasting the size to u64.
Bug 3962552
Change-Id: Ieaf93a3a91062d3f630921259aa9b3935853e91c
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2861614
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
There is a potential data race for RO dma-buf in the following scenario:
------------------------------------------------------------------
Process 1 | Process 2 | Process 3 |
------------------------------------------------------------------|
AllocAttr handle H1 | | |
MemMap (H1) | | |
AllocAttr(H2) | | |
MemMap(H2) | | |
id1 = GetSciIpcId(H1)| | |
id2 = GetSciIpcId(H2)|H3=HandleFromSciIpcId | |
id3 = GetSciIpcId(H1)| (id1, RO) |H4=HandleFromSciIpcId|
MemUnmap(H2) |QueryHandlePararms(H3)|(id2, RO) |
MemUnmap(H1) |MemMap(H3) |QueryHandleParams(H4)|
HandleFree(H2) |MemUnmap(H3) |MemMap(H4) |
HandleFree(H1) |HandleFree(H3) |H5=HandleFromSciIpcId|
| |(id3, RO) |
| |QueryHandleParams(H5)|
| |MemMap(H5) |
| |MemUnmap(H4) |
| |MemUnmap(H5) |
| |HandleFree(H4) |
| |HandleFree(H5) |
-------------------------------------------------------------------
The race is happening between the HandleFree(H3) in process 2 and
HandleFromSciIpcId(id3, RO) in process 3. Process 2 tries to free the
H3, and function nvmap_free_handle decrements the RO dma-buf's counter,
so that it reaches 0, but nvmap_dmabuf_release is not called immediately
because of which the process 3 get's false value for the following check
if (is_ro && h->dmabuf_ro == NULL)
It results in calling nvmap_duplicate_handle and then meanwhile function
nvmap_dmabuf_release is called and it makes h->dmabuf_ro to NULL. Hence
get_dma_buf fails with null pointer dereference error.
Fix this issue with following approach:
- Before using dmabuf_ro, take the handle->lock, then check if it is not
NULL.
- If not NULL, then call get_file_rcu on the file associated with RO
dma-buf and check return value.
- If return value is false, then dma-buf's ref counter is zero and it is
going away. So wait until dmabuf_ro is set to NULL; and then create a
new dma-buf for RO.
- Otherwise, use the existing RO dma-buf and decrement the refcount
taken with get_file_rcu.
Bug 3741751
Change-Id: I8987efebc476a794b240ca968b7915b4263ba664
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2850394
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
NvMap is using bitmap_allocate_region while doing allocation from IVM
carveout. It expects size to be always power of 2, this is resulting
into memory shortage. Better way to handle this is to use the function
bitmap_find_next_zero_area which expects bitmap size rather than order.
Then use bitmap_set to set the allocated bits from the bitmap.
Similarly, while freeing the buffer, use bitmap_clear instead of
bitmap_release_region.
Bug 3923812
Change-Id: I91005d16f678405f341c4fc620509f56af538e1c
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2839848
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
get_task_struct increment the ref count over task struct, and it will be
decremented as part of put_task_struct. task_struct won't be freed
unless it's refcount becomes 0. Hence the missing put_task_struct in
nvmap code was resulting into kmemleak. Fix it by add this missing call.
Also, mutex_unlock was missing in one of the return path, add it.
Bug 3901618
Change-Id: I630eac19e628a549179a8ddaad86ad4d2c9b9a53
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2837383
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
This patch fixes the following issues:
- When the handle associated with the sub-buffer is freed, the call to
the nvmap_page_pool_fill_lots is made, which would free the pages when
the refcount on the pages is > 1, even though the main handle is not
freed, hence add a check for sub-handle.
- In cpu unmap code, list_for_each_entry is used for iterating over the
vma list and in the same loop list_del is aldo being called, this can
lead to undefined behavior, instead use list_for_each_entry_safe which
is safe against removal of list entry.
- Mutex of sub-handle is not initialized, fix it by initializing it.
- Set error value when handle creation failed.
Bug 3494980
Change-Id: I0659d7f70b44814e87e3081702352e891d9191f7
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2824668
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Some of the libraries may be linked into different namespaces, but they
belong to same process. So each namespace can open the /dev/nvmap node
and call nvmap ioctls, instead of reusing the already opened /dev/nvmap
FD. Because of this, memory handles created by one namespace can't be
used by other namespaces, even though they belong to same process.
Fix this issue by following:
- When /dev/nvmap node is opened, check if there is already any nvmap
client with same pid, if yes use that client; otherwise, create new
nvmap client.
- Track the number of namespaces via count field.
- When /dev/nvmap node is closed, destroy the nvmap client only when
count reaches to 0.
Bug 3689604
Change-Id: I4c91db36b88e78b7526dd63b006e562c8f66c7ae
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2819915
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Ivan Raul Guadarrama <iguadarrama@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
On TOT, in nvmap probe function, platform_set_drvdata is called after
misc register. So nvmap node is created and clients can open it even
before platform driver data is set. Because of which, the call to
dev_get_drvdata returns NULL and BUG_ON condition is hit. Move misc
register call towards end of the nvmap probe, so that /dev/nvmap is
exposed once all initilization is completed.
As misc register being moved to end of probe, the functions which are
called before misc register and which make use of dev_user field from
nvmap_device for calling dev_err/dev_info function will see the dev
field as NULL. Hence replace such calls with pr_err/pr_info.
Bug 3853486
Change-Id: Ifdd8443812a621aceada7739cf9b02fcf00568b4
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2803672
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
On TOT, in case of carveouts, nvmap performs cache flush operation
during carveout creation, buffer allocation and buffer release. Due to
cache flush for entire carveout at creation time, nvmap takes ~430 ms
for probe. This is affecting boot KPIs.
Fix this by performing cache flush only at buffer allocation time,
instead of carveout creation and buffer release. This is reducing nvmap
probe time to ~0.69 ms.
Bug 3821631
Change-Id: I54da7dd179f8d30b8b038daf3eceafb355b2e789
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2802353
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The resume functionality of maxim gmsl dp serializer
driver calls init routine. Function incorrectly treats
register value as return value and shows error message
in logs. Removing return value check from register read
during init fixes this issue.
bug 3955858
Change-Id: Ibe2058a49827bdd802ea4b5f24be986c911450e6
Signed-off-by: prafulls <prafulls@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2851087
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
This change adds GMSL3 support to maxim dp serializer
driver. The property is set in device tree which is if true,
then PAM4 mode is enabled and 12 Gbps link rate is set.
GMSL3 also needs to have FEC enabled. This change also
adds that support.
Device tree need to have "enable-gmsl3" property to be set
to get GMSL3 enabled.
When GMSL3 is enabled, it will enable GMSL-FEC by default.
GMSL-FEC can only be enabled by setting propery "enable-gmsl-fec".
JIRA TDS-10659
Signed-off-by: Prafull Suryawanshi <prafulls@nvidia.com>
Change-Id: I1757f71babbc5135f0ddf3d2a501de721e84da6d
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2831963
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Shu Zhong <shuz@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
