From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793208895; b=H4zm8aALZT8BH526ItbIBNMjQkM9DRIr4V9q7MrjXNWIsx4thzd+/S0i251ggr/05vP0 L8OLMdfTRM6sd2pSISe/cjkXwmm6xJuhAT0cVSPCUKTavQWqksA+ExMH8fKie3hx5WnXX XuvnM99jiw6ZMk163NO9v2kDhO6a4I4voo+nRrFFXVMDoTCL8ZJKOq70vHPEPz1w2nE7U 6ftQT9j4coChcRy8OYTSU9nwKzl7CnSCsgQztVe9FhnmBFkIJsZoIHzcgSbDlmx4sZ5rT gmXK1MTlAJM8Cfa66Umdc//j6XdrYBXNZlPHGk8Jemh9DWPJFHzpQwoL9/STzAp1MYg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793208895; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=Qonrm3Tv4e8aSJaNm4EhiPuGAa/emrsHo2doNCYjmNA=; b=U6fg45T9f4eo9MAVghFw8hOVn1qzAdW5vs2vW7XHD05NGbUgbMnou0sOAIt2guz/OGtx Bh99Sv1YgJyZHhWsJXPf3p+Kn4RU1PwqbUqz2Emj3DT/SvcFmPo5ka7ocTdNbZQVWFf65 gAiHj54Jkzfp4IETZvbI5yZDHoSM0tva0GhYn/k5iyNkIeM8ZM06/5io5nXvgHyCywzg6 7xISrbLY7gECLXs9p7ENwV7VWtBzHzuqRogylFlQMY/Ygl//BqoWsY9eXmbb9HTV6D+5e ezqJdjjTMxCQSHr+nho4ZqgVsFGdKpyVGCpP+h/WsO3Bqpe/VJ18zBper67wpoH57Ew== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="nTocvr/H"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D80A0606A322; Wed, 28 Oct 2026 17:34:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=nTocvr/H Received: by smtp.kernel.org (Postfix) with ESMTPSA id 321DB1F01825; Wed, 28 Oct 2026 17:34:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793208894; bh=Qonrm3Tv4e8aSJaNm4EhiPuGAa/emrsHo2doNCYjmNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nTocvr/HnAG+lWNJhGFrfsgxsVG/d8BSQwMdUybmV/Xj8C06hGfpSHv+w8353a3AS Z4dWKXoKSaeqCSTm/3q8u0GriqUzC26FqfXgXlJLYgjrD9WuwMxRlWBeu+Q7K3eKFv Nz+mEgeWmkdRftekztFhH/C2gnZjjtjxyq9idVts= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, =?UTF-8?q?Christian=20K=C3=B6nig?= , Alex Deucher , =?UTF-8?q?Francisco=20Beltr=C3=A1n=20Millal=C3=A9n?= , Sasha Levin Subject: [PATCH 5.10 278/516] drm/amdgpu: reset VI ASIC on MacBookPro14,3 Date: Wed, 28 Oct 2026 17:57:10 +0100 Message-ID: <20261028170010.076692577@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028170003.522232767@linuxfoundation.org> References: <20261028170003.522232767@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Francisco Beltrán Millalén [ Upstream commit a22e5e4f2ebbdbb962cc3233094d189c4dfaa051 ] On a MacBookPro14,3 with a Radeon Pro 555 (Polaris11), the framebuffer is at MC address 0 when amdgpu loads after a cold boot, as the firmware leaves it (MC_VM_FB_LOCATION = 0x007f0000), while the VBIOS ASIC_Init table places it at 0xF4_0000_0000 (0xf47ff400). amdgpu reads the location once, at init, so after a re-POST (S3 resume or GPU reset) the framebuffer has moved and the driver keeps programming the old one: the SMU is handed a table that was never written and the GPU does not come back, which leaves the internal panel black. Resetting the ASIC on load makes ASIC_Init run before the driver reads the location, so the driver uses the VBIOS placement from the start and every later re-POST puts the framebuffer back where it already is. Add the Radeon Pro 555 used in this machine to the existing VI reset quirk table. Tested on a MacBookPro14,3 on 6.18.49 with the quirk table backported (the kernel also carries unrelated local PCI and ACPI patches for this machine). The framebuffer is at 0x000000F400000000 after both cold and warm boot, and the GPU survived 9 S3 cycles (lid close and rtcwake, one of them with the lid closed for about 7.5 minutes and a USB-C disk attached), each followed by a few minutes of 3D load; no ring timeouts or VM faults were reported. The reset adds about 0.23 s to amdgpu init. Suggested-by: Christian König Suggested-by: Alex Deucher Link: https://lore.kernel.org/all/20260924132952.25054-1-fbeltranmillalen@gmail.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Francisco Beltrán Millalén Signed-off-by: Alex Deucher (cherry picked from commit b6b1d97218518003107d4446fac278fa3e0a19a0) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/vi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c index 39c51dc897879..1ceb23f2fd92d 100644 --- a/drivers/gpu/drm/amd/amdgpu/vi.c +++ b/drivers/gpu/drm/amd/amdgpu/vi.c @@ -1068,6 +1068,7 @@ struct vi_reset_quirk { static const struct vi_reset_quirk vi_reset_quirks[] = { { 0x67ef, PCI_VENDOR_ID_APPLE, 0x0190, 0xe3 }, /* Radeon Pro 555X */ { 0x67ef, PCI_VENDOR_ID_APPLE, 0x018f, 0xc2 }, /* Radeon Pro 560X */ + { 0x67ef, PCI_VENDOR_ID_APPLE, 0x017a, 0xc7 }, /* Radeon Pro 555 */ }; static bool vi_need_reset_on_init(struct amdgpu_device *adev) -- 2.53.0