From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [Intel-gfx] [PATCH] drm/i915: flush cursors harder Date: Mon, 4 Nov 2013 18:58:13 +0200 Message-ID: <20131104165813.GV13047@intel.com> References: <1383549225-16841-1-git-send-email-daniel.vetter@ffwll.ch> <20131104160224.GT13047@intel.com> <20131104163441.GM4167@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20131104163441.GM4167@phenom.ffwll.local> Sender: stable-owner@vger.kernel.org To: Daniel Vetter Cc: Daniel Vetter , Intel Graphics Development , stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org On Mon, Nov 04, 2013 at 05:34:41PM +0100, Daniel Vetter wrote: > On Mon, Nov 04, 2013 at 06:02:24PM +0200, Ville Syrj=E4l=E4 wrote: > > On Mon, Nov 04, 2013 at 08:13:45AM +0100, Daniel Vetter wrote: > > > Apparently they need the same treatment as primary planes. This f= ixes > > > modesetting failures because of stuck cursors (!) on Thomas' i830= M > > > machine. > >=20 > > What treatment? Primary planes don't need any extra posting reads A= =46AIK. >=20 > If you look at flush_primary_plane it's definitely there. So I've cop= ied > it over (it's just a real I915_READ, not a posting one). The regular read is there just so that we don't modify the surface base address. We should be able to replace the read w/ recomputing the address. >=20 > >=20 > > >=20 > > > I've figured while at it I'll also roll it out for the ivb 3 pipe > > > version of this function. I didn't do this for i845/i865 since Bs= pec > > > says the update mechanism works differently, and there's some > > > additional rules about what can be updated in which order. > > >=20 > > > Tested-by: Thomas Richter > >=20 > > I didn't see an explicit note from Thomas saying that he tested it. >=20 > It's burried somewhere in the thread, but he said that with the 2 ear= lier > dvo patches + this one here the lvds-only use-case now works well. Be= fore > that he had issues with the display just showing a cursor and the ker= nel > complaining about the cursor being stuck in the enabled position when > trying to re-enable it. =46rom the mails, I couldn't figure out if he tried them all or just th= e two patches you posted earlier. > -Daniel >=20 > >=20 > > > Cc: stable@vger.kernel.org > > > Cc: Thomas Richter > > > Signed-off-by: Daniel Vetter > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > >=20 > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/d= rm/i915/intel_display.c > > > index f34252d134b6..04d2699f51b4 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_c= rtc *crtc, u32 base) > > > intel_crtc->cursor_visible =3D visible; > > > } > > > /* and commit changes on next vblank */ > > > + POSTING_READ(CURCNTR(pipe)); > > > I915_WRITE(CURBASE(pipe), base); > > > + POSTING_READ(CURBASE(pipe)); > > > } > > > =20 > > > static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) > > > @@ -7152,7 +7154,9 @@ static void ivb_update_cursor(struct drm_cr= tc *crtc, u32 base) > > > intel_crtc->cursor_visible =3D visible; > > > } > > > /* and commit changes on next vblank */ > > > + POSTING_READ(CURCNTR_IVB(pipe)); > > > I915_WRITE(CURBASE_IVB(pipe), base); > > > + POSTING_READ(CURBASE_IVB(pipe)); > > > } > > > =20 > > > /* If no-part of the cursor is visible on the framebuffer, then = the GPU may hang... */ > > > --=20 > > > 1.8.4.rc3 > > >=20 > > > _______________________________________________ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > >=20 > > --=20 > > Ville Syrj=E4l=E4 > > Intel OTC > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >=20 > --=20 > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch --=20 Ville Syrj=E4l=E4 Intel OTC