[PATCH] drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0

[PATCH] drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0

[Maciej Kucharek]

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.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5978
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/si.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 0adfd4b10..892e80f09 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -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;
 }
 
-- 
2.55.0

RE: [PATCH] drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0

[Deucher, Alexander]

Public

> -----Original Message-----
> From: Maciej Kucharek <qchcio@gmail.com>
> Sent: Wednesday, October 14, 2026 3:21 PM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>
> Cc: Koenig, Christian <Christian.Koenig@amd.com>; Maciej Kucharek
> <qchcio@gmail.com>
> Subject: [PATCH] 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.

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

>
> 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.
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5978
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/si.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si.c
> b/drivers/gpu/drm/amd/amdgpu/si.c index 0adfd4b10..892e80f09 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si.c
> +++ b/drivers/gpu/drm/amd/amdgpu/si.c
> @@ -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;
>  }
>
> --
> 2.55.0

[PATCH v2 0/3] drm/amdgpu: reset SI/CIK/VI ASIC on Apple boards with VRAM at 0

[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, 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/20261014192030.10611-1-qchcio@gmail.com/

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(+)

-- 
2.55.0

[PATCH v2 1/3] drm/amdgpu: reset SI ASIC on MacBookPros with VRAM at 0

[Maciej Kucharek]

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.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5978
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/si.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 0adfd4b10..e5e590425 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -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;
 }
 
-- 
2.55.0

[PATCH v2 2/3] drm/amdgpu: reset CIK ASIC on Apple boards with VRAM at 0

[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.  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.

Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/cik.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index d29991a4a..e1029239b 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik.c
@@ -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;
 
-- 
2.55.0

[PATCH v2 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0

[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_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.

Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index a0435fd55..cad6bbfce 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -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 &&
-- 
2.55.0

Re: [PATCH v2 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0

[Alex Deucher]

On Thu, Oct 15, 2026 at 9:06 AM Maciej Kucharek <qchcio@gmail.com> wrote:
>
> 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_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.
>
> Suggested-by: Alex Deucher <alexander.deucher@amd.com>
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index a0435fd55..cad6bbfce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -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 &&

Please drop the now duplicate quirk handling here.

Thanks,

Alex

> --
> 2.55.0
>

Re: [PATCH v2 3/3] drm/amdgpu: reset VI ASIC on Apple boards with VRAM at 0

[Alex Deucher]

On Thu, Oct 15, 2026 at 9:26 AM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> On Thu, Oct 15, 2026 at 9:06 AM Maciej Kucharek <qchcio@gmail.com> wrote:
> >
> > 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_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.
> >
> > Suggested-by: Alex Deucher <alexander.deucher@amd.com>
> > Cc: stable@vger.kernel.org
> > Assisted-by: Claude:claude-opus-5-5
> > Signed-off-by: Maciej Kucharek <qchcio@gmail.com>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/vi.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> > index a0435fd55..cad6bbfce 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> > @@ -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 &&
>
> 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:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
and applied.

Thanks!

Alex

>
> Thanks,
>
> Alex
>
> > --
> > 2.55.0
> >