Date: Wed, 12 Jul 2017 11:17:53 +0800
From: Zhenyu Wang <zhenyuw@linux.intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        Tina Zhang <tina.zhang@intel.com>, alex.williamson@redhat.com,
        chris@chris-wilson.co.uk, zhenyuw@linux.intel.com,
        zhiyuan.lv@intel.com, zhi.a.wang@intel.com, kevin.tian@intel.com,
        intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation
Message-ID: <20170712031753.oiwg262ewkimgtlf@zhen-hp.sh.intel.com>
Reply-To: Zhenyu Wang <zhenyuw@linux.intel.com>
References: <1499293795-6265-1-git-send-email-tina.zhang@intel.com>
 <980a5c09-fa8a-255d-19ad-acf4bb29d271@nvidia.com>
 <1499753648.8257.3.camel@redhat.com>
 <20170711091236.run4zirxmr34kazb@phenom.ffwll.local>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="hx4s2a56u6mbl5kt"
Content-Disposition: inline
In-Reply-To: <20170711091236.run4zirxmr34kazb@phenom.ffwll.local>
User-Agent: NeoMutt/20170306 (1.8.0)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2054
Lines: 64


--hx4s2a56u6mbl5kt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2017.07.11 11:12:36 +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 08:14:08AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> >=20
> > > > +struct vfio_device_query_gfx_plane {
> > > > +	__u32 argsz;
> > > > +	__u32 flags;
> > > > +	struct vfio_device_gfx_plane_info plane_info;
> > > > +	__u32 plane_type;
> > > > +	__s32 fd; /* dma-buf fd */
> > > > +	__u32 plane_id;
> > > > +};
> > > > +
> > >=20
> > > It would be better to have comment here about what are expected
> > > values
> > > for plane_type and plane_id.
> >=20
> > plane_type is DRM_PLANE_TYPE_*.
> >=20
> > yes, a comment saying so would be good, same for drm_format which is
> > DRM_FORMAT_*.  While looking at these two: renaming plane_type to
> > drm_plane_type (for consistency) is probably a good idea too.

For drm universal plane, this is not in drm uapi, but uabi. I think we
can align with drm plane definition for sure, but not need to pull in
drm header for that enum type.

> >=20
> > plane_id needs a specification.
>=20
> Why do you need plane_type? With universal planes the plane_id along is
> sufficient to identify a plane on a given drm device instance. I'd just
> remove it.

This interface is to get vGPU display plane info, there's no normal
drm kms client involved, but vGPU device model trys to expose guest
planes for display. We need to ask for what type of plane required on
target vGPU. I think plane_id here doesn't mean like in drm kms,
but I'm not sure about plane_id here without details, what's the
purpose, etc.

--=20
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

--hx4s2a56u6mbl5kt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTXuabgHDW6LPt9CICxBBozTXgYJwUCWWWU4QAKCRCxBBozTXgY
J14QAJ97gExoWyRTLRls0h1obAwJ03r8OQCfeHqEC80f2crqDoDYvgGMnLyIt5E=
=20B3
-----END PGP SIGNATURE-----

--hx4s2a56u6mbl5kt--