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

[Mario Kleiner]

On Feb 8, 2011, at 8:52 PM, Hugh Dickins wrote:
> > 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.

Just a remark, the do_gettimeofday() call is placed where it is  
(Before the spin_lock_irqsave() call for the event_lock), so that  
taking that timestamp (which is only needed later for some  
comparisons) isn't delayed by a possible blocking on that lock.  
Getting the timestamp as early as possible after entering that  
function is needed to make pageflip timestamping more robust.

I'm puzzled why calling do_gettimeofday() could cause any harm, even  
if that code gets executed by accident. I stared at the code for a  
while and couldn't see missing initializations or similar. Maybe it  
would still make sense to try to get some ftrace's on how the code  
there executes, e.g., which path does it actually take or if some  
piece of code takes an unusual and excessive amount of time to execute?

-mario

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/