From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 0/9] drm/i915: Plane assert/readout cleanups etc. Date: Thu, 12 Oct 2017 15:29:01 +0200 Message-ID: <20171012132901.GC4453@ulmo> References: <20171011160455.1874-1-ville.syrjala@linux.intel.com> <20171012113520.GA18419@ulmo> <20171012121953.GE10981@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0051526242==" Return-path: Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id 277B86E82F for ; Thu, 12 Oct 2017 13:29:05 +0000 (UTC) Received: by mail-qk0-x242.google.com with SMTP id l194so1200327qke.13 for ; Thu, 12 Oct 2017 06:29:05 -0700 (PDT) In-Reply-To: <20171012121953.GE10981@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: intel-gfx@lists.freedesktop.org, Alex =?utf-8?B?VmlsbGFjw61z?= Lasso List-Id: intel-gfx@lists.freedesktop.org --===============0051526242== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 12, 2017 at 03:19:53PM +0300, Ville Syrj=C3=A4l=C3=A4 wrote: > On Thu, Oct 12, 2017 at 01:35:20PM +0200, Thierry Reding wrote: > > On Wed, Oct 11, 2017 at 07:04:46PM +0300, Ville Syrjala wrote: > > > From: Ville Syrj=C3=A4l=C3=A4 > > >=20 > > > This series aims to clean up some of the plane state readout and > > > sanitation, and clean up the enum plane mess a bit by renaming it > > > to enum old_plane_id. > > >=20 > > > The one actual bugfix here is the plane<->crtc sanitation > > > change. Previously we tried to shut down the entire pipe when > > > the plane mapping wasn't what we want, now we just shut down the > > > plane, which is easier. > > >=20 > > > Most of the other stuff is just polish, but I also decided to > > > throw the gen2/3 and chv primary plane windowing support on on top > > > just because it's been bugging me for years, and I was already > > > in the neighbourhood. > > >=20 > > > Series available here: > > > git://github.com/vsyrjala/linux.git plane_sanitation_2 > > >=20 > > > Cc: Thierry Reding > > > Cc: Alex Villac=C3=ADs Lasso > > >=20 > > > Ville Syrj=C3=A4l=C3=A4 (9): > > > drm/i915: Add .get_hw_state() method for planes > > > drm/i915: Redo plane sanitation during readout > > > drm/i915: s/enum plane/enum old_plane_id/ > > > drm/i915: Use enum old_plane_id for the .get_fifo_size() hooks > > > drm/i915: Cleanup enum pipe/enum plane_id/enum old_plane_id in init= ial > > > fb readout > > > drm/i915: Nuke ironlake_get_initial_plane_config() > > > drm/i915: Switch fbc over to for_each_new_intel_plane_in_state() > > > drm/i915: Nuke crtc->plane > > > drm/i915: Add windowing for primary planes on gen2/3 and chv > > >=20 > > > drivers/gpu/drm/i915/i915_drv.h | 16 +- > > > drivers/gpu/drm/i915/intel_display.c | 500 +++++++++++++++----------= ---------- > > > drivers/gpu/drm/i915/intel_drv.h | 8 +- > > > drivers/gpu/drm/i915/intel_fbc.c | 27 +- > > > drivers/gpu/drm/i915/intel_pm.c | 36 +-- > > > drivers/gpu/drm/i915/intel_sprite.c | 43 +++ > > > 6 files changed, 299 insertions(+), 331 deletions(-) > >=20 > > I take it that this is the same as the plane_sanitation branch that I > > tested on yesterday, >=20 > Close enough ;) >=20 > > and it fixes both issues I had seen, >=20 > One was the plane assert. What was the other one? Yes, the plane assert is what I think was related to the weird corruption that I've been seeing since 4.13 (the first two lines in the framebuffer console stay around, the rest of the screen is offset by those two lines, so the last two lines aren't visible). The second issue I was seeing, for much longer than 4.13, I think maybe as far back as 4.9 or so, was that the display would stay black after resuming from suspend-to-disk (though suspend-to-RAM worked fine). This could possibly be related to the plane assert, too, but I was never able to properly diagnose because the device was unresponsive after the failing resume. Both of these are gone with this series applied (or the plane_sanitation branch merged int next-20171009, rather). Thanks for fixing it! Thierry --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlnfbh0ACgkQ3SOs138+ s6HucA//aPSVUeWJK82slJJMLQku87cmiQo1fO7dmSln7nCL3GN7CNnhcENzrVtw zEkD0Tp8NPcYsr7To5vWqXSjMdYI4t40ud2qJmE7XRR6T9BYbqXSiyu8h6GEqiKM poGNct0HqyjQWwmiAJav9esmfFrFN994ghu8lpHhE1TiVssAwc308AQB7skon4U2 YsWOUwL11h3NFfzd8h0SkyK0TkZY+CwP5GyGA/8DROFZhcggbnX3VNS8q8Jj1i5j cdjiscn9+moAe0GgXSrBxasVv5OZ/MjgpMMhVP5tww1DfhQ7J/YXwFMFFgtU/uCN rcTxd4NhgR3d7GKXwQhtYBF0RL3qBIEcdHeZKT3Jc23ILR8M8KOJlrXHqnwxMkSj hE91ukc+sYHr30DQ9TqwlCayug4IO/RyL51TCzJib9dAQv9zGZ+ydE7ofu8HDnvr WkK7j7ihw219fJpQq6JYMqFXYGe78HmYCKSAbM1oHa1Er2pgKQEkniUJSeoM1OA8 CRmoG8SV2CA2t8YVIbMpqNbkBcblmQA79AaN5fKKCOI7V3an+Avl28qHOwhoWzie x+LdMSTZyEVH1EEtzH8H8hAH9s05olHJ14ffdSG77lCWZPhzROjK3TnhqxKMYj5m gu498vT8rnJBifqvwVMba8J7Onm+FfLB8sysL835r9CPvrEsFUI= =mwNT -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- --===============0051526242== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0051526242==--