On Tue, Apr 12, 2011 at 10:41:47AM -0700, Keith Packard wrote: > On Tue, 12 Apr 2011 18:21:23 +0100, Chris Wilson <ch...@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.pack...@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 [<ffffffff810565e5>] warn_slowpath_null+0x15/0x20 [<ffffffffa05185e3>] gen6_gt_force_wake_get+0xf3/0x110 [i915] [<ffffffffa0524875>] i915_driver_irq_handler+0x2175/0x2190 [i915] [<ffffffff8139320d>] ? _raw_spin_unlock_irq+0x3d/0x60 [<ffffffff810c1cb4>] handle_irq_event_percpu+0x74/0x270 [<ffffffff810c1ef3>] handle_irq_event+0x43/0x70 [<ffffffff810c443f>] handle_edge_irq+0x6f/0x120 [<ffffffff8100db5d>] handle_irq+0x1d/0x30 [<ffffffff8100d7d8>] do_IRQ+0x58/0xe0 [<ffffffff81393613>] common_interrupt+0x13/0x13 and all hope was lost. So next up is exactly what Keith recommended. Ben
pgpxaFnkYayXm.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
