From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@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: Tue, 6 Oct 2020 02:37:58 +0300 [thread overview]
Message-ID: <20201005233758.GP6112@intel.com> (raw)
In-Reply-To: <20201005202605.GA1378377@ideak-desk.fi.intel.com>
On Mon, Oct 05, 2020 at 11:26:05PM +0300, Imre Deak wrote:
> 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.
IMO trying to be fancy just makes the code harder to read.
>
> >
> > > + /*
> > > + * 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.
I'd probably just set them to zero if they're bogus. Looks like
that should already give us warn and just return zero as the 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
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-10-06 1:07 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
2020-10-05 23:37 ` Ville Syrjälä [this message]
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=20201005233758.GP6112@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox