[igt-dev] [PATCH v2] tests/kms_flip: Retry test in case of a DP/HDMI link reset

[Shankar, Uma]

> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Sent: Tuesday, May 12, 2020 10:47 PM
> To: Shankar, Uma <uma.shankar at intel.com>
> Cc: Deak, Imre <imre.deak at intel.com>; igt-dev at lists.freedesktop.org
> Subject: Re: [igt-dev] [PATCH v2] tests/kms_flip: Retry test in case of a DP/HDMI
> link reset
> 
> On Tue, May 12, 2020 at 05:07:09PM +0000, Shankar, Uma wrote:
> >
> >
> > > -----Original Message-----
> > > From: Imre Deak <imre.deak at intel.com>
> > > Sent: Tuesday, May 12, 2020 10:21 PM
> > > To: Shankar, Uma <uma.shankar at intel.com>
> > > Cc: igt-dev at lists.freedesktop.org
> > > Subject: Re: [igt-dev] [PATCH v2] tests/kms_flip: Retry test in case
> > > of a DP/HDMI link reset
> > >
> > > On Tue, May 12, 2020 at 06:11:08PM +0300, Shankar, Uma wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: igt-dev <igt-dev-bounces at lists.freedesktop.org> On Behalf
> > > > > Of Imre Deak
> > > > > Sent: Tuesday, May 12, 2020 12:39 AM
> > > > > To: igt-dev at lists.freedesktop.org
> > > > > Subject: [igt-dev] [PATCH v2] tests/kms_flip: Retry test in case
> > > > > of a DP/HDMI link reset
> > > > >
> > > > > At least an IIyama and LG monitor have a strange behaviour when
> > > > > waking from a power saving state and getting enabled with an
> > > > > otherwise
> > > successful modeset:
> > > > > after the modeset in ~2 sec they signal a bad link state, either
> > > > > due to a lost CR/EQ in case of DP or a lost scrambling/TMDS
> > > > > clock setting in case
> > > of HDMI link.
> > > > > In response the driver resets the link with either a
> > > > > link-retraining or a modeset, which in turn makes the test miss vblank/flip
> events and fail.
> > > > >
> > > > > Work around the above issue, by retrying the test once if the
> > > > > test detects after a failure that a link reset happened during
> > > > > the test and a corresponding hotplug uevent was sent by the driver.
> > > > >
> > > > > v2: Suspend the signal helper while waiting for a hotplug event, so the
> > > > >     wait will not get inerrupted/restarted in an endless loop.
> > > > >
> > > >
> > > > Though not sure that this is behavior which should be allowed from
> > > > a compliant monitor, I feel this is the right way to handle/WA
> > > > this.  We may have to extend this to some other tests as well
> > > > which will also get impacted due to these spurious hotplug events.
> > >
> > > Yes, one more place would be the connector probing at test startup,
> > > which should be retried if a hotplug uevent is detected (waiting for
> > > both uevents that a long pulse can generate).
> >
> > Yes, there is also a similar failure in alpha test we have seen:
> > igt at kms_plane_alpha_blend@pipe-c-alpha-opaque-fb - fail - Failed
> > assertion: !mismatch || igt_skip_crc_compare
> >
> > This also occurred due to the spurious interrupt only. Not sure if there is any
> other test which is affected.
> 
> In theory this sort of stuff should not cause a crc mismatch.
> IIRC somebody (Maarten maybe?) made the crc interface supposedly provide
> consistent crcs across modeset. So if we are seeing crc change across a pure ->off-
> >on modeset there is potentially a bug in the driver.

Oh ok, based on the CI logs this happens very sporadically and every time it has reproduced, its
happening when this spurious interrupt is received. Will try to investigate the driver flows related
to alpha handling. 

One another thing in common I got was that when this happened, we also get :
<7> [926.239189] [drm:intel_crtc_set_crc_source [i915]] Trying to capture CRC while pipe is off
<7> [926.254878] i915 0000:03:00.0: [drm:drm_fb_helper_hotplug_event.part.15]

Regards,
Uma Shankar

> --
> Ville Syrjälä
> Intel