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 83FA9CCF9E1 for ; Wed, 22 Oct 2025 07:32:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3B4C310E6ED; Wed, 22 Oct 2025 07:32:53 +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="qLLw4CWF"; dkim-atps=neutral Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8F67210E6E9 for ; Wed, 22 Oct 2025 07:32:51 +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=fMyJ28GRYTKbhUohTZ3HXWmS5z5/iy6Sj8vXxmt1a5k=; b=qLLw4CWFeb1JGzdQ1HjJR6PUbX TEl+eBOiH7A2lGaAwFrMxbdnRnTIL71YD8LrcPAYju+B1UCSFP8R4K8nLRAvHLM1CGOE0fkYpmHkd 0lfFWmgqeQHK/D7kSFP+StilMpGobEREg671X4ankXGzT6EEqCFfpEsA3dlFm0y1uzcdGtTNk9u69 X4hNnr35Sbyi5DNvENSducDcPbQoLmBX/6oMlfz5q0NVByDLiSGxhbE9IZRkRQ6CMOGPJ19yuGmku gh8Uihg7DfgyuDoFIooF0rbm+0QtBSB9W/tHXRABK9n5lU5IEPI/QdFUz7t5yocUoMxoT9q9C7aAv vl4XdsNQ==; Received: from [90.242.12.242] (helo=localhost) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1vBTKz-00Ct1C-QE for ; Wed, 22 Oct 2025 09:32:49 +0200 From: Tvrtko Ursulin To: intel-xe@lists.freedesktop.org Subject: [CI 09/14] drm/xe: Flush GGTT writes after populating DPT Date: Wed, 22 Oct 2025 08:32:34 +0100 Message-ID: <20251022073241.71401-10-tvrtko.ursulin@igalia.com> X-Mailer: git-send-email 2.48.0 In-Reply-To: <20251022073241.71401-1-tvrtko.ursulin@igalia.com> References: <20251022073241.71401-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 b18d15cc3c53..eb21eeae9d17 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