Upstream Linux commit 393b06383fb7 ("debugfs: remove return value of
debugfs_create_bool()") updated the function debugfs_create_bool() to
remove the return value because it was not needed and user do not need
to check the return value. This breaks building the NVGPU driver against
the current upstream Linux kernel and the following error messages are
seen ...
nvgpu/drivers/gpu/nvgpu/os/linux/debug.c: In function ‘gk20a_debug_init’:
nvgpu/drivers/gpu/nvgpu/os/linux/debug.c:469:25: error: void value not ignored as it ought to be
l->debugfs_ltc_enabled =
^
nvgpu/drivers/gpu/nvgpu/os/linux/debug.c:507:32: error: void value not ignored as it ought to be
l->debugfs_runlist_interleave =
^
Fix this by not saving the value returned from debugfs_create_bool() and
remove the variables debugfs_ltc_enabled and debugfs_runlist_interleave
from the nvgpu_os_linux structure. Note that these variables are not
used anywhere in the driver and currently we don't check the return
value from debugfs_create_bool() and so there is no impact from this
change for older kernel versions.
JIRA LS-114
Change-Id: I539388c8645f2026292d8b9f33f55921dfda648f
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2555299
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
On all chips except ga10b, the number of ROP, L2 units per FBP
were in sync, hence, their FS masks could be represented by a single
fuse register NV_FUSE_STATUS_OPT_ROP_L2_FBP. However, on ga10b, the ROP
unit was moved out from FBP to GPC and it no longer matches the number
of L2 units, so the previous fuse register was broken into two -
NV_FUSE_CTRL_OPT_LTC_FBP, NV_FUSE_CTRL_OPT_ROP_GPC.
At present, the driver reads the NV_FUSE_CTRL_OPT_ROP_GPC register
and reports incorrect L2 mask. Introduce HAL function
ga10b_fuse_status_opt_l2_fbp to fix this.
In addition, rename fields and functions to exclusively fetch L2 masks,
this should help accommadate ga10b and future chips in which L2 and ROP units
are not in same. As part of this, the following functions and
fields have been renamed.
- nvgpu_fbp_get_rop_l2_en_mask => nvgpu_fbp_get_l2_en_mask
- fuse.fuse_status_opt_rop_l2_fbp => fuse.fuse_status_opt_l2_fbp
- nvgpu_fbp.fbp_rop_l2_en_mask => nvgpu_fbp.fbp_l2_en_mask
The HAL ga10b_fuse_status_opt_rop_gpc is removed as rop mask is not
used anywhere in the driver nor exposed to userspace.
Bug 200737717
Bug 200747149
Change-Id: If40fe7ecd1f47c23f7683369a60d8dd686590ca4
Signed-off-by: Antony Clince Alex <aalex@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2551998
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
The NVGPU driver fails to build with current upstream Linux mainline
which will be Linux v5.14. Upstream Linux commit f39650de687e
("kernel.h: split out panic and oops helpers") re-organised some
kernel headers and removed the inclusion of 'linux/kernel.h' from
'include/asm-generic/bug.h'. This is now breaks the compilation of
NVGPU because the definitions in 'linux/limits.h' for UINT_MAX, INT_MAX,
etc are not found. Fix this by ensuring the 'linux/limits.h' is included
in 'nvgpu/types.h'.
JIRA LS-114
Change-Id: Id57322cd280532da6e6f9a16dbe54f88cd7a0cca
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2554713
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
This CL covers the following modifications,
1) Added logic to skip the graphics unit specific sw context load
register write during context creation when MIG is enabled.
2) Added logic to skip the graphics unit specific sw method
register write when MIG is enabled.
3) Added logic to skip the graphics unit specific slcg and blcg gr
register write when MIG is enabled.
4) Fixed some priv errors observed during MIG boot.
5) Added MIG Physical support for GPU count < 1.
6) Host clk register access is not allowed for GA100.
So skipped to access host clk register.
7) Added utiliy api - nvgpu_gr_exec_with_ret_for_all_instances()
8) Added gr_pri_mme_shadow_ram_index_nvclass_v() reg field
to identify the sw method class number.
Bug 200649233
Change-Id: Ie434226f007ee5df75a506fedeeb10c3d6e227a3
Signed-off-by: Lakshmanan M <lm@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2549811
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
common.cic unit is divided into common.cic.mon and common.cic.rm
based on rm and mon process split.
CIC-mon subunit includes the code which is utilized in critical
interrupt handling path like initialization, error detection and
error reporting path. CIC-rm subunit includes the code corresponding
to rest of interrupt handling(like collecting error debug data from
registers) and ISR status management (status of deferred interrupts).
Split the CIC APIs and data-members into above two subunits.
JIRA NVGPU-6899
Change-Id: I151b59105ff570607c4a62e974785e9c1323ef69
Signed-off-by: Tejal Kudav <tkudav@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2551897
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
common.ptimer unit right now exposes two APIs -
scale_ptimer() to scale the timer
ptimer_scalingfactor10x() to get the scaling factor
receiving scaling factor is not really necessary for user of
common.ptimer since it can be internally calculated in scale_ptimer()
function itself.
Hence make ptimer_scalingfactor10x() static and rename public API
scale_ptimer() to nvgpu_ptimer_scale()
nvgpu_ptimer_scale() will not accept timeout value as parameter
and return scaled timeout value in another pointer parameter.
Error code is returned if timeout value is invalid.
Jira NVGPU-6394
Change-Id: Ib882d99f6096c3af5f96eef298d713fb5e36dd87
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2546970
(cherry picked from commit 2da7c918efe91046818c83481664312e194ead8e)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2551334
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Add REMAP ioctl and accompanying support to the linux nvgpu driver.
REMAP support provides per-page control over sparse VM areas using the
concept of a virtual memory pool.
The REMAP ioctl accepts a list of operations (each a map or unmap) that
modify the VM area pages tracked by the virtual mmemory pool.
Inclusion of REMAP support in the nvgpu build is controlled by the new
CONFIG_NVGPU_REMAP flag. This flag is enabled by default for linux builds.
A new NVGPU_GPU_FLAGS_SUPPORT_REMAP characteristics flag is added for use
in detecting when REMAP support is available.
When a VM allocation tagged with NVGPU_VM_AREA_ALLOC_SPARSE is made the
base virtual memory pool resources are allocated. Per-page resources are
later allocated when the NVGPU_AS_IOCTL_REMAP ioctl is issued. All REMAP
resources are released when the corresponding VM area is freed.
Jira NVGPU-6804
Change-Id: I1f2cdc0c06c1698a62640c1c6fbcb2f9db24a0bc
Signed-off-by: scottl <scottl@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2542178
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Replace all nvgpu_next functions/structs either by 1) collapsing them
into nvgpu legacy functions/structs 2) renaming them as follows:
- nvgpu_next_*() => nvgpu_(ga10b/ga100)_*()
- nvgpu_next_*() => (ga10b/ga100)_*()
- nvgpu_next_*() => nvgpu_*() [only if this doesn't cause collision]
- nvgpu_next_*() = > nvgpu_*_extra()
Create hal.sim unit and move Ampere+ SIM code into it.
Jira NVGPU-4771
Change-Id: I215594a0d0df4bd663bd875a0d0db47bcb9ff6a2
Signed-off-by: Antony Clince Alex <aalex@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2548056
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Mahantesh Kumbar <mkumbar@nvidia.com>
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The CONFIG_NVGPU_NEXT config is no longer required now that ga10b and
ga100 sources have been collapsed. However, the ga100, ga10b sources
are not safety certified, so mark them as NON_FUSA by replacing
CONFIG_NVGPU_NEXT with CONFIG_NVGPU_NON_FUSA.
Move CONFIG_NVGPU_MIG to Makefile.linux.config and enable MIG support
by default on standard build.
Jira NVGPU-4771
Change-Id: Idc5861fe71d9d510766cf242c6858e2faf97d7d0
Signed-off-by: Antony Clince Alex <aalex@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2547092
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
nvgpu does map attachment with DMA_BIDIRECTIONAL direction for buffers
irrespective of the GPU mapping type. nvmap will allow map attachment
with only DMA_TO_DEVICE direction for RO buffers for secure buffer
access.
nvgpu does RO GPU mapping if the buffer is RO for CPU or user requests
to map as RO. In both cases the dma_buf map attachment should be done
with DMA_TO_DEVICE direction as the intent for accessing the SGT is
reading from GPU.
Also, map the gpfifo buffer as read_only as it is intended to be read
only. The userd buffer is accessed by the GPU through iova and is not
GMMU mapped.
Bug 200731819
Change-Id: Ifc60973f298f7cacab16c5dedecbb40c5f33ed1d
Signed-off-by: Sagar Kamble <skamble@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2539312
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
To use enum gk20a_mem_rw_flag declaration, gmmu.h was included in qnx
nvgpu_nvmap_user.h. However with that recursive header inclusion
happens as below:
nvgpu_nvmap_user.h <- nvgpu/gmmu.h <- nvgpu/nvgpu-mem.h
<- nvgpu_rmos/include/nvgpu_mem.h <- nvgpu_nvmap_user.h
Remove this recursion by moving gk20a_mem_rw_flag to gmmu.h. Also
move nvgpu_aperture to gmmu.h. With this approach gmmu.h can be
included in nvgpu-mem.h as it is independent of OS header.
Bug 200717195
Bug 3250920
Change-Id: I6d3011d830e3778d8d4224ddfcc2eb85a49e444b
Signed-off-by: Sagar Kamble <skamble@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2531788
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Add api to translate dmabuf's fmode_t to gk20a_mem_rw_flag
for read only/read write mapping selection.
By default dmabuf fd mapping permission should be a maximum
access permission associated to a particual dmabuf fd.
Remove bit flag MAP_ACCESS_NO_WRITE and add 2 bit values for
user access requests NVGPU_VM_MAP_ACCESS_DEFAULT|READ_ONLY|
READ_WRITE.
To unify map access type handling in Linux and QNX move the
parameter NVGPU_VM_MAP_ACCESS_* check to common function
nvgpu_vm_map.
Set MAP_ACCESS_TYPE enabled flag in common characteristics
init function as it is supported for Linux and QNX.
Bug 200717195
Bug 3250920
Change-Id: I1a249f7c52bda099390dd4f371b005e1a7cef62f
Signed-off-by: Lakshmanan M <lm@nvidia.com>
Signed-off-by: Sagar Kamble <skamble@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2507150
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-misra <svc-mobile-misra@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When force closing the app, poweron needed in channel close path will
fail as pg_task kthread creation fails with -EINTR (process is
SIGKILL'd so threads don't get created).
Upon poweron failure, device nodes are removed and the nvgpu power
state is not reset to NVGPU_STATE_POWERED_OFF. Hence on further
gk20a_busy attempts, poweron is not attempted and gpu remains
unusable from thereon.
Change the state to POWERED_OFF from POWERING_ON on poweron fail.
Bug 3308828
Change-Id: I2360f11a4937dfe93eb7933b30c13748fb570898
Signed-off-by: Sagar Kamble <skamble@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2543797
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Presently, gk20a_user_deinit is used to remove all device nodes
including "power" node as well.
Split removal of power node into a separate function
gk20a_power_node_deinit to enable other device removal during the
normal runtime_suspend path to facilitate the fast path for MIG
reconfiguration. Powernode can be removed only during a call to
Rmmod. This also enables separately powering off the device nodes
in the unlikely case of a poweron failure.
Bug 3308828
Jira NVGPU-6920
Change-Id: Ib045a09a992a63c468492a837b273cca41e20f15
Signed-off-by: Debarshi Dutta <ddutta@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvgpu/+/2543014
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Dinesh T <dt@nvidia.com>
Reviewed-by: Lakshmanan M <lm@nvidia.com>
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
