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
next prev 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