diff options
| author | Rodrigo Vivi <rodrigo.vivi@intel.com> | 2015-03-09 17:57:07 -0700 |
|---|---|---|
| committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2015-03-17 22:30:14 +0100 |
| commit | 03e515f7f8949c0787e0674091d9fbdb8afc4fd3 (patch) | |
| tree | 4ce79236ca6febeecdd028cf4d18e345f9d988f8 /drivers/gpu/drm/i915/intel_fbdev.c | |
| parent | 9cbe40c15a753e02f5da16f6de901decf3276cf1 (diff) | |
| download | talos-obmc-linux-03e515f7f8949c0787e0674091d9fbdb8afc4fd3.tar.gz talos-obmc-linux-03e515f7f8949c0787e0674091d9fbdb8afc4fd3.zip | |
drm/i915: Make sure we invalidate frontbuffer on fbcon.
There are some cases like suspend/resume or dpms off/on sequences
that can flush frontbuffer bits. In these cases features that relies
on frontbuffer tracking can start working and user can stop getting
screen updates on fbcon having impression the system is frozen.
So, let's make sure we also invalidate frontbuffer on fbdev blank.
v2: Daniel was right, backtrace didn't show other path than this blank
one so let's make sure frontbuffer bits gets invalidate here instead of
on random write operations that doesn't garantee we track all frontbuffer
writes.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Exchange code comments for one that complains about the
locking, like in set_par.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_fbdev.c')
| -rw-r--r-- | drivers/gpu/drm/i915/intel_fbdev.c | 27 |
1 files changed, 26 insertions, 1 deletions
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 234a699b8219..757c0d216f80 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -71,6 +71,31 @@ static int intel_fbdev_set_par(struct fb_info *info) return ret; } +static int intel_fbdev_blank(int blank, 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_blank(blank, 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, @@ -79,7 +104,7 @@ static struct fb_ops intelfb_ops = { .fb_copyarea = cfb_copyarea, .fb_imageblit = cfb_imageblit, .fb_pan_display = drm_fb_helper_pan_display, - .fb_blank = drm_fb_helper_blank, + .fb_blank = intel_fbdev_blank, .fb_setcmap = drm_fb_helper_setcmap, .fb_debug_enter = drm_fb_helper_debug_enter, .fb_debug_leave = drm_fb_helper_debug_leave, |
