drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0
Subsystems (3)
PATCH 1/1 drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. The EFI stub enables the iGPU on these machines through apple_set_os(). On a MacBookPro11,5 (Radeon R9 M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout at init:
MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0 VRAM at 0x0-0x7fffffff, GART table at 0x1400000
The driver posts the ASIC again on S3 resume and after a GPU reset. The VBIOS asic_init table then moves VRAM back to the VBIOS default:
MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000
gmc_v6_0 does not reprogram these registers. The GART table is then no longer in VRAM, and the gfx ring test times out:
amdgpu: ring gfx test failed (-110)
amdgpu: resume of IP block <gfx_v6_0> failed -110
Reset and post the ASIC at driver load on Apple boards with VRAM at 0. The driver then uses the VBIOS layout (VRAM at 0xf400000000) from the start, and later posts keep it. After the reset, FB_BASE is not 0, so a module reload does not reset the ASIC again.
The test is the same one that commit c7f44ec5c4ec ("drm/amdgpu: make Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at
0. The VI quirks for the MacBookPro14,3 and MacBookPro15,1 reset at load for the same reason:
commit a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3") commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1")
Other Apple SI boards only change if their firmware also leaves VRAM at
0. They then get the same reset at load.
Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3 resume fails every time. The GPU reset path is not tested.
--- drivers/gpu/drm/amd/amdgpu/si.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/gpu/drm/amd/amdgpu/si.c +9 -0
@@ -1512,6 +1512,15 @@ static void si_invalidate_hdp(struct amdgpu_device *adev,static bool si_need_reset_on_init (struct amdgpu_device *adev) { +/* +* MacBookPros with switchable graphics put VRAM at 0. Any later post +* (S3 resume, GPU reset) moves it back to the vbios default, so reset +* and post on load to start with the vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +return false; }
Signature · 1 line
2.55.0
Deucher, Alexander
maintainerPublic
Quoted 40 lines
-----Original Message-----
From: Maciej Kucharek <[email protected]>
Sent: Wednesday, October 14, 2026 3:21 PM
To: [email protected]; Deucher, Alexander <[email protected]>
Cc: Koenig, Christian <[email protected]>; Maciej Kucharek <[email protected]>
Subject: [PATCH] drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. The EFI stub enables the iGPU on these machines through
apple_set_os(). On a MacBookPro11,5 (Radeon R9 M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout at init:MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0 VRAM at 0x0-0x7fffffff, GART table at
0x1400000The driver posts the ASIC again on S3 resume and after a GPU reset. The VBIOS
asic_inittable then moves VRAM back to the VBIOS default:MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000
gmc_v6_0does not reprogram these registers. The GART table is then no longer in VRAM, and the gfx ring test times out:amdgpu: ring gfx test failed (-110)
amdgpu: resume of IP block <gfx_v6_0> failed -110Reset and post the ASIC at driver load on Apple boards with VRAM at 0. The driver then uses the VBIOS layout (VRAM at
0xf400000000) from the start, and later posts keep it. After the reset,FB_BASEis not 0, so a module reload does not reset the ASIC again.The test is the same one that commit
c7f44ec5c4ec("drm/amdgpu: make Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at 0. The VI quirks for the MacBookPro14,3 and MacBookPro15,1 reset at load for the same reason:
Quoted 5 lines
commit
a22e5e4f2ebb("drm/amdgpu: reset VI ASIC on MacBookPro14,3") commita5be7ad8f5f0("drm/amdgpu: reset VI ASIC on MacBookPro15,1")Other Apple SI boards only change if their firmware also leaves VRAM at 0. They then get the same reset at load.
Can you also update the VI code to follow the same logic? Or better yet, add the same logic to si.c, cik.c, and vi.c. Presumably CI based chips have the same issue.
Alex
Quoted 37 lines
Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3 resume fails every time. The GPU reset path is not tested.
Assisted-by Claude:claude-opus-5-5Signed-off-by Maciej Kucharek <[email protected]>--- drivers/gpu/drm/amd/amdgpu/si.c | 9 +++++++++ 1 file changed, 9 insertions(+)(quoted diff) +0
-0
b/drivers/gpu/drm/amd/amdgpu/si.cindex0adfd4b10..892e80f09100644drivers/gpu/drm/amd/amdgpu/si.c +2
-0@@ -1512,6 +1512,15 @@ static void si_invalidate_hdp(struct amdgpu_device *adev, static bool si_need_reset_on_init(struct amdgpu_device *adev) { +/* +* MacBookPros with switchable graphics put VRAM at 0. Any later post
drivers/gpu/drm/amd/amdgpu/si.c +5
-0+* (S3 resume, GPU reset) moves it back to the vbios default, so reset +* and post on load to start with the vbios layout. +*/ + if (adev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE && + !(RREG32(mmMC_VM_FB_LOCATION) &
MC_VM_FB_LOCATION__FB_BASE_MASK))drivers/gpu/drm/amd/amdgpu/si.c +2
-1+return true; +return false; } --2.55.0
v2 cover drm/amdgpu: reset SI/CIK/VI ASIC on Apple boards with VRAM at 0
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default, and the driver keeps using the old layout. This series resets and posts the ASIC at driver load on Apple boards with VRAM at 0. As Alex asked in the review of v1, it adds the same test to si.c, cik.c and vi.c.
Testing:
- Patch 1 (SI) is tested on a MacBookPro11,5: 4 of 4 S3 cycles resume.
- Patches 2 (CIK) and 3 (VI) are only compile-tested.
- No MacBookPro has a CIK GPU, so patch 2 is for consistency only.
- Patch 3 also resets other Polaris MacBookPros with VRAM at 0, for example the MacBookPro13,3. This is not tested.
- The series does not change Vega or Navi.
Patch 3 keeps vi_reset_quirks[]. Its MacBookPro15,1 entries fix a module reload after S3, when VRAM is no longer at 0. The new test may not cover that case. The new test also catches the MacBookPro14,3, so its entry is now redundant. I can remove it in a follow-up if you prefer.
Changes in v2:
- Add the same test to cik.c and vi.c (Alex).
- SI commit message: cite only the MacBookPro14,3 quirk as the same cause. The MacBookPro15,1 quirk fixes a different failure.
- Code comment: add the iGPU condition.
v1: https://lore.kernel.org/amd-gfx/[email protected]/
Maciej Kucharek (3):
drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0 drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0 drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
drivers/gpu/drm/amd/amdgpu/cik.c | 10 ++++++++++ drivers/gpu/drm/amd/amdgpu/si.c | 10 ++++++++++ drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++ 3 files changed, 30 insertions(+)
Signature · 1 line
2.55.0
PATCH v2 1/3 drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. The EFI stub enables the iGPU on these machines through apple_set_os(). On a MacBookPro11,5 (Radeon R9 M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout at init:
MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0 VRAM at 0x0-0x7fffffff, GART table at 0x1400000
The driver posts the ASIC again on S3 resume and after a GPU reset. The VBIOS asic_init table then moves VRAM back to the VBIOS default:
MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000
gmc_v6_0 does not reprogram these registers. The GART table is then no longer in VRAM, and the gfx ring test times out:
amdgpu: ring gfx test failed (-110)
amdgpu: resume of IP block <gfx_v6_0> failed -110
Reset and post the ASIC at driver load on Apple boards with VRAM at 0. The driver then uses the VBIOS layout (VRAM at 0xf400000000) from the start, and later posts keep it. After the reset, FB_BASE is not 0, so a module reload does not reset the ASIC again.
The test is the same one that commit c7f44ec5c4ec ("drm/amdgpu: make Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at
0. The VI quirk for the MacBookPro14,3 resets at load for the same reason:
commit a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Other Apple SI boards get the same reset if FB_BASE reads 0 at load.
Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3 resume fails every time. The GPU reset path is not tested.
--- drivers/gpu/drm/amd/amdgpu/si.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdgpu/si.c +10 -0
@@ -1512,6 +1512,16 @@ static void si_invalidate_hdp(struct amdgpu_device *adev,static bool si_need_reset_on_init (struct amdgpu_device *adev) { +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +return false; }
Signature · 1 line
2.55.0
Hi Maciej,
I tested this patch on a second MacBookPro11,5 (Radeon R9 M370X, Verde, 1002:6821, subsystem 106b:0149). Here the dGPU is a headless PRIME offload GPU and the panel is on i915. The kernel is linux 7.3-rc7, with amdgpu rebuilt from that tree with this patch on top and nothing else changed in amdgpu (amdgpu.si_support=1 radeon.si_support=0, mem_sleep=deep).
Without the patch, VRAM is at 0 after boot and every S3 resume fails with "ring gfx test failed (-110)".
With it, amdgpu logs "PCI CONFIG reset" and "GPU posting now..." at load, and VRAM ends up at 0x000000F400000000. I then ran four S3 cycles:
two on battery and two on AC, from 9 minutes to 13 h 19 min asleep. After each resume the GART table was still at 0x000000F400000000 and the kernel log showed no ring timeouts, -110 errors or GPU recovery. After the last (overnight) resume, DRI_PRIME=1 glxgears (radeonsi) and vkcube (RADV) ran, and VA-API H.264 encode (VCE) and decode (UVD) both worked through ffmpeg.
One thing I noticed: on 2 of the 4 resumes, about a second after resume, vce_v1_0_stop() logged:
amdgpu 0000:01:00.0: VCE busy: VCE_STATUS=0x2, SRBM_STATUS2=0x80
VCE encode worked straight afterwards, so it doesn't seem to break anything. I didn't see it in about 11 resumes with a local workaround that kept VRAM at 0, so it may come with the new layout, but I haven't looked further. Mentioning it in case it's known.
This supersedes the gmc6 patch I sent on 20 Oct for the same failure:
https://lore.kernel.org/amd-gfx/[email protected]/
Thanks,
Brad
Quoted 7 lines · On 2026. október 22., csütörtök 9:36:38 közép-európai téli idő Brad Drury wrote:
One thing I noticed: on 2 of the 4 resumes, about a second after resume,
vce_v1_0_stop()logged:amdgpu 0000:01:00.0: VCE busy: VCE_STATUS=0x2, SRBM_STATUS2=0x80
VCE encode worked straight afterwards, so it doesn't seem to break anything.
The following patch should fix that:
"drm/amdgpu/vce1: Fix checking whether VCE1 is idle"
https://lists.freedesktop.org/archives/amd-gfx/2026-October/154367.html
Best regards,
Timur
Quoted 3 lines · Timur Kristóf
The following patch should fix that:
"drm/amdgpu/vce1: Fix checking whether VCE1 is idle"
https://lists.freedesktop.org/archives/amd-gfx/2026-October/154367.html
Thanks, Timur. That matches what I see here.
On my MacBookPro11,5 (R9 M370X, 1002:6821), 7.2.15 with the SI patch and VCE enabled (no amdgpu.ip_block_mask), all 8 of 8 S3 resumes worked, with no ring test failures, -110 errors or GPU resets. "VCE busy" was logged on every VCE stop: 24 messages, mostly VCE_STATUS=0x100, SRBM_STATUS2=0x0, and 3 of VCE_STATUS=0x102, SRBM_STATUS2=0x80 right after resume. The stock module, without the reset at load, logged the same 0x100 message at load on this machine, so it doesn't come from the new VRAM layout.
With your patch on top, the same test gave 3 messages instead of 24. I sent the details and a Tested-by in your thread:
https://lore.kernel.org/amd-gfx/[email protected]/
Maciej
PATCH v2 2/3 drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0
In reply to Maciej KucharekOn MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. The SI fix resets and posts the ASIC at load, so the driver uses the VBIOS layout from the start:
"drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0"
No MacBookPro has a CIK GPU, and no affected CIK board is known. Add the same test to cik_need_reset_on_init(), so that SI, CIK and VI handle this firmware layout in the same way. gmc_v7_0 reads MC_VM_FB_LOCATION once at init and does not reprogram it. A CIK board with VRAM at 0 therefore has the same problem as the SI boards.
After the reset, FB_BASE is not 0, so the new test does not fire again on a module reload.
Only compile-tested.
--- drivers/gpu/drm/amd/amdgpu/cik.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdgpu/cik.c +10 -0
@@ -1927,6 +1927,16 @@ static bool cik_need_reset_on_init(struct amdgpu_device *adev) {u32 clock_cntl, pc; +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +if (adev->flags &AMD_IS_APU )return false;
Signature · 1 line
2.55.0
PATCH v2 3/3 drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
In reply to Maciej KucharekOn MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. gmc_v8_0 reads MC_VM_FB_LOCATION once at init and reprograms it only on SR-IOV. On bare metal, the driver then keeps using the old layout.
vi_reset_quirks[] handles this for the MacBookPro14,3 by PCI ID:
commit a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Add the test that SI and CIK use: an Apple subsystem vendor and VRAM at
0. Other Polaris MacBookPros then get the same reset at load, for example the MacBookPro13,3 if its firmware leaves VRAM at 0. These boards are not tested.
Keep vi_reset_quirks[]. Its MacBookPro15,1 entries fix a different failure, a module reload after S3:
commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1")
VRAM is not at 0 at that point, so the new test may not cover it.
After the reset, FB_BASE is not 0, so the new test does not fire again on a module reload.
Only compile-tested.
--- drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdgpu/vi.c +10 -0
@@ -1405,6 +1405,16 @@ static bool vi_need_reset_on_init(struct amdgpu_device *adev)unsigned int i;u32 clock_cntl, pc; +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +for (i =0 ; i <ARRAY_SIZE (vi_reset_quirks); i++) if (adev->pdev->device == vi_reset_quirks[i].device && adev->pdev->subsystem_vendor == vi_reset_quirks[i].subsystem_vendor &&
Signature · 1 line
2.55.0
Re: [PATCH v2 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
Quoted 47 lines · Maciej Kucharek
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default.
gmc_v8_0readsMC_VM_FB_LOCATIONonce at init and reprograms it only on SR-IOV. On bare metal, the driver then keeps using the old layout.vi_reset_quirks[] handles this for the MacBookPro14,3 by PCI ID:
commit
a22e5e4f2ebb("drm/amdgpu: reset VI ASIC on MacBookPro14,3")Add the test that SI and CIK use: an Apple subsystem vendor and VRAM at
0. Other Polaris MacBookPros then get the same reset at load, for example the MacBookPro13,3 if its firmware leaves VRAM at 0. These boards are not tested.Keep vi_reset_quirks[]. Its MacBookPro15,1 entries fix a different failure, a module reload after S3:
commit
a5be7ad8f5f0("drm/amdgpu: reset VI ASIC on MacBookPro15,1")VRAM is not at 0 at that point, so the new test may not cover it.
After the reset,
FB_BASEis not 0, so the new test does not fire again on a module reload.Only compile-tested.
Suggested-by Alex Deucher <[email protected]>Assisted-by Claude:claude-opus-5-5Signed-off-by Maciej Kucharek <[email protected]>--- drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++ 1 file changed, 10 insertions(+)drivers/gpu/drm/amd/amdgpu/vi.c +3
-0@@ -1405,6 +1405,16 @@ static bool vi_need_reset_on_init(struct amdgpu_device *adev)unsigned int i;u32 clock_cntl, pc; +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to
drivers/gpu/drm/amd/amdgpu/vi.c static bool vi_need_reset_on_init(struct amdgpu_device *adev) · line 1420
Quoted 10 lines
drivers/gpu/drm/amd/amdgpu/vi.c +7
-0+* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +for (i =0 ; i <ARRAY_SIZE (vi_reset_quirks); i++) if (adev->pdev->device == vi_reset_quirks[i].device && adev->pdev->subsystem_vendor == vi_reset_quirks[i].subsystem_vendor &&
Please drop the now duplicate quirk handling here.
Thanks,
Alex
Quoted 3 lines
--
2.55.0
v3 cover drm/amdgpu: reset SI/CIK/VI ASIC on Apple boards with VRAM at 0
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default, and the driver keeps using the old layout. This series resets and posts the ASIC at driver load on Apple boards with VRAM at 0. It adds the same test to si.c, cik.c and vi.c.
Testing:
- Patch 1 (SI) is tested on a MacBookPro11,5: 4 of 4 S3 cycles resume.
- Patches 2 (CIK) and 3 (VI) are only compile-tested.
- No MacBookPro has a CIK GPU, so patch 2 is for consistency only.
- Patch 3 also resets other Polaris MacBookPros with VRAM at 0, for example the MacBookPro13,3. This is not tested.
- The series does not change Vega or Navi.
Patch 3 removes vi_reset_quirks[]. Andre, Frederick and Francisco, you added its entries for the MacBookPro15,1 and 14,3. If you can, please test patch 3 on those machines:
- MacBookPro14,3: S3 resume works.
- MacBookPro15,1: S3 resume works, and a module reload after S3 works.
Changes in v3:
- VI: remove vi_reset_quirks[], because the new test replaces it (Alex).
Changes in v2:
- Add the same test to cik.c and vi.c (Alex).
- SI commit message: cite only the MacBookPro14,3 quirk as the same cause. The MacBookPro15,1 quirk fixes a different failure.
- Code comment: add the iGPU condition.
v2: https://lore.kernel.org/amd-gfx/[email protected]/
v1: https://lore.kernel.org/amd-gfx/[email protected]/
Maciej Kucharek (3):
drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0 drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0 drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
drivers/gpu/drm/amd/amdgpu/cik.c | 10 ++++++++++ drivers/gpu/drm/amd/amdgpu/si.c | 10 ++++++++++ drivers/gpu/drm/amd/amdgpu/vi.c | 29 +++++++++-------------------- 3 files changed, 29 insertions(+), 20 deletions(-)
Signature · 1 line
2.55.0
PATCH v3 1/3 drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. The EFI stub enables the iGPU on these machines through apple_set_os(). On a MacBookPro11,5 (Radeon R9 M370X, 1002:6821, subsystem 106b:0149), the driver adopts this layout at init:
MC_VM_FB_LOCATION=0x007f0000, HDP_NONSURFACE_BASE=0 VRAM at 0x0-0x7fffffff, GART table at 0x1400000
The driver posts the ASIC again on S3 resume and after a GPU reset. The VBIOS asic_init table then moves VRAM back to the VBIOS default:
MC_VM_FB_LOCATION=0xf47ff400, HDP_NONSURFACE_BASE=0xf4000000
gmc_v6_0 does not reprogram these registers. The GART table is then no longer in VRAM, and the gfx ring test times out:
amdgpu: ring gfx test failed (-110)
amdgpu: resume of IP block <gfx_v6_0> failed -110
Reset and post the ASIC at driver load on Apple boards with VRAM at 0. The driver then uses the VBIOS layout (VRAM at 0xf400000000) from the start, and later posts keep it. After the reset, FB_BASE is not 0, so a module reload does not reset the ASIC again.
The test is the same one that commit c7f44ec5c4ec ("drm/amdgpu: make Mac FB workaround generic") uses: an Apple subsystem vendor and VRAM at
0. The VI quirk for the MacBookPro14,3 resets at load for the same reason:
commit a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Other Apple SI boards get the same reset if FB_BASE reads 0 at load.
Tested on a MacBookPro11,5 with 7.2.5 and this patch: the panel comes up at boot, and 4 of 4 deep S3 cycles resume. Without the patch, S3 resume fails every time. The GPU reset path is not tested.
--- drivers/gpu/drm/amd/amdgpu/si.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdgpu/si.c +10 -0
@@ -1512,6 +1512,16 @@ static void si_invalidate_hdp(struct amdgpu_device *adev,static bool si_need_reset_on_init (struct amdgpu_device *adev) { +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +return false; }
Signature · 1 line
2.55.0
PATCH v3 2/3 drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0
In reply to Maciej KucharekOn MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. The SI fix resets and posts the ASIC at load, so the driver uses the VBIOS layout from the start:
"drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0"
No MacBookPro has a CIK GPU, and no affected CIK board is known. Add the same test to cik_need_reset_on_init(), so that SI, CIK and VI handle this firmware layout in the same way. gmc_v7_0 reads MC_VM_FB_LOCATION once at init and does not reprogram it. A CIK board with VRAM at 0 therefore has the same problem as the SI boards.
After the reset, FB_BASE is not 0, so the new test does not fire again on a module reload.
Only compile-tested.
--- drivers/gpu/drm/amd/amdgpu/cik.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdgpu/cik.c +10 -0
@@ -1927,6 +1927,16 @@ static bool cik_need_reset_on_init(struct amdgpu_device *adev) {u32 clock_cntl, pc; +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +if (adev->flags &AMD_IS_APU )return false;
Signature · 1 line
2.55.0
Re: [PATCH v3 2/3] drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0
Quoted 11 lines · On 2026. október 15., csütörtök 20:18:36 közép-európai téli idő Maciej…
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. The SI fix resets and posts the ASIC at load, so the driver uses the VBIOS layout from the start:
"drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0"
No MacBookPro has a CIK GPU, and no affected CIK board is known. Add the same test to
cik_need_reset_on_init(), so that SI, CIK and VI handle this firmware layout in the same way.
Just a side note: some old iMacs have a Bonaire GPU, which is CI. Not sure if those boards are affected or not, but it definitely won't hurt.
Quoted 22 lines
gmc_v7_0readsMC_VM_FB_LOCATIONonce at init and does not reprogram it. A CIK board with VRAM at 0 therefore has the same problem as the SI boards.After the reset,
FB_BASEis not 0, so the new test does not fire again on a module reload.Only compile-tested.
Suggested-by Alex Deucher <[email protected]>Assisted-by Claude:claude-opus-5-5Signed-off-by Maciej Kucharek <[email protected]>--- drivers/gpu/drm/amd/amdgpu/cik.c | 10 ++++++++++ 1 file changed, 10 insertions(+)(quoted diff) +0
-0
b/drivers/gpu/drm/amd/amdgpu/cik.cindexd29991a4a..e1029239b100644
drivers/gpu/drm/amd/amdgpu/cik.c static bool cik_need_reset_on_init(struct · line 1932
Quoted 6 lines
drivers/gpu/drm/amd/amdgpu/cik.c +3
-0@@ -1927,6 +1927,16 @@ static bool cik_need_reset_on_init(struct amdgpu_device *adev) {u32 clock_cntl, pc; +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back
to
drivers/gpu/drm/amd/amdgpu/cik.c static bool cik_need_reset_on_init(struct amdgpu_device *adev)
Quoted 5 lines
drivers/gpu/drm/amd/amdgpu/cik.c +5
-0+* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ + if (adev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE && + !(RREG32(mmMC_VM_FB_LOCATION) &
MC_VM_FB_LOCATION__FB_BASE_MASK))
Quoted 4 lines
drivers/gpu/drm/amd/amdgpu/cik.c +2
-0+return true; +if (adev->flags &AMD_IS_APU )return false;
PATCH v3 3/3 drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
In reply to Maciej KucharekOn MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default. gmc_v8_0 reads MC_VM_FB_LOCATION once at init and reprograms it only on SR-IOV. On bare metal, the driver then keeps using the old layout.
vi_reset_quirks[] resets these boards at load by PCI ID:
commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1") commit a22e5e4f2ebb ("drm/amdgpu: reset VI ASIC on MacBookPro14,3")
Replace the table with the test that SI and CIK use: an Apple subsystem vendor and VRAM at 0. Other Polaris MacBookPros then also get the reset at load, for example the MacBookPro13,3 if its firmware leaves VRAM at 0.
On the MacBookPro14,3, MC_VM_FB_LOCATION is 0x007f0000 at load, so the new test covers it. The MacBookPro15,1 entries fix a module reload after S3. With the reset at first load, later posts keep VRAM where the driver expects it. The reload failure on these boards is then expected to go away, but this is not tested.
After the reset, FB_BASE is not 0, so the new test does not fire again on a module reload.
Only compile-tested.
--- drivers/gpu/drm/amd/amdgpu/vi.c | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-)
drivers/gpu/drm/amd/amdgpu/vi.c +9 -20
@@ -1387,30 +1387,19 @@ static uint64_t vi_get_pcie_replay_count(struct amdgpu_device *adev)return (nak_r + nak_g); } -struct vi_reset_quirk { -u16 device; -u16 subsystem_vendor; -u16 subsystem_device; -u8 revision; -}; - -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) { -unsigned int i;u32 clock_cntl, pc; -for (i =0 ; i <ARRAY_SIZE (vi_reset_quirks); i++) -if (adev->pdev->device == vi_reset_quirks[i].device && - adev->pdev->subsystem_vendor == vi_reset_quirks[i].subsystem_vendor && - adev->pdev->subsystem_device == vi_reset_quirks[i].subsystem_device && - adev->pdev->revision == vi_reset_quirks[i].revision) -return true; +/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true;if (adev->flags &AMD_IS_APU )return false;
Signature · 1 line
2.55.0
Re: [PATCH v3 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
Hi Maciej,
Thanks for the patch.
I applied patch 3 to the 6.18.49 kernel I use on my MacBookPro14,3 (Radeon Pro 555, 1002:67ef, subsystem 106b:017a, rev c7). The kernel also carries my unrelated PCI and ACPI patches for this machine.
After a cold boot, amdgpu logs "PCI CONFIG reset" and "GPU posting now..." while it loads, and VRAM ends up at 0xF400000000. MC_VM_FB_LOCATION reads 0xf47ff400 through debugfs. In my tests in September, a kernel without the reset left VRAM at 0 after a cold boot.
I then suspended to RAM three times with rtcwake. After each resume MC_VM_FB_LOCATION was still 0xf47ff400, the screen came back, and the kernel log showed no VM faults, ring timeouts or GPU recovery. After the last one I ran glxgears for a minute and the gfx ring kept going.
I also closed the lid for about ten minutes. After opening it the screen came back, MC_VM_FB_LOCATION was 0xf47ff400, and glxgears ran for a minute without errors.
Before that I had also tried it after a warm reboot, with four rtcwake cycles and one 45-minute suspend from the idle timer. After each of those MC_VM_FB_LOCATION was 0xf47ff400 and the log showed no GPU errors.
Finally, I reloaded amdgpu after a suspend, twice, with modprobe -r and modprobe. Each time amdgpu logged "PCI CONFIG reset" and "GPU posting now..." during the reload, VRAM was at 0xF400000000 and MC_VM_FB_LOCATION read 0xf47ff400. VRAM is no longer at 0 by then, so I think the reset came from the existing SMC check: with amdgpu unloaded, SMC_SYSCON_CLOCK_CNTL_0 read 0x01000000 and SMC_PC_C was about 0x205xx and changing (read through the MMIO BAR). After the second reload I logged in again and ran glxgears for a minute without errors.
Thanks again,
Francisco
Alex Deucher
Reviewed-byRe: [PATCH v2 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
In reply to Alex DeucherQuoted 46 lines · Alex Deucher
Quoted 44 lines · Maciej Kucharek
On MacBookPros with switchable graphics, the firmware puts VRAM at MC address 0 when the iGPU is enabled. A later post (S3 resume, GPU reset) moves VRAM back to the VBIOS default.
gmc_v8_0readsMC_VM_FB_LOCATIONonce at init and reprograms it only on SR-IOV. On bare metal, the driver then keeps using the old layout.vi_reset_quirks[] handles this for the MacBookPro14,3 by PCI ID:
commit
a22e5e4f2ebb("drm/amdgpu: reset VI ASIC on MacBookPro14,3")Add the test that SI and CIK use: an Apple subsystem vendor and VRAM at
0. Other Polaris MacBookPros then get the same reset at load, for example the MacBookPro13,3 if its firmware leaves VRAM at 0. These boards are not tested.Keep vi_reset_quirks[]. Its MacBookPro15,1 entries fix a different failure, a module reload after S3:
commit
a5be7ad8f5f0("drm/amdgpu: reset VI ASIC on MacBookPro15,1")VRAM is not at 0 at that point, so the new test may not cover it.
After the reset,
FB_BASEis not 0, so the new test does not fire again on a module reload.Only compile-tested.
Suggested-by Alex Deucher <[email protected]>Assisted-by Claude:claude-opus-5-5Signed-off-by Maciej Kucharek <[email protected]>--- drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++ 1 file changed, 10 insertions(+)drivers/gpu/drm/amd/amdgpu/vi.c +0
-0@@ -1405,6 +1405,16 @@ static bool vi_need_reset_on_init(struct amdgpu_device *adev)unsigned int i;u32 clock_cntl, pc;
Quoted 15 lines
drivers/gpu/drm/amd/amdgpu/vi.c static bool vi_need_reset_on_init(struct amdgpu_device *adev) · line 1420
Quoted 13 lines
drivers/gpu/drm/amd/amdgpu/vi.c +10
-0+/* +* MacBookPros with switchable graphics put VRAM at 0 when the iGPU +* is enabled. Any later post (S3 resume, GPU reset) moves it back to +* the vbios default, so reset and post on load to start with the +* vbios layout. +*/ +if (adev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE && + !(RREG32 (mmMC_VM_FB_LOCATION) &MC_VM_FB_LOCATION__FB_BASE_MASK )) +return true; +for (i =0 ; i <ARRAY_SIZE (vi_reset_quirks); i++) if (adev->pdev->device == vi_reset_quirks[i].device && adev->pdev->subsystem_vendor == vi_reset_quirks[i].subsystem_vendor &&Please drop the now duplicate quirk handling here.
After re-reading your commit message and thinking about it more, I've decided to take v1. Series is:
and applied.
Thanks!
Alex
Quoted 8 lines
Thanks,
Alex
Quoted 3 lines
--
2.55.0
Re: [PATCH v2 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0
In reply to Maciej KucharekHi Maciej,
I tested this patch on a MacBookPro14,3 with the Radeon Pro 560 (1002:67ef, subsystem 106b:0179, rev c0), which is not in vi_reset_quirks[]. The kernel is 7.2.5 with commits a5be7ad8f5f0 and a22e5e4f2ebb backported, plus distribution patches; amdgpu was built from that tree with this patch on top.
Without the patch this board boots with VRAM at 0 every time (MC_VM_FB_LOCATION 0x00ff0000), and a re-post moves it to 0xf4fff400 under the driver.
With it, after both a warm reboot and a cold boot (powered off for three minutes), amdgpu logs "PCI CONFIG reset" and "GPU posting now..." on load, VRAM is at 0x000000F400000000, MC_VM_FB_LOCATION reads 0xf4fff400 through debugfs, and there are no amdgpu errors.
I then ran five S3 cycles with rtcwake. After each resume MC_VM_FB_LOCATION was still 0xf4fff400, the GART table was at 0x000000F401B00000, the internal panel came back, and the kernel log showed no amdgpu errors, ring timeouts or IOMMU faults.
The 560 is not in vi_reset_quirks[], so v3 3/3 behaves the same way on this machine. This also covers the one-line quirk entry I sent for this GPU [1], so that one can be dropped.