All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
	Deepak Singh Rawat <drawat@vmware.com>,
	Thomas Hellstrom <thellstrom@vmware.com>
Cc: Linux-graphics-maintainer <Linux-graphics-maintainer@vmware.com>
Subject: Re: [igt-dev] [PATCH i-g-t 2/3] igt/kms_addfb_basic: Call igt_require_gem for gem specific tiling
Date: Wed, 16 Jan 2019 16:44:23 +0000	[thread overview]
Message-ID: <154765705852.22625.17782170270847006148@skylake-alporthouse-com> (raw)
In-Reply-To: <e5605926f8b45b0984d9fc89067107ba2c1cf4f9.camel@vmware.com>

Quoting Deepak Singh Rawat (2019-01-16 16:34:39)
> On Wed, 2019-01-16 at 16:17 +0000, Chris Wilson wrote:
> > Quoting Deepak Singh Rawat (2019-01-16 16:11:16)
> > > On Wed, 2019-01-16 at 00:42 -0800, Chris Wilson wrote:
> > > > Quoting Deepak Rawat (2019-01-16 00:22:29)
> > > > > For tests using gem specific buffer tiling, add a call to
> > > > > igt_require_gem so that these tests don't fail at later stage.
> > > > 
> > > > KMS operates independently from GEM on i915. So long as you are
> > > > not
> > > > calling gem_execbuf, it should continue to work even if we
> > > > disable
> > > > the
> > > > GPU, i.e. igt_require_gem() should not be required here (afaik).
> > > > -Chris
> > > 
> > > gem_set_tiling() calls an i915 private IOCTL which I think would
> > > fail
> > > when GEM is disabled or on other drivers. So I guess either have a
> > > igt_require_gem() or perhaps GEM specific private IOCTL calls SKIP
> > > on
> > > other drivers.
> > 
> > Ah, you want igt_require(is_i915_device(fd)), or introduce something
> > like igt_require_i915(fd). Even better if such specifics are removed,
> > or
> > moved to a subtest group that are clearly device specific.
> > -Chris
> 
> I am not sure if i915 and GEM are independent of each other but yes you
> are right about kms_addfb_basic.c should not have device/GEM specific
> requires. Perhaps the better way would be something like (instead of
> gem_set_tiling()):
> 
> set_tiling() -> device_specific_tiling()
> 
> Also set_tiling() wrapper SKIP's for drivers which do not support
> tiling, which for now applies to all except i915.

It's not just testing a backend tiling format, but also the
corresponding I915_FORMAT_MOD. It won't generalise more than a starting
point for testing other backend specific DRM_FORMAT_MODIFIERS.

That addfb_expected_ret() is bogus. A different backend may reuse the
same value as I915_FORMAT_MOD_Y_TILED for a completely different
purpose, that ends up being valid for the given addfb.

My reading is addfb25_tests(); addfb25_ytile(); tiling_tests(); are all
i915-specific and should be placed in an i915 subtest group. And that we
should try to extract the (one?) generic addfb25 tests.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-01-16 16:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16  0:22 [igt-dev] [PATCH i-g-t 0/3] Fixes to kms_addfb_basic + RFC IGT buf alloc Deepak Rawat
2019-01-16  0:22 ` [igt-dev] [PATCH i-g-t 1/3] igt/kms_addfb_basic: Call dumb destroy in case have dumb buffer Deepak Rawat
2019-01-16  0:22 ` [igt-dev] [PATCH i-g-t 2/3] igt/kms_addfb_basic: Call igt_require_gem for gem specific tiling Deepak Rawat
2019-01-16  8:42   ` Chris Wilson
2019-01-16 16:11     ` Deepak Singh Rawat
2019-01-16 16:17       ` Chris Wilson
2019-01-16 16:34         ` Deepak Singh Rawat
2019-01-16 16:44           ` Chris Wilson [this message]
2019-01-16 16:53             ` Deepak Singh Rawat
2019-01-16  0:22 ` [igt-dev] [PATCH i-g-t 3/3] igt/kms_addfb_basic: Add missing calls to gem_close Deepak Rawat
2019-01-16  4:13 ` [igt-dev] ✓ Fi.CI.BAT: success for Fixes to kms_addfb_basic + RFC IGT buf alloc Patchwork
2019-01-16  6:20 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

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=154765705852.22625.17782170270847006148@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=Linux-graphics-maintainer@vmware.com \
    --cc=drawat@vmware.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=thellstrom@vmware.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.