[Intel-gfx] [PATCH] drm/i915: Another fbdev hack to avoid PSR on fbcon.

Rodrigo Vivi rodrigo.vivi at gmail.com
Thu May 28 10:37:27 PDT 2015


Hi Matthew,

Could you please check if this patch solves the issue you were facing
with PSR enabled with missed screen updates on fbcon?

Thanks in advance,
Rodrigo.

On Thu, May 28, 2015 at 10:26 AM, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
> With unified modeset and flip paths introduced recently when switching
> to fbcon PSR was being disabled on fb_set_par path but re-enabled on
> fb_pan_display one, causing missed screen updates and un unusable
> console.
>
> Regression introduced with:
>
> commit bb54662350662815b4bfc2ff4464330a2dbd7041
> Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
> Date:   Tue Apr 21 17:13:13 2015 +0300
>
>     drm/i915: Unify modeset and flip paths of intel_crtc_set_config()
>
> Cc: Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 28 +++++++++++++++++++++++++++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> index 4e7e7da..6372cfc 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -96,6 +96,32 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
>         return ret;
>  }
>
> +static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
> +                                  struct fb_info *info)
> +{
> +       struct drm_fb_helper *fb_helper = info->par;
> +       struct intel_fbdev *ifbdev =
> +               container_of(fb_helper, struct intel_fbdev, helper);
> +
> +       int ret;
> +       ret = drm_fb_helper_pan_display(var, info);
> +
> +       if (ret == 0) {
> +               /*
> +                * FIXME: fbdev presumes that all callbacks also work from
> +                * atomic contexts and relies on that for emergency oops
> +                * printing. KMS totally doesn't do that and the locking here is
> +                * by far not the only place this goes wrong.  Ignore this for
> +                * now until we solve this for real.
> +                */
> +               mutex_lock(&fb_helper->dev->struct_mutex);
> +               intel_fb_obj_invalidate(ifbdev->fb->obj, NULL, ORIGIN_GTT);
> +               mutex_unlock(&fb_helper->dev->struct_mutex);
> +       }
> +
> +       return ret;
> +}
> +
>  static struct fb_ops intelfb_ops = {
>         .owner = THIS_MODULE,
>         .fb_check_var = drm_fb_helper_check_var,
> @@ -103,7 +129,7 @@ static struct fb_ops intelfb_ops = {
>         .fb_fillrect = cfb_fillrect,
>         .fb_copyarea = cfb_copyarea,
>         .fb_imageblit = cfb_imageblit,
> -       .fb_pan_display = drm_fb_helper_pan_display,
> +       .fb_pan_display = intel_fbdev_pan_display,
>         .fb_blank = intel_fbdev_blank,
>         .fb_setcmap = drm_fb_helper_setcmap,
>         .fb_debug_enter = drm_fb_helper_debug_enter,
> --
> 2.1.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br


More information about the Intel-gfx mailing list