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
next prev parent 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