Re: [Intel-gfx] [PATCH] drm/i915: irq handlers don't need interrupt-safe spinlocks

2013-06-28 Thread Paulo Zanoni
2013/6/27 Daniel Vetter : > On Thu, Jun 27, 2013 at 11:14 PM, Paulo Zanoni wrote: >> 2013/6/25 Daniel Vetter : >>> Since we only have one interrupt handler and interrupt handlers are >>> non-reentrant. >>> >>> To drive the point really home give them all an _irq_handler suffix. >> >> Could we also

Re: [Intel-gfx] [PATCH] drm/i915: irq handlers don't need interrupt-safe spinlocks

2013-06-27 Thread Daniel Vetter
On Thu, Jun 27, 2013 at 11:14 PM, Paulo Zanoni wrote: > 2013/6/25 Daniel Vetter : >> Since we only have one interrupt handler and interrupt handlers are >> non-reentrant. >> >> To drive the point really home give them all an _irq_handler suffix. > > Could we also add WARN(!in_irq()) or something e

Re: [Intel-gfx] [PATCH] drm/i915: irq handlers don't need interrupt-safe spinlocks

2013-06-27 Thread Paulo Zanoni
2013/6/25 Daniel Vetter : > Since we only have one interrupt handler and interrupt handlers are > non-reentrant. > > To drive the point really home give them all an _irq_handler suffix. Could we also add WARN(!in_irq()) or something equivalent for better protection? Big backtraces are a nice way t

[Intel-gfx] [PATCH] drm/i915: irq handlers don't need interrupt-safe spinlocks

2013-06-25 Thread Daniel Vetter
Since we only have one interrupt handler and interrupt handlers are non-reentrant. To drive the point really home give them all an _irq_handler suffix. This is a tiny micro-optimization but even more important it makes it clearer what locking we actually need. And in case someone screws this up: