public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
* [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit
@ 2019-01-31 14:48 Nicholas Kazlauskas
  2019-01-31 14:53 ` Maarten Lankhorst
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Nicholas Kazlauskas @ 2019-01-31 14:48 UTC (permalink / raw)
  To: igt-dev; +Cc: Petri Latvala

If the VRR tests failed then there was a chance that VRR could be
left enabled when exiting the test so the VRR_ENABLED property was
reset to 0 whenever the pipe was reset.

However, in doing so the pipe's state was considered changed even
if VRR_ENABLED was already 0. This causes the pipe to be added to
commits where it previously wasn't.

Other tests with properties that can persist for failures (like color
management) don't bother resetting the properties - so this patch
changes VRR_ENABLED to work the same.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
---
 lib/igt_kms.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 71df98d2..0bec3734 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
 	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
 	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
 
-	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
-		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
-
 	pipe->out_fence_fd = -1;
 }
 
-- 
2.17.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit
  2019-01-31 14:48 [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit Nicholas Kazlauskas
@ 2019-01-31 14:53 ` Maarten Lankhorst
  2019-01-31 15:09   ` Kazlauskas, Nicholas
  2019-01-31 16:26 ` [igt-dev] ✓ Fi.CI.BAT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2) Patchwork
  2019-02-01  0:05 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
  2 siblings, 1 reply; 7+ messages in thread
From: Maarten Lankhorst @ 2019-01-31 14:53 UTC (permalink / raw)
  To: Nicholas Kazlauskas, igt-dev; +Cc: Petri Latvala

Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
> If the VRR tests failed then there was a chance that VRR could be
> left enabled when exiting the test so the VRR_ENABLED property was
> reset to 0 whenever the pipe was reset.
>
> However, in doing so the pipe's state was considered changed even
> if VRR_ENABLED was already 0. This causes the pipe to be added to
> commits where it previously wasn't.
>
> Other tests with properties that can persist for failures (like color
> management) don't bother resetting the properties - so this patch
> changes VRR_ENABLED to work the same.
>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Petri Latvala <petri.latvala@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> ---
>  lib/igt_kms.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 71df98d2..0bec3734 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>  	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>  	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>  
> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
> -
>  	pipe->out_fence_fd = -1;
>  }
>   

It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit
  2019-01-31 14:53 ` Maarten Lankhorst
@ 2019-01-31 15:09   ` Kazlauskas, Nicholas
  2019-01-31 15:57     ` Maarten Lankhorst
  0 siblings, 1 reply; 7+ messages in thread
From: Kazlauskas, Nicholas @ 2019-01-31 15:09 UTC (permalink / raw)
  To: Maarten Lankhorst, igt-dev@lists.freedesktop.org; +Cc: Petri Latvala

On 1/31/19 9:53 AM, Maarten Lankhorst wrote:
> Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
>> If the VRR tests failed then there was a chance that VRR could be
>> left enabled when exiting the test so the VRR_ENABLED property was
>> reset to 0 whenever the pipe was reset.
>>
>> However, in doing so the pipe's state was considered changed even
>> if VRR_ENABLED was already 0. This causes the pipe to be added to
>> commits where it previously wasn't.
>>
>> Other tests with properties that can persist for failures (like color
>> management) don't bother resetting the properties - so this patch
>> changes VRR_ENABLED to work the same.
>>
>> Cc: Harry Wentland <harry.wentland@amd.com>
>> Cc: Petri Latvala <petri.latvala@intel.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>> ---
>>   lib/igt_kms.c | 3 ---
>>   1 file changed, 3 deletions(-)
>>
>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>> index 71df98d2..0bec3734 100644
>> --- a/lib/igt_kms.c
>> +++ b/lib/igt_kms.c
>> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>>   	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>>   	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>>   
>> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
>> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
>> -
>>   	pipe->out_fence_fd = -1;
>>   }
>>    
> 
> It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.
> 

A lot of atomic state can persist outside of an intended test. I 
couldn't really find anywhere that explicitly resets CRTC properties 
like gamma/background color/etc.

So I currently disable vrr before I check the main pass/fail threshold 
in the test. There are a few cases where the test can still fail while 
it's enabled, but those are mostly system failures. This bit in igt_kms 
is kind of redundant in that sense.

This patch aims to keep things they were before, where one test failure 
can cascade and cause many other tests to fail. I personally favor full 
test isolation when possible so I can tell what specifically went wrong 
when something happens but when everything breaks I guess it gives more 
incentive to address the breakage itself.

Nicholas Kazlauskas
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit
  2019-01-31 15:09   ` Kazlauskas, Nicholas
