[v1] ACPI: video: Fix missing native backlight on Chromebooks

  Chromebooks don't have backlight in ACPI table, they suppose to use
native backlight in this case. Check presence of the CrOS embedded
controller ACPI device and prefer the native backlight if EC found.

Suggested-by: Hans de Goede <hdegoede@redhat.com>
Fixes: b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 drivers/acpi/video_detect.c | 8 ++++++++
 1 file changed, 8 insertions(+)
  

Hi,

On 10/24/22 15:32, Dmitry Osipenko wrote:
> Chromebooks don't have backlight in ACPI table, they suppose to use
> native backlight in this case. Check presence of the CrOS embedded
> controller ACPI device and prefer the native backlight if EC found.

Thank you for this patch!

> Suggested-by: Hans de Goede <hdegoede@redhat.com>
> Fixes: b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---
>  drivers/acpi/video_detect.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index 0d9064a9804c..8ed5021de6fb 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -668,6 +668,11 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>  	{ },
>  };
>  
> +static bool google_cros_ec_present(void)
> +{
> +	return acpi_dev_found("GOOG0004");
> +}
> +
>  /*
>   * Determine which type of backlight interface to use on this system,
>   * First check cmdline, then dmi quirks, then do autodetect.
> @@ -730,6 +735,9 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>  			return acpi_backlight_video;
>  	}
>  
> +	if (google_cros_ec_present())
> +		return acpi_backlight_native;
> +

Nice, a couple of remarks:

1. Maybe add a small comment explaining why, like all the other tests in the function have a small comment ?

2. I think it would be better to do:

	if (google_cros_ec_present() && native_available)
		return acpi_backlight_native;

I can e.g. imagine in the future some chromebooks where for some reason native
GPU backlight control is not available using the EC for backlight control
and then having the chrome-ec code register a backlight with "vendor" type ?

3. This will also trigger on the Framework laptops and possible other new
non Chromebook designs which choose to use the Chrome EC code for their EC,
I don't expect these devices to get to this point of __acpi_video_get_backlight_type()
(they will hit the earlier acpi_video / native paths) but still I want to
at least point this out in case someone sees a potential issue with this?


If you can address 1. and 2. from above (or explain why 2. is a bad idea)
then I believe that the next version of this can get merged to resolve
the chromebook backlight issues introduced in 6.1-rc1, thank you!


>  	/* No ACPI video (old hw), use vendor specific fw methods. */
>  	return acpi_backlight_vendor;
>  }


Regards,

Hans
  

On 10/24/22 16:46, Hans de Goede wrote:
> Hi,
> 
> On 10/24/22 15:32, Dmitry Osipenko wrote:
>> Chromebooks don't have backlight in ACPI table, they suppose to use
>> native backlight in this case. Check presence of the CrOS embedded
>> controller ACPI device and prefer the native backlight if EC found.
> 
> Thank you for this patch!
> 
>> Suggested-by: Hans de Goede <hdegoede@redhat.com>
>> Fixes: b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> ---
>>  drivers/acpi/video_detect.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index 0d9064a9804c..8ed5021de6fb 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -668,6 +668,11 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>>  	{ },
>>  };
>>  
>> +static bool google_cros_ec_present(void)
>> +{
>> +	return acpi_dev_found("GOOG0004");
>> +}
>> +
>>  /*
>>   * Determine which type of backlight interface to use on this system,
>>   * First check cmdline, then dmi quirks, then do autodetect.
>> @@ -730,6 +735,9 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>  			return acpi_backlight_video;
>>  	}
>>  
>> +	if (google_cros_ec_present())
>> +		return acpi_backlight_native;
>> +
> 
> Nice, a couple of remarks:
> 
> 1. Maybe add a small comment explaining why, like all the other tests in the function have a small comment ?
> 
> 2. I think it would be better to do:
> 
> 	if (google_cros_ec_present() && native_available)
> 		return acpi_backlight_native;
> 
> I can e.g. imagine in the future some chromebooks where for some reason native
> GPU backlight control is not available using the EC for backlight control
> and then having the chrome-ec code register a backlight with "vendor" type ?
> 
> 3. This will also trigger on the Framework laptops and possible other new
> non Chromebook designs which choose to use the Chrome EC code for their EC,
> I don't expect these devices to get to this point of __acpi_video_get_backlight_type()
> (they will hit the earlier acpi_video / native paths) but still I want to
> at least point this out in case someone sees a potential issue with this?
> 
> 
> If you can address 1. and 2. from above (or explain why 2. is a bad idea)
> then I believe that the next version of this can get merged to resolve
> the chromebook backlight issues introduced in 6.1-rc1, thank you!

I don't have anything against 2., it also works.

Thank you for the review!