Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ea0dd85a authored by Daniel Vetter's avatar Daniel Vetter
Browse files

drm/doc: use preferred struct reference in kernel-doc 



sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i

Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-apply these changes!

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-6-git-send-email-daniel.vetter@ffwll.ch
parent e9b4d7b5

drivers/gpu/drm/drm_atomic.c

+3 −3
Original line number Diff line number Diff line
@@ -1882,7 +1882,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb); 
 * As a contrast, with implicit fencing the kernel keeps track of any

 * ongoing rendering, and automatically ensures that the atomic update waits

 * for any pending rendering to complete. For shared buffers represented with

 * a struct &dma_buf this is tracked in &reservation_object structures.

 * a &struct dma_buf this is tracked in &reservation_object structures.

 * Implicit syncing is how Linux traditionally worked (e.g. DRI2/3 on X.org),

 * whereas explicit fencing is what Android wants.

 *
@@ -1898,7 +1898,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb); 
 *	it will only check if the Sync File is a valid one.

 *

 *	On the driver side the fence is stored on the @fence parameter of

 *	struct &drm_plane_state. Drivers which also support implicit fencing

 *	&struct drm_plane_state. Drivers which also support implicit fencing

 *	should set the implicit fence using drm_atomic_set_fence_for_plane(),

 *	to make sure there's consistent behaviour between drivers in precedence

 *	of implicit vs. explicit fencing.
@@ -1917,7 +1917,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb); 
 *	DRM_MODE_ATOMIC_TEST_ONLY flag the out fence will also be set to -1.

 *

 *	Note that out-fences don't have a special interface to drivers and are

 *	internally represented by a struct &drm_pending_vblank_event in struct

 *	internally represented by a &struct drm_pending_vblank_event in struct

 *	&drm_crtc_state, which is also used by the nonblocking atomic commit

 *	helpers and for the DRM event handling for existing userspace.

 */

drivers/gpu/drm/drm_atomic_helper.c

+4 −4
Original line number Diff line number Diff line
@@ -56,9 +56,9 @@ 
 * implement these functions themselves but must use the provided helpers.

 *

 * The atomic helper uses the same function table structures as all other

 * modesetting helpers. See the documentation for struct &drm_crtc_helper_funcs,

 * struct &drm_encoder_helper_funcs and struct &drm_connector_helper_funcs. It

 * also shares the struct &drm_plane_helper_funcs function table with the plane

 * modesetting helpers. See the documentation for &struct drm_crtc_helper_funcs,

 * struct &drm_encoder_helper_funcs and &struct drm_connector_helper_funcs. It

 * also shares the &struct drm_plane_helper_funcs function table with the plane

 * helpers.

 */

static void
@@ -1369,7 +1369,7 @@ static int stall_checks(struct drm_crtc *crtc, bool nonblock) 
 * actually committing the hardware state, and for nonblocking commits this call

 * must be placed in the async worker. See also drm_atomic_helper_swap_state()

 * and it's stall parameter, for when a driver's commit hooks look at the

 * ->state pointers of struct &drm_crtc, &drm_plane or &drm_connector directly.

 * ->state pointers of &struct drm_crtc, &drm_plane or &drm_connector directly.

 *

 * Completion of the hardware commit step must be signalled using

 * drm_atomic_helper_commit_hw_done(). After this step the driver is not allowed

drivers/gpu/drm/drm_auth.c

+4 −4
Original line number Diff line number Diff line
@@ -35,8 +35,8 @@ 
/**

 * DOC: master and authentication

 *

 * struct &drm_master is used to track groups of clients with open

 * primary/legacy device nodes. For every struct &drm_file which has had at

 * &struct drm_master is used to track groups of clients with open

 * primary/legacy device nodes. For every &struct drm_file which has had at

 * least once successfully became the device master (either through the

 * SET_MASTER IOCTL, or implicitly through opening the primary device node when

 * no one else is the current master that time) there exists one &drm_master.
@@ -294,7 +294,7 @@ EXPORT_SYMBOL(drm_is_current_master); 


/**

 * drm_master_get - reference a master pointer

 * @master: struct &drm_master

 * @master: &struct drm_master

 *

 * Increments the reference count of @master and returns a pointer to @master.

 */
@@ -322,7 +322,7 @@ static void drm_master_destroy(struct kref *kref) 


/**

 * drm_master_put - unreference and clear a master pointer

 * @master: pointer to a pointer of struct &drm_master

 * @master: pointer to a pointer of &struct drm_master

 *

 * This decrements the &drm_master behind @master and sets it to NULL.

 */

drivers/gpu/drm/drm_bridge.c

+2 −2
Original line number Diff line number Diff line
@@ -33,7 +33,7 @@ 
/**

 * DOC: overview

 *

 * struct &drm_bridge represents a device that hangs on to an encoder. These are

 * &struct drm_bridge represents a device that hangs on to an encoder. These are

 * handy when a regular &drm_encoder entity isn't enough to represent the entire

 * encoder chain.

 *
@@ -55,7 +55,7 @@ 
 * just provide additional hooks to get the desired output at the end of the

 * encoder chain.

 *

 * Bridges can also be chained up using the next pointer in struct &drm_bridge.

 * Bridges can also be chained up using the next pointer in &struct drm_bridge.

 *

 * Both legacy CRTC helpers and the new atomic modeset helpers support bridges.

 */

drivers/gpu/drm/drm_color_mgmt.c

+2 −2
Original line number Diff line number Diff line
@@ -36,7 +36,7 @@ 
 * "DEGAMMA_LUT”:

 *	Blob property to set the degamma lookup table (LUT) mapping pixel data

 *	from the framebuffer before it is given to the transformation matrix.

 *	The data is interpreted as an array of struct &drm_color_lut elements.

 *	The data is interpreted as an array of &struct drm_color_lut elements.

 *	Hardware might choose not to use the full precision of the LUT elements

 *	nor use all the elements of the LUT (for example the hardware might

 *	choose to interpolate between LUT[0] and LUT[4]).
@@ -65,7 +65,7 @@ 
 * “GAMMA_LUT”:

 *	Blob property to set the gamma lookup table (LUT) mapping pixel data

 *	after the transformation matrix to data sent to the connector. The

 *	data is interpreted as an array of struct &drm_color_lut elements.

 *	data is interpreted as an array of &struct drm_color_lut elements.

 *	Hardware might choose not to use the full precision of the LUT elements

 *	nor use all the elements of the LUT (for example the hardware might

 *	choose to interpolate between LUT[0] and LUT[4]).