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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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:
> > On Thu, May 21, 2026 at 03:01:25AM +0000, Jason-JH Lin (林睿祥) wrote:
> > > On Wed, 2026-05-20 at 16:50 +0300, Ville Syrjälä wrote:
> > > > On Wed, May 20, 2026 at 02:46:26PM +0800, Jason-JH Lin wrote:
> > > > > 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