intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	Imre Deak <imre.deak@intel.com>
Subject: Re: [RFC PATCH 18/39] drm/i915/display: Determine Cx0 PLL DP mode from PLL state
Date: Mon, 20 Oct 2025 13:51:24 +0300	[thread overview]
Message-ID: <c13d2c12759bb25e7a70dd803c3511fb38feca4f@intel.com> (raw)
In-Reply-To: <aPEzkHAVpYKl-GcC@intel.com>

On Thu, 16 Oct 2025, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Oct 01, 2025 at 12:16:57PM +0300, Jani Nikula wrote:
>> On Wed, 01 Oct 2025, Mika Kahola <mika.kahola@intel.com> wrote:
>> > From: Imre Deak <imre.deak@intel.com>
>> >
>> > The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI
>> > mode. 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
>> > for Cx0 PHY PLLs by determining the DP/HDMI mode from the PLL state.
>> >
>> > For C10 PHYs use the fact that the HDMI divider value in the PLL
>> > registers are set if and only if the PLL is in HDMI mode.
>> >
>> > For C20 PHYs use the DP mode flag programmed to the VDR SERDES register,
>> > which is set if and only if the PLL is in DP mode.
>> >
>> > Assert that the above PLL/VDR SERDES register values match the DP/HDMI
>> > mode being configured already during state computation.
>> >
>> > This also allows dropping the is_dp 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>
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 43 ++++++++++++++++----
>> >  1 file changed, 36 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 93e37b7ac3d9..f2fd766343d5 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > @@ -2090,6 +2090,24 @@ static void intel_c10pll_update_pll(struct intel_encoder *encoder,
>> >  		pll_state->c10.pll[i] = 0;
>> >  }
>> >  
>> > +static bool c10pll_state_is_dp(const struct intel_c10pll_state *pll_state)
>> > +{
>> > +	return !REG_FIELD_GET8(C10_PLL15_HDMIDIV_MASK, pll_state->pll[15]);
>> > +}
>> > +
>> > +static bool c20pll_state_is_dp(const struct intel_c20pll_state *pll_state)
>> > +{
>> > +	return pll_state->vdr.serdes_rate & PHY_C20_IS_DP;
>> 
>> Wouldn't need this if software state was the logical state instead of
>> hardware state that you need to mask. It could be just
>> pll_state->vdr.is_dp, and no function needed.
>
> I think for now we want the PLL states to be raw registers. That's how
> it all worked so far, except that snps/cx0 screwed that up by adding
> some non-register stuff in there. It looks to me like one of the reasons
> why the cx0 code is a bit of a mess is exactly because it hasn't fully
> committed to either representation.
>
> I think for now we should generally nuke that abstract stuff from
> cx0/snps and go for pure register values to keep the design consistent. 
>
> In the future we might want to change things to track the PLL state
> in some common abstract form in high level code, and just convert
> to/from the register based representation inside the specific PLL
> implementation.
>
> For that we would need to come up with some abstract PLL state
> that covers all the important aspects across all the platforms,
> but doesn't delve into the super low level hw details because
> there's just far too much of that in PLLs.

Okay, yuck, but acceptable for consistency in the *PLL* state. As long
as we're careful to not let that leak to crtc state.

BR,
Jani.



-- 
Jani Nikula, Intel

  reply	other threads:[~2025-10-20 10:51 UTC|newest]

Thread overview: 57+ 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
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 [this message]
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
2025-10-01 10:50 ` ✓ i915.CI.BAT: success for drm/i915/display: Add MTL+ platforms to support dpll framework Patchwork
2025-10-07  0:17 ` ✗ i915.CI.Full: failure " Patchwork
2025-10-07 11:17   ` Kahola, Mika

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=c13d2c12759bb25e7a70dd803c3511fb38feca4f@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 \
    --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;
as well as URLs for NNTP newsgroup(s).