summaryrefslogtreecommitdiffstats
path: root/Documentation/gpu
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2016-08-29 10:27:50 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2016-08-29 15:37:08 +0200
commite03e6de03e931bd3d93b1e2a9dc7d0bf0b505287 (patch)
tree5347b3a7fc64a3db34b469549a17311e1305b2eb /Documentation/gpu
parent321a95ae35f2ec4f58c4cda28d3606cc6f2b97d1 (diff)
downloadlinux-e03e6de03e931bd3d93b1e2a9dc7d0bf0b505287.tar.bz2
drm/doc: Polish kerneldoc for encoders
- Move missing bits into struct drm_encoder docs. - Explain that encoders are 95% internal and only 5% uapi, and that in general the uapi part is broken. - Remove verbose comments for functions not exposed to drivers. v2: Review from Archit: - Appease checkpatch in the moved code. - Make it clearer that bridges are not exposed to userspace. Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-2-daniel.vetter@ffwll.ch
Diffstat (limited to 'Documentation/gpu')
-rw-r--r--Documentation/gpu/drm-kms.rst46
1 files changed, 6 insertions, 40 deletions
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 7f788caebea3..47c2835b7c2d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -128,6 +128,12 @@ Connector Functions Reference
Encoder Abstraction
===================
+.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
+ :doc: overview
+
+Encoder Functions Reference
+---------------------------
+
.. kernel-doc:: include/drm/drm_encoder.h
:internal:
@@ -207,46 +213,6 @@ future); drivers that do not wish to provide special handling for
primary planes may make use of the helper functions described in ? to
create and register a primary plane with standard capabilities.
-Encoders (:c:type:`struct drm_encoder <drm_encoder>`)
------------------------------------------------------
-
-An encoder takes pixel data from a CRTC and converts it to a format
-suitable for any attached connectors. On some devices, it may be
-possible to have a CRTC send data to more than one encoder. In that
-case, both encoders would receive data from the same scanout buffer,
-resulting in a "cloned" display configuration across the connectors
-attached to each encoder.
-
-Encoder Initialization
-~~~~~~~~~~~~~~~~~~~~~~
-
-As for CRTCs, a KMS driver must create, initialize and register at least
-one :c:type:`struct drm_encoder <drm_encoder>` instance. The
-instance is allocated and zeroed by the driver, possibly as part of a
-larger structure.
-
-Drivers must initialize the :c:type:`struct drm_encoder
-<drm_encoder>` possible_crtcs and possible_clones fields before
-registering the encoder. Both fields are bitmasks of respectively the
-CRTCs that the encoder can be connected to, and sibling encoders
-candidate for cloning.
-
-After being initialized, the encoder must be registered with a call to
-:c:func:`drm_encoder_init()`. The function takes a pointer to the
-encoder functions and an encoder type. Supported types are
-
-- DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
-- DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
-- DRM_MODE_ENCODER_LVDS for display panels
-- DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
- Component, SCART)
-- DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
-
-Encoders must be attached to a CRTC to be used. DRM drivers leave
-encoders unattached at initialization time. Applications (or the fbdev
-compatibility layer when implemented) are responsible for attaching the
-encoders they want to use to a CRTC.
-
Cleanup
-------