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 545E9CA0EED for ; Tue, 19 Aug 2025 08:55:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E44BB10E55F; Tue, 19 Aug 2025 08:55:48 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=igalia.com header.i=@igalia.com header.b="lf4x0QGS"; dkim-atps=neutral Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2BC1610E55A for ; Tue, 19 Aug 2025 08:55:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PDx1QLIk8NiWv6shO2uvjeYuuExmUaTJAHnSb2B7RDc=; b=lf4x0QGSKKA3ySXGQ23PdzIhpG FoYmP5LFrAKIk2icJ06PmiVOgOoJySW450seKvAdJy/PzUGmdTrNb0ft/85O7HfKWYtqWhj+zZ8Td H1j7eQXkYEZ3/EtjdWSTG5ihJsbzAjCYwUWbD9ygyJbzAolN54YMm2tj9rxR3x1ZeWxkoQN8hRP95 O8ujIFjsWyCl/lwX0C/MX0cH6t4GLbmf3IfNCxs+xGxTrXW/iioadOxtTLZMJKz88gwidwWZTPrk8 uNt14bqmePNtKUOchLkaasfJh0b+CEaYiCjy6GZh18PcX2fSl/CA31SyMKrubAeuIA4c1g7eyZwPz ivRY0GZw==; Received: from [84.66.36.92] (helo=localhost) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1uoI88-00GD7a-Eo for ; Tue, 19 Aug 2025 10:55:44 +0200 From: Tvrtko Ursulin To: intel-xe@lists.freedesktop.org Subject: [CI 08/13] drm/xe: Flush GGTT writes after populating DPT Date: Tue, 19 Aug 2025 09:55:29 +0100 Message-ID: <20250819085537.97902-9-tvrtko.ursulin@igalia.com> X-Mailer: git-send-email 2.48.0 In-Reply-To: <20250819085537.97902-1-tvrtko.ursulin@igalia.com> References: <20250819085537.97902-1-tvrtko.ursulin@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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" When DPT is placed in stolen it is populated using ioremap_wc() via GGTT. I915 has established that on modern platforms a small flush and delay is required for those writes to reliably land so lets add the same logic (simplified by removing impossible platforms) to xe as well. v2: * Do it only for system memory buffers. Signed-off-by: Tvrtko Ursulin Cc: Ville Syrjälä --- drivers/gpu/drm/xe/display/xe_fb_pin.c | 45 ++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c index f1f8b5ab53ef..460e330676b3 100644 --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c @@ -12,9 +12,11 @@ #include "intel_fb.h" #include "intel_fb_pin.h" #include "intel_fbdev.h" +#include "regs/xe_engine_regs.h" #include "xe_bo.h" #include "xe_device.h" #include "xe_ggtt.h" +#include "xe_mmio.h" #include "xe_pm.h" #include "xe_vram_types.h" @@ -79,6 +81,46 @@ write_dpt_remapped(struct xe_bo *bo, struct iosys_map *map, u32 *dpt_ofs, *dpt_ofs = ALIGN(*dpt_ofs, 4096); } +static void gt_flush_ggtt_writes(struct xe_gt *gt) +{ + if (!gt) + return; + + xe_mmio_read32(>->mmio, RING_TAIL(RENDER_RING_BASE)); +} + +static void ggtt_flush_writes(struct xe_ggtt *ggtt) +{ + struct xe_device *xe = tile_to_xe(ggtt->tile); + + /* + * No actual flushing is required for the GTT write domain for reads + * from the GTT domain. Writes to it "immediately" go to main memory + * as far as we know, so there's no chipset flush. It also doesn't + * land in the GPU render cache. + * + * However, we do have to enforce the order so that all writes through + * the GTT land before any writes to the device, such as updates to + * the GATT itself. + * + * We also have to wait a bit for the writes to land from the GTT. + * An uncached read (i.e. mmio) seems to be ideal for the round-trip + * timing. This issue has only been observed when switching quickly + * between GTT writes and CPU reads from inside the kernel on recent hw, + * and it appears to only affect discrete GTT blocks (i.e. on LLC + * system agents we cannot reproduce this behaviour, until Cannonlake + * that was!). + */ + + wmb(); + + if (xe_pm_runtime_get_if_active(xe)) { + gt_flush_ggtt_writes(ggtt->tile->primary_gt); + gt_flush_ggtt_writes(ggtt->tile->media_gt); + xe_pm_runtime_put(xe); + } +} + static int __xe_pin_fb_vma_dpt(const struct intel_framebuffer *fb, const struct i915_gtt_view *view, struct i915_vma *vma, @@ -162,6 +204,9 @@ static int __xe_pin_fb_vma_dpt(const struct intel_framebuffer *fb, rot_info->plane[i].dst_stride); } + if (dpt->vmap.is_iomem && !xe_bo_is_vram(dpt)) + ggtt_flush_writes(tile0->mem.ggtt); + vma->dpt = dpt; vma->node = dpt->ggtt_node[tile0->id]; -- 2.48.0