[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21fe5a6c-06f9-a902-6621-19c4a2a451ad@redhat.com>
Date: Thu, 29 Dec 2022 15:35:12 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: Mario Limonciello <mario.limonciello@....com>,
Alex Deucher <alexander.deucher@....com>,
linux-kernel@...r.kernel.org
Cc: Carlos Soriano Sanchez <csoriano@...hat.com>,
amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, christian.koenig@....com,
stable@...r.kernel.org, Alex Deucher <alex.deucher@....com>,
"Pan, Xinhui" <Xinhui.Pan@....com>
Subject: Re: [PATCH v2 01/11] drm/amd: Delay removal of the firmware
framebuffer
Hello Mario,
On 12/28/22 17:30, Mario Limonciello wrote:
> Removing the firmware framebuffer from the driver means that even
> if the driver doesn't support the IP blocks in a GPU it will no
> longer be functional after the driver fails to initialize.
>
> This change will ensure that unsupported IP blocks at least cause
> the driver to work with the EFI framebuffer.
>
> Cc: stable@...r.kernel.org
> Suggested-by: Alex Deucher <alex.deucher@....com>
> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> ---
As mentioned, I'm not familiar with this driver but the change looks
good to me. Delaying the firmware-provided framebuffer removal is the
correct thing to do IMO.
Reviewed-by: Javier Martinez Canillas <javierm@...hat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Powered by blists - more mailing lists