From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm/i915: Properly track domain of the fbcon fb Date: Wed, 18 Jun 2014 17:57:39 +0200 Message-ID: <20140618155739.GL5821@phenom.ffwll.local> References: <1403092757-31421-12-git-send-email-daniel.vetter@ffwll.ch> <1403096719-26844-1-git-send-email-daniel.vetter@ffwll.ch> <20140618145749.GR31023@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 7CCE989DAB for ; Wed, 18 Jun 2014 08:57:46 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so1043999wgh.26 for ; Wed, 18 Jun 2014 08:57:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140618145749.GR31023@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , Daniel Vetter , Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Wed, Jun 18, 2014 at 03:57:49PM +0100, Chris Wilson wrote: > On Wed, Jun 18, 2014 at 03:05:19PM +0200, Daniel Vetter wrote: > > X could end up putting the fbcon fb into other domains, e.g. > > for smooth take-overs. Also we want this for accurate frontbuffer > > tracking: The set_config is an implicit flush and will re-enable > > psr and similar features, so we need to bring the bo back into > > the gtt domain. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/i915/intel_fbdev.c | 21 ++++++++++++++++++++- > > 1 file changed, 20 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c > > index 27975c3e21c5..53c50240d1c2 100644 > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > @@ -43,10 +43,29 @@ > > #include > > #include "i915_drv.h" > > > > +static int intel_fbdev_set_par(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_set_par(info); > > + > > + if (ret == 0) { > > Add a comment here saying you are happy with the potential deadlock, > double-fault and what not, and I'll accept it with provisons that I'll > still worry that this will explode in our faces. /* * 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. */ Like this? -Daniel > > > + 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 struct fb_ops intelfb_ops = { > > .owner = THIS_MODULE, > > .fb_check_var = drm_fb_helper_check_var, > > - .fb_set_par = drm_fb_helper_set_par, > > + .fb_set_par = intel_fbdev_set_par, > > .fb_fillrect = cfb_fillrect, > > .fb_copyarea = cfb_copyarea, > > .fb_imageblit = cfb_imageblit, > > -- > > 2.0.0 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@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