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 EC781C52D71 for ; Fri, 9 Aug 2024 09:22:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A869110E88E; Fri, 9 Aug 2024 09:22:01 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="dhtk6qnX"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by gabe.freedesktop.org (Postfix) with ESMTPS id D671110E88E for ; Fri, 9 Aug 2024 09:21:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723195320; x=1754731320; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=uBeIZgJMRhVr2KGoaBCSQZrQPPQAWZ7h/F7HlVb3ZYA=; b=dhtk6qnXui3tpPlRZ5iq4MVdO/4FIX4Bmj9c0su48cUd6rIz7gv6uy5T oUXnmGYN4hoZ2b6sJdU+e8eHHanzzHyHHnKvzOOgxqiQ1DoLn59Tec7Id nDyIiiGMifDOfHTMx1QLa7k1jjgopiC/3H1HAk7eeQvc6wC+4W2yDGmgA JCgxVeSOhyRQlEAB/O5eC1o/QA5oVUURq2ccJtOGT5avkg1VtGgklgCGO MEM0msTzm/valSZAHkiDAf/4c2lLCwhfn/JDyAaVxiBt2NZTEKN/lhk9J joQYAn1ra15R3H1wxVlkgZI6rpC8oEqaI6ecZz2+AhO5H7rK7cKDCcgs4 A==; X-CSE-ConnectionGUID: rPrs+JpkQN2y8B6D4xPy+g== X-CSE-MsgGUID: uAPtGDIqR26UTTho5X+BqA== X-IronPort-AV: E=McAfee;i="6700,10204,11158"; a="20923944" X-IronPort-AV: E=Sophos;i="6.09,275,1716274800"; d="scan'208";a="20923944" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2024 02:21:59 -0700 X-CSE-ConnectionGUID: 0UpWrS3CS6SwUJ7EPufzRg== X-CSE-MsgGUID: MpOhvsmGRzu7CfiIXTg6MA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,275,1716274800"; d="scan'208";a="57594464" Received: from apaszkie-mobl2.apaszkie-mobl2 (HELO [10.245.245.147]) ([10.245.245.147]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2024 02:21:58 -0700 Message-ID: <2bd3e553-6319-4f9a-844f-d08528e4c331@intel.com> Date: Fri, 9 Aug 2024 10:21:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] drm/xe: Init MCR before any mcr register read To: "Upadhyay, Tejas" , "Roper, Matthew D" Cc: "intel-xe@lists.freedesktop.org" , "De Marchi, Lucas" References: <20240808092826.585276-1-tejas.upadhyay@intel.com> <20240808092826.585276-2-tejas.upadhyay@intel.com> <20240808195114.GE5091@mdroper-desk1.amr.corp.intel.com> <4a41b168-10de-432f-8535-a719d321823a@intel.com> Content-Language: en-GB From: Matthew Auld In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 09/08/2024 10:11, Upadhyay, Tejas wrote: > > >> -----Original Message----- >> From: Auld, Matthew >> Sent: Friday, August 9, 2024 2:25 PM >> To: Roper, Matthew D ; Upadhyay, Tejas >> >> Cc: intel-xe@lists.freedesktop.org; De Marchi, Lucas >> >> Subject: Re: [PATCH 1/2] drm/xe: Init MCR before any mcr register read >> >> On 08/08/2024 20:51, Matt Roper wrote: >>> On Thu, Aug 08, 2024 at 02:58:25PM +0530, Tejas Upadhyay wrote: >>>> enable host l2 VRAM is example where MCR register is getting read >>>> before fully MCR init is done. Lets move >>> >>> "is example" makes it sound like this is just one of multiple places >>> where we're incorrectly using MCR registers before MCR handling is >>> initialized. If there are indeed other cases, then I'd expect to see >>> more patches in this series making other changes as well. >>> >>> Also, the title seems slightly misleading as well; it makes it sound >>> like we're changing where we do the MCR init (which would run into >>> other chicken-and-egg problems with topology and GuC init), but in >>> reality we're just moving the L2 thing for Wa_16023588340 a bit later >>> in the init process, so it might be best to focus the wording on that. >>> >>> From a quick skim of Wa_16023588340 it just says that we need to do >>> this as part of initialization (and GT reset) without really >>> specifying any specific ordering with respect to other initialization >>> tasks. If I remember this workaround correctly it's probably >>> something that we want to do before we start having a bunch of CPU >>> writes to the LMEMBAR. I think there are some CPU -> VRAM writes >>> during GuC initialization (e.g., the GuC ADS), but maybe not enough to >>> require doing this workaround earlier; we should probably test this >>> carefully and/or double check with the architects on whether they >>> think this would be a concern. I know the really heavy CPU -> LMEMBAR >>> traffic would probably come later once we initialize display and the >>> fbcon starts writing to the fbdev framebuffer, so the new placement is >>> still early enough to avoid those at least. >> >> Yeah, it seemed reasonable to enable the host l2 caching before we started >> touching vram from the host. I don't recall if it was this version of the WA or >> the one that did the timer reg write thing, but I do seem to remember the >> placement being sensitive even during module load (IIRC gt_init vs >> gt_init_early), where if done too late (gt_init) you would sometimes still get >> the issue with the register read timing out in the interrupt handler. But in >> xe_gt_init_hwconfig perhaps not an issue, since it is still quite early. > > Should we get this extensively tested on BMG by validation before going ahead? Maybe just repeated module load/unload a hundred times or so in a loop on BMG? > > Thanks, > Tejas >> >>> >>> >>> Matt >>> >>>> enable host l2 VRAM after MCR init. >>>> >>>> V1(Lucas): >>>> - Reorder patch and reorder flow of L2 VRAM enable >>>> >>>> Cc: Lucas De Marchi >>>> Signed-off-by: Tejas Upadhyay >>>> --- >>>> drivers/gpu/drm/xe/xe_gt.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c >>>> index 58895ed22f6e..238c7d1053f0 100644 >>>> --- a/drivers/gpu/drm/xe/xe_gt.c >>>> +++ b/drivers/gpu/drm/xe/xe_gt.c >>>> @@ -557,7 +557,6 @@ int xe_gt_init_hwconfig(struct xe_gt *gt) >>>> >>>> xe_gt_mcr_init_early(gt); >>>> xe_pat_init(gt); >>>> - xe_gt_enable_host_l2_vram(gt); >>>> >>>> err = xe_uc_init(>->uc); >>>> if (err) >>>> @@ -569,6 +568,7 @@ int xe_gt_init_hwconfig(struct xe_gt *gt) >>>> >>>> xe_gt_topology_init(gt); >>>> xe_gt_mcr_init(gt); >>>> + xe_gt_enable_host_l2_vram(gt); >>>> >>>> out_fw: >>>> xe_force_wake_put(gt_to_fw(gt), XE_FW_GT); >>>> -- >>>> 2.25.1 >>>> >>>