From: Matt Roper <matthew.d.roper@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: "Ville Syrjälä" <ville.syrjala@intel.com>
Subject: [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
Date: Wed, 25 Nov 2015 08:48:27 -0800 [thread overview]
Message-ID: <1448470115-7863-2-git-send-email-matthew.d.roper@intel.com> (raw)
In-Reply-To: <1448470115-7863-1-git-send-email-matthew.d.roper@intel.com>
If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb. This mismatch causes problems later on
(e.g., for the watermark code). Since we've failed to reconstruct the
BIOS FB, the best solution is to just disable the primary plane and
pretend the BIOS never had it enabled.
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
With this patch, the rest of this series now runs without problems on Jani's
system where the regressions were originally reported.
Chris pointed out that this might also fix some of the other bugzillas we have
on older platforms where there's a GPU hang on failed FB takeover. I don't
think I have any platforms that can reproduce those types of problems to
verify, but he listed candidate bugs as:
https://bugs.freedesktop.org/show_bug.cgi?id=89319
https://bugs.freedesktop.org/show_bug.cgi?id=87677
https://bugs.freedesktop.org/show_bug.cgi?id=89146
https://bugs.freedesktop.org/show_bug.cgi?id=91653
drivers/gpu/drm/i915/intel_display.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4b21d5e..d03a235 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2597,6 +2597,8 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
+ struct drm_crtc_state *crtc_state = intel_crtc->base.state;
+ struct intel_plane *intel_plane = to_intel_plane(primary);
struct drm_framebuffer *fb;
if (!plane_config->fb)
@@ -2633,6 +2635,17 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
}
}
+ /*
+ * We've failed to reconstruct the BIOS FB. Current display state
+ * indicates that the primary plane is visible, but has a NULL FB,
+ * which will lead to problems later if we don't fix it up. The
+ * simplest solution is to just disable the primary plane now and
+ * pretend the BIOS never had it enabled.
+ */
+ to_intel_plane_state(plane_state)->visible = false;
+ crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
+ intel_plane->disable_plane(primary, &intel_crtc->base);
+
return;
valid_fb:
--
2.1.4
_______________________________________________
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-25 16:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 16:48 [PATCH 0/9] Wrap up ILK-style atomic watermarks Matt Roper
2015-11-25 16:48 ` Matt Roper [this message]
2015-12-03 11:40 ` [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state Matt Roper
2015-12-03 12:27 ` Maarten Lankhorst
2015-12-04 9:31 ` Daniel Vetter
2015-11-25 16:48 ` [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2) Matt Roper
2015-12-03 12:28 ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed Matt Roper
2015-12-03 12:29 ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2) Matt Roper
2015-12-03 12:06 ` Maarten Lankhorst
2015-12-03 17:08 ` Matt Roper
2015-11-25 16:48 ` [PATCH 6/9] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state Matt Roper
2015-11-25 16:48 ` [PATCH 7/9] drm/i915: Add extra paranoia to ILK watermark calculations Matt Roper
2015-11-25 16:48 ` [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2) Matt Roper
2015-11-25 17:05 ` Ville Syrjälä
2015-11-30 23:56 ` [PATCH] drm/i915: Sanitize watermarks after hardware state readout (v3) Matt Roper
2015-12-01 7:42 ` Maarten Lankhorst
2015-11-30 9:50 ` [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2) Maarten Lankhorst
2015-11-30 23:09 ` Matt Roper
2015-11-30 23:22 ` [PATCH] drm/atomic-helper: Grab connection_mutex while duplicating state Matt Roper
2015-12-01 7:24 ` Daniel Vetter
2015-12-01 7:37 ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7) Matt Roper
2015-11-25 17:08 ` Ville Syrjälä
2015-12-01 0:08 ` Matt Roper
2015-11-25 17:00 ` [PATCH 0/9] Wrap up ILK-style atomic watermarks Ville Syrjälä
2015-11-25 17:04 ` Matt Roper
2015-11-25 17:14 ` Ville Syrjälä
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=1448470115-7863-2-git-send-email-matthew.d.roper@intel.com \
--to=matthew.d.roper@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@intel.com \
/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