Re: force wake reference counting (another try)

From: Ben Widawsky <ben@bwidawsk.net>
To: Keith Packard <keithp@keithp.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: force wake reference counting (another try)
Date: Tue, 12 Apr 2011 18:31:51 -0700	[thread overview]
Message-ID: <20110413013151.GB30729@bwgnt.jf.intel.com> (raw)
In-Reply-To: <yunipujpdt0.fsf@aiko.keithp.com>

[-- Attachment #1.1: Type: text/plain, Size: 1898 bytes --]

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@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@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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx