public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm/i915: Tear down fbdev if initialization fails
Date: Thu, 19 Nov 2015 21:26:40 +0100	[thread overview]
Message-ID: <20151119202640.GA25466@wunner.de> (raw)
In-Reply-To: <20151119160204.GL17050@phenom.ffwll.local> <20151119155844.GK17050@phenom.ffwll.local>

Hi again,

On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote:
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -408,7 +408,10 @@ static void intel_connector_add_to_fbdev(struct intel_connector *connector)
> >  {
> >  #ifdef CONFIG_DRM_FBDEV_EMULATION
> >  	struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > -	drm_fb_helper_add_one_connector(&dev_priv->fbdev->helper, &connector->base);
> > +
> > +	if (dev_priv->fbdev)
> > +		drm_fb_helper_add_one_connector(&dev_priv->fbdev->helper,
> > +						&connector->base);
> >  #endif
> >  }
> >  
> > @@ -416,7 +419,10 @@ static void intel_connector_remove_from_fbdev(struct intel_connector *connector)
> >  {
> >  #ifdef CONFIG_DRM_FBDEV_EMULATION
> >  	struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > -	drm_fb_helper_remove_one_connector(&dev_priv->fbdev->helper, &connector->base);
> > +
> > +	if (dev_priv->fbdev)
> > +		drm_fb_helper_remove_one_connector(&dev_priv->fbdev->helper,
> > +						   &connector->base);
> >  #endif
> >  }
> >  
> Queued for -next, thanks for the patch. Aside, with this patch and the
> static inline dummies from Archit I think we can drop most of the #ifdef
> blocks (not the one in debugfs though). Care for a follow-up patch to
> remove them around add/remove_one_connector?

Looking at it once more I've realized that the fbdev member in struct
drm_i915_private is enclosed in an #ifdef CONFIG_DRM_FBDEV_EMULATION,
so we can't remove the #ifdefs here: The compiler would complain about
non-existence of the dev_priv->fbdev member.


On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> > @@ -727,7 +730,8 @@ void intel_fbdev_fini(struct drm_device *dev)
> >  
> >  	flush_work(&dev_priv->fbdev_suspend_work);
> >  
> > -	async_synchronize_full();
> > +	if (!current_is_async())
> > +		async_synchronize_full();
> 
> I think this is a bit too fragile, and the core depency will make merging
> tricky. Can't we just push the async_synchronize_full into module unload
> for now?

Thinking about this a bit longer I believe that if anything the change
should make it more robust rather than fragile. After all we eliminate
the source of a deadlock that could occur here (async_synchronize_full()
waiting forever for itself to finish).

That said I'm not married to this solution. If you do find it concerning
I could change it according to Ville's suggestion, i.e. splitting
intel_fbdev_fini() in two parts.

Moving the async_synchronize_full() to i915_driver_unload() would be
contrary to the clarity Ville had sought by consolidating everything
in intel_fbdev.c.

Thanks & best regards,

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

  parent reply	other threads:[~2015-11-19 20:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 13:00 [PATCH v3 0/2] fbdev fixes Lukas Wunner
2015-11-18 12:43 ` [PATCH v3 2/2] drm/i915: Fix oops caused by fbdev initialization failure Lukas Wunner
2015-11-19 16:02   ` Daniel Vetter
2015-11-19 16:17     ` Lukas Wunner
2015-11-18 15:29 ` [PATCH v3 1/2] drm/i915: Tear down fbdev if initialization fails Lukas Wunner
2015-11-19 15:58   ` Daniel Vetter
2015-11-19 16:08     ` Lukas Wunner
2015-11-19 20:26     ` Lukas Wunner [this message]
2015-11-19 21:46     ` Chris Wilson
2015-11-19 22:25       ` Lukas Wunner

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=20151119202640.GA25466@wunner.de \
    --to=lukas@wunner.de \
    --cc=daniel@ffwll.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox