Re: [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, May 31, 2013 at 05:15:10PM +0200, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 4:05 PM, Paulo Zanoni <przanoni@gmail.com> wrote:
> > 2013/5/23 Daniel Vetter <daniel@ffwll.ch>:
> >> On Thu, May 23, 2013 at 01:57:17PM +0100, Chris Wilson wrote:
> >>> If none of the CRTC parameters change along with the framebuffer, we can
> >>> forgo rewriting the register and waiting for a vblank. There are a few
> >>> calls made by the display managers as they start up which tend to end up
> >>> performing no-ops on the current CRTC settings.
> >>>
> >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>
> >> Makes sense. Queued for -next, thanks for the patch. Now the only things
> >> left (besides beating fastboot into good shape) is to cache the edids a
> >> bit and we've (hopefully) killed all kms stalls at startup ...
> >
> > This commit introduced a regression.
> >
> > - Boot with both eDP and DP plugged
> > - When I boot like this, eDP1 has 1920x1080 and DP1 has 1920x1080i.
> > - Run "xrandr --output DP1 --mode 0x55" (that's 1024x768@60Hz here)
> > - See the black screen on DP output, dmesg has the "skipping reset of
> > current fb" message.
> > - After we get the black screen, if we run "xrandr --output DP1 --off;
> > xrandr --output DP1 --mode 0x55" the mode will work.
> >
> > If I diff the "bad state" with the "good state" we'll see the cause is
> > the DSPCNTR register. When we do the early return in
> > intel_pipe_set_base we don't call the update_plane function. For me
> > what changes is the pixel format and the trickle feed bits.
> 
> Oh, in the modeset case we can't optimize the update_fb away, even
> when both fbs are the same ...

I think there are two problems currently:

1) .crtc_mode_set will clear DSPCNTR, so .update_plane() is needed to
   re-populate the relevant bits

2) We no longer do a tiling_mode check on the obj. That's done in
   intel_pin_and_fence_fb_obj() which is now skipped too.

   I've been pondering whether we should just prevent tiling changes
   for any obj with fbs...

> 
> Just to check that our level of paranoia is still high enough: Has the
> modeset state checker complained or not?
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC