Re: [PATCH i-g-t 2/2] tests/kms_setmode: Disable CPU deep sleep for accurate vblank timestamps

On Fri, May 22, 2026 at 02:59:00AM +0000, Jason-JH Lin (林睿祥) wrote:

On Thu, 2026-05-21 at 13:39 +0300, Ville Syrjälä wrote:

quoted

On Thu, May 21, 2026 at 03:01:25AM +0000, Jason-JH Lin (林睿祥) wrote:

quoted

On Wed, 2026-05-20 at 16:50 +0300, Ville Syrjälä wrote:

quoted

On Wed, May 20, 2026 at 02:46:26PM +0800, Jason-JH Lin wrote:

quoted

Use igt_disable_cpu_deep_sleep() to prevent CPU wakeup latency
that
affects vblank timestamp acquisition.

This addresses vblank timing stability issues on MediaTek
platforms
where CPU entering idle states can cause ~200us timestamp
jitter
and
test failures.

Can't you fix the kernel to generate accurate timestamps?

Hi Ville,

Thanks for the feedback.

Currently, the kernel timestamp itself is accurate. The issue is
that
even though the vblank IRQ fires accurately, the timestamp captured
by
DRM core via ktime_get() in drm_crtc_get_last_vbltimestamp() cannot
avoid the delay(randomly ~200us) introduced by the CPU idle exit
sequence before the IRQ handler can actually execute.

After looking into this further, I referenced how Intel handles
vblank
timestamps and noticed they use
drm_crtc_vblank_helper_get_vblank_timestamp() together with
get_scanout_position() to calculate accurate timestamps by
compensating
for IRQ handling delays. Please correct me if I'm wrong :)

However, this approach requires the hardware to provide scanline
position information. On MediaTek platforms, this has not been
fully
validated yet, so disabling CPU deep idle states seems to be the
most
appropriate solution for now.

Then you should probably do that in the kernel, or not at all. I
don't
think adding hacks to make tests pass makes any sense because then
what
you are testing doesn't match any real world use scenario at all.
So all you are doing is sweeping the problem under the carpet during 
testing, but the problem still remains and will still be hit during
actual use.

Hi Ville,

Thank you for the feedback.

You're right - the patch was purely to pass IGT tests, not to fix a
real problem (although we haven't encountered any issue within
randomly ~200us jitter on our current platform).

I've investigated the real-world impact of this ~200us timestamp
jitter. In our current Android SurfaceFlinger implementation,
real-world usage is stable with CPU deep sleep enabled.
It seems this issue only appears in IGT single-CRTC testing where CPU
enters deep sleep during idle periods between frames.
Therefore, we prefer not to disable CPU deep sleep system-wide in
kernel due to power consumption concerns.

However, I'd like to understand how the 1-scanline standard was
originally defined for this test. Do real-world use cases actually
require this level of precision?

I don't have specific examples, but people cared about precision
enough to add the whole timestamp correction thingy into the kernel.
And in i915 we also sometimes use the timestamps to cook up a frame
counter (when the hardware lacks one) and I wouldn't want to do that
without adjusting the timestamps based on the scanout position.

Anyways, since this is usually implemented via a scanline counter
(sometimes even a pixel counter) that's the kind of accuracy one
would expect to get, and so that's what one tests for to make sure
it's working correctly.

Not all platforms support or implement get_scanout_position() -
could the standard be relaxed for such platforms?

If you don't implement accurate timestamps then the test is
expected to fail. I see nothing wrong in that.

Relaxing the test doesn't make sense to me because then it can
no longer tell you whether your timestamps are accurate or not.
Although I guess you could have another similar test that
makes sure that the timestamps are at least somewhat sane,
even if not very accurate.

-- 
Ville Syrjälä
Intel