All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: [PATCH 12/34] drm/doc: Clarify PRIME documentation
Date: Tue, 11 Mar 2014 11:30:08 +0100	[thread overview]
Message-ID: <1394533830-30150-13-git-send-email-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <1394533830-30150-1-git-send-email-daniel.vetter@ffwll.ch>

PRIME fds aren't actually GEM fds but are (like the modeset API)
independent of the underlying buffer manager, as long as that one uses
uint32_t as handles. So move that entire section out of the GEM
section and reword it a bit to clarify which parts of PRIME are
generic, and which are the mandatory pieces for GEM drivers to
correctly implement the GEM lifetime rules. The rewording mostly
consists of not mixing up GEM, PRIME and DRM.

I've considered adding some blurbs to the GEM object lifetime section
about interactions with dma-bufs, but then dropped that. As long as
drivers use the right helpers they should have this all implemented
correctly and hence can be regarded as an implementation detail of the
PRIME/GEM helpers. So no need to confuse driver writers with those
tricky interactions.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 Documentation/DocBook/drm.tmpl | 125 ++++++++++++++++++++++++-----------------
 1 file changed, 74 insertions(+), 51 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 0e0390ece122..641db5cb656c 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -697,55 +697,16 @@ char *date;</synopsis>
           respectively. The conversion is handled by the DRM core without any
           driver-specific support.
         </para>
-        <para>
-          Similar to global names, GEM file descriptors are also used to share GEM
-          objects across processes. They offer additional security: as file
-          descriptors must be explicitly sent over UNIX domain sockets to be shared
-          between applications, they can't be guessed like the globally unique GEM
-          names.
-        </para>
-        <para>
-          Drivers that support GEM file descriptors, also known as the DRM PRIME
-          API, must set the DRIVER_PRIME bit in the struct
-          <structname>drm_driver</structname>
-          <structfield>driver_features</structfield> field, and implement the
-          <methodname>prime_handle_to_fd</methodname> and
-          <methodname>prime_fd_to_handle</methodname> operations.
-        </para>
-        <para>
-          <synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
-                            struct drm_file *file_priv, uint32_t handle,
-                            uint32_t flags, int *prime_fd);
-  int (*prime_fd_to_handle)(struct drm_device *dev,
-                            struct drm_file *file_priv, int prime_fd,
-                            uint32_t *handle);</synopsis>
-          Those two operations convert a handle to a PRIME file descriptor and
-          vice versa. Drivers must use the kernel dma-buf buffer sharing framework
-          to manage the PRIME file descriptors.
-        </para>
-        <para>
-          While non-GEM drivers must implement the operations themselves, GEM
-          drivers must use the <function>drm_gem_prime_handle_to_fd</function>
-          and <function>drm_gem_prime_fd_to_handle</function> helper functions.
-          Those helpers rely on the driver
-          <methodname>gem_prime_export</methodname> and
-          <methodname>gem_prime_import</methodname> operations to create a dma-buf
-          instance from a GEM object (dma-buf exporter role) and to create a GEM
-          object from a dma-buf instance (dma-buf importer role).
-        </para>
-        <para>
-          <synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
-                                       struct drm_gem_object *obj,
-                                       int flags);
-  struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
-                                              struct dma_buf *dma_buf);</synopsis>
-          These two operations are mandatory for GEM drivers that support DRM
-          PRIME.
-        </para>
-        <sect4>
-          <title>DRM PRIME Helper Functions Reference</title>
-!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
-        </sect4>
+	<para>
+	  GEM also supports buffer sharing with dma-buf file descriptors through
+	  PRIME. GEM-based drivers must use the provided helpers functions to
+	  implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />.
+	  Since sharing file descriptors is inherently more secure than the
+	  easily guessable and global GEM names it is the preferred buffer
+	  sharing mechanism. Sharing buffers through GEM names is only supported
+	  for legacy userspace. Furthermore PRIME also allows cross-device
+	  buffer sharing since it is based on dma-bufs.
+	</para>
       </sect3>
       <sect3 id="drm-gem-objects-mapping">
         <title>GEM Objects Mapping</title>
@@ -868,10 +829,10 @@ char *date;</synopsis>
           abstracted from the client in libdrm.
         </para>
       </sect3>
-      <sect2>
+      <sect3>
         <title>GEM Function Reference</title>
 !Edrivers/gpu/drm/drm_gem.c
-      </sect2>
+      </sect3>
       </sect2>
       <sect2>
 	<title>VMA Offset Manager</title>
@@ -879,6 +840,68 @@ char *date;</synopsis>
 !Edrivers/gpu/drm/drm_vma_manager.c
 !Iinclude/drm/drm_vma_manager.h
       </sect2>
+      <sect2 id="drm-prime-support">
+	<title>PRIME Buffer Sharing</title>
+	<para>
+	  PRIME is the cross device buffer sharing framework in drm, originally
+	  created for the OPTIMUS range of multi-gpu platforms. To userspace
+	  PRIME buffers are dma-buf based file descriptors.
+	</para>
+	<sect3>
+	  <title>Overview and Driver Interface</title>
+	  <para>
+	    Similar to GEM global names, PRIME file descriptors are
+	    also used to share buffer objects across processes. They offer
+	    additional security: as file descriptors must be explicitly sent over
+	    UNIX domain sockets to be shared between applications, they can't be
+	    guessed like the globally unique GEM names.
+	  </para>
+	  <para>
+	    Drivers that support the PRIME
+	    API must set the DRIVER_PRIME bit in the struct
+	    <structname>drm_driver</structname>
+	    <structfield>driver_features</structfield> field, and implement the
+	    <methodname>prime_handle_to_fd</methodname> and
+	    <methodname>prime_fd_to_handle</methodname> operations.
+	  </para>
+	  <para>
+	    <synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
+			  struct drm_file *file_priv, uint32_t handle,
+			  uint32_t flags, int *prime_fd);
+int (*prime_fd_to_handle)(struct drm_device *dev,
+			  struct drm_file *file_priv, int prime_fd,
+			  uint32_t *handle);</synopsis>
+	    Those two operations convert a handle to a PRIME file descriptor and
+	    vice versa. Drivers must use the kernel dma-buf buffer sharing framework
+	    to manage the PRIME file descriptors. Similar to the mode setting
+	    API PRIME is agnostic to the underlying buffer object manager, as
+	    long as handles are 32bit unsinged integers.
+	  </para>
+	  <para>
+	    While non-GEM drivers must implement the operations themselves, GEM
+	    drivers must use the <function>drm_gem_prime_handle_to_fd</function>
+	    and <function>drm_gem_prime_fd_to_handle</function> helper functions.
+	    Those helpers rely on the driver
+	    <methodname>gem_prime_export</methodname> and
+	    <methodname>gem_prime_import</methodname> operations to create a dma-buf
+	    instance from a GEM object (dma-buf exporter role) and to create a GEM
+	    object from a dma-buf instance (dma-buf importer role).
+	  </para>
+	  <para>
+	    <synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
+				     struct drm_gem_object *obj,
+				     int flags);
+struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
+					    struct dma_buf *dma_buf);</synopsis>
+	    These two operations are mandatory for GEM drivers that support
+	    PRIME.
+	  </para>
+	</sect3>
+        <sect3>
+          <title>PRIME Helper Functions Reference</title>
+!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
+        </sect3>
+      </sect2>
   </sect1>
 
   <!-- Internals: mode setting -->
