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

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

On Tue, 2026-04-14 at 16:40 +0300, Ville Syrjälä wrote:
> 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.
> 

Hi Ville,

Thank you for the clarification. I want to make sure I understand your
expectation correctly.

When you say "the kernel should accompany each CRC with the correct
frame number," do you mean:

**Option A: Accurate frame number reporting**
- Kernel reports the exact frame number when CRC was captured
- IGT can compare frame numbers to determine if CRC reflects new
configuration
- Requires hardware frame counter support (which MTK lacks)

**Option B: Internal synchronization**
- Kernel internally waits for configuration to take effect
- Only reports CRC to userspace after it's guaranteed to reflect
current config
- IGT doesn't need to know about internal delays

Or perhaps a different approach?

The challenge with Option A is MTK hardware doesn't provide a frame 
counter register.
Option B is feasible, but the latency is variable (1-2 vblanks) due
to asynchronous CMDQ execution.

Could you clarify which direction you'd prefer, or suggest an
alternative?

Thanks,
Jason-JH Lin