[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <efae4aa5-29e4-4811-a91a-3f6182ccbe65@amd.com>
Date: Fri, 28 Mar 2025 08:42:40 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Gergo Koteles <soyer@....hu>
Cc: Len Brown <lenb@...nel.org>, Rodrigo Siqueira <siqueira@...lia.com>,
Alex Hung <alex.hung@....com>, Alex Deucher <alexander.deucher@....com>,
linux-acpi@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH] ACPI: video: Handle fetching EDID as ACPI_TYPE_PACKAGE
On 3/28/2025 06:12, Rafael J. Wysocki wrote:
> CC: Hans
>
> On Fri, Mar 28, 2025 at 3:51 AM Gergo Koteles <soyer@....hu> wrote:
>>
>> Some Lenovo laptops incorrectly return EDID as
>> buffer in ACPI package (instead of just a buffer)
>> when calling _DDC.
>>
>> Calling _DDC generates this ACPI Warning:
>> ACPI Warning: \_SB.PCI0.GP17.VGA.LCD._DDC: Return type mismatch - \
>> found Package, expected Integer/Buffer (20240827/nspredef-254)
>>
>> Use the first element of the package to get the EDID buffer.
>>
>> The DSDT:
>>
>> Name (AUOP, Package (0x01)
>> {
>> Buffer (0x80)
>> {
>> ...
>> }
>> })
>>
>> ...
>>
>> Method (_DDC, 1, NotSerialized) // _DDC: Display Data Current
>> {
>> If ((PAID == AUID))
>> {
>> Return (AUOP) /* \_SB_.PCI0.GP17.VGA_.LCD_.AUOP */
>> }
>> ElseIf ((PAID == IVID))
>> {
>> Return (IVOP) /* \_SB_.PCI0.GP17.VGA_.LCD_.IVOP */
>> }
>> ElseIf ((PAID == BOID))
>> {
>> Return (BOEP) /* \_SB_.PCI0.GP17.VGA_.LCD_.BOEP */
>> }
>> ElseIf ((PAID == SAID))
>> {
>> Return (SUNG) /* \_SB_.PCI0.GP17.VGA_.LCD_.SUNG */
>> }
>>
>> Return (Zero)
>> }
>>
>> Cc: stable@...r.kernel.org
>> Fixes: c6a837088bed ("drm/amd/display: Fetch the EDID from _DDC if available for eDP")
>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4085
>> Signed-off-by: Gergo Koteles <soyer@....hu>
FWIW the ACPI spec is clear that this /should/ be an ACPI buffer.
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/Apx_B_Video_Extensions/output-device-specific-methods.html#ddc-return-the-edid-for-this-device
That being said this is production firmware and in the wild, I don't
personally see a problem with handling it this way.
Some other improvement suggestion though below.
>> ---
>> drivers/acpi/acpi_video.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
>> index efdadc74e3f4..65cf36796506 100644
>> --- a/drivers/acpi/acpi_video.c
>> +++ b/drivers/acpi/acpi_video.c
>> @@ -649,6 +649,9 @@ acpi_video_device_EDID(struct acpi_video_device *device, void **edid, int length
>>
>> obj = buffer.pointer;
>>
>> + if (obj && obj->type == ACPI_TYPE_PACKAGE && obj->package.count == 1)
>> + obj = &obj->package.elements[0];
>> +
As the ACPI spec indicates this should be a buffer, I think it's a good
idea to emit a FW_BUG message here so that this can be detected by users
and tools like FWTS and the firmware can be improved in the future.
Something like this:
if (condition) {
pr_info(FW_BUG "EDID was found in ACPI package instead of ACPI buffer");
obj = &obj->package.elements[0];
}
>> if (obj && obj->type == ACPI_TYPE_BUFFER) {
>> *edid = kmemdup(obj->buffer.pointer, obj->buffer.length, GFP_KERNEL);
>> ret = *edid ? obj->buffer.length : -ENOMEM;
>> @@ -658,7 +661,7 @@ acpi_video_device_EDID(struct acpi_video_device *device, void **edid, int length
>> ret = -EFAULT;
>> }
>>
>> - kfree(obj);
>> + kfree(buffer.pointer);
Any reason for this change? obj is assigned to buffer.pointer already.
>> return ret;
>> }
>>
>> --
>> 2.49.0
>>
Powered by blists - more mailing lists