- 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>
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>
In Linux v6.13, the quirk definition 'UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS'
was removed and replaced with a function pointer than can be used to set
the DMA mask as needed for a given device. Update the Tegra UFS driver
to fix support for Linux v6.13. Note that prior to Linux v6.13, the flag
'UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS' would set the DMA mask to 32-bits
and so this change is equivalent to the configuration of prior kernels.
Bug 4991705
Change-Id: I859331e9eea918d2438d68b871642fee5e4148e0
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3283447
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
1. Add mechanism(s) to trigger syncpoint fence scan when
syncpoint increment UMD called. Following methods are added.
- METHOD-1: Check fence expire in user context when syncpoint
increment UMD API is called.
- METHOD-2: Add tasklet based mechanism that schedule tasklet to scan for
syncpoint fence expiry. This also improve signaling latency.
METHOD-1 is enabled by default, to enable METHOD-2 define MACRO
"HOST1X_EMU_SYNC_INC_TASKLET".
2. Add interface "host1x_syncpt_fence_scan()" that can be called from
client interrupt handler to initiate syncpoint fence scan.
Jira HOSTX-5527
Change-Id: I4d5a0ba9fd67042d824a1df2794b316831001dc4
Signed-off-by: amitabhd <amitabhd@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3267144
Reviewed-by: Raghavendra Vishnu Kumar <rvk@nvidia.com>
Reviewed-by: Sanif Veeras <sveeras@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Leslin Varghese <lvarghese@nvidia.com>
Fix v4l2-compliance VIDIOC_G/S_PARM failure.
Below is the function call sequence starting from
ioctl.
doioctl(VIDIOC_G_PARM)
vidioc_g_parm
tegra_channel_g_parm
v4l2_g_parm_cap
v4l2_subdev_call_state_active
v4l2_subdev_call
v4l2_subdev_call_wrappers.pad.get_frame_interval
call_get_frame_interval
check_frame_interval
check_state
In file: v4l2-subdev.c check_state() function
failed at check:
(!state || !state->pads)
Which caused the function to return -EINVAL=-22.
struct v4l2_subdev contain a member
active_state which should be initialized to
overcome the failure. To fill active_state
call v4l2_subdev_init_finalize in
tegracam_v4l2subdev_register().
This failure is seen in K6.8 because in earlier
kernel, v4l2_subdev_call() was called instead of
v4l2_subdev_call_state_active() in
v4l2_g_parm_cap(). And v4l2_subdev doesn't contain
active_state member in earlier kernel.
Bug 4449673
Change-Id: Id0fbcf9476cf6d194b721f85790e95580ff4007d
Signed-off-by: Ankur Pawar <ankurp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3281759
Reviewed-by: Frank Chen <frankc@nvidia.com>
Reviewed-by: Praveen AC <pac@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- dce-client-ipc.c is a common file used by HVRTOS as well to
register as a DCE client.
- We need to refactor existing register function due to certain
HVRTOS restrictions at init time.
1) Register function will be called at init time from HVRTOS.
2) HVRTOS doesn't allow any mutex acquire calls or wait calls
during INIT phase.
JIRA TDS-16581
Change-Id: I1b3a9587c1e237c2cca8214a3acce9ff34d98cc0
Signed-off-by: anupamg <anupamg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3280251
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Arun Swain <arswain@nvidia.com>
Reviewed-by: Vinod Gopalakrishnakurup <vinodg@nvidia.com>
+ Add the following data validation checks based on
gaps identified when inspecting code for
SHR-9320:
+ FSYNC: Add check to ensure existence of generators
property before parse
+ FSYNC: Add check to ensure generators in default
group adhere to LCM rule
+ CDI: Add check to ensure reg_len / dat_len do
not exceed 2 bytes
+ CDI: Ensure err is set before jumping to err_probe
+ CDI: Jump to err_probe if IOExpander i2c-bus read
fails
+ CDI-TCA: Return error if reg_len or dat_len
out of expected range
+ FuSaCap: Ensure isp/vi-max-channels validated
+ VI: Add check for vi-mapping index found (this was
already caught in existing code, but error message
was non-specific)
+ camera_common: Add check for err that was set but
never read
+ RTCPU: Add debug prints for properties not found
Jira CAMERASW-30537
Change-Id: I9953029f594c0153d6c335913944fb8906adedd9
Signed-off-by: kevixie <kevixie@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3280557
Reviewed-by: Vincent Chung <vincentc@nvidia.com>
Reviewed-by: Frank Chen <frankc@nvidia.com>
Reviewed-by: Mohit Ingale <mohiti@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Fix for: Sparse defects
Sparse defect stated that "iovmm_debugfs_info" was not declared. Should it be static?
and symbol 'nvmap_max_handle_count' was not declared. Should it be static?
-Since iovmm_debugfs_info is only used in nvmap_debug.c, hence it can be
made static.
-Since nvmap_max_handle_count is only used in nvmap_handle.c, hence it can be
made static.
Bug 4513982
Change-Id: Ifb12f14c07e56c340d926f6a4a3f858a762d71fb
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3274000
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
This patch ensures that the Maximum Payload Size (MPS) and Maximum Read Request Size (MRRS) settings of the root port associated with r8168 ethernet endpoint are properly configured after overwritten by kernel when pcie_bus_perf is enabled.
Bug 4607316
Change-Id: I7f7b83f74e4ac2104345bd568d9d2e7c03a1441e
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3273562
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Issue: on resume the mac set speed is not called due
to which the data transmissions are not happening in
alternate suspend resume cycles.
This is because the oldlink status is not set to 1 during
the successful resume, in set_speed_work_func retries
Fix: set oldlink to 1 once setspeed is successful in
function set_speed_work_func, so that next time
ether_adjust_link will call the set speed after resume
Bug 4891730
Change-Id: Iadb426f2cada99387ce180dfa2d0c9ee57e7ccd5
Signed-off-by: Bibhay Ranjan <bibhayr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3260342
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