-- 
1.8.5.2

  parent reply	other threads:[~2014-03-11 10:30 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 10:29 [PATCH 00/34] drm: moar kerneldoc and cleanups Daniel Vetter
2014-03-11 10:29 ` [PATCH 01/34] drm/doc: Clarify the dumb object interfaces Daniel Vetter
2014-03-11 10:29 ` [PATCH 02/34] drm/doc: Fix up kerneldoc in drm_edid.c Daniel Vetter
2014-03-11 10:29 ` [PATCH 03/34] drm/doc: Clean up and integrate kerneldoc for drm_gem.c Daniel Vetter
2014-03-11 10:30 ` [PATCH 04/34] drm/doc: Remove <term> from rendernode docs Daniel Vetter
2014-03-11 10:30 ` [PATCH 05/34] drm/doc: Reorganize driver documentation Daniel Vetter
2014-03-11 10:30 ` [PATCH 06/34] drm/doc: Move the vma offset manager to the right spot Daniel Vetter
2014-03-11 10:30 ` [PATCH 07/34] drm/doc: Remove the "command submissin and fencing" section Daniel Vetter
2014-03-11 10:30 ` [PATCH 08/34] drm/doc: No more drm perf counters Daniel Vetter
2014-03-11 10:30 ` [PATCH 09/34] drm/doc: Document drm_helper_resume_force_mode Daniel Vetter
2014-03-11 10:30 ` [PATCH 10/34] drm/doc: Hide legacy horrors better Daniel Vetter
2014-03-11 10:30 ` [PATCH 11/34] drm/docs: Include hdmi infoframe helper reference Daniel Vetter
2014-03-11 10:30 ` Daniel Vetter [this message]
2014-03-11 10:30 ` [PATCH 13/34] drm/doc: Add PRIME function references Daniel Vetter
2014-03-11 10:30 ` [PATCH 14/34] drm/doc: Update copyright Daniel Vetter
2014-03-11 10:30 ` [PATCH 15/34] drm/mm: Remove MM_UNUSED_TARGET Daniel Vetter
2014-03-11 10:30 ` [PATCH 16/34] drm/doc: Overview documentation for drm_mm.c Daniel Vetter
2014-03-11 10:30 ` [PATCH 17/34] drm/doc: Add fucntion reference " Daniel Vetter
2014-03-11 10:30 ` [PATCH 18/34] drm/kms: rip out drm_mode_connector_detach_encoder Daniel Vetter
2014-03-11 10:30 ` [PATCH 19/34] drm/doc: Integrate drm_modes.c kerneldoc Daniel Vetter
2014-03-11 10:30 ` [PATCH 20/34] drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c Daniel Vetter
2014-03-20  1:31   ` Dave Airlie
2014-03-22  6:45     ` Ben Widawsky
2014-03-23  8:19       ` Daniel Vetter
2014-03-11 10:30 ` [PATCH 21/34] drm: move drm_mode related functions into drm_modes.c Daniel Vetter
2014-03-11 10:30 ` [PATCH 22/34] drm: extract drm_modes.h for drm_modes.c functions Daniel Vetter
2014-03-11 10:30 ` [PATCH 23/34] drm/modes: remove drm_mode_height/width Daniel Vetter
2014-03-11 10:30 ` [PATCH 24/34] drm/modes: drop return value from drm_display_mode_from_videomode Daniel Vetter
2014-03-11 10:30 ` [PATCH 25/34] drm/modes: drop maxPitch from drm_mode_validate_size Daniel Vetter
2014-03-11 10:30 ` [PATCH 26/34] drm: polish function kerneldoc for drm_modes.[hc] Daniel Vetter
2014-03-11 10:30 ` [PATCH 27/34] drm: remove drm_display_mode->private_size Daniel Vetter
2014-03-11 10:30 ` [PATCH 28/34] drm/doc: Fix misplaced </para> Daniel Vetter
2014-03-11 10:30 ` [PATCH 29/34] drm: remove return value from drm_helper_mode_fill_fb_struct Daniel Vetter
2014-03-11 10:30 ` [PATCH 30/34] drm/crtc-helper: remove LOCKING from kerneldoc Daniel Vetter
2014-03-11 10:30 ` [PATCH 31/34] drm: drop error code for drm_helper_resume_force_mode Daniel Vetter
2014-03-11 10:30 ` [PATCH 32/34] drm: kerneldoc polish for drm_crtc_helper.c Daniel Vetter
2014-03-11 10:30 ` [PATCH 33/34] drm: kerneldoc polish for drm_crtc.c Daniel Vetter
2014-03-11 10:30 ` [PATCH 34/34] drm/kms: don't export drm_mode_group_init_legacy_group Daniel Vetter
2014-03-11 14:16 ` [PATCH 00/34] drm: moar kerneldoc and cleanups Alex Deucher
2014-03-15 11:15 ` [PATCH] drm/imx: remove drm_mode_connector_detach_encoder harder Daniel Vetter
2014-03-15 11:23   ` Russell King - ARM Linux
2014-03-15 11:35     ` Daniel Vetter
2014-03-17 21:48   ` Greg Kroah-Hartman

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=1394533830-30150-13-git-send-email-daniel.vetter@ffwll.ch \
    --to=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /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.