All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepak Singh Rawat <drawat@vmware.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
	Sinclair Yeh <syeh@vmware.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
	linux-graphics-maintainer <linux-graphics-maintainer@vmware.com>
Subject: Re: [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
Date: Thu, 11 Oct 2018 15:32:55 +0000	[thread overview]
Message-ID: <BYAPR05MB41814493BCA6807AA135853DBAE10@BYAPR05MB4181.namprd05.prod.outlook.com> (raw)
In-Reply-To: <20181011152716.GF31561@phenom.ffwll.local>

> > > This seems not needed? For pure generic kms tests I think it'd be great if
> > > we don't have to sprinkle driver-specific checks all over. Which you seem
> > > to achive in your series here.
> > >
> > > So not clear why this here is needed?
> > > -Daniel
> >
> > Hi Daniel,
> >
> > Thanks for the review. You are right for kms tests having vmwgfx driver
> type
> > is not needed but I added vmwgfx device type because I plan to add more
> > vmwgfx test cases, and since vmwgfx buffer allocation is private ioctl
> > having a separate device type might be needed.
> 
> Oh, this sounds awesome. And yes, for private ioctl tests vmwgfx is
> obviuosly very much welcome!
> 
> > I can drop this until I have some vmwgfx specific test cases.
> 
> Sounds like a good plan to me.
> -Daniel

I saw latest email from Perti mentioning that this might be needed for loading
ko. I am really not sure about that but I will test without vmwgfx as a separate
driver type and see if things work.

Thanks,
Deepak


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

WARNING: multiple messages have this Message-ID (diff)
From: Deepak Singh Rawat <drawat@vmware.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
	"petri.latvala@intel.com" <petri.latvala@intel.com>,
	Sinclair Yeh <syeh@vmware.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
	linux-graphics-maintainer <linux-graphics-maintainer@vmware.com>
Subject: Re: [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
Date: Thu, 11 Oct 2018 15:32:55 +0000	[thread overview]
Message-ID: <BYAPR05MB41814493BCA6807AA135853DBAE10@BYAPR05MB4181.namprd05.prod.outlook.com> (raw)
In-Reply-To: <20181011152716.GF31561@phenom.ffwll.local>

> > > This seems not needed? For pure generic kms tests I think it'd be great if
> > > we don't have to sprinkle driver-specific checks all over. Which you seem
> > > to achive in your series here.
> > >
> > > So not clear why this here is needed?
> > > -Daniel
> >
> > Hi Daniel,
> >
> > Thanks for the review. You are right for kms tests having vmwgfx driver
> type
> > is not needed but I added vmwgfx device type because I plan to add more
> > vmwgfx test cases, and since vmwgfx buffer allocation is private ioctl
> > having a separate device type might be needed.
> 
> Oh, this sounds awesome. And yes, for private ioctl tests vmwgfx is
> obviuosly very much welcome!
> 
> > I can drop this until I have some vmwgfx specific test cases.
> 
> Sounds like a good plan to me.
> -Daniel

I saw latest email from Perti mentioning that this might be needed for loading
ko. I am really not sure about that but I will test without vmwgfx as a separate
driver type and see if things work.

Thanks,
Deepak


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

  reply	other threads:[~2018-10-11 15:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11  0:20 [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device Deepak Rawat
2018-10-11  0:20 ` [igt-dev] " Deepak Rawat
2018-10-11  0:21 ` [PATCH i-g-t 2/6] lib/igt_fb: Call dumb_destroy ioctl in case of dumb buffers Deepak Rawat
2018-10-11  0:21   ` [Intel-gfx] " Deepak Rawat
2018-10-11  0:21 ` [PATCH i-g-t 3/6] lib/igt_fb: Check for cairo surface success Deepak Rawat
2018-10-11  0:21   ` [Intel-gfx] " Deepak Rawat
2018-10-11 15:06   ` [igt-dev] " Ville Syrjälä
2018-10-11 15:06     ` Ville Syrjälä
2018-10-11 15:48     ` Deepak Singh Rawat
2018-10-11 15:48       ` Deepak Singh Rawat
2018-10-11  0:21 ` [PATCH i-g-t 4/6] lib: Don't call igt_require_fb_modifiers() when no modifier Deepak Rawat
2018-10-11  0:21   ` [igt-dev] " Deepak Rawat
2018-10-11 14:51   ` Ville Syrjälä
2018-10-11 14:51     ` Ville Syrjälä
2018-10-11 15:38     ` Deepak Singh Rawat
2018-10-11 15:38       ` Deepak Singh Rawat
2018-10-11 15:48       ` Daniel Vetter
2018-10-11 15:48         ` Daniel Vetter
2018-10-11  0:21 ` [PATCH i-g-t 5/6] tests/kms_atomic: Add a new test case for FB_DAMAGE_CLIPS plane property Deepak Rawat
2018-10-11  0:21   ` [Intel-gfx] " Deepak Rawat
2018-10-11  0:21 ` [PATCH i-g-t 6/6] tests/plane_damage: Integrate kernel selftest test-drm_damage_helper Deepak Rawat
2018-10-11  0:21   ` [Intel-gfx] " Deepak Rawat
2018-10-11  9:05   ` Daniel Vetter
2018-10-11  9:05     ` [Intel-gfx] " Daniel Vetter
2018-10-11 15:23     ` Deepak Singh Rawat
2018-10-11 15:23       ` [Intel-gfx] " Deepak Singh Rawat
2018-10-11 15:25       ` Daniel Vetter
2018-10-11 15:25         ` [Intel-gfx] " Daniel Vetter
2018-10-11  9:01 ` [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device Daniel Vetter
2018-10-11  9:01   ` Daniel Vetter
2018-10-11  9:11   ` Petri Latvala
2018-10-11  9:11     ` Petri Latvala
2018-10-11  9:46     ` Daniel Vetter
2018-10-11  9:46       ` Daniel Vetter
2018-10-11 15:17   ` Deepak Singh Rawat
2018-10-11 15:17     ` Deepak Singh Rawat
2018-10-11 15:27     ` Daniel Vetter
2018-10-11 15:27       ` Daniel Vetter
2018-10-11 15:32       ` Deepak Singh Rawat [this message]
2018-10-11 15:32         ` Deepak Singh Rawat
2018-10-11  9:21 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/6] " Patchwork
2018-10-11 14:22 ` [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=BYAPR05MB41814493BCA6807AA135853DBAE10@BYAPR05MB4181.namprd05.prod.outlook.com \
    --to=drawat@vmware.com \
    --cc=daniel@ffwll.ch \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=syeh@vmware.com \
    --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.