From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Subject: Re: [PATCH 1/2] vfio: add edid api for display (vgpu) devices.
Date: Mon, 17 Sep 2018 17:15:50 +0800
Message-ID: <20180917091550.GK20737@zhen-hp.sh.intel.com>
References: <20180913054745.6353-1-kraxel@redhat.com>
 <20180913054745.6353-2-kraxel@redhat.com>
 <20180913115139.02775316@t450s.home>
 <20180914122552.3xmepqo7azzmx7ky@sirius.home.kraxel.org>
 <20180917065154.GI20737@zhen-hp.sh.intel.com>
 <20180917085033.ttcs3cpznnf3wngd@sirius.home.kraxel.org>
Reply-To: Zhenyu Wang <zhenyuw@linux.intel.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="O8nUzFXSEQuWwhTG"
Cc: Alex Williamson <alex.williamson@redhat.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        intel-gvt-dev@lists.freedesktop.org,
        open list <linux-kernel@vger.kernel.org>, kvm@vger.kernel.org
To: Gerd Hoffmann <kraxel@redhat.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20180917085033.ttcs3cpznnf3wngd@sirius.home.kraxel.org>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org


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

On 2018.09.17 10:50:33 +0200, Gerd Hoffmann wrote:
> > > +#define VFIO_DEVICE_INFO_CAP_EDID	1
> > > +
> > > +struct vfio_device_info_edid_cap {
> > > +	struct vfio_info_cap_header header;
> > > +	__u32   max_x;     /* Max display height (zero =3D=3D no limit) */
> > > +	__u32   max_y;     /* Max display height (zero =3D=3D no limit) */
> > > +};
> >=20
> > As current virtual display for Intel vGPU is still emulating against re=
al HW
> > pipeline with same limitations, asked display developers that whether o=
r not
> > specific mode can work might still depend on current or future HW behav=
ior.
> > So could we add some hints on what kind of edid mode vfio device can op=
erate?
> > Some may support arbitrary modes, but some may only support standard mo=
des.
>=20
> What kind of restrictions do we have here?  Really to a fixed list of
> standard modes?

Restriction is still with HW differences, e.g for skl/kbl with ddi wrpll
within min/max clock range which may generate any required frequency, but
I've been told for bxt there're some gaps in clock range that could be
generated.

>=20
> Some testing (kaby lake) indicates y axis has no restrictions and x axis
> gets rounded up to the next multiple of 8 pixels (32 bytes), maybe to
> align scanlines with cachelines?

That should be plane stride requirement I think.

>=20
> Oh, and btw:  Seems the resolution restriction (to 1024x768 for the
> smallest vgpu type) seems to not be enforced.  Intentional?
>=20

hmm, what do you mean here? Not enforce to have only one mode for vgpu type?
Or can't change to other mode?

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

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

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

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

iF0EARECAB0WIQTXuabgHDW6LPt9CICxBBozTXgYJwUCW59wxgAKCRCxBBozTXgY
J7O8AJsFx1JPF0xgMGdYaJXONvbIWvOM3ACglzhQ+F/jyxdCf2qr4oqUg3j+jyc=
=0BaV
-----END PGP SIGNATURE-----

--O8nUzFXSEQuWwhTG--