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 1FC9EE7718B for ; Fri, 20 Dec 2024 22:00:58 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B0B0B10F083; Fri, 20 Dec 2024 22:00:58 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="OpRprXV0"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id 45EB410F083 for ; Fri, 20 Dec 2024 22:00:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1734732057; x=1766268057; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=I4L1JoUxS/WOzmnU+ZPG3nyRXh9WFWivq5ID6yeo4XY=; b=OpRprXV0FMfm7VPRc61OVUkg2kWcI/ZY2XBmMhvgXN4+AFjW2mbA26eg tXlrCky70CIQ7L/vVYIvLR1cZlx8OWx4moVRCzCwpG1qCP1wm3tXdC19L TwHGnBoE06xewChM9Tnj74+NqUppwB5GxrOmisoefZhbjmOnQdV0andVa T+AFH8dmGIqQDreGfJ/6Ni2N7e1PYMMplrQkODhkDMbcJjKDOj5rJlCWl K8UvA/vJkHRJ6Ma03zhsK2xl0ibRNxZCGzYHEvk5UHvG/AqcuD3tWAq/d 1SW6IZ5aRCTgXLVXV8tM9L/aVyUmf17vySbPRL5FmznBJP26ElKvGipJQ w==; X-CSE-ConnectionGUID: 6jvmplurRqOJh6BcnpNgmg== X-CSE-MsgGUID: HS4itN/OR4W8z+X2xyPSmQ== X-IronPort-AV: E=McAfee;i="6700,10204,11292"; a="39072399" X-IronPort-AV: E=Sophos;i="6.12,251,1728975600"; d="scan'208";a="39072399" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Dec 2024 14:00:57 -0800 X-CSE-ConnectionGUID: ln5oaT5/SDaWxh4NVOiSPg== X-CSE-MsgGUID: 7kfbYw98RMacKc9+ypm31Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="98462863" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Dec 2024 14:00:50 -0800 Date: Fri, 20 Dec 2024 14:00:50 -0800 Message-ID: <85ed2210bx.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Cavitt, Jonathan" Cc: "Nerlige Ramappa, Umesh" , "intel-xe@lists.freedesktop.org" , "Souza, Jose" Subject: Re: [PATCH v5 1/2] xe/oa: Fix query mode of operation for OAR/OAC In-Reply-To: References: <20241220171919.571528-1-umesh.nerlige.ramappa@intel.com> <20241220171919.571528-2-umesh.nerlige.ramappa@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/28.2 (x86_64-redhat-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 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: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 20 Dec 2024 10:08:41 -0800, Cavitt, Jonathan wrote: > > > I don't have any major blocking revision notes for this. Feel free to > take or leave any of the questions/suggestions I left below. > Reviewed-by: Jonathan Cavitt Thanks. > > > --- > > drivers/gpu/drm/xe/xe_oa.c | 136 ++++++++---------------- > > drivers/gpu/drm/xe/xe_ring_ops.c | 5 +- > > drivers/gpu/drm/xe/xe_sched_job_types.h | 2 + > > 3 files changed, 51 insertions(+), 92 deletions(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c > > index ae94490b0eac..9add60097ab5 100644 > > --- a/drivers/gpu/drm/xe/xe_oa.c > > +++ b/drivers/gpu/drm/xe/xe_oa.c > > @@ -74,12 +74,6 @@ struct xe_oa_config { > > struct rcu_head rcu; > > }; > > > > -struct flex { > > - struct xe_reg reg; > > - u32 offset; > > - u32 value; > > -}; > > - > > struct xe_oa_open_param { > > struct xe_file *xef; > > u32 oa_unit_id; > > @@ -605,19 +599,38 @@ static __poll_t xe_oa_poll(struct file *file, poll_table *wait) > > return ret; > > } > > > > +static void xe_oa_lock_vma(struct xe_exec_queue *q) > > +{ > > + if (q->vm) { > > + down_read(&q->vm->lock); > > + xe_vm_lock(q->vm, false); > > + } > > +} > > + > > +static void xe_oa_unlock_vma(struct xe_exec_queue *q) > > +{ > > + if (q->vm) { > > + xe_vm_unlock(q->vm); > > + up_read(&q->vm->lock); > > + } > > +} > > + > > static struct dma_fence *xe_oa_submit_bb(struct xe_oa_stream *stream, enum xe_oa_submit_deps deps, > > struct xe_bb *bb) > > { > > + struct xe_exec_queue *q = stream->exec_q ?: stream->k_exec_q; > > struct xe_sched_job *job; > > struct dma_fence *fence; > > int err = 0; > > > > - /* Kernel configuration is issued on stream->k_exec_q, not stream->exec_q */ > > - job = xe_bb_create_job(stream->k_exec_q, bb); > > + xe_oa_lock_vma(q); > > + > > + job = xe_bb_create_job(q, bb); > > if (IS_ERR(job)) { > > err = PTR_ERR(job); > > goto exit; > > } > > + job->ggtt = true; > > > > if (deps == XE_OA_SUBMIT_ADD_DEPS) { > > for (int i = 0; i < stream->num_syncs && !err; i++) > > @@ -632,10 +645,13 @@ static struct dma_fence *xe_oa_submit_bb(struct xe_oa_stream *stream, enum xe_oa > > fence = dma_fence_get(&job->drm.s_fence->finished); > > xe_sched_job_push(job); > > > > + xe_oa_unlock_vma(q); > > + > > return fence; > > err_put_job: > > xe_sched_job_put(job); > > exit: > > + xe_oa_unlock_vma(q); > > return ERR_PTR(err); > > Non-blocking note: > Hmm... I'm not a big fan of needing to call xe_oa_unlock_vma for the > two separate cases, though unless we wanted to completely > restructure the ending sequence here, I think this is the best option. > > Though, I guess this is what the ending sequence restructuring would > look like if we took that route: > """ > fence = dma_fence_get(&job->drm.s_fence->finished); > xe_sched_job_push(job); > > err_put_job: > if (err) > xe_sched_job_put(job); > exit: > xe_oa_unlock_vma(q); > return err ? ERR_PTR(err) : fence; > } > """ > So it seems restructuring the exit sequence would be less of a bad option than > I had initially thought, but it's not a necessary change. About this, I think we are going to leave as is for now. But if interested look at include/linux/cleanup.h for some other ideas. Thanks. -- Ashutosh