Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Mika Kahola <mika.kahola@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: Imre Deak <imre.deak@intel.com>, Mika Kahola <mika.kahola@intel.com>
Subject: Re: [RFC PATCH 15/39] drm/i915/display: Track the Cx0 PHY enabled lane count in the PLL state
Date: Wed, 01 Oct 2025 12:13:59 +0300	[thread overview]
Message-ID: <dd6a361fd448b6629dadb4476b8d4d94ff93fe30@intel.com> (raw)
In-Reply-To: <20251001082839.2585559-16-mika.kahola@intel.com>

On Wed, 01 Oct 2025, Mika Kahola <mika.kahola@intel.com> wrote:
> From: Imre Deak <imre.deak@intel.com>
>
> The Cx0 PLL enable programming requires the enabled lane count. The PLL
> manager framework doesn't pass the CRTC state to the PLL's enable hook,
> so prepare here for the conversion to use the PLL manager, by tracking
> the enabled lane count in the PLL state as well. This has the advantage,
> that the enabled lane count can be verified against the PHY/PLL's
> enabled TX lanes.
>
> This also allows dropping the lane count param from the
> __intel_cx0pll_enable() function, since it can retrieve this now from
> the PLL state.
>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Mika Kahola <mika.kahola@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 55 ++++++++++++++++---
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.h |  1 +
>  2 files changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 2aba1ebae428..d69ff9115659 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -12,6 +12,7 @@
>  #include "intel_alpm.h"
>  #include "intel_cx0_phy.h"
>  #include "intel_cx0_phy_regs.h"
> +#include "intel_display_regs.h"
>  #include "intel_ddi.h"
>  #include "intel_ddi_buf_trans.h"
>  #include "intel_de.h"
> @@ -2083,7 +2084,7 @@ static void intel_c10pll_update_pll(struct intel_encoder *encoder,
>   */
>  static int intel_c10pll_calc_state_from_table(struct intel_encoder *encoder,
>  					      const struct intel_c10pll_state * const *tables,
> -					      bool is_dp, int port_clock,
> +					      bool is_dp, int port_clock, int lane_count,
>  					      struct intel_cx0pll_state *pll_state)
>  {
>  	int i;
> @@ -2093,7 +2094,9 @@ static int intel_c10pll_calc_state_from_table(struct intel_encoder *encoder,
>  			pll_state->c10 = *tables[i];
>  			intel_cx0pll_update_ssc(encoder, pll_state, is_dp);
>  			intel_c10pll_update_pll(encoder, pll_state);
> +
>  			pll_state->use_c10 = true;
> +			pll_state->lane_count = lane_count;
>  
>  			return 0;
>  		}
> @@ -2114,7 +2117,7 @@ static int intel_c10pll_calc_state(struct intel_crtc_state *crtc_state,
>  
>  	err = intel_c10pll_calc_state_from_table(encoder, tables,
>  						 intel_crtc_has_dp_encoder(crtc_state),
> -						 crtc_state->port_clock,
> +						 crtc_state->port_clock, crtc_state->lane_count,
>  						 &crtc_state->dpll_hw_state.cx0pll);
>  
>  	if (err == 0 || !intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> @@ -2126,6 +2129,7 @@ static int intel_c10pll_calc_state(struct intel_crtc_state *crtc_state,
>  	intel_c10pll_update_pll(encoder,
>  				&crtc_state->dpll_hw_state.cx0pll);
>  	crtc_state->dpll_hw_state.cx0pll.use_c10 = true;
> +	crtc_state->dpll_hw_state.cx0pll.lane_count = crtc_state->lane_count;
>  
>  	return 0;
>  }
> @@ -2157,6 +2161,37 @@ static int intel_c10pll_calc_port_clock(struct intel_encoder *encoder,
>  	return tmpclk;
>  }
>  
> +static int readout_enabled_lane_count(struct intel_encoder *encoder)
> +{
> +	struct intel_display *display = to_intel_display(encoder);
> +	u8 enabled_tx_lane_count = 0;
> +	int max_tx_lane_count;
> +	int tx_lane;
> +
> +	/*
> +	 * TODO: also check inactive TX lanes in all PHY lanes owned by the
> +	 * display. For now checking only those PHY lane(s) which are owned
> +	 * based on the active TX lane count (i.e.
> +	 *   1,2 active TX lanes -> PHY lane#0
> +	 *   3,4 active TX lanes -> PHY lane#0 and PHY lane#1).
> +	 */
> +	max_tx_lane_count = DDI_PORT_WIDTH_GET(intel_de_read(display, DDI_BUF_CTL(encoder->port)));

Hmm, feels slightly wrong to be touching DDI_BUF_CTL() here. I think
it's already being used in too many places. But I'm not sure what the
clean alternative should be either.

> +	if (!drm_WARN_ON(display->drm, max_tx_lane_count == 0))
> +		max_tx_lane_count = roundup_pow_of_two(max_tx_lane_count);

So I don't want to see WARN and the happy day scenario mixed like this.

This is fine, and common:

	if (WARN_ON(something that should not happen))
		handle_the_error_case();

But not:

	if (!WARN_ON(something_that_should_not_happen))
		handle_the_normal_case();

Looks like this could be just:
	
	if (drm_WARN_ON(display->drm, max_tx_lane_count == 0))
		return 0;

	max_tx_lane_count = roundup_pow_of_two(max_tx_lane_count);

And it reads like it should.

> +
> +	for (tx_lane = 0; tx_lane < max_tx_lane_count; tx_lane++) {
> +		u8 phy_lane_mask = tx_lane < 2 ? INTEL_CX0_LANE0 : INTEL_CX0_LANE1;
> +		int tx = tx_lane % 2 + 1;
> +		u8 val;
> +
> +		val = intel_cx0_read(encoder, phy_lane_mask, PHY_CX0_TX_CONTROL(tx, 2));
> +		if (!(val & CONTROL2_DISABLE_SINGLE_TX))
> +			enabled_tx_lane_count++;
> +	}
> +
> +	return enabled_tx_lane_count;
> +}
> +
>  static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
>  					  struct intel_cx0pll_state *cx0pll_state)
>  {
> @@ -2175,6 +2210,8 @@ static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
>  	 */
>  	intel_c10_msgbus_access_begin(encoder, lane);
>  
> +	cx0pll_state->lane_count = readout_enabled_lane_count(encoder);
> +
>  	for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
>  		pll_state->pll[i] = intel_cx0_read(encoder, lane, PHY_C10_VDR_PLL(i));
>  
> @@ -2581,6 +2618,7 @@ static int intel_c20pll_calc_state(struct intel_crtc_state *crtc_state,
>  	int err = -ENOENT;
>  
>  	crtc_state->dpll_hw_state.cx0pll.use_c10 = false;
> +	crtc_state->dpll_hw_state.cx0pll.lane_count = crtc_state->lane_count;
>  
>  	/* try computed C20 HDMI tables before using consolidated tables */
>  	if (!is_dp)
> @@ -2670,6 +2708,8 @@ static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
>  
>  	wakeref = intel_cx0_phy_transaction_begin(encoder);
>  
> +	cx0pll_state->lane_count = readout_enabled_lane_count(encoder);
> +
>  	/* 1. Read VDR params and current context selection */
>  	intel_c20_readout_vdr_params(encoder, &pll_state->vdr, &cntx);
>  
> @@ -3107,7 +3147,7 @@ static u32 intel_cx0_get_pclk_pll_ack(u8 lane_mask)
>  
>  static void __intel_cx0pll_enable(struct intel_encoder *encoder,
>  				  const struct intel_cx0pll_state *pll_state,
> -				  bool is_dp, int port_clock, int lane_count)
> +				  bool is_dp, int port_clock)
>  {
>  	struct intel_display *display = to_intel_display(encoder);
>  	enum phy phy = intel_encoder_to_phy(encoder);
> @@ -3149,7 +3189,7 @@ static void __intel_cx0pll_enable(struct intel_encoder *encoder,
>  	 * 6. Program the enabled and disabled owned PHY lane
>  	 * transmitters over message bus
>  	 */
> -	intel_cx0_program_phy_lane(encoder, lane_count, lane_reversal);
> +	intel_cx0_program_phy_lane(encoder, pll_state->lane_count, lane_reversal);
>  
>  	/*
>  	 * 7. Follow the Display Voltage Frequency Switching - Sequence
> @@ -3192,7 +3232,7 @@ static void intel_cx0pll_enable(struct intel_encoder *encoder,
>  {
>  	__intel_cx0pll_enable(encoder, &crtc_state->dpll_hw_state.cx0pll,
>  			      intel_crtc_has_dp_encoder(crtc_state),
> -			      crtc_state->port_clock, crtc_state->lane_count);
> +			      crtc_state->port_clock);
>  }
>  
>  int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder)
> @@ -3723,6 +3763,7 @@ void intel_cx0_pll_power_save_wa(struct intel_display *display)
>  	for_each_intel_encoder(display->drm, encoder) {
>  		struct intel_cx0pll_state pll_state = {};
>  		int port_clock = 162000;
> +		int lane_count = 4;
>  
>  		if (!intel_encoder_is_dig_port(encoder))
>  			continue;
> @@ -3735,7 +3776,7 @@ void intel_cx0_pll_power_save_wa(struct intel_display *display)
>  
>  		if (intel_c10pll_calc_state_from_table(encoder,
>  						       mtl_c10_edp_tables,
> -						       true, port_clock,
> +						       true, port_clock, lane_count,
>  						       &pll_state) < 0) {
>  			drm_WARN_ON(display->drm,
>  				    "Unable to calc C10 state from the tables\n");
> @@ -3746,7 +3787,7 @@ void intel_cx0_pll_power_save_wa(struct intel_display *display)
>  			    "[ENCODER:%d:%s] Applying power saving workaround on disabled PLL\n",
>  			    encoder->base.base.id, encoder->base.name);
>  
> -		__intel_cx0pll_enable(encoder, &pll_state, true, port_clock, 4);
> +		__intel_cx0pll_enable(encoder, &pll_state, true, port_clock);
>  		intel_cx0pll_disable(encoder);
>  	}
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> index 43c7200050e9..839b1a98534f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> @@ -267,6 +267,7 @@ struct intel_cx0pll_state {
>  		struct intel_c10pll_state c10;
>  		struct intel_c20pll_state c20;
>  	};
> +	int lane_count;
>  	bool ssc_enabled;
>  	bool use_c10;
>  	bool tbt_mode;

-- 
Jani Nikula, Intel

  reply	other threads:[~2025-10-01  9:14 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-01  8:28 [RFC PATCH 00/39] drm/i915/display: Add MTL+ platforms to support dpll framework Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 01/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/DP_RATE field macros Mika Kahola
2025-10-01  8:52   ` Jani Nikula
2025-10-01  8:57     ` Raag Jadav
2025-10-01  9:57       ` Jani Nikula
2025-10-01 10:01         ` Kahola, Mika
2025-10-01  8:28 ` [RFC PATCH 02/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/IS_DP flag macro Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 03/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/CONTEXT_TOGGLE " Mika Kahola
2025-10-01  8:49   ` Jani Nikula
2025-10-01  8:28 ` [RFC PATCH 04/39] drm/i915/display: Sanitize PHY_C20_VDR_CUSTOM_SERDES_RATE/IS_HDMI_FRL " Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 05/39] drm/i915/display: Fix PHY_C20_VDR_CUSTOM_SERDES_RATE programming Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 06/39] drm/i915/display: Fix PHY_C20_VDR_HDMI_RATE programming Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 07/39] drm/i915/display: Add missing clock to C10 PHY state compute/HW readout Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 08/39] drm/i915/display: Rename TBT functions to be ICL specific Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 09/39] drm/i915/display: Factor out C10 msgbus access start/end helpers Mika Kahola
2025-10-01  8:55   ` Jani Nikula
2025-10-01  8:28 ` [RFC PATCH 10/39] drm/i915/display: Sanitize setting the Cx0 PLL use_c10 flag Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 11/39] drm/i915/display: Sanitize calculating C20 PLL state from tables Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 12/39] drm/i915/display: Track the C20 PHY VDR state in the PLL state Mika Kahola
2025-10-01  9:03   ` Jani Nikula
2025-10-01  8:28 ` [RFC PATCH 13/39] drm/i915/display: Move definition of Cx0 PHY functions earlier Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 14/39] drm/i915/display: Add macro to get DDI port width from a register value Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 15/39] drm/i915/display: Track the Cx0 PHY enabled lane count in the PLL state Mika Kahola
2025-10-01  9:13   ` Jani Nikula [this message]
2025-10-01 12:09     ` Imre Deak
2025-10-01  8:28 ` [RFC PATCH 16/39] drm/i915/display: Sanitize C10 PHY PLL SSC register setup Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 17/39] drm/i915/display: Read out the Cx0 PHY SSC enabled state Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 18/39] drm/i915/display: Determine Cx0 PLL DP mode from PLL state Mika Kahola
2025-10-01  9:16   ` Jani Nikula
2025-10-16 18:04     ` Ville Syrjälä
2025-10-20 10:51       ` Jani Nikula
2025-10-01  8:28 ` [RFC PATCH 19/39] drm/i915/display: Determine Cx0 PLL port clock " Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 20/39] drm/i915/display: Zero Cx0 PLL state before compute and HW readout Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 21/39] drm/i915/display: Print additional Cx0 PLL HW state Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 22/39] drm/i915/display: Remove state verification Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 23/39] drm/i915/display: PLL information for MTL+ Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 24/39] drm/i915/display: Update C10/C20 state calculation Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 25/39] drm/i915/display: Compute plls for MTL+ platform Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 26/39] drm/i915/display: MTL+ .get_dplls Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 27/39] drm/i915/display: MTL+ .put_dplls Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 28/39] drm/i915/display: Add .update_active_dpll Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 29/39] drm/i915/display: Add .update_dpll_ref_clks Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 30/39] drm/i915/display: Add .dump_hw_state Mika Kahola
2025-10-01  9:33   ` Jani Nikula
2025-10-02  9:12     ` Kahola, Mika
2025-10-01  8:28 ` [RFC PATCH 31/39] drm/i915/display: Add .compare_hw_state Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 32/39] drm/i915/display: Add .get_hw_state to MTL+ platforms Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 33/39] drm/i915/display: Add .get_freq " Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 34/39] drm/i915/display: Add .crtc_get_dpll hook Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 35/39] drm/i915/display: PLL verify debug state print Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 36/39] drm/i915/display: Add .enable_clock on DDI for MTL+ platforms Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 37/39] drm/i915/display: Get configuration for C10 and C20 Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 38/39] drm/i915/display: Add Thunderbolt support Mika Kahola
2025-10-01  8:28 ` [RFC PATCH 39/39] drm/i915/display: Enable dpll framework for MTL+ Mika Kahola

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=dd6a361fd448b6629dadb4476b8d4d94ff93fe30@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=mika.kahola@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