Fix for: Sparse defects
Sparse stated that:
-symbol 'tegra_vpr1_dev' was not declared. Should it be static?
-symbol 'tegra_vpr_cma_dev' was not declared. Should it be static?
-symbol 'tegra_generic_cma_dev' was not declared. Should it be static?
-symbol 'tegra_vpr_dev' was not declared. Should it be static?
-symbol 'tegra_generic_dev' was not declared. Should it be static?
Making all the above functions static since it is being used in nvmap_init.c only.
Bug 4513982
Change-Id: I4887d994d9ae852a4faa7da735c18d25b393187a
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3295831
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In current implementation, when NvRmMemQueryHeapParams is
called and multiple numa nodes are online:
1. For iovmm carveout, numa_id is set to garbage value,
and we are calling compute_memory_stat with it.
2. For gpu carveout, we are returning values for
numa_id 0.
3. For other carveouts, we are returning params for the
first matching entry in nvmap_dev->heaps[i].
Correct this behavior as follows:
Regardless of carveout type, return params for numa_id 0
when NvRmMemQueryHeapParams is called and multiple numa
nodes are online.
In long-term, we need to disable NvRmMemQueryHeapParams
when multiple numa nodes are online. Clients should use
NvRmMemQueryHeapParamsNuma instead.
Jira TMM-5970
Change-Id: Id49289e51eda187b1d676e5192583f320835c2f4
Signed-off-by: N V S Abhishek <nabhishek@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3290730
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In order to serve MEMSERV70-REQ-670 requirement, which makes validation
checks mandatory for input flowing across execution boundary. Hence add
checks for input flags in nvmap and make sure the execution does not
proceed if flag other than read or write is provided in handle
duplication, creating sciipc id or during handle creation from sciipc id
even though the checks are present at libnvrm_mem layer.
JIRA TMM-5962
Change-Id: I1fc6ce6ec4435c50220d4e49a08de50320a8f574
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3295201
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
- use TSC lock trigger interval param from dt to optimize
As per HW suggestion we should not trigger sync on every
PPS edge. TSC needs atleast 2 PPS edges to align with the
PTP clock.
- save platform specific register offset during drv init time
instead of checking plat id everytime in monitoring thread
Bug 5042311
Bug 4899241
Bug 5082436
Signed-off-by: Sheetal Tigadoli <stigadoli@nvidia.com>
Change-Id: I22befbc2a52c22ace1a8573b9a34a544ed1ae8f9
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3294329
(cherry picked from commit 209dc26eddd2cd5e9d88ea8c6eb603706cd3c3f0)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3292322
Reviewed-by: Amlan Kundu <akundu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Add kernel module parameter to enable a mode where syncpoints
must be freed explicitly (using the free IOCTL) or they will be
left dangling. This ensures that, for particularly locked down
configurations, a syncpoint will be forever left in an expected
state even if the process owning it dies -- for example another
process will not be able to allocate it.
Change-Id: I2f350c710775a296c70910df21e95737a36c6a45
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3284405
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Santosh BS <santoshb@nvidia.com>
On TOT, NvMap does page by page cache flush i.e. it takes virtual
address of each page present in the buffer and then perform cache
flush on it using dcache_by_line_op. This result in very poor
performance for larger buffers. ~70% of the time taken by
NvRmMemHandleAllocAttr is consumed in cache flush.
Address this perf issue using multithreaded cache flush
- Use a threshold value of 32768 pages which is derived from perf
experiments and as per discussion with cuda as per usecases.
- When the cache flush request of >= 32768 pages is made, then vmap
pages to map them in contiguous VA space and create n number of kernel
threads; where n indicate the number of online CPUs.
- Divide the above VA range among the threads and each thread would do
cache flush on the VA range assigned to it.
This logic in resulting into following % improvement for alloc tests.
-----------------------------------
Buffer Size in MB | % improvement |
----------------------------------|
128 | 52 |
256 | 56 |
512 | 57 |
1024 | 58 |
1536 | 57 |
2048 | 58 |
2560 | 57 |
3072 | 58 |
3584 | 58 |
4096 | 58 |
4608 | 58 |
5120 | 58 |
-----------------------------------
Bug 4628529
Change-Id: I803ef5245ff9283fdc3afc497a6b642c97e89c06
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3187871
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- support use of higher PPS freq in nvpps. The freq value
is read from primary mac interface's "nvidia,pps_op_ctrl"
field and vetted for valid values(0,1,2,4,5 & 8).
- To use higher PPS freq, nvpps needs to update K_INT and
REF_FREQ.INC value and also increase the freq of monitoring
thread.
Bug 5042311
Bug 4899241
Signed-off-by: Sheetal Tigadoli <stigadoli@nvidia.com>
Change-Id: I87e9be5a0ba2156054aea380c730b087d274c223
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3286820
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Vijay Mishra <vijaym@nvidia.com>
Reviewed-by: Sumeet Gupta <sumeetg@nvidia.com>
In Linux v6.13, commit 7bac65687510 ("scsi: ufs: qcom: Power off the PHY
if it was already powered on in ufs_qcom_power_up_sequence()") removed
the 'reinit_notify' function pointer from the 'ufs_hba_variant_ops'
structure. This breaks the build for the Tegra UFS driver because we
maintain a copy of the upstream header file 'ufshcd-priv.h' in order to
build the Tegra UFS driver as an out-of-tree driver.
It is possible to fix this by using conftest to detect if the
'reinit_notify' function pointer is defined in the kernel's
'ufs_hba_variant_ops' structure. However, given that the Tegra UFS
driver does not use the 'ufshcd_vops_reinit_notify' where this
function pointer is referenced, it is simpler to remove the function
ufshcd_vops_reinit_notify completely.
Bug 4991705
Change-Id: I2228f2a26640e13f61721e82856cc32b8d570809
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3283377
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
NvRmMemSetAllocationTagLabel is not being used by any of clients. Also,
this API does not have any SHR or JAMA requirement. Hence we are
removing support for this API on linux to have a cleaner and uniform
ICD. Remove the corresponding ioctl code from nvmap.
Bug 4980808
Change-Id: I74676e07b2c617ad6554b4538ce27ab52176e5b9
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3288404
Reviewed-by: N V S Abhishek <nabhishek@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.13, commit 94a20fb9af16 ("sysfs: treewide: constify
attribute callback of bin_attribute::mmap()") changed the type of
the 'struct bin_attribute' argument of the bin_attribute:mmap function
pointer to const.
One instance of this change has already been fixed in the hvc_sysfs
driver but another case was recently introduced breaking the build for
Linux v6.13. Fix this in the same way as the previous instance.
Bug 4985113
Bug 4991705
Change-Id: I7f68138f3b484ebfe7a4ff5032c7b4365865f248
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3287044
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
This reverts commit 40b9876e2f277472677c22b947da7260cf39626e.
Reason for revert:
Initial change to fix year calculation is correct.
We do not need to blindly add +100 in year value. RTC_YEAR
register can accomodate values from 0..199. Being year base 1900
and valid rtc time being 1970, valid year values are 1970..2099.
Bug 4911320
Change-Id: Ic4183f4d85e4612b6a5a7ab53baf0483b7b6acad
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3283957
Reviewed-by: Evan Wei <evwei@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
