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 55595CDB470 for ; Tue, 23 Jun 2026 09:02:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DD40E10EA23; Tue, 23 Jun 2026 09:02:27 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="Q27LO949"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id DE5B410EA21 for ; Tue, 23 Jun 2026 09:02:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782205346; x=1813741346; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=0OsWPFT24/1A3gVvRtsDb/q1IkfyAEiksm6+VwAVXtc=; b=Q27LO949vFcjWtIMvMgdG54ybbWCP5NlZQvr5DOTbpB5VPxZcZ2Pq8mj yYGP2fQdO0xVSE6xhR6vo95wm+bQPIqdT2dpBngMz6MoQ2KA2JD8to+nz RVdm19SmpkLA9TBy6WMO3HuPsyXdZu9n8H1gOi29k3kvlGzZ4NBPLB0I1 2nT31gaphJ31heboIy9jTtImr+tB1LYOKIsOICxoV/nbOUMw0G4XmOS4R HmHKG4GLDFwqPckOQ9qmPhEnrWAv1h8Dxa6NwP5THl7qOmAfpRlllu2Iv gD+N/xKEGloAfrSSuWLAzopBvqEsXEbuTjobrDlB5PEWPp90LZL5aCpwD A==; X-CSE-ConnectionGUID: n/QrAprwQMyWfazfQtxgTA== X-CSE-MsgGUID: z1Cwf6v2Sgugld4k1B0fMA== X-IronPort-AV: E=McAfee;i="6800,10657,11825"; a="86850156" X-IronPort-AV: E=Sophos;i="6.24,220,1774335600"; d="scan'208";a="86850156" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 02:02:26 -0700 X-CSE-ConnectionGUID: z3buD7AQQmuFZ5uAd9qbDw== X-CSE-MsgGUID: 8Onl5Nt8TIeZEQseCQGoTw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,220,1774335600"; d="scan'208";a="246547047" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO mwauld-desk.intel.com) ([10.245.244.52]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 02:02:23 -0700 From: Matthew Auld To: intel-xe@lists.freedesktop.org Cc: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Matthew Brost , Rodrigo Vivi , Nikolay Mikhaylov , Uma Shankar , Jani Nikula , stable@vger.kernel.org Subject: [PATCH v2] drm/xe/display: consider DPT when WA 22019338487 is active Date: Tue, 23 Jun 2026 10:01:56 +0100 Message-ID: <20260623090155.268763-2-matthew.auld@intel.com> X-Mailer: git-send-email 2.54.0 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" WA 22019338487 (22019338487_display) indicates that stolen memory should not be used for display allocations on affected platforms (like Lunar Lake). In particular we need to be mindful of not hammering stolen over the BAR from the host side, like with issuing many writes. While the fbdev allocation in xe_display_bo.c properly respected this workaround, the Display Page Table (DPT) allocation in xe_fb_pin.c continued to unconditionally attempt to allocate from stolen memory on all integrated GPUs. Check XE_DEVICE_WA(xe, 22019338487_display) before attempting to allocate the DPT from stolen memory. If the workaround applies, skip the stolen allocation attempt and let the driver naturally fall back to allocating from system memory. Without this we will end up hammering stolen when programming the DPT on the host side during the normal operation, which seems to be exactly what the WA wants us to avoid. There are a bunch of users all getting some kind of hard hang in the fb pin programming sequence on LNL, so wondering if this could help there. v2 (Jani): - Invert the WA check. No functional change. Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Signed-off-by: Matthew Auld Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+") Cc: "Thomas Hellström" Cc: Matthew Brost Cc: Rodrigo Vivi Cc: Nikolay Mikhaylov Cc: Uma Shankar Cc: Jani Nikula Cc: # v6.12+ --- drivers/gpu/drm/xe/display/xe_fb_pin.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c index f93c98bec5b5..8ebb52741ea6 100644 --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c @@ -20,6 +20,9 @@ #include "xe_pat.h" #include "xe_pm.h" #include "xe_vram_types.h" +#include "xe_wa.h" + +#include static void write_dpt_rotated(struct xe_bo *bo, struct iosys_map *map, u32 *dpt_ofs, u32 bo_ofs, @@ -172,6 +175,8 @@ static int __xe_pin_fb_vma_dpt(struct drm_gem_object *obj, XE_BO_FLAG_GGTT | XE_BO_FLAG_PAGETABLE, pin_params->alignment, false); + else if (XE_DEVICE_WA(xe, 22019338487_display)) + dpt = ERR_PTR(-ENODEV); else dpt = xe_bo_create_pin_map_at_novm(xe, tile0, dpt_size, ~0ull, -- 2.54.0