[Intel-gfx] [PATCH] drm/i915: Treat resetting of the current framebuffer as a no-op
Paulo Zanoni
przanoni at gmail.com
Fri May 31 16:05:14 CEST 2013
2013/5/23 Daniel Vetter <daniel at 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 at 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 at 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.
> -Daniel
>
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 981549c..f4450f1 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2286,6 +2286,11 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
>> return -EINVAL;
>> }
>>
>> + if (fb == crtc->fb && crtc->x == x && crtc->y == y) {
>> + DRM_DEBUG_KMS("skipping reset of current fb");
>> + return 0;
>> + }
>> +
>> mutex_lock(&dev->struct_mutex);
>> ret = intel_pin_and_fence_fb_obj(dev,
>> to_intel_framebuffer(fb)->obj,
>> --
>> 1.7.10.4
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
More information about the Intel-gfx
mailing list