From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Vlad Subject: Re: [PATCH i-g-t 2/2] lib/igt_kms: Short description between Intel/DRM terminology. Date: Tue, 19 Jan 2016 17:04:33 +0200 Message-ID: <20160119150433.GC13494@mcvlad-wk.rb.intel.com> References: <1452848802-8041-1-git-send-email-marius.c.vlad@intel.com> <1452848802-8041-2-git-send-email-marius.c.vlad@intel.com> <20160115124645.GD23290@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1373291280==" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 240536E778 for ; Tue, 19 Jan 2016 07:03:46 -0800 (PST) In-Reply-To: <20160115124645.GD23290@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1373291280== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LwW0XdcUbUexiWVK" Content-Disposition: inline --LwW0XdcUbUexiWVK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 15, 2016 at 02:46:45PM +0200, Ville Syrj=E4l=E4 wrote: > On Fri, Jan 15, 2016 at 11:06:42AM +0200, Marius Vlad wrote: > > lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes, encod= ers and > > connectors. > >=20 > > Signed-off-by: Marius Vlad > > --- > > lib/igt_kms.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++ > > 1 file changed, 82 insertions(+) > >=20 > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c > > index c7a0b77..caa8837 100644 > > --- a/lib/igt_kms.c > > +++ b/lib/igt_kms.c > > @@ -68,6 +68,88 @@ > > * functions have all igt_ prefixes. This part is still very much work= in > > * progress and so also lacks a bit documentation for the individual f= unctions. > > * > > + * Intel/DRM terminology and display connections: > > + * > > + * Intel documentation describes the road from memory to an output con= nector as > > + * follows: > > + * > > + * |[!<-- language=3D"C" --> > > + * .--------. .-------. .-------------. .-----. > > + * | Memory |---->| Pipes |---->| Transcoders |---->| DDI | > > + * '--------' '-------' '-------------' '-----' > > + * ]| > > + * > > + * Pipes represent the front-end of the display contain the planes, bl= ending, > > + * and color correction, while the transcoders contain timing generato= rs, > > + * encoders, A/V mixers and PSR (Panel-Self Refresh) controllers. Fina= lly the > > + * DDI represent the connectors attached to the display. > > + * > > + * > > + * In DRM we have the following: > > + * > > + * |[!<-- language=3D"C" --> > > + * .-----------. .-------. .-----------. .------------. > > + * | Framebuff |---->| Pipes |---->| Encoders |---->| Connectors | > > + * '-----------' '-------' '-----------' '------------' >=20 > "Framebuff"? >=20 > Also should this say crtc instead of pipe? Right, pipe indeed. >=20 > > + * ]| > > + * > > + * > > + * The frame buffer ties a reference to a memory object and provides a= pointer > > + * to the actual data. > > + * > > + * The pipe is used to set the display mode, timings and gamma tables.= On some > > + * hardware models this is tied with the transcoder. In DRM-parlance = this is > > + * referred as a CRTC. > > + * > > + * Each pipe has multiple planes. On older hardware these planes where= known as > > + * primary plane, overlay/sprite plane, and cursor plane. From GEN9 (S= KL/BXT) > > + * each pipe has three planes and a cursor plane. >=20 > Not quite true. >=20 > > Each plane can be used as a > > + * primary, as a sprite or as an overlay plane. The planes are the one= s that > > + * retrieve the pixels from memory and pushes them to the encoder. > > + * > > + * A pipe prior to GEN9: >=20 > Really more like g4x-bdw. Before g4x it was totally different, and gen4 w= as > sort of mix of both the old and the new. And vlv/chv have two sprites on > each pipe. >=20 > So given all the variations in the hardware, and the fact that it keeps > changing all the time, I'm not convinced there's any point in > documenting this in igt. It'll get stale real quick, and there are > efforts to decouple igt from i915 as much as possible, so next thing you > know someone else will want to docuemnt their favorite hardware here as > well. >=20 > So if we do want to document this stuff, then I think it should be > somewhere in the kernel modeset code (around crtc/plane init I suppose). Yes, it might make more sense to be in the kernel. What I wanted to achieve with this small intro was to bridge the gap between DRM terminology and the one in Intel 01.org PRM for igt. For a first timer is rather tedious to identify software/hadware abstraction when looking at the PRMs and when looking in igt -- I know for a fact that I'm still having trouble identifying those parts. Daniel has already suggested to add some documention between DRM-to-Intel Mappings in the kernel. Do you suggest that we should document all platforms? >=20 > > + * > > + * |[!<-- language=3D"C" --> > > + * .--------. > > + * | Memory | .--------. > > + * | |------------>| Cursor |------>... > > + * | | '--------' > > + * | | > > + * | | .--------. > > + * | |-------->| Sprite |---------->... > > + * | | '--------' > > + * | | > > + * | | .---------. > > + * | |----->| Primary |------------>... > > + * | | '---------' > > + * '--------' > > + * ]| > > + * > > + * A pipe with universal planes: > > + * > > + * |[!<-- language=3D"C" --> > > + * .--------. > > + * | Memory | .--------. > > + * | |------------>| Cursor |------>... > > + * | | '--------' > > + * | | > > + * | | .-------. > > + * | |-------->| Plane |---------->... > > + * | | '-------' > > + * | | > > + * | | .-------. > > + * | |----->| Plane |------------>... > > + * | | '-------' > > + * '--------' > > + * ]| > > + * > > + * The encoder is used to convert, depending on the output, pixels fro= m pipes > > + * to signals understood by the connector. > > + * > > + * The connector will connect to the output display. This contains inf= ormation > > + * about the attached display such as EDID, DPMS and information about= modes > > + * supported by the display. > > + * > > * Note that this library's header pulls in the [i-g-t > > * framebuffer](intel-gpu-tools-Framebuffer.html) library as a > > * dependency. > > --=20 > > 2.6.2 > >=20 > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >=20 > --=20 > Ville Syrj=E4l=E4 > Intel OTC --LwW0XdcUbUexiWVK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWnlCBAAoJELmLWIAQzyE+8XoH/jctaPrzY6sFX3UbefANywuf qLoFNoYup8LTNQ9nVFnAopPuE55T/MfkGluGp05VLlZmEFHjEOnA6iN58CrH41zD xsB+rawO0H6oMNrT9QDmgGJh7cvijES5z7a1De1oUOJlIC5up4TCKnjyKDKGpYad 3j6n85HF/MJO/Qx/zxCFrWVrhD4W5jBq8RdXjBVc1k8wSD0Q+0R37sjuyaIVzL/8 yqwgh7D1kYWGqjeSR6j73Vrs79sc+vgujxuPZ6tyO5tnUwZm8T8dVdHJfeHMQidY Y+Mqh+CVoV53n4ylNKKnBMsQsGdTj6CTIDH6Xqsd89I75NTHAbrOWkd1hAtz1lw= =I8ni -----END PGP SIGNATURE----- --LwW0XdcUbUexiWVK-- --===============1373291280== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK --===============1373291280==--