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

["Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>]

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.

Regards,
Jason-JH Lin