Revision f2efc6e60089c99c342a6b7da47f1037e06c4296 authored by Shirish S on 30 October 2019, 08:50:46 UTC, committed by Alex Deucher on 06 November 2019, 20:26:53 UTC
[Why] doing kthread_park()/unpark() from drm_sched_entity_fini while GPU reset is in progress defeats all the purpose of drm_sched_stop->kthread_park. If drm_sched_entity_fini->kthread_unpark() happens AFTER drm_sched_stop->kthread_park nothing prevents from another (third) thread to keep submitting job to HW which will be picked up by the unparked scheduler thread and try to submit to HW but fail because the HW ring is deactivated. [How] grab the reset lock before calling drm_sched_entity_fini() Signed-off-by: Shirish S <shirish.s@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
1 parent 576daab
File | Mode | Size |
---|---|---|
Kconfig | -rw-r--r-- | 4.3 KB |
Makefile | -rw-r--r-- | 307 bytes |
ftrace.c | -rw-r--r-- | 3.0 KB |
inode.c | -rw-r--r-- | 9.7 KB |
internal.h | -rw-r--r-- | 1.2 KB |
platform.c | -rw-r--r-- | 18.4 KB |
pmsg.c | -rw-r--r-- | 1.9 KB |
ram.c | -rw-r--r-- | 24.8 KB |
ram_core.c | -rw-r--r-- | 14.7 KB |
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...