public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/skl: Work around incorrect BIOS WRPLL PDIV programming
Date: Mon, 5 Oct 2020 23:26:05 +0300	[thread overview]
Message-ID: <20201005202605.GA1378377@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <20201005200819.GJ6112@intel.com>

On Mon, Oct 05, 2020 at 11:08:19PM +0300, Ville Syrjälä wrote:
> On Sat, Oct 03, 2020 at 03:18:42AM +0300, Imre Deak wrote:
> > The BIOS of at least one ASUS-Z170M system with an SKL I have programs
> > the 101b WRPLL PDIV divider value, which is the encoding for PDIV=7 with
> > bit#0 incorrectly set.
> > 
> > This happens with the
> > 
> > "3840x2160": 30 262750 3840 3888 3920 4000 2160 2163 2168 2191 0x48 0x9
> > 
> > HDMI mode (scaled from a 1024x768 src fb) set by BIOS and the
> > 
> > ref_clock=24000, dco_integer=383, dco_fraction=5802, pdiv=7, qdiv=1, kdiv=1
> > 
> > WRPLL parameters (assuming PDIV=7 was the intended setting). This
> > corresponds to 262749 PLL frequency/port clock.
> > 
> > Later the driver sets the same mode for which it calculates the same
> > dco_int/dco_frac/div WRPLL parameters (with the correct PDIV=7 encoding).
> > 
> > Based on the above, let's assume that PDIV=7 was intended and the HW
> > just ignores bit#0 in the PDIV register field for this setting, treating
> > 100b and 101b encodings the same way.
> > 
> > While at it add the MISSING_CASE() for the p0,p2 divider decodings.
> > 
> > v2: (Ville)
> > - Add a define for the incorrect divider value.
> > - Emit only a debug message when detecting the incorrect divider value.
> > - Use fallthrough from the incorrect divider value case.
> > - Add the MISSING_CASE()s.
> > 
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 14 ++++++++++++++
> >  drivers/gpu/drm/i915/i915_reg.h               |  1 +
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index e08684e34078..61cb558c60d1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -1602,12 +1602,26 @@ static int skl_ddi_wrpll_get_freq(struct drm_i915_private *i915,
> >  	case DPLL_CFGCR2_PDIV_3:
> >  		p0 = 3;
> >  		break;
> > +	default:
> > +		if (p0 == DPLL_CFGCR2_PDIV_7_INVALID)
> 
> Why not just 'case DPLL_CFGCR2_PDIV_7_INVALID:' ?

So we can use fallthrough for both this one and the default case.

> 
> > +			/*
> > +			 * Incorrect ASUS-Z170M BIOS setting, the HW seems to ignore bit#0,
> > +			 * handling it the same way as PDIV_7.
> > +			 */
> > +			drm_dbg_kms(&i915->drm, "Invalid WRPLL PDIV divider value, fixing it.\n");
> > +		else
> > +			MISSING_CASE(p0);
> > +
> > +		fallthrough;
> >  	case DPLL_CFGCR2_PDIV_7:
> >  		p0 = 7;
> >  		break;
> >  	}
> >  
> >  	switch (p2) {
> > +	default:
> > +		MISSING_CASE(p2);
> > +		fallthrough;
> 
> Is there a specific reason we fall through to the 5 and 7 cases for
> bogus values?

Just to default to dividers that result in the minimum PLL freq.

> 
> >  	case DPLL_CFGCR2_KDIV_5:
> >  		p2 = 5;
> >  		break;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index 88c215cf97d4..d911583526db 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -10261,6 +10261,7 @@ enum skl_power_gate {
> >  #define  DPLL_CFGCR2_PDIV_2 (1 << 2)
> >  #define  DPLL_CFGCR2_PDIV_3 (2 << 2)
> >  #define  DPLL_CFGCR2_PDIV_7 (4 << 2)
> > +#define  DPLL_CFGCR2_PDIV_7_INVALID	(5 << 2)
> >  #define  DPLL_CFGCR2_CENTRAL_FREQ_MASK	(3)
> >  
> >  #define DPLL_CFGCR1(id)	_MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR1, _DPLL2_CFGCR1)
> > -- 
> > 2.25.1
> 
> -- 
> Ville Syrjälä
> Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-10-05 23:50 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03  0:18 [Intel-gfx] [PATCH 0/5] drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock Imre Deak
2020-10-03  0:18 ` [Intel-gfx] [PATCH 1/5] drm/i915/skl: Work around incorrect BIOS WRPLL PDIV programming Imre Deak
2020-10-05 20:08   ` Ville Syrjälä
2020-10-05 20:26     ` Imre Deak [this message]
2020-10-05 23:37       ` Ville Syrjälä
2020-10-06  1:24         ` Imre Deak
2020-10-06  1:35   ` [Intel-gfx] [PATCH v3 " Imre Deak
2020-10-06  8:59     ` Ville Syrjälä
2020-10-03  0:18 ` [Intel-gfx] [PATCH 2/5] drm/i915: Move the initial fastset commit check to encoder hooks Imre Deak
2020-10-03  1:07   ` [Intel-gfx] [PATCH v2 " Imre Deak
2020-10-05 20:24     ` Ville Syrjälä
2020-10-05 20:34       ` Imre Deak
2020-10-05 21:53     ` [Intel-gfx] [PATCH v3 " Imre Deak
2020-10-06  9:42       ` Jani Nikula
2020-10-06  9:55         ` Imre Deak
2020-10-06 10:00           ` Jani Nikula
2020-10-06 10:05             ` Imre Deak
2020-10-03  0:18 ` [Intel-gfx] [PATCH 3/5] drm/i915: Check for unsupported DP link rates during initial commit Imre Deak
2020-10-05 20:25   ` Ville Syrjälä
2020-10-03  0:18 ` [Intel-gfx] [PATCH 4/5] drm/i915: Add an encoder hook to sanitize its state during init/resume Imre Deak
2020-10-05 20:30   ` Ville Syrjälä
2020-10-05 20:46     ` Imre Deak
2020-10-05 23:39       ` Ville Syrjälä
2020-10-05 20:40   ` Ville Syrjälä
2020-10-05 20:57     ` Imre Deak
2020-10-05 20:51   ` Ville Syrjälä
2020-10-05 23:00     ` Imre Deak
2020-10-05 21:53   ` [Intel-gfx] [PATCH v2 " Imre Deak
2020-10-05 23:01     ` [Intel-gfx] [PATCH v3 " Imre Deak
2020-10-06  8:58       ` Ville Syrjälä
2020-10-03  0:18 ` [Intel-gfx] [PATCH 5/5] drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock Imre Deak
2020-10-03  0:40 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev2) Patchwork
2020-10-03  0:58 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-10-03  1:31 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev3) Patchwork
2020-10-03  1:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-10-03  3:56 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-10-03 13:48   ` Imre Deak
2020-10-04  6:12     ` Vudum, Lakshminarayana
2020-10-04  5:47 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
2020-10-06  0:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev6) Patchwork
2020-10-06  0:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-10-06  1:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev7) Patchwork
2020-10-06  2:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-10-06  2:39 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev6) Patchwork
2020-10-06 10:32   ` Imre Deak
2020-10-06 11:04     ` Imre Deak
2020-10-06  5:39 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev7) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2020-09-29  0:29 [Intel-gfx] [PATCH 0/5] drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock Imre Deak
2020-09-29  0:29 ` [Intel-gfx] [PATCH 1/5] drm/i915/skl: Work around incorrect BIOS WRPLL PDIV programming Imre Deak
2020-10-01 16:41   ` Ville Syrjälä
2020-10-01 16:53     ` Imre Deak

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=20201005202605.GA1378377@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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