diff options
Diffstat (limited to 'Documentation/DocBook')
| -rw-r--r-- | Documentation/DocBook/device-drivers.tmpl | 36 | ||||
| -rw-r--r-- | Documentation/DocBook/gpu.tmpl | 38 |
2 files changed, 47 insertions, 27 deletions
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index de79efdad46c..c3313d45f4d6 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -128,16 +128,48 @@ X!Edrivers/base/interface.c !Edrivers/base/platform.c !Edrivers/base/bus.c </sect1> - <sect1><title>Device Drivers DMA Management</title> + <sect1> + <title>Buffer Sharing and Synchronization</title> + <para> + The dma-buf subsystem provides the framework for sharing buffers + for hardware (DMA) access across multiple device drivers and + subsystems, and for synchronizing asynchronous hardware access. + </para> + <para> + This is used, for example, by drm "prime" multi-GPU support, but + is of course not limited to GPU use cases. + </para> + <para> + The three main components of this are: (1) dma-buf, representing + a sg_table and exposed to userspace as a file descriptor to allow + passing between devices, (2) fence, which provides a mechanism + to signal when one device as finished access, and (3) reservation, + which manages the shared or exclusive fence(s) associated with + the buffer. + </para> + <sect2><title>dma-buf</title> !Edrivers/dma-buf/dma-buf.c +!Iinclude/linux/dma-buf.h + </sect2> + <sect2><title>reservation</title> +!Pdrivers/dma-buf/reservation.c Reservation Object Overview +!Edrivers/dma-buf/reservation.c +!Iinclude/linux/reservation.h + </sect2> + <sect2><title>fence</title> !Edrivers/dma-buf/fence.c -!Edrivers/dma-buf/seqno-fence.c !Iinclude/linux/fence.h +!Edrivers/dma-buf/seqno-fence.c !Iinclude/linux/seqno-fence.h +!Edrivers/dma-buf/fence-array.c +!Iinclude/linux/fence-array.h !Edrivers/dma-buf/reservation.c !Iinclude/linux/reservation.h !Edrivers/dma-buf/sync_file.c !Iinclude/linux/sync_file.h + </sect2> + </sect1> + <sect1><title>Device Drivers DMA Management</title> !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c </sect1> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 7586bf75f62e..d09536c91717 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1018,6 +1018,11 @@ int max_width, max_height;</synopsis> </para> </sect2> <sect2> + <title>DRM Format Handling</title> +!Iinclude/drm/drm_fourcc.h +!Edrivers/gpu/drm/drm_fourcc.c + </sect2> + <sect2> <title>Dumb Buffer Objects</title> <para> The KMS API doesn't standardize backing storage object creation and @@ -1092,22 +1097,6 @@ int max_width, max_height;</synopsis> operation. </para> </sect2> - <sect2> - <title>Locking</title> - <para> - Beside some lookup structures with their own locking (which is hidden - behind the interface functions) most of the modeset state is protected - by the <code>dev-<mode_config.lock</code> mutex and additionally - per-crtc locks to allow cursor updates, pageflips and similar operations - to occur concurrently with background tasks like output detection. - Operations which cross domains like a full modeset always grab all - locks. Drivers there need to protect resources shared between crtcs with - additional locking. They also need to be careful to always grab the - relevant crtc locks if a modset functions touches crtc state, e.g. for - load detection (which does only grab the <code>mode_config.lock</code> - to allow concurrent screen updates on live crtcs). - </para> - </sect2> </sect1> <!-- Internals: kms initialization and cleanup --> @@ -1586,7 +1575,7 @@ void intel_crt_init(struct drm_device *dev) </sect3> <sect3> <title>Implementing Asynchronous Atomic Commit</title> -!Pdrivers/gpu/drm/drm_atomic_helper.c implementing async commit +!Pdrivers/gpu/drm/drm_atomic_helper.c implementing nonblocking commit </sect3> <sect3> <title>Atomic State Reset and Initialization</title> @@ -1699,6 +1688,12 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_panel.c !Pdrivers/gpu/drm/drm_panel.c drm panel </sect2> + <sect2> + <title>Simple KMS Helper Reference</title> +!Iinclude/drm/drm_simple_kms_helper.h +!Edrivers/gpu/drm/drm_simple_kms_helper.c +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview + </sect2> </sect1> <!-- Internals: kms properties --> @@ -2845,14 +2840,7 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis> <para> Drivers must initialize the vertical blanking handling core with a call to <function>drm_vblank_init</function> in their - <methodname>load</methodname> operation. The function will set the struct - <structname>drm_device</structname> - <structfield>vblank_disable_allowed</structfield> field to 0. This will - keep vertical blanking interrupts enabled permanently until the first mode - set operation, where <structfield>vblank_disable_allowed</structfield> is - set to 1. The reason behind this is not clear. Drivers can set the field - to 1 after <function>calling drm_vblank_init</function> to make vertical - blanking interrupts dynamically managed from the beginning. + <methodname>load</methodname> operation. </para> <para> Vertical blanking interrupts can be enabled by the DRM core or by drivers |