From: Mario Limonciello <mario.limonciello@amd.com>
To: Richard Lane <richardlanedev@gmail.com>,
Alex Deucher <alexdeucher@gmail.com>
Cc: "Christian König" <christian.koenig@amd.com>,
amd-gfx@lists.freedesktop.org,
"Alex Deucher" <alexander.deucher@amd.com>,
"Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] drm/amdgpu: reserve 64M stolen memory for Apple 5K iMac
Date: Tue, 27 Oct 2026 21:14:52 -0500 [thread overview]
Message-ID: <76b577d9-e8ce-45d5-9330-564411cc099d@amd.com> (raw)
In-Reply-To: <138497f6-2271-4229-87f1-4e42e9d2b581@gmail.com>
On 10/27/26 18:59, Richard Lane wrote:
> On 27/10/2026 13:37, Alex Deucher wrote:
>> On Tue, Oct 27, 2026 at 9:16 AM Mario Limonciello
>> <mario.limonciello@amd.com> wrote:
>>>
>>>
>>>
>>> On 10/27/26 07:57, Alex Deucher wrote:
>>>> On Tue, Oct 27, 2026 at 8:21 AM Christian König
>>>> <christian.koenig@amd.com> wrote:
>>>>>
>>>>> On 10/26/26 23:46, Richard Lane wrote:
>>>>>> Apple 27" 5K iMacs report a single 2560x2880 tile (28.125 MiB) in
>>>>>> VIEWPORT_SIZE while scanning out up to 64 MiB across the relocated EFI
>>>>>> framebuffer.
>>>>>>
>>>>>> Override the stolen VGA memory allocation size to 64 MiB when matching
>>>>>> PCI_VENDOR_ID_APPLE with a 2560x2880x4 viewport size to prevent
>>>>>> framebuffer corruption during boot handover.
>>>>>
>>>>> Hacks like those are usually a big no-go.
>>>>>
>>>>> Why is that framebuffer handling not working with DC out of the box?
>>>>
>>>> The GMC IP code reserves the memory used by the display hardware from
>>>> the pre-OS console. The gmc get_vbios_fb_size() callback looks to see
>>>> what display viewport was set by the pre-OS environment. If the Macs
>>>> need a workaround, that's where it should go. Since these displays
>>>> require multiple display pipes, my guess is you need to double the
>>>> allocation in that case since the current code just checks the first
>>>> pipe.
>>>
>>>
>>> Could this also be a logic error in that callback? Would it be worth
>>> double checking all the register values in that callback for this system?
>>>
>>> I know for example there are a few different IP specific implementations
>>> in gmc_v9_0_get_vbios_fb_size().
>>
>> Not likely. I suspect the issue is that these systems use two display
>> pipes so we only reserve enough memory to cover half of the display.
>> On PCs the vbios never sets up MST.
>>
>> Alex
>>
>
> I tested doubling the allocation in gmc_v8_0_get_vbios_fb_size():
>
> if (adev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
> size == (2560 * 2880 * 4))
> size *= 2;
>
> That eliminated the corruption across the middle (45-60%) of the screen,
> but still left a band of corruption along the very bottom (95-100%) of
> the screen.
>
> Dumping the DCE registers inside gmc_v8_0_get_vbios_fb_size() on the
> iMac17,1 showed:
>
> vram_start = 0xf400000000, d1vga = 0x0
> CRTC0: grph_en=0x1 surf_hi=0xf4 surf_lo=0x300000 pitch=5120 vp_size=2560x2880
> CRTC1: grph_en=0x80000000 surf_hi=0x0 surf_lo=0x0 pitch=0 vp_size=0x0
>
> Even though only CRTC0 is active at EFI boot with a 2560x2880 viewport,
> Apple's EFI allocates a full 5120-pixel stride surface (mmGRPH_PITCH) and places
> mmGRPH_PRIMARY_SURFACE_ADDRESS at a 3 MiB offset (0x300000) from
> vram_start.
>
> Because CRTC0 scans out 2880 lines at a 5120-pixel pitch starting at
> offset 3 MiB, the active pre-OS scanout spans [3 MiB, 59.25 MiB) in VRAM:
> - Reserving 2560 * 2880 * 4 (28.125 MiB) places permanent driver BOs at
> ~28.125..32 MiB, corrupting the middle (40-60%) of the screen.
> - Reserving 2 * 2560 * 2880 * 4 (56.25 MiB) places those BOs at
> ~56.25..59.25 MiB, leaving the final 3 MiB exposed due to the 0x300000
> surface offset and corrupting the bottom (95-100%) of the screen.
> - Accounting for the 5120 pitch and the 0x300000 surface offset reserves
> the full 59.25 MiB span and eliminates the corruption completely.
>
> For v2 of the patch, which of the following two approaches in both
> gmc_v7_0/v8_0_get_vbios_fb_size() would you prefer? Both tested working.
My feeling is that Option A is less magical. I'd actually wonder if we
should be doing this more widely. I'd *think* the same problem could
happen on a non-Apple display that behaves similarly.
>
> Option A (change whole function):
>
> static unsigned gmc_v8_0_get_vbios_fb_size(struct amdgpu_device *adev)
> {
> u32 d1vga_control = RREG32(mmD1VGA_CONTROL);
> unsigned size;
>
> if (REG_GET_FIELD(d1vga_control, D1VGA_CONTROL, D1VGA_MODE_ENABLE)) {
> size = AMDGPU_VBIOS_VGA_ALLOCATION;
> } else {
> u32 viewport = RREG32(mmVIEWPORT_SIZE);
> - size = (REG_GET_FIELD(viewport, VIEWPORT_SIZE, VIEWPORT_HEIGHT) *
> - REG_GET_FIELD(viewport, VIEWPORT_SIZE, VIEWPORT_WIDTH) * 4);
> + size = REG_GET_FIELD(viewport, VIEWPORT_SIZE, VIEWPORT_HEIGHT) *
> + RREG32(mmGRPH_PITCH) * 4;
> + if (size)
> + size += RREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS) -
> + lower_32_bits(adev->gmc.vram_start);
> }
>
> return size;
> }
>
> Option B (add Apple 5K iMacs quirk):
>
> static unsigned gmc_v8_0_get_vbios_fb_size(struct amdgpu_device *adev)
> {
> u32 d1vga_control = RREG32(mmD1VGA_CONTROL);
> unsigned size;
>
> if (REG_GET_FIELD(d1vga_control, D1VGA_CONTROL, D1VGA_MODE_ENABLE)) {
> size = AMDGPU_VBIOS_VGA_ALLOCATION;
> } else {
> u32 viewport = RREG32(mmVIEWPORT_SIZE);
> size = (REG_GET_FIELD(viewport, VIEWPORT_SIZE, VIEWPORT_HEIGHT) *
> REG_GET_FIELD(viewport, VIEWPORT_SIZE, VIEWPORT_WIDTH) * 4);
> +
> + if (adev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
> + size == (2560 * 2880 * 4))
> + size = size * 2 + RREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS);
> }
>
> return size;
> }
>
>
> Richard
>
>>>
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>>
>>>>>> Signed-off-by: Richard Lane <richardlanedev@gmail.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 10 +++++++++-
>>>>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>>>>>> index 4204c3c750a8..8b196fbfa724 100644
>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>>>>>> @@ -1232,7 +1232,15 @@ void amdgpu_gmc_init_vga_resv_regions(struct amdgpu_device *adev)
>>>>>> } else {
>>>>>> size = amdgpu_gmc_get_vbios_fb_size(adev);
>>>>>>
>>>>>> - if (adev->mman.keep_stolen_vga_memory)
>>>>>> + /*
>>>>>> + * Apple 5K iMacs report one 2560x2880 tile in VIEWPORT_SIZE
>>>>>> + * while scanning out up to 64M across the relocated EFI
>>>>>> + * framebuffer.
>>>>>> + */
>>>>>> + if (adev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
>>>>>> + size == (2560 * 2880 * 4))
>>>>>> + size = 64U * 1024 * 1024;
>>>>>> + else if (adev->mman.keep_stolen_vga_memory)
>>>>>> size = max(size, (unsigned)AMDGPU_VBIOS_VGA_ALLOCATION);
>>>>>> }
>>>>>>
>>>>>> --
>>>>>> 2.55.0
>>>>>
>>>
>
next prev parent reply other threads:[~2026-10-28 2:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 22:46 Richard Lane
2026-10-27 12:14 ` Christian König
2026-10-27 12:57 ` Alex Deucher
2026-10-27 13:16 ` Mario Limonciello
2026-10-27 13:37 ` Alex Deucher
2026-10-27 23:59 ` Richard Lane
2026-10-28 2:14 ` Mario Limonciello [this message]
2026-10-28 10:13 ` Christian König
2026-10-28 14:53 ` Alex Deucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76b577d9-e8ce-45d5-9330-564411cc099d@amd.com \
--to=mario.limonciello@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richardlanedev@gmail.com \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®