From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Force DPLL calculation for TC ports after readout
Date: Thu, 22 Sep 2022 14:56:53 +0300 [thread overview]
Message-ID: <87pmfn62re.fsf@intel.com> (raw)
In-Reply-To: <20220921211525.10675-2-ville.syrjala@linux.intel.com>
On Thu, 22 Sep 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We always allocate two DPLLs (TC and TBT) for TC ports. This
> is because we can't know ahead of time wherher we need to put
> the PHY into DP-Alt or TBT mode.
>
> However during readout we can obviously only read out the state
> of the DPLL that the port is actually using. Thus the state after
> readout will not have both DPLLs populated.
>
> We run into problems if during readout the TC port is in DP-Alt
> mode, but we then perform a modeset on the port without going
> through the full .compute_config() machinery, and during said
> modeset the port cannot be switched back into DP-Alt mode and
> we need to take the TBT fallback path. Such a modeset can
> happen eg. due to cdclk reprogramming.
>
> This wasn't a problem earlier because we did all the DPLL
> calculations much later in the modeset. So even if flagged
> a modeset very late we'd still have gone through the DPLL
> calculations. But now all the DPLL calculations happen much
> earlier and so we need to deal with it, or else we'll attempt
> a modeset without a DPLL.
>
> To guarantee that we always have both DPLLs fully cal/ulated
> for TC ports force a full modeset computation during the
> initial commit.
>
> Reported-by: Lee Shawn C <shawn.c.lee@intel.com>
> Fixes: b000abd3b3d2 ("drm/i915: Do .crtc_compute_clock() earlier")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 643832d55c28..6278b8ea5bf1 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3600,10 +3600,21 @@ static void intel_ddi_sync_state(struct intel_encoder *encoder,
> static bool intel_ddi_initial_fastset_check(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state)
> {
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> + bool ret = true;
> +
> + if (intel_phy_is_tc(i915, phy)) {
> + drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Forcing full modeset to compute TC port DPLLs\n",
> + encoder->base.base.id, encoder->base.name);
> + crtc_state->uapi.mode_changed = true;
> + ret = false;
> + }
> +
> if (intel_crtc_has_dp_encoder(crtc_state))
> - return intel_dp_initial_fastset_check(encoder, crtc_state);
> + ret &= intel_dp_initial_fastset_check(encoder, crtc_state);
I think there have been static checker warnings about mixing bitwise and
boolean AND like this. I guess there's implicit type conversion to int
and back to bool.
BR,
Jani.
>
> - return true;
> + return ret;
> }
>
> static enum intel_output_type
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-09-22 11:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 21:15 [Intel-gfx] [PATCH 0/4] drm/i915: Fix TC port PLLs after readout Ville Syrjala
2022-09-21 21:15 ` [Intel-gfx] [PATCH 1/4] drm/i915: Force DPLL calculation for TC ports " Ville Syrjala
2022-09-22 11:56 ` Jani Nikula [this message]
2022-09-22 15:40 ` Ville Syrjälä
2022-09-22 19:12 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-09-26 17:00 ` Jani Nikula
2022-09-21 21:15 ` [Intel-gfx] [PATCH 2/4] drm/i915: Don't bail early from intel_dp_initial_fastset_check() Ville Syrjala
2022-09-22 19:13 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-09-21 21:15 ` [Intel-gfx] [PATCH 3/4] drm/i915: Pimp DPLL ref/unref debugs Ville Syrjala
2022-09-22 11:57 ` Jani Nikula
2022-09-22 15:42 ` Ville Syrjälä
2022-09-22 19:13 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-09-21 21:15 ` [Intel-gfx] [PATCH 4/4] drm/i915: WARN if PLL ref/unref got messed up Ville Syrjala
2022-09-21 21:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix TC port PLLs after readout Patchwork
2022-09-21 22:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-22 0:45 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-09-22 23:05 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix TC port PLLs after readout (rev4) Patchwork
2022-09-22 23:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-23 6:09 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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=87pmfn62re.fsf@intel.com \
--to=jani.nikula@linux.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