All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marius Vlad <marius.c.vlad@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
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	[thread overview]
Message-ID: <20160119150433.GC13494@mcvlad-wk.rb.intel.com> (raw)
In-Reply-To: <20160115124645.GD23290@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 5884 bytes --]

On Fri, Jan 15, 2016 at 02:46:45PM +0200, Ville Syrjälä 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, encoders and
> > connectors.
> > 
> > Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
> > ---
> >  lib/igt_kms.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 82 insertions(+)
> > 
> > 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 functions.
> >   *
> > + * Intel/DRM terminology and display connections:
> > + *
> > + * Intel documentation describes the road from memory to an output connector as
> > + * follows:
> > + *
> > + * |[!<-- language="C" -->
> > + * .--------.     .-------.     .-------------.     .-----.
> > + * | Memory |---->| Pipes |---->| Transcoders |---->| DDI |
> > + * '--------'     '-------'     '-------------'     '-----'
> > + * ]|
> > + *
> > + * Pipes represent the front-end of the display contain the planes, blending,
> > + * and color correction, while the transcoders contain timing generators,
> > + * encoders, A/V mixers and PSR (Panel-Self Refresh) controllers. Finally the
> > + * DDI represent the connectors attached to the display.
> > + *
> > + *
> > + *  In DRM we have the following:
> > + *
> > + * |[!<-- language="C" -->
> > + * .-----------.     .-------.     .-----------.     .------------.
> > + * | Framebuff |---->| Pipes |---->| Encoders  |---->| Connectors |
> > + * '-----------'     '-------'     '-----------'     '------------'
> 
> "Framebuff"?
> 
> Also should this say crtc instead of pipe?
Right, pipe indeed.
> 
> > + * ]|
> > + *
> > + *
> > + * 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 (SKL/BXT)
> > + * each pipe has three planes and a cursor plane.
> 
> Not quite true.
> 
> > Each plane can be used as a
> > + * primary, as a sprite or as an overlay plane. The planes are the ones that
> > + * retrieve the pixels from memory and pushes them to the encoder.
> > + *
> > + * A pipe prior to GEN9:
> 
> Really more like g4x-bdw. Before g4x it was totally different, and gen4 was
> sort of mix of both the old and the new. And vlv/chv have two sprites on
> each pipe.
> 
> 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.
> 
> 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?


> 
> > + *
> > + * |[!<-- language="C" -->
> > + * .--------.
> > + * | Memory |             .--------.
> > + * |        |------------>| Cursor |------>...
> > + * |        |             '--------'
> > + * |        |
> > + * |        |         .--------.
> > + * |        |-------->| Sprite |---------->...
> > + * |        |         '--------'
> > + * |        |
> > + * |        |      .---------.
> > + * |        |----->| Primary |------------>...
> > + * |        |      '---------'
> > + * '--------'
> > + * ]|
> > + *
> > + * A pipe with universal planes:
> > + *
> > + * |[!<-- language="C" -->
> > + * .--------.
> > + * | Memory |             .--------.
> > + * |        |------------>| Cursor |------>...
> > + * |        |             '--------'
> > + * |        |
> > + * |        |         .-------.
> > + * |        |-------->| Plane |---------->...
> > + * |        |         '-------'
> > + * |        |
> > + * |        |      .-------.
> > + * |        |----->| Plane |------------>...
> > + * |        |      '-------'
> > + * '--------'
> > + * ]|
> > + *
> > + * The encoder is used to convert, depending on the output, pixels from pipes
> > + * to signals understood by the connector.
> > + *
> > + * The connector will connect to the output display. This contains information
> > + * 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.
> > -- 
> > 2.6.2
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  reply	other threads:[~2016-01-19 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  9:06 [PATCH i-g-t 1/2 v2] lib/igt_kms: Various fixes and add remaining documentation Marius Vlad
2016-01-15  9:06 ` [PATCH i-g-t 2/2] lib/igt_kms: Short description between Intel/DRM terminology Marius Vlad
2016-01-15 12:46   ` Ville Syrjälä
2016-01-19 15:04     ` Marius Vlad [this message]
2016-01-19 15:18       ` Ville Syrjälä
2016-01-19 19:45         ` Daniel Vetter

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=20160119150433.GC13494@mcvlad-wk.rb.intel.com \
    --to=marius.c.vlad@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.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.