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

[Ville Syrjälä]

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.

-- 
Ville Syrjälä
Intel