All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.