From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Sanitize the PPT fdi lane bifurcate state on ivb
Date: Wed, 23 Oct 2013 13:58:26 +0300 [thread overview]
Message-ID: <20131023105826.GH13047@intel.com> (raw)
In-Reply-To: <1382445473-17558-1-git-send-email-daniel.vetter@ffwll.ch>
On Tue, Oct 22, 2013 at 02:37:53PM +0200, Daniel Vetter wrote:
> We expect this bit to be always set when possible, but some BIOSes are
> lazy and don't do this. The result is a pile of WARNs and unhappy fdi
> link training code ...
>
> v2: It's actually the inverse: The BIOS sets this bit when it's not
> strictly needed. This should be cleaned up in the
> global_modeset_resources callback, but we've failed to look at the
> active bit. Which means this won't fire (and so clean up BIOS state)
> when enabling pipe B or C for the first time.
>
> v3: Wrap lines.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
> Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index cfe9e709..3569db6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2421,9 +2421,10 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc)
> FDI_FE_ERRC_ENABLE);
> }
>
> -static bool pipe_has_enabled_pch(struct intel_crtc *intel_crtc)
> +static bool pipe_has_enabled_pch(struct intel_crtc *crtc)
> {
> - return intel_crtc->base.enabled && intel_crtc->config.has_pch_encoder;
> + return crtc->base.enabled && crtc->active &&
> + crtc->config.has_pch_encoder;
I'm thinking the crtc->base.enabled check is actually pointless.
AFAICS we should never get here with crtc->base.enabled==false and
crtc->active==true.
We anyway re-enable the bifurcation bit when we do the mode_set.
Actually that in itself could be a maybe a bug. We'd turn off the
bifurcation bit when both pipes B and C are disabled based on
prepare_pipes, but we only do the mode_set based on modeset_pipes.
But currently we are saved by the fact that those two bitmasks are
the same.
Another potential bug I found is that we always set the bifurcation
bit in mode_set, even if we're not using FDI. So if we have eg.
pipe B enabled w/ FDI using 4 lanes, and then we enable pipe C w/ EDP,
we'd still flip the bifurcation bit in pipe C's mode_set and destroy pipe
B's output. The fix would be to call ivybridge_update_fdi_bc_bifurcation()
only when has_pch_encoder==true.
> }
>
> static void ivb_modeset_global_resources(struct drm_device *dev)
> --
> 1.8.4.rc3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-10-23 10:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-22 12:37 [PATCH] drm/i915: Sanitize the PPT fdi lane bifurcate state on ivb Daniel Vetter
2013-10-23 10:58 ` Ville Syrjälä [this message]
2013-10-24 13:05 ` [Intel-gfx] " 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=20131023105826.GH13047@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.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