linux-kernel - Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.00.1102081132160.1591@sister.anvils>
Date:	Tue, 8 Feb 2011 11:52:45 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Mario Kleiner <mario.kleiner@...bingen.mpg.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

On Wed, 2 Feb 2011, Jesse Barnes wrote:
> On Tue, 1 Feb 2011 19:37:09 -0800
> Hugh Dickins <hughd@...gle.com> wrote:
> 
> > On Tue, Feb 1, 2011 at 11:32 AM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> > 
> > > What I find strange is that you're seeing flip pending interrupts.  Are
> > > your symptoms affected if you remove the
> > > I915_DISPLAY_PLANE_[AB]_FLIP_PENDING_INTERRUPT lines from
> > > I915_INTERRUPT_ENABLE_FIX at the top of i915_irq.c?
> > 
> > No.  The first time it looked like yes it fixed it; but when I
> > rebooted again, same symptoms and same underruns back: this thing is
> > very erratic.
> > 
> > > Do you see any calls to drm_mode_page_flip_ioctl() in your environment?
> > 
> > None at all.
> > 
> > Sometime I should do a bisection between v2.6.36 and v2.6.37 to see
> > what started the underruns; but I can't promise when "sometime" will
> > arrive.
> 
> But presumably the FLIP_PENDING_INTERRUPT bits are stuck on in your
> case, otherwise we wouldn't be getting to flip prepare/finish at all.
> 
> Some updated docs indicate those bits may not be reliable on 965
> (though earlier ones did), so we may need to disable the flip code
> entirely on 965 if we can't figure out what's going wrong on your
> config...

Sometime arrived, I did a bisection between v2.6.36 and v2.6.37,
and my "pipe a underrun"s on 965 begin with 29e1316ab129 drm/i915/tv:
Sleep before checking for state changes (appended below).

But that's a necessary patch for me: without it both VESA framebuffer
and X mistake the size and shape of the laptop screen, and my windows
don't fit in properly.

I experimented a little with intel_tv.c on 2.6.38-rc3 and rc4.
Indeed, just deleting that intel_wait_for_vblank() stops the underruns,
but leaves the display missized.  Replacing it by msleep(20), as used to
be done, behaves the same as with intel_wait_for_vblank() there: underruns
with correctly sized display.  "#if 0"ing all of intel_tv_detect_type(),
just returning -1 from it, gives no underruns and correctly sized display.

I was going to work with the latter, when my original unflushed text
problem resurfaced again (just as it had later done when trying Chris's
"Suppress spurious vblank interrupts" patch).  It appears that the
underruns, while mysterious and worrisome, have litte or nothing to do
with the unflushed text problem which is making 2.6.38-rc unusable.

For the moment I've gone back to my patch moving intel_display.c's
do_gettimeofday() call into the block where it's needed; though that
too disappointed eventually before.  It all rather stinks of something
uninitialized somewhere.

Hugh

commit 29e1316ab129f2d3a9ea874e7c9a4cb936f43542
Author: Chris Wilson <chris@...is-wilson.co.uk>
Date:   Wed Sep 22 19:10:09 2010 +0100

    drm/i915/tv: Sleep before checking for state changes.

    We need to wait for the PLLs to settle prior to detecting the state
    changes. The BIOS writers guide suggests waiting for the next vblank.

    Reported-by: Carlos R. Mafra <crmafra2@...il.com>
    Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 49ab11c..106560b 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1271,8 +1271,12 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
 	I915_WRITE(TV_DAC, tv_dac);
 	POSTING_READ(TV_DAC);

+	intel_wait_for_vblank(intel_tv->base.base.dev,
+			      to_intel_crtc(intel_tv->base.base.crtc)->pipe);
+
 	type = -1;
 	if (wait_for((tv_dac = I915_READ(TV_DAC)) & TVDAC_STATE_CHG, 20) == 0) {
+		DRM_DEBUG_KMS("TV detected: %x, %x\n", tv_ctl, tv_dac);
 		/*
 		 *  A B C
 		 *  0 1 1 Composite
@@ -1289,8 +1293,7 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
 			DRM_DEBUG_KMS("Detected Component TV connection\n");
 			type = DRM_MODE_CONNECTOR_Component;
 		} else {
-			DRM_DEBUG_KMS("Unrecognised TV connection: %x\n",
-				      tv_dac);
+			DRM_DEBUG_KMS("Unrecognised TV connection\n");
 		}
 	}