From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2A11FCDB482 for ; Tue, 17 Oct 2023 15:38:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D85B010E182; Tue, 17 Oct 2023 15:38:24 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3788210E182 for ; Tue, 17 Oct 2023 15:38:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697557103; x=1729093103; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=yETGGPCICzn+24DmWFniEPiW4z/nMqZG/y9I8KiSQuw=; b=kh+Ype1atvOhvlW2Su/yOnBJJyfug6+3Sg0PUPOqpmwW6TLlayYveaXM wJ2qu4aRdN9i2LmIOkQAU0hpWUxrmDnXCaYQvGFuSi1pJwhlK9n2u9qPb 44cxE2qCJ9BVdW4X7y0+kAVE+C4fhTxM/SbBcSa1iwSbVMPevYjyzIF/4 3fOIBctIxFLhyqZxbO1YKbWEzrSbNx54WLBRC74R4ZORbD4gCuahraDF3 bAK6OQJR40SzU0wseqUzo0MNLpMq/FykCC+FTQnnDTuDobFg+eh8Fs2Gn xYsMWRODi9/d4mE6lHHpDwaJHlFfh4onm973u6G9ETaewIOmvwCcEwHhF g==; X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="416892631" X-IronPort-AV: E=Sophos;i="6.03,232,1694761200"; d="scan'208";a="416892631" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 08:38:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="785520074" X-IronPort-AV: E=Sophos;i="6.03,232,1694761200"; d="scan'208";a="785520074" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.11.216]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 08:38:22 -0700 Date: Tue, 17 Oct 2023 08:37:47 -0700 Message-ID: <871qdtdzuc.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Francois Dugast In-Reply-To: <20231006095943.7-11-francois.dugast@intel.com> References: <20231006095943.7-1-francois.dugast@intel.com> <20231006095943.7-11-francois.dugast@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-xe] [PATCH v5 10/20] drm/xe: Remove XE_EXEC_QUEUE_SET_PROPERTY_COMPUTE_MODE from uAPI X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-xe@lists.freedesktop.org, Rodrigo Vivi Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 06 Oct 2023 02:59:33 -0700, Francois Dugast wrote: > Hi Francois, > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h > index ad21ba1d6e0b..2a9e04024723 100644 > --- a/include/uapi/drm/xe_drm.h > +++ b/include/uapi/drm/xe_drm.h > @@ -781,21 +781,14 @@ struct drm_xe_exec_queue_set_property { > /** @exec_queue_id: Exec queue ID */ > __u32 exec_queue_id; > > -#define XE_EXEC_QUEUE_SET_PROPERTY_PRIORITY 0 > +#define XE_EXEC_QUEUE_SET_PROPERTY_PRIORITY 0 > #define XE_EXEC_QUEUE_SET_PROPERTY_TIMESLICE 1 > #define XE_EXEC_QUEUE_SET_PROPERTY_PREEMPTION_TIMEOUT 2 > - /* > - * Long running or ULLS engine mode. DMA fences not allowed in this > - * mode. Must match the value of DRM_XE_VM_CREATE_COMPUTE_MODE, serves > - * as a sanity check the UMD knows what it is doing. Can only be set at > - * engine create time. > - */ > -#define XE_EXEC_QUEUE_SET_PROPERTY_COMPUTE_MODE 3 > -#define XE_EXEC_QUEUE_SET_PROPERTY_PERSISTENCE 4 > -#define XE_EXEC_QUEUE_SET_PROPERTY_JOB_TIMEOUT 5 > -#define XE_EXEC_QUEUE_SET_PROPERTY_ACC_TRIGGER 6 > -#define XE_EXEC_QUEUE_SET_PROPERTY_ACC_NOTIFY 7 > -#define XE_EXEC_QUEUE_SET_PROPERTY_ACC_GRANULARITY 8 > +#define XE_EXEC_QUEUE_SET_PROPERTY_PERSISTENCE 3 > +#define XE_EXEC_QUEUE_SET_PROPERTY_JOB_TIMEOUT 4 > +#define XE_EXEC_QUEUE_SET_PROPERTY_ACC_TRIGGER 5 > +#define XE_EXEC_QUEUE_SET_PROPERTY_ACC_NOTIFY 6 > +#define XE_EXEC_QUEUE_SET_PROPERTY_ACC_GRANULARITY 7 > /** @property: property to set */ > __u32 property; > > /** @value: property value */ > __u64 value; Mostly a nit, but I had a question about this because I am facing a similar decision elsewhere. Why do we have one property/value pair in this struct when all the rest of the property/value pairs are coming in via the extensions? Basically, how about removing this property/value pair from thus struct and let all the property/value pairs come in only via extensions? I think that would both simplify the code a bit and be more consistent. Thoughts? Thanks. -- Ashutosh