Re: [PATCH] drm: Fix typo in encoder docs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 19, 2016 at 03:40:48PM -0700, Dhinakaran Pandiyan wrote:
> Corrected typo in bridge and encoder comparison. Also, added a one-line
> encoder description from the previous documentation.
> 
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> Cc: Archit Taneja <architt@xxxxxxxxxxxxxx>
> 
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx>

Thanks for spotting these and creating the patch, applied to drm-misc.
-Daniel

> ---
>  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
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux