gpu: nvgpu: runlist update timeout in safety

Runlist update occurs in non-mission mode, when
adding/removing channel/TSGs. The pending bit
is a debug only feature. As a result logging a
warning is sufficient.

We expect other HW safety mechanisms such as
PBDMA timeout to detect issues that caused pending
to not clear. It's possible bad base address could
cause some MMU faults too.

Worst case we rely on the application level task
monitor to detect the GPU tasks are not completing
on time.

Jira NVGPU-4322

Change-Id: I7233770349db5dfad6904170a1e9a2d5eada70b2
Signed-off-by: Thomas Fleury <tfleury@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/2265094
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: Automatic_Commit_Validation_User
Reviewed-by: Deepak Nibade <dnibade@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Vinod Gopalakrishnakurup <vinodg@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
This commit is contained in:
Thomas Fleury
2019-12-18 17:49:22 -05:00
committed by Alex Waterman
parent d10a39e143
commit 5e9bdbc80d

View File

@@ -146,6 +146,19 @@ void nvgpu_rc_runlist_update(struct gk20a *g, u32 runlist_id)
RC_TYPE_RUNLIST_UPDATE_TIMEOUT);
}
#else
/*
* Runlist update occurs in non-mission mode, when
* adding/removing channel/TSGs. The pending bit
* is a debug only feature. As a result logging a
* warning is sufficient.
* We expect other HW safety mechanisms such as
* PBDMA timeout to detect issues that caused pending
* to not clear. It's possible bad base address could
* cause some MMU faults too.
* Worst case we rely on the application level task
* monitor to detect the GPU tasks are not completing
* on time.
*/
WARN_ON(!g->sw_quiesce_pending);
#endif
}