@ 2019-01-31 15:57     ` Maarten Lankhorst
  2019-02-05 16:16       ` Wentland, Harry
  0 siblings, 1 reply; 7+ messages in thread
From: Maarten Lankhorst @ 2019-01-31 15:57 UTC (permalink / raw)
  To: Kazlauskas, Nicholas, igt-dev@lists.freedesktop.org; +Cc: Petri Latvala

Op 31-01-2019 om 16:09 schreef Kazlauskas, Nicholas:
> On 1/31/19 9:53 AM, Maarten Lankhorst wrote:
>> Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
>>> If the VRR tests failed then there was a chance that VRR could be
>>> left enabled when exiting the test so the VRR_ENABLED property was
>>> reset to 0 whenever the pipe was reset.
>>>
>>> However, in doing so the pipe's state was considered changed even
>>> if VRR_ENABLED was already 0. This causes the pipe to be added to
>>> commits where it previously wasn't.
>>>
>>> Other tests with properties that can persist for failures (like color
>>> management) don't bother resetting the properties - so this patch
>>> changes VRR_ENABLED to work the same.
>>>
>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>> Cc: Petri Latvala <petri.latvala@intel.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>>> ---
>>>   lib/igt_kms.c | 3 ---
>>>   1 file changed, 3 deletions(-)
>>>
>>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>> index 71df98d2..0bec3734 100644
>>> --- a/lib/igt_kms.c
>>> +++ b/lib/igt_kms.c
>>> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>>>   	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>>>   	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>>>   
>>> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
>>> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
>>> -
>>>   	pipe->out_fence_fd = -1;
>>>   }
>>>    
>> It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.
>>
> A lot of atomic state can persist outside of an intended test. I 
> couldn't really find anywhere that explicitly resets CRTC properties 
> like gamma/background color/etc.
>
> So I currently disable vrr before I check the main pass/fail threshold 
> in the test. There are a few cases where the test can still fail while 
> it's enabled, but those are mostly system failures. This bit in igt_kms 
> is kind of redundant in that sense.
>
> This patch aims to keep things they were before, where one test failure 
> can cascade and cause many other tests to fail. I personally favor full 
> test isolation when possible so I can tell what specifically went wrong 
> when something happens but when everything breaks I guess it gives more 
> incentive to address the breakage itself.

Hmm, I guess there's precedence to this with the other properties. Maybe we should clear out gamma/etc as well for a saner experience, but it 's harmless for now.

You're free to choose tif you want to keep resetting this or not. I'm a bit indifferent, but some tests may not handle VRR enabled correctly.

I think cascading tests should be avoided personally, igt_display_reset() should recover from a not too weird state, but then again it should also clear csc/gamma/etc then. Oh well..


Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [igt-dev] ✓ Fi.CI.BAT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)
  2019-01-31 14:48 [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit Nicholas Kazlauskas
  2019-01-31 14:53 ` Maarten Lankhorst
@ 2019-01-31 16:26 ` Patchwork
  2019-02-01  0:05 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
  2 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2019-01-31 16:26 UTC (permalink / raw)
  To: Kazlauskas, Nicholas; +Cc: igt-dev

== Series Details ==

Series: lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)
URL   : https://patchwork.freedesktop.org/series/55992/
State : success

== Summary ==

CI Bug Log - changes from IGT_4802 -> IGTPW_2328
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/55992/revisions/2/mbox/

Known issues
------------

  Here are the changes found in IGTPW_2328 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@pm_rpm@basic-rte:
    - fi-bsw-kefka:       PASS -> FAIL [fdo#108800]

  
#### Possible fixes ####

  * igt@i915_module_load@reload:
    - fi-blb-e6850:       INCOMPLETE [fdo#107718] -> PASS

  * igt@kms_frontbuffer_tracking@basic:
    - fi-byt-clapper:     FAIL [fdo#103167] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
    - fi-byt-clapper:     FAIL [fdo#107362] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#108915]: https://bugs.freedesktop.org/show_bug.cgi?id=108915
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271


Participating hosts (48 -> 46)
------------------------------

  Additional (2): fi-icl-y fi-kbl-7567u 
  Missing    (4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-------------

    * IGT: IGT_4802 -> IGTPW_2328

  CI_DRM_5518: 2369fd28d3a46b865f6d4f1d309a4c6b7b4e6d93 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2328: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2328/
  IGT_4802: 4049adf01014af077df2174def4fadf7cecb066e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [igt-dev] ✓ Fi.CI.IGT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)
  2019-01-31 14:48 [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit Nicholas Kazlauskas
  2019-01-31 14:53 ` Maarten Lankhorst
  2019-01-31 16:26 ` [igt-dev] ✓ Fi.CI.BAT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2) Patchwork
@ 2019-02-01  0:05 ` Patchwork
  2 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2019-02-01  0:05 UTC (permalink / raw)
  To: Nicholas Kazlauskas; +Cc: igt-dev

== Series Details ==

Series: lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2)
URL   : https://patchwork.freedesktop.org/series/55992/
State : success

== Summary ==

CI Bug Log - changes from IGT_4802_full -> IGTPW_2328_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/55992/revisions/2/mbox/

Known issues
------------

  Here are the changes found in IGTPW_2328_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
    - shard-snb:          NOTRUN -> DMESG-WARN [fdo#107956] +1

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
    - shard-glk:          PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_color@pipe-a-degamma:
    - shard-apl:          PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_cursor_crc@cursor-128x42-onscreen:
    - shard-glk:          PASS -> FAIL [fdo#103232] +3

  * igt@kms_cursor_crc@cursor-256x256-suspend:
    - shard-glk:          PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
    - shard-apl:          PASS -> FAIL [fdo#103191] / [fdo#103232]

  * igt@kms_cursor_crc@cursor-64x21-random:
    - shard-apl:          PASS -> FAIL [fdo#103232] +6

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-hsw:          PASS -> FAIL [fdo#105767]

  * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled:
    - shard-glk:          PASS -> FAIL [fdo#103184]

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-glk:          PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-apl:          PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
    - shard-apl:          PASS -> FAIL [fdo#108948]
    - shard-glk:          PASS -> FAIL [fdo#108948]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
    - shard-glk:          PASS -> FAIL [fdo#108145]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
    - shard-glk:          NOTRUN -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
    - shard-glk:          PASS -> FAIL [fdo#103166] +3

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
    - shard-apl:          PASS -> FAIL [fdo#103166] +2

  * igt@kms_setmode@basic:
    - shard-snb:          NOTRUN -> FAIL [fdo#99912]

  
#### Possible fixes ####

  * igt@i915_suspend@fence-restore-untiled:
    - shard-apl:          DMESG-WARN [fdo#108566] -> PASS

  * igt@kms_busy@basic-modeset-a:
    - shard-apl:          FAIL [fdo#109490] -> PASS +3
    - shard-glk:          FAIL [fdo#109490] -> PASS +3
    - shard-snb:          FAIL [fdo#109490] -> PASS +1

  * igt@kms_cursor_crc@cursor-256x85-random:
    - shard-apl:          FAIL [fdo#103232] -> PASS +1

  * igt@kms_cursor_crc@cursor-size-change:
    - shard-glk:          FAIL [fdo#103232] -> PASS +3

  * igt@kms_flip@2x-flip-vs-modeset:
    - shard-hsw:          DMESG-WARN [fdo#102614] -> PASS

  * igt@kms_flip@modeset-vs-vblank-race:
    - shard-apl:          FAIL [fdo#103060] -> PASS

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
    - shard-glk:          FAIL [fdo#108145] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
    - shard-glk:          FAIL [fdo#103166] -> PASS +4

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
    - shard-apl:          FAIL [fdo#103166] -> PASS

  * igt@kms_setmode@basic:
    - shard-apl:          FAIL [fdo#99912] -> PASS
    - shard-hsw:          FAIL [fdo#99912] -> PASS

  * igt@kms_vblank@crtc-id:
    - shard-hsw:          FAIL [fdo#109490] -> PASS +3

  * igt@pm_rc6_residency@rc6-accuracy:
    - shard-snb:          {SKIP} [fdo#109271] -> PASS

  
#### Warnings ####

  * igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270:
    - shard-snb:          {SKIP} [fdo#109271] -> INCOMPLETE [fdo#105411]

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109490]: https://bugs.freedesktop.org/show_bug.cgi?id=109490
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (7 -> 5)
------------------------------

  Missing    (2): shard-skl shard-iclb 


Build changes
-------------

    * IGT: IGT_4802 -> IGTPW_2328

  CI_DRM_5518: 2369fd28d3a46b865f6d4f1d309a4c6b7b4e6d93 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2328: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2328/
  IGT_4802: 4049adf01014af077df2174def4fadf7cecb066e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit
  2019-01-31 15:57     ` Maarten Lankhorst
@ 2019-02-05 16:16       ` Wentland, Harry
  0 siblings, 0 replies; 7+ messages in thread
From: Wentland, Harry @ 2019-02-05 16:16 UTC (permalink / raw)
  To: Maarten Lankhorst, Kazlauskas, Nicholas,
	igt-dev@lists.freedesktop.org
  Cc: Petri Latvala

On 2019-01-31 10:57 a.m., Maarten Lankhorst wrote:
> Op 31-01-2019 om 16:09 schreef Kazlauskas, Nicholas:
>> On 1/31/19 9:53 AM, Maarten Lankhorst wrote:
>>> Op 31-01-2019 om 15:48 schreef Nicholas Kazlauskas:
>>>> If the VRR tests failed then there was a chance that VRR could be
>>>> left enabled when exiting the test so the VRR_ENABLED property was
>>>> reset to 0 whenever the pipe was reset.
>>>>
>>>> However, in doing so the pipe's state was considered changed even
>>>> if VRR_ENABLED was already 0. This causes the pipe to be added to
>>>> commits where it previously wasn't.
>>>>
>>>> Other tests with properties that can persist for failures (like color
>>>> management) don't bother resetting the properties - so this patch
>>>> changes VRR_ENABLED to work the same.
>>>>
>>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>>> Cc: Petri Latvala <petri.latvala@intel.com>
>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109490
>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>>>> ---
>>>>   lib/igt_kms.c | 3 ---
>>>>   1 file changed, 3 deletions(-)
>>>>
>>>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>>> index 71df98d2..0bec3734 100644
>>>> --- a/lib/igt_kms.c
>>>> +++ b/lib/igt_kms.c
>>>> @@ -1791,9 +1791,6 @@ static void igt_pipe_reset(igt_pipe_t *pipe)
>>>>   	igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_ACTIVE, 0);
>>>>   	igt_pipe_obj_clear_prop_changed(pipe, IGT_CRTC_OUT_FENCE_PTR);
>>>>   
>>>> -	if (igt_pipe_obj_has_prop(pipe, IGT_CRTC_VRR_ENABLED))
>>>> -		igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_VRR_ENABLED, 0);
>>>> -
>>>>   	pipe->out_fence_fd = -1;
>>>>   }
>>>>    
>>> It's ok to force it disabled if any test could start failing because of it? Most tests are probably not aware of VRR.
>>>
>> A lot of atomic state can persist outside of an intended test. I 
>> couldn't really find anywhere that explicitly resets CRTC properties 
>> like gamma/background color/etc.
>>
>> So I currently disable vrr before I check the main pass/fail threshold 
>> in the test. There are a few cases where the test can still fail while 
>> it's enabled, but those are mostly system failures. This bit in igt_kms 
>> is kind of redundant in that sense.
>>
>> This patch aims to keep things they were before, where one test failure 
>> can cascade and cause many other tests to fail. I personally favor full 
>> test isolation when possible so I can tell what specifically went wrong 
>> when something happens but when everything breaks I guess it gives more 
>> incentive to address the breakage itself.
> 
> Hmm, I guess there's precedence to this with the other properties. Maybe we should clear out gamma/etc as well for a saner experience, but it 's harmless for now.
> 
> You're free to choose tif you want to keep resetting this or not. I'm a bit indifferent, but some tests may not handle VRR enabled correctly.
> 
> I think cascading tests should be avoided personally, igt_display_reset() should recover from a not too weird state, but then again it should also clear csc/gamma/etc then. Oh well..
> 
> 
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 

Not nice that igt_display_reset can't properly reset things without potentially impacting tests that run after. This might have unintended consequences but would it make sense to do a commit from igt_display_reset to commit the state and therefore actually go into any subsequent test with a "default" state?

Either way, based on current behavior this patch is
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

Harry
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-02-05 16:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-31 14:48 [igt-dev] [PATCH i-g-t v2] lib/igt_kms: Don't reset VRR_ENABLED on every commit Nicholas Kazlauskas
2019-01-31 14:53 ` Maarten Lankhorst
2019-01-31 15:09   ` Kazlauskas, Nicholas
2019-01-31 15:57     ` Maarten Lankhorst
2019-02-05 16:16       ` Wentland, Harry
2019-01-31 16:26 ` [igt-dev] ✓ Fi.CI.BAT: success for lib/igt_kms: Don't reset VRR_ENABLED on every commit (rev2) Patchwork
2019-02-01  0:05 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox