From: Gabriel Feceoru <gabriel.feceoru@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3] drm/i915: Protect fbdev across slow or failed initialisation
Date: Thu, 31 Mar 2016 15:00:17 +0300 [thread overview]
Message-ID: <56FD1151.5050303@intel.com> (raw)
In-Reply-To: <1459364165-16031-1-git-send-email-chris@chris-wilson.co.uk>
This almost fixes the problem , but with this:
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 5029f92..a6d3c58 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -123,8 +123,9 @@ static struct intel_fbdev
*intel_fbdev_get_if_active(struct drm_device *dev)
return NULL;
info = dev_priv->fbdev->helper.fbdev;
- if (info->screen_base == NULL)
+ if (info == NULL || info->screen_base == NULL)
return NULL;
if (info->state != FBINFO_STATE_RUNNING)
return NULL;
I got initially a page fault during init, but with this fix, the suspend
test passes.
Thank you, please consider this.
Regards,
Gabriel
On 30.03.2016 21:56, Chris Wilson wrote:
> If the initialisation fails, we may be left with a dangling pointer with
> an incomplete fbdev structure. Here we want to disable internal calls
> into fbdev. Similarly, the initialisation may be slow and we haven't yet
> enabled the fbdev (e.g. quick suspend or last-close before the async init
> completes).
>
> v3: To create a typo introduced when retyping
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> Reported-by: "Li, Weinan Z" <weinan.z.li@intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 48 ++++++++++++++++++++++++--------------
> 1 file changed, 30 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> index 153ea7a3fcf6..5029f927fe0d 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -114,6 +114,24 @@ static struct fb_ops intelfb_ops = {
> .fb_debug_leave = drm_fb_helper_debug_leave,
> };
>
> +static struct intel_fbdev *intel_fbdev_get_if_active(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct fb_info *info;
> +
> + if (dev_priv->fbdev == NULL)
> + return NULL;
> +
> + info = dev_priv->fbdev->helper.fbdev;
> + if (info->screen_base == NULL)
> + return NULL;
> +
> + if (info->state != FBINFO_STATE_RUNNING)
> + return NULL;
> +
> + return dev_priv->fbdev;
> +}
> +
> static int intelfb_alloc(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size *sizes)
> {
> @@ -766,6 +784,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous
> return;
>
> info = ifbdev->helper.fbdev;
> + if (info->screen_base == NULL)
> + return;
>
> if (synchronous) {
> /* Flush any pending work to turn the console on, and then
> @@ -807,32 +827,24 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous
>
> void intel_fbdev_output_poll_changed(struct drm_device *dev)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
> +
> + if (ifbdev == NULL)
> + return;
>
> - async_synchronize_full();
> - if (dev_priv->fbdev)
> - drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
> + drm_fb_helper_hotplug_event(&ifbdev->helper);
> }
>
> void intel_fbdev_restore_mode(struct drm_device *dev)
> {
> - int ret;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> - struct drm_fb_helper *fb_helper;
> + struct intel_fbdev *ifbdev = intel_fbdev_get_if_active(dev);
>
> - async_synchronize_full();
> - if (!ifbdev)
> + if (ifbdev == NULL)
> return;
>
> - fb_helper = &ifbdev->helper;
> -
> - ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> - if (ret) {
> - DRM_DEBUG("failed to restore crtc mode\n");
> - } else {
> - mutex_lock(&fb_helper->dev->struct_mutex);
> + if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0) {
> + mutex_lock(&dev->struct_mutex);
> intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> - mutex_unlock(&fb_helper->dev->struct_mutex);
> + mutex_unlock(&dev->struct_mutex);
> }
> }
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-31 12:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 17:20 [REGRESSION] system hang on ILK/SNB/IVB Gabriel Feceoru
2016-03-30 17:57 ` [PATCH] drm/i915: Protect fbdev across slow or failed initialisation Chris Wilson
2016-03-30 18:10 ` kbuild test robot
2016-03-30 18:10 ` kbuild test robot
2016-03-30 18:26 ` kbuild test robot
2016-03-30 18:30 ` Chris Wilson
2016-03-30 18:56 ` [PATCH v3] " Chris Wilson
2016-03-31 12:00 ` Gabriel Feceoru [this message]
2016-03-31 13:57 ` [PATCH v4 1/2] " Chris Wilson
2016-03-31 13:57 ` [PATCH v4 2/2] drm/i915: Move fbdev_suspend_work to intel_fbdev Chris Wilson
2016-03-31 15:22 ` Joonas Lahtinen
2016-03-31 15:30 ` Chris Wilson
2016-03-31 15:56 ` Joonas Lahtinen
2016-03-31 16:05 ` [PATCH v4 1/2] drm/i915: Protect fbdev across slow or failed initialisation Joonas Lahtinen
2016-03-31 16:13 ` Chris Wilson
2016-03-31 16:28 ` Joonas Lahtinen
2016-03-31 16:30 ` Lukas Wunner
2016-03-30 18:47 ` [REGRESSION] system hang on ILK/SNB/IVB Daniel Vetter
2016-03-30 21:35 ` Lukas Wunner
2016-03-31 7:21 ` Tomi Sarvela
2016-03-31 20:35 ` Lukas Wunner
2016-04-01 7:59 ` Tomi Sarvela
2016-03-31 7:42 ` Gabriel Feceoru
2016-03-31 15:23 ` Lukas Wunner
2016-03-31 14:42 ` ✗ Fi.CI.BAT: failure for drm/i915: Protect fbdev across slow or failed initialisation (rev2) Patchwork
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=56FD1151.5050303@intel.com \
--to=gabriel.feceoru@intel.com \
--cc=chris@chris-wilson.co.uk \
--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;
as well as URLs for NNTP newsgroup(s).