All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Kandpal, Suraj" <suraj.kandpal@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 5/7] drm/i915/ltphy: Nuke bogus weird timeouts
Date: Thu, 6 Nov 2025 15:12:34 +0200	[thread overview]
Message-ID: <aQyewv447ln68vnL@intel.com> (raw)
In-Reply-To: <DM3PPF208195D8D46BC28CDE4965CD063A6E3C2A@DM3PPF208195D8D.namprd11.prod.outlook.com>

On Thu, Nov 06, 2025 at 12:03:28PM +0000, Kandpal, Suraj wrote:
> > Subject: Re: [PATCH 5/7] drm/i915/ltphy: Nuke bogus weird timeouts
> > 
> > On Wed, 05 Nov 2025, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > The LT PHY code is abusing intel_de_wait_custom() in all kinds of
> > > weird ways. Get rid of the weird slow timeouts. If these are actually
> > > needed then the fast timeouts should really be specified as the
> > > default 2 microscond or something.
> > >
> > > This will let us eventually nuke intel_de_wait_custom() and convert
> > > over to poll_timeout_us().
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Suraj, any input here?
> > 
> > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> > 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_lt_phy.c      | 11 +++++------
> > >  drivers/gpu/drm/i915/display/intel_lt_phy_regs.h |  1 -
> > >  2 files changed, 5 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_lt_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_lt_phy.c
> > > index 6fb68157b322..cc1d6b7a7de4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_lt_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_lt_phy.c
> > > @@ -1178,10 +1178,9 @@ intel_lt_phy_lane_reset(struct intel_encoder
> > *encoder,
> > >  	if (intel_de_wait_custom(display, XELPDP_PORT_CLOCK_CTL(display,
> > port),
> > >  				 XELPDP_LANE_PCLK_PLL_ACK(0),
> > >  				 XELPDP_LANE_PCLK_PLL_ACK(0),
> > > -				 XE3PLPD_MACCLK_TURNON_LATENCY_US,
> > > -				 XE3PLPD_MACCLK_TURNON_LATENCY_MS,
> > NULL))
> > > +				 XE3PLPD_MACCLK_TURNON_LATENCY_US, 0,
> > NULL))
> > >  		drm_warn(display->drm, "PHY %c PLL MacCLK assertion Ack
> > not done after %dus.\n",
> > > -			 phy_name(phy),
> > XE3PLPD_MACCLK_TURNON_LATENCY_MS * 1000);
> > > +			 phy_name(phy),
> > XE3PLPD_MACCLK_TURNON_LATENCY_US);
> 
> According to Bspec: 74499
> Latency can be either 21us for 1ms depending on what port is connected.
> 
>  > >
> > >  	intel_de_rmw(display, XELPDP_PORT_CLOCK_CTL(display, port),
> > >  		     XELPDP_FORWARD_CLOCK_UNGATE,
> > > @@ -1192,7 +1191,7 @@ intel_lt_phy_lane_reset(struct intel_encoder
> > > *encoder,
> > >
> > >  	if (intel_de_wait_custom(display, XELPDP_PORT_BUF_CTL2(display,
> > port),
> > >  				 lane_phy_current_status, 0,
> > > -				 XE3PLPD_RESET_END_LATENCY_US, 2, NULL))
> > > +				 XE3PLPD_RESET_END_LATENCY_US, 0, NULL))
> 
> Bspec : 74499
> Says 200us but 2ms (1.5ms to be precise) was the actual time we found the this to work properly
> 
> 
> > >  		drm_warn(display->drm,
> > >  			 "PHY %c failed to bring out of Lane reset after
> > %dus.\n",
> > >  			 phy_name(phy),
> > XE3PLPD_RESET_END_LATENCY_US); @@ -1674,7 +1673,7
> > > @@ void intel_lt_phy_pll_enable(struct intel_encoder *encoder,
> > >  		if (intel_de_wait_custom(display,
> > XELPDP_PORT_CLOCK_CTL(display, port),
> > >  					 XELPDP_LANE_PCLK_PLL_ACK(0),
> > >  					 XELPDP_LANE_PCLK_PLL_ACK(0),
> > > -
> > XE3PLPD_MACCLK_TURNON_LATENCY_US, 2, NULL))
> > > +
> > XE3PLPD_MACCLK_TURNON_LATENCY_US, 0, NULL))
> 
> Ditto here.
> 
> > >  			drm_warn(display->drm, "PHY %c PLL MacCLK Ack
> > assertion Timeout after %dus.\n",
> > >  				 phy_name(phy),
> > XE3PLPD_MACCLK_TURNON_LATENCY_US);
> > >
> > > @@ -1702,7 +1701,7 @@ void intel_lt_phy_pll_enable(struct intel_encoder
> > *encoder,
> > >  		/* 16. Poll for PORT_BUF_CTL2 register PHY Pulse Status = 1
> > for Owned PHY Lanes. */
> > >  		if (intel_de_wait_custom(display,
> > XELPDP_PORT_BUF_CTL2(display, port),
> > >  					 lane_phy_pulse_status,
> > lane_phy_pulse_status,
> > > -
> > XE3PLPD_RATE_CALIB_DONE_LATENCY_US, 2, NULL))
> > > +
> > XE3PLPD_RATE_CALIB_DONE_LATENCY_US, 0, NULL))
> 
> Ditto here.
> I would suggest giving this a CI run on NVLS before merging this.

