From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Subject: Re: [PATCH] drm/i915: paper over missed irq issues with force wake vodoo Date: Fri, 13 Jan 2012 16:50:39 -0800 Message-ID: <86boq73y5c.fsf@sumi.keithp.com> References: <1325702445-2231-1-git-send-email-daniel.vetter@ffwll.ch> <86lipb367b.fsf@sumi.keithp.com> <20120113235231.GE3843@phenom.ffwll.local> <86k44v3zy8.fsf@sumi.keithp.com> <20120114003140.GG3843@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0920604143==" Return-path: Received: from keithp.com (home.keithp.com [63.227.221.253]) by gabe.freedesktop.org (Postfix) with ESMTP id 5927F9E841 for ; Fri, 13 Jan 2012 16:50:43 -0800 (PST) In-Reply-To: <20120114003140.GG3843@phenom.ffwll.local> 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: Daniel Vetter Cc: Daniel Vetter , intel-gfx , Eugeni Dodonov , stable@kernel.org List-Id: intel-gfx@lists.freedesktop.org --===============0920604143== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Sat, 14 Jan 2012 01:31:40 +0100, Daniel Vetter wrote: > On Fri, Jan 13, 2012 at 04:11:43PM -0800, Keith Packard wrote: > > On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wro= te: > > > acc101d drm/i915: Hold gt_lock across forcewake register reads > > >=20 > > > Imo this is a simple cleanup (reading forcewake-protected registers i= sn't > > > really a fast-path for us), so material for -next. > >=20 > > The 'optimization' is just a side benefit. The fix is to prevent reads > > From happening without forcewake being set. >=20 > I still fail to see how you can sneak a read in there without forcewake > being asserted. And assuming I haven't understood you the last time around > we've discussed this, you've agreed. Yes, except during reset, where forcewake is cleared even if the lock count is non-zero. Any reads happening while reset is going on will return garbage. None of this is 'required' given the structure of the code today, it just makes it all evident without having to go through yet another long sequence of explanations. I had patches to hold the spinlock across register writes too, as using different locking for reading and writing seems like a bad plan, but I didn't put those in because writes involve spinning to wait for the fifo to drain, and that seemed like a bad thing to do while holding the spinlock. =2D-=20 keith.packard@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIVAwUBTxDRXzYtFsjWk68qAQi1ORAAkbpQMhYnWQ3KI5kAMk4lS1E+bgba2NOU xVlBaxANhY3u0FsGm5urxaw4bd8pb4zeMrFu4kmjlNhgi7k/9yAUFeaPr4sgsSRc 1PZ1nsk+0S4xzvc6peGhrG5mGKDZ0bN7+dLGdkKPncK6C40Y9ybX5JN5sjQaj/Kb rcnvnshx2sPjzOUqzFbowsy76OaN0dZGzaQpNZxLHABVx33YfWvEEnr+YGUdVzAM JUqXAYfSFz22z8c/zffaG78TbJo0BiatrUbhvPuOHFSZutTLnfw8cHYHWeuh47UJ 49JZzyLi/FHHQ3Y/x5vNaTpMdNmgBHlUeyXu1CdxwemIbPXu9OjLAAgQLKmZFgcM Rf/WXnC9Ljy18Wm7r5hwKbfEDBTkcUvgZBoqr5U2Uf4GaDJY/e7I/I2SE7puw3YA sztyAC4kMf9+O3viG84uqwtq7Z1GYemiDnwvjt8itDZqR7EFAtKYvjPT6QP9WwxY HSVCJ098Imk6B8mdRD4KKhEUtfXPSMRvHcK21SCzsKCDPj/BH3saWdAh095C1Xhx EM8UxakdYy/JVwDiUH7XEpjWy5MNKnUO07Mz6NjkvYx/C2ImHQQwjoLCwrtZK0d0 E41Ph9pKwpr8ROWgq21asWxi3cbCyGHLbtzVWK6E6cTV38G++rcAjEvYjSEFTe/9 acUeGeMgyxU= =UnCM -----END PGP SIGNATURE----- --=-=-=-- --===============0920604143== 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 --===============0920604143==--