All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: "Alex Deucher" <alexdeucher@gmail.com>,
	"Christian König" <christian.koenig@amd.com>
Cc: Richard Lane <richardlanedev@gmail.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 08:16:22 -0500	[thread overview]
Message-ID: <6f79a3e2-5510-4018-aabd-45fcdf5dcbb3@amd.com> (raw)
In-Reply-To: <CADnq5_M8f2Hgs06n9EXUaihGsr6YEm6G4YFVQmPfQbGU08XkBg@mail.gmail.com>



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

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


  reply	other threads:[~2026-10-27 13:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26 22:46 [PATCH 1/3] drm/amdgpu: reserve 64M stolen memory for Apple 5K iMac Richard Lane
2026-10-27 12:14 ` Christian König
2026-10-27 12:57   ` Alex Deucher
2026-10-27 13:16     ` Mario Limonciello [this message]
2026-10-27 13:37       ` Alex Deucher
2026-10-27 23:59         ` Richard Lane
2026-10-28  2:14           ` Mario Limonciello
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=6f79a3e2-5510-4018-aabd-45fcdf5dcbb3@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.