Since you have some idea why these magic numbers were chosen
please redo all of these, and make sure to:
- don't use intel_de_wait_custom() unless absolutely necessary
- if you need to use intel_de_wait_custom() then either
  use the default '2,<whatever ms>' or '<whatever us>,0' timeouts
- document all the used timeouts. This is especially important
  when they are not directly specified in bspec

> 
> Regards,
> Suraj Kandpal
> 
> > >  			drm_warn(display->drm, "PHY %c PLL rate not
> > changed after %dus.\n",
> > >  				 phy_name(phy),
> > XE3PLPD_RATE_CALIB_DONE_LATENCY_US);
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_lt_phy_regs.h
> > > b/drivers/gpu/drm/i915/display/intel_lt_phy_regs.h
> > > index 9223487d764e..36abc2bdbd9b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_lt_phy_regs.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_lt_phy_regs.h
> > > @@ -7,7 +7,6 @@
> > >  #define __INTEL_LT_PHY_REGS_H__
> > >
> > >  #define XE3PLPD_MSGBUS_TIMEOUT_FAST_US	500
> > > -#define XE3PLPD_MACCLK_TURNON_LATENCY_MS	1
> > >  #define XE3PLPD_MACCLK_TURNON_LATENCY_US	21
> > >  #define XE3PLPD_MACCLK_TURNOFF_LATENCY_US	1
> > >  #define XE3PLPD_RATE_CALIB_DONE_LATENCY_US	50
> > 
> > --
> > Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-11-06 13:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05 19:04 [PATCH 0/7] drm/i915: Stop the intel_de_wait_custom() abuse Ville Syrjala
2025-11-05 19:04 ` [PATCH 1/7] drm/i915/cx0: Undo the unjustified timeout change Ville Syrjala
2025-11-06 10:53   ` Jani Nikula
2025-11-06 11:53     ` Kandpal, Suraj
2025-11-06 13:17       ` Jani Nikula
2025-11-05 19:04 ` [PATCH 2/7] drm/i915/cx0: Get rid of XELPDP_MSGBUS_TIMEOUT_FAST_US Ville Syrjala
2025-11-06 10:56   ` Jani Nikula
2025-11-05 19:04 ` [PATCH 3/7] drm/i915/cx0: s/XELPDP_MSGBUS_TIMEOUT_SLOW/XELPDP_MSGBUS_TIMEOUT_MS/ Ville Syrjala
2025-11-06 10:57   ` Jani Nikula
2025-11-05 19:04 ` [PATCH 4/7] drm/i915/cx0: s/XELPDP_PORT_RESET_END_TIMEOUT/XELPDP_PORT_RESET_END_TIMEOUT_US/ Ville Syrjala
2025-11-06 10:57   ` Jani Nikula
2025-11-05 19:04 ` [PATCH 5/7] drm/i915/ltphy: Nuke bogus weird timeouts Ville Syrjala
2025-11-05 19:57   ` Jani Nikula
2025-11-06 11:00   ` Jani Nikula
2025-11-06 12:03     ` Kandpal, Suraj
2025-11-06 13:12       ` Ville Syrjälä [this message]
2025-11-06 13:17         ` Ville Syrjälä
2025-11-06 13:19         ` Jani Nikula
2025-11-07  3:40           ` Kandpal, Suraj
2025-11-07  9:33             ` Jani Nikula
2025-11-10  6:32               ` Kandpal, Suraj
2025-11-05 19:04 ` [PATCH 6/7] drm/i915/hdcp: Use the default 2 usec fast polling timeout Ville Syrjala
2025-11-06 11:00   ` Jani Nikula
2025-11-05 19:04 ` [PATCH 7/7] drm/i915/pmdemand: " Ville Syrjala
2025-11-06 11:01   ` Jani Nikula
2025-11-05 20:20 ` ✗ i915.CI.BAT: failure for drm/i915: Stop the intel_de_wait_custom() abuse Patchwork
2025-11-05 22:57 ` ✓ CI.KUnit: success " Patchwork
2025-11-05 23:12 ` ✗ CI.checksparse: warning " Patchwork
2025-11-06  0:21 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-11-06 12:59 ` ✗ Xe.CI.Full: " 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=aQyewv447ln68vnL@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.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 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.