drm/i915: Mark up the calling context for intel_wakeref_put()
Previously, we assumed we could use mutex_trylock() within an atomic context, falling back to a worker if contended. However, such trickery is illegal inside interrupt context, and so we need to always use a worker under such circumstances. As we normally are in process context, we can typically use a plain mutex, and only defer to a work when we know we are being called from an interrupt path. Fixes:51fbd8de87
("drm/i915/pmu: Atomically acquire the gt_pm wakeref") References:a0855d24fc
("locking/mutex: Complain upon mutex API misuse in IRQ contexts") References: https://bugs.freedesktop.org/show_bug.cgi?id=111626 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191120125433.3767149-1-chris@chris-wilson.co.uk
This commit is contained in:
@ -51,11 +51,12 @@ static int live_engine_pm(void *arg)
|
||||
pr_err("intel_engine_pm_get_if_awake(%s) failed under %s\n",
|
||||
engine->name, p->name);
|
||||
else
|
||||
intel_engine_pm_put(engine);
|
||||
intel_engine_pm_put(engine);
|
||||
intel_engine_pm_put_async(engine);
|
||||
intel_engine_pm_put_async(engine);
|
||||
p->critical_section_end();
|
||||
|
||||
/* engine wakeref is sync (instant) */
|
||||
intel_engine_pm_flush(engine);
|
||||
|
||||
if (intel_engine_pm_is_awake(engine)) {
|
||||
pr_err("%s is still awake after flushing pm\n",
|
||||
engine->name);
|
||||
|
Reference in New Issue
Block a user