[Intel-gfx] force wake reference counting (another try)
ben at bwidawsk.net
Tue Apr 12 18:31:51 PDT 2011
On Tue, Apr 12, 2011 at 10:41:47AM -0700, Keith Packard wrote:
> On Tue, 12 Apr 2011 18:21:23 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > Agreed. I had been working under the assumption that dev->struct_mutex was
> > the sufficient lock. This may be entirely due to the false premise that we
> > only needed i915_gt_read() for the ring registers. I still haven't looked
> > through just what registers are impacted.
> Seems like we should start using a spinlock and wake lock around all
> register accesses, then figure out which registers are not within the GT
> power well and split those off to a separate macro which avoids both. If
> we finally discover that all wake-lock requiring registers are now
> obviously covered by the struct mutex, we could then consider removing
> the spinlock.
> Make it work, then make it fast.
> keith.packard at intel.com
I think we have no other option since the first thing that
i915_driver_irq_handler() does is read IIR, which according to the limited
knowledge I have requires forcewake.
I was hoping if I could just fix the current issues, which is mostly
focused around fbc, we'd be fine, but then I saw this backtrace:
<IRQ> [<ffffffff8105659a>] warn_slowpath_common+0x7a/0xb0
[<ffffffffa05185e3>] gen6_gt_force_wake_get+0xf3/0x110 [i915]
[<ffffffffa0524875>] i915_driver_irq_handler+0x2175/0x2190 [i915]
[<ffffffff8139320d>] ? _raw_spin_unlock_irq+0x3d/0x60
and all hope was lost.
So next up is exactly what Keith recommended.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
More information about the Intel-gfx