Re: [PATCH v2 9/9] drm/xe/multi_queue: Whitelist QUEUE_TIMESTAMP register

[Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>]

On Tue, May 05, 2026 at 10:58:42AM -0700, Umesh Nerlige Ramappa wrote:
>On Mon, May 04, 2026 at 09:25:29PM -0700, Niranjana Vishwanathapura wrote:
>>On Fri, May 01, 2026 at 05:53:42PM -0700, Umesh Nerlige Ramappa wrote:
>>>In a multi-queue use case, when a job is running on the secondary queue,
>>>the CTX_TIMESTAMP does not reflect the queues run ticks. Instead, we use
>>>the QUEUE TIMESTAMP to check how long the job ran. For user space to see
>>>the run ticks for a secondary queue, whitelist the QUEUE_TIMESTAMP
>>>register.
>>>
>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>---
>>>v2: Whitelist QUEUE_TIMESTAMP only for copy and compute engines (Niranjana)
>>>---
>>>drivers/gpu/drm/xe/xe_reg_whitelist.c | 14 ++++++++++++++
>>>1 file changed, 14 insertions(+)
>>>
>>>diff --git a/drivers/gpu/drm/xe/xe_reg_whitelist.c b/drivers/gpu/drm/xe/xe_reg_whitelist.c
>>>index 80577e4b7437..37d6ac720d5c 100644
>>>--- a/drivers/gpu/drm/xe/xe_reg_whitelist.c
>>>+++ b/drivers/gpu/drm/xe/xe_reg_whitelist.c
>>>@@ -33,6 +33,14 @@ static bool match_has_mert(const struct xe_device *xe,
>>>	return xe_device_has_mert((struct xe_device *)xe);
>>>}
>>>
>>>+static bool match_multiq_class(const struct xe_device *xe,
>>>+			       const struct xe_gt *gt,
>>>+			       const struct xe_hw_engine *hwe)
>>
>>To be consistent, we have used 'multi_queue' as naming convention
>>and avoided 'multiq'. It would be good to keep that consistency
>>everywhere.
>
>sure, will change that
>>
>>>+{
>>>+	return hwe->class == XE_ENGINE_CLASS_COMPUTE ||
>>>+	       hwe->class == XE_ENGINE_CLASS_COPY;
>>
>>We already have xe_exec_queue_supports_multi_queue() function which 
>>does similar check. I think we need to abstract it out to a single
>>function and use that instead of multiple places in code that
>>determine whether a class supports multi-queue or not.
>
>The whitelist is applied during engine init at driver load, so we 
>don't have any exec queues yet. Instead, should we derive supported 
>engines from xe_graphics_desc.multi_queue_engine_class_mask and check?
>

Yah, xe_exec_queue_supports_multi_queue() also uses it. So, may be add a
xe_gt_supports_multi_queue(struct xe_gt *gt, enum xe_engine_class class)
in xe_gt.h and use that both here and in xe_exec_queue_supports_multi_queue().

Niranjana

>Umesh
>
>>
>>Niranjana
>>
>>>+}
>>>+
>>>static const struct xe_rtp_entry_sr register_whitelist[] = {
>>>	{ XE_RTP_NAME("WaAllowPMDepthAndInvocationCountAccessFromUMD, 1408556865"),
>>>	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1200, 1210), ENGINE_CLASS(RENDER)),
>>>@@ -54,6 +62,12 @@ static const struct xe_rtp_entry_sr register_whitelist[] = {
>>>				RING_FORCE_TO_NONPRIV_ACCESS_RD,
>>>				XE_RTP_ACTION_FLAG(ENGINE_BASE)))
>>>	},
>>>+	{ XE_RTP_NAME("allow_read_queue_timestamp"),
>>>+	  XE_RTP_RULES(GRAPHICS_VERSION_RANGE(3500, 3511), FUNC(match_multiq_class)),
>>>+	  XE_RTP_ACTIONS(WHITELIST(RING_QUEUE_TIMESTAMP(0),
>>>+				   RING_FORCE_TO_NONPRIV_ACCESS_RD,
>>>+				   XE_RTP_ACTION_FLAG(ENGINE_BASE)))
>>>+	},
>>>	{ XE_RTP_NAME("16014440446"),
>>>	  XE_RTP_RULES(PLATFORM(PVC)),
>>>	  XE_RTP_ACTIONS(WHITELIST(XE_REG(0x4400),
>>>-- 
>>>2.43.0
>>>