[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d71e258-0bfd-a0d0-868f-a3299864de5b@redhat.com>
Date: Tue, 25 Jul 2023 10:39:29 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>,
Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc: lenb@...nel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ACPI: video: Put ACPI video and its child devices to
D0 at boot
Hi,
On 7/21/23 17:45, Rafael J. Wysocki wrote:
> Thanks for the update!
>
> On Fri, Jul 21, 2023 at 5:22 PM Kai-Heng Feng
> <kai.heng.feng@...onical.com> wrote:
>>
>> Screen brightness can only be changed once on HP ZBook Fury 16 G10.
>>
>> Vendor identified the root cause as Linux doesn't invoke _PS0 at boot
>> for all ACPI devices:
>>
>> Scope (\_SB.PC00.GFX0)
>> {
>> Scope (DD1F)
>> {
>> Method (_PS0, 0, Serialized) // _PS0: Power State 0
>> {
>> If (CondRefOf (\_SB.PC00.LPCB.EC0.SSBC))
>> {
>> \_SB.PC00.LPCB.EC0.SSBC ()
>> }
>> }
>> ...
>> }
>> ...
>> }
>>
>> The \_SB.PC00.GFX0.DD1F is the panel device, and its _PS0 needs to be
>> executed to make the brightness control work properly.
>>
>> _PS0 doesn't get invoked for this device because _PSC is missing,
>> which violates ACPI spec 6.3, section 7.3.6. Commit 7cd8407d53ef
>> ("ACPI / PM: Do not execute _PS0 for devices without _PSC during
>> initialization") tried to workaround missing _PSC on defective
>> firmwares, but got reverted because of regression.
>>
>> So the safest approach is to use acpi_device_fix_up_power_extended() to
>> put ACPI video and its child devices to D0 to workaround the issue.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217683
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
>
> Hans, what do you think?
I believe most (almost all?) child devices of the GFX0 (and other
acpi-video) ACPI device will not have a _PS0. So wrt child-devices
this should mostly be a no-op.
However the GFX0 ACPI device is the ACPI companion for the PCI
device for the GPU, so this will also execute _PS0 on the GPU,
we do that every suspend/resume cycle so this should be fine.
But if we do see regressions then we may need to rework this
to skip the _PS0 on the GPU itself.
With that caveat this looks good to me:
Reviewed-by: Hans de Goede <hdegoede@...hat.com>
Regards,
Hans
>
>> ---
>> v3:
>> - Wording change to make it clear it's a firmware issue.
>> - Specify the device name in comment.
>>
>> v2:
>> - Wording
>> - Bugzilla
>> - Add comment
>>
>> drivers/acpi/acpi_video.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
>> index 62f4364e4460..1732780a672b 100644
>> --- a/drivers/acpi/acpi_video.c
>> +++ b/drivers/acpi/acpi_video.c
>> @@ -2027,6 +2027,12 @@ static int acpi_video_bus_add(struct acpi_device *device)
>> if (error)
>> goto err_put_video;
>>
>> + /*
>> + * HP ZBook Fury 16 G10 requires ACPI video's child devices have _PS0
>> + * evaluated to have functional panel brightness control.
>> + */
>> + acpi_device_fix_up_power_extended(device);
>> +
>> pr_info("%s [%s] (multi-head: %s rom: %s post: %s)\n",
>> ACPI_VIDEO_DEVICE_NAME, acpi_device_bid(device),
>> video->flags.multihead ? "yes" : "no",
>> --
>> 2.34.1
>>
>
Powered by blists - more mailing lists