- Query heap functionality belongs to nvmap_alloc unit, as heap is
managed by it. Hence move the function to query the heap to nvmap_alloc
unit.
- Move nvmap_get_user_pages function to nvmap_alloc unit as it is
relevant for nvmap_alloc unit.
- Move nvmap_dma_alloc_attrs/free_attrs functions to nvmap_alloc unit
as they are more relevant for nvmap_alloc unit.
- Move dma_coherent_mem_replica, nvmap_carveout_node structs to
nvmap_alloc unit.
- Cleanup unused macros from nvmap_priv.h
JIRA TMM-5694
Change-Id: I8884831771443de7db0e95c3b2dfc43c03f7c48e
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3214196
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Fix for: Sparse defects
Sparse defect stated that "symbol 'debug_free_size_fops' was not declared. Should it be static?"
-Since carveouts also have free_size debugfs and it is directly using
the field from heap struct.
-So to make free_size_fops static we are changing DEBUGFS_OPEN_FOPS to DEBUGFS_OPEN_FOPS_STATIC
Bug 4513982
Change-Id: I296bf95a421a9c751cc11266a896d2806bfc82b4
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3205061
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
- Files for nvmap_handle unit: nvmap_handle.c, nvmap_sci_ipc.c,
nvmap_id_array.c.
- Define external header for nvmap_handle unit as nvmap_handle.h and
move declarations of all external APIs of nvmap_handle unit to this
header.
- Define internal header for nvmap_handle unit as nvmap_handle_int.h and
move declarations of all internally called APIs to this header.
JIRA TMM-5651
Change-Id: Ie4922c0839070491f9893f23744eb700cabb9828
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3211591
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
nvmap uses pid of group_leader task to indicate a client process. During
create_client operation, whenever any client with the same group_leader
pid already exists in clients list of nvmap_device, then nvmap
increments the count field of nvmap_client struct. Otherwise, create a
new nvmap_client. Both of the operations i.e. checking the list for
client and incrementing the counter happen inside lock. On the other
hand, during nvmap_release, first the counter is decremented and checked
if it's zero or not. If it's zero then the lock is taken and client is
removed from client list of nvmap_device. As both the operations i.e.
decrementing the counter value and removing client from list (if the
counter becomes 0) are not happening inside a lock, it's resulting into
the following data race scenario.
1) nvmap_release on existing client process 1
- decrement client's counter
- counter value has become zero
- client is yet to be removed from the dev->clients list
- context switch happen to __nvmap_create_client as another
namespace/thread with same with same group_leader pid is created.
2) __nvmap_create_client
- as the client with same pid exists in dev->client list, it
increments counter value to 1, instead of creating a new client struct.
- context switch happen to nvmap_release from step 1
3) nvmap_release
- It calls destroy_client and remove the client from dev->client
list.
- Completes rest of the operations in destroy_client and returns.
- Context switch to remaining operations from step 2
4) nvmap_release
- Now, when the nvmap_release will be called for the thread/namespace
which was created in step 2, then list_del operation would fail as the
client struct was already removed from dev->client list.
Fix the above issue by doing both operations i.e. decrementing the
counter value and removing the client struct from dev->client list in a
single lock.
Bug 4829958
Change-Id: I87ebbcb45b18114d0ec75520443bee010f88d59e
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3209794
(cherry picked from commit cc74d1fe1b)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3207520
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
This change includes
1. First version of nvdisp serdes driver.
2. Opcode parsing and implementation as per nvdisp serdes opcode specification.
3. ERRB generic interrupt handler with ERRB specific opcode parsing.
4. Suspend-Resume functionality.
5. Device tree binding documentation.
Verification:
* It is verified with MAX96851 DP serializer on P3710 and P3960.
* GMSL2 and GMSL3, MST like features verified.
* Suspend/Resume functionality verified.
* Internal and Remote video CRC error detection verified.
JIRA TDS-15967
Signed-off-by: prafulls <prafulls@nvidia.com>
Change-Id: I61b9c216b5a7d4bd402dfe55e31f652824c8cc43
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3175316
Reviewed-by: Shu Zhong <shuz@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- Move macro definitions from nvmap_priv.h to nvmap_alloc unit wherever
required.
- Cleanup unnecessary macros.
- Add function to cleanup the memory allocated for debugfs_info for
iovmm. This was missed in the previous patch where the allocation for
debugfs_info is moved to dynamic memory allocation.
- Move nvmap page pool related data structs from nvmap_priv to
nvmap_alloc unit.
JIRA TMM-5621
Change-Id: I3b668b2d6182da1bf0d2034c66834efc02d3179f
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3203118
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Fix for Rule: Misra-C 2012 Rule 10.1
- Data type of client is a pointer, hence compare it with NULL.
- Data type of co is a pointer, hence compare it with NULL.
- h is a pointer, hence compare with NULL.
- size is of data type size_t, hence compare it with OU.
- Data type of node is a pointer, hence compare it with NULL.
- Data type of priv, priv->handle is a pointer,
hence compare with NULL.
- Data value of Kzalloc is pointer not a boolean, hence compare new with NULL.
- Data type of vma is a pointer, hence compare it with NULL.
- Data type of elem_size and count is unsigned long, hence compare it
with 0.
- Data type of nr is u32, hence compare it with 0U.
- Data type of ret is int, hence compare it with 0.
- Data type of heap is pointer, hence compare it with NULL.
CID 1675220
CID 1677129
CID 1680522
CID 1680855
CID 1682355
CID 1684748
CID 1685031
CID 1688104
CID 1691439
CID 1691492
CID 1697576
CID 1700206
CID 1703733
CID 1705732
CID 1713149
CID 1713881
CID 1715301
CID 1716395
CID 1718186
CID 1724356
CID 1736224
CID 1737251
CID 1742375
CID 1742507
CID 1743460
CID 1747820
CID 1751065
CID 1753197
CID 1754913
CID 1756020
CID 1758334
CID 1761585
CID 1762790
CID 1763725
JIRA TMM-5594
Change-Id: Iec045c45555b364b5869de856b9bb8a8586dfe02
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3201341
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
- Move all data structures from nvmap_heap.h header file to
nvmap_alloc_int.h file as they are owned by nvmap_alloc unit.
- Provide getter and setter functions to get or set the members of these
data structures.
- Provide forward declaration of such data structures.
- Remove nvmap_heap.h header file as nvmap_heap is part of the
nvmap_alloc unit and nvmap_alloc unit exposes nvmap_alloc.h as header
file to other units.
JIRA TMM-5621
Change-Id: I2c4dd95a1a1011e4a7c1b425aa7521c6f13202da
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3201354
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
As part of the nvmap_refactoring, add nvmap_alloc.h file which include
declaration for functions which are exposed by nvmap_alloc unit to other
units. Also, add nvmap_alloc_int.h file which include declaration for
functions which are internal to nvmap_alloc unit that can be called by
files within nvmap_alloc unit.
JIRA TMM-5621
Change-Id: Ie30e5e8a4f87591eb9c49a0a349f837a22726fa5
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3198546
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Fix for Rule: Misra-C 2012 Rule 10.1
-In nvmap_alloc.c h is of type pointer, hence compare with NULL.
-In nvmap_handle.c
-the return type of kzalloc is pointer, hence compare it with NULL.
-Client is a pointer, hence compare it with NULL.
-In nvmap_ioctl.c vaddr is a pointer, hence compare it with NULL.
-In nvmap_pp.c
- the data type of nvmap_root is pointer, hence compare with NULL.
- the data type of page is pointer, hence compare with NULL.
-In nvmap_dmabuf.c
- the return type of kzalloc is pointer, hence compare it with NULL.
- the data type of dev is a pointer, hence compare with NULL.
-In nvmap_priv.c pages are pointer, hence compare it with NULL.
-In nvmap_dev.c dev is a pointer, hence compare it with NULL.
CID 1634656
CID 1637713
CID 1647382
CID 1654006
CID 1657629
CID 1668126
CID 1668779
CID 1671917
CID 1672384
CID 1672959
CID 1653291
JIRA TMM-5627
Change-Id: I2ca971d7957040bf0fbef60b58497c509ca1153f
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3198648
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Fix for Rule: Misra-C 2012 Rule 10.1
-In nvmap_pp.c return type of non_zero_cnt is integer not boolean, hence
compare it with 0.
-In nvmap_dmabuf.c the result for & operation would be 0 or 1, hence
compare it with 0.
-In nvmap_core.c the return type of kzalloc is pointer, hence compare it
with NULL.
-In nvmap_dev.c priv is a pointer, hence compare it with NULL.
CID 1608945
CID 1617267
CID 1622229
CID 1625991
CID 1630899
JIRA TMM-5627
Change-Id: Ib40286f852cdade2e115384d18f615ae52134bdd
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3197795
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: Sachin Nikam <snikam@nvidia.com>
For bigger buffer allocation (e.g. 4GB, 5GB etc) from IOMMU heap, 70% of
the total time is consumed in cache cleaning. CUDA team confirmed that,
it is not always necessary to clean the CPU cache during allocation
flow. Hence provide an option to users of libnvrm_mem to skip cache
cleaning whenever required.
Bug 4628529
Change-Id: I9f4cdc930fcc673b69344f0167c8bc1378ec8d61
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3192376
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
A crash is observed when trying to access ch1 debugfs register in vi0
and vi1 folder. This is because the base reg address is not defined in
DT. This seems like an old legacy code which is ported over. The
registers accessed by this debugfs node are not longer directly
accessible using CCPLEX. While we wait on confirmation for this, adding
this check to not create debugfs node, if register base address is not
defined.
Bug 4626339
Change-Id: Ife714fa7e989bcaf187956920d757870e5fd9701
Signed-off-by: Mohit Ingale <mohiti@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3184450
(cherry picked from commit 1fb6c087c924a540b151183cb5be13311f2c4af1)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3185971
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reduce free memory reported by QueryHeapParams by 0.1% to avoid
OOM issues for Iovmm_heap. For the overall free memory reported
by the query heap params api, page align it to the previous page
to avoid any failures in allocattr due to page align of requested
size, when requested size is equal to reported free size. Update
allocattr api as well so that it checks the available free memory
before allocating.
Bug 4719292
Change-Id: I7ecd69216d58c36ee5d0750107546601400e722d
Signed-off-by: N V S Abhishek <nabhishek@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3165599
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
- For NvRmHeap_GpuMem, we are switching from a carveout to huge pages
obtained from hugetlbfs.
- Allocate a handle from VA using get_user_pages, when allocation is
requested from GPU heap.
- Introduce a new field to indicate that the pages are allocated from
hugetlbfs. This field will be useful while returning the correct heap
while querying the handle params for a handle which was created using
hugetlbfs.
- Update the query heap API for GpuMem heap to return the huge pages
memory values from meminfo.
Bug 4510173
Change-Id: I0dbef4c4e95969f8e3975a6dc58f10255db0635e
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3174720
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Upstream commit cdd9a571b7d8 ("fs/proc: move page_mapcount() to
fs/proc/internal.h") made page_mapcount() an internal function for Linux
v6.11. This function is used by the NVMAP driver and so implement this
function in the NVMAP driver directly instead. Note that newer kernels
implement folio_entire_mapcount() for compound page counts where as
older kernels use compound_mapcount(). Use conftest to detect which of
these functions is present in the kernel.
Bug 4749580
Change-Id: I6504448727d6b3e9f2caa8581a66aad464ae2426
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3180097
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
This patch allows CPU to read and mmap VPR buffers by restricting CPU
VPR read restrictions for pre-si platforms. The knob for controlling the
access is /sys/kernel/debug/nvmap/vpr/vpr_cpu_acces and by default VPR
CPU read is disallowed.
This change is necessary to support pre-si VPR validation for platforms
where there may not be a HW engine that supports CRC computation for VPR
buffers.
Bug 4670086
Change-Id: Ic0d575abbda3cdda10f075a2c7092ced09723333
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3145680
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Add additional HW SEQ validation checks
- Validate all frames with different addressing modes in a
HW SEQ blob
- Validate multiple frames on a single channel in RDF
frame-linking mode
- Validate each column/row within a given frame since
multiple column/rows are supported in next chip
Bug 4588239
Signed-off-by: Amruta Bhamidipati<abhamidipati@nvidia.com>
Change-Id: Ic30c8c1982c5ac21a960f0546c39e5a28cc7d4bd
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3153297
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: Amruta Sai Anusha Bhamidipati <abhamidipati@nvidia.com>
Reviewed-by: Krish Agarwal <krisha@nvidia.com>
Reviewed-by: Sreehari Mohan <sreeharim@nvidia.com>
Reviewed-by: Omar Nemri <onemri@nvidia.com>
NvRmMemHandleAllocAttr can be called with multiple input heaps, if
allocation from first heap fails, then allocation from next heap is
attempted and so on. In case of GPU carveout, the handle size is aligned
to next 2MB while for other heaps, it is aligned to 4KB. If the user
provides an array of heaps, where first one is GPU carveout, then the
handle size is aligned to 2MB and then if the enough memory is not
available in GPU carveout the allocation call fails, but the handle size
is not restored back to 4KB aligned size. So the next allocation attempt
from the second heap would request for incorrect buffer size. Correct
this behavior by restoring the handle size back to 4KB aligned size, if
allocation from GPU carveout fails.
Bug 4661684
Change-Id: I6d93eb96b21e384554df888d9819dcfc2f3565fa
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3159925
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: Ashish Mhetre <amhetre@nvidia.com>
In function nvmap_ioctl_get_fd_from_list, the return pointer from nvmap_handle_get_from_id is being dereferenced without checking if it is valid. This is causing a kernel panic crash in syzkaller. Fix this by checking whether the pointer is valid or not before dereferencing it.
Bug 4479038
Change-Id: Ia65341e9eb12873e660baae44d28966e71317377
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3154940
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Remove WARN_ON macro invocation and exit gracefully from the nvmap_query_heap_params function when the heap_mask parameter is not a power of two. This is because if two or more bits are set in heap_mask, then it's an invalid parameter because NvMap can allocate buffer from only one heap at a time.
Bug 4479038
Change-Id: I6cfca911115f7f29e2c4e46816a89fa1869adae4
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3154939
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When granule_size of type u32 and size is more than 4GB (i.e. value
having more than 32 bits), then ALIGN_GRANULE_SIZE would return
incorrect value due to ~(GRANULE_SIZE - 1), as this would be in 32
bits. Hence change the granule size's data type to size_t, so that the
above value is not restricted to 32 bits.
Bug 4650102
Change-Id: If44f2663b6a4735c193d3a80b233b53d70772335
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3149162
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Tested-by: Bitan Biswas <bbiswas@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Upstream commit 690da22dbfa8 ("asm-generic/io.h: kill vmalloc.h
dependency") removed the vmalloc.h header file from io.h and this breaks
building various drivers with the latest -next kernels. Fix this
by ensuring vmalloc.h is included and in most cases slab is not actually
needed and so remove this where possible. Note that it is fine to make
this change for all current supported kernels.
Bug 4593750
Change-Id: I003d1302bda226d356467e6ede99949b2716940a
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3141984
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
When the tsec driver is built with the compiler flag
-Werror=old-style-declaration the following error is observed ...
error: 'static' is not at beginning of declaration
[-Werror=old-style-declaration]
393 | const static struct dev_pm_ops tsec_module_pm_ops = {
| ^~~~~
This is observed with the latest linux-next kernels, but could be
observed with any kernel where this flag is set. Fix this by ensuring
that the 'static' keyword is declared first.
Bug 4593750
Change-Id: Ia635188569d827d361bd36f7be943fbf9f1f0a60
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3126898
(cherry picked from commit ac51641cf1)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3127605
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
