All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: [PATCH 4/4] drm/i915: fbdev dirty calls fb user dirty to invalidate frontbuffer.
Date: Mon, 29 Jun 2015 13:44:46 -0700	[thread overview]
Message-ID: <1435610686-2249-4-git-send-email-rodrigo.vivi@intel.com> (raw)
In-Reply-To: <1435610686-2249-1-git-send-email-rodrigo.vivi@intel.com>

Now that we have fb user dirty invalidating frontbuffer and we have
the new fbdev dirty callback let's merge them.

So it doesn't matter if fbcon throught fbdev or splash screen throught
drm_ioctl_dirtyfb, in any case we will have frontbuffer properly
invalidated and power savings features that rely on frontbuffer tracking
will be able to work as expected.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/intel_fbdev.c | 86 ++++++--------------------------------
 1 file changed, 13 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 2a1724e..f1592c7 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -45,92 +45,32 @@
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
 
-static int intel_fbdev_set_par(struct fb_info *info)
+static void intel_fbdev_dirty(struct fb_info *info, u32 x1, u32 y1,
+			      u32 x2, u32 y2)
 {
 	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_set_par(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);
-		ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj,
-							true);
-		mutex_unlock(&fb_helper->dev->struct_mutex);
-	}
-
-	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, ORIGIN_GTT);
-		mutex_unlock(&fb_helper->dev->struct_mutex);
-	}
-
-	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, ORIGIN_GTT);
-		mutex_unlock(&fb_helper->dev->struct_mutex);
-	}
+	struct intel_framebuffer *intel_fb = ifbdev->fb;
+	struct drm_framebuffer *fb = &intel_fb->base;
 
-	return ret;
+	/*
+	 * Our fb dirty callback is just used to invalidate frontbuffer
+	 * entirely. So just fb reference is needed and rest is ignored.
+	 */
+	fb->funcs->dirty(fb, NULL, 0, 0, NULL, 1);
 }
 
 static struct fb_ops intelfb_ops = {
 	.owner = THIS_MODULE,
 	.fb_check_var = drm_fb_helper_check_var,
-	.fb_set_par = intel_fbdev_set_par,
+	.fb_set_par = drm_fb_helper_set_par,
 	.fb_fillrect = cfb_fillrect,
 	.fb_copyarea = cfb_copyarea,
 	.fb_imageblit = cfb_imageblit,
-	.fb_pan_display = intel_fbdev_pan_display,
-	.fb_blank = intel_fbdev_blank,
+	.fb_dirty = intel_fbdev_dirty,
+	.fb_pan_display = drm_fb_helper_pan_display,
+	.fb_blank = drm_fb_helper_blank,
 	.fb_setcmap = drm_fb_helper_setcmap,
 	.fb_debug_enter = drm_fb_helper_debug_enter,
 	.fb_debug_leave = drm_fb_helper_debug_leave,
-- 
2.1.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-06-29 20:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29 20:44 [PATCH 1/4] drm/i915: Make fb user dirty operation to invalidate frontbuffer Rodrigo Vivi
2015-06-29 20:44 ` [PATCH 2/4] fbdev: Introduce fb_dirty operation Rodrigo Vivi
2015-06-30  7:07   ` Daniel Vetter
2015-06-29 20:44 ` [PATCH 3/4] drm/udl: Use fb_dirty ops to simplify damage calls Rodrigo Vivi
2015-06-29 20:44 ` Rodrigo Vivi [this message]
2015-06-30  7:11   ` [Intel-gfx] [PATCH 4/4] drm/i915: fbdev dirty calls fb user dirty to invalidate frontbuffer Daniel Vetter
2015-06-30 22:44     ` Rodrigo Vivi
2015-07-01 10:31   ` shuang.he
2015-06-29 21:36 ` [PATCH] " Rodrigo Vivi
2015-06-30  6:55 ` [Intel-gfx] [PATCH 1/4] drm/i915: Make fb user dirty operation " Daniel Vetter
2015-06-30 22:41   ` Rodrigo Vivi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1435610686-2249-4-git-send-email-rodrigo.vivi@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.