diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-01-25 07:26:45 +0100 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-01-25 16:30:34 +0100 |
commit | d574528a64c3a3b2a9c6a125e2428b38bddbdf3c (patch) | |
tree | bd6f2868577455ce8910346fc8033d63a93b0314 /drivers/gpu/drm/drm_blend.c | |
parent | ef40cbf9998528e4f4457df52624d56ae95a7dee (diff) | |
download | linux-d574528a64c3a3b2a9c6a125e2428b38bddbdf3c.tar.gz linux-d574528a64c3a3b2a9c6a125e2428b38bddbdf3c.tar.bz2 linux-d574528a64c3a3b2a9c6a125e2428b38bddbdf3c.zip |
drm/kms-core: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I read a lot
of docs ...
v2: Review from Eric.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-4-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/gpu/drm/drm_blend.c')
-rw-r--r-- | drivers/gpu/drm/drm_blend.c | 11 |
1 files changed, 5 insertions, 6 deletions
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 1f2412c7ccfd..665aafc6ad68 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -40,9 +40,8 @@ * sub-pixel accuracy, which is scaled up to a pixel-aligned destination * rectangle in the visible area of a &drm_crtc. The visible area of a CRTC is * defined by the horizontal and vertical visible pixels (stored in @hdisplay - * and @vdisplay) of the requested mode (stored in @mode in the - * &drm_crtc_state). These two rectangles are both stored in the - * &drm_plane_state. + * and @vdisplay) of the requested mode (stored in &drm_crtc_state.mode). These + * two rectangles are both stored in the &drm_plane_state. * * For the atomic ioctl the following standard (atomic) properties on the plane object * encode the basic plane composition model: @@ -215,7 +214,7 @@ EXPORT_SYMBOL(drm_rotation_simplify); * for it in drm core. Drivers can then attach this property to planes to enable * support for configurable planes arrangement during blending operation. * Once mutable zpos property has been enabled, the DRM core will automatically - * calculate drm_plane_state->normalized_zpos values. Usually min should be set + * calculate &drm_plane_state.normalized_zpos values. Usually min should be set * to 0 and max to maximal number of planes for given crtc - 1. * * If zpos of some planes cannot be changed (like fixed background or @@ -367,8 +366,8 @@ done: * For every CRTC this function checks new states of all planes assigned to * it and calculates normalized zpos value for these planes. Planes are compared * first by their zpos values, then by plane id (if zpos is equal). The plane - * with lowest zpos value is at the bottom. The plane_state->normalized_zpos is - * then filled with unique values from 0 to number of active planes in crtc + * with lowest zpos value is at the bottom. The &drm_plane_state.normalized_zpos + * is then filled with unique values from 0 to number of active planes in crtc * minus one. * * RETURNS |