All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marcin Ślusarz" <marcin.slusarz@arm.com>
To: Liviu Dudau <liviu.dudau@arm.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Steven Price <steven.price@arm.com>,
	dri-devel@lists.freedesktop.org, Chia-I Wu <olvaffe@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Lukas Zapolskas <lukas.zapolskas@arm.com>,
	nd@arm.com
Subject: Re: [PATCH v3] drm/panthor: extend timestamp query with flags
Date: Thu, 19 Mar 2026 13:39:40 +0100	[thread overview]
Message-ID: <abvujKZxtg0zvFaz@e129842.arm.com> (raw)
In-Reply-To: <abvhcedS46eLEYVB@e142607>

On Thu, Mar 19, 2026 at 11:43:45AM +0000, Liviu Dudau wrote:
> Hi Marcin,
> 
> On Thu, Mar 19, 2026 at 12:00:53PM +0100, Marcin Slusarz wrote:
> > ...
> > +#define VALID_TIMESTAMP_QUERY_FLAGS \
> > +		(DRM_PANTHOR_TIMESTAMP_GPU | \
> > +		 DRM_PANTHOR_TIMESTAMP_CPU_TYPE_MASK | \
> > +		 DRM_PANTHOR_TIMESTAMP_GPU_OFFSET | \
> > +		 DRM_PANTHOR_TIMESTAMP_GPU_CYCLE_COUNT | \
> > +		 DRM_PANTHOR_TIMESTAMP_FREQ | \
> > +		 DRM_PANTHOR_TIMESTAMP_DURATION)
> > +
> >  static int panthor_query_timestamp_info(struct panthor_device *ptdev,
> >  					struct drm_panthor_timestamp_info *arg)
> >  {
> >  	int ret;
> > +	u32 flags;
> > +	unsigned long irq_flags;
> > +	struct timespec64 cpu_ts;
> > +	u64 query_start_time;
> > +	bool minimize_interruption;
> > +	u32 timestamp_types = 0;
> > +
> > +	if (arg->flags != 0) {
> > +		flags = arg->flags;
> > +	} else {
> > +		/*
> > +		 * If flags are 0, then ask for the same things that we asked
> > +		 * for before flags were added.
> > +		 */
> > +		flags = DRM_PANTHOR_TIMESTAMP_GPU |
> > +			DRM_PANTHOR_TIMESTAMP_GPU_OFFSET |
> > +			DRM_PANTHOR_TIMESTAMP_FREQ;
> > +	}
> > +
> > +	switch (flags & DRM_PANTHOR_TIMESTAMP_CPU_TYPE_MASK) {
> > +	case 0:

Umm, this should be DRM_PANTHOR_TIMESTAMP_CPU_NONE.

> > +		break;
> > +	case DRM_PANTHOR_TIMESTAMP_CPU_MONOTONIC:
> > +	case DRM_PANTHOR_TIMESTAMP_CPU_MONOTONIC_RAW:
> > +		timestamp_types++;
> > +		break;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +
> > +	if (flags & ~VALID_TIMESTAMP_QUERY_FLAGS)
> > +		return -EINVAL;
> 
> Can we move this check before the switch and simplify the switch itself to only do the timestamp_types increment?

DRM_PANTHOR_TIMESTAMP_CPU_TYPE_MASK is bit field that holds individual
clock type values, so we still need to validate the bit field.

> > +
> > +	if (flags & DRM_PANTHOR_TIMESTAMP_GPU)
> > +		timestamp_types++;
> > +	if (flags & DRM_PANTHOR_TIMESTAMP_GPU_CYCLE_COUNT)
> > +		timestamp_types++;
> > +
> > +	/* If user asked to obtain timestamps from more than one source,
> > +	 * then it very likely means they want them to be as close as possible.
> > +	 * If they asked for duration, then that likely means that they
> > +	 * want to know how long obtaining timestamp takes, without random
> > +	 * events, like process scheduling or interrupts.
> > +	 */
> 
> This comment makes me think that user can ask for both CPU_MONOTONIC and
> CPU_MONOTONIC_RAW timestamps, but the code is built to make them exclusive.
> Can we document better what sources can be requested simultaneously?

Somethine like this?

diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
index 8a46ef040c3d..0e455d91e77d 100644
--- a/include/uapi/drm/panthor_drm.h
+++ b/include/uapi/drm/panthor_drm.h
@@ -466,6 +466,11 @@ struct drm_panthor_timestamp_info {
         *  DRM_PANTHOR_TIMESTAMP_GPU |
         *  DRM_PANTHOR_TIMESTAMP_GPU_OFFSET |
         *  DRM_PANTHOR_TIMESTAMP_FREQ
+        *
+        * Note: these flags are exclusive to each other (only one can be used):
+        * - DRM_PANTHOR_TIMESTAMP_CPU_NONE
+        * - DRM_PANTHOR_TIMESTAMP_CPU_MONOTONIC
+        * - DRM_PANTHOR_TIMESTAMP_CPU_MONOTONIC_RAW
         */
        __u32 flags;
 

  reply	other threads:[~2026-03-19 12:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 11:29 [PATCH] drm/panthor: extend timestamp query with flags Marcin Slusarz
2026-03-18 12:10 ` Boris Brezillon
2026-03-18 14:51   ` Marcin Ślusarz
2026-03-18 15:20     ` Steven Price
2026-03-18 16:06       ` Boris Brezillon
2026-03-18 16:27         ` Marcin Ślusarz
2026-03-18 16:37           ` Boris Brezillon
2026-03-18 16:34       ` Boris Brezillon
2026-03-19  8:25 ` [PATCH v2] " Marcin Slusarz
2026-03-19 10:15   ` Boris Brezillon
2026-03-19 11:00 ` [PATCH v3] " Marcin Slusarz
2026-03-19 11:10   ` Boris Brezillon
2026-03-19 11:43   ` Liviu Dudau
2026-03-19 12:39     ` Marcin Ślusarz [this message]
2026-03-19 15:17       ` Liviu Dudau
2026-03-19 15:33         ` Marcin Ślusarz
2026-03-23 13:16           ` Liviu Dudau
2026-03-23 16:12             ` Marcin Ślusarz
2026-03-24 10:41               ` Liviu Dudau
2026-03-24 13:26                 ` Marcin Ślusarz
2026-03-24 13:25 ` [PATCH v4] " Marcin Slusarz
2026-03-24 15:25   ` Liviu Dudau
2026-03-24 16:05   ` Liviu Dudau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abvujKZxtg0zvFaz@e129842.arm.com \
    --to=marcin.slusarz@arm.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=liviu.dudau@arm.com \
    --cc=lukas.zapolskas@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nd@arm.com \
    --cc=olvaffe@gmail.com \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.