All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 03/10] drm/i915: Check VBT for CRT port presence on HSW/BDW
Date: Tue, 1 Dec 2015 15:57:37 +0200	[thread overview]
Message-ID: <20151201135737.GX4437@intel.com> (raw)
In-Reply-To: <20151201134149.GA26256@nuc-i3427.alporthouse.com>

On Tue, Dec 01, 2015 at 01:41:49PM +0000, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> > NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
> > FDI training fails every single time on these machines. Dunno,
> > maybe they just didn't bother wiring it up or something?
> > 
> > Unfortunately all the fuse bits and whatnot are telling us that
> > the CRT connector is present. And so what we get from this is tons
> > of false positives from the CI systems due to VGA connector forcing.
> > 
> > I've not found any way to detect this purely from hardware, so we
> > have to resort to looking at the VBT int_crt_support bit. We used
> > to check this bit on all platforms, but that broke all the old
> > machines, so the check was then restricted to VLV only in
> > commit 84b4e042c470 ("drm/i915: only apply crt_present check on VLV")
> > 
> > Considering HSW and VLV VBT probably got defined around the same time,
> > it should be reasonably safe to assume that the bits is sane for
> > HSW/BDW as well. At least I have one copy of some VBT spec here that
> > says it's meant for both VLV and HSW, and it knows about the bit
> > (lists it being valid from version 155 onwards). Also I have two
> > HSW desktop machines with actual CRT ports and both have
> > int_crt_support==1 in their VBTs.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index e80387dd6582..29ea4c458ab3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14263,7 +14263,7 @@ static bool intel_crt_present(struct drm_device *dev)
> >  	if (HAS_DDI(dev) && I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)
> >  		return false;
> >  
> > -	if (IS_VALLEYVIEW(dev) && !dev_priv->vbt.int_crt_support)
> > +	if ((HAS_DDI(dev) || IS_VALLEYVIEW(dev)) && !dev_priv->vbt.int_crt_support)
> 
> Would it not be better to move this knowledge to vbt if it is version
> dependent?
> 
> 	vbt.int_crtc_support = (UNKNOWN, NOT_PRESENT, PRESENT)
> 
> then
> 
> 	if (dev_priv->vbt.int_crt_support == NOT_PRESENT)
> >  		return false;

I'm not sure the UNKNWON value really buys us anything. But I suppose we
could just do this:

        general = find_section(bdb, BDB_GENERAL_FEATURES);
        if (general) {
                dev_priv->vbt.int_tv_support = general->int_tv_support;
-               dev_priv->vbt.int_crt_support = general->int_crt_support;
+               if (HAS_DDI(dev_priv) || IS_VALLEYIEW(dev_priv))
+                       dev_priv->vbt.int_crt_support = general->int_crt_support;

The other option is to make it check the version. But I'm not sure if
that's entirely safe. For extra paranoia I guess we could do both,
just in case there's some early VLV/HSW out there with <155 VBT
version.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-12-01 13:57 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 13:08 [PATCH 00/10] HSW/BDW PCH modeset fixes and stuff ville.syrjala
2015-12-01 13:08 ` [PATCH 01/10] drm/i915: Don't register the CRT connector when it's fused off ville.syrjala
2015-12-01 19:05   ` Paulo Zanoni
2015-12-01 19:18     ` Ville Syrjälä
2015-12-01 21:28   ` [PATCH v2 01/10] drm/i915: Don't register the CRT connector when it's fused off on LPT-H ville.syrjala
2015-12-01 13:08 ` [PATCH 02/10] drm/i915: Don't register CRT connectro when DDI E can't be used ville.syrjala
2015-12-01 19:13   ` Paulo Zanoni
2015-12-01 21:29   ` [PATCH v2 02/10] drm/i915: Don't register CRT connector " ville.syrjala
2015-12-01 13:08 ` [PATCH 03/10] drm/i915: Check VBT for CRT port presence on HSW/BDW ville.syrjala
2015-12-01 13:41   ` Chris Wilson
2015-12-01 13:57     ` Ville Syrjälä [this message]
2015-12-01 14:06       ` Chris Wilson
2015-12-01 14:19         ` Ville Syrjälä
2015-12-01 16:07   ` [PATCH v2 " ville.syrjala
2015-12-01 18:15     ` Ville Syrjälä
2015-12-01 19:28     ` Paulo Zanoni
2015-12-01 19:40       ` Ville Syrjälä
2015-12-01 21:31     ` [PATCH v3 " ville.syrjala
2015-12-01 13:08 ` [PATCH 04/10] drm/i915: Add "missing" break to haswell_get_ddi_pll() ville.syrjala
2015-12-01 19:34   ` Paulo Zanoni
2015-12-01 19:45     ` Ville Syrjälä
2015-12-01 21:32   ` [PATCH v2 " ville.syrjala
2015-12-02  9:29     ` Ville Syrjälä
2015-12-01 13:08 ` [PATCH 05/10] drm/i915: Disable CLKOUT_DP bending on LPT/WPT as needed ville.syrjala
2015-12-02 13:35   ` Paulo Zanoni
2015-12-03 10:03     ` Ville Syrjälä
2015-12-03 11:16       ` Paulo Zanoni
2015-12-04 20:19   ` [PATCH v2 " ville.syrjala
2015-12-07 16:54     ` Paulo Zanoni
2015-12-01 13:08 ` [PATCH 06/10] drm/i915: Round to closest when computing the VGA dotclock for LPT-H ville.syrjala
2015-12-02 13:45   ` Paulo Zanoni
2015-12-04 20:20   ` [PATCH v2 " ville.syrjala
2015-12-01 13:08 ` [PATCH 07/10] drm/i915: Disable FDI after the CRT port on LPT-H ville.syrjala
2015-12-02 14:01   ` Paulo Zanoni
2015-12-03 10:14     ` Ville Syrjälä
2015-12-04 20:20   ` [PATCH v2 " ville.syrjala
2015-12-07 17:51     ` Paulo Zanoni
2015-12-07 18:57       ` Ville Syrjälä
2015-12-08 14:04         ` Ville Syrjälä
2015-12-08 14:05     ` [PATCH] " ville.syrjala
2015-12-01 13:08 ` [PATCH 08/10] drm/i915: Refactor LPT-H VGA dotclock disabling ville.syrjala
2015-12-02 16:56   ` Paulo Zanoni
2015-12-03 10:15     ` Ville Syrjälä
2015-12-04 20:21   ` [PATCH v2 " ville.syrjala
2015-12-01 13:08 ` [PATCH 09/10] drm/i915: Disable LPT-H VGA dotclock during crtc disable ville.syrjala
2015-12-02 17:02   ` Paulo Zanoni
2015-12-03 10:29     ` Ville Syrjälä
2015-12-04 20:22   ` [PATCH v2 " ville.syrjala
2015-12-01 13:08 ` [PATCH 10/10] drm/i915: Leave FDI running after failed link training on LPT-H ville.syrjala
2015-12-02 17:16   ` Paulo Zanoni
2015-12-03 10:30     ` Ville Syrjälä
2015-12-04 10:09   ` Daniel Vetter
2015-12-04 11:59     ` Ville Syrjälä
2015-12-04 20:22   ` [PATCH v2 " ville.syrjala
2015-12-08 14:32 ` [PATCH 00/10] HSW/BDW PCH modeset fixes and stuff 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=20151201135737.GX4437@intel.com \
    --to=ville.syrjala@linux.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 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.