From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: force wake reference counting (another try) Date: Tue, 12 Apr 2011 18:31:51 -0700 Message-ID: <20110413013151.GB30729@bwgnt.jf.intel.com> References: <1302570079-17032-1-git-send-email-ben@bwidawsk.net> <1bdc18$k6h5tu@fmsmga002.fm.intel.com> <20110412163022.GA12791@snipes.kumite> <1bdc18$k6n2j0@fmsmga002.fm.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0517859852==" Return-path: Received: from cloud01.chad-versace.us (184-106-247-128.static.cloud-ips.com [184.106.247.128]) by gabe.freedesktop.org (Postfix) with ESMTP id E72EA9E761 for ; Tue, 12 Apr 2011 18:31:54 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Keith Packard Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0517859852== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2011 at 10:41:47AM -0700, Keith Packard wrote: > On Tue, 12 Apr 2011 18:21:23 +0100, Chris Wilson wrote: >=20 > > 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 look= ed > > through just what registers are impacted. >=20 > 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. >=20 > Make it work, then make it fast. >=20 > --=20 > 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: [] warn_slowpath_common+0x7a/0xb0 [] warn_slowpath_null+0x15/0x20 [] gen6_gt_force_wake_get+0xf3/0x110 [i915] [] i915_driver_irq_handler+0x2175/0x2190 [i915] [] ? _raw_spin_unlock_irq+0x3d/0x60 [] handle_irq_event_percpu+0x74/0x270 [] handle_irq_event+0x43/0x70 [] handle_edge_irq+0x6f/0x120 [] handle_irq+0x1d/0x30 [] do_IRQ+0x58/0xe0 [] common_interrupt+0x13/0x13 and all hope was lost. So next up is exactly what Keith recommended. Ben --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBAgAGBQJNpP0HAAoJEL9nTIiJEj0pHLUH/2dXXsrsdWfOsn852IAl+a0s q3RqKP5LVqgQGo99W6gnZlv4usb0zTxg1Gz1AebRRsdXvLxFppPabs0Kp8wkQuUv EOsF6Z52y/aG/L1mMtS45NxFDa7ARVT6Qd7dp9A4+IlotEN6s+YLgwMCbychjWJb pkiPeroBKiqqdebonDXX9I+bHTP2qkz/eQ3q4epScUQwDPmNIB/VSbAMeD+XW9K6 PEdL6yGO2YYVcHtbGGLhxwv80hyYsb52TXTmmkmVJbNGvjGo9EHglEBRjWoeNtVi +WTXfH8/rEypfxWkNh0ya/JNd+zx48R6gRhMR6LGSWxyBDl8cP0NwOoQscU94T0= =bDlK -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- --===============0517859852== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0517859852==--