On Mon, Sep 15, 2014 at 11:56 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, Sep 15, 2014 at 11:51:42AM +0200, Daniel Vetter wrote: >> On Mon, Sep 15, 2014 at 11:48 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >> > intel_engine_cs *ring) >> >> struct drm_i915_private *dev_priv = dev->dev_private; >> >> unsigned long flags; >> >> >> >> + WARN_ON(!intel_irqs_enabled(dev_priv)); >> > >> > Please no. This would be a BUG(). >> >> No BUG if not doing it means the driver will survive for a bit longer. >> And doing a few bogus register writes usually means it'll surive. > > I mean that this offers no additional benefit over the first WARN. Which > is already redundant as we WARN in the caller. There are more meaningful > places where that WARN would be appropriate, but after the event of > something else screwing up is usually close to useless. If we drop the runtime pm reference before the put_irq then we'll WARN here. Which is somewhat likely if some waiter doesn't have it's own runtime pm reference but relies upon someone else holding that for him. Then the get_irq will likely happen while the gpu is still busy, but the put_irq has a good chance to only happen once we've cleaned up. Of course it might mean that we get 2 backtraces in some case if e.g. a wait happens somehow before anything is really set up (in driver load). But I think the additional coverage makes this worth it. If it's too annoying we can always back it out again. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
