Re: [PATCH i-g-t] tests/kms_rotation_crc: Add MTK device support

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

On Tue, Apr 14, 2026 at 03:11:21AM +0000, Jason-JH Lin (林睿祥) wrote:
> On Fri, 2026-04-10 at 13:25 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 10, 2026 at 06:07:31PM +0800, Jason-JH Lin wrote:
> > > Adapt rotation CRC tests for MTK devices by using Intel-like pipe
> > > CRC
> > > approach with explicit vblank synchronization.
> > > MTK devices require a vblank wait to ensure rotation completes
> > > before
> > > CRC capture.
> > 
> > Instead of adding these checks all over igt I think you should
> > try to fix you kernel CRC implementation to not hand out garbage
> > CRCs.
> > 
> 
> The issue is fundamental to MTK's HW design where all HW configurations
> are applied by GCE (Global Command Engine) triggered by EOF signal.
> 
> MTK HW Configuration Flow:
> 
> igt_display_commit2(display, COMMIT_ATOMIC)
>             │
>             ▼
>        atomic_commit()
>             │
>             ▼
>        CMDQ submit
>             │
>             ▼
>     Wait for next EOF signal ─────────────────┐
>                                               │
>                                               ▼
>                                   GCE applies HW config
>                                   (Rotation parameters, etc.)
>                                   during VBlanking period
>                                 & GCE reads HW CRC from HW register
>                                   into DRAM buffer
>                                               │
>                                               ▼
>                                   Next Active Display Period
>                                   HW renders with new config
>                                               │
>                                               ▼
>                                   EOF → GCE reads HW CRC from
>                                     HW register into DRAM buffer
>                                               │
>                                               ▼
>                                   VBlank+1 → read CRC from DRAM
>                                            → drm_crtc_add_crc_entry() ✅
>                                   (MTK always reports CRC at VBlank+1
>                                    after the EOF capture)
> 
> 
> This design is intentional to ensure all HW settings are fully applied
> within the VBlanking period, guaranteeing tearing-free display updates.
> At the EOF signal, GCE reads the HW CRC from the HW register into a
> DRAM buffer. Note that MTK always reports the CRC at VBlank+1 after the
> EOF capture, which means there is already an inherent one-frame delay
> before the CRC is reported to IGT via drm_crtc_add_crc_entry().
> 
> IGT Expected Behavior (Intel/AMD):
> 
>   igt_display_commit2(display, COMMIT_ATOMIC)
>             │
>             ▼
>        atomic_commit()
>             │
>             ▼
>         VBlank N ──► HW config takes effect immediately ✅
>             │
>             ▼
>         EOF N ──► CRC captured with new config ✅
>             │
>             ▼
>         VBlank N+1 ──────────────────────► igt_pipe_crc_get_current() ✅
> 
> 
> 
> MTK Actual Behavior:
> 
>   igt_display_commit2(display, COMMIT_ATOMIC)
>             │
>             ▼
>        atomic_commit()
>             │
>             ▼
>        CMDQ submit
>             │
>             ▼
>         EOF N ──► GCE applies new config
>                ──► GCE reads CRC(old) from HW register into DRAM
>             │
>       VBlanking N ──► HW updated with new config (tearing-free ✅)
>             │
>         VBlank N+1 ──► CRC(old) reported via drm_crtc_add_crc_entry()
>             │
>         EOF N+1 ──► GCE reads CRC(new) from HW register into DRAM
>             │
>         VBlank N+2 ──► CRC(new) reported via drm_crtc_add_crc_entry()
>             │
>             ▼
>     igt_wait_for_vblank() is needed to ensure
>     igt_pipe_crc_get_current() captures the correct CRC ✅
> 
> As shown above, due to MTK's GCE-based HW architecture, there is an
> inherent multi-frame latency between igt_display_commit2() and the
> correct CRC being available. Unlike Intel/AMD where the new
> configuration takes effect immediately at the next VBlank, MTK requires
> at least 2 VBlanks after atomic_commit() before the correct CRC can be
> captured. Therefore, igt_wait_for_vblank() is necessary to ensure
> igt_pipe_crc_get_current() captures the correct CRC reflecting the new
> rotation configuration.
> 
> Since this timing behavior is inherent to MTK's GCE-based HW
> architecture and cannot be eliminated at the kernel driver level,
> adding igt_wait_for_vblank() in IGT is the appropriate solution.

It doesn't matter how long the latency is. The kernel should accompany
each CRC with the correct frame number for which the CRC was generated.
igt should have to do nothing but wait for the CRC with the correct
frame number to appear.

-- 
Ville Syrjälä
Intel