From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/vlv: don't try to enable a crtc without fb
Date: Sat, 18 Oct 2014 15:56:38 +0300 [thread overview]
Message-ID: <20141018125638.GU4284@intel.com> (raw)
In-Reply-To: <1413586414-2657-1-git-send-email-robdclark@gmail.com>
On Fri, Oct 17, 2014 at 06:53:34PM -0400, Rob Clark wrote:
> On valleyview, all enabled pipes get added to the prepare mask. However
> if you did state readout to find that the crtc is enabled, but failed to
> map stolen mem and wrap it in a bo (and fb), you could end up in a
> scenario where crtc->primary->fb is still null on first modeset. So
> lets check for this rather than exploding.
>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
> ---
> As with http://lists.freedesktop.org/archives/dri-devel/2014-September/069341.html
> the root cause is issues with stolen region. But it would be nice if
> i915 was a bit less fragile when things don't go as planned.
>
> This could have the side effect that, at first modeset, the crtc's which
> were enabled by BIOS but not yet set (by fbcon or userspace) get disabled.
> This is a somewhat lesser inconvenience compared to opps'ing under
> console_lock.
>
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index d8324c6..9f85033 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10895,6 +10895,9 @@ static int __intel_set_mode(struct drm_crtc *crtc,
>
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> for_each_intel_crtc_masked(dev, prepare_pipes, intel_crtc) {
> + if (!intel_crtc->base.primary->fb)
> + continue;
> +
I think the right fix would be to turn off the primary plane during
the sanitize phase. Although our primary plane code isn't quite up to
the task yet since we'd still try to turn it back on during
.crtc_enable(). The code is somewhat in flux currently and hopefully
soon we'd be able to handle that case correctly.
In the meantime we could potentially disable the whole crtc in
intel_sanitize_crtc() or we could stick a hack into
intel_enable_primary_hw_plane() so that it won't try to enable the plane
w/o an fb (with a comment stating that it's a temporary kludge).
> update_scanline_offset(intel_crtc);
>
> dev_priv->display.crtc_enable(&intel_crtc->base);
> --
> 1.9.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-10-18 12:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-17 22:53 [PATCH] drm/i915/vlv: don't try to enable a crtc without fb Rob Clark
2014-10-18 12:56 ` Ville Syrjälä [this message]
2014-10-19 11:47 ` Daniel Vetter
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=20141018125638.GU4284@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=robdclark@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.