On 02/05/2019 15:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 15:14:08)
On 02/05/2019 14:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 14:48:18)
On 01/05/2019 12:45, Chris Wilson wrote:
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++++++-
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 851e62ddcb87..7be54b868d8e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct i915_request *rq)
return i915_gem_render_state_emit(rq);
}
+static void execlists_park(struct intel_engine_cs *engine)
+{
+ tasklet_kill(&engine->execlists.tasklet);
Isn't it actually a problem if tasklet is scheduled and unstarted, or
even in progress at the point of engine getting parked?
That would be a broken driver. :|
We must be quite sure that engine isn't going to send an interrupt as we
are just about to drop the wakeref we need to service that interrupt.
tasklet_kill()
GEM_BUG_ON(engine->execlists.active);
Or instead of both:
/* Tasklet must not be running or scheduled at this point. */
GEM_BUG_ON(engine->execlists.tasklet.state);
There's the dilemma that we start parking based on retirement not
final CS event.
But engine->park() is called once the last engine pm reference is
dropped. Are we dropping the last reference with a CS event pending?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
