From: Jani Nikula <jani.nikula@linux.intel.com>
To: Dibin Moolakadan Subrahmanian
<dibin.moolakadan.subrahmanian@intel.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: ankit.k.nautiyal@intel.com, uma.shankar@intel.com,
arun.r.murthy@intel.com, lucas.demarchi@intel.com,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915/display: Optimize panel power-on wait time
Date: Tue, 01 Jul 2025 12:28:41 +0300 [thread overview]
Message-ID: <b5a84286f9729e9d92e08596bfbeb4e9c77f6dc1@intel.com> (raw)
In-Reply-To: <20250630122339.3007880-1-dibin.moolakadan.subrahmanian@intel.com>
On Mon, 30 Jun 2025, Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> wrote:
> The current wait_panel_on() uses intel_de_wait() with a long timeout
> (5000ms), which is suboptimal on Xe platforms where the underlying
> xe_mmio_wait32() employs an exponential backoff strategy. This leads
> to unnecessary delays during resume or power-on when the panel becomes
> ready earlier than the full timeout.
>
> This patch splits the total wait time into two pases
> - First wait for the typical panel-on time(180ms)
> - If panel is not ready , continue polling in short 20ms intervals
> until the maximum timeout (5000ms) is reached
I'm *very* reluctant to merge any new custom wait hacks. I'm in the
process of *removing* a plethora of them [1][2][3].
I think the question is, should xe_mmio_wait32() (and the i915
counterpart) and the intel_de_wait*() functions be migrated to an
interface similar to read_poll_timeout(), i.e. provide sleep and timeout
separately, no exponential backoff. And implement the waits using
read_poll_timeout(), or whatever Ville ends up with [4].
[1] https://lore.kernel.org/r/cover.1750959689.git.jani.nikula@intel.com
[2] https://lore.kernel.org/r/20250626192632.2330349-1-jani.nikula@intel.com
[3] https://lore.kernel.org/r/cover.1751023767.git.jani.nikula@intel.com
[4] https://lore.kernel.org/r/aF67cxjlfWiWMx-4@intel.com
> Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_pps.c | 61 +++++++++++++++++++++++-
> 1 file changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c
> index bff81fb5c316..57a062c8038d 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -598,8 +598,67 @@ void intel_pps_check_power_unlocked(struct intel_dp *intel_dp)
> #define IDLE_CYCLE_MASK (PP_ON | PP_SEQUENCE_MASK | PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK)
> #define IDLE_CYCLE_VALUE (0 | PP_SEQUENCE_NONE | 0 | PP_SEQUENCE_STATE_OFF_IDLE)
>
> +#define PANEL_TYPICAL_ON_TIME_MS (180)
> +#define PANEL_MAXIMUM_ON_TIME_MS (5000)
> +
> static void intel_pps_verify_state(struct intel_dp *intel_dp);
>
> +/*
> + * Panel power-on typically completes within ~200ms. Using a large timeout
> + * (5000ms) with intel_de_wait() results in unnecessary delays,
> + * especially under Xe, where xe_mmio_wait32() uses an exponential backoff.
> + *
> + * To optimize resume and power-on latency, we first wait for the typical
> + * completion window, then perform short polling loops thereafter.
> + * This reduces worst-case latency while still ensuring correctness.
> + */
> +static void wait_panel_on_status(struct intel_dp *intel_dp)
> +{
> + struct intel_display *display = to_intel_display(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + i915_reg_t pp_stat_reg, pp_ctrl_reg;
> + u32 mask = IDLE_ON_MASK;
> + u32 value = IDLE_ON_VALUE;
> + int elapsed = PANEL_TYPICAL_ON_TIME_MS;
> +
> + lockdep_assert_held(&display->pps.mutex);
> +
> + intel_pps_verify_state(intel_dp);
> +
> + pp_stat_reg = _pp_stat_reg(intel_dp);
> + pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
> +
> + drm_dbg_kms(display->drm,
> + "[ENCODER:%d:%s] %s mask: 0x%08x value: 0x%08x PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n",
> + dig_port->base.base.base.id, dig_port->base.base.name,
> + pps_name(intel_dp),
> + mask, value,
> + intel_de_read(display, pp_stat_reg),
> + intel_de_read(display, pp_ctrl_reg));
> +
> + /* Wait for typical panel on time first */
> + if (intel_de_wait(display, pp_stat_reg, mask, value, PANEL_TYPICAL_ON_TIME_MS) == 0)
> + goto panel_wait_complete;
> +
> + /* Wait for maxtime in 20ms intervals */
> + while (elapsed < PANEL_MAXIMUM_ON_TIME_MS) {
> + if (intel_de_wait(display, pp_stat_reg, mask, value, 20) == 0)
> + goto panel_wait_complete;
> +
> + elapsed += 20;
> + }
That's just not how time works in the kernel. Please let's not reinvent
wheels.
BR,
Jani.
> +
> + drm_err(display->drm,
> + "[ENCODER:%d:%s] %s panel status timeout: PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n",
> + dig_port->base.base.base.id, dig_port->base.base.name,
> + pps_name(intel_dp),
> + intel_de_read(display, pp_stat_reg),
> + intel_de_read(display, pp_ctrl_reg));
> +
> +panel_wait_complete:
> + drm_dbg_kms(display->drm, "Wait complete\n");
> +}
> +
> static void wait_panel_status(struct intel_dp *intel_dp,
> u32 mask, u32 value)
> {
> @@ -642,7 +701,7 @@ static void wait_panel_on(struct intel_dp *intel_dp)
> "[ENCODER:%d:%s] %s wait for panel power on\n",
> dig_port->base.base.base.id, dig_port->base.base.name,
> pps_name(intel_dp));
> - wait_panel_status(intel_dp, IDLE_ON_MASK, IDLE_ON_VALUE);
> + wait_panel_on_status(intel_dp);
> }
>
> static void wait_panel_off(struct intel_dp *intel_dp)
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-07-01 9:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 12:23 [PATCH] drm/i915/display: Optimize panel power-on wait time Dibin Moolakadan Subrahmanian
2025-07-01 2:34 ` ✓ CI.KUnit: success for " Patchwork
2025-07-01 3:09 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-01 9:28 ` Jani Nikula [this message]
2025-07-01 14:25 ` [PATCH] " Lucas De Marchi
2025-07-02 9:01 ` Jani Nikula
2025-07-03 8:28 ` Dibin Moolakadan Subrahmanian
2025-07-04 12:47 ` Jani Nikula
2025-07-07 13:23 ` Dibin Moolakadan Subrahmanian
2025-07-02 16:15 ` ✓ Xe.CI.Full: success for " 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=b5a84286f9729e9d92e08596bfbeb4e9c77f6dc1@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=arun.r.murthy@intel.com \
--cc=dibin.moolakadan.subrahmanian@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=uma.shankar@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