[Intel-gfx] [PATCH 2/2] drm/i915: Fix irq checks in ring->irq_get/put functions

Daniel Vetter daniel.vetter at ffwll.ch
Mon Sep 15 12:08:39 CEST 2014


On Mon, Sep 15, 2014 at 11:56 AM, Chris Wilson <chris at chris-wilson.co.uk> 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 at chris-wilson.co.uk> 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



More information about the Intel-gfx mailing list