[PATCH] drm/i915/display: Optimize panel power-on wait time

Lucas De Marchi lucas.demarchi at intel.com
Tue Jul 1 14:25:47 UTC 2025


On Tue, Jul 01, 2025 at 12:28:41PM +0300, Jani Nikula wrote:
>On Mon, 30 Jun 2025, Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian at 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].

good riddance

>
>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].

I saw your patch series and I'm eagerly waiting it to either propagate
it in xe or have someone merge such a patch.  I'm not sure about
removing the exponential backoff is a good thing overall, but if it's
needed then it needs to be justified to add a new function to pair with
read_poll_timeout(), not a custom driver function.

Lucas De Marchi


More information about the Intel-gfx mailing list