From: Imre Deak <imre.deak@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>,
<intel-xe@lists.freedesktop.org>,
<intel-gfx@lists.freedesktop.org>, <ankit.k.nautiyal@intel.com>,
Mika Kahola <mika.kahola@intel.com>
Subject: Re: [PATCH v3 1/3] drm/i915/pps: Enable panel power earlier
Date: Thu, 22 Jan 2026 20:02:24 +0200 [thread overview]
Message-ID: <aXJmMOhMIcf0mrC5@ideak-desk> (raw)
In-Reply-To: <7c7b6afb4fdb0c4259a20a6fd847f66f5c9dbb17@intel.com>
On Tue, Jan 20, 2026 at 03:57:56PM +0200, Jani Nikula wrote:
> On Tue, 20 Jan 2026, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Fri, 16 Jan 2026, Suraj Kandpal <suraj.kandpal@intel.com> wrote:
> >> From: Mika Kahola <mika.kahola@intel.com>
> >>
> >> Move intel_pps_on() to intel_dpll_mgr PLL enabling
> >> .enable function hook to enable panel power earlier.
> >> We need to do this to make sure we are following the
> >> modeset sequences of Bspec. This had changed when we
> >> moved the PLL PHY enablement for CX0 from .enable_clock
> >> to dpll.enable hook
> >
> > So I really hate this.
> >
> > Yeah, maybe it follows the spec now, but what connection does the DPLL
> > manager have with the panel power sequencing?
> >
> > Absolutely nothing.
> >
> > The DPLL manager has no business calling PPS functions.
> >
> > Currently only the g4x and DDI encoder code does PPS power calls, and
> > they're the only ones who should manage PPS.
> >
> >>
> >> Signed-off-by: Mika Kahola <mika.kahola@intel.com>
> >> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
> >> ---
> >>
> >> v2 -> v3:
> >> - Rather than splitting the PHY enablement sequence, enable PPS
> >> earlier (Imre)
> >
> > Please point me at the review comment. I couldn't find anything that
> > would suggest moving the PPS calls to the DPLL manager.
> >
> > Please let's not do this.
>
> Cc: Imre
Yes, moving the intel_pps_on() call from the DDI code to PLL code is not
correct and it's not what I suggested (offline). Based on Suraj's and
Mika's testing the ordering of intel_pps_on() vs. enabling the PLL did
make a difference, avoiding a PLL enabling timeout. This rationale for
the change should've been also added to the commit log, as I requested
in an earlier version of the patchset addressing the same issue in:
https://lore.kernel.org/all/aWeybp1JaC99Rf8L@ideak-desk
If bspec is actually correct and PPS must be enabled before enabling the
PLL, then the correct way to do that would be moving intel_pps_on() to
intel_ddi_pre_pll_enable(). But I have doubt that bspec is correct and
this ordering must be followed. As I pointed out in my earlier review
comment above, I'm not sure what happens then if the PLL must be in an
enabled state already (due to CMTG) before a DDI output using the same
PLL is enabled. So I'd prefer more evidence that following the bspec
order is actually a requirement (for instance a confirmation about that
from HW folks).
> > BR,
> > Jani.
> >
> >
> >>
> >> drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++++--
> >> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 5 +++++
> >> 2 files changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> index cb91d07cdaa6..1784fa687c03 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> @@ -2653,8 +2653,10 @@ static void mtl_ddi_pre_enable_dp(struct intel_atomic_state *state,
> >> /* 3. Select Thunderbolt */
> >> mtl_port_buf_ctl_io_selection(encoder);
> >>
> >> - /* 4. Enable Panel Power if PPS is required */
> >> - intel_pps_on(intel_dp);
> >> + /*
> >> + * 4. Enable Panel Power if PPS is required
> >> + * moved to intel_dpll_mgr .enable hook
> >> + */
> >>
> >> /* 5. Enable the port PLL */
> >> intel_ddi_enable_clock(encoder, crtc_state);
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >> index 9aa84a430f09..b5655c734c53 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> >> @@ -40,6 +40,7 @@
> >> #include "intel_hti.h"
> >> #include "intel_mg_phy_regs.h"
> >> #include "intel_pch_refclk.h"
> >> +#include "intel_pps.h"
> >> #include "intel_step.h"
> >> #include "intel_tc.h"
> >>
> >> @@ -4401,6 +4402,10 @@ static void mtl_pll_enable(struct intel_display *display,
> >> if (drm_WARN_ON(display->drm, !encoder))
> >> return;
> >>
> >> + /* Enable Panel Power if PPS is required */
> >> + if (intel_encoder_is_dp(encoder))
> >> + intel_pps_on(enc_to_intel_dp(encoder));
> >> +
> >> intel_mtl_pll_enable(encoder, pll, dpll_hw_state);
> >> }
>
> --
> Jani Nikula, Intel
next prev parent reply other threads:[~2026-01-22 18:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 8:54 [PATCH v3 0/3] Fix Cx0 Suspend Resume issue Suraj Kandpal
2026-01-16 8:54 ` [PATCH v3 1/3] drm/i915/pps: Enable panel power earlier Suraj Kandpal
2026-01-20 13:57 ` Jani Nikula
2026-01-20 13:57 ` Jani Nikula
2026-01-22 18:02 ` Imre Deak [this message]
2026-01-21 6:13 ` Dibin Moolakadan Subrahmanian
2026-01-16 8:54 ` [PATCH v3 2/3] drm/i915/cx0: Clear response ready & error bit Suraj Kandpal
2026-01-16 8:54 ` [PATCH v3 3/3] drm/i915/cx0: Rename intel_clear_response_ready flag Suraj Kandpal
2026-01-19 6:43 ` Garg, Nemesa
2026-01-16 9:02 ` ✓ CI.KUnit: success for Fix Cx0 Suspend Resume issue (rev3) Patchwork
2026-01-16 9:35 ` ✓ Xe.CI.BAT: " Patchwork
2026-01-16 11:41 ` ✗ Xe.CI.Full: failure " 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=aXJmMOhMIcf0mrC5@ideak-desk \
--to=imre.deak@intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=mika.kahola@intel.com \
--cc=suraj.kandpal@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