From: Jani Nikula <jani.nikula@linux.intel.com>
To: imre.deak@intel.com
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 07/17] drm/i915/ddi: Simplify waiting for a port to idle via DDI_BUF_CTL
Date: Wed, 05 Feb 2025 15:02:26 +0200 [thread overview]
Message-ID: <87a5b04k9p.fsf@intel.com> (raw)
In-Reply-To: <Z6Nd_4pAWl7KGAD2@ideak-desk.fi.intel.com>
On Wed, 05 Feb 2025, Imre Deak <imre.deak@intel.com> wrote:
> On Wed, Feb 05, 2025 at 02:35:18PM +0200, Jani Nikula wrote:
>> On Wed, 29 Jan 2025, Imre Deak <imre.deak@intel.com> wrote:
>> > When waiting for a port to idle, there is no point in distinguishing the
>> > platform specific timeouts, instead of just using the maximum timeout.
>>
>> Why?
>>
>> All of this sounds kind of reasonable, but we'll need a better rationale
>> than "there is no point".
>
> The rational is that there is no point in the complexity of specifying
> an exact timeout and for that the suitable wait API. The sequence in
> particular is not performance critical at all either and due to
> scheduling it's not guaranteed anyhow how long the wait will last at the
> given timescale. In the usual case where the wait succeeds the actual
> time waited does not change with the increased timeout.
Fair. Just needs to be in the commit message. ;)
BR,
Jani.
>
>> > Simplify things accordingly, describing the Bspec platform specific
>> > timeouts in code comments.
>> >
>> > Signed-off-by: Imre Deak <imre.deak@intel.com>
>> > ---
>> > drivers/gpu/drm/i915/display/intel_ddi.c | 78 +++++++++++-------------
>> > 1 file changed, 36 insertions(+), 42 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > index 24c56d2aa5f31..d040558b5d029 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> > @@ -177,69 +177,63 @@ static void hsw_prepare_hdmi_ddi_buffers(struct intel_encoder *encoder,
>> > trans->entries[level].hsw.trans2);
>> > }
>> >
>> > -static void mtl_wait_ddi_buf_idle(struct drm_i915_private *i915, enum port port)
>> > +static i915_reg_t intel_ddi_buf_status_reg(struct intel_display *display, enum port port)
>> > {
>> > - int ret;
>> > + struct drm_i915_private *i915 = to_i915(display->drm);
>>
>> Please don't add new i915 uses, display will work just fine here.
>>
>> >
>> > - /* FIXME: find out why Bspec's 100us timeout is too short */
>> > - ret = wait_for_us((intel_de_read(i915, XELPDP_PORT_BUF_CTL1(i915, port)) &
>> > - XELPDP_PORT_BUF_PHY_IDLE), 10000);
>> > - if (ret)
>> > - drm_err(&i915->drm, "Timeout waiting for DDI BUF %c to get idle\n",
>> > - port_name(port));
>> > + if (DISPLAY_VER(display) >= 14)
>> > + return XELPDP_PORT_BUF_CTL1(i915, port);
>> > + else
>> > + return DDI_BUF_CTL(port);
>> > }
>> >
>> > void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
>> > enum port port)
>> > {
>> > - if (IS_BROXTON(dev_priv)) {
>> > + struct intel_display *display = &dev_priv->display;
>> > +
>> > + /*
>> > + * Bspec's platform specific timeouts:
>> > + * MTL+ : 100 us
>> > + * BXT : fixed 16 us
>> > + * HSW-ADL: 8 us
>> > + *
>> > + * FIXME: MTL requires 10 ms based on tests, find out why 100 us is too short
>> > + */
>>
>> Seems a bit odd to me to list all the platform specific timeouts, and
>> then largely ignore them without explanation!
>
> It's documented so after any future platform requirement changes
> (dropping support for a platform, adding a new platform with a new
> timeout) can be applied to the timeout used below.
>
>> Also, 10 ms is several orders of magnitude longer than it should need to
>> be on all platforms.
>
> I described above why this doesn't matter (in the usual case the wait
> duration will not change).
>
>>
>> > + if (display->platform.broxton) {
>> > udelay(16);
>> > return;
>> > }
>> >
>> > - if (wait_for_us((intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
>> > - DDI_BUF_IS_IDLE), 8))
>> > - drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c to get idle\n",
>> > + static_assert(DDI_BUF_IS_IDLE == XELPDP_PORT_BUF_PHY_IDLE);
>> > + if (intel_de_wait_for_set(display, intel_ddi_buf_status_reg(display, port),
>> > + DDI_BUF_IS_IDLE, 10))
>> > + drm_err(display->drm, "Timeout waiting for DDI BUF %c to get idle\n",
>> > port_name(port));
>> > }
>> >
>> > static void intel_wait_ddi_buf_active(struct intel_encoder *encoder)
>> > {
>> > - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> > + struct intel_display *display = to_intel_display(encoder);
>> > enum port port = encoder->port;
>> > - int timeout_us;
>> > - int ret;
>> >
>> > - /* Wait > 518 usecs for DDI_BUF_CTL to be non idle */
>> > - if (DISPLAY_VER(dev_priv) < 10) {
>> > + /*
>> > + * Bspec's platform specific timeouts:
>> > + * MTL+ : 10000 us
>> > + * DG2 : 1200 us
>> > + * TGL-ADL combo PHY: 1000 us
>> > + * TGL-ADL TypeC PHY: 3000 us
>> > + * HSW-ICL : fixed 518 us
>> > + */
>> > + if (DISPLAY_VER(display) < 10) {
>> > usleep_range(518, 1000);
>> > return;
>> > }
>> >
>> > - if (DISPLAY_VER(dev_priv) >= 14) {
>> > - timeout_us = 10000;
>> > - } else if (IS_DG2(dev_priv)) {
>> > - timeout_us = 1200;
>> > - } else if (DISPLAY_VER(dev_priv) >= 12) {
>> > - if (intel_encoder_is_tc(encoder))
>> > - timeout_us = 3000;
>> > - else
>> > - timeout_us = 1000;
>> > - } else {
>> > - timeout_us = 500;
>> > - }
>> > -
>> > - if (DISPLAY_VER(dev_priv) >= 14)
>> > - ret = _wait_for(!(intel_de_read(dev_priv,
>> > - XELPDP_PORT_BUF_CTL1(dev_priv, port)) &
>> > - XELPDP_PORT_BUF_PHY_IDLE),
>> > - timeout_us, 10, 10);
>> > - else
>> > - ret = _wait_for(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & DDI_BUF_IS_IDLE),
>> > - timeout_us, 10, 10);
>> > -
>> > - if (ret)
>> > - drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c to get active\n",
>> > + static_assert(DDI_BUF_IS_IDLE == XELPDP_PORT_BUF_PHY_IDLE);
>> > + if (intel_de_wait_for_clear(display, intel_ddi_buf_status_reg(display, port),
>> > + DDI_BUF_IS_IDLE, 10))
>> > + drm_err(display->drm, "Timeout waiting for DDI BUF %c to get active\n",
>> > port_name(port));
>> > }
>> >
>> > @@ -3067,7 +3061,7 @@ static void mtl_disable_ddi_buf(struct intel_encoder *encoder,
>> > intel_de_rmw(dev_priv, DDI_BUF_CTL(port), DDI_BUF_CTL_ENABLE, 0);
>> >
>> > /* 3.c Poll for PORT_BUF_CTL Idle Status == 1, timeout after 100us */
>>
>> Comment is now stale. (Which is why we should never add comments like
>> that.)
>
> Right, I remove all these later in the patchset.
>
>>
>> > - mtl_wait_ddi_buf_idle(dev_priv, port);
>> > + intel_wait_ddi_buf_idle(dev_priv, port);
>> >
>> > /* 3.d Disable D2D Link */
>> > mtl_ddi_disable_d2d_link(encoder);
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-02-05 13:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 20:02 [PATCH 00/17] drm/i915/ddi: Fix/simplify port enabling/disabling Imre Deak
2025-01-29 20:02 ` [PATCH 01/17] drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro Imre Deak
2025-01-30 11:47 ` Jani Nikula
2025-01-29 20:02 ` [PATCH 02/17] drm/i915/ddi: Fix HDMI port width programming in DDI_BUF_CTL Imre Deak
2025-01-30 11:51 ` Jani Nikula
2025-01-30 13:33 ` Imre Deak
2025-01-29 20:02 ` [PATCH 03/17] drm/i915/ddi: Make all the PORT_WIDTH macros work the same way Imre Deak
2025-01-30 11:52 ` Jani Nikula
2025-01-29 20:02 ` [PATCH 04/17] drm/i915/ddi: Set missing TC DP PHY lane stagger delay in DDI_BUF_CTL Imre Deak
2025-02-05 12:22 ` Jani Nikula
2025-02-05 13:20 ` Imre Deak
2025-01-29 20:02 ` [PATCH 05/17] drm/i915/ddi: Simplify the port enabling via DDI_BUF_CTL Imre Deak
2025-01-30 11:55 ` Jani Nikula
2025-01-30 13:34 ` Imre Deak
2025-01-29 20:02 ` [PATCH 06/17] drm/i915/ddi: Simplify the port disabling " Imre Deak
2025-02-05 12:24 ` Jani Nikula
2025-01-29 20:02 ` [PATCH 07/17] drm/i915/ddi: Simplify waiting for a port to idle " Imre Deak
2025-02-05 12:35 ` Jani Nikula
2025-02-05 12:47 ` Imre Deak
2025-02-05 13:02 ` Jani Nikula [this message]
2025-02-12 11:48 ` Kahola, Mika
2025-01-29 20:02 ` [PATCH 08/17] drm/i915/ddi: Move platform checks within mtl_ddi_enable/disable_d2d_link() Imre Deak
2025-02-05 12:42 ` Jani Nikula
2025-02-05 13:46 ` Imre Deak
2025-01-29 20:02 ` [PATCH 09/17] drm/i915/ddi: Unify the platform specific functions disabling a port Imre Deak
2025-02-05 12:45 ` Jani Nikula
2025-01-29 20:02 ` [PATCH 10/17] drm/i915/ddi: Add a helper to enable " Imre Deak
2025-02-05 12:49 ` Jani Nikula
2025-02-05 14:43 ` Imre Deak
2025-01-29 20:02 ` [PATCH 11/17] drm/i915/ddi: Sanitize DDI_BUF_CTL register definitions Imre Deak
2025-02-05 12:52 ` Jani Nikula
2025-02-05 14:52 ` Imre Deak
2025-01-29 20:02 ` [PATCH 12/17] drm/i915/ddi: Configure/enable a port in DDI_BUF_CTL via read-modify-write Imre Deak
2025-02-10 18:13 ` Jani Nikula
2025-02-10 18:25 ` Imre Deak
2025-02-12 11:51 ` Kahola, Mika
2025-01-29 20:02 ` [PATCH 13/17] drm/i915/ddi: Factor out a helper to get DDI_BUF_CTL's config value Imre Deak
2025-02-10 18:06 ` Jani Nikula
2025-01-29 20:02 ` [PATCH 14/17] drm/i915/ddi: Reuse helper to compute the HDMI DDI_BUF_CTL config Imre Deak
2025-02-11 14:06 ` Kahola, Mika
2025-01-29 20:02 ` [PATCH 15/17] drm/i915/ddi: Reuse helper to compute the HDMI PORT_BUF_CTL1 config Imre Deak
2025-02-12 9:51 ` Kahola, Mika
2025-01-29 20:02 ` [PATCH 16/17] drm/i915/ddi: Move platform/encoder checks within adlp_tbt_to_dp_alt_switch_wa() Imre Deak
2025-02-12 11:06 ` Kahola, Mika
2025-01-29 20:02 ` [PATCH 17/17] drm/i915/ddi: Unify the platform specific functions enabling a port Imre Deak
2025-02-12 11:26 ` Kahola, Mika
2025-01-29 22:16 ` ✓ CI.Patch_applied: success for drm/i915/ddi: Fix/simplify port enabling/disabling Patchwork
2025-01-29 22:17 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-29 22:18 ` ✓ CI.KUnit: success " Patchwork
2025-01-29 22:34 ` ✓ CI.Build: " Patchwork
2025-01-29 22:37 ` ✓ CI.Hooks: " Patchwork
2025-01-29 22:38 ` ✗ CI.checksparse: warning " Patchwork
2025-01-30 6:22 ` ✓ Xe.CI.BAT: success " Patchwork
2025-01-30 8:27 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-31 7:42 ` 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=87a5b04k9p.fsf@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 \
/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