We right now do not handle misaligned_addr SM exception explicitly and hence
we incorrectly initiate CILP on this exception
Handle this exception explicitly in this sequence -
- set error notifier first
- clear the interrupt
- return error from gr_gv11b_handle_warp_esr_error_misaligned_addr() so that
RC recovery is triggered by gk20a_gr_isr()
Ensure that the error value is propagated back to gk20a_gr_isr() correctly
Use nvgpu_set_error_notifier_if_empty() to set error notifier since this will
prevent overwriting of error notifier value in case gk20a_gr_isr() also tries
to write to some error notifier value
Bug 200388475
Jira NVGPU-554
Change-Id: I84c4d202a8068e738567ccd344e05d9d5f6ad2f0
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1686781
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
BIT() is defined as returning a 64-bit value. We use it to create the
log mask values, but the functions that accept log mask take only
u32 as parameter.
Use u64 as log mask parameter for the logging functions to match the
sizes.
Change-Id: I6f0803a7d04ee6a2ee725b5defc4cc14b5b7acf5
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1683818
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
If golden context creation happens before any gpu railgate then
channel creation is always fine. If gpu railgate happens after gpu
finalize poweon, but before golden context creation, then golden
context creation is failing during first channel creation with
watchdog timeout from ctxsw because of invalid ctxsw state.
To Fix this issue, if the golden context is not created, then during
finalize power on always query ctxsw image sizes, which is making ctxsw
hw in correct state before golden context creation.
Bug 2051863
Change-Id: I81d221100a099b12bad3adc2d252de4621c335a5
Signed-off-by: seshendra Gadagottu <sgadagottu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1682265
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
In gr_gk20a_create_priv_addr_table() and gv11b_gr_egpc_etpc_priv_addr_table(),
we create a table of unicast addresses from broadcast addresses
For GPC boardcast addresses like NV_PGRAPH_PRI_EGPCS_ETPC6_SM_*, we generate
the table assuming there are 7 TPCs in all the GPCs
But this is incorrect in some cases like GV100 where GPC0/1 have only 6 TPCs
And hence we end up generating registers which do not exist
Fix this by explicitly checking the number of TPCs and ensuring that address
generated is belongs to valid TPC
Bug 200400376
Jira NVGPU-564
Change-Id: I65d7d6cd7f0bf16171eb54ed71f1f3840ade3495
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1686806
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When runtime pm is disabled, then gpu rail will be on as soon as
nvgpu module is loaded. If pm suspend/resume called before gpu
hw initialization(g->poweron = false) then pm suspend is skipping
gpu railgate, which is causing issues with SC7 entry/exit.
To fix this issue:
1. During pm suspend, if g->poweron is false, check for runtime pm
disable to railgate gpu rail.
2. On pm resume, check for runtime pm disable to enable gpu rail,
though gpu driver not initialized.
Bug 2073029
Change-Id: I7631109d79cda5882d2864557f1b7b3d2d89c9f6
Signed-off-by: seshendra Gadagottu <sgadagottu@nvidia.com>
Signed-off-by: Seema Khowala <seemaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1679010
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Do not continue polling if engine save has not started yet
and stall intr is set because if a stall intr is hit,
preemption will anyways not get completed. Just set the
reset_eng_bitmask of the engine for which ctx_status
was being polled, As part of teardown corresponding
engine will be reset.
Bug 2069807
Change-Id: I9a506e0bca1d891ed5cd5d4953e292a40356f8ff
Signed-off-by: Seema Khowala <seemaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1683694
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Multiple places were missing explicit <nvgpu/types.h> includes but
used various types anyway. Fix that by including <nvgpu/types.h>
where necessary.
A gp106 file directly used the Linux delay header instead of
including <nvgpu/timers.h>.
This patch fixes both problems.
JIRA NVGPU-525
Change-Id: Ib7a30a8ed9098d469d646c0a2bba293087b8de90
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1673821
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Konsta Holtta <kholtta@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
CLANG, when compiling regops_gk20a.c sees the following warning:
../drivers/gpu/nvgpu/gk20a/regops_gk20a.c:464:30: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if (unlikely(skip_read_lo == false)) {
~~~~~~~~~~~~~^~~~~~~~
../drivers/gpu/nvgpu/gk20a/regops_gk20a.c:464:30: note: remove extraneous parentheses around the comparison to silence this warning
if (unlikely(skip_read_lo == false)) {
~ ^ ~
../drivers/gpu/nvgpu/gk20a/regops_gk20a.c:464:30: note: use '=' to turn this equality comparison into an assignment
if (unlikely(skip_read_lo == false)) {
^~
=
1 error generated.
But this obviously is fine. However, it's simple enough to work around
by just deleting the unlikely() call. We don't do anything with that
anyway.
JIRA NVGPU-525
Change-Id: I674855ad08daf65ac6d79ceab7d4f56f637d4437
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1673818
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Konsta Holtta <kholtta@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
The patch declares globally few channel/fifo HAL functions
required for QNX code compilation (as they are being referred
elsewhere in QNX code). This is required as a part of
bringing in the nvgpu Channel/FIFO HAL into QNX.
Jira VQRM-3058
Change-Id: Ia176535b64de981d2f7ddb20f62015a0da74fd2a
Signed-off-by: Sourab Gupta <sourabg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1662411
GVS: Gerrit_Virtual_Submit
Tested-by: Richard Zhao <rizhao@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
-Dump timeout save0 and save1 even if they could
be unreliable when fecs_tgt in set in save0 . This
is good to have for debug purposes.
-Add priv_ring hal for decode_error_code
-Decode fecs error code for supported error types
Bug 1998067
Change-Id: I60cb6902d099df4a7df45fa624e44d9e0d46360f
Signed-off-by: Seema Khowala <seemaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1683014
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Current code does not compute priv error register offsets
properly. This leads to invalid decoding of priv errors, and
can also trigger additional priv errors.
- add GPU_LIT_GPC_PRIV_STRIDE define
- return proj_gpc_priv_stride for GPU_LIT_GPC_PRIV_STRIDE in hals
- use GPU_LIT_GPC_PRIV_STRIDE instead of GPU_LIT_GPC_STRIDE in
g->ops.priv_ring.isr() to compute priv error register offsets.
Bug 2093058
Change-Id: Ia7c36ccba0441126784bb0e00452f2cf1196ef71
Signed-off-by: Thomas Fleury <tfleury@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1682118
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Seema Khowala <seemaj@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tested-by: Seema Khowala <seemaj@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Instead of looping all jobs and releasing their semaphores separately,
do just one semaphore release. All the jobs are using the same sema
index, and the final, maximum value of it is known.
Move also this resetting into ch->sync->set_min_eq_max() to be
consistent with syncpoints.
Change-Id: I03601aae67db0a65750c8df6b43387c042d383bd
Signed-off-by: Konsta Holtta <kholtta@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1680362
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Semaphores don't need to be released from CPU anymore, so clarify the
code by deleting nvgpu_semaphore_release() and refactoring
__nvgpu_semaphore_release() to nvgpu_semaphore_reset() that only
"fast-forwards" the semaphore to a later value.
While doing this, the meaning of nvgpu_semaphore_incr() changes, so
rename it to nvgpu_semaphore_prepare(). Now it's only used to prepare an
nvgpu_semaphore for a value that the HW will increment the sema to.
Also change the BUG_ON that guards sema double-inits into just WARN_ON.
Change-Id: I6f6df368ec5436cc97a229697742b6a4115dca51
Signed-off-by: Konsta Holtta <kholtta@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1680361
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Alex Waterman <alexw@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Accept submits on deterministic channels even when the prefence is a
syncfd, but only if it has just one fence inside.
Because NVGPU_SUBMIT_GPFIFO_FLAGS_SYNC_FENCE is shared between pre- and
postfences, a postfence (SUBMIT_GPFIFO_FLAGS_FENCE_GET) is not allowed
at the same time though.
The sync framework is problematic for deterministic channels due to
certain allocations that are not controlled by nvgpu. However, that only
applies for postfences, yet we've disallowed FLAGS_SYNC_FENCE for
deterministic channels even when a postfence is not needed.
Bug 200390539
Change-Id: I099bbadc11cc2f093fb2c585f3bd909143238d57
Signed-off-by: Konsta Holtta <kholtta@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1680271
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
nvgpu_semaphore_pool_alloc() returns an ERR_PTR instead of NULL which
the caller checks on failure. Common code should not use ERR_PTRs
though, so modify nvgpu_semaphore_pool_alloc() to return error code
separately and fix nvgpu_init_sema_pool() to consider this.
Jira NVGPU-513
Change-Id: I435c0d2794d226774ed4c6b3bcbdde1e741854d8
Signed-off-by: Konsta Holtta <kholtta@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1673458
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
MAX/threshold value of user managed syncpoint is not tracked by nvgpu
So if channel is reset by nvgpu there could be waiters still waiting on some
user syncpoint fence
Fix this by setting a large safe value to user managed syncpoint when aborting
the channel and when closing the channel
We right now increment the current value by 0x10000 which should be sufficient
to release any pending waiter
Bug 200326065
Jira NVGPU-179
Change-Id: Ie6432369bb4c21bd922c14b8d5a74c1477116f0b
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1678768
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Konsta Holtta <kholtta@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>
GV100 ucode is changed so that it expects LIST_nv_perf_pma_ctx_reg list in
ctxsw buffer to be 256 byte aligned but same change is not applied to other
chip ucodes
ADD new HAL (*add_ctxsw_reg_perf_pma) to configure PMA register list and
define a common HAL gr_gk20a_add_ctxsw_reg_perf_pma() for all other
chips except GV100
Define a separate HAL for GV100 gr_gv100_add_ctxsw_reg_perf_pma() and fix
the required alignment in this function
Bug 1998067
Change-Id: Ie172fe90e2cdbac2509f2ece953cd8552e66fc56
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1676655
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
For LIST_nv_pm_fbpa_ctx_regs, we right now call
add_ctxsw_buffer_map_entries_subunits() to add registers corresponding
to all the FBPAs
But while configuring total number of registers, we do not consider
floorswept FBPAs and that causes misalignment in subsequent lists for GV100
Fix this by reading disabled/floorswept FBPAs from fuse and consider only those
FBPAs which are active for GV100
Add new HAL (*add_ctxsw_reg_pm_fbpa) to support this setting and define a
common HAL gr_gk20a_add_ctxsw_reg_pm_fbpa() for all chips except GV100
Define GV100 specific gr_gv100_add_ctxsw_reg_pm_fbpa() with above mentioned
implementation to consider floorsweeping
Bug 1998067
Change-Id: Id560551bb0b8142791c117b6d27864566c90b489
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1676654
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Switching GPU clock in/out of bypass concurrently with h/w thermal
throttling may result in unpredictable/unstable clock output from GPU
linear divider. Hence, made sure thermal throttling is disabled before
bypass entry, and enabled after bypass exit.
Bug 1893467
Change-Id: Ia919c599eeb0115e11a34370aea3982aa935db2f
Signed-off-by: Srikar Srimath Tirumala <srikars@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1677022
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Req : Some boardobjgrp don't need getstatus support, so
boardobjgrp pmu cmd not constructed for those boardobjgrp.
Don't request memory alloc if boardobjgrp pmu cmd
not constructed & should exit cleanly without allocating memory.
Fix: Don't request memory alloc if boardobjgrp pmu cmd
not constructed by checking "sturct boardobjgrp_pmu_cmd"
member "fbsize" value.
Change-Id: I610d6812ec1d1bcf7ea38645236601b3e5672650
Signed-off-by: Mahantesh Kumbar <mkumbar@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1674191
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Vijayakumar Subbu <vsubbu@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When generating the aperture field for the PDE being programmed
we must use the next PD not the current PD. This is important for
cases on the dGPU where VIDMEM runs out.
In such cases the page table may reside in both VIDMEM and SYSMEM.
Thus, if a PDE points to a PDE in a different type of memory
(VIDMEM -> SYSMEM or SYSMEM -> VIDMEM) then the aperture will not
be programmed correctly if the code uses the current PD for
picking the next PD aperture.
Bug 2082475
Change-Id: Ic1a8d1e2c2237712039dc298b97095d3bbc6c844
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/1676831
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
