On Fri, Oct 16, 2026 at 10:46 AM Sergey Armodin via B4 Relay <[email protected]> wrote: > > From: Sergey Armodin <[email protected]> > > The MacBookPro14,3 also ships with a Radeon Pro 560 (Polaris11, > 1002:67ef, subsystem 106b:0179, revision c0), which has the same problem > as the Radeon Pro 555 added in commit a22e5e4f2ebb ("drm/amdgpu: reset > VI ASIC on MacBookPro14,3"): the firmware leaves the framebuffer at MC > address 0 at boot (MC_VM_FB_LOCATION = 0x00ff0000, 4 GiB of VRAM), while > a re-POST through the VBIOS ASIC_Init table places it at 0xF4_0000_0000 > (0xf4fff400), so a GPU reset, or the S3 resume described there, moves it > under the driver. > > Add this variant to the VI reset quirk table. > > Tested on a MacBookPro14,3 with this Radeon Pro 560 on 7.2.5 with > commit a5be7ad8f5f0 ("drm/amdgpu: reset VI ASIC on MacBookPro15,1") and > the 555 commit backported (the kernel also carries distribution patches > and machine-local workarounds for its BCM43602 Wi-Fi and T1). > > Without this entry the framebuffer is at 0x0000000000000000 on every > boot, and a GPU reset forced through amdgpu_gpu_recover fails: after the > re-POST MC_VM_FB_LOCATION reads 0xf4fff400 while the driver still puts > the GART table at 0x0000000001B00000, the IOMMU reports DMA read faults > from the GPU, and the SMU firmware load fails ("SMU load firmware > failed", then "GPU reset end with ret = -22"), leaving the internal > panel black. > > With it, amdgpu logs a PCI CONFIG reset on load and the framebuffer is > at 0x000000F400000000 after both cold and warm boot. The same forced > GPU reset completes ("GPU reset(1) succeeded!") without SMU errors or > IOMMU faults, followed by two "ring gfx timeout, but soft recovered" > messages, and the GPU came back from 14 S3 cycles (4 lid close, > 3 systemctl suspend, 7 rtcwake) with no amdgpu errors; the internal > panel was back after each lid-close resume. > > Cc: Francisco Beltrán Millalén <[email protected]> > Cc: [email protected] # 6.12.x > Assisted-by: LLM > Signed-off-by: Sergey Armodin <[email protected]>
Already fixed with this patch: https://lists.freedesktop.org/archives/amd-gfx/2026-October/154973.html Alex > --- > The kernel logs of both forced-reset runs (with and without this entry) > and of the S3 cycles are available if they help. > --- > 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 a0435fd..ac26641 100644 > --- a/drivers/gpu/drm/amd/amdgpu/vi.c > +++ b/drivers/gpu/drm/amd/amdgpu/vi.c > @@ -1398,6 +1398,7 @@ 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 */ > + { 0x67ef, PCI_VENDOR_ID_APPLE, 0x0179, 0xc0 }, /* Radeon Pro 560 */ > }; > > static bool vi_need_reset_on_init(struct amdgpu_device *adev) > > --- > base-commit: f307e9d20cc7bd6dd54a3fd8c2af767dd7ef2931 > change-id: 20261016-amdgpu-pro560-quirk-7d51df1c2649 > > Best regards, > -- > Sergey Armodin <[email protected]> > >
