summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/nvgpu/vgpu/fifo_vgpu.c
diff options
context:
space:
mode:
authorDeepak Nibade <dnibade@nvidia.com>2015-12-10 03:58:32 -0500
committerTerje Bergstrom <tbergstrom@nvidia.com>2015-12-10 11:39:42 -0500
commitc4ac1ed369cb5737de10924908d97be9f11ec875 (patch)
tree294d2bc504f16cad8653413d63a6b47c6753adaa /drivers/gpu/nvgpu/vgpu/fifo_vgpu.c
parent54f76d1ac6cf0ace524e073076578c891d1b3f79 (diff)
gpu: nvgpu: preempt before adjusting fences
Current sequence in gk20a_disable_channel() is - disable channel in gk20a_channel_abort() - adjust pending fence in gk20a_channel_abort() - preempt channel But this leads to scenarios where syncpoint has min > max value Hence to fix this, make sequence in gk20a_disable_channel() - disable channel in gk20a_channel_abort() - preempt channel in gk20a_channel_abort() - adjust pending fence in gk20a_channel_abort() If gk20a_channel_abort() is called from other API where preemption is not needed, then use channel_preempt flag and do not preempt channel in those cases Bug 1683059 Change-Id: I4d46d4294cf8597ae5f05f79dfe1b95c4187f2e3 Signed-off-by: Deepak Nibade <dnibade@nvidia.com> Reviewed-on: http://git-master/r/921290 Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com> Tested-by: Terje Bergstrom <tbergstrom@nvidia.com>
Diffstat (limited to 'drivers/gpu/nvgpu/vgpu/fifo_vgpu.c')
-rw-r--r--drivers/gpu/nvgpu/vgpu/fifo_vgpu.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/gpu/nvgpu/vgpu/fifo_vgpu.c b/drivers/gpu/nvgpu/vgpu/fifo_vgpu.c
index dd6630a7..3db215bc 100644
--- a/drivers/gpu/nvgpu/vgpu/fifo_vgpu.c
+++ b/drivers/gpu/nvgpu/vgpu/fifo_vgpu.c
@@ -566,7 +566,7 @@ int vgpu_fifo_isr(struct gk20a *g, struct tegra_vgpu_fifo_intr_info *info)
566 break; 566 break;
567 case TEGRA_VGPU_FIFO_INTR_MMU_FAULT: 567 case TEGRA_VGPU_FIFO_INTR_MMU_FAULT:
568 vgpu_fifo_set_ctx_mmu_error(g, ch); 568 vgpu_fifo_set_ctx_mmu_error(g, ch);
569 gk20a_channel_abort(ch); 569 gk20a_channel_abort(ch, false);
570 break; 570 break;
571 default: 571 default:
572 WARN_ON(1); 572 WARN_ON(1);