All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sharma, Swati2" <swati2.sharma@intel.com>
To: Petri Latvala <petri.latvala@intel.com>,
	Jeremy Cline <jcline@redhat.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t v2 1/2] kms_hdr: Skip HDR tests on pre-Kaby Lake Intel devices
Date: Mon, 8 Mar 2021 18:11:09 +0530	[thread overview]
Message-ID: <d95e9fef-ee70-4875-beb6-7ebfee4c56f7@intel.com> (raw)
In-Reply-To: <YEXkhTnlwCaFo9Fk@platvala-desk.ger.corp.intel.com>



On 08-Mar-21 2:17 PM, Petri Latvala wrote:
> On Fri, Mar 05, 2021 at 11:42:52AM -0500, Jeremy Cline wrote:
>> According to the Intel documentation[0] I could find, HDR support is
>> only in Kaby Lake+. Skip tests in kms_hdr if the hardware doesn't
>> support HDR.
>>
>> [0] https://www.intel.com/content/dam/support/us/en/documents/graphics/HDR_Intel_Graphics_TechWhitePaper.pdf
>>
>> Signed-off-by: Jeremy Cline <jcline@redhat.com>
> 
> 
> While that might be true, strictly speaking IGT tests are not testing
> the HW capabilities but the kernel interfaces. The difference is often
> only interesting for nitpicking.
> 
> However, in this case a good argument can be made either way, with
> what the correct behaviour with setting the "max bpc" property when
> the HW doesn't support HDR _output_ should be. IGT tests should be
> written the way one would expect "real" userspace to behave; does the
> documented kernel interface require userspace to detect the device id
> somehow? The connector property is there so one would assume setting
> it should work and do something.
> 
> A good argument can also be made that even though we're testing "just
> the interface", we (Intel) should have a separate test that requires
> actual HW support...
> 
> Swati, Maarten, thoughts on this? Are we even testing the right things
> for i915 at all? Are we able to express the HW requirement for HDR
> with something other than comparing devid? Should we? (If we should
> not, please suggest a better way to get around the issue being fixed
> here)

There are 2 types of tests which are being validated in kms_hdr
(i) bpc switch
(ii) hdr metadata
And both these tests will skip on platforms which doesn't support 
respective connector
properties (MAX_BPC, HDR_OUTPUT_METADATA resp). These tests are 
independent of platforms on which they are being tested.
This can be validated from the link below:
https://intel-gfx-ci.01.org/tree/drm-tip/shards-all.html?testfilter=kms_hdr
where you can see platforms which doesn't support either max_bpc or 
hdr_metadata
connector properties; tests are being skipped.

And I don't think anything is being fixed here, with gen specific check 
even bpc switch
tests cases won't get executed. MAX_BPC is supported by platforms prior 
to gen9 aswell. But like said HDR is supported is gen9+; so we can lose 
coverage of bpc switch test cases on non-HDR platforms.
IMO there is no need to express HW requirement for HDR; this is already 
being
handled smoothly through connector properties.
> 
> 

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

  reply	other threads:[~2021-03-08 12:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 17:27 [igt-dev] [PATCH i-g-t] tests/kms_hdr: Fix bpc-switch tests on AMD hardware Jeremy Cline
2021-02-19 18:27 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2021-02-19 19:35 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2021-02-19 22:00   ` Jeremy Cline
2021-03-05 16:42 ` [igt-dev] [PATCH i-g-t v2 0/2] Fix up the HDR tests for AMD devices Jeremy Cline
2021-03-05 16:42   ` [igt-dev] [PATCH i-g-t v2 1/2] kms_hdr: Skip HDR tests on pre-Kaby Lake Intel devices Jeremy Cline
2021-03-08  8:47     ` Petri Latvala
2021-03-08 12:41       ` Sharma, Swati2 [this message]
2021-03-08 12:53         ` Petri Latvala
2021-03-08 15:06           ` Jeremy Cline
2021-03-09 14:01             ` Petri Latvala
2021-03-10 12:48               ` Shankar, Uma
2021-03-10 12:53                 ` Petri Latvala
2021-03-10 14:55                   ` Sharma, Swati2
2021-03-05 16:42   ` [igt-dev] [PATCH i-g-t v2 2/2] kms_hdr: Fix bpc-switch tests on AMD hardware Jeremy Cline
2021-03-05 16:48     ` Kazlauskas, Nicholas
2021-03-05 17:17 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/kms_hdr: Fix bpc-switch tests on AMD hardware (rev2) Patchwork
2021-03-05 21:42 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2021-03-10 16:34 ` [igt-dev] [PATCH i-g-t v3] tests/kms_hdr: Fix bpc-switch tests on AMD hardware Jeremy Cline
2021-03-10 16:38   ` Shankar, Uma
2021-03-10 16:45 ` [igt-dev] ✗ Fi.CI.BUILD: failure for tests/kms_hdr: Fix bpc-switch tests on AMD hardware (rev3) Patchwork
2021-03-11  9:01   ` Petri Latvala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d95e9fef-ee70-4875-beb6-7ebfee4c56f7@intel.com \
    --to=swati2.sharma@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jcline@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=petri.latvala@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.