[PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Chris Wilson]

PSR may not exit instantaneously, so while asserting that PSR is
disabled after an action, we may have to wait a short while. Currently
that wait is waiting for PSR to enabled and expecting to timeout; this
fails when we start the assertion with PSR already enabled. Fix the wait
to wait until PSR is disabled rather than timeout.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/kms_frontbuffer_tracking.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 6c4071de..57ae047b 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1002,6 +1002,11 @@ static bool psr_wait_until_enabled(void)
 	return igt_wait(psr_is_enabled(), 5000, 1);
 }
 
+static bool psr_wait_until_disabled(void)
+{
+	return igt_wait(!psr_is_enabled(), 5000, 1);
+}
+
 static bool drrs_wait_until_rr_switch_to_low(void)
 {
 	return igt_wait(is_drrs_low(), 5000, 1);
@@ -1845,10 +1850,13 @@ static void do_status_assertions(int flags)
 	if (flags & ASSERT_PSR_ENABLED) {
 		if (!psr_wait_until_enabled()) {
 			psr_print_status();
-			igt_assert_f(psr_is_enabled(), "PSR disabled\n");
+			igt_assert_f(psr_is_enabled(), "PSR still disabled\n");
 		}
 	} else if (flags & ASSERT_PSR_DISABLED) {
-		igt_assert(!psr_wait_until_enabled());
+		if (!psr_wait_until_disabled()) {
+			psr_print_status();
+			igt_assert_f(!psr_is_enabled(), "PSR still enabled\n");
+		}
 	}
 }
 
-- 
2.16.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Chris Wilson]

PSR may not exit instantaneously, so while asserting that PSR is
disabled after an action, we may have to wait a short while. Currently
that wait is waiting for PSR to enabled and expecting to timeout; this
fails when we start the assertion with PSR already enabled. Fix the wait
to wait until PSR is disabled rather than timeout.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/kms_frontbuffer_tracking.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 6c4071de..57ae047b 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1002,6 +1002,11 @@ static bool psr_wait_until_enabled(void)
 	return igt_wait(psr_is_enabled(), 5000, 1);
 }
 
+static bool psr_wait_until_disabled(void)
+{
+	return igt_wait(!psr_is_enabled(), 5000, 1);
+}
+
 static bool drrs_wait_until_rr_switch_to_low(void)
 {
 	return igt_wait(is_drrs_low(), 5000, 1);
@@ -1845,10 +1850,13 @@ static void do_status_assertions(int flags)
 	if (flags & ASSERT_PSR_ENABLED) {
 		if (!psr_wait_until_enabled()) {
 			psr_print_status();
-			igt_assert_f(psr_is_enabled(), "PSR disabled\n");
+			igt_assert_f(psr_is_enabled(), "PSR still disabled\n");
 		}
 	} else if (flags & ASSERT_PSR_DISABLED) {
-		igt_assert(!psr_wait_until_enabled());
+		if (!psr_wait_until_disabled()) {
+			psr_print_status();
+			igt_assert_f(!psr_is_enabled(), "PSR still enabled\n");
+		}
 	}
 }
 
-- 
2.16.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Daniel Vetter]

On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> PSR may not exit instantaneously, so while asserting that PSR is
> disabled after an action, we may have to wait a short while. Currently
> that wait is waiting for PSR to enabled and expecting to timeout; this
> fails when we start the assertion with PSR already enabled. Fix the wait
> to wait until PSR is disabled rather than timeout.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I guess that's the reply to my question about the earlier
kms_frontbuffer_tracking patch?

Makes a bunch more sense to me.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> ---
>  tests/kms_frontbuffer_tracking.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
> index 6c4071de..57ae047b 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -1002,6 +1002,11 @@ static bool psr_wait_until_enabled(void)
>  	return igt_wait(psr_is_enabled(), 5000, 1);
>  }
>  
> +static bool psr_wait_until_disabled(void)
> +{
> +	return igt_wait(!psr_is_enabled(), 5000, 1);
> +}
> +
>  static bool drrs_wait_until_rr_switch_to_low(void)
>  {
>  	return igt_wait(is_drrs_low(), 5000, 1);
> @@ -1845,10 +1850,13 @@ static void do_status_assertions(int flags)
>  	if (flags & ASSERT_PSR_ENABLED) {
>  		if (!psr_wait_until_enabled()) {
>  			psr_print_status();
> -			igt_assert_f(psr_is_enabled(), "PSR disabled\n");
> +			igt_assert_f(psr_is_enabled(), "PSR still disabled\n");
>  		}
>  	} else if (flags & ASSERT_PSR_DISABLED) {
> -		igt_assert(!psr_wait_until_enabled());
> +		if (!psr_wait_until_disabled()) {
> +			psr_print_status();
> +			igt_assert_f(!psr_is_enabled(), "PSR still enabled\n");
> +		}
>  	}
>  }
>  
> -- 
> 2.16.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Daniel Vetter]

On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> PSR may not exit instantaneously, so while asserting that PSR is
> disabled after an action, we may have to wait a short while. Currently
> that wait is waiting for PSR to enabled and expecting to timeout; this
> fails when we start the assertion with PSR already enabled. Fix the wait
> to wait until PSR is disabled rather than timeout.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I guess that's the reply to my question about the earlier
kms_frontbuffer_tracking patch?

Makes a bunch more sense to me.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> ---
>  tests/kms_frontbuffer_tracking.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
> index 6c4071de..57ae047b 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -1002,6 +1002,11 @@ static bool psr_wait_until_enabled(void)
>  	return igt_wait(psr_is_enabled(), 5000, 1);
>  }
>  
> +static bool psr_wait_until_disabled(void)
> +{
> +	return igt_wait(!psr_is_enabled(), 5000, 1);
> +}
> +
>  static bool drrs_wait_until_rr_switch_to_low(void)
>  {
>  	return igt_wait(is_drrs_low(), 5000, 1);
> @@ -1845,10 +1850,13 @@ static void do_status_assertions(int flags)
>  	if (flags & ASSERT_PSR_ENABLED) {
>  		if (!psr_wait_until_enabled()) {
>  			psr_print_status();
> -			igt_assert_f(psr_is_enabled(), "PSR disabled\n");
> +			igt_assert_f(psr_is_enabled(), "PSR still disabled\n");
>  		}
>  	} else if (flags & ASSERT_PSR_DISABLED) {
> -		igt_assert(!psr_wait_until_enabled());
> +		if (!psr_wait_until_disabled()) {
> +			psr_print_status();
> +			igt_assert_f(!psr_is_enabled(), "PSR still enabled\n");
> +		}
>  	}
>  }
>  
> -- 
> 2.16.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Chris Wilson]

Quoting Daniel Vetter (2018-02-20 15:44:38)
> On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> > PSR may not exit instantaneously, so while asserting that PSR is
> > disabled after an action, we may have to wait a short while. Currently
> > that wait is waiting for PSR to enabled and expecting to timeout; this
> > fails when we start the assertion with PSR already enabled. Fix the wait
> > to wait until PSR is disabled rather than timeout.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> I guess that's the reply to my question about the earlier
> kms_frontbuffer_tracking patch?

Which, the -ENODEV? I thought I explained that was purely to cope with
the i915_fbc_info API for !HAS_FBC machines, as we are running
kms_frontbuffer_tracking across farm1 in idle time.
https://intel-gfx-ci.01.org/tree/drm-tip/kasan2.html
 
> Makes a bunch more sense to me.

There's the question of whether to apply this to
fbc_wait_until_disabled() as well, but I guess fbc behaves slightly
differently as we don't see the assert failure there.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Chris Wilson]

Quoting Daniel Vetter (2018-02-20 15:44:38)
> On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> > PSR may not exit instantaneously, so while asserting that PSR is
> > disabled after an action, we may have to wait a short while. Currently
> > that wait is waiting for PSR to enabled and expecting to timeout; this
> > fails when we start the assertion with PSR already enabled. Fix the wait
> > to wait until PSR is disabled rather than timeout.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> I guess that's the reply to my question about the earlier
> kms_frontbuffer_tracking patch?

Which, the -ENODEV? I thought I explained that was purely to cope with
the i915_fbc_info API for !HAS_FBC machines, as we are running
kms_frontbuffer_tracking across farm1 in idle time.
https://intel-gfx-ci.01.org/tree/drm-tip/kasan2.html
 
> Makes a bunch more sense to me.

There's the question of whether to apply this to
fbc_wait_until_disabled() as well, but I guess fbc behaves slightly
differently as we don't see the assert failure there.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Patchwork]

== Series Details ==

Series: igt/kms_frontbuffer_tracking: Wait for PSR to be disabled
URL   : https://patchwork.freedesktop.org/series/38599/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4340b479e7769eb619249600328b916fb16949da igt/gem_fenced_exec_thrash: Use fixed durations

with latest DRM-Tip kernel build CI_DRM_3813
f727568c3b37 drm-tip: 2018y-02m-20d-20h-39m-03s UTC integration manifest

No testlist changes.

Test gem_mmap_gtt:
        Subgroup basic-small-bo-tiledx:
                pass       -> FAIL       (fi-gdg-551) fdo#102575

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:417s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:429s
fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:376s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:486s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:285s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:478s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:482s
fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:455s
fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:571s
fi-elk-e7500     total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  time:416s
fi-gdg-551       total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 time:284s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:511s
fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:386s
fi-ilk-650       total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  time:409s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:455s
fi-ivb-3770      total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  time:416s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:449s
fi-kbl-7560u     total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  time:490s
fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:449s
fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:495s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:586s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:428s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:504s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:518s
fi-skl-6700k2    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:487s
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:477s
fi-skl-guc       total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:416s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:432s
fi-snb-2520m     total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:512s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:394s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_963/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✗ Fi.CI.IGT: warning for igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Patchwork]

== Series Details ==

Series: igt/kms_frontbuffer_tracking: Wait for PSR to be disabled
URL   : https://patchwork.freedesktop.org/series/38599/
State : warning

== Summary ==

Test perf:
        Subgroup oa-exponents:
                pass       -> FAIL       (shard-apl) fdo#102254
Test kms_flip:
        Subgroup 2x-plain-flip-fb-recreate:
                pass       -> FAIL       (shard-hsw) fdo#100368 +1
        Subgroup flip-vs-expired-vblank:
                pass       -> FAIL       (shard-hsw) fdo#102887
        Subgroup 2x-modeset-vs-vblank-race-interruptible:
                pass       -> FAIL       (shard-hsw) fdo#103060
Test gem_eio:
        Subgroup in-flight-suspend:
                fail       -> PASS       (shard-hsw) fdo#104676 +1
Test kms_rotation_crc:
        Subgroup sprite-rotation-180:
                pass       -> FAIL       (shard-snb) fdo#103925
Test kms_chv_cursor_fail:
        Subgroup pipe-b-256x256-right-edge:
                pass       -> DMESG-WARN (shard-snb)
Test kms_cursor_crc:
        Subgroup cursor-256x256-suspend:
                incomplete -> PASS       (shard-hsw) fdo#103375
Test kms_vblank:
        Subgroup pipe-c-wait-idle:
                dmesg-warn -> PASS       (shard-hsw)

fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apl        total:3367 pass:1769 dwarn:1   dfail:0   fail:8   skip:1588 time:12365s
shard-hsw        total:3429 pass:1758 dwarn:1   dfail:0   fail:4   skip:1665 time:11581s
shard-snb        total:3429 pass:1348 dwarn:2   dfail:0   fail:3   skip:2076 time:6566s
Blacklisted hosts:
shard-kbl        total:3377 pass:1888 dwarn:7   dfail:1   fail:9   skip:1471 time:9519s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_963/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Daniel Vetter]

On Tue, Feb 20, 2018 at 04:31:40PM +0000, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-02-20 15:44:38)
> > On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> > > PSR may not exit instantaneously, so while asserting that PSR is
> > > disabled after an action, we may have to wait a short while. Currently
> > > that wait is waiting for PSR to enabled and expecting to timeout; this
> > > fails when we start the assertion with PSR already enabled. Fix the wait
> > > to wait until PSR is disabled rather than timeout.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > I guess that's the reply to my question about the earlier
> > kms_frontbuffer_tracking patch?
> 
> Which, the -ENODEV? I thought I explained that was purely to cope with
> the i915_fbc_info API for !HAS_FBC machines, as we are running
> kms_frontbuffer_tracking across farm1 in idle time.
> https://intel-gfx-ci.01.org/tree/drm-tip/kasan2.html

I got confused. In my defense, too much vacations recently :-P

> > Makes a bunch more sense to me.
> 
> There's the question of whether to apply this to
> fbc_wait_until_disabled() as well, but I guess fbc behaves slightly
> differently as we don't see the assert failure there.

Afaiui fbc exit is instantly, psr exit might take some idle frames until
the link is up again (at least for the super deep PSR variants, not so
much for the PSR2 partial uploads magic).

I think this makes sense now to me.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

[Daniel Vetter]

On Tue, Feb 20, 2018 at 04:31:40PM +0000, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-02-20 15:44:38)
> > On Tue, Feb 20, 2018 at 02:33:08PM +0000, Chris Wilson wrote:
> > > PSR may not exit instantaneously, so while asserting that PSR is
> > > disabled after an action, we may have to wait a short while. Currently
> > > that wait is waiting for PSR to enabled and expecting to timeout; this
> > > fails when we start the assertion with PSR already enabled. Fix the wait
> > > to wait until PSR is disabled rather than timeout.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > I guess that's the reply to my question about the earlier
> > kms_frontbuffer_tracking patch?
> 
> Which, the -ENODEV? I thought I explained that was purely to cope with
> the i915_fbc_info API for !HAS_FBC machines, as we are running
> kms_frontbuffer_tracking across farm1 in idle time.
> https://intel-gfx-ci.01.org/tree/drm-tip/kasan2.html

I got confused. In my defense, too much vacations recently :-P

> > Makes a bunch more sense to me.
> 
> There's the question of whether to apply this to
> fbc_wait_until_disabled() as well, but I guess fbc behaves slightly
> differently as we don't see the assert failure there.

Afaiui fbc exit is instantly, psr exit might take some idle frames until
the link is up again (at least for the super deep PSR variants, not so
much for the PSR2 partial uploads magic).

I think this makes sense now to me.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx