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 84D4DC5472C for ; Mon, 26 Aug 2024 23:43:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4EA5E10E1EC; Mon, 26 Aug 2024 23:43:55 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="WuaHb4c/"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6461910E1EC for ; Mon, 26 Aug 2024 23:43:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724715834; x=1756251834; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=eYSq3yffZI70CrllnIdLcpHHdhu7r23k7nxb/BGO824=; b=WuaHb4c/u1QMtSAm4Ke+AJLDwfRe1aQZG59WV7WGxm8Adu9VgA8DQBJ6 B+3sI988FUAGmXzDoef9AbwLg36wvHSDneJfEFon2aTiVwN86LzltH2kF boQUJJk124d54MddRzSLVRoek8FdjaU1GBnPjCiB/1KM/z2Y3avDHeLTq NNMRYGAmKe/8GXlaaQajDKRql+BKxtajcfjJ9rcsbHMGs+nAzmyAC4aXe 4nHPRnUyONw9KlYPXhbrjX1xAmUyxGZfOOynbLtsYDjgcSaV5vcYY7CXu mYkbZGOP2yLU4caO4t5aPkcrnjR/QZOc9NnMngjweEDsVLaMnMZMFpX7l A==; X-CSE-ConnectionGUID: 8MuZBpf9RS2pBOGPECJTDw== X-CSE-MsgGUID: AXerEjBiTmi6QnXr4H0luQ== X-IronPort-AV: E=McAfee;i="6700,10204,11176"; a="13226079" X-IronPort-AV: E=Sophos;i="6.10,178,1719903600"; d="scan'208";a="13226079" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 16:43:53 -0700 X-CSE-ConnectionGUID: 4PBk0g6eQxud6Iux6xDhrA== X-CSE-MsgGUID: h+jtFEobRGKGGwtG7bE87w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,178,1719903600"; d="scan'208";a="62633391" Received: from dsanche3-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.124.84.89]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2024 16:43:53 -0700 Date: Mon, 26 Aug 2024 16:24:30 -0700 Message-ID: <87cyluuatt.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Michal Wajdeczko Cc: intel-xe@lists.freedesktop.org, Matt Roper , Rodrigo Vivi Subject: Re: [PATCH 3/3] drm/xe: Use VF_CAP_REG for device wmb In-Reply-To: <20240702183704.1022-4-michal.wajdeczko@intel.com> References: <20240702183704.1022-1-michal.wajdeczko@intel.com> <20240702183704.1022-4-michal.wajdeczko@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.4 (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 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 Tue, 02 Jul 2024 11:37:04 -0700, Michal Wajdeczko wrote: > I have a couple of questions about xe_device_wmb() below: > To force a write barrier on the device memory, we write to the > SOFTWARE_FLAGS_SPR33 register, but this particular register was > selected because it was one of the writable and unused register. > > Since a write barrier should also work if we use the read-only > register, switch to VF_CAP_REG register that is also marked as > accessible for VFs. > > While at it, add simple kernel-doc for xe_device_wmb() function. > > Signed-off-by: Michal Wajdeczko > Cc: Matt Roper > --- > drivers/gpu/drm/xe/xe_device.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c > index cfda7cb5df2c..74beddb55284 100644 > --- a/drivers/gpu/drm/xe/xe_device.c > +++ b/drivers/gpu/drm/xe/xe_device.c > @@ -744,13 +744,22 @@ void xe_device_shutdown(struct xe_device *xe) > { > } > > +/** > + * xe_device_wmb() - Device specific write memory barrier > + * @xe: the &xe_device > + * > + * While wmb() is sufficient for a barrier if we use system memory, on discrete > + * platforms with device memory we additionally need to issue a register write. > + * Since it doesn't matter which register we write to, use the read-only VF_CAP > + * register that is also marked as accessible by the VFs. > + */ > void xe_device_wmb(struct xe_device *xe) > { > struct xe_gt *gt = xe_root_mmio_gt(xe); > > wmb(); > if (IS_DGFX(xe)) > - xe_mmio_write32(gt, SOFTWARE_FLAGS_SPR33, 0); > + xe_mmio_write32(gt, VF_CAP_REG, 0); * What is the purpose of this register write following wmb (aka sfence)? As far as I understand, wmb/sfence should be sufficient by itself. If we wanted to flush PCI transactions, we should have to issue a PCI read, but here we are not doing that. * Why only Xe has such a function, why is such a function not present in any of the other drivers, including i915? * Also, as an aside, use of write barriers in the kernel requires a comment saying which read barrier the write barrier is paired with. Generally speaking, such comments are missing in Xe. I have sent a patch with xe_device_wmb() replaced just with wmb() here: https://patchwork.freedesktop.org/series/137818/ Let's see if we see any failures in CI with this patch. Thanks. -- Ashutosh