diff mbox series

Docs: fix incorrect use of kernel-doc format in structure description.

Message ID 20190919104928.22084-1-anna.karas@intel.com (mailing list archive)
State New, archived
Headers show
Series Docs: fix incorrect use of kernel-doc format in structure description. | expand

Commit Message

Anna Karas Sept. 19, 2019, 10:49 a.m. UTC
Insert structure members names into their descriptions to follow
kernel-doc format

Signed-off-by: Anna Karas <anna.karas@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

Comments

Chris Wilson Sept. 19, 2019, 11 a.m. UTC | #1
Quoting Anna Karas (2019-09-19 11:49:28)
> Insert structure members names into their descriptions to follow
> kernel-doc format
> 
> Signed-off-by: Anna Karas <anna.karas@intel.com>

Lgtm, 
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki 
> Business Identity Code: 0357606 - 4 
> Domiciled in Helsinki 
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

We'll need to strip this disclaimer off for inclusion though :)
-Chris
Jani Nikula Sept. 19, 2019, 12:21 p.m. UTC | #2
On Thu, 19 Sep 2019, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Anna Karas (2019-09-19 11:49:28)
>> Insert structure members names into their descriptions to follow
>> kernel-doc format
>> 
>> Signed-off-by: Anna Karas <anna.karas@intel.com>
>
> Lgtm, 
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Yes, apart from subject prefix. Maybe something like "drm/i915/perf: "
would be more accurate.

BR,
Jani.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0d1949a78c44..dc6c9f52d3a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1225,7 +1225,7 @@  struct i915_perf_stream {
 	struct i915_oa_config *oa_config;
 
 	/**
-	 * The OA context specific information.
+	 * @pinned_ctx: The OA context specific information.
 	 */
 	struct intel_context *pinned_ctx;
 	u32 specific_ctx_id;
@@ -1239,7 +1239,7 @@  struct i915_perf_stream {
 	int period_exponent;
 
 	/**
-	 * State of the OA buffer.
+	 * @oa_buffer: State of the OA buffer.
 	 */
 	struct {
 		struct i915_vma *vma;
@@ -1250,7 +1250,7 @@  struct i915_perf_stream {
 		int size_exponent;
 
 		/**
-		 * Locks reads and writes to all head/tail state
+		 * @ptr_lock: Locks reads and writes to all head/tail state
 		 *
 		 * Consider: the head and tail pointer state needs to be read
 		 * consistently from a hrtimer callback (atomic context) and
@@ -1272,8 +1272,8 @@  struct i915_perf_stream {
 		spinlock_t ptr_lock;
 
 		/**
-		 * One 'aging' tail pointer and one 'aged' tail pointer ready to
-		 * used for reading.
+		 * @tails: One 'aging' tail pointer and one 'aged' tail pointer
+		 * ready to used for reading.
 		 *
 		 * Initial values of 0xffffffff are invalid and imply that an
 		 * update is required (and should be ignored by an attempted
@@ -1284,21 +1284,23 @@  struct i915_perf_stream {
 		} tails[2];
 
 		/**
-		 * Index for the aged tail ready to read() data up to.
+		 * @aged_tail_idx: Index for the aged tail ready to read() data
+		 * up to.
 		 */
 		unsigned int aged_tail_idx;
 
 		/**
-		 * A monotonic timestamp for when the current aging tail pointer
-		 * was read; used to determine when it is old enough to trust.
+		 * @aging_timestamp: A monotonic timestamp for when the current
+		 * aging tail pointer was read; used to determine when it is old
+		 * enough to trust.
 		 */
 		u64 aging_timestamp;
 
 		/**
-		 * Although we can always read back the head pointer register,
-		 * we prefer to avoid trusting the HW state, just to avoid any
-		 * risk that some hardware condition could * somehow bump the
-		 * head pointer unpredictably and cause us to forward the wrong
+		 * @head: Although we can always read back the head pointer
+		 * register, we prefer to avoid trusting the HW state, just to
+		 * avoid any risk that some hardware condition could somehow bump
+		 * the head pointer unpredictably and cause us to forward the wrong
 		 * OA buffer data to userspace.
 		 */
 		u32 head;