| Message ID | 1474324848-6446-1-git-send-email-dhinakaran.pandiyan@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@ffwll.ch> > Cc: Archit Taneja <architt@codeaurora.org> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> 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 >
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
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(-)