[PATCH] drm: Fix typo in encoder docs

* [PATCH] drm: Fix typo in encoder docs
@ 2016-09-19 22:40 Dhinakaran Pandiyan
  2016-09-19 22:50 ` ✗ Fi.CI.BAT: warning for " Patchwork
  2016-09-21 11:34 ` [PATCH] " Daniel Vetter
  0 siblings, 2 replies; 3+ messages in thread
From: Dhinakaran Pandiyan @ 2016-09-19 22:40 UTC (permalink / raw)
  To: dri-devel; +Cc: Daniel Vetter, intel-gfx, Dhinakaran Pandiyan, Archit Taneja

Corrected typo in bridge and encoder comparison. Also, added a one-line
encoder description from the previous documentation.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Archit Taneja <architt@codeaurora.org>

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
 drivers/gpu/drm/drm_encoder.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 998a674..5c06771 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -31,20 +31,21 @@
  *
  * Encoders represent the connecting element between the CRTC (as the overall
  * pixel pipeline, represented by struct &drm_crtc) and the connectors (as the
- * generic sink entity, represented by struct &drm_connector). Encoders are
- * objects exposed to userspace, originally to allow userspace to infer cloning
- * and connector/CRTC restrictions. Unfortunately almost all drivers get this
- * wrong, making the uabi pretty much useless. On top of that the exposed
- * restrictions are too simple for todays hardware, and the recommend way to
- * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
- * atomic IOCTL.
+ * generic sink entity, represented by struct &drm_connector). An encoder takes
+ * pixel data from a CRTC and converts it to a format suitable for any attached
+ * connector. Encoders are objects exposed to userspace, originally to allow
+ * userspace to infer cloning and connector/CRTC restrictions. Unfortunately
+ * almost all drivers get this wrong, making the uabi pretty much useless. On
+ * top of that the exposed restrictions are too simple for today's hardware, and
+ * the recommended way to infer restrictions is by using the
+ * DRM_MODE_ATOMIC_TEST_ONLY flag for the atomic IOCTL.
  *
  * Otherwise encoders aren't used in the uapi at all (any modeset request from
  * userspace directly connects a connector with a CRTC), drivers are therefore
  * free to use them however they wish. Modeset helper libraries make strong use
  * of encoders to facilitate code sharing. But for more complex settings it is
  * usually better to move shared code into a separate &drm_bridge. Compared to
- * encoders bridges also have the benefit of not being purely an internal
+ * encoders, bridges also have the benefit of being purely an internal
  * abstraction since they are not exposed to userspace at all.
  *
  * Encoders are initialized with drm_encoder_init() and cleaned up using
-- 
2.5.0

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

^ permalink raw reply related	[flat|nested] 3+ messages in thread