Re: [PATCH] arch: Fix name collision with ACPI's video.o

[Hans de Goede]

Hi,

On 5/17/24 11:14 AM, Thomas Zimmermann wrote:
> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
> renames the video source files under arch/ such that they do not
> refer to fbdev any longer. The new files named video.o conflict with
> ACPI's video.ko module. Modprobing the ACPI module can then fail with
> warnings about missing symbols, as shown below.
> 
>   (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
> acpi_video_unregister (err -2)
>   (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
> acpi_video_register_backlight (err -2)
>   (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
> __acpi_video_get_backlight_type (err -2)
>   (i915_selftest:1107) igt_kmod-WARNING: i915: Unknown symbol 
> acpi_video_register (err -2)
> 
> Fix the issue by renaming the architecture's video.o to video-common.o.
> 
> Reported-by: Chaitanya Kumar Borah 
> Closes: 
> https://lore.kernel.org/intel-gfx/9dcac6e9-a3bf-4ace-bbdc-f697f767f...@suse.de/T/#t
> Signed-off-by: Thomas Zimmermann 
> Fixes: 2fd001cd3600 ("arch: Rename fbdev header and source files")
> Cc: Arnd Bergmann 
> Cc: linux-a...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




> ---
>  arch/sparc/video/Makefile| 2 +-
>  arch/sparc/video/{video.c => video-common.c} | 0
>  arch/x86/video/Makefile  | 2 +-
>  arch/x86/video/{video.c => video-common.c}   | 0
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename arch/sparc/video/{video.c => video-common.c} (100%)
>  rename arch/x86/video/{video.c => video-common.c} (100%)
> 
> diff --git a/arch/sparc/video/Makefile b/arch/sparc/video/Makefile
> index fdf83a408d750..dcfbe7a5912c0 100644
> --- a/arch/sparc/video/Makefile
> +++ b/arch/sparc/video/Makefile
> @@ -1,3 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
> -obj-y+= video.o
> +obj-y+= video-common.o
> diff --git a/arch/sparc/video/video.c b/arch/sparc/video/video-common.c
> similarity index 100%
> rename from arch/sparc/video/video.c
> rename to arch/sparc/video/video-common.c
> diff --git a/arch/x86/video/Makefile b/arch/x86/video/Makefile
> index fdf83a408d750..dcfbe7a5912c0 100644
> --- a/arch/x86/video/Makefile
> +++ b/arch/x86/video/Makefile
> @@ -1,3 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
> -obj-y+= video.o
> +obj-y+= video-common.o
> diff --git a/arch/x86/video/video.c b/arch/x86/video/video-common.c
> similarity index 100%
> rename from arch/x86/video/video.c
> rename to arch/x86/video/video-common.c

Re: [PATCH] ACPI: video: Fix name collision with architecture's video.o

[Hans de Goede]

Hi,

On 5/16/24 5:11 PM, Thomas Zimmermann wrote:
> Hi
> 
> Am 16.05.24 um 17:03 schrieb Hans de Goede:
>> Hi,
>>
>> On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
>>> CC Hans who has been doing the majority of the ACPI video work.
>>>
>>> On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann  
>>> wrote:
>>>> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
>>>> renames the video source files under arch/ such that they does not
>>>> refer to fbdev any longer. The new files named video.o conflict with
>>>> ACPI's video.ko module.
>>> And surely nobody knew or was unable to check upfront that there was a
>>> video.ko already in the kernel.
>> Sorry, but nack for this change. I very deliberately kept the module-name
>> as video when renaming the actual .c file from video.c to acpi_video.c
>> because many people pass drivers/video/acpi_video.c module arguments
>> on the kernel commandline using video.param=val .
>>
>> Try e.g. doing a duckduckgo search for 1 off:
>>
>> "video.only_lcd"
>> "video.allow_duplicates"
>> "video.brightness_switch_enabled"
> 
> Ok, that makes sense. I'll rename the other files.

Great, thank you.

Regards,

Hans

Re: [PATCH] ACPI: video: Fix name collision with architecture's video.o

[Hans de Goede]

Hi,

On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
> CC Hans who has been doing the majority of the ACPI video work.
> 
> On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann  wrote:
>>
>> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
>> renames the video source files under arch/ such that they does not
>> refer to fbdev any longer. The new files named video.o conflict with
>> ACPI's video.ko module.
> 
> And surely nobody knew or was unable to check upfront that there was a
> video.ko already in the kernel.

Sorry, but nack for this change. I very deliberately kept the module-name
as video when renaming the actual .c file from video.c to acpi_video.c
because many people pass drivers/video/acpi_video.c module arguments
on the kernel commandline using video.param=val .

Try e.g. doing a duckduckgo search for 1 off:

"video.only_lcd"
"video.allow_duplicates"
"video.brightness_switch_enabled"

And you will find a lot of hits. The last one is even documented as
being "video.brightness_switch_enabled" in the main kernel-parameters.txt
as well as separately:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt#n39
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt#n7152
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/video_extension.rst#n118

https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon#Brightness_control

If you rename this module then peoples config will break for
a whole lot of users.

So lets not do that and lets rename the new module which is causing
the conflict in the first place instead.

Regards,

Hans

[Intel-gfx] [PATCH] drm/i915/dsi: Use devm_gpiod_get() for all GPIOs

[Hans de Goede]

soc_gpio_set_value() already uses devm_gpiod_get(), lets be consistent
and use devm_gpiod_get() for all GPIOs.

This allows removing the intel_dsi_vbt_gpio_cleanup() function,
which only function was to put the GPIO-descriptors.

Signed-off-by: Hans de Goede 
---
Note this applies on top of Andy's recent GPIO rework series which
has just landed in drm-intel-next
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 17 ++---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.h |  1 -
 drivers/gpu/drm/i915/display/vlv_dsi.c   | 10 +-
 3 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 275d0218394c..a5d7fc8418c9 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -922,7 +922,7 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, 
bool panel_is_on)
gpiod_add_lookup_table(gpiod_lookup_table);
 
if (want_panel_gpio) {
-   intel_dsi->gpio_panel = gpiod_get(dev->dev, "panel", flags);
+   intel_dsi->gpio_panel = devm_gpiod_get(dev->dev, "panel", 
flags);
if (IS_ERR(intel_dsi->gpio_panel)) {
drm_err(_priv->drm,
"Failed to own gpio for panel control\n");
@@ -932,7 +932,7 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, 
bool panel_is_on)
 
if (want_backlight_gpio) {
intel_dsi->gpio_backlight =
-   gpiod_get(dev->dev, "backlight", flags);
+   devm_gpiod_get(dev->dev, "backlight", flags);
if (IS_ERR(intel_dsi->gpio_backlight)) {
drm_err(_priv->drm,
"Failed to own gpio for backlight control\n");
@@ -943,16 +943,3 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, 
bool panel_is_on)
if (gpiod_lookup_table)
gpiod_remove_lookup_table(gpiod_lookup_table);
 }
-
-void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi)
-{
-   if (intel_dsi->gpio_panel) {
-   gpiod_put(intel_dsi->gpio_panel);
-   intel_dsi->gpio_panel = NULL;
-   }
-
-   if (intel_dsi->gpio_backlight) {
-   gpiod_put(intel_dsi->gpio_backlight);
-   intel_dsi->gpio_backlight = NULL;
-   }
-}
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
index 468d873fab1a..3462fcc760e6 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
@@ -13,7 +13,6 @@ struct intel_dsi;
 
 bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id);
 void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on);
-void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
 void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
 enum mipi_seq seq_id);
 void intel_dsi_log_params(struct intel_dsi *intel_dsi);
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 5bda97c96810..9b33b8a74d64 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1532,16 +1532,8 @@ static void intel_dsi_unprepare(struct intel_encoder 
*encoder)
}
 }
 
-static void intel_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
-   struct intel_dsi *intel_dsi = 
enc_to_intel_dsi(to_intel_encoder(encoder));
-
-   intel_dsi_vbt_gpio_cleanup(intel_dsi);
-   intel_encoder_destroy(encoder);
-}
-
 static const struct drm_encoder_funcs intel_dsi_funcs = {
-   .destroy = intel_dsi_encoder_destroy,
+   .destroy = intel_encoder_destroy,
 };
 
 static enum drm_mode_status vlv_dsi_mode_valid(struct drm_connector *connector,
-- 
2.41.0

Re: [Intel-gfx] [rft, PATCH v4 00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO

[Hans de Goede]

Hi,

On 11/3/23 21:18, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. A second attempt
> to fix that is here.
> 
> If I understood correctly, my approach should work in the similar way as
> the current IOSF GPIO.
> 
> Hans, I believe you have some devices that use this piece of code,
> is it possible to give a test run on (one of) them?

Ok, this now has been testen on both a BYT and a CHT device which
actually use GPIO controls in their MIPI sequences so this
series is:

Tested-by: Hans de Goede 

And the code of the entire series also looks good to me:

Reviewed-by: Hans de Goede 

for the series.

Regards,

Hans




> In v4:
> - fixed compile time errors in patch 14 (Hans, LKP)
> - fixed cover letter Subject
> - added patch 15 (as suggested by Ville)
> - added Ack tag (Jani)
> 
> In v3:
> - incorporated series by Jani
> - incorporated couple of precursor patches by Hans
> - added Rb tag for used to be first three patches (Andi)
> - rebased on top of the above changes
> - fixed indexing for multi-community devices, such as Cherry View
> 
> In v2:
> - added a few cleanup patches
> - reworked to use dynamic GPIO lookup tables
> - converted CHV as well
> 
> Andy Shevchenko (9):
>   drm/i915/dsi: Replace while(1) with one with clear exit condition
>   drm/i915/dsi: Get rid of redundant 'else'
>   drm/i915/dsi: Replace check with a (missing) MIPI sequence name
>   drm/i915/dsi: Extract common soc_gpio_set_value() helper
>   drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
>   drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO
> communities
>   drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
>   drm/i915/dsi: Combine checks in mipi_exec_gpio()
>   drm/i915/iosf: Drop unused APIs
> 
> Hans de Goede (2):
>   drm/i915/dsi: Remove GPIO lookup table at the end of
> intel_dsi_vbt_gpio_init()
>   drm/i915/dsi: Fix wrong initial value for GPIOs in
> bxt_gpio_set_value()
> 
> Jani Nikula (5):
>   drm/i915/dsi: assume BXT gpio works for non-native GPIO
>   drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915
>   drm/i915/dsi: clarify GPIO exec sequence
>   drm/i915/dsi: rename platform specific *_exec_gpio() to
> *_gpio_set_value()
>   drm/i915/dsi: bxt/icl GPIO set value do not need gpio source
> 
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 355 +++
>  drivers/gpu/drm/i915/vlv_sideband.c  |  17 -
>  drivers/gpu/drm/i915/vlv_sideband.h  |   3 -
>  3 files changed, 136 insertions(+), 239 deletions(-)
> 

Re: [Intel-gfx] [PATCH v3 14/15] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi,

On 11/2/23 16:12, Andy Shevchenko wrote:
> It's a dirty hack in the driver that pokes GPIO registers behind
> the driver's back. Moreoever it might be problematic as simultaneous
> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
> cherryview: prevent concurrent access to GPIO controllers") for
> the details. Taking all this into consideration replace the hack
> with proper GPIO APIs being used.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 47 +---
>  1 file changed, 10 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index b1736c1301ea..ffc65c943b11 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -66,19 +66,6 @@ struct i2c_adapter_lookup {
>  #define CHV_GPIO_IDX_START_SW100
>  #define CHV_GPIO_IDX_START_SE198
>  
> -#define CHV_VBT_MAX_PINS_PER_FMLY15
> -
> -#define CHV_GPIO_PAD_CFG0(f, i)  (0x4400 + (f) * 0x400 + (i) * 8)
> -#define  CHV_GPIO_GPIOEN (1 << 15)
> -#define  CHV_GPIO_GPIOCFG_GPIO   (0 << 8)
> -#define  CHV_GPIO_GPIOCFG_GPO(1 << 8)
> -#define  CHV_GPIO_GPIOCFG_GPI(2 << 8)
> -#define  CHV_GPIO_GPIOCFG_HIZ(3 << 8)
> -#define  CHV_GPIO_GPIOTXSTATE(state) ((!!(state)) << 1)
> -
> -#define CHV_GPIO_PAD_CFG1(f, i)  (0x4400 + (f) * 0x400 + (i) * 8 
> + 4)
> -#define  CHV_GPIO_CFGLOCK(1 << 31)
> -
>  /* ICL DSI Display GPIO Pins */
>  #define  ICL_GPIO_DDSP_HPD_A 0
>  #define  ICL_GPIO_L_VDDEN_1  1
> @@ -278,23 +265,21 @@ static void chv_gpio_set_value(struct intel_connector 
> *connector,
>  u8 gpio_source, u8 gpio_index, bool value)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> - u16 cfg0, cfg1;
> - u16 family_num;
> - u8 port;
>  
>   if (connector->panel.vbt.dsi.seq_version >= 3) {
>   if (gpio_index >= CHV_GPIO_IDX_START_SE) {
>   /* XXX: it's unclear whether 255->57 is part of SE. */
> - gpio_index -= CHV_GPIO_IDX_START_SE;
> - port = CHV_IOSF_PORT_GPIO_SE;
> + soc_exec_opaque_gpio(connector, gpio_index, 
> "INT33FF:03", "Panel SE",
> +  gpio_index - 
> CHV_GPIO_IDX_START_SW, value);

The "gpio_index - CHV_GPIO_IDX_START_SW" here needs to be "gpio_index - 
CHV_GPIO_IDX_START_SE".

Also this patch needs s/soc_exec_opaque_gpio/soc_opaque_gpio_set_value/ to 
compile ...

Regards,

Hans




>   } else if (gpio_index >= CHV_GPIO_IDX_START_SW) {
> - gpio_index -= CHV_GPIO_IDX_START_SW;
> - port = CHV_IOSF_PORT_GPIO_SW;
> + soc_exec_opaque_gpio(connector, gpio_index, 
> "INT33FF:00", "Panel SW",
> +  gpio_index - 
> CHV_GPIO_IDX_START_SW, value);
>   } else if (gpio_index >= CHV_GPIO_IDX_START_E) {
> - gpio_index -= CHV_GPIO_IDX_START_E;
> - port = CHV_IOSF_PORT_GPIO_E;
> + soc_exec_opaque_gpio(connector, gpio_index, 
> "INT33FF:02", "Panel E",
> +  gpio_index - CHV_GPIO_IDX_START_E, 
> value);
>   } else {
> - port = CHV_IOSF_PORT_GPIO_N;
> + soc_exec_opaque_gpio(connector, gpio_index, 
> "INT33FF:01", "Panel N",
> +  gpio_index - CHV_GPIO_IDX_START_N, 
> value);
>   }
>   } else {
>   /* XXX: The spec is unclear about CHV GPIO on seq v2 */
> @@ -311,21 +296,9 @@ static void chv_gpio_set_value(struct intel_connector 
> *connector,
>   return;
>   }
>  
> - port = CHV_IOSF_PORT_GPIO_N;
> + soc_exec_opaque_gpio(connector, gpio_index, "INT33FF:01", 
> "Panel N",
> +  gpio_index - CHV_GPIO_IDX_START_N, value);
>   }
> -
> - family_num = gpio_index / CHV_VBT_MAX_PINS_PER_FMLY;
> - gpio_index = gpio_index % CHV_VBT_MAX_PINS_PER_FMLY;
> -
> - cfg0 = CHV_GPIO_PAD_CFG0(family_num, gpio_index);
> - cfg1 = CHV_GPIO_PAD_CFG1(family_num, gpio_index);
> -
> - vlv_iosf_sb_get(dev_priv, BIT(VLV_IOSF_SB_GPIO));
> - vlv_iosf_sb_write(dev_priv, port, cfg1, 0);
> - vlv_iosf_sb_write(dev_priv, port, cfg0,
> -   CHV_GPIO_GPIOEN | CHV_GPIO_GPIOCFG_GPO |
> -   CHV_GPIO_GPIOTXSTATE(value));
> - vlv_iosf_sb_put(dev_priv, BIT(VLV_IOSF_SB_GPIO));
>  }
>  
>  static void bxt_gpio_set_value(struct intel_connector *connector,

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi,

On 11/2/23 15:19, Andy Shevchenko wrote:
> On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
>> On 11/1/23 10:32, Andy Shevchenko wrote:
>>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>>> On 10/31/23 17:07, Hans de Goede wrote:
>>>>> On 10/24/23 18:11, Andy Shevchenko wrote:
>>>>>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
> 
> ...
> 
>> Note you still need the first part of my patch which is
>> an unrelated bugfix:
>>
>> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> @@ -219,8 +219,7 @@ static void soc_exec_gpio(struct intel_connector 
>> *connector, const char *con_id,
>>  } else {
>>  gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
>>   con_id, gpio_index,
>> - value ? GPIOD_OUT_LOW :
>> - GPIOD_OUT_HIGH);
>> + value ? GPIOD_OUT_HIGH : 
>> GPIOD_OUT_LOW);
>>  if (IS_ERR(gpio_desc)) {
>>  drm_err(_priv->drm,
>>  "GPIO index %u request failed (%pe)\n",
> 
> Can you attach or send a formal submission, so I can incorporate it into one
> (v3) series among other changes?

I thought this fixed new code in your series and it is a trivial fix,
so my idea was that you would just fold the fix into the patch
introducing the code.

But I see now that this is existing code from bxt_exec_gpio().

A formal fix to use as a prep patch for your series is now attached,
this is based on top of drm-misc-next (I guess drm-intel-next
would be better but I had an up2date drm-misc-next handy).

Regards,

Hans

From c300ed0e09d1fd14bf966dc172c6db54b888faf3 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Wed, 1 Nov 2023 11:49:01 +0100
Subject: [PATCH] drm/i915/dsi: Fix wrong initial value for GPIOs in
 bxt_exec_gpio()

Fix wrong initial value for GPIOs in bxt_exec_gpio().

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index e56ec3f2d84a..0587cbc2e584 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -356,9 +356,7 @@ static void bxt_exec_gpio(struct intel_connector *connector,
 	if (!gpio_desc) {
 		gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
 		 NULL, gpio_index,
-		 value ? GPIOD_OUT_LOW :
-		 GPIOD_OUT_HIGH);
-
+		 value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW);
 		if (IS_ERR_OR_NULL(gpio_desc)) {
 			drm_err(_priv->drm,
 "GPIO index %u request failed (%ld)\n",
-- 
2.41.0

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi,

On 11/1/23 11:20, Hans de Goede wrote:
> Hi,
> 
> On 11/1/23 10:32, Andy Shevchenko wrote:
>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>> On 10/31/23 17:07, Hans de Goede wrote:
>>>> On 10/24/23 18:11, Andy Shevchenko wrote:
>>>>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>>
>> ...
>>
>>>> As for the CHT support, I have not added that to my tree yet, I would
>>>> prefer to directly test the correct/fixed patch.
>>>
>>> And I hit the "jackpot" on the first device I tried and the code needed
>>> some fixing to actually work, so here is something to fold into v3 to
>>> fix things:
>>
>> Thanks!
>>
>> But let me first send current v3 as it quite differs to v2 in the sense
>> of how I do instantiate GPIO lookup tables.
> 
> The problem is there already is a GPIO lookup table registered for
> the ":00:02.0" device by intel_dsi_vbt_gpio_init() and there can
> be only be one GPIO lookup table per device. So no matter how you
> instantiate GPIO lookup tables it will not work.
> 
> The solution that I chose is to not instantiate a GPIO lookup table
> at all and instead to extend the existing table with an extra entry.
> 
> Although thinking more about it I must admit that this is racy.
> 
> So a better idea would be to unregister the GPIO lookup
> table registered by intel_dsi_vbt_gpio_init() after getting
> the GPIOs there, that would allow instantiating a new one
> from soc_exec_opaque_gpio() as it currently does and that
> would be race free.
> 
>> Meanwhile I will look into the change you sent (and hopefully we can
>> incorporate something in v3 for v4).
> 
> Ok, lets go with your v3.
> 
> I'll prepare a patch  to move the unregistering of the existing
> conflicting GPIO lookup from intel_dsi_vbt_gpio_cleanup()
> to the end of intel_dsi_vbt_gpio_init() to avoid the conflict
> we have there.

Attached is this patch, this should probably be one of
the first patches in the v3 submission.

Note that if you go with Ville's suggestion to preparse
the MIPI sequences, things will change significantly
and then the attached patch will likely be unnecessary.

Regards,

Hans




> Note you still need the first part of my patch which is
> an unrelated bugfix:
> 
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -219,8 +219,7 @@ static void soc_exec_gpio(struct intel_connector 
> *connector, const char *con_id,
>   } else {
>   gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
>con_id, gpio_index,
> -  value ? GPIOD_OUT_LOW :
> -  GPIOD_OUT_HIGH);
> +  value ? GPIOD_OUT_HIGH : 
> GPIOD_OUT_LOW);
>   if (IS_ERR(gpio_desc)) {
>   drm_err(_priv->drm,
>   "GPIO index %u request failed (%pe)\n",
> 
> Regards,
> 
> Hans
> 
> 
From cb3cc656ad89d98824d38c07a35019c512227601 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Wed, 1 Nov 2023 11:54:18 +0100
Subject: [PATCH] drm/i915/dsi: Remove GPIO lookup table at the end of
 intel_dsi_vbt_gpio_init()

To properly deal with GPIOs used in MIPI panel sequences a temporary
GPIO lookup will be used. Since there can only be 1 GPIO lookup table
for the ":00:02.0" device this will not work if the GPIO lookup
table used by intel_dsi_vbt_gpio_init() is still registered.

After getting the "backlight" and "panel" GPIOs the lookup table
registered by intel_dsi_vbt_gpio_init() is no longer necessary,
remove it so that another temporary lookup-table for the ":00:02.0"
device can be added.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 25 +++-
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index cb64454932d1..d965ae1d2b08 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -922,6 +922,7 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on)
 	struct intel_connector *connector = intel_dsi->attached_connector;
 	struct mipi_config *mipi_config = connector->panel.vbt.dsi.config;
 	enum gpiod_flags flags = panel_is_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+	struct gpiod_lookup_table *gpiod_lookup_table = NULL;
 	bool want_backlight_gpio = false;
 	bool want_panel_gpio = false;
 	struct pinctrl

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi,

On 11/1/23 11:34, Ville Syrjälä wrote:
> On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/1/23 10:32, Andy Shevchenko wrote:
>>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>>> On 10/31/23 17:07, Hans de Goede wrote:
>>>>> On 10/24/23 18:11, Andy Shevchenko wrote:
>>>>>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>>>
>>> ...
>>>
>>>>> As for the CHT support, I have not added that to my tree yet, I would
>>>>> prefer to directly test the correct/fixed patch.
>>>>
>>>> And I hit the "jackpot" on the first device I tried and the code needed
>>>> some fixing to actually work, so here is something to fold into v3 to
>>>> fix things:
>>>
>>> Thanks!
>>>
>>> But let me first send current v3 as it quite differs to v2 in the sense
>>> of how I do instantiate GPIO lookup tables.
>>
>> The problem is there already is a GPIO lookup table registered for
>> the ":00:02.0" device by intel_dsi_vbt_gpio_init() and there can
>> be only be one GPIO lookup table per device. So no matter how you
>> instantiate GPIO lookup tables it will not work.
>>
>> The solution that I chose is to not instantiate a GPIO lookup table
>> at all and instead to extend the existing table with an extra entry.
>>
>> Although thinking more about it I must admit that this is racy.
>>
>> So a better idea would be to unregister the GPIO lookup
>> table registered by intel_dsi_vbt_gpio_init() after getting
>> the GPIOs there, that would allow instantiating a new one
>> from soc_exec_opaque_gpio() as it currently does and that
>> would be race free.
> 
> The proper solution would likely be be to pre-parse the sequences
> to determine which GPIOs are actually needed. That would also get
> rid of the bxt_gpio_table[] eyesore.

Interesting suggestion. Note that intel_dsi_vbt_gpio_init() arm
only runs on byt and cht though, so that is something to keep
in mind.

Regards,

Hans

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi,

On 11/1/23 10:32, Andy Shevchenko wrote:
> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>> On 10/31/23 17:07, Hans de Goede wrote:
>>> On 10/24/23 18:11, Andy Shevchenko wrote:
>>>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
> 
> ...
> 
>>> As for the CHT support, I have not added that to my tree yet, I would
>>> prefer to directly test the correct/fixed patch.
>>
>> And I hit the "jackpot" on the first device I tried and the code needed
>> some fixing to actually work, so here is something to fold into v3 to
>> fix things:
> 
> Thanks!
> 
> But let me first send current v3 as it quite differs to v2 in the sense
> of how I do instantiate GPIO lookup tables.

The problem is there already is a GPIO lookup table registered for
the ":00:02.0" device by intel_dsi_vbt_gpio_init() and there can
be only be one GPIO lookup table per device. So no matter how you
instantiate GPIO lookup tables it will not work.

The solution that I chose is to not instantiate a GPIO lookup table
at all and instead to extend the existing table with an extra entry.

Although thinking more about it I must admit that this is racy.

So a better idea would be to unregister the GPIO lookup
table registered by intel_dsi_vbt_gpio_init() after getting
the GPIOs there, that would allow instantiating a new one
from soc_exec_opaque_gpio() as it currently does and that
would be race free.

> Meanwhile I will look into the change you sent (and hopefully we can
> incorporate something in v3 for v4).

Ok, lets go with your v3.

I'll prepare a patch  to move the unregistering of the existing
conflicting GPIO lookup from intel_dsi_vbt_gpio_cleanup()
to the end of intel_dsi_vbt_gpio_init() to avoid the conflict
we have there.

Note you still need the first part of my patch which is
an unrelated bugfix:

--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -219,8 +219,7 @@ static void soc_exec_gpio(struct intel_connector 
*connector, const char *con_id,
} else {
gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
 con_id, gpio_index,
-value ? GPIOD_OUT_LOW :
-GPIOD_OUT_HIGH);
+value ? GPIOD_OUT_HIGH : 
GPIOD_OUT_LOW);
if (IS_ERR(gpio_desc)) {
drm_err(_priv->drm,
"GPIO index %u request failed (%pe)\n",

Regards,

Hans

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi,

On 10/31/23 17:07, Hans de Goede wrote:
> Hi Andy,
> 
> On 10/24/23 18:11, Andy Shevchenko wrote:
>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>>> It's a dirty hack in the driver that pokes GPIO registers behind
>>> the driver's back. Moreoever it might be problematic as simultaneous
>>> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
>>> cherryview: prevent concurrent access to GPIO controllers") for
>>> the details. Taking all this into consideration replace the hack
>>> with proper GPIO APIs being used.
>>
>> Ah, just realised that this won't work if it happens to request to GPIOs with
>> the same index but different communities. I will fix that in v3, but will 
>> wait
>> for Hans to test VLV and it might even work in most of the cases on CHV as it
>> seems quite unlikely that the above mentioned assertion is going to happen in
>> real life.
> 
> I have added patches 1-5 to my personal tree + a small debug patch on top
> which logs when soc_exec_opaque_gpio() actually gets called.
> 
> So these patches will now get run every time I run some tests on
> one my tablets.
> 
> I'll get back to you with testing results when I've found a device where
> the new soc_exec_opaque_gpio() actually gets called.
> 
> As for the CHT support, I have not added that to my tree yet, I would
> prefer to directly test the correct/fixed patch.

And I hit the "jackpot" on the first device I tried and the code needed
some fixing to actually work, so here is something to fold into v3 to
fix things:

>From 144fae4de91a6b5ed993b1722a07cca679f74cbe Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Tue, 31 Oct 2023 17:04:35 +0100
Subject: [PATCH] drm/i915/dsi: Fix GPIO lookup table used by
 soc_exec_opaque_gpio()

There already is a GPIO lookup table for device ":00:02.0" and
there can be only one GPIO lookup per device.

Instead add an extra empty entry to the GPIO lookup table
registered by intel_dsi_vbt_gpio_init() and use that extra entry
in soc_exec_opaque_gpio().

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 60 ++--
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 8fc82aceae14..70f1d2c411e8 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -219,8 +219,7 @@ static void soc_exec_gpio(struct intel_connector 
*connector, const char *con_id,
} else {
gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
 con_id, gpio_index,
-value ? GPIOD_OUT_LOW :
-GPIOD_OUT_HIGH);
+value ? GPIOD_OUT_HIGH : 
GPIOD_OUT_LOW);
if (IS_ERR(gpio_desc)) {
drm_err(_priv->drm,
"GPIO index %u request failed (%pe)\n",
@@ -232,26 +231,20 @@ static void soc_exec_gpio(struct intel_connector 
*connector, const char *con_id,
}
 }
 
+static struct gpiod_lookup *soc_exec_opaque_gpiod_lookup;
+
 static void soc_exec_opaque_gpio(struct intel_connector *connector,
 const char *chip, const char *con_id,
 u8 gpio_index, bool value)
 {
-   struct gpiod_lookup_table *lookup;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
 
-   lookup = kzalloc(struct_size(lookup, table, 2), GFP_KERNEL);
-   if (!lookup)
-   return;
-
-   lookup->dev_id = ":00:02.0";
-   lookup->table[0] =
+   *soc_exec_opaque_gpiod_lookup =
GPIO_LOOKUP_IDX(chip, gpio_index, con_id, gpio_index, 
GPIO_ACTIVE_HIGH);
 
-   gpiod_add_lookup_table(lookup);
-
soc_exec_gpio(connector, con_id, gpio_index, value);
 
-   gpiod_remove_lookup_table(lookup);
-   kfree(lookup);
+   soc_exec_opaque_gpiod_lookup->key = NULL;
 }
 
 static void vlv_exec_gpio(struct intel_connector *connector,
@@ -898,6 +891,7 @@ static struct gpiod_lookup_table pmic_panel_gpio_table = {
.table = {
/* Panel EN/DISABLE */
GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
+   { }, /* Extra lookup entry for soc_exec_opaque_gpiod_lookup */
{ }
},
 };
@@ -907,6 +901,15 @@ static struct gpiod_lookup_table soc_panel_gpio_table = {
.table = {
GPIO_LOOKUP("INT33FC:01", 10, "backlight", GPIO_ACTIVE_HIGH),
GPIO_LOOKUP("I

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back

[Hans de Goede]

Hi Andy,

On 10/24/23 18:11, Andy Shevchenko wrote:
> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>> It's a dirty hack in the driver that pokes GPIO registers behind
>> the driver's back. Moreoever it might be problematic as simultaneous
>> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
>> cherryview: prevent concurrent access to GPIO controllers") for
>> the details. Taking all this into consideration replace the hack
>> with proper GPIO APIs being used.
> 
> Ah, just realised that this won't work if it happens to request to GPIOs with
> the same index but different communities. I will fix that in v3, but will wait
> for Hans to test VLV and it might even work in most of the cases on CHV as it
> seems quite unlikely that the above mentioned assertion is going to happen in
> real life.

I have added patches 1-5 to my personal tree + a small debug patch on top
which logs when soc_exec_opaque_gpio() actually gets called.

So these patches will now get run every time I run some tests on
one my tablets.

I'll get back to you with testing results when I've found a device where
the new soc_exec_opaque_gpio() actually gets called.

As for the CHT support, I have not added that to my tree yet, I would
prefer to directly test the correct/fixed patch.

Regards,

Hans

Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

[Hans de Goede]

Hi Sean,

On 10/22/23 12:46, Sean Young wrote:
> Hi Hans,
> 
> On Sat, Oct 21, 2023 at 11:08:22AM +0200, Hans de Goede wrote:
>> On 10/19/23 12:51, Uwe Kleine-König wrote:
>>> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>>>> On 10/17/23 11:17, Sean Young wrote:
>>>>> Some drivers require sleeping, for example if the pwm device is connected
>>>>> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
>>>>> with the generated IR signal when sleeping occurs.
>>>>>
>>>>> This patch makes it possible to use pwm when the driver does not sleep,
>>>>> by introducing the pwm_can_sleep() function.
>>>>>
>>>>> Signed-off-by: Sean Young 
>>>>
>>>> I have no objection to this patch by itself, but it seems a bit
>>>> of unnecessary churn to change all current callers of pwm_apply_state()
>>>> to a new API.
>>>
>>> The idea is to improve the semantic of the function name, see
>>> https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rly...@pengutronix.de
>>> for more context.
>>
>> Hmm, so the argument here is that the GPIO API has this, but GPIOs
>> generally speaking can be set atomically, so there not being able
>> to set it atomically is special.
>>
>> OTOH we have many many many other kernel functions which may sleep
>> and we don't all postfix them with _can_sleep.
>>
>> And for PWM controllers pwm_apply_state is IMHO sorta expected to
>> sleep. Many of these are attached over I2C so things will sleep,
>> others have a handshake to wait for the current dutycycle to
>> end before you can apply a second change on top of an earlier
>> change during the current dutycycle which often also involves
>> sleeping.
>>
>> So the natural/expeected thing for pwm_apply_state() is to sleep
>> and thus it does not need a postfix for this IMHO.
> 
> Most pwm drivers look like they can be made to work in atomic context,
> I think. Like you say this is not the case for all of them. Whatever
> we choose to be the default for pwm_apply_state(), we should have a
> clear function name for the alternative. This is essentially why
> pam_apply_cansleep() was picked.
> 
> The alternative to pwm_apply_cansleep() is to have a function name
> which implies it can be used from atomic context. However, 
> pwm_apply_atomic() is not great because the "atomic" could be
> confused with the PWM atomic API, not the kernel process/atomic
> context.

Well pwm_apply_state() is the atomic PWM interface right?

So to me pwm_apply_state_atomic() would be clearly about
running atomically.

> So what should the non-sleeping function be called then? 
>  - pwm_apply_cannotsleep() 
>  - pwm_apply_nosleep()
>  - pwm_apply_nonsleeping()
>  - pwm_apply_atomic_context()

I would just go with:

pwm_apply_state_atomic()

but if this is disliked by others then lets just rename

pwm_apply_state() to pwm_apply_state_cansleep() as
is done in this patch and use plain pwm_apply_state()
for the new atomic-context version.

Regards,

Hans



> 
>>> I think it's very subjective if you consider this
>>> churn or not.
>>
>> I consider it churn because I don't think adding a postfix
>> for what is the default/expected behavior is a good idea
>> (with GPIOs not sleeping is the expected behavior).
>>
>> I agree that this is very subjective and very much goes
>> into the territory of bikeshedding. So please consider
>> the above my 2 cents on this and lets leave it at that.
> 
> You have a valid point. Let's focus on having descriptive function names.
> 
>>> While it's nice to have every caller converted in a single
>>> step, I'd go for
>>>
>>> #define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state)
>>>
>>> , keep that macro for a while and convert all users step by step. This
>>> way we don't needlessly break oot code and the changes to convert to the
>>> new API can go via their usual trees without time pressure.
>>
>> I don't think there are enough users of pwm_apply_state() to warrant
>> such an exercise.
>>
>> So if people want to move ahead with the _can_sleep postfix addition
>> (still not a fan) here is my acked-by for the drivers/platform/x86
>> changes, for merging this through the PWM tree in a single commit:
>>
>> Acked-by: Hans de Goede 
> 
> Thanks,
> 
> Sean
> 

Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

[Hans de Goede]

Hi Uwe,

On 10/19/23 12:51, Uwe Kleine-König wrote:
> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>> Hi Sean,
>>
>> On 10/17/23 11:17, Sean Young wrote:
>>> Some drivers require sleeping, for example if the pwm device is connected
>>> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
>>> with the generated IR signal when sleeping occurs.
>>>
>>> This patch makes it possible to use pwm when the driver does not sleep,
>>> by introducing the pwm_can_sleep() function.
>>>
>>> Signed-off-by: Sean Young 
>>
>> I have no objection to this patch by itself, but it seems a bit
>> of unnecessary churn to change all current callers of pwm_apply_state()
>> to a new API.
> 
> The idea is to improve the semantic of the function name, see
> https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rly...@pengutronix.de
> for more context.

Hmm, so the argument here is that the GPIO API has this, but GPIOs
generally speaking can be set atomically, so there not being able
to set it atomically is special.

OTOH we have many many many other kernel functions which may sleep
and we don't all postfix them with _can_sleep.

And for PWM controllers pwm_apply_state is IMHO sorta expected to
sleep. Many of these are attached over I2C so things will sleep,
others have a handshake to wait for the current dutycycle to
end before you can apply a second change on top of an earlier
change during the current dutycycle which often also involves
sleeping.

So the natural/expeected thing for pwm_apply_state() is to sleep
and thus it does not need a postfix for this IMHO.

> I think it's very subjective if you consider this
> churn or not.

I consider it churn because I don't think adding a postfix
for what is the default/expected behavior is a good idea
(with GPIOs not sleeping is the expected behavior).

I agree that this is very subjective and very much goes
into the territory of bikeshedding. So please consider
the above my 2 cents on this and lets leave it at that.

> While it's nice to have every caller converted in a single
> step, I'd go for
> 
>   #define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state)
> 
> , keep that macro for a while and convert all users step by step. This
> way we don't needlessly break oot code and the changes to convert to the
> new API can go via their usual trees without time pressure.

I don't think there are enough users of pwm_apply_state() to warrant
such an exercise.

So if people want to move ahead with the _can_sleep postfix addition
(still not a fan) here is my acked-by for the drivers/platform/x86
changes, for merging this through the PWM tree in a single commit:

Acked-by: Hans de Goede 

Regards,

Hans

Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context

[Hans de Goede]

Hi Sean,

On 10/17/23 11:17, Sean Young wrote:
> Some drivers require sleeping, for example if the pwm device is connected
> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
> with the generated IR signal when sleeping occurs.
> 
> This patch makes it possible to use pwm when the driver does not sleep,
> by introducing the pwm_can_sleep() function.
> 
> Signed-off-by: Sean Young 

I have no objection to this patch by itself, but it seems a bit
of unnecessary churn to change all current callers of pwm_apply_state()
to a new API.

Why not just keep pwm_apply_state() as is and introduce a new
pwm_apply_state_atomic() for callers which want to apply state
in a case where sleeping is not allowed ?

Regards,

Hans



> ---
>  Documentation/driver-api/pwm.rst  | 16 +++-
>  .../gpu/drm/i915/display/intel_backlight.c|  6 +-
>  drivers/gpu/drm/solomon/ssd130x.c |  2 +-
>  drivers/hwmon/pwm-fan.c   |  8 +-
>  drivers/input/misc/da7280.c   |  4 +-
>  drivers/input/misc/pwm-beeper.c   |  4 +-
>  drivers/input/misc/pwm-vibra.c|  8 +-
>  drivers/leds/leds-pwm.c   |  2 +-
>  drivers/leds/rgb/leds-pwm-multicolor.c|  4 +-
>  drivers/media/rc/pwm-ir-tx.c  |  4 +-
>  drivers/platform/x86/lenovo-yogabook.c|  2 +-
>  drivers/pwm/core.c| 75 ++-
>  drivers/pwm/pwm-renesas-tpu.c |  1 -
>  drivers/pwm/pwm-twl-led.c |  2 +-
>  drivers/pwm/pwm-vt8500.c  |  2 +-
>  drivers/pwm/sysfs.c   | 10 +--
>  drivers/regulator/pwm-regulator.c |  4 +-
>  drivers/video/backlight/lm3630a_bl.c  |  2 +-
>  drivers/video/backlight/lp855x_bl.c   |  2 +-
>  drivers/video/backlight/pwm_bl.c  |  6 +-
>  drivers/video/fbdev/ssd1307fb.c   |  2 +-
>  include/linux/pwm.h   | 57 ++
>  22 files changed, 147 insertions(+), 76 deletions(-)
> 
> diff --git a/Documentation/driver-api/pwm.rst 
> b/Documentation/driver-api/pwm.rst
> index 3fdc95f7a1d15..a2fb5f8f6e1f8 100644
> --- a/Documentation/driver-api/pwm.rst
> +++ b/Documentation/driver-api/pwm.rst
> @@ -41,7 +41,15 @@ the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also 
> exist.
>  
>  After being requested, a PWM has to be configured using::
>  
> - int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
> + int pwm_apply_cansleep(struct pwm_device *pwm, struct pwm_state *state);
> +
> +If the PWM support atomic mode, which can be determined with::
> +
> +bool pwm_is_atomic(struct pwm_device *pwm);
> +
> +Then the PWM can be configured with::
> +
> + int pwm_apply(struct pwm_device *pwm, struct pwm_state *state);
>  
>  This API controls both the PWM period/duty_cycle config and the
>  enable/disable state.
> @@ -57,13 +65,13 @@ If supported by the driver, the signal can be optimized, 
> for example to improve
>  EMI by phase shifting the individual channels of a chip.
>  
>  The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
> -around pwm_apply_state() and should not be used if the user wants to change
> +around pwm_apply_cansleep() and should not be used if the user wants to 
> change
>  several parameter at once. For example, if you see pwm_config() and
>  pwm_{enable,disable}() calls in the same function, this probably means you
> -should switch to pwm_apply_state().
> +should switch to pwm_apply_cansleep().
>  
>  The PWM user API also allows one to query the PWM state that was passed to 
> the
> -last invocation of pwm_apply_state() using pwm_get_state(). Note this is
> +last invocation of pwm_apply_cansleep() using pwm_get_state(). Note this is
>  different to what the driver has actually implemented if the request cannot 
> be
>  satisfied exactly with the hardware in use. There is currently no way for
>  consumers to get the actually implemented settings.
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 2e8f17c045222..cf516190cde8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -274,7 +274,7 @@ static void ext_pwm_set_backlight(const struct 
> drm_connector_state *conn_state,
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
>   pwm_set_relative_duty_cycle(>backlight.pwm_state, level, 100);
> - pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
> + pwm_apply_cansleep(panel->backlight.pwm, >backlight.pwm_state);
>  }
>  
>  static void
> @@ -427,7 +427,7 @@ static void ext_pwm_disable_backlight(const struct 
> drm_connector_state *old_conn
>   intel_backlight_set_pwm_level(old_conn_state, level);
>  
>   panel->backlight.pwm_state.enabled = 

Re: [Intel-gfx] [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

[Hans de Goede]

Hi Andy,

On 10/18/23 07:10, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. An attempt to fix
> that is here.
> 
> If I understood correctly, my approach should work in the similar way as
> the current IOSF GPIO. 
> 
> Hans, I believe you have some devices that use this piece of code,
> is it possible to give a test run on (one of) them?

Yes I should be able to find a device or 2 which poke GPIOs from the
VBT MIPI sequences. Unfortunately I don't know from the top of my head
which devices actually use this, so I may need to try quite a few devices
before finding one which actually uses this.

I'll try to get this series tested sometime the coming weeks,
depending on when I can schedule some time for this.

Regards,

Hans




> 
> Andy Shevchenko (2):
>   drm/i915/dsi: Extract common soc_gpio_exec() helper
>   drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
> 
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 150 +++
>  1 file changed, 58 insertions(+), 92 deletions(-)
> 

Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

[Hans de Goede]

Hi,

On 10/11/23 15:05, Jani Nikula wrote:
> On Sun, 08 Oct 2023, Hans de Goede  wrote:
>> Hi All,
>>
>> Ping what is the status of this now? This v3 addresses all review
>> remarks from previous versions (specifically the request to file
>> + link gitlab issues).
>>
>> So AFAICT this is ready for merging ?
>>
>> But I'm waiting for an ack for this before pushing it
>> do drm-intel-next myself ...
> 
> There are maybe one or two things I could nitpick about, such as casting
> away the const in there, but then I just don't have the time to look
> into this much deeper, it's all fairly isolated, and, let's be honest,
> you of all people probably have the best idea how well the vlv dsi code
> works out in the real world.
> 
> Thanks for fixing all this stuff, and please just merge.
> 
> Acked-by: Jani Nikula 

Thank you, I've pushed this to drm-intel-next now.

Regards,

Hans

Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

[Hans de Goede]

Hi All,

Ping what is the status of this now? This v3 addresses all review
remarks from previous versions (specifically the request to file
+ link gitlab issues).

So AFAICT this is ready for merging ?

But I'm waiting for an ack for this before pushing it
do drm-intel-next myself ...

Regards,

Hans




On 9/20/23 21:56, Hans de Goede wrote:
> Hi All,
> 
> Some vlv/chv tablets ship with Android as factory OS. The factory OS
> BSP style kernel on these tablets does not use the normal x86 hw
> autodetection instead it hardcodes a whole bunch of things including
> using panel drivers instead of relying on VBT MIPI sequences to
> turn the panel/backlight on/off.
> 
> The normal i915 driver (which does not use panel drivers) mostly works
> since the VBT still needs to contain valid info for the GOP, but because
> of the Android kernel relying on panel drivers with various things
> hardcoded some DMI quirks are necessary to fix some issues on these
> devices.
> 
> Some of these issues also are related to which I2C bus to use for
> MIPI sequence elements which do I2C transfers. This series also
> includes a patch adding some extra debugging to mipi_exec_i2c() to
> help with debugging similar issues in the future.
> 
> These patches have been posted before but back then I did not get around
> to follow up on the series:
> https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/
> 
> v2:
> - Drop the changes how the I2C bus number is found, instead just have
>   the quirks set the right number directly where necessary. This should
>   avoid any chances of causing regressions on devices where the quirks
>   do not apply.
> - New quirk for backlight control issues on Lenovo Yoga Tab 3
> - Address Jani Nikula's remark about __func__ being redundant when using
>   drm_dbg_kms()
> 
> v3:
> - File 3 gitlab issues with drm.debug=0xe dmesg output, VBT dump for all
>   3 affected models. Add Closes: tags with links to gitlab issues
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (4):
>   drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
> Asus TF103C (v3)
>   drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
> Lenovo Yoga Tablet 2 series (v3)
>   drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo
> Yoga Tab 3 (v2)
>   drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)
> 
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c |   3 +
>  drivers/gpu/drm/i915/display/vlv_dsi.c   | 124 +++
>  2 files changed, 127 insertions(+)
> 

[Intel-gfx] [PATCH 2/4] drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3)

[Hans de Goede]

On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:

1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
   which under Linux become bus 0 - 6. And the MIPI sequence reference
   to bus 3 is indented for I2C3 which is bus 2 under Linux.

   This leads to errors like these:
   [  178.244049] i2c_designware 80860F41:03: controller timed out
   [  178.245703] i915 :00:02.0: [drm] *ERROR* Failed to xfer payload of 
size (1) to reg (169)
   There are 3 timeouts when the panel is on, delaying
   waking up the screen on a key press by 3 seconds.

   Note mipi_exec_i2c() cannot just subtract 1 from the bus
   given in the I2C MIPI sequence element. Since on other
   devices the I2C bus-numbers used in the MIPI sequences do
   actually start at 0.

2. width_/height_mm contain a bogus 192mm x 120mm size. This is
   especially a problem on the 8" 830 version which uses a 10:16
   portrait screen where as the bogus size is 16:10.

Add a DMI quirk to override the I2C bus and the panel size with
the correct values.

Note both the 10" 1050 models as well as the 8" 830 models use the same
mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200
landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen,
so the quirk handling uses the display resolution to detect the model.

v2:
- Also override i2c_bus_num to fix mipi_exec_i2c() timeouts

v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 0d3aabf6a1dd..f69cafe8a17d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1767,6 +1767,44 @@ static void vlv_dsi_asus_tf103c_mode_fixup(struct 
intel_dsi *intel_dsi)
fixed_mode->vtotal -= 4;
 }
 
+/*
+ * On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:
+ * 1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
+ *which under Linux become bus 0 - 6. And the MIPI sequence reference
+ *to bus 3 is indented for I2C3 which is bus 2 under Linux.
+ *
+ *Note mipi_exec_i2c() cannot just subtract 1 from the bus
+ *given in the I2C MIPI sequence element. Since on other
+ *devices the I2C bus-numbers used in the MIPI sequences do
+ *actually start at 0.
+ *
+ * 2. width_/height_mm contain a bogus 192mm x 120mm size. This is
+ *especially a problem on the 8" 830 version which uses a 10:16
+ *portrait screen where as the bogus size is 16:10.
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9379
+ */
+static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct intel_dsi *intel_dsi)
+{
+   const struct drm_display_mode *fixed_mode =
+   intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+   struct drm_display_info *info = 
_dsi->attached_connector->base.display_info;
+
+   intel_dsi->i2c_bus_num = 2;
+
+   /*
+* The 10" 1050 uses a 1920x1200 landscape screen, where as the 8" 830
+* uses a 1200x1920 portrait screen.
+*/
+   if (fixed_mode->hdisplay == 1920) {
+   info->width_mm = 216;
+   info->height_mm = 135;
+   } else {
+   info->width_mm = 107;
+   info->height_mm = 171;
+   }
+}
+
 static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1776,6 +1814,20 @@ static const struct dmi_system_id 
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
},
+   {
+   /*
+* Lenovo Yoga Tablet 2 830F/L or 1050F/L (The 8" and 10"
+* Lenovo Yoga Tablet 2 use the same mainboard)
+*/
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Intel Corp."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "VALLEYVIEW C0 PLATFORM"),
+   DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+   /* Partial match on beginning of BIOS version */
+   DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21"),
+   },
+   .driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
+   },
{ }
 };
 
-- 
2.41.0

[Intel-gfx] [PATCH 3/4] drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2)

[Hans de Goede]

On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight
on/off MIPI sequences:

1. The backlight on sequence has an I2C MIPI sequence element which uses
   bus 0, but there is a bogus I2cSerialBus resource under the GPU in
   the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus.

2. There is no backlight off sequence, causing the backlight to stay on.

Add a DMI quirk fixing both issues.

v2:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f69cafe8a17d..55da627a8b8d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1805,6 +1805,31 @@ static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct 
intel_dsi *intel_dsi)
}
 }
 
+/*
+ * On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 problems:
+ * 1. i2c_acpi_find_adapter() picks the wrong adapter causing mipi_exec_i2c()
+ *to not work. Fix this by setting i2c_bus_num.
+ * 2. There is no backlight off MIPI sequence, causing the backlight to stay 
on.
+ *Add a backlight off sequence mirroring the existing backlight on 
sequence.
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9380
+ */
+static void vlv_dsi_lenovo_yoga_tab3_backlight_fixup(struct intel_dsi 
*intel_dsi)
+{
+   static const u8 backlight_off_sequence[16] = {
+   /* Header Seq-id 7, length after header 11 bytes */
+   0x07, 0x0b, 0x00, 0x00, 0x00,
+   /* MIPI_SEQ_ELEM_I2C bus 0 addr 0x2c reg 0x00 data-len 1 data 
0x00 */
+   0x04, 0x08, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x01, 0x00,
+   /* MIPI_SEQ_ELEM_END */
+   0x00
+   };
+   struct intel_connector *connector = intel_dsi->attached_connector;
+
+   intel_dsi->i2c_bus_num = 0;
+   connector->panel.vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF] = 
backlight_off_sequence;
+}
+
 static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1828,6 +1853,15 @@ static const struct dmi_system_id 
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
},
+   {
+   /* Lenovo Yoga Tab 3 Pro YT3-X90F */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Blade3-10A-001"),
+   },
+   .driver_data = (void *)vlv_dsi_lenovo_yoga_tab3_backlight_fixup,
+   },
{ }
 };
 
-- 
2.41.0

[Intel-gfx] [PATCH 4/4] drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

[Hans de Goede]

Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.

Changes in v2:
- Drop unnecessary __func__ drm_dbg_kms() argument

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index e56ec3f2d84a..24b2cbcfc1ef 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -565,6 +565,9 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, 
const u8 *data)
u8 payload_size = *(data + 6);
u8 *payload_data;
 
+   drm_dbg_kms(>drm, "bus %d client-addr 0x%02x reg 0x%02x data 
%*ph\n",
+   vbt_i2c_bus_num, slave_addr, reg_offset, payload_size, data 
+ 7);
+
if (intel_dsi->i2c_bus_num < 0) {
intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
i2c_acpi_find_adapter(intel_dsi, slave_addr);
-- 
2.41.0

[Intel-gfx] [PATCH 1/4] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3)

[Hans de Goede]

Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.

Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa
Fixed:"1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 0xa

The factory installed Android has a hardcoded modeline in its kernel,
causing it to not suffer from this BIOS bug;
and the Android boot-splash which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.

This commit introduces a generic DMI based quirk mechanism to vlv_dsi for
doing various fixups, and uses this to correct the modeline.

v2:
- s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic
- Add a comment with the old and new modelines to the patch and commit msg

v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index a96e7d028c5c..0d3aabf6a1dd 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -23,6 +23,7 @@
  * Author: Jani Nikula 
  */
 
+#include 
 #include 
 
 #include 
@@ -1744,6 +1745,40 @@ static void vlv_dphy_param_init(struct intel_dsi 
*intel_dsi)
intel_dsi_log_params(intel_dsi);
 }
 
+typedef void (*vlv_dsi_dmi_quirk_func)(struct intel_dsi *intel_dsi);
+
+/*
+ * Vtotal is wrong on the Asus TF103C leading to the last line of the display
+ * being shown as the first line. The factory installed Android has a hardcoded
+ * modeline, causing it to not suffer from this BIOS bug.
+ *
+ * Original mode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 
0xa
+ * Fixedmode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 
0xa
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9381
+ */
+static void vlv_dsi_asus_tf103c_mode_fixup(struct intel_dsi *intel_dsi)
+{
+   /* Cast away the const as we want to fixup the mode */
+   struct drm_display_mode *fixed_mode = (struct drm_display_mode *)
+   intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+
+   if (fixed_mode->vtotal == 820)
+   fixed_mode->vtotal -= 4;
+}
+
+static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
+   {
+   /* Asus Transformer Pad TF103C */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TF103C"),
+   },
+   .driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
+   },
+   { }
+};
+
 void vlv_dsi_init(struct drm_i915_private *dev_priv)
 {
struct intel_dsi *intel_dsi;
@@ -1752,6 +1787,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_display_mode *current_mode;
+   const struct dmi_system_id *dmi_id;
enum port port;
enum pipe pipe;
 
@@ -1883,6 +1919,14 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err_cleanup_connector;
}
 
+   dmi_id = dmi_first_match(vlv_dsi_dmi_quirk_table);
+   if (dmi_id) {
+   vlv_dsi_dmi_quirk_func quirk_func =
+   (vlv_dsi_dmi_quirk_func)dmi_id->driver_data;
+
+   quirk_func(intel_dsi);
+   }
+
intel_panel_init(intel_connector, NULL);
 
intel_backlight_setup(intel_connector, INVALID_PIPE);
-- 
2.41.0

[Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

[Hans de Goede]

Hi All,

Some vlv/chv tablets ship with Android as factory OS. The factory OS
BSP style kernel on these tablets does not use the normal x86 hw
autodetection instead it hardcodes a whole bunch of things including
using panel drivers instead of relying on VBT MIPI sequences to
turn the panel/backlight on/off.

The normal i915 driver (which does not use panel drivers) mostly works
since the VBT still needs to contain valid info for the GOP, but because
of the Android kernel relying on panel drivers with various things
hardcoded some DMI quirks are necessary to fix some issues on these
devices.

Some of these issues also are related to which I2C bus to use for
MIPI sequence elements which do I2C transfers. This series also
includes a patch adding some extra debugging to mipi_exec_i2c() to
help with debugging similar issues in the future.

These patches have been posted before but back then I did not get around
to follow up on the series:
https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/

v2:
- Drop the changes how the I2C bus number is found, instead just have
  the quirks set the right number directly where necessary. This should
  avoid any chances of causing regressions on devices where the quirks
  do not apply.
- New quirk for backlight control issues on Lenovo Yoga Tab 3
- Address Jani Nikula's remark about __func__ being redundant when using
  drm_dbg_kms()

v3:
- File 3 gitlab issues with drm.debug=0xe dmesg output, VBT dump for all
  3 affected models. Add Closes: tags with links to gitlab issues

Regards,

Hans


Hans de Goede (4):
  drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
Asus TF103C (v3)
  drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
Lenovo Yoga Tablet 2 series (v3)
  drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo
Yoga Tab 3 (v2)
  drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

 drivers/gpu/drm/i915/display/intel_dsi_vbt.c |   3 +
 drivers/gpu/drm/i915/display/vlv_dsi.c   | 124 +++
 2 files changed, 127 insertions(+)

-- 
2.41.0

Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)

[Hans de Goede]

Hi Ville,

On 9/18/23 10:00, Ville Syrjälä wrote:
> On Sat, Sep 16, 2023 at 02:54:51PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Some vlv/chv tablets ship with Android as factory OS. The factory OS
>> BSP style kernel on these tablets does not use the normal x86 hw
>> autodetection instead it hardcodes a whole bunch of things including
>> using panel drivers instead of relying on VBT MIPI sequences to
>> turn the panel/backlight on/off.
>>
>> The normal i915 driver (which does not use panel drivers) mostly works
>> since the VBT still needs to contain valid info for the GOP, but because
>> of the Android kernel relying on panel drivers with various things
>> hardcoded some DMI quirks are necessary to fix some issues on these
>> devices.
>>
>> Some of these issues also are related to which I2C bus to use for
>> MIPI sequence elements which do I2C transfers. This series also
>> includes a patch adding some extra debugging to mipi_exec_i2c() to
>> help with debugging similar issues in the future.
>>
>> These patches have been posted before but back then I did not get around
>> to follow up on the series:
>> https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/
>>
>> Changes compared to this old version:
>> - Drop the changes how the I2C bus number is found, instead just have
>>   the quirks set the right number directly where necessary. This should
>>   avoid any chances of causing regressions on devices where the quirks
>>   do not apply.
>>
>> - New quirk for backlight control issues on Lenovo Yoga Tab 3
>>
>> - Address Jani Nikula's remark about __func__ being redundant when using
>>   drm_dbg_kms()
>>
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>> Hans de Goede (4):
>>   drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
>> Asus TF103C (v2)
>>   drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
>> Lenovo Yoga Tablet 2 series (v2)
>>   drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo
>> Yoga Tab 3
> 
> Please file a bug for each of these and attach the usual drm.debug=0xe
> dmesg + VBT + any other relevant information there. Otherwise a few
> years from now I'll be cursing at these commits as well for not leaving
> a decent papertrail...

Ok. I've just completed filing 3 issues (1 per affected model) and
I've added Closes: tags to the patches pointing to the issues.

I'll send out a v3 of this series with the Closes tags.

Regards,

Hans



> 
>>   drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)
>>
>>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c |   3 +
>>  drivers/gpu/drm/i915/display/vlv_dsi.c   | 124 +++
>>  2 files changed, 127 insertions(+)
>>
>> -- 
>> 2.41.0
> 

[Intel-gfx] [PATCH 4/4] drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

[Hans de Goede]

Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.

Changes in v2:
- Drop unnecessary __func__ drm_dbg_kms() argument

Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index e56ec3f2d84a..24b2cbcfc1ef 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -565,6 +565,9 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, 
const u8 *data)
u8 payload_size = *(data + 6);
u8 *payload_data;
 
+   drm_dbg_kms(>drm, "bus %d client-addr 0x%02x reg 0x%02x data 
%*ph\n",
+   vbt_i2c_bus_num, slave_addr, reg_offset, payload_size, data 
+ 7);
+
if (intel_dsi->i2c_bus_num < 0) {
intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
i2c_acpi_find_adapter(intel_dsi, slave_addr);
-- 
2.41.0

[Intel-gfx] [PATCH 3/4] drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3

[Hans de Goede]

On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight
on/off MIPI sequences:

1. The backlight on sequence has an I2C MIPI sequence element which uses
   bus 0, but there is a bogus I2cSerialBus resource under the GPU in
   the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus.

2. There is no backlight off sequence, causing the backlight to stay on.

Add a DMI quirk fixing both issues.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 32 ++
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index e247e3413d90..db519cfc243b 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1801,6 +1801,29 @@ static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct 
intel_dsi *intel_dsi)
}
 }
 
+/*
+ * On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 problems:
+ * 1. i2c_acpi_find_adapter() picks the wrong adapter causing mipi_exec_i2c()
+ *to not work. Fix this by setting i2c_bus_num.
+ * 2. There is no backlight off MIPI sequence, causing the backlight to stay 
on.
+ *Add a backlight off sequence mirroring the existing backlight on 
sequence.
+ */
+static void vlv_dsi_lenovo_yoga_tab3_backlight_fixup(struct intel_dsi 
*intel_dsi)
+{
+   static const u8 backlight_off_sequence[16] = {
+   /* Header Seq-id 7, length after header 11 bytes */
+   0x07, 0x0b, 0x00, 0x00, 0x00,
+   /* MIPI_SEQ_ELEM_I2C bus 0 addr 0x2c reg 0x00 data-len 1 data 
0x00 */
+   0x04, 0x08, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x01, 0x00,
+   /* MIPI_SEQ_ELEM_END */
+   0x00
+   };
+   struct intel_connector *connector = intel_dsi->attached_connector;
+
+   intel_dsi->i2c_bus_num = 0;
+   connector->panel.vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF] = 
backlight_off_sequence;
+}
+
 static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1824,6 +1847,15 @@ static const struct dmi_system_id 
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
},
+   {
+   /* Lenovo Yoga Tab 3 Pro YT3-X90F */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Blade3-10A-001"),
+   },
+   .driver_data = (void *)vlv_dsi_lenovo_yoga_tab3_backlight_fixup,
+   },
{ }
 };
 
-- 
2.41.0

[Intel-gfx] [PATCH 1/4] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v2)

[Hans de Goede]

Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.

Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa
Fixed:"1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 0xa

The factory installed Android has a hardcoded modeline in its kernel,
causing it to not suffer from this BIOS bug;
and the Android boot-splash which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.

This commit introduces a generic DMI based quirk mechanism to vlv_dsi for
doing various fixups, and uses this to correct the modeline.

v2:
- s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic
- Add a comment with the old and new modelines to the patch and commit msg

Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index a96e7d028c5c..51c4b1491fa2 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -23,6 +23,7 @@
  * Author: Jani Nikula 
  */
 
+#include 
 #include 
 
 #include 
@@ -1744,6 +1745,38 @@ static void vlv_dphy_param_init(struct intel_dsi 
*intel_dsi)
intel_dsi_log_params(intel_dsi);
 }
 
+typedef void (*vlv_dsi_dmi_quirk_func)(struct intel_dsi *intel_dsi);
+
+/*
+ * Vtotal is wrong on the Asus TF103C leading to the last line of the display
+ * being shown as the first line. The factory installed Android has a hardcoded
+ * modeline, causing it to not suffer from this BIOS bug.
+ *
+ * Original mode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 
0xa
+ * Fixedmode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 
0xa
+ */
+static void vlv_dsi_asus_tf103c_mode_fixup(struct intel_dsi *intel_dsi)
+{
+   /* Cast away the const as we want to fixup the mode */
+   struct drm_display_mode *fixed_mode = (struct drm_display_mode *)
+   intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+
+   if (fixed_mode->vtotal == 820)
+   fixed_mode->vtotal -= 4;
+}
+
+static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
+   {
+   /* Asus Transformer Pad TF103C */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TF103C"),
+   },
+   .driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
+   },
+   { }
+};
+
 void vlv_dsi_init(struct drm_i915_private *dev_priv)
 {
struct intel_dsi *intel_dsi;
@@ -1752,6 +1785,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_display_mode *current_mode;
+   const struct dmi_system_id *dmi_id;
enum port port;
enum pipe pipe;
 
@@ -1883,6 +1917,14 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err_cleanup_connector;
}
 
+   dmi_id = dmi_first_match(vlv_dsi_dmi_quirk_table);
+   if (dmi_id) {
+   vlv_dsi_dmi_quirk_func quirk_func =
+   (vlv_dsi_dmi_quirk_func)dmi_id->driver_data;
+
+   quirk_func(intel_dsi);
+   }
+
intel_panel_init(intel_connector, NULL);
 
intel_backlight_setup(intel_connector, INVALID_PIPE);
-- 
2.41.0

[Intel-gfx] [PATCH 2/4] drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v2)

[Hans de Goede]

On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:

1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
   which under Linux become bus 0 - 6. And the MIPI sequence reference
   to bus 3 is indented for I2C3 which is bus 2 under Linux.

   This leads to errors like these:
   [  178.244049] i2c_designware 80860F41:03: controller timed out
   [  178.245703] i915 :00:02.0: [drm] *ERROR* Failed to xfer payload of 
size (1) to reg (169)
   There are 3 timeouts when the panel is on, delaying
   waking up the screen on a key press by 3 seconds.

   Note mipi_exec_i2c() cannot just subtract 1 from the bus
   given in the I2C MIPI sequence element. Since on other
   devices the I2C bus-numbers used in the MIPI sequences do
   actually start at 0.

2. width_/height_mm contain a bogus 192mm x 120mm size. This is
   especially a problem on the 8" 830 version which uses a 10:16
   portrait screen where as the bogus size is 16:10.

Add a DMI quirk to override the I2C bus and the panel size with
the correct values.

Note both the 10" 1050 models as well as the 8" 830 models use the same
mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200
landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen,
so the quirk handling uses the display resolution to detect the model.

Changes in v2:
- Also override i2c_bus_num to fix mipi_exec_i2c() timeouts

Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 51c4b1491fa2..e247e3413d90 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1765,6 +1765,42 @@ static void vlv_dsi_asus_tf103c_mode_fixup(struct 
intel_dsi *intel_dsi)
fixed_mode->vtotal -= 4;
 }
 
+/*
+ * On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:
+ * 1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
+ *which under Linux become bus 0 - 6. And the MIPI sequence reference
+ *to bus 3 is indented for I2C3 which is bus 2 under Linux.
+ *
+ *Note mipi_exec_i2c() cannot just subtract 1 from the bus
+ *given in the I2C MIPI sequence element. Since on other
+ *devices the I2C bus-numbers used in the MIPI sequences do
+ *actually start at 0.
+ *
+ * 2. width_/height_mm contain a bogus 192mm x 120mm size. This is
+ *especially a problem on the 8" 830 version which uses a 10:16
+ *portrait screen where as the bogus size is 16:10.
+ */
+static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct intel_dsi *intel_dsi)
+{
+   const struct drm_display_mode *fixed_mode =
+   intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+   struct drm_display_info *info = 
_dsi->attached_connector->base.display_info;
+
+   intel_dsi->i2c_bus_num = 2;
+
+   /*
+* The 10" 1050 uses a 1920x1200 landscape screen, where as the 8" 830
+* uses a 1200x1920 portrait screen.
+*/
+   if (fixed_mode->hdisplay == 1920) {
+   info->width_mm = 216;
+   info->height_mm = 135;
+   } else {
+   info->width_mm = 107;
+   info->height_mm = 171;
+   }
+}
+
 static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1774,6 +1810,20 @@ static const struct dmi_system_id 
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
},
+   {
+   /*
+* Lenovo Yoga Tablet 2 830F/L or 1050F/L (The 8" and 10"
+* Lenovo Yoga Tablet 2 use the same mainboard)
+*/
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Intel Corp."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "VALLEYVIEW C0 PLATFORM"),
+   DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+   /* Partial match on beginning of BIOS version */
+   DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21"),
+   },
+   .driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
+   },
{ }
 };
 
-- 
2.41.0

[Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)

[Hans de Goede]

Hi All,

Some vlv/chv tablets ship with Android as factory OS. The factory OS
BSP style kernel on these tablets does not use the normal x86 hw
autodetection instead it hardcodes a whole bunch of things including
using panel drivers instead of relying on VBT MIPI sequences to
turn the panel/backlight on/off.

The normal i915 driver (which does not use panel drivers) mostly works
since the VBT still needs to contain valid info for the GOP, but because
of the Android kernel relying on panel drivers with various things
hardcoded some DMI quirks are necessary to fix some issues on these
devices.

Some of these issues also are related to which I2C bus to use for
MIPI sequence elements which do I2C transfers. This series also
includes a patch adding some extra debugging to mipi_exec_i2c() to
help with debugging similar issues in the future.

These patches have been posted before but back then I did not get around
to follow up on the series:
https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/

Changes compared to this old version:
- Drop the changes how the I2C bus number is found, instead just have
  the quirks set the right number directly where necessary. This should
  avoid any chances of causing regressions on devices where the quirks
  do not apply.

- New quirk for backlight control issues on Lenovo Yoga Tab 3

- Address Jani Nikula's remark about __func__ being redundant when using
  drm_dbg_kms()


Regards,

Hans



Hans de Goede (4):
  drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
Asus TF103C (v2)
  drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
Lenovo Yoga Tablet 2 series (v2)
  drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo
Yoga Tab 3
  drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

 drivers/gpu/drm/i915/display/intel_dsi_vbt.c |   3 +
 drivers/gpu/drm/i915/display/vlv_dsi.c   | 124 +++
 2 files changed, 127 insertions(+)

-- 
2.41.0

[Intel-gfx] [PATCH v2] drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()

[Hans de Goede]

The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
a version of 3 or newer and the panel is in vid-mode.

This is based on the big comment around line 730 which starts with
"Panel enable/disable sequences from the VBT spec.", where
the "v3 video mode seq" column does not have any wait t# entries.

Checking the Windows driver shows that it does always honor
the VBT delays independent of the version of the VBT sequences.

Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
the panel_on_delay when there is no reset-deassert MIPI-sequence")
switched to a direct msleep() instead of intel_dsi_msleep()
when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.

And now testing on a Nextbook Ares 8A shows that panel_on_delay
must always be honored otherwise the panel will not turn on.

Instead of only always using regular msleep() for panel_on_delay
do as Windows does and always use regular msleep() everywhere
were intel_dsi_msleep() is used and drop the intel_dsi_msleep()
helper.

Changes in v2:
- Replace all intel_dsi_msleep() calls instead of just
  the intel_dsi_msleep(panel_on_delay) call

Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the 
panel_on_delay when there is no reset-deassert MIPI-sequence")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/icl_dsi.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 --
 drivers/gpu/drm/i915/display/intel_dsi_vbt.h |  1 -
 drivers/gpu/drm/i915/display/vlv_dsi.c   | 22 +---
 4 files changed, 6 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index fc0eaf40dc94..6dd942522021 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1211,7 +1211,7 @@ static void gen11_dsi_powerup_panel(struct intel_encoder 
*encoder)
 
/* panel power on related mipi dsi vbt sequences */
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
-   intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
+   msleep(intel_dsi->panel_on_delay);
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 2cbc1292ab38..f102c13cb959 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -762,17 +762,6 @@ void intel_dsi_vbt_exec_sequence(struct intel_dsi 
*intel_dsi,
gpiod_set_value_cansleep(intel_dsi->gpio_backlight, 0);
 }
 
-void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec)
-{
-   struct intel_connector *connector = intel_dsi->attached_connector;
-
-   /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */
-   if (is_vid_mode(intel_dsi) && connector->panel.vbt.dsi.seq_version >= 3)
-   return;
-
-   msleep(msec);
-}
-
 void intel_dsi_log_params(struct intel_dsi *intel_dsi)
 {
struct drm_i915_private *i915 = to_i915(intel_dsi->base.base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
index dc642c1fe7ef..468d873fab1a 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.h
@@ -16,7 +16,6 @@ void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, 
bool panel_is_on);
 void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
 void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
 enum mipi_seq seq_id);
-void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec);
 void intel_dsi_log_params(struct intel_dsi *intel_dsi);
 
 #endif /* __INTEL_DSI_VBT_H__ */
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 2289f6b1b4eb..37efeab52581 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -783,7 +783,6 @@ static void intel_dsi_pre_enable(struct intel_atomic_state 
*state,
 {
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
-   struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
enum port port;
@@ -831,21 +830,10 @@ static void intel_dsi_pre_enable(struct 
intel_atomic_state *state,
if (!IS_GEMINILAKE(dev_priv))
intel_dsi_prepare(encoder, pipe_config);
 
+   /* Give the panel time to power-on and then deass

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay

[Hans de Goede]

Hi Ville,

On 4/24/23 20:34, Ville Syrjälä wrote:
> On Sat, Apr 22, 2023 at 08:43:59PM +0200, Hans de Goede wrote:
>> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
>> a version of 3 or newer and the panel is in vid-mode.
>>
>> This is based on the big comment around line 730 which starts with
>> "Panel enable/disable sequences from the VBT spec.", where
>> the "v3 video mode seq" column does not have any wait t# entries.
>>
>> Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
>> the panel_on_delay when there is no reset-deassert MIPI-sequence")
>> switched to a direct msleep() instead of intel_dsi_msleep()
>> when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
>> the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.
>>
>> This was done under the assumption that when there is a v3
>> MIPI_SEQ_DEASSERT_RESET sequence it will take care of any
>> necessary delays.
>>
>> On the Nextbook Ares 8A (a Cherry Trail device like the Acer SW3-016)
>> there is a MIPI_SEQ_DEASSERT_RESET sequence, yet panel_on_delay
>> must still be honored otherwise the panel will not turn on.
>>
>> Switch to always using an unconditional msleep() for
>> the panel_on_delay instead of making this depend on
>> the presence of a MIPI_SEQ_DEASSERT_RESET sequence.
> 
> I just checked what Windows does, and at least for icl+ it
> always waits for the panel power delays regardless of what
> the VBT MIPI sequences are doing.
> 
> So I suspect we should just get rid of intel_dsi_msleep()
> entirely and do what the power sequencing delays tell us.
> Anything else is untested territory. If the VBT actually
> wanted us to skip the delays then it should really be
> setting them to zero.

So I checked and there are only 4 (before this patch) /
3 (after this patch) callers of intel_dsi_msleep().

So just getting rid of it entirely sounds good to me.

Shall I prepare a v2 patch which does this ?

Regards,

Hans





>> Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the 
>> panel_on_delay when there is no reset-deassert MIPI-sequence")
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++---
>>  1 file changed, 3 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
>> b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> index a6d6d8b33f3f..1b87f8f5f7fd 100644
>> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> @@ -788,7 +788,6 @@ static void intel_dsi_pre_enable(struct 
>> intel_atomic_state *state,
>>  {
>>  struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>>  struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
>> -struct intel_connector *connector = 
>> to_intel_connector(conn_state->connector);
>>  struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>  enum pipe pipe = crtc->pipe;
>>  enum port port;
>> @@ -836,21 +835,10 @@ static void intel_dsi_pre_enable(struct 
>> intel_atomic_state *state,
>>  if (!IS_GEMINILAKE(dev_priv))
>>  intel_dsi_prepare(encoder, pipe_config);
>>  
>> +/* Give the panel time to power-on and then deassert its reset */
>>  intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>> -
>> -/*
>> - * Give the panel time to power-on and then deassert its reset.
>> - * Depending on the VBT MIPI sequences version the deassert-seq
>> - * may contain the necessary delay, intel_dsi_msleep() will skip
>> - * the delay in that case. If there is no deassert-seq, then an
>> - * unconditional msleep is used to give the panel time to power-on.
>> - */
>> -if (connector->panel.vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
>> -intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>> -intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> -} else {
>> -msleep(intel_dsi->panel_on_delay);
>> -}
>> +msleep(intel_dsi->panel_on_delay);
>> +intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>>  
>>  if (IS_GEMINILAKE(dev_priv)) {
>>  glk_cold_boot = glk_dsi_enable_io(encoder);
>> -- 
>> 2.39.2
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay

[Hans de Goede]

Hi,

On 4/22/23 22:33, Patchwork wrote:
> *Patch Details*
> *Series:* drm/i915/dsi: Always use unconditional msleep() for the 
> panel_on_delay
> *URL:*https://patchwork.freedesktop.org/series/116858/ 
> 
> *State:*  failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116858v1/index.html 
> 
> 
> 
>   CI Bug Log - changes from CI_DRM_13043_full -> Patchwork_116858v1_full
> 
> 
> Summary
> 
> *FAILURE*
> 
> Serious unknown changes coming with Patchwork_116858v1_full absolutely need 
> to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_116858v1_full, please notify your bug team to allow 
> them
> to document this new failure mode, which will reduce false positives in CI.
> 
> 
> Participating hosts (7 -> 7)
> 
> No changes in participating hosts
> 
> 
> Possible new issues
> 
> Here are the unknown changes that may have been introduced in 
> Patchwork_116858v1_full:
> 
> 
>   IGT changes
> 
> 
> Possible regressions
> 
>   * igt@gem_ppgtt@blt-vs-render-ctx0:
>   o shard-snb: PASS 
> 
>  -> FAIL 
> 

The only touched file is not used on snb, so this is a false positive.

Regards,

Hans

[Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay

[Hans de Goede]

The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
a version of 3 or newer and the panel is in vid-mode.

This is based on the big comment around line 730 which starts with
"Panel enable/disable sequences from the VBT spec.", where
the "v3 video mode seq" column does not have any wait t# entries.

Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
the panel_on_delay when there is no reset-deassert MIPI-sequence")
switched to a direct msleep() instead of intel_dsi_msleep()
when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.

This was done under the assumption that when there is a v3
MIPI_SEQ_DEASSERT_RESET sequence it will take care of any
necessary delays.

On the Nextbook Ares 8A (a Cherry Trail device like the Acer SW3-016)
there is a MIPI_SEQ_DEASSERT_RESET sequence, yet panel_on_delay
must still be honored otherwise the panel will not turn on.

Switch to always using an unconditional msleep() for
the panel_on_delay instead of making this depend on
the presence of a MIPI_SEQ_DEASSERT_RESET sequence.

Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the 
panel_on_delay when there is no reset-deassert MIPI-sequence")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index a6d6d8b33f3f..1b87f8f5f7fd 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -788,7 +788,6 @@ static void intel_dsi_pre_enable(struct intel_atomic_state 
*state,
 {
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
-   struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
enum port port;
@@ -836,21 +835,10 @@ static void intel_dsi_pre_enable(struct 
intel_atomic_state *state,
if (!IS_GEMINILAKE(dev_priv))
intel_dsi_prepare(encoder, pipe_config);
 
+   /* Give the panel time to power-on and then deassert its reset */
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
-
-   /*
-* Give the panel time to power-on and then deassert its reset.
-* Depending on the VBT MIPI sequences version the deassert-seq
-* may contain the necessary delay, intel_dsi_msleep() will skip
-* the delay in that case. If there is no deassert-seq, then an
-* unconditional msleep is used to give the panel time to power-on.
-*/
-   if (connector->panel.vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
-   intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
-   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
-   } else {
-   msleep(intel_dsi->panel_on_delay);
-   }
+   msleep(intel_dsi->panel_on_delay);
+   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
 
if (IS_GEMINILAKE(dev_priv)) {
glk_cold_boot = glk_dsi_enable_io(encoder);
-- 
2.39.2

Re: [Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

[Hans de Goede]

Hi,

On 1/11/23 21:16, Rafael J. Wysocki wrote:
> On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede  wrote:
>>
>> The Dell Latitude E6430 both with and without the optional NVidia dGPU
>> has a bug in its ACPI tables which is causing Linux to assign the wrong
>> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>>
>> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
>>
>>  Scope (_SB.PCI0)
>>  {
>>  Device (GFX0)
>>  {
>>  Name (_ADR, 0x0002)  // _ADR: Address
>>  }
>>
>>  ...
>>
>>  Device (VID)
>>  {
>>  Name (_ADR, 0x0002)  // _ADR: Address
>>  ...
>>
>>  Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
>>  {
>>  VDP8 = Arg0
>>  VDP1 (One, VDP8)
>>  }
>>
>>  Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
>>  {
>>  ...
>>  }
>>  ...
>>  }
>>  }
>>
>> The non-functional GFX0 ACPI device is a problem, because this gets
>> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
>>
>> This is a long standing problem and the i915 driver does use the ACPI
>> companion for some things, but works fine without it.
>>
>> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
>> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
>> and that is set on the wrong acpi_device because of the wrong
>> acpi_find_child_device() return. This breaks the ACPI video code,
>> leading to non working backlight control in some cases.
>>
>> Add a type.backlight flag, mark ACPI video bus devices with this and make
>> find_child_checks() return a higher score for children with this flag set,
>> so that it picks the right companion-device.
>>
>> Co-developed-by: Rafael J. Wysocki 
>> Signed-off-by: Hans de Goede 
>> ---
>> Changes in v2:
>> - Switch to Rafael's suggested implementation using a type.backlight flag
>>   and only make find_child_checks() return a higher score when this is set
>> ---
>>  drivers/acpi/glue.c | 14 --
>>  drivers/acpi/scan.c |  7 +--
>>  include/acpi/acpi_bus.h |  3 ++-
>>  3 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>> index 204fe94c7e45..a194f30876c5 100644
>> --- a/drivers/acpi/glue.c
>> +++ b/drivers/acpi/glue.c
>> @@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bus_type(struct 
>> device *dev)
>>  }
>>
>>  #define FIND_CHILD_MIN_SCORE   1
>> -#define FIND_CHILD_MAX_SCORE   2
>> +#define FIND_CHILD_MID_SCORE   2
>> +#define FIND_CHILD_MAX_SCORE   3
>>
>>  static int match_any(struct acpi_device *adev, void *not_used)
>>  {
>> @@ -96,8 +97,17 @@ static int find_child_checks(struct acpi_device *adev, 
>> bool check_children)
>> return -ENODEV;
>>
>> status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
>> -   if (status == AE_NOT_FOUND)
>> +   if (status == AE_NOT_FOUND) {
>> +   /*
>> +* Special case: backlight device objects without _STA are
>> +* preferred to other objects with the same _ADR value, 
>> because
>> +* it is more likely that they are actually useful.
>> +*/
>> +   if (adev->pnp.type.backlight)
>> +   return FIND_CHILD_MID_SCORE;
>> +
>> return FIND_CHILD_MIN_SCORE;
>> +   }
>>
>> if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
>> return -ENODEV;
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 274344434282..0c6f06abe3f4 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle handle, 
>> struct acpi_device_pnp *pnp,
>>  * Some devices don't reliably have _HIDs & _CIDs, so add
>>  * synthetic HIDs to make sure drivers can find them.
>>  */
>> -   if (acpi_is_video_device(handle))
>> +   if (acpi_is_video_device(handle)) {
>> acpi_add_id(pnp, ACPI_VIDEO_HID);
>> -   else if (acpi_bay_match(handle))
>> +

[Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

[Hans de Goede]

The Dell Latitude E6430 both with and without the optional NVidia dGPU
has a bug in its ACPI tables which is causing Linux to assign the wrong
ACPI fwnode / companion to the pci_device for the i915 iGPU.

Specifically under the PCI root bridge there are these 2 ACPI Device()s :

 Scope (_SB.PCI0)
 {
 Device (GFX0)
 {
 Name (_ADR, 0x0002)  // _ADR: Address
 }

 ...

 Device (VID)
 {
 Name (_ADR, 0x0002)  // _ADR: Address
 ...

 Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
 {
 VDP8 = Arg0
 VDP1 (One, VDP8)
 }

 Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
 {
 ...
 }
 ...
 }
 }

The non-functional GFX0 ACPI device is a problem, because this gets
returned as ACPI companion-device by acpi_find_child_device() for the iGPU.

This is a long standing problem and the i915 driver does use the ACPI
companion for some things, but works fine without it.

However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
and that is set on the wrong acpi_device because of the wrong
acpi_find_child_device() return. This breaks the ACPI video code,
leading to non working backlight control in some cases.

Add a type.backlight flag, mark ACPI video bus devices with this and make
find_child_checks() return a higher score for children with this flag set,
so that it picks the right companion-device.

Co-developed-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
Changes in v2:
- Switch to Rafael's suggested implementation using a type.backlight flag
  and only make find_child_checks() return a higher score when this is set
---
 drivers/acpi/glue.c | 14 --
 drivers/acpi/scan.c |  7 +--
 include/acpi/acpi_bus.h |  3 ++-
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 204fe94c7e45..a194f30876c5 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device 
*dev)
 }
 
 #define FIND_CHILD_MIN_SCORE   1
-#define FIND_CHILD_MAX_SCORE   2
+#define FIND_CHILD_MID_SCORE   2
+#define FIND_CHILD_MAX_SCORE   3
 
 static int match_any(struct acpi_device *adev, void *not_used)
 {
@@ -96,8 +97,17 @@ static int find_child_checks(struct acpi_device *adev, bool 
check_children)
return -ENODEV;
 
status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
-   if (status == AE_NOT_FOUND)
+   if (status == AE_NOT_FOUND) {
+   /*
+* Special case: backlight device objects without _STA are
+* preferred to other objects with the same _ADR value, because
+* it is more likely that they are actually useful.
+*/
+   if (adev->pnp.type.backlight)
+   return FIND_CHILD_MID_SCORE;
+
return FIND_CHILD_MIN_SCORE;
+   }
 
if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
return -ENODEV;
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 274344434282..0c6f06abe3f4 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct 
acpi_device_pnp *pnp,
 * Some devices don't reliably have _HIDs & _CIDs, so add
 * synthetic HIDs to make sure drivers can find them.
 */
-   if (acpi_is_video_device(handle))
+   if (acpi_is_video_device(handle)) {
acpi_add_id(pnp, ACPI_VIDEO_HID);
-   else if (acpi_bay_match(handle))
+   pnp->type.backlight = 1;
+   break;
+   }
+   if (acpi_bay_match(handle))
acpi_add_id(pnp, ACPI_BAY_HID);
else if (acpi_dock_match(handle))
acpi_add_id(pnp, ACPI_DOCK_HID);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index cd3b75e08ec3..e44be31115a6 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -230,7 +230,8 @@ struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
u32 platform_id:1;
-   u32 reserved:29;
+   u32 backlight:1;
+   u32 reserved:28;
 };
 
 struct acpi_device_pnp {
-- 
2.39.0

Re: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

[Hans de Goede]

Hi Rafael,

On 1/10/23 14:33, Rafael J. Wysocki wrote:
> On Monday, January 9, 2023 9:57:21 PM CET Hans de Goede wrote:
>> The Dell Latitude E6430 both with and without the optional NVidia dGPU
>> has a bug in its ACPI tables which is causing Linux to assign the wrong
>> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>>
>> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
>>
>>  Scope (_SB.PCI0)
>>  {
>>  Device (GFX0)
>>  {
>>  Name (_ADR, 0x0002)  // _ADR: Address
>>  }
>>
>>  ...
>>
>>  Device (VID)
>>  {
>>  Name (_ADR, 0x0002)  // _ADR: Address
>>  ...
>>
>>  Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
>>  {
>>  VDP8 = Arg0
>>  VDP1 (One, VDP8)
>>  }
>>
>>  Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
>>  {
>>  ...
>>  }
>>  ...
>>  }
>>  }
>>
>> The non-functional GFX0 ACPI device is a problem, because this gets
>> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
>>
>> This is a long standing problem and the i915 driver does use the ACPI
>> companion for some things, but works fine without it.
>>
>> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
>> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
>> and that is set on the wrong acpi_device because of the wrong
>> acpi_find_child_device() return. This breaks the ACPI video code, leading
>> to non working backlight control in some cases.
> 
> Interesting.  Sorry for the trouble.

No problem, as mentioned this is actually a long standing issue / bug
in the ACPI tables, it just never surfaced before.

>> Make find_child_checks() return a higher score for children which have
>> pnp-ids set by various scan helpers like acpi_is_video_device(), so
>> that it picks the right companion-device.
> 
> This has a potential of changing the behavior in some cases that are not
> relevant here which is generally risky.
> 
>> An alternative approach would be to directly call acpi_is_video_device()
>> from find_child_checks() but that would be somewhat computationally
>> expensive given that acpi_find_child_device() iterates over all the
>> PCI0 children every time it is called.
> 
> I agree with the above, but my fix would be something like the patch below 
> (not
> really tested, but it builds).

Thanks, I have just given this a spin on my E6430 and I can confirm
it still fixes things.

I'll send out this version (re-using most of the v1 commitmsg) as a v2
right away.

Regards,

Hans





> 
> ---
>  drivers/acpi/glue.c |   14 --
>  drivers/acpi/scan.c |7 +--
>  include/acpi/acpi_bus.h |3 ++-
>  3 files changed, 19 insertions(+), 5 deletions(-)
> 
> Index: linux-pm/include/acpi/acpi_bus.h
> ===
> --- linux-pm.orig/include/acpi/acpi_bus.h
> +++ linux-pm/include/acpi/acpi_bus.h
> @@ -230,7 +230,8 @@ struct acpi_pnp_type {
>   u32 hardware_id:1;
>   u32 bus_address:1;
>   u32 platform_id:1;
> - u32 reserved:29;
> + u32 backlight:1;
> + u32 reserved:28;
>  };
>  
>  struct acpi_device_pnp {
> Index: linux-pm/drivers/acpi/scan.c
> ===
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle
>* Some devices don't reliably have _HIDs & _CIDs, so add
>* synthetic HIDs to make sure drivers can find them.
>*/
> - if (acpi_is_video_device(handle))
> + if (acpi_is_video_device(handle)) {
>   acpi_add_id(pnp, ACPI_VIDEO_HID);
> - else if (acpi_bay_match(handle))
> + pnp->type.backlight = 1;
> + break;
> + }
> + if (acpi_bay_match(handle))
>   acpi_add_id(pnp, ACPI_BAY_HID);
>   else if (acpi_dock_match(handle))
>   acpi_add_id(pnp, ACPI_DOCK_HID);
> Index: linux-pm/drivers/acpi/glue.c
> ===
> --- linux-pm.orig/drivers/acpi/glue.c
> +++ linux-pm/drivers/acpi/glue.c
> @@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bu
>  }
>  

Re: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

[Hans de Goede]

p.s.

This fixes a regression in 6.1, adding the regressions list to the Cc.

Once we figure out the best way to fix this (this patch is more of a proposal
how to fix this rather then a definitive fix), we should also backport
the fix to 6.1.y.


On 1/9/23 21:57, Hans de Goede wrote:
> The Dell Latitude E6430 both with and without the optional NVidia dGPU
> has a bug in its ACPI tables which is causing Linux to assign the wrong
> ACPI fwnode / companion to the pci_device for the i915 iGPU.
> 
> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
> 
>  Scope (_SB.PCI0)
>  {
>  Device (GFX0)
>  {
>  Name (_ADR, 0x0002)  // _ADR: Address
>  }
> 
>  ...
> 
>  Device (VID)
>  {
>  Name (_ADR, 0x0002)  // _ADR: Address
>  ...
> 
>  Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
>  {
>  VDP8 = Arg0
>  VDP1 (One, VDP8)
>  }
> 
>  Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
>  {
>  ...
>  }
>  ...
>  }
>  }
> 
> The non-functional GFX0 ACPI device is a problem, because this gets
> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
> 
> This is a long standing problem and the i915 driver does use the ACPI
> companion for some things, but works fine without it.
> 
> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
> and that is set on the wrong acpi_device because of the wrong
> acpi_find_child_device() return. This breaks the ACPI video code, leading
> to non working backlight control in some cases.
> 
> Make find_child_checks() return a higher score for children which have
> pnp-ids set by various scan helpers like acpi_is_video_device(), so
> that it picks the right companion-device.
> 
> An alternative approach would be to directly call acpi_is_video_device()
> from find_child_checks() but that would be somewhat computationally
> expensive given that acpi_find_child_device() iterates over all the
> PCI0 children every time it is called.
> 
> Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> Signed-off-by: Hans de Goede 
> ---
>  drivers/acpi/glue.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 204fe94c7e45..2055dfd7678b 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -75,7 +75,7 @@ static struct acpi_bus_type *acpi_get_bus_type(struct 
> device *dev)
>  }
>  
>  #define FIND_CHILD_MIN_SCORE 1
> -#define FIND_CHILD_MAX_SCORE 2
> +#define FIND_CHILD_MAX_SCORE 3
>  
>  static int match_any(struct acpi_device *adev, void *not_used)
>  {
> @@ -89,15 +89,25 @@ static bool acpi_dev_has_children(struct acpi_device 
> *adev)
>  
>  static int find_child_checks(struct acpi_device *adev, bool check_children)
>  {
> + int score = FIND_CHILD_MIN_SCORE;
>   unsigned long long sta;
>   acpi_status status;
>  
>   if (check_children && !acpi_dev_has_children(adev))
>   return -ENODEV;
>  
> + /*
> +  * For devices without a _STA method, prefer devices without a _HID
> +  * (which conflicts with having an _ADR) but which have been matched
> +  * in some other way, like e.g. by acpi_is_video_device() over devices
> +  * with no ids at all.
> +  */
> + if (!adev->pnp.type.platform_id && adev->pnp.type.hardware_id)
> + score++;
> +
>   status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
>   if (status == AE_NOT_FOUND)
> - return FIND_CHILD_MIN_SCORE;
> + return score;
>  
>   if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
>   return -ENODEV;

[Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops

[Hans de Goede]

The Dell Latitude E6430 both with and without the optional NVidia dGPU
has a bug in its ACPI tables which is causing Linux to assign the wrong
ACPI fwnode / companion to the pci_device for the i915 iGPU.

Specifically under the PCI root bridge there are these 2 ACPI Device()s :

 Scope (_SB.PCI0)
 {
 Device (GFX0)
 {
 Name (_ADR, 0x0002)  // _ADR: Address
 }

 ...

 Device (VID)
 {
 Name (_ADR, 0x0002)  // _ADR: Address
 ...

 Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
 {
 VDP8 = Arg0
 VDP1 (One, VDP8)
 }

 Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
 {
 ...
 }
 ...
 }
 }

The non-functional GFX0 ACPI device is a problem, because this gets
returned as ACPI companion-device by acpi_find_child_device() for the iGPU.

This is a long standing problem and the i915 driver does use the ACPI
companion for some things, but works fine without it.

However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
and that is set on the wrong acpi_device because of the wrong
acpi_find_child_device() return. This breaks the ACPI video code, leading
to non working backlight control in some cases.

Make find_child_checks() return a higher score for children which have
pnp-ids set by various scan helpers like acpi_is_video_device(), so
that it picks the right companion-device.

An alternative approach would be to directly call acpi_is_video_device()
from find_child_checks() but that would be somewhat computationally
expensive given that acpi_find_child_device() iterates over all the
PCI0 children every time it is called.

Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
Signed-off-by: Hans de Goede 
---
 drivers/acpi/glue.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 204fe94c7e45..2055dfd7678b 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -75,7 +75,7 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device 
*dev)
 }
 
 #define FIND_CHILD_MIN_SCORE   1
-#define FIND_CHILD_MAX_SCORE   2
+#define FIND_CHILD_MAX_SCORE   3
 
 static int match_any(struct acpi_device *adev, void *not_used)
 {
@@ -89,15 +89,25 @@ static bool acpi_dev_has_children(struct acpi_device *adev)
 
 static int find_child_checks(struct acpi_device *adev, bool check_children)
 {
+   int score = FIND_CHILD_MIN_SCORE;
unsigned long long sta;
acpi_status status;
 
if (check_children && !acpi_dev_has_children(adev))
return -ENODEV;
 
+   /*
+* For devices without a _STA method, prefer devices without a _HID
+* (which conflicts with having an _ADR) but which have been matched
+* in some other way, like e.g. by acpi_is_video_device() over devices
+* with no ids at all.
+*/
+   if (!adev->pnp.type.platform_id && adev->pnp.type.hardware_id)
+   score++;
+
status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
if (status == AE_NOT_FOUND)
-   return FIND_CHILD_MIN_SCORE;
+   return score;
 
if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
return -ENODEV;
-- 
2.39.0

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

[Hans de Goede]

Hi,

On 11/14/22 11:10, Jani Nikula wrote:
> On Mon, 14 Nov 2022, Hans de Goede  wrote:
>> Hi,
>>
>> On 11/14/22 00:23, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the drm-intel tree got a conflict in:
>>>
>>>   drivers/gpu/drm/i915/display/intel_backlight.c
>>>
>>> between commit:
>>>
>>>   b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight 
>>> should be used (v2)")
>>>
>>> from Linus' tree and commit:
>>>
>>>   801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
>>>
>>> from the drm-intel tree.
>>
>> This is weird, because the:
>>
>>b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight 
>> should be used (v2)")
>>
>> commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
>> been back-merged into drm-intel yet ?
> 
> That's the reason it *is* a conflict, right?

Right what I was trying to say is that I am surprised that 6.1-rc1 has not
been back-merged into drm-intel yet even though it has been released
4 weeks ago.

I thought it was more or less standard process to backmerge rc1 soon after
it is released ?

Regards,

Hans

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

[Hans de Goede]

Hi,

On 11/14/22 00:23, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/display/intel_backlight.c
> 
> between commit:
> 
>   b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight 
> should be used (v2)")
> 
> from Linus' tree and commit:
> 
>   801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
> 
> from the drm-intel tree.

This is weird, because the:

   b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight 
should be used (v2)")

commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
been back-merged into drm-intel yet ?

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi Matthew, Rafael,

On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 10/27/22 11:52, Matthew Garrett wrote:
>>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
>>>
>>>> The *only* behavior which actually is new in 6.1 is the native GPU
>>>> drivers now doing the equivalent of:
>>>>
>>>>  if (acpi_video_get_backlight_type() != acpi_backlight_native)
>>>>  return;
>>>>
>>>> In their backlight register paths (i), which is causing the native
>>>> backlight to disappear on your custom laptop setup and on Chromebooks
>>>> (with the Chromebooks case being already solved I hope.).
>>>
>>> It's causing the backlight control to vanish on any machine that isn't
>>> ((acpi_video || vendor interface) || !acpi). Most machines that fall
>>> into that are either weird or Chromebooks or old, but there are machines
>>> that fall into that.
>>
>> I acknowledge that their are machines that fall into this category,
>> but I expect / hope there to be so few of them that we can just DMI
>> quirk our way out if this.
>>
>> I believe the old group to be small because:
>>
>> 1. Generally speaking the "native" control method is usually not
>> present on the really old (pre ACPI video spec) mobile GPUs.
>>
>> 2. On most old laptops I would still expect there to be a vendor
>> interface too, and if both get registered standard desktop environments
>> will prefer the vendor one, so then we need a native DMI quirk to
>> disable the vendor interface anyways and we already have a bunch of
>> those, so some laptops in this group are already covered by DMI quirks.
>>
>> And a fix for the Chromebook case is already in Linus' tree, which
>> just leaves the weird case, of which there will hopefully be only
>> a few.
>>
>> I do share your worry that this might break some machines, but
>> the only way to really find out is to get this code out there
>> I'm afraid.
>>
>> I have just written a blog post asking for people to check if
>> their laptop might be affected; and to report various details
>> to me of their laptop is affected:
>>
>> https://hansdegoede.dreamwidth.org/26548.html
>>
>> Lets wait and see how this goes. If I get (too) many reports then
>> I will send a revert of the addition of the:
>>
>> if (acpi_video_get_backlight_type() != acpi_backlight_native)
>> return;
>>
>> check to the i915 / radeon / amd / nouveau drivers.
>>
>> (And if I only get a couple of reports I will probably just submit
>> DMI quirks for the affected models).
> 
> Sounds reasonable to me, FWIW.

I have received quite a few test reports as a result of my blogpost
(and of the blogpost's mention in an arstechnica article).

Long story short, Matthew, you are right. Quite a few laptop models
will end up with an empty /sys/class/backlight because of the native
backlight class devices no longer registering when
acpi_video_backlight_use_native() returns false.

I will submit a patch-set later today to fix this (by making 
cpi_video_backlight_use_native() always return true for now).

More detailed summary/analysis of the received test reports:

-30 unaffected models

-The following laptop models:
 Acer Aspire 1640
 Apple MacBook 2.1
 Apple MacBook 4.1
 Apple MacBook Pro 7.1 (uses nv_backligh instead of intel_backlight!)
 HP Compaq nc6120
 IBM ThinkPad X40
 System76 Starling Star1

 All only have a native intel_backlight interface and the heuristics from
 acpi_video_get_backlight_type() return acpi_backlight_vendor there causing
 the changes in 6.1 to not register native backlights when
 acpi_video_backlight_use_native() returns false resulting in an empty
 /sys/class/backlight, breaking users ability to control their laptop
 panel's brightness.

 I will submit a patch to always make acpi_video_backlight_use_native()
 return true for now to work around this for 6.1.

 I do plan to try to re-introduce that change again later. First I need to
 change the heuristics to still native on more models so that on models
 where the native backlight is the only (working) entry they will
 return native.

-The Dell N1410 has acpi_video support and acpi_osi_is_win8() returns false
 so acpi_video_get_backlight_type() returns acpi_video, but acpi_video
 fails to register a backlight device due to a_BCM eval error.
 The intel_backlight interface works fine, but this model is going to need
 a DMI-use-native-quirk to avoid intel_backlight disappearing when
 acpi_video_backlight_use_native() is change

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi,

On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 10/27/22 11:52, Matthew Garrett wrote:
>>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
>>>
>>>> The *only* behavior which actually is new in 6.1 is the native GPU
>>>> drivers now doing the equivalent of:
>>>>
>>>>  if (acpi_video_get_backlight_type() != acpi_backlight_native)
>>>>  return;
>>>>
>>>> In their backlight register paths (i), which is causing the native
>>>> backlight to disappear on your custom laptop setup and on Chromebooks
>>>> (with the Chromebooks case being already solved I hope.).
>>>
>>> It's causing the backlight control to vanish on any machine that isn't
>>> ((acpi_video || vendor interface) || !acpi). Most machines that fall
>>> into that are either weird or Chromebooks or old, but there are machines
>>> that fall into that.
>>
>> I acknowledge that their are machines that fall into this category,
>> but I expect / hope there to be so few of them that we can just DMI
>> quirk our way out if this.
>>
>> I believe the old group to be small because:
>>
>> 1. Generally speaking the "native" control method is usually not
>> present on the really old (pre ACPI video spec) mobile GPUs.
>>
>> 2. On most old laptops I would still expect there to be a vendor
>> interface too, and if both get registered standard desktop environments
>> will prefer the vendor one, so then we need a native DMI quirk to
>> disable the vendor interface anyways and we already have a bunch of
>> those, so some laptops in this group are already covered by DMI quirks.
>>
>> And a fix for the Chromebook case is already in Linus' tree, which
>> just leaves the weird case, of which there will hopefully be only
>> a few.
>>
>> I do share your worry that this might break some machines, but
>> the only way to really find out is to get this code out there
>> I'm afraid.
>>
>> I have just written a blog post asking for people to check if
>> their laptop might be affected; and to report various details
>> to me of their laptop is affected:
>>
>> https://hansdegoede.dreamwidth.org/26548.html
>>
>> Lets wait and see how this goes. If I get (too) many reports then
>> I will send a revert of the addition of the:
>>
>> if (acpi_video_get_backlight_type() != acpi_backlight_native)
>> return;
>>
>> check to the i915 / radeon / amd / nouveau drivers.
>>
>> (And if I only get a couple of reports I will probably just submit
>> DMI quirks for the affected models).
> 
> Sounds reasonable to me, FWIW.
> 
> And IIUC the check above can be overridden by passing
> acpi_backlight=native in the kernel command line, right?

Right, that can be used as a quick workaround, but we really do
want this to work OOTB everywhere.

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi,

On 10/27/22 11:52, Matthew Garrett wrote:
> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
> 
>> The *only* behavior which actually is new in 6.1 is the native GPU
>> drivers now doing the equivalent of:
>>
>>  if (acpi_video_get_backlight_type() != acpi_backlight_native)
>>  return;
>>
>> In their backlight register paths (i), which is causing the native
>> backlight to disappear on your custom laptop setup and on Chromebooks
>> (with the Chromebooks case being already solved I hope.).
> 
> It's causing the backlight control to vanish on any machine that isn't 
> ((acpi_video || vendor interface) || !acpi). Most machines that fall 
> into that are either weird or Chromebooks or old, but there are machines 
> that fall into that.

I acknowledge that their are machines that fall into this category,
but I expect / hope there to be so few of them that we can just DMI
quirk our way out if this.

I believe the old group to be small because:

1. Generally speaking the "native" control method is usually not
present on the really old (pre ACPI video spec) mobile GPUs.

2. On most old laptops I would still expect there to be a vendor
interface too, and if both get registered standard desktop environments
will prefer the vendor one, so then we need a native DMI quirk to
disable the vendor interface anyways and we already have a bunch of
those, so some laptops in this group are already covered by DMI quirks.

And a fix for the Chromebook case is already in Linus' tree, which
just leaves the weird case, of which there will hopefully be only
a few.

I do share your worry that this might break some machines, but
the only way to really find out is to get this code out there
I'm afraid.

I have just written a blog post asking for people to check if
their laptop might be affected; and to report various details
to me of their laptop is affected:

https://hansdegoede.dreamwidth.org/26548.html

Lets wait and see how this goes. If I get (too) many reports then
I will send a revert of the addition of the:

if (acpi_video_get_backlight_type() != acpi_backlight_native)
return;

check to the i915 / radeon / amd / nouveau drivers.

(And if I only get a couple of reports I will probably just submit
DMI quirks for the affected models).

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi Matthew,

On 10/27/22 11:11, Matthew Garrett wrote:
> On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote:
> 
>> In their backlight register paths and this has been present since
>> circa 2015.
>>
>> So both before and after my 6.1 refactor vendor is only preferred
>> on devices which don't implement the ACPI video bus control method.
> 
> Sorry, yes, that's the case I meant.
> 
>> Just because a vendor interface is present does not mean that it will
>> work. Unfortunately for none of the 3 main native/acpi_video/vendor
>> backlight control methods the control method being present also guarantees
>> that it will work. Which completely sucks, but it is the reality we
>> have to deal with.
> 
> But traditionally that's been logic that we've encoded into the vendor 
> drivers, which can take other factors into account when determining 
> whether the exposed interface works. You've now discarded that 
> knowledge.

As I already mentioned in my previous email, the vendor drivers have
been using something like:

if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return;

In their backlight register paths *since 2015* and even before
then most of them called some acpi_video helper function to determine
if ACPI video backlight control was available and skipped registering
their backlight device if that returned true. And calling that
acpi_video helper is as smart as they traditionally were. That +
DMI quirks and we still have all those quirks.

I was very careful with the refactoring landing in 6.1 to *not*
change any of this.

The *only* behavior which actually is new in 6.1 is the native GPU
drivers now doing the equivalent of:

if (acpi_video_get_backlight_type() != acpi_backlight_native)
return;

In their backlight register paths (i), which is causing the native
backlight to disappear on your custom laptop setup and on Chromebooks
(with the Chromebooks case being already solved I hope.).

I am fully aware that this may turn out to also impact other laptops.
I'm keeping out an eye for this and I have specifically reached-out
to the coreboot community asking them to test 6.1 .

> The only way you can maintain the degree of functionality 
> that 6.0 had is to move that determination into core code, or 
> alternatively support dynamic reattachment of backlight interfaces based 
> on vendor drivers loading later. An alternative would be to just revert 
> all of this, and instead only use this logic for the output property 
> interface (which would still result in different outcomes, but only for 
> userland that's choosing to use the new interface, so that's a different 
> problem).

Yes I am considering dropping the "acpi_video_get_backlight_type() !=
acpi_backlight_native" check from at least the i915 driver if we get more
bug reports and then indeed only do the equivalent of that check in
the code for the new output property.

I agree this is a possible solution if this turns out to break more
systems and there is no other easy/clean way to fix those. But I would
greatly prefer to keep this change and stop the IMHO bad kernel behavior
of "registering multiple backlight-devices for a single panel and then
let userspace sort it out".

Regards,

Hans


i) Before this, the kernel was relying on userspace preferring acpi_video
or vendor backlight devices over native if both are present and the
native backlight devices were registered unconditionally.

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi,

On 10/26/22 22:49, Matthew Garrett wrote:
> On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote:
> 
>> Ok, so this is a local customization to what is already a custom BIOS
>> for a custom motherboard. There is a lot of custom in that sentence and
>> TBH at some point things might become too custom for them to be expected
>> to work OOTB.
> 
> But it *did* work OOTB before. You broke it. I accept that I'm a 
> ludicrously weird corner case here, but there are going to be other 
> systems that are also affected by this.
> 
>> I'm afraid things are not that simple. I assume that with
>> "if ACPI backlight control is expected to work" you mean don't
>> use ACPI backlight control when (acpi_osi_is_win8() && native_available)
>> evaluates to true because it is known to be broken on some of
>> those systems because Windows 8 stopped using it ?
> 
> Correct.
> 
>> Unfortunately something similar applies to vendor interfaces,
>> When Windows XP started using (and mandating for certification
>> IIRC) ACPI backlight control, vendors still kept their own
>> vendor specific EC/smbios/ACPI/WMI backlight interfaces around for
>> a long long time, except they were often no longer tested.
> 
> The current situation (both before your patchset and with its current 
> implementation) is that vendor is preferred to native, so if the vendor 
> interface is present then we're already using it.

All vendor drivers that I'm aware of have:

if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return;

In their backlight register paths and this has been present since
circa 2015.

So both before and after my 6.1 refactor vendor is only preferred
on devices which don't implement the ACPI video bus control method.

>>> The 
>>> problem you're dealing with is that the knowledge of whether or not 
>>> there's a vendor interface isn't something the core kernel code knows 
>>> about. What you're proposing here is effectively for us to expose 
>>> additional information about whether or not there's a vendor interface 
>>> in the system firmware, but since we're talking in some cases about 
>>> hardware that's almost 20 years old, we're not realistically going to 
>>> get those old machines fixed.
>>
>> I don't understand why you keep talking about the old vendor interfaces,
>> at least for the chromebook part of this thread the issue is that
>> the i915 driver no longer registers the intel_backlight device which
>> is a native device type, which is caused by the patch this email
>> thread is about (and old vendor interfaces do not come into play
>> at all here). So AFAICT this is a native vs acpi backlight control
>> issue ?
> 
> I'm referring to your proposed patch that changed the default from 
> backlight_vendor to backlight_native, which would fix my machine and 
> Chromebooks but break anything that relies on the vendor interfaces.

I see. I agree that preferring native over vendor on machines
which do not have ACPI video backlight control will cause issues
on older machines. Avoiding this scenario is exactly why currently
the native check is conditional on the presence of ACPI video
backlight control.

>> I really want to resolve your bug, but I still lack a lot of info,
>> like what backlight interface you were actually using in 6.0 ?
> 
> Native.
> 
>> {
>>  .callback = video_detect_force_video,
>>  /* ThinkPad X201s */
>>  .matches = {
>> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"),
>> },
>> },
>>
>> will trigger.
> 
> In this case you'd break anyone else running the system who isn't using 
> the hacked EC and different ACPI tables - obviously there's ways round 
> this, but realistically since I'm (as far as I know) the only person in 
> this situation it makes more sense for me to add a kernel parameter than 
> carry around an exceedingly niche DMI quirk. I'm fine with that. But the 
> point I'm trying to make is that the machines *are* telling you whether 
> they'd prefer vendor or native.

I wish that that ("telling you whether they'd prefer vendor or native")
were true. But that does not match my experience at all and I've been
working on making the kernel pick the right backlight interface on
laptops since 2014.

Just because a vendor interface is present does not mean that it will
work. Unfortunately for none of the 3 main native/acpi_video/vendor
backlight control methods the control method being present also guarantees
that it will work. Which completely sucks, but it is the reality we
have to deal with.

> , and you're not taking that into account 
> in the video_detect code.

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi,

On 10/26/22 01:40, Matthew Garrett wrote:
> On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote:
> 
>> this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
>> drivers/acpi/scan.c:
>>
>> static acpi_status
>> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
>>   void **return_value)
>> {
>> long *cap = context;
>>
>> if (acpi_has_method(handle, "_BCM") &&
>> acpi_has_method(handle, "_BCL")) {
>> acpi_handle_debug(handle, "Found generic backlight 
>> support\n");
>> *cap |= ACPI_VIDEO_BACKLIGHT;
>> /* We have backlight support, no need to scan further */
>> return AE_CTRL_TERMINATE;
>> }
>> return 0;
>> }
> 
> Ah, yeah, my local tree no longer matches the upstream behaviour because 
> I've hacked the EC firmware to remove the backlight trigger because it 
> had an extremely poor brightness curve and also automatically changed it 
> on AC events - as a result I removed the backlight code from the DSDT 
> and just fell back to the native control. Like I said I'm a long way 
> from the normal setup, but this did previously work.

Ok, so this is a local customization to what is already a custom BIOS
for a custom motherboard. There is a lot of custom in that sentence and
TBH at some point things might become too custom for them to be expected
to work OOTB.

Note that you can always just override the choses made by the heuristisc/
quirks on the kernel commandline by adding:

acpi_backlight=native   (I think you want this one?)

or if you want the old thinkpad_acpi module vendor/EC interface:

acpi_backlight=vendor

Asking you to pass this on the commandline does not seem like a huge
stretch given the large amount of hw/firmware customization you have done ?

> The "right" logic here seems pretty simple: if ACPI backlight control is 
> expected to work, use it. If it isn't, but there's a vendor interface, 
> use it. If there's no vendor interface, use the native interface.

I'm afraid things are not that simple. I assume that with
"if ACPI backlight control is expected to work" you mean don't
use ACPI backlight control when (acpi_osi_is_win8() && native_available)
evaluates to true because it is known to be broken on some of
those systems because Windows 8 stopped using it ?

Unfortunately something similar applies to vendor interfaces,
When Windows XP started using (and mandating for certification
IIRC) ACPI backlight control, vendors still kept their own
vendor specific EC/smbios/ACPI/WMI backlight interfaces around for
a long long time, except they were often no longer tested.

So basically we have 3 major backlight control methods:

1. native GPU backlight control, which sometimes does not work
on older laptops because the backlight is connected to the EC
rather then the GPU there, yet often still enabled in the
video-bios-tables so the GPU drivers will still try to use it.

2. ACPI -> known to be always present on recent Windows laptops
because mandated by the hardware certification requirements
(even on Windows 8+), but regularly broken on Windows 8+ because
their backlight control was moved from the core-os to the GPU
drivers and those typically use the native method.

3. Vendor specific EC/smbios/ACPI/WMI interfaces which work
on older laptops, but are often present on newer laptops
despite them no longer working and to get working backlight
control either 1. or 2. should be used.

So basically non of the 3 main backlight control methods can
be trusted even if they are present. Which is why need to have
a combination of heuristics + quirks.

And I have been working on moving all this into a central
place in drivers/acpi/video_detect.c because having
the heuristics + quirks spread out all over the place does
not help.

> The 
> problem you're dealing with is that the knowledge of whether or not 
> there's a vendor interface isn't something the core kernel code knows 
> about. What you're proposing here is effectively for us to expose 
> additional information about whether or not there's a vendor interface 
> in the system firmware, but since we're talking in some cases about 
> hardware that's almost 20 years old, we're not realistically going to 
> get those old machines fixed.

I don't understand why you keep talking about the old vendor interfaces,
at least for the chromebook part of this thread the issue is that
the i915 driver no longer registers the intel_backlight device which
is a native device type, which is caused by the patch this email
thread is about (and old vendor interfaces do not come into play
at all here). So AFAICT this is a native vs acpi backlight control
issue ?

I rea

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi,

On 10/25/22 22:40, Matthew Garrett wrote:
> On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote:
> 
>> Having the native driver come and then go and be replaced
>> with the vendor driver would also be quite inconvenient
>> for these planned changes.
> 
> I understand that it would be inconvenient, but you've broken existing 
> working setups.

I fully acknowledge that I have broken existing working setups
and I definitely want to see this fixed before say 6.1-rc6!

I'm not convinced (at all) that any solutions which re-introduce
acpi_video_get_backlight_type() return-s value changing
half way the boot, with some backlight interface getting
registered and then unregistered again later because
it turns out to be the wrong one is a good fix here.

The whole goal of the refactor was to leave these sorts
of shenanigans behind us.

>> Can you perhaps explain a bit in what way your laptop
>> is weird ?
> 
> It's a Chinese replacement motherboard for a Thinkpad X201, running my 
> own port of Coreboot. Its DMI strings look like an actual Thinkpad in 
> order to ensure that thinkpad_acpi can bind for hotkey suport, so it's 
> hard to quirk. It'll actually be fixed by your proposed patch to fall 
> back to native rather than vendor, but that patch will break any older 
> machines that offer a vendor interface and don't have the native control 
> hooked up (pretty sure at least the Thinkpad X40 falls into that 
> category).

So looking at:

https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/51nb/x210/acpi/graphics.asl

this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
drivers/acpi/scan.c:

static acpi_status
acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
  void **return_value)
{
long *cap = context;

if (acpi_has_method(handle, "_BCM") &&
acpi_has_method(handle, "_BCL")) {
acpi_handle_debug(handle, "Found generic backlight support\n");
*cap |= ACPI_VIDEO_BACKLIGHT;
/* We have backlight support, no need to scan further */
return AE_CTRL_TERMINATE;
}
return 0;
}

What does seem to be missing compared to a "normal" DSDT
is a call to _OSI("Windows 2012") so I would expect this code
in acpi_video_get_backlight_type():

/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
 * Windows 8 and newer no longer use the ACPI video interface,
 * so it often does not work. If the ACPI tables are written
 * for win8 and native brightness ctl is available, use that.
 *
 * The native check deliberately is inside the if acpi-video
 * block on older devices without acpi-video support native
 * is usually not the best choice.
 */
if (acpi_osi_is_win8() && native_available)
return acpi_backlight_native;
else
return acpi_backlight_video;
}

To enter the "return acpi_backlight_video" path since acpi_osi_is_win8()
will return false.

And then the ACPI backlight methods from:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/51nb/x210/acpi/graphics.asl

should get called when changing the backlight brightness,
so assuming that those methods work then things should work fine.

What does "ls /sys/class/backlight" output on the X210 / NB51 board
with a 6.0 kernel? And what does it output with the 6.1-rc? kernels?

IOW which backlight device / control method is being selected
and which one do you want / which one(s) do actually work?

I have been thinking about maybe doing something with 
a dmi_get_bios_year() check (see below), but that will cause
native to get prefered over vendor on old ThinkPads with
coreboot (and thus a new enough year in DMI_BIOS_DATE), which
will likely break backlight control there (if i915 offers
backlight control on those that is).

Also I wonder if it would be possible to set DMI_BIOS_VENDOR
to "Coreboot" so that we can use that? Note that thinkpad_acpi
does not care about the DMI_BIOS_VENDOR value, at least
not on models which start their DMI_PRODUCT_VERSION with
either "ThinkPad" or "Lenovo".

###

Looking more at this I notice that coreboot has a
drivers_intel_gma_displays_ssdt_generate() which seems to
at least always generate ACPI video bus ASL including
backlight control bits.

So the only reason why the current heurstics are not
returning native is the acpi_osi_is_win8() check.

So maybe that beeds to become:

if ((acpi_osi_is_win8() || dmi_get_bios_year() &

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi (again),

On 10/25/22 22:25, Hans de Goede wrote:
> Hi Matthew,
> 
> On 10/25/22 21:32, Matthew Garrett wrote:
>> On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote:
>>
>>> That is a valid point, but keep in mind that this is only used on ACPI
>>> platforms and then only on devices with a builtin LCD panel and then
>>> only by GPU drivers which actually call acpi_video_get_backlight_type(),
>>> so e.g. not by all the ARM specific display drivers.
>>>
>>> So I believe that Chromebooks quite likely are the only devices with
>>> this issue.
>>
>> My laptop is, uh, weird, but it falls into this category.
>>  
>>>> I think for this to work correctly you need to have 
>>>> the infrastructure be aware of whether or not a vendor interface exists, 
>>>> which means having to handle cleanup if a vendor-specific module gets 
>>>> loaded later.
>>>
>>> Getting rid of the whole ping-ponging of which backlight drivers
>>> get loaded during boot was actually one of the goals of the rework
>>> which landed in 6.1 this actually allowed us to remove some quirks
>>> because some hw/firmware did not like us changing our mind and
>>> switching backlight interfaces after first poking another one.
>>> So we definitely don't want to go back to the ping-pong thing.
>>
>> Defaulting to native but then having a vendor driver be able to disable 
>> native drivers seems easiest? It shouldn't be a regression over the 
>> previous state of affairs since both drivers were being loaded already.
> 
> Part of the reason for the ACPI backlight detect refactor is
> because of a planned new backlight uAPI where the brightness
> control becomes a property on the drm connector object, for a
> RFC including the rationale behind this planned uAPI change see:
> https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/
> 
> These plans require that there is only 1 backlight device
> registered (per panel).
> 
> Having the native driver come and then go and be replaced
> with the vendor driver would also be quite inconvenient
> for these planned changes.
> 
> As such I would rather find a solution for your "weird"
> laptop so that acpi_video_get_backlight_type() just always
> returns vendor there.

I just realized that your have vendor driver unregister
the native one is suggested as an alternative for
the new behavior where the i915 driver no longer
registers its native backlight in cases where
acpi_video_get_backlight_type() does not return native,
and that you probably actually want the native backlight
device, right ?

So the above should read:

"so that acpi_video_get_backlight_type() just always
returns native there."

> Note that drivers/acpi/video_detect.c already has a DMI
> quirk tables for models where the heuristics from
> acpi_video_get_backlight_type() don't work. In general
> we (mostly me) try to make it so that the heuristics
> work on most models, to avoid needing to add every model
> under the sun to the DMI quirk table, but if your laptop
> is somehow special then adding a DMI quirk for it should
> be fine ?
> 
> Can you perhaps explain a bit in what way your laptop
> is weird ?

I guess it is weird in that it does not have the ACPI video,
or at least does not offer ACPI video bus backlight control
in its ACPI tables?

Can you perhaps email me an acpidump of the laptop ?

> Note that technically if the native backlight does not work,
> then the GPU driver really should not even try to register
> it. But sometimes the video-bios-tables claim the backlight
> pwm input is attached to the GPU while it is not and things
> have evolved in such a way that the DMI quirks for that
> live in acpi/video_detect.c rather then in the GPU driver.

And this bit can be ignored then because it certainly
is not relevant if you actually want the native driver.

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi Matthew,

On 10/25/22 21:32, Matthew Garrett wrote:
> On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote:
> 
>> That is a valid point, but keep in mind that this is only used on ACPI
>> platforms and then only on devices with a builtin LCD panel and then
>> only by GPU drivers which actually call acpi_video_get_backlight_type(),
>> so e.g. not by all the ARM specific display drivers.
>>
>> So I believe that Chromebooks quite likely are the only devices with
>> this issue.
> 
> My laptop is, uh, weird, but it falls into this category.
>  
>>> I think for this to work correctly you need to have 
>>> the infrastructure be aware of whether or not a vendor interface exists, 
>>> which means having to handle cleanup if a vendor-specific module gets 
>>> loaded later.
>>
>> Getting rid of the whole ping-ponging of which backlight drivers
>> get loaded during boot was actually one of the goals of the rework
>> which landed in 6.1 this actually allowed us to remove some quirks
>> because some hw/firmware did not like us changing our mind and
>> switching backlight interfaces after first poking another one.
>> So we definitely don't want to go back to the ping-pong thing.
> 
> Defaulting to native but then having a vendor driver be able to disable 
> native drivers seems easiest? It shouldn't be a regression over the 
> previous state of affairs since both drivers were being loaded already.

Part of the reason for the ACPI backlight detect refactor is
because of a planned new backlight uAPI where the brightness
control becomes a property on the drm connector object, for a
RFC including the rationale behind this planned uAPI change see:
https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/

These plans require that there is only 1 backlight device
registered (per panel).

Having the native driver come and then go and be replaced
with the vendor driver would also be quite inconvenient
for these planned changes.

As such I would rather find a solution for your "weird"
laptop so that acpi_video_get_backlight_type() just always
returns vendor there.

Note that drivers/acpi/video_detect.c already has a DMI
quirk tables for models where the heuristics from
acpi_video_get_backlight_type() don't work. In general
we (mostly me) try to make it so that the heuristics
work on most models, to avoid needing to add every model
under the sun to the DMI quirk table, but if your laptop
is somehow special then adding a DMI quirk for it should
be fine ?

Can you perhaps explain a bit in what way your laptop
is weird ?

Note that technically if the native backlight does not work,
then the GPU driver really should not even try to register
it. But sometimes the video-bios-tables claim the backlight
pwm input is attached to the GPU while it is not and things
have evolved in such a way that the DMI quirks for that
live in acpi/video_detect.c rather then in the GPU driver.

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi,

On 10/24/22 22:30, Matthew Garrett wrote:
> On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote:
> 
>> So to fix this we need to make acpi_video_get_backlight_type()
>> return native on the Acer Chromebook Spin 713.
> 
> Isn't the issue broader than that? Unless the platform is Windows 8 or 
> later, we'll *always* (outside of some corner cases) return 
> acpi_backlight_vendor if there's no ACPI video interface. This is broken 
> for any platform that implements ACPI but relies on native video 
> control, which is going to include a range of Coreboot platforms, not 
> just Chromebooks.

That is a valid point, but keep in mind that this is only used on ACPI
platforms and then only on devices with a builtin LCD panel and then
only by GPU drivers which actually call acpi_video_get_backlight_type(),
so e.g. not by all the ARM specific display drivers.

So I believe that Chromebooks quite likely are the only devices with
this issue.

We could do something like the patch which I have pasted at the end
of this email, but as its commit message notes there is a real
good chance this will cause regressions on some laptops.

So if we ever decide to go with something like the patch below,
I think we should at a minimum wait for the next cycle with that,
because 6.1 already significantly reworks the ACPI backlight
detect handling and I don't want to throw this into the mix
on top of those changes.

> I think for this to work correctly you need to have 
> the infrastructure be aware of whether or not a vendor interface exists, 
> which means having to handle cleanup if a vendor-specific module gets 
> loaded later.

Getting rid of the whole ping-ponging of which backlight drivers
get loaded during boot was actually one of the goals of the rework
which landed in 6.1 this actually allowed us to remove some quirks
because some hw/firmware did not like us changing our mind and
switching backlight interfaces after first poking another one.
So we definitely don't want to go back to the ping-pong thing.

Regards,

Hans



>From 67ee5d7163e33e65dca06887befd0639b0345883 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Tue, 25 Oct 2022 20:38:56 +0200
Subject: [PATCH] ACPI: video: Simplify __acpi_video_get_backlight_type()

Simplify __acpi_video_get_backlight_type() removing a nested if which
makes the flow harder to follow.

Note this will cause a behavior change on devices which do not have
ACPI video support but do have both a vendor and native backlight
driver available. This change will cause these devices to switch
from vendor to native.

This may not be desirable in all cases, this is likely to happen
on significantly older laptops, where there very well might be
cases where the native driver does not work because the backlight is
controlled by the EC.

This removes the need for the special handling of Chromebooks,
these will now hit the if (native_available) return acpi_backlight_native;
path.

Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 36 +++-
 1 file changed, 11 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 9cd8797d12bb..9bd85b159e02 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -668,11 +668,6 @@ 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.
@@ -718,30 +713,21 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
if (apple_gmux_present())
return acpi_backlight_apple_gmux;
 
-   /* On systems with ACPI video use either native or ACPI video. */
-   if (video_caps & ACPI_VIDEO_BACKLIGHT) {
-   /*
-* Windows 8 and newer no longer use the ACPI video interface,
-* so it often does not work. If the ACPI tables are written
-* for win8 and native brightness ctl is available, use that.
-*
-* The native check deliberately is inside the if acpi-video
-* block on older devices without acpi-video support native
-* is usually not the best choice.
-*/
-   if (acpi_osi_is_win8() && native_available)
-   return acpi_backlight_native;
-   else
-   return acpi_backlight_video;
-   }
-
/*
-* Chromebooks that don't have backlight handle in ACPI table
-* are supposed to use native backlight if it's available.
+* Pre Windows 8, Windows uses ACPI video, so prefer that over native
+* on pre-win8 systems (Windows 8+ no longer uses ACPI 

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

[Hans de Goede]

Hi,

On 10/24/22 16:31, Akihiko Odaki wrote:
> On 2022/10/24 23:06, Akihiko Odaki wrote:
>> On 2022/10/24 22:21, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 10/24/22 14:58, Akihiko Odaki wrote:
>>>> On 2022/10/24 20:53, Hans de Goede wrote:
>>>>> Hi Akihiko,
>>>>>
>>>>> On 10/24/22 13:34, Akihiko Odaki wrote:
>>>>>> Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native()
>>>>>> helper") and following commits made native backlight unavailable if
>>>>>> CONFIG_ACPI_VIDEO is set and the backlight feature of ACPI video is
>>>>>> unavailable, which broke the backlight functionality on Lenovo ThinkPad
>>>>>> C13 Yoga Chromebook. Allow to fall back to native backlight in such
>>>>>> cases.
>>>>>
>>>>> I appreciate your work on this, but what this in essence does is
>>>>> it allows 2 backlight drivers (vendor + native) to get registered
>>>>> for the same panel again. While the whole goal of the backlight refactor
>>>>> series landing in 6.1 was to make it so that there always is only
>>>>> *1* backlight device registered instead of (possibly) registering
>>>>> multiple and letting userspace figure it out. It is also important
>>>>> to only always have 1 backlight device per panel for further
>>>>> upcoming changes.
>>>>>
>>>>> So nack for this solution, sorry.
>>>>>
>>>>> I am aware that this breaks backlight control on some Chromebooks,
>>>>> this was already reported and I wrote a long reply explaining why
>>>>> things are done the way they are done now and also suggesting
>>>>> 2 possible (much simpler) fixes, see:
>>>>> https://lore.kernel.org/linux-acpi/42a5f2c9-a1dc-8fc0-7334-fe6c390ec...@redhat.com/
>>>>>
>>>>> Unfortunately the reported has not followed-up on this and
>>>>> I don't have the hardware to test this myself.
>>>>>
>>>>> Can you please try implementing 1 of the fixes suggested there
>>>>> and then submit that upstream ?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>>>
>>>>
>>>> Hi Hans,
>>>>
>>>> Thanks for reviewing and letting me know the prior attempt.
>>>>
>>>> In this case, there is only a native backlight device and no vendor 
>>>> backlight device so the duplication of backlight devices does not happen. 
>>>> I think it is better to handle such a case without quirks.
>>>
>>> Adding a single heuristic for all chromebooks is something completely 
>>> different
>>> then adding per model quirks which indeed ideally should be avoided (but 
>>> this
>>> is not always possible).
>>>
>>>> I understand it is still questionable to cover the case by allowing 
>>>> duplication when both of a vendor backlight device and native one. To 
>>>> explain my understanding and reasoning for *not* trying to apply the 
>>>> de-duplication rule to the vendor/native combination, let me first 
>>>> describe that the de-duplication which happens in 
>>>> acpi_video_get_backlight_type() is a heuristics and limited.
>>>>
>>>> As the background of acpi_video_get_backlight_type(), there is an 
>>>> assumption that it should be common that both of the firmware, 
>>>> implementing ACPI, and the kernel have code to drive backlight. In the 
>>>> case, the more reliable one should be picked instead of using both, and 
>>>> that is what the statements in `if (video_caps & ACPI_VIDEO_BACKLIGHT)` 
>>>> does.
>>>>
>>>> However, the method has two limitations:
>>>> 1. It does not cover the case where two backlight devices with the same 
>>>> type exist.
>>>
>>> This only happens when there are 2 panels; or 2 gpus driving a single panel
>>> which are both special cases where we actually want 2 backlight devices.
>>>
>>>> 2. The underlying assumption does not apply to vendor/native combination.
>>>>
>>>> Regarding the second limitation, I don't even understand the difference 
>>>> between vendor and native. My guess is that a vendor backlight device uses 
>>>> vendor-specific ACPI interface, and a native one directly uses hardware 
>>&

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

[Hans de Goede]

Hi,

On 10/24/22 15:14, Pali Rohár wrote:
> On Monday 24 October 2022 21:58:57 Akihiko Odaki wrote:
>> Regarding the second limitation, I don't even understand the difference
>> between vendor and native. My guess is that a vendor backlight device uses
>> vendor-specific ACPI interface, and a native one directly uses hardware
>> registers. If my guess is correct, the difference between vendor and native
>> does not imply that both of them are likely to exist at the same time. As
>> the conclusion, there is no more motivation to try to de-duplicate the
>> vendor/native combination than to try to de-duplicate combination of devices
>> with a single type.
> 
> Hello! I just want to point one thing. On some Dell laptops there are
> 3 different ways (= 3 different APIs) how to control display backlight.
> There is ACPI driver (uses ACPI), GPU/DRM driver (i915.ko; uses directly
> HW) and platform vendor driver (dell-laptop.ko; uses vendor BIOS or
> firmware API).

Right and that is just one example of laptops which can register both
vendor + native backlight devices, which is why this whole series is
a bad idea.

Regards,

Hans



> Just every driver has different pre-calculated scaling
> values. So sometimes user wants to choose different driver just because
> it allows to set backlight level with "better" granularity. Registering
> all 3 device drivers is bad as user does not want to see 3 display
> panels and forcing registration of specific one without runtime option
> is also bad (some of those drivers do not have to be suitable or has
> worse granularity as other).

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

[Hans de Goede]

Hi,

On 10/24/22 14:58, Akihiko Odaki wrote:
> On 2022/10/24 20:53, Hans de Goede wrote:
>> Hi Akihiko,
>>
>> On 10/24/22 13:34, Akihiko Odaki wrote:
>>> Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native()
>>> helper") and following commits made native backlight unavailable if
>>> CONFIG_ACPI_VIDEO is set and the backlight feature of ACPI video is
>>> unavailable, which broke the backlight functionality on Lenovo ThinkPad
>>> C13 Yoga Chromebook. Allow to fall back to native backlight in such
>>> cases.
>>
>> I appreciate your work on this, but what this in essence does is
>> it allows 2 backlight drivers (vendor + native) to get registered
>> for the same panel again. While the whole goal of the backlight refactor
>> series landing in 6.1 was to make it so that there always is only
>> *1* backlight device registered instead of (possibly) registering
>> multiple and letting userspace figure it out. It is also important
>> to only always have 1 backlight device per panel for further
>> upcoming changes.
>>
>> So nack for this solution, sorry.
>>
>> I am aware that this breaks backlight control on some Chromebooks,
>> this was already reported and I wrote a long reply explaining why
>> things are done the way they are done now and also suggesting
>> 2 possible (much simpler) fixes, see:
>> https://lore.kernel.org/linux-acpi/42a5f2c9-a1dc-8fc0-7334-fe6c390ec...@redhat.com/
>>
>> Unfortunately the reported has not followed-up on this and
>> I don't have the hardware to test this myself.
>>
>> Can you please try implementing 1 of the fixes suggested there
>> and then submit that upstream ?
>>
>> Regards,
>>
>> Hans
>>
> 
> Hi Hans,
> 
> Thanks for reviewing and letting me know the prior attempt.
> 
> In this case, there is only a native backlight device and no vendor backlight 
> device so the duplication of backlight devices does not happen. I think it is 
> better to handle such a case without quirks.

Adding a single heuristic for all chromebooks is something completely different
then adding per model quirks which indeed ideally should be avoided (but this
is not always possible).

> I understand it is still questionable to cover the case by allowing 
> duplication when both of a vendor backlight device and native one. To explain 
> my understanding and reasoning for *not* trying to apply the de-duplication 
> rule to the vendor/native combination, let me first describe that the 
> de-duplication which happens in acpi_video_get_backlight_type() is a 
> heuristics and limited.
> 
> As the background of acpi_video_get_backlight_type(), there is an assumption 
> that it should be common that both of the firmware, implementing ACPI, and 
> the kernel have code to drive backlight. In the case, the more reliable one 
> should be picked instead of using both, and that is what the statements in 
> `if (video_caps & ACPI_VIDEO_BACKLIGHT)` does.
> 
> However, the method has two limitations:
> 1. It does not cover the case where two backlight devices with the same type 
> exist.

This only happens when there are 2 panels; or 2 gpus driving a single panel
which are both special cases where we actually want 2 backlight devices.

> 2. The underlying assumption does not apply to vendor/native combination.
> 
> Regarding the second limitation, I don't even understand the difference 
> between vendor and native. My guess is that a vendor backlight device uses 
> vendor-specific ACPI interface, and a native one directly uses hardware 
> registers. If my guess is correct, the difference between vendor and native 
> does not imply that both of them are likely to exist at the same time. As the 
> conclusion, there is no more motivation to try to de-duplicate the 
> vendor/native combination than to try to de-duplicate combination of devices 
> with a single type.
> 
> Of course, it is better if we could also avoid registering two devices with 
> one type for one physical device. Possibly we can do so by providing a 
> parameter to indicate that it is for the same "internal" backlight to 
> devm_backlight_device_register(), and let the function check for the 
> duplication. However, this rule may be too restrict, or may have problems I 
> missed.
> 
> Based on the discussion above, we can deduce three possibilities:
> a. There is no reason to distinguish vendor and native in this case, and we 
> can stick to my current proposal.
> b. There is a valid reason to distinguish vendor and native, and we can adopt 
> the same strategy that already adopted for ACPI video/vendor combination.
> c. We can impleme

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

[Hans de Goede]

Hi,

On 10/24/22 13:56, Akihiko Odaki wrote:
> On 2022/10/24 20:48, Jani Nikula wrote:
>> On Mon, 24 Oct 2022, Akihiko Odaki  wrote:
>>> Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native()
>>> helper") and following commits made native backlight unavailable if
>>> CONFIG_ACPI_VIDEO is set and the backlight feature of ACPI video is
>>> unavailable, which broke the backlight functionality on Lenovo ThinkPad
>>> C13 Yoga Chromebook. Allow to fall back to native backlight in such
>>> cases.
>>
>> Where's the bug report with relevant logs, kconfigs, etc?
> 
> I haven't filed one. Should I? Please tell me where to report and what 
> information you would need (to bugzilla.kernel.org with things mentioned in 
> Documentation/admin-guide/reporting-issues.rst?)

As mentioned in my other email this is a known issue, and your effort
to fix this is appreciated very much, but I don't believe your solution
to be the right one.

See: 
https://lore.kernel.org/linux-acpi/42a5f2c9-a1dc-8fc0-7334-fe6c390ec...@redhat.com/
for more details and possible solutions. Please try implementing one of
those solutions for your Chromebook. I unfortunately do not have hw to
test this myself.

Regards,

Hans



> 
> Regards,
> Akihiko Odaki
> 
>>
>> BR,
>> Jani.
>>
>>>
>>> Signed-off-by: Akihiko Odaki 
>>>
>>> Akihiko Odaki (22):
>>>    drm/i915/opregion: Improve backlight request condition
>>>    ACPI: video: Introduce acpi_video_get_backlight_types()
>>>    LoongArch: Use acpi_video_get_backlight_types()
>>>    platform/x86: acer-wmi: Use acpi_video_get_backlight_types()
>>>    platform/x86: asus-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: asus-wmi: Use acpi_video_get_backlight_types()
>>>    platform/x86: compal-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: eeepc-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: fujitsu-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: ideapad-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: msi-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: msi-wmi: Use acpi_video_get_backlight_types()
>>>    platform/x86: nvidia-wmi-ec-backlight: Use
>>>  acpi_video_get_backlight_types()
>>>    platform/x86: panasonic-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: samsung-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: sony-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: thinkpad_acpi: Use acpi_video_get_backlight_types()
>>>    platform/x86: toshiba_acpi: Use acpi_video_get_backlight_types()
>>>    platform/x86: dell-laptop: Use acpi_video_get_backlight_types()
>>>    platform/x86: intel_oaktrail: Use acpi_video_get_backlight_types()
>>>    ACPI: video: Remove acpi_video_get_backlight_type()
>>>    ACPI: video: Fallback to native backlight
>>>
>>>   Documentation/gpu/todo.rst    |  8 +--
>>>   drivers/acpi/acpi_video.c |  2 +-
>>>   drivers/acpi/video_detect.c   | 54 ++-
>>>   drivers/gpu/drm/i915/display/intel_opregion.c |  3 +-
>>>   drivers/platform/loongarch/loongson-laptop.c  |  4 +-
>>>   drivers/platform/x86/acer-wmi.c   |  2 +-
>>>   drivers/platform/x86/asus-laptop.c    |  2 +-
>>>   drivers/platform/x86/asus-wmi.c   |  4 +-
>>>   drivers/platform/x86/compal-laptop.c  |  2 +-
>>>   drivers/platform/x86/dell/dell-laptop.c   |  2 +-
>>>   drivers/platform/x86/eeepc-laptop.c   |  2 +-
>>>   drivers/platform/x86/fujitsu-laptop.c |  4 +-
>>>   drivers/platform/x86/ideapad-laptop.c |  2 +-
>>>   drivers/platform/x86/intel/oaktrail.c |  2 +-
>>>   drivers/platform/x86/msi-laptop.c |  2 +-
>>>   drivers/platform/x86/msi-wmi.c    |  2 +-
>>>   .../platform/x86/nvidia-wmi-ec-backlight.c    |  2 +-
>>>   drivers/platform/x86/panasonic-laptop.c   |  2 +-
>>>   drivers/platform/x86/samsung-laptop.c |  2 +-
>>>   drivers/platform/x86/sony-laptop.c    |  2 +-
>>>   drivers/platform/x86/thinkpad_acpi.c  |  4 +-
>>>   drivers/platform/x86/toshiba_acpi.c   |  2 +-
>>>   drivers/video/backlight/backlight.c   | 18 +++
>>>   include/acpi/video.h  | 21 
>>>   include/linux/backlight.h |  1 +
>>>   25 files changed, 85 insertions(+), 66 deletions(-)
>>
> 

Re: [Intel-gfx] [PATCH 00/22] Fallback to native backlight

[Hans de Goede]

Hi Akihiko,

On 10/24/22 13:34, Akihiko Odaki wrote:
> Commit 2600bfa3df99 ("ACPI: video: Add acpi_video_backlight_use_native()
> helper") and following commits made native backlight unavailable if
> CONFIG_ACPI_VIDEO is set and the backlight feature of ACPI video is
> unavailable, which broke the backlight functionality on Lenovo ThinkPad
> C13 Yoga Chromebook. Allow to fall back to native backlight in such
> cases.

I appreciate your work on this, but what this in essence does is
it allows 2 backlight drivers (vendor + native) to get registered
for the same panel again. While the whole goal of the backlight refactor
series landing in 6.1 was to make it so that there always is only
*1* backlight device registered instead of (possibly) registering
multiple and letting userspace figure it out. It is also important
to only always have 1 backlight device per panel for further
upcoming changes.

So nack for this solution, sorry.

I am aware that this breaks backlight control on some Chromebooks,
this was already reported and I wrote a long reply explaining why
things are done the way they are done now and also suggesting
2 possible (much simpler) fixes, see:
https://lore.kernel.org/linux-acpi/42a5f2c9-a1dc-8fc0-7334-fe6c390ec...@redhat.com/

Unfortunately the reported has not followed-up on this and
I don't have the hardware to test this myself.

Can you please try implementing 1 of the fixes suggested there
and then submit that upstream ?

Regards,

Hans









> 
> Signed-off-by: Akihiko Odaki 
> 
> Akihiko Odaki (22):
>   drm/i915/opregion: Improve backlight request condition
>   ACPI: video: Introduce acpi_video_get_backlight_types()
>   LoongArch: Use acpi_video_get_backlight_types()
>   platform/x86: acer-wmi: Use acpi_video_get_backlight_types()
>   platform/x86: asus-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: asus-wmi: Use acpi_video_get_backlight_types()
>   platform/x86: compal-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: eeepc-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: fujitsu-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: ideapad-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: msi-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: msi-wmi: Use acpi_video_get_backlight_types()
>   platform/x86: nvidia-wmi-ec-backlight: Use
> acpi_video_get_backlight_types()
>   platform/x86: panasonic-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: samsung-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: sony-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: thinkpad_acpi: Use acpi_video_get_backlight_types()
>   platform/x86: toshiba_acpi: Use acpi_video_get_backlight_types()
>   platform/x86: dell-laptop: Use acpi_video_get_backlight_types()
>   platform/x86: intel_oaktrail: Use acpi_video_get_backlight_types()
>   ACPI: video: Remove acpi_video_get_backlight_type()
>   ACPI: video: Fallback to native backlight
> 
>  Documentation/gpu/todo.rst|  8 +--
>  drivers/acpi/acpi_video.c |  2 +-
>  drivers/acpi/video_detect.c   | 54 ++-
>  drivers/gpu/drm/i915/display/intel_opregion.c |  3 +-
>  drivers/platform/loongarch/loongson-laptop.c  |  4 +-
>  drivers/platform/x86/acer-wmi.c   |  2 +-
>  drivers/platform/x86/asus-laptop.c|  2 +-
>  drivers/platform/x86/asus-wmi.c   |  4 +-
>  drivers/platform/x86/compal-laptop.c  |  2 +-
>  drivers/platform/x86/dell/dell-laptop.c   |  2 +-
>  drivers/platform/x86/eeepc-laptop.c   |  2 +-
>  drivers/platform/x86/fujitsu-laptop.c |  4 +-
>  drivers/platform/x86/ideapad-laptop.c |  2 +-
>  drivers/platform/x86/intel/oaktrail.c |  2 +-
>  drivers/platform/x86/msi-laptop.c |  2 +-
>  drivers/platform/x86/msi-wmi.c|  2 +-
>  .../platform/x86/nvidia-wmi-ec-backlight.c|  2 +-
>  drivers/platform/x86/panasonic-laptop.c   |  2 +-
>  drivers/platform/x86/samsung-laptop.c |  2 +-
>  drivers/platform/x86/sony-laptop.c|  2 +-
>  drivers/platform/x86/thinkpad_acpi.c  |  4 +-
>  drivers/platform/x86/toshiba_acpi.c   |  2 +-
>  drivers/video/backlight/backlight.c   | 18 +++
>  include/acpi/video.h  | 21 
>  include/linux/backlight.h |  1 +
>  25 files changed, 85 insertions(+), 66 deletions(-)
> 

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

[Hans de Goede]

Hi,

On 10/17/22 15:35, Jani Nikula wrote:
> On Mon, 17 Oct 2022, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/17/22 13:19, Thorsten Leemhuis wrote:
>>> CCing the regression mailing list, as it should be in the loop for all
>>> regressions, as explained here:
>>> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
>>
>> Yes sorry about that I meant to Cc the regressions list, not you personally,
>> but the auto-completion picked the wrong address-book entry
>> (and I did not notice this).
>>
>>> On 17.10.22 12:48, Hans de Goede wrote:
>>>> On 10/17/22 10:39, Jani Nikula wrote:
>>>>> On Mon, 17 Oct 2022, Jani Nikula  wrote:
>>>>>> On Thu, 13 Oct 2022, Hans de Goede  wrote:
>>>>>>> With 6.0 the following WARN triggers:
>>>>>>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>>>>>>
>>>>>>> drm_WARN(>drm, min_size == 0,
>>>>>>>  "Block %d min_size is zero\n", section_id);
>>>>>>
>>>>>> What's the value of section_id that gets printed?
>>>>>
>>>>> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
>>>>> Use hardcoded fp_timing size for generating LFP data pointers") in
>>>>> v6.1-rc1.
>>>>>
>>>>> I don't think this is the root cause for your issues, but I wonder if
>>>>> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
>>>>> already too?
>>>>
>>>> 6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
>>>> reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
>>>> crashed during boot (but not always).
>>>>
>>>> Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?
>>
>> So I have been trying 6.0.0 with d3a7051841f0 doing a whole bunch of
>> reboots + general use and that seems stable, then I reverted it and
>> the very first boot of the kernel with that broke again, so I'm
>> pretty sure that d3a7051841f0 fixes things.
>>
>> So d3a7051841f0 seems to do more then just fix the WARN().
> 
> Wow, so I guess we do screw up the parsing royally then. :o

I'm running the kernel with lockdep + list-debugging enabled and
I could not reproduce this (not easily at least) on a standard
Fedora 6.0.0 build without that. So maybe the parsing just manages
to write out of binds a tiny bit which just happens to hit a list_head
somewhere ... ?

Either way things look stable with d3a7051841f0 and it turns out
that Fedora already had that cherry-picked downstream in the
5.19.13 kernel which was stable for me too.

>> So lets try to get d3a7051841f0 added to the official stable series
>> ASAP (I just noticed that Mark Pearson from Lenovo has already added it
>> to Fedora's 6.0.2 build.
> 
> I think I'd also pick d3a7051841f0^ i.e. both commits:
> 
> d3a7051841f0 ("drm/i915/bios: Use hardcoded fp_timing size for generating LFP 
> data pointers")
> 4e78d6023c15 ("drm/i915/bios: Validate fp_timing terminator presence")
> 
> for stable.

That sounds good, can you take care of submitting these to gkh ?

Regards,

Hans

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

[Hans de Goede]

Hi,

On 10/17/22 13:19, Thorsten Leemhuis wrote:
> CCing the regression mailing list, as it should be in the loop for all
> regressions, as explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

Yes sorry about that I meant to Cc the regressions list, not you personally,
but the auto-completion picked the wrong address-book entry
(and I did not notice this).

> On 17.10.22 12:48, Hans de Goede wrote:
>> On 10/17/22 10:39, Jani Nikula wrote:
>>> On Mon, 17 Oct 2022, Jani Nikula  wrote:
>>>> On Thu, 13 Oct 2022, Hans de Goede  wrote:
>>>>> With 6.0 the following WARN triggers:
>>>>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>>>>
>>>>> drm_WARN(>drm, min_size == 0,
>>>>>  "Block %d min_size is zero\n", section_id);
>>>>
>>>> What's the value of section_id that gets printed?
>>>
>>> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
>>> Use hardcoded fp_timing size for generating LFP data pointers") in
>>> v6.1-rc1.
>>>
>>> I don't think this is the root cause for your issues, but I wonder if
>>> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
>>> already too?
>>
>> 6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
>> reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
>> crashed during boot (but not always).
>>
>> Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?

So I have been trying 6.0.0 with d3a7051841f0 doing a whole bunch of
reboots + general use and that seems stable, then I reverted it and
the very first boot of the kernel with that broke again, so I'm
pretty sure that d3a7051841f0 fixes things.

So d3a7051841f0 seems to do more then just fix the WARN().

So lets try to get d3a7051841f0 added to the official stable series
ASAP (I just noticed that Mark Pearson from Lenovo has already added it
to Fedora's 6.0.2 build.

Regards,

Hans

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

[Hans de Goede]

Hi,

On 10/17/22 10:39, Jani Nikula wrote:
> On Mon, 17 Oct 2022, Jani Nikula  wrote:
>> On Thu, 13 Oct 2022, Hans de Goede  wrote:
>>> With 6.0 the following WARN triggers:
>>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>>
>>> drm_WARN(>drm, min_size == 0,
>>>  "Block %d min_size is zero\n", section_id);
>>
>> What's the value of section_id that gets printed?
> 
> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
> Use hardcoded fp_timing size for generating LFP data pointers") in
> v6.1-rc1.
> 
> I don't think this is the root cause for your issues, but I wonder if
> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
> already too?

6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
crashed during boot (but not always).

Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?

Any other commits which I can try before I go down the bisect route ?

(I'm assuming this will also affect other users, so we really need
to fix this for 6.0.x before it starts hitting Arch + Fedora users)

Regards,

Hans



> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/6592

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

[Hans de Goede]

Hi,

On 10/17/22 10:30, Jani Nikula wrote:
> On Thu, 13 Oct 2022, Hans de Goede  wrote:
>> With 6.0 the following WARN triggers:
>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>
>> drm_WARN(>drm, min_size == 0,
>>  "Block %d min_size is zero\n", section_id);
> 
> What's the value of section_id that gets printed?

It is 42.

Regards,

Hans

Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

[Hans de Goede]

Hi,

On 10/13/22 22:33, Hans de Goede wrote:
> Hi All,
> 
> Yesterday I got a new Lenovo ThinkPad X1 yoga gen 7 laptop, since I plan
> to make this my new day to day laptop I have copied over the entire
> rootfs, /home, etc. from my current laptop to avoid having to tweak
> everything to my liking again.
> 
> This meant I had an initramfs generated for the other laptop. Which should
> be fine since both are Intel machines and the old 5.19.y initramfs-es
> worked fine. But 6.0.0 crashed with what seems like random memory
> corruption (list integrity checks failing) until I regenerated the initrd ...
> 
> Comparing the old vs regenerated initrds showed no relevant differences,
> which made me think this is a CPU ucode issue (which is pre-fixed
> to the initrd for early microcode loading).
> 
> After some tests I have the following obeservations with 6.0.0:
> 
> 1. The least stable is the old initrd (so with the wrong
> ucode prefixed) this crashes before ever reaching gdm.
> I believe that this is caused by late microcode loading
> kicking in in this case (I though that was being removed?)
> and doing load microcode loading on the i7-1260P with its
> mix of P + E cores seems to seriously mess things up.
> 
> 2. Slightly more stable, lasting at least a few minutes
> before crashing is using dis_ucode_ldr
> 
> 3. Using nomodeset seems to stabilize things even with
> the old initrd with the wrong microcode prefixed
> 
> 4. 5.19, with an old initrd and with normal modesetting
> enabled works fine, so in a way this is a 6.0.0 regression
> 
> 5. Using 6.0 with the new initrd with the new microcode
> seems mostly stable, although sometimes this seems to 
> hang very early during boot, esp. if a previous boot
> crashed and I have not run this for a long time yet.
> 
> 6. After crashes it seems to be necessary to powercycle
> the machine to get things back in working condition.
> 
> 
> With 6.0 the following WARN triggers:
> drivers/gpu/drm/i915/display/intel_bios.c:477:
> 
> drm_WARN(>drm, min_size == 0,
>  "Block %d min_size is zero\n", section_id);
> 
> Since nomodeset helps this might be quite relevant, in 5.19.13
> this does not happen, but I'm not sure if 5.19 has this check
> at all.
> 
> 
> There is a 2022/10/07 BIOS update which includes a CPU microcode
> update available from Lenovo, I have not applied this yet in case
> people want to investigate this further first.

A quick update on this, the microcode being in the initrd or not
seems to be a bit of a red herring. Yesterday the machine crashed
twice at boot with 6.0.0 with an initrd which did correctly have
the alderlake microcode cpio archive prefixed.

Where as with 5.19 it boots correctly everytime. I will try to
make some time to git bisect this sometime next week. I expect
this is an i915 issue though since 6.0.0 with nomodeset on
the cmdline does seem to boot successfully every time.

Regards,

Hans

[Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related

[Hans de Goede]

Hi All,

Yesterday I got a new Lenovo ThinkPad X1 yoga gen 7 laptop, since I plan
to make this my new day to day laptop I have copied over the entire
rootfs, /home, etc. from my current laptop to avoid having to tweak
everything to my liking again.

This meant I had an initramfs generated for the other laptop. Which should
be fine since both are Intel machines and the old 5.19.y initramfs-es
worked fine. But 6.0.0 crashed with what seems like random memory
corruption (list integrity checks failing) until I regenerated the initrd ...

Comparing the old vs regenerated initrds showed no relevant differences,
which made me think this is a CPU ucode issue (which is pre-fixed
to the initrd for early microcode loading).

After some tests I have the following obeservations with 6.0.0:

1. The least stable is the old initrd (so with the wrong
ucode prefixed) this crashes before ever reaching gdm.
I believe that this is caused by late microcode loading
kicking in in this case (I though that was being removed?)
and doing load microcode loading on the i7-1260P with its
mix of P + E cores seems to seriously mess things up.

2. Slightly more stable, lasting at least a few minutes
before crashing is using dis_ucode_ldr

3. Using nomodeset seems to stabilize things even with
the old initrd with the wrong microcode prefixed

4. 5.19, with an old initrd and with normal modesetting
enabled works fine, so in a way this is a 6.0.0 regression

5. Using 6.0 with the new initrd with the new microcode
seems mostly stable, although sometimes this seems to 
hang very early during boot, esp. if a previous boot
crashed and I have not run this for a long time yet.

6. After crashes it seems to be necessary to powercycle
the machine to get things back in working condition.


With 6.0 the following WARN triggers:
drivers/gpu/drm/i915/display/intel_bios.c:477:

drm_WARN(>drm, min_size == 0,
 "Block %d min_size is zero\n", section_id);

Since nomodeset helps this might be quite relevant, in 5.19.13
this does not happen, but I'm not sure if 5.19 has this check
at all.


There is a 2022/10/07 BIOS update which includes a CPU microcode
update available from Lenovo, I have not applied this yet in case
people want to investigate this further first.

Regards,

Hans

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi Dmitry,

On 9/26/22 01:39, Dmitry Osipenko wrote:
> 25.08.2022 17:36, Hans de Goede пишет:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight device and acpi_video's
>> firmware acpi_video# backlight device. This relies on userspace preferring
>> firmware type backlight devices over native ones.
>>
>> Registering 2 backlight devices for a single display really is
>> undesirable, don't register the GPU's native backlight device when
>> another backlight device should be used.
>>
>> Changes in v2:
>> - Use drm_info(drm_dev,  ...) for log messages
>>
>> Reviewed-by: Jani Nikula 
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
>> b/drivers/gpu/drm/i915/display/intel_backlight.c
>> index 681ebcda97ad..03c7966f68d6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
>> @@ -8,6 +8,8 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +
>>  #include "intel_backlight.h"
>>  #include "intel_backlight_regs.h"
>>  #include "intel_connector.h"
>> @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct 
>> intel_connector *connector)
>>  
>>  WARN_ON(panel->backlight.max == 0);
>>  
>> +if (!acpi_video_backlight_use_native()) {
>> +drm_info(>drm, "Skipping intel_backlight registration\n");
>> +return 0;
>> +}
>> +
>>  memset(, 0, sizeof(props));
>>  props.type = BACKLIGHT_RAW;
>>  
> 
> This breaks backlight on Acer Chromebook Spin 713 because backlight
> isn't registered anymore. Any ideas how to fix it?

Thank you for reporting this.

Let me start with some background info on this change:

As you may have noticed sometimes on laptops there are multiple
backlights registered under /sys/class/backlight and we just let
userspace figure out which one to use, which is quite bad.

This patch is part of a series fixing this, this is also preparation
for adding a new display brightness control API where the brightness is
a property on the drm_connector object for the panel/display, which
of course requires the kernel to know which backlight control method
to use.

If you are want to know more about the new userspace API see:
https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/

What this series does is on x86/ACPI platforms make all the possible
/sys/class/backlight providers call: acpi_video_get_backlight_type()
(acpi_video_backlight_use_native() is a special wrapper) and only if
that returns their type then have them register their backlight device.

So to fix this we need to make acpi_video_get_backlight_type()
return native on the Acer Chromebook Spin 713.

The heuristics used in acpi_video_get_backlight_type() is
explained by comments in the function:

/*
 * The below heuristics / detection steps are in order of descending
 * presedence. The commandline takes presedence over anything else.
 */
/* DMI quirks override any autodetection. */
/* Special cases such as nvidia_wmi_ec and apple gmux. */

None of these apply here, so we end up in the core of this function:

/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
 * Windows 8 and newer no longer use the ACPI video interface,
 * so it often does not work. If the ACPI tables are written
 * for win8 and native brightness ctl is available, use that.
 *
 * The native check deliberately is inside the if acpi-video
 * block on older devices without acpi-video support native
 * is usually not the best choice.
 */
if (acpi_osi_is_win8() && native_available)
return acpi_backlight_native;
else
return acpi_backlight_video;
}

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


The acpi_video_backlight_use_native() wrappers causes native_available to
be true, so one or both of these 2 conditions fail:

1.  if (video_caps & ACPI_VIDEO_BACKLIGHT)
2.  if (acpi_osi_is_win8())

I assume that 2. will actually likely fail on quite a few chromebooks.
So to fix this you could do something like this:

diff --git a/drivers/acpi/video_detect.c b/drivers

Re: [Intel-gfx] [GIT PULL] Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86

[Hans de Goede]

Hi,

On 9/14/22 12:29, Maxime Ripard wrote:
> Hi Hans,
> 
> On Mon, Sep 05, 2022 at 10:35:47AM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Now that all patches have been reviewed/acked here is an immutable 
>> backlight-detect-refactor
>> branch with 6.0-rc1 + the v5 patch-set, for merging into the relevant (acpi, 
>> drm-* and pdx86)
>> subsystems.
>>
>> Please pull this branch into the relevant subsystems.
>>
>> I will merge this into the review-hans branch of the pdx86 git tree today and
>> from there it will move to for-next once the builders have successfully 
>> build-tested
>> the merge.
> 
> I merged it into drm-misc-next, thanks!

Great, thank you!

Regards,

Hans

[Intel-gfx] [GIT PULL] Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86

[Hans de Goede]

Hi All,

Now that all patches have been reviewed/acked here is an immutable 
backlight-detect-refactor
branch with 6.0-rc1 + the v5 patch-set, for merging into the relevant (acpi, 
drm-* and pdx86)
subsystems.

Please pull this branch into the relevant subsystems.

I will merge this into the review-hans branch of the pdx86 git tree today and
from there it will move to for-next once the builders have successfully 
build-tested
the merge.

Regards,

Hans


The following changes since commit 568035b01cfb107af8d2e4bd2fb9aea22cf5b868:

  Linux 6.0-rc1 (2022-08-14 15:50:18 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git 
tags/backlight-detect-refactor-1

for you to fetch changes up to 4f96b1bc156e7076f6efedc2a76a8c7e897c7977:

  drm/todo: Add entry about dealing with brightness control on devices with > 1 
panel (2022-09-03 12:17:27 +0200)


Immutable backlight-detect-refactor branch between acpi, drm-* and pdx86

Tag (immutable branch) with v6.0-rc1 + the (acpi/x86) backlight
detect refactor work. For merging into the acpi, drm-* and pdx86
subsystems.

----
Hans de Goede (31):
  ACPI: video: Add acpi_video_backlight_use_native() helper
  drm/i915: Don't register backlight when another backlight should be used 
(v2)
  drm/amdgpu: Don't register backlight when another backlight should be 
used (v3)
  drm/radeon: Don't register backlight when another backlight should be 
used (v3)
  drm/nouveau: Don't register backlight when another backlight should be 
used (v2)
  ACPI: video: Drop backlight_device_get_by_type() call from 
acpi_video_get_backlight_type()
  ACPI: video: Remove acpi_video_bus from list before tearing it down
  ACPI: video: Simplify acpi_video_unregister_backlight()
  ACPI: video: Make backlight class device registration a separate step (v2)
  ACPI: video: Remove code to unregister acpi_video backlight when a native 
backlight registers
  drm/i915: Call acpi_video_register_backlight() (v3)
  drm/nouveau: Register ACPI video backlight when nv_backlight registration 
fails (v2)
  drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight 
registration
  drm/radeon: Register ACPI video backlight when skipping radeon backlight 
registration
  platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a 
header (v2)
  ACPI: video: Refactor acpi_video_get_backlight_type() a bit
  ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
  ACPI: video: Add Apple GMUX brightness control detection
  platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()
  platform/x86: apple-gmux: Stop calling acpi/video.h functions
  platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()
  platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
  platform/x86: asus-wmi: Drop DMI chassis-type check from backlight 
handling
  platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI 
video_detect.c
  platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI 
video_detect.c
  platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks 
to ACPI video_detect.c
  ACPI: video: Remove acpi_video_set_dmi_backlight_type()
  ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
  ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks
  ACPI: video: Fix indentation of video_detect_dmi_table[] entries
  drm/todo: Add entry about dealing with brightness control on devices with 
> 1 panel

 Documentation/gpu/todo.rst |  68 
 MAINTAINERS|   1 +
 drivers/acpi/Kconfig   |   1 +
 drivers/acpi/acpi_video.c  |  64 ++-
 drivers/acpi/video_detect.c| 428 -
 drivers/gpu/drm/Kconfig|  14 +
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c |  14 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |   9 +
 drivers/gpu/drm/gma500/Kconfig |   2 +
 drivers/gpu/drm/i915/Kconfig   |   2 +
 drivers/gpu/drm/i915/display/intel_acpi.c  |  27 ++
 drivers/gpu/drm/i915/display/intel_acpi.h  |   3 +
 drivers/gpu/drm/i915/display/intel_backlight.c |   7 +
 drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  10 +
 drivers/gpu/drm/nouveau/nouveau_acpi.h |   4 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c|  13 +
 drivers/gpu/drm/radeon/atombios_encoders.c |   7 +
 drivers/gpu/drm/radeon/radeon_encoders.c   |  11 +-
 driver

Re: [Intel-gfx] [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

[Hans de Goede]

Hi,

On 8/26/22 00:21, Daniel Dadap wrote:
> On 8/25/22 9:37 AM, Hans de Goede wrote:
>> On some new laptop designs a new Nvidia specific WMI interface is present
>> which gives info about panel brightness control and may allow controlling
>> the brightness through this interface when the embedded controller is used
>> for brightness control.
>>
>> When this WMI interface is present and indicates that the EC is used,
>> then this interface should be used for brightness control.
>>
>> Changes in v2:
>> - Use the new shared nvidia-wmi-ec-backlight.h header for the
>>    WMI firmware API definitions
>> - ACPI_VIDEO can now be enabled on non X86 too,
>>    adjust the Kconfig changes to match this.
>>
>> Changes in v3:
>> - Use WMI_BRIGHTNESS_GUID define
>>
>> Acked-by: Rafael J. Wysocki 
>> Signed-off-by: Hans de Goede 
>> ---
>>   drivers/acpi/Kconfig   |  1 +
>>   drivers/acpi/video_detect.c    | 37 ++
>>   drivers/gpu/drm/gma500/Kconfig |  2 ++
>>   drivers/gpu/drm/i915/Kconfig   |  2 ++
>>   include/acpi/video.h   |  1 +
>>   5 files changed, 43 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 7802d8846a8d..44ad4b6bd234 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>>   tristate "Video"
>>   depends on BACKLIGHT_CLASS_DEVICE
>>   depends on INPUT
>> +    depends on ACPI_WMI || !X86
>>   select THERMAL
>>   help
>>     This driver implements the ACPI Extensions For Display Adapters
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index cc9d0d91e268..4dc7fb865083 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -32,6 +32,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, 
>> void **rv)
>>   return AE_OK;
>>   }
>>   +/* This depends on ACPI_WMI which is X86 only */
>> +#ifdef CONFIG_X86
> 
> 
> This could probably also provide the { return false; } stub which you have 
> for non-x86 if the kernel is built without nvidia-wmi-ec-backight, e.g.:
> 
> #if defined(CONFIG_X86) && (defined(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) || 
> defined(CONFIG_NVIDIA_WMI_EC_BACKLIGHT_MODULE))
> 
> Although I suppose that would break things if somebody has a kernel that 
> originally had NVIDIA_WMI_EC_BACKLIGHT=n in Kconfig, and then builds the 
> nvidia-wmi-ec-backlight driver out-of-tree later. I don't know whether that's 
> intended to be a supported use case, so I guess it is fine either way.

The video-detect code is about detecting what interface should be used.
So far it does this independently of the driver implementing that interface
actually being enabled or not.

If someone has a system which needs the nvidia-wmi-ec-backlight driver,
but it is disabled then they / their distro should enable that driver,
rather then trying to fallback on e.g. acpi_video.

Taking which drivers are enabled into account would both make
the code more complicated and would also explode the test matrix.

All of this is already somewhat fragile, so lets not make it
extra complicated :)

Regards,

Hans



> 
> 
>> +static bool nvidia_wmi_ec_supported(void)
>> +{
>> +    struct wmi_brightness_args args = {
>> +    .mode = WMI_BRIGHTNESS_MODE_GET,
>> +    .val = 0,
>> +    .ret = 0,
>> +    };
>> +    struct acpi_buffer buf = { (acpi_size)sizeof(args),  };
>> +    acpi_status status;
>> +
>> +    status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
>> + WMI_BRIGHTNESS_METHOD_SOURCE, , );
>> +    if (ACPI_FAILURE(status))
>> +    return false;
>> +
>> +    /*
>> + * If brightness is handled by the EC then nvidia-wmi-ec-backlight
>> + * should be used, else the GPU driver(s) should be used.
>> + */
>> +    return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>> +}
>> +#else
>> +static bool nvidia_wmi_ec_supported(void)
>> +{
>> +    return false;
>> +}
>> +#endif
>> +
>>   /* Force to use vendor driver when the ACPI device is known to be
>>    * buggy */
>>   static int video_detect_force_vendor(const struct dmi_system_id *d)
>> @@ -541,6 +572,7 @@ static const struct dmi_system_id 
>> video_detect_dmi_table[] = {
>>   static enum acpi_backligh

[Intel-gfx] [PATCH v5 25/31] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c

[Hans de Goede]

Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c|  8 
 drivers/platform/x86/asus-nb-wmi.c | 14 --
 drivers/platform/x86/asus-wmi.c|  3 ---
 drivers/platform/x86/asus-wmi.h|  1 -
 4 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index d893313fe1a0..a09089e7fada 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -564,6 +564,14 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+   {
+.callback = video_detect_force_native,
+/* Asus UX303UB */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
+   },
+   },
/*
 * Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
 * working native and video interface. However the default detection
diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 810a94557a85..bbfed85051ee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -97,11 +97,6 @@ static struct quirk_entry quirk_asus_x200ca = {
.wmi_backlight_set_devstate = true,
 };
 
-static struct quirk_entry quirk_asus_ux303ub = {
-   .wmi_backlight_native = true,
-   .wmi_backlight_set_devstate = true,
-};
-
 static struct quirk_entry quirk_asus_x550lb = {
.wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
@@ -372,15 +367,6 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = _asus_x200ca,
},
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. UX303UB",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
-   },
-   .driver_data = _asus_ux303ub,
-   },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 5cf9d9aff164..434249ac47a5 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
 
-   if (asus->driver->quirks->wmi_backlight_native)
-   acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
 
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 30770e411301..f30252efe1db 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
-   bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
bool use_kbd_dock_devid;
-- 
2.37.2

[Intel-gfx] [PATCH v5 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries

[Hans de Goede]

The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.

Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.

But over time some entries did not event have the single space
indent in front of the ".name = ..." lines.

Make things consistent by using a single space indent for these
lines everywhere.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 48 ++---
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 789d5913c178..db2474fe58ac 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -142,17 +142,17 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Asus UL30VT */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30VT */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Asus UL30A */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30A */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
@@ -198,9 +198,9 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* GIGABYTE GB-BXBT-2807 */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* GIGABYTE GB-BXBT-2807 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
@@ -233,17 +233,17 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Sony VPCEH3U1E */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Sony VPCEH3U1E */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"),
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Xiaomi Mi Pad 2 */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Xiaomi Mi Pad 2 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
@@ -551,25 +551,25 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA401 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA401 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA502 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA502 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA503 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA503 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
-- 
2.37.2

[Intel-gfx] [PATCH v5 29/31] ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks

[Hans de Goede]

acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.

After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.

So this is no longer an issue an the quirks are no longer needed.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683
Tested-by: Werner Sembach 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 92 +
 1 file changed, 1 insertion(+), 91 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index af2833b57b8b..789d5913c178 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -609,97 +609,7 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
-   /*
-* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
-* working native and video interface. However the default detection
-* mechanism first registers the video interface before unregistering
-* it again and switching to the native interface during boot. This
-* results in a dangling SBIOS request for backlight change for some
-* reason, causing the backlight to switch to ~2% once per boot on the
-* first power cord connect or disconnect event. Setting the native
-* interface explicitly circumvents this buggy behaviour, by avoiding
-* the unregistering process.
-*/
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
-   /*
-* The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 
Gen10,
-* Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the 
Clevo
-* NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description
-* above.
-*/
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5PU1G",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF4NU1F",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF4NU1F",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5NU1G",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5NU1G",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5LUXG",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"),
-   },
-   },
+
/*
 * Desktops which falsely report a backlight and which our heuristics
 * for this do not catch.
-- 
2.37.2

[Intel-gfx] [PATCH v5 26/31] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c

[Hans de Goede]

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to
drivers/acpi/video_detect.c .

Note the X360 -> acpi_backlight=native quirk is not moved because that
already was present in drivers/acpi/video_detect.c .

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c   | 54 +
 drivers/platform/x86/samsung-laptop.c | 87 ---
 2 files changed, 54 insertions(+), 87 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a09089e7fada..3861d4121172 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -222,6 +222,33 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
},
+   {
+.callback = video_detect_force_vendor,
+/* Samsung N150/N210/N220 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
+   DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Samsung NF110/NF210/NF310 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
+   DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Samsung NC210 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"),
+   DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"),
+   },
+   },
{
.callback = video_detect_force_vendor,
/* Sony VPCEH3U1E */
@@ -572,6 +599,33 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
},
},
+   {
+.callback = video_detect_force_native,
+/* Samsung N150P */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
+   DMI_MATCH(DMI_BOARD_NAME, "N150P"),
+   },
+   },
+   {
+.callback = video_detect_force_native,
+/* Samsung N145P/N250P/N260P */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
+   DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
+   },
+   },
+   {
+.callback = video_detect_force_native,
+/* Samsung N250P */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N250P"),
+   DMI_MATCH(DMI_BOARD_NAME, "N250P"),
+   },
+   },
/*
 * Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
 * working native and video interface. However the default detection
diff --git a/drivers/platform/x86/samsung-laptop.c 
b/drivers/platform/x86/samsung-laptop.c
index c187dcdf82f0..cc30cf08f32d 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -356,23 +356,13 @@ struct samsung_laptop {
 };
 
 struct samsung_quirks {
-   bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
-   bool use_native_backlight;
bool lid_handling;
 };
 
 static struct samsung_quirks samsung_unknown = {};
 
-static struct samsung_quirks samsung_broken_acpi_video = {
-   .broken_acpi_video = true,
-};
-
-static struct samsung_quirks samsung_use_native_backlight = {
-   .use_native_backlight = true,
-};
-
 static struct samsung_quirks samsung_np740u3e = {
.four_kbd_backlight_levels = true,
.enable_kbd_backlight = true,
@@ -1540,76 +1530,6 @@ static const struct dmi_system_id samsung_dmi_table[] 
__initconst = {
},
},
/* Specific DMI ids for laptop with quirks */
-   {
-.callback = samsung_dmi_matched,
-.ident = "N150P",
-.matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., L

[Intel-gfx] [PATCH v5 28/31] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk

[Hans de Goede]

acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.

After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.

So this is no longer an issue an the quirk is no longer needed.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 67a0211c07b4..af2833b57b8b 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -132,21 +132,6 @@ static int video_detect_force_none(const struct 
dmi_system_id *d)
 }
 
 static const struct dmi_system_id video_detect_dmi_table[] = {
-   /* On Samsung X360, the BIOS will set a flag (VDRV) if generic
-* ACPI backlight device is used. This flag will definitively break
-* the backlight interface (even the vendor interface) until next
-* reboot. It's why we should prevent video.ko from being used here
-* and we can't rely on a later call to acpi_video_unregister().
-*/
-   {
-.callback = video_detect_force_vendor,
-/* X360 */
-.matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
-   DMI_MATCH(DMI_BOARD_NAME, "X360"),
-   },
-   },
{
 /* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
 .callback = video_detect_force_vendor,
-- 
2.37.2

[Intel-gfx] [PATCH v5 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel

[Hans de Goede]

Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.

The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/

Reviewed-by: Lyude Paul 
Signed-off-by: Hans de Goede 
---
 Documentation/gpu/todo.rst | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7634c27ac562..393d218e4a0c 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -679,6 +679,74 @@ Contact: Sam Ravnborg
 
 Level: Advanced
 
+Brightness handling on devices with multiple internal panels
+
+
+On x86/ACPI devices there can be multiple backlight firmware interfaces:
+(ACPI) video, vendor specific and others. As well as direct/native (PWM)
+register programming by the KMS driver.
+
+To deal with this backlight drivers used on x86/ACPI call
+acpi_video_get_backlight_type() which has heuristics (+quirks) to select
+which backlight interface to use; and backlight drivers which do not match
+the returned type will not register themselves, so that only one backlight
+device gets registered (in a single GPU setup, see below).
+
+At the moment this more or less assumes that there will only
+be 1 (internal) panel on a system.
+
+On systems with 2 panels this may be a problem, depending on
+what interface acpi_video_get_backlight_type() selects:
+
+1. native: in this case the KMS driver is expected to know which backlight
+   device belongs to which output so everything should just work.
+2. video: this does support controlling multiple backlights, but some work
+   will need to be done to get the output <-> backlight device mapping
+
+The above assumes both panels will require the same backlight interface type.
+Things will break on systems with multiple panels where the 2 panels need
+a different type of control. E.g. one panel needs ACPI video backlight control,
+where as the other is using native backlight control. Currently in this case
+only one of the 2 required backlight devices will get registered, based on
+the acpi_video_get_backlight_type() return value.
+
+If this (theoretical) case ever shows up, then supporting this will need some
+work. A possible solution here would be to pass a device and connector-name
+to acpi_video_get_backlight_type() so that it can deal with this.
+
+Note in a way we already have a case where userspace sees 2 panels,
+in dual GPU laptop setups with a mux. On those systems we may see
+either 2 native backlight devices; or 2 native backlight devices.
+
+Userspace already has code to deal with this by detecting if the related
+panel is active (iow which way the mux between the GPU and the panels
+points) and then uses that backlight device. Userspace here very much
+assumes a single panel though. It picks only 1 of the 2 backlight devices
+and then only uses that one.
+
+Note that all userspace code (that I know off) is currently hardcoded
+to assume a single panel.
+
+Before the recent changes to not register multiple (e.g. video + native)
+/sys/class/backlight devices for a single panel (on a single GPU laptop),
+userspace would see multiple backlight devices all controlling the same
+backlight.
+
+To deal with this userspace had to always picks one preferred device under
+/sys/class/backlight and will ignore the others. So to support brightness
+control on multiple panels userspace will need to be updated too.
+
+There are plans to allow brightness control through the KMS API by adding
+a "display brightness" property to drm_connector objects for panels. This
+solves a number of issues with the /sys/class/backlight API, including not
+being able to map a sysfs backlight device to a specific connector. Any
+userspace changes to add support for brightness control on devices with
+multiple panels really should build on top of this new KMS property.
+
+Contact: Hans de Goede
+
+Level: Advanced
+
 Outside DRM
 ===
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 27/31] ACPI: video: Remove acpi_video_set_dmi_backlight_type()

[Hans de Goede]

acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.

All callers have been fixed to no longer call it, so remove
acpi_video_set_dmi_backlight_type() now.

This means we now also no longer need acpi_video_unregister_backlight()
for the remove acpi_video backlight after it was wrongly registered hack,
so remove that too.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c   | 10 --
 drivers/acpi/video_detect.c | 16 
 include/acpi/video.h|  4 
 3 files changed, 30 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index d1e41f30c004..a7c3d11e0dac 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2296,16 +2296,6 @@ void acpi_video_register_backlight(void)
 }
 EXPORT_SYMBOL(acpi_video_register_backlight);
 
-void acpi_video_unregister_backlight(void)
-{
-   struct acpi_video_bus *video;
-
-   mutex_lock(_list_lock);
-   list_for_each_entry(video, _bus_head, entry)
-   acpi_video_bus_unregister_backlight(video);
-   mutex_unlock(_list_lock);
-}
-
 bool acpi_video_handles_brightness_key_presses(void)
 {
return may_report_brightness_keys &&
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 3861d4121172..67a0211c07b4 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,8 +38,6 @@
 #include 
 #include 
 
-void acpi_video_unregister_backlight(void);
-
 static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
 static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
 
@@ -817,17 +815,3 @@ bool acpi_video_backlight_use_native(void)
return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
 }
 EXPORT_SYMBOL(acpi_video_backlight_use_native);
-
-/*
- * Set the preferred backlight interface type based on DMI info.
- * This function allows DMI blacklists to be implemented by external
- * platform drivers instead of putting a big blacklist in video_detect.c
- */
-void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
-{
-   acpi_backlight_dmi = type;
-   /* Remove acpi-video backlight interface if it is no longer desired */
-   if (acpi_video_get_backlight_type() != acpi_backlight_video)
-   acpi_video_unregister_backlight();
-}
-EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
diff --git a/include/acpi/video.h b/include/acpi/video.h
index dbd48cb8bd23..a275c35e5249 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -60,7 +60,6 @@ extern int acpi_video_get_edid(struct acpi_device *device, 
int type,
   int device_id, void **edid);
 extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
 extern bool acpi_video_backlight_use_native(void);
-extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
 /*
  * Note: The value returned by acpi_video_handles_brightness_key_presses()
  * may change over time and should not be cached.
@@ -86,9 +85,6 @@ static inline bool acpi_video_backlight_use_native(void)
 {
return true;
 }
-static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type 
type)
-{
-}
 static inline bool acpi_video_handles_brightness_key_presses(void)
 {
return false;
-- 
2.37.2

[Intel-gfx] [PATCH v5 21/31] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()

[Hans de Goede]

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.

In case of toshiba_acpi there are no DMI quirks to move to
acpi/video_detect.c, but it also (ab)uses it for transflective
displays. Adding transflective display support to video_detect.c would
be quite involved. But luckily there are only 2 known models with
a transflective display, so we can just add DMI quirks for those.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 19 +++
 drivers/platform/x86/toshiba_acpi.c | 16 
 2 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index be2fc43418af..74e2087c8ff0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -190,6 +190,25 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
},
 
+   /*
+* Toshiba models with Transflective display, these need to use
+* the toshiba_acpi vendor driver for proper Transflective handling.
+*/
+   {
+.callback = video_detect_force_vendor,
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R500"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R600"),
+   },
+   },
+
/*
 * These models have a working acpi_video backlight control, and using
 * native backlight causes a regression where backlight does not work
diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 0fc9e8b8827b..030dc37d50b8 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -271,14 +271,6 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
{ KE_END, 0 },
 };
 
-/*
- * List of models which have a broken acpi-video backlight interface and thus
- * need to use the toshiba (vendor) interface instead.
- */
-static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
-   {}
-};
-
 /*
  * Utility
  */
@@ -2881,14 +2873,6 @@ static int toshiba_acpi_setup_backlight(struct 
toshiba_acpi_dev *dev)
return 0;
}
 
-   /*
-* Tell acpi-video-detect code to prefer vendor backlight on all
-* systems with transflective backlight and on dmi matched systems.
-*/
-   if (dev->tr_backlight_supported ||
-   dmi_check_system(toshiba_vendor_backlight_dmi))
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 24/31] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c

[Hans de Goede]

Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c.
This is because the entries using the removed wmi_backlight_power flag
also use other model specific quirks from the asus-wmi quirk_entry struct.
So the quirk_asus_x55u struct and the entries pointing to it cannot be
dropped.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c| 40 ++
 drivers/platform/x86/asus-nb-wmi.c |  7 --
 drivers/platform/x86/asus-wmi.c|  3 ---
 drivers/platform/x86/asus-wmi.h|  1 -
 drivers/platform/x86/eeepc-wmi.c   | 25 +--
 5 files changed, 41 insertions(+), 35 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 6a2523bc02ba..d893313fe1a0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -174,6 +174,46 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
+   {
+.callback = video_detect_force_vendor,
+/* Asus X55U */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X55U"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus X101CH */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus X401U */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X401U"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus X501U */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X501U"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus 1015CX */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"),
+   },
+   },
{
.callback = video_detect_force_vendor,
/* GIGABYTE GB-BXBT-2807 */
diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 478dd300b9c9..810a94557a85 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -79,12 +79,10 @@ static struct quirk_entry quirk_asus_q500a = {
 
 /*
  * For those machines that need software to control bt/wifi status
- * and can't adjust brightness through ACPI interface
  * and have duplicate events(ACPI and WMI) for display toggle
  */
 static struct quirk_entry quirk_asus_x55u = {
.wapf = 4,
-   .wmi_backlight_power = true,
.wmi_backlight_set_devstate = true,
.no_display_toggle = true,
 };
@@ -147,11 +145,6 @@ static const struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "U32U"),
},
-   /*
-* Note this machine has a Brazos APU, and most Brazos Asus
-* machines need quirk_asus_x55u / wmi_backlight_power but
-* here acpi-video seems to work fine for backlight control.
-*/
.driver_data = _asus_wapf4,
},
{
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 301166a5697d..5cf9d9aff164 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
 
-   if (asus->driver->quirks->wmi_backlight_power)
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_native)
acpi_video_set_dmi_backlight_type(acpi_backlight_native);
 
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platfor

[Intel-gfx] [PATCH v5 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling

[Hans de Goede]

Remove this check from the asus-wmi backlight handling:

/* Some Asus desktop boards export an acpi-video backlight interface,
   stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);

This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be
removed because other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:

if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */

So leaving this in place can break things on laptops with a broken
DMI chassis-type, which would have GPU native brightness control before
the addition of the acpi_video_get_backlight_type() != native check.

Removing this should be ok now, since the ACPI video code has improved
heuristics for this itself now (which includes a chassis-type check).

Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/asus-wmi.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 89b604e04d7f..301166a5697d 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3553,7 +3553,6 @@ static int asus_wmi_add(struct platform_device *pdev)
struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver);
struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv);
struct asus_wmi *asus;
-   const char *chassis_type;
acpi_status status;
int err;
u32 result;
@@ -3635,12 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
 
-   /* Some Asus desktop boards export an acpi-video backlight interface,
-  stop this from showing up */
-   chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
-   if (chassis_type && !strcmp(chassis_type, "3"))
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_power)
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 22/31] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c

[Hans de Goede]

Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Note that even though the DMI quirk table name was video_vendor_dmi_table,
5/6 quirks were actually quirks to use the GPU native backlight.

These 5 quirks also had a callback in their dmi_system_id entry which
disabled the acer-wmi vendor driver; and any DMI match resulted in:

acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);

which disabled the acpi_video driver, so only the native driver was left.
The new entries for these 5/6 devices correctly marks these as needing
the native backlight driver.

Also note that other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:

if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */

which without this patch would have broken these 5/6 "special" quirks.

Since I had to look at all the commits adding the quirks anyways, to make
sure that I understood the code correctly, I've also added links to
the various original bugzillas for these quirks to the new entries.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 53 ++
 drivers/platform/x86/acer-wmi.c | 66 -
 2 files changed, 53 insertions(+), 66 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 74e2087c8ff0..6a2523bc02ba 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -149,6 +149,15 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "X360"),
},
},
+   {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
+.callback = video_detect_force_vendor,
+/* Acer KAV80 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
+   },
+   },
{
.callback = video_detect_force_vendor,
/* Asus UL30VT */
@@ -437,6 +446,41 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "JV50"),
},
},
+   {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
+.callback = video_detect_force_native,
+/* Acer Aspire 5741 */
+.matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
+   },
+   },
+   {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
+.callback = video_detect_force_native,
+/* Acer Aspire 5750 */
+.matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
+   },
+   },
+   {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
+.callback = video_detect_force_native,
+/* Acer Extensa 5235 */
+.matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
+   },
+   },
+   {
+.callback = video_detect_force_native,
+/* Acer TravelMate 4750 */
+.matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
+   },
+   },
{
 /* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
 .callback = video_detect_force_native,
@@ -447,6 +491,15 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
},
},
+   {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=36322 */
+.callback = video_detect_force_native,
+/* Acer TravelMate 5760 */
+.matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
+   },
+   },
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA401 */
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index e0230ea0cb7e..b933a5165edb 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -643,69 +643,6 @@ static const struct dmi_system

[Intel-gfx] [PATCH v5 19/31] platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()

[Hans de Goede]

Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.

Since the auto-detect code check for nvidia-wmi-ec-backlight in
drivers/acpi/video_detect.c already checks that the WMI advertised
brightness-source is the embedded controller, this new check makes it
unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself.

Suggested-by: Daniel Dadap 
Reviewed-by: Daniel Dadap 
Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/Kconfig   |  1 +
 drivers/platform/x86/nvidia-wmi-ec-backlight.c | 14 +++---
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index f2f98e942cf2..0cc5ac35fc57 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,6 +93,7 @@ config PEAQ_WMI
 
 config NVIDIA_WMI_EC_BACKLIGHT
tristate "EC Backlight Driver for Hybrid Graphics Notebook Systems"
+   depends on ACPI_VIDEO
depends on ACPI_WMI
depends on BACKLIGHT_CLASS_DEVICE
help
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c 
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index be803e47eac0..baccdf658538 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI 
method
@@ -87,19 +88,10 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device 
*wdev, const void *ct
 {
struct backlight_properties props = {};
struct backlight_device *bdev;
-   u32 source;
int ret;
 
-   ret = wmi_brightness_notify(wdev, WMI_BRIGHTNESS_METHOD_SOURCE,
-  WMI_BRIGHTNESS_MODE_GET, );
-   if (ret)
-   return ret;
-
-   /*
-* This driver is only to be used when brightness control is handled
-* by the EC; otherwise, the GPU driver(s) should control brightness.
-*/
-   if (source != WMI_BRIGHTNESS_SOURCE_EC)
+   /* drivers/acpi/video_detect.c also checks that SOURCE == EC */
+   if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
return -ENODEV;
 
/*
-- 
2.37.2

[Intel-gfx] [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

[Hans de Goede]

On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.

When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.

Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
  WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
  adjust the Kconfig changes to match this.

Changes in v3:
- Use WMI_BRIGHTNESS_GUID define

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/Kconfig   |  1 +
 drivers/acpi/video_detect.c| 37 ++
 drivers/gpu/drm/gma500/Kconfig |  2 ++
 drivers/gpu/drm/i915/Kconfig   |  2 ++
 include/acpi/video.h   |  1 +
 5 files changed, 43 insertions(+)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7802d8846a8d..44ad4b6bd234 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
+   depends on ACPI_WMI || !X86
select THERMAL
help
  This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cc9d0d91e268..4dc7fb865083 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, void 
**rv)
return AE_OK;
 }
 
+/* This depends on ACPI_WMI which is X86 only */
+#ifdef CONFIG_X86
+static bool nvidia_wmi_ec_supported(void)
+{
+   struct wmi_brightness_args args = {
+   .mode = WMI_BRIGHTNESS_MODE_GET,
+   .val = 0,
+   .ret = 0,
+   };
+   struct acpi_buffer buf = { (acpi_size)sizeof(args),  };
+   acpi_status status;
+
+   status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
+WMI_BRIGHTNESS_METHOD_SOURCE, , );
+   if (ACPI_FAILURE(status))
+   return false;
+
+   /*
+* If brightness is handled by the EC then nvidia-wmi-ec-backlight
+* should be used, else the GPU driver(s) should be used.
+*/
+   return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+#else
+static bool nvidia_wmi_ec_supported(void)
+{
+   return false;
+}
+#endif
+
 /* Force to use vendor driver when the ACPI device is known to be
  * buggy */
 static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -541,6 +572,7 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
 static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
 {
static DEFINE_MUTEX(init_mutex);
+   static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -553,6 +585,7 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
_caps, NULL);
+   nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
if (native)
@@ -570,6 +603,10 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
 
+   /* Special cases such as nvidia_wmi_ec and apple gmux. */
+   if (nvidia_wmi_ec_present)
+   return acpi_backlight_nvidia_wmi_ec;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..807b989e3c77 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -7,6 +7,8 @@ config DRM_GMA500
select ACPI_VIDEO if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
+   select X86_PLATFORM_DEVICES if ACPI
+   select ACPI_WMI if ACPI
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7ae3b7d67fcf..3efce05d7b57 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,8 @@ config DRM_I915
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
  

[Intel-gfx] [PATCH v5 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2)

[Hans de Goede]

Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .

Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well

Suggested-by: Daniel Dadap 
Signed-off-by: Hans de Goede 
---
 MAINTAINERS   |  1 +
 .../platform/x86/nvidia-wmi-ec-backlight.c| 68 +
 .../x86/nvidia-wmi-ec-backlight.h | 76 +++
 3 files changed, 78 insertions(+), 67 deletions(-)
 create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d7f64dc0efe..d6f6b96f51f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14527,6 +14527,7 @@ M:  Daniel Dadap 
 L: platform-driver-...@vger.kernel.org
 S: Supported
 F: drivers/platform/x86/nvidia-wmi-ec-backlight.c
+F: include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
 
 NVM EXPRESS DRIVER
 M: Keith Busch 
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c 
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index 61e37194df70..be803e47eac0 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -7,74 +7,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-/**
- * enum wmi_brightness_method - WMI method IDs
- * @WMI_BRIGHTNESS_METHOD_LEVEL:  Get/Set EC brightness level status
- * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
- */
-enum wmi_brightness_method {
-   WMI_BRIGHTNESS_METHOD_LEVEL = 1,
-   WMI_BRIGHTNESS_METHOD_SOURCE = 2,
-   WMI_BRIGHTNESS_METHOD_MAX
-};
-
-/**
- * enum wmi_brightness_mode - Operation mode for WMI-wrapped method
- * @WMI_BRIGHTNESS_MODE_GET:Get the current brightness 
level/source.
- * @WMI_BRIGHTNESS_MODE_SET:Set the brightness level.
- * @WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL:  Get the maximum brightness level. This
- *  is only valid when the WMI method is
- *  %WMI_BRIGHTNESS_METHOD_LEVEL.
- */
-enum wmi_brightness_mode {
-   WMI_BRIGHTNESS_MODE_GET = 0,
-   WMI_BRIGHTNESS_MODE_SET = 1,
-   WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL = 2,
-   WMI_BRIGHTNESS_MODE_MAX
-};
-
-/**
- * enum wmi_brightness_source - Backlight brightness control source selection
- * @WMI_BRIGHTNESS_SOURCE_GPU: Backlight brightness is controlled by the GPU.
- * @WMI_BRIGHTNESS_SOURCE_EC:  Backlight brightness is controlled by the
- * system's Embedded Controller (EC).
- * @WMI_BRIGHTNESS_SOURCE_AUX: Backlight brightness is controlled over the
- * DisplayPort AUX channel.
- */
-enum wmi_brightness_source {
-   WMI_BRIGHTNESS_SOURCE_GPU = 1,
-   WMI_BRIGHTNESS_SOURCE_EC = 2,
-   WMI_BRIGHTNESS_SOURCE_AUX = 3,
-   WMI_BRIGHTNESS_SOURCE_MAX
-};
-
-/**
- * struct wmi_brightness_args - arguments for the WMI-wrapped ACPI method
- * @mode:Pass in an  wmi_brightness_mode value to select between
- *   getting or setting a value.
- * @val: In parameter for value to set when using %WMI_BRIGHTNESS_MODE_SET
- *   mode. Not used in conjunction with %WMI_BRIGHTNESS_MODE_GET or
- *   %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL mode.
- * @ret: Out parameter returning retrieved value when operating in
- *   %WMI_BRIGHTNESS_MODE_GET or %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL
- *   mode. Not used in %WMI_BRIGHTNESS_MODE_SET mode.
- * @ignored: Padding; not used. The ACPI method expects a 24 byte params 
struct.
- *
- * This is the parameters structure for the WmiBrightnessNotify ACPI method as
- * wrapped by WMI. The value passed in to @val or returned by @ret will be a
- * brightness value when the WMI method ID is %WMI_BRIGHTNESS_METHOD_LEVEL, or
- * an  wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
- */
-struct wmi_brightness_args {
-   u32 mode;
-   u32 val;
-   u32 ret;
-   u32 ignored[3];
-};
-
 /**
  * wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI 
method
  * @w:Pointer to the struct wmi_device identified by %WMI_BRIGHTNESS_GUID
@@ -191,8 +127,6 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device 
*wdev, const void *ct
return PTR_ERR_OR_ZERO(bdev);
 }
 
-#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
-
 static const struct wmi_device_id nvidia_wmi_ec_backlight_id_table[] = {
{ .guid_string = WMI_BRIGHTNESS_GUID },
{ }
diff --git a/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h 
b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
new file mode 100644
index ..23d60130272c
--- /dev/null
+++ b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020, NVIDIA C

[Intel-gfx] [PATCH v5 16/31] ACPI: video: Refactor acpi_video_get_backlight_type() a bit

[Hans de Goede]

Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.

Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 39 ++---
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index fb49b8f4523a..cc9d0d91e268 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -537,16 +537,6 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
 /*
  * Determine which type of backlight interface to use on this system,
  * First check cmdline, then dmi quirks, then do autodetect.
- *
- * The autodetect order is:
- * 1) Is the acpi-video backlight interface supported ->
- *  no, use a vendor interface
- * 2) Is this a win8 "ready" BIOS and do we have a native interface ->
- *  yes, use a native interface
- * 3) Else use the acpi-video interface
- *
- * Arguably the native on win8 check should be done first, but that would
- * be a behavior change, which may causes issues.
  */
 static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
 {
@@ -569,19 +559,36 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
native_available = true;
mutex_unlock(_mutex);
 
+   /*
+* The below heuristics / detection steps are in order of descending
+* presedence. The commandline takes presedence over anything else.
+*/
if (acpi_backlight_cmdline != acpi_backlight_undef)
return acpi_backlight_cmdline;
 
+   /* DMI quirks override any autodetection. */
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
 
-   if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
-   return acpi_backlight_vendor;
-
-   if (acpi_osi_is_win8() && native_available)
-   return acpi_backlight_native;
+   /* On systems with ACPI video use either native or ACPI video. */
+   if (video_caps & ACPI_VIDEO_BACKLIGHT) {
+   /*
+* Windows 8 and newer no longer use the ACPI video interface,
+* so it often does not work. If the ACPI tables are written
+* for win8 and native brightness ctl is available, use that.
+*
+* The native check deliberately is inside the if acpi-video
+* block on older devices without acpi-video support native
+* is usually not the best choice.
+*/
+   if (acpi_osi_is_win8() && native_available)
+   return acpi_backlight_native;
+   else
+   return acpi_backlight_video;
+   }
 
-   return acpi_backlight_video;
+   /* No ACPI video (old hw), use vendor specific fw methods. */
+   return acpi_backlight_vendor;
 }
 
 enum acpi_backlight_type acpi_video_get_backlight_type(void)
-- 
2.37.2

[Intel-gfx] [PATCH v5 20/31] platform/x86: apple-gmux: Stop calling acpi/video.h functions

[Hans de Goede]

Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.

So remove the handling for this from the apple-gmux driver.

Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/apple-gmux.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index ffe98a18440b..ca33df7ea550 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /**
@@ -694,7 +693,6 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
 * backlight control and supports more levels than other options.
 * Disable the other backlight choices.
 */
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
apple_bl_unregister();
 
gmux_data->power_state = VGA_SWITCHEROO_ON;
@@ -804,7 +802,6 @@ static void gmux_remove(struct pnp_dev *pnp)
apple_gmux_data = NULL;
kfree(gmux_data);
 
-   acpi_video_register();
apple_bl_register();
 }
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 12/31] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)

[Hans de Goede]

Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.

This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.

Add a call to the new acpi_video_register_backlight() when native backlight
device registration has failed / was skipped to ensure that there is a
backlight device available before the drm_device gets registered with
userspace.

Changes in v2:
- Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved
  symbol errors on non X86

Reviewed-by: Lyude Paul 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c  | 5 +
 drivers/gpu/drm/nouveau/nouveau_acpi.h  | 2 ++
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 1592c9cd7750..8cf096f841a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -391,3 +391,8 @@ bool nouveau_acpi_video_backlight_use_native(void)
 {
return acpi_video_backlight_use_native();
 }
+
+void nouveau_acpi_video_register_backlight(void)
+{
+   acpi_video_register_backlight();
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h 
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 3c666c30dfca..e39dd8b94b8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -12,6 +12,7 @@ void nouveau_unregister_dsm_handler(void);
 void nouveau_switcheroo_optimus_dsm(void);
 void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
 bool nouveau_acpi_video_backlight_use_native(void);
+void nouveau_acpi_video_register_backlight(void);
 #else
 static inline bool nouveau_is_optimus(void) { return false; };
 static inline bool nouveau_is_v1_dsm(void) { return false; };
@@ -20,6 +21,7 @@ static inline void nouveau_unregister_dsm_handler(void) {}
 static inline void nouveau_switcheroo_optimus_dsm(void) {}
 static inline void *nouveau_acpi_edid(struct drm_device *dev, struct 
drm_connector *connector) { return NULL; }
 static inline bool nouveau_acpi_video_backlight_use_native(void) { return 
true; }
+static inline void nouveau_acpi_video_register_backlight(void) {}
 #endif
 
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index d2b8f8c13db4..a614582779ca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector)
 
 fail_alloc:
kfree(bl);
+   /*
+* If we get here we have an internal panel, but no nv_backlight,
+* try registering an ACPI video backlight device instead.
+*/
+   if (ret == 0)
+   nouveau_acpi_video_register_backlight();
+
return ret;
 }
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 18/31] ACPI: video: Add Apple GMUX brightness control detection

[Hans de Goede]

On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.

Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.

This will allow removig the (ab)use of:

acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);

Inside the apple-gmux driver.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 4 
 include/acpi/video.h| 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4dc7fb865083..be2fc43418af 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -607,6 +608,9 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
if (nvidia_wmi_ec_present)
return acpi_backlight_nvidia_wmi_ec;
 
+   if (apple_gmux_present())
+   return acpi_backlight_apple_gmux;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 91578e77ac4e..dbd48cb8bd23 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -49,6 +49,7 @@ enum acpi_backlight_type {
acpi_backlight_vendor,
acpi_backlight_native,
acpi_backlight_nvidia_wmi_ec,
+   acpi_backlight_apple_gmux,
 };
 
 #if IS_ENABLED(CONFIG_ACPI_VIDEO)
-- 
2.37.2

[Intel-gfx] [PATCH v5 07/31] ACPI: video: Remove acpi_video_bus from list before tearing it down

[Hans de Goede]

Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 5cbe2196176d..cde8ffa9f0b8 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2111,14 +2111,14 @@ static int acpi_video_bus_remove(struct acpi_device 
*device)
 
video = acpi_driver_data(device);
 
-   acpi_video_bus_remove_notify_handler(video);
-   acpi_video_bus_unregister_backlight(video);
-   acpi_video_bus_put_devices(video);
-
mutex_lock(_list_lock);
list_del(>entry);
mutex_unlock(_list_lock);
 
+   acpi_video_bus_remove_notify_handler(video);
+   acpi_video_bus_unregister_backlight(video);
+   acpi_video_bus_put_devices(video);
+
kfree(video->attached_array);
kfree(video);
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 14/31] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration

[Hans de Goede]

Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.

This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.

Add a call to the new acpi_video_register_backlight() when radeon skips
registering its own backlight device because of e.g. the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the radeon drm_device gets registered with userspace.

Acked-by: Alex Deucher 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 35c535e48b8d..fbc0a2182318 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include 
+
 #include "radeon.h"
 #include "radeon_atombios.h"
 #include "radeon_legacy_encoders.h"
@@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct 
radeon_encoder *radeon_encoder,
return;
 
if (radeon_backlight == 0) {
-   return;
+   use_bl = false;
} else if (radeon_backlight == 1) {
use_bl = true;
} else if (radeon_backlight == -1) {
@@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct 
radeon_encoder *radeon_encoder,
else
radeon_legacy_backlight_init(radeon_encoder, connector);
}
+
+   /*
+* If there is no native backlight device (which may happen even when
+* use_bl==true) try registering an ACPI video backlight device instead.
+*/
+   if (!rdev->mode_info.bl_encoder)
+   acpi_video_register_backlight();
 }
 
 void
-- 
2.37.2

[Intel-gfx] [PATCH v5 10/31] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers

[Hans de Goede]

Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.

Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer necessary to monitor for a
native (BACKLIGHT_RAW) device showing up later and to then unregister
the acpi_video backlight device(s).

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c   |  2 --
 drivers/acpi/video_detect.c | 36 
 2 files changed, 38 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 09dd86f86cf3..d1e41f30c004 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -94,7 +94,6 @@ static void acpi_video_bus_notify(struct acpi_device *device, 
u32 event);
 static void acpi_video_bus_register_backlight_work(struct work_struct 
*ignored);
 static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
acpi_video_bus_register_backlight_work);
-void acpi_video_detect_exit(void);
 
 /*
  * Indices in the _BCL method response: the first two items are special,
@@ -2342,7 +2341,6 @@ static int __init acpi_video_init(void)
 
 static void __exit acpi_video_exit(void)
 {
-   acpi_video_detect_exit();
acpi_video_unregister();
 }
 
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 385eb49c763f..fb49b8f4523a 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,10 +38,6 @@
 
 void acpi_video_unregister_backlight(void);
 
-static bool backlight_notifier_registered;
-static struct notifier_block backlight_nb;
-static struct work_struct backlight_notify_work;
-
 static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
 static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
 
@@ -538,26 +534,6 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
{ },
 };
 
-/* This uses a workqueue to avoid various locking ordering issues */
-static void acpi_video_backlight_notify_work(struct work_struct *work)
-{
-   if (acpi_video_get_backlight_type() != acpi_backlight_video)
-   acpi_video_unregister_backlight();
-}
-
-static int acpi_video_backlight_notify(struct notifier_block *nb,
-  unsigned long val, void *bd)
-{
-   struct backlight_device *backlight = bd;
-
-   /* A raw bl registering may change video -> native */
-   if (backlight->props.type == BACKLIGHT_RAW &&
-   val == BACKLIGHT_REGISTERED)
-   schedule_work(_notify_work);
-
-   return NOTIFY_OK;
-}
-
 /*
  * Determine which type of backlight interface to use on this system,
  * First check cmdline, then dmi quirks, then do autodetect.
@@ -587,12 +563,6 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
_caps, NULL);
-   INIT_WORK(_notify_work,
- acpi_video_backlight_notify_work);
-   backlight_nb.notifier_call = acpi_video_backlight_notify;
-   backlight_nb.priority = 0;
-   if (backlight_register_notifier(_nb) == 0)
-   backlight_notifier_registered = true;
init_done = true;
}
if (native)
@@ -639,9 +609,3 @@ void acpi_video_set_dmi_backlight_type(enum 
acpi_backlight_type type)
acpi_video_unregister_backlight();
 }
 EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
-
-void __exit acpi_video_detect_exit(void)
-{
-   if (backlight_notifier_registered)
-   backlight_unregister_notifier(_nb);
-}
-- 
2.37.2

[Intel-gfx] [PATCH v5 13/31] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration

[Hans de Goede]

Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.

This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.

Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.

Acked-by: Alex Deucher 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 9 +++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index b4e3cedceaf8..6be9ac2b9c5b 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -184,11 +184,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
amdgpu_encoder *amdgpu_encode
return;
 
if (!(adev->mode_info.firmware_flags & 
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
-   return;
+   goto register_acpi_backlight;
 
if (!acpi_video_backlight_use_native()) {
drm_info(dev, "Skipping amdgpu atom DIG backlight 
registration\n");
-   return;
+   goto register_acpi_backlight;
}
 
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
@@ -225,6 +225,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
amdgpu_encoder *amdgpu_encode
 error:
kfree(pdata);
return;
+
+register_acpi_backlight:
+   /* Try registering an ACPI video backlight device instead. */
+   acpi_video_register_backlight();
+   return;
 }
 
 void
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 706c67f4bda8..c450964f84d4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4037,6 +4037,8 @@ amdgpu_dm_register_backlight_device(struct 
amdgpu_display_manager *dm)
 
if (!acpi_video_backlight_use_native()) {
drm_info(adev_to_drm(dm->adev), "Skipping amdgpu DM backlight 
registration\n");
+   /* Try registering an ACPI video backlight device instead. */
+   acpi_video_register_backlight();
return;
}
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 11/31] drm/i915: Call acpi_video_register_backlight() (v3)

[Hans de Goede]

On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.

Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the drivers/acpi/video_detect.c code
unregistered the acpi_video0 device to avoid there being 2 backlight
devices (when acpi_video_get_backlight_type()==native).

This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.

Add a call to the new acpi_video_register_backlight() after the i915 calls
acpi_video_register() (after setting up the i915 opregion) so that the
acpi_video backlight devices get registered on systems where the i915
native backlight device is not registered.

Changes in v2:
-Only call acpi_video_register_backlight() when a panel is detected

Changes in v3:
-Add a new intel_acpi_video_register() helper which checks if a panel
 is present and then calls acpi_video_register_backlight()

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_acpi.c| 27 
 drivers/gpu/drm/i915/display/intel_acpi.h|  3 +++
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..9df78e7caa2b 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "intel_acpi.h"
@@ -331,3 +332,29 @@ void intel_acpi_assign_connector_fwnodes(struct 
drm_i915_private *i915)
 */
fwnode_handle_put(fwnode);
 }
+
+void intel_acpi_video_register(struct drm_i915_private *i915)
+{
+   struct drm_connector_list_iter conn_iter;
+   struct drm_connector *connector;
+
+   acpi_video_register();
+
+   /*
+* If i915 is driving an internal panel without registering its native
+* backlight handler try to register the acpi_video backlight.
+* For panels not driven by i915 another GPU driver may still register
+* a native backlight later and acpi_video_register_backlight() should
+* only be called after any native backlights have been registered.
+*/
+   drm_connector_list_iter_begin(>drm, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   struct intel_panel *panel = 
_intel_connector(connector)->panel;
+
+   if (panel->backlight.funcs && !panel->backlight.device) {
+   acpi_video_register_backlight();
+   break;
+   }
+   }
+   drm_connector_list_iter_end(_iter);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h 
b/drivers/gpu/drm/i915/display/intel_acpi.h
index 4a760a2baed9..6a0007452f95 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -14,6 +14,7 @@ void intel_unregister_dsm_handler(void);
 void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
 void intel_acpi_device_id_update(struct drm_i915_private *i915);
 void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
+void intel_acpi_video_register(struct drm_i915_private *i915);
 #else
 static inline void intel_register_dsm_handler(void) { return; }
 static inline void intel_unregister_dsm_handler(void) { return; }
@@ -23,6 +24,8 @@ static inline
 void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
 static inline
 void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) { 
return; }
+static inline
+void intel_acpi_video_register(struct drm_i915_private *i915) { return; }
 #endif /* CONFIG_ACPI */
 
 #endif /* __INTEL_ACPI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6103b02c081f..129a13375101 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9087,7 +9087,7 @@ void intel_display_driver_register(struct 
drm_i915_private *i915)
 
/* Must be done after probing outputs */
intel_opregion_register(i915);
-   acpi_video_register();
+   intel_acpi_video_register(i915);
 
intel_audio_init(i915);
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 08/31] ACPI: video: Simplify acpi_video_unregister_backlight()

[Hans de Goede]

When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index cde8ffa9f0b8..8545bf94866f 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2257,14 +2257,10 @@ void acpi_video_unregister_backlight(void)
 {
struct acpi_video_bus *video;
 
-   mutex_lock(_count_mutex);
-   if (register_count) {
-   mutex_lock(_list_lock);
-   list_for_each_entry(video, _bus_head, entry)
-   acpi_video_bus_unregister_backlight(video);
-   mutex_unlock(_list_lock);
-   }
-   mutex_unlock(_count_mutex);
+   mutex_lock(_list_lock);
+   list_for_each_entry(video, _bus_head, entry)
+   acpi_video_bus_unregister_backlight(video);
+   mutex_unlock(_list_lock);
 }
 
 bool acpi_video_handles_brightness_key_presses(void)
-- 
2.37.2

[Intel-gfx] [PATCH v5 06/31] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()

[Hans de Goede]

All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.

This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.

Relying on the cached native_available value not only is simpler, it will
also work correctly in cases where then native backlight registration was
skipped because of acpi_video_backlight_use_native() returning false.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 5f105eaa7d30..385eb49c763f 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -608,8 +608,7 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
 
-   if (acpi_osi_is_win8() &&
-   (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
+   if (acpi_osi_is_win8() && native_available)
return acpi_backlight_native;
 
return acpi_backlight_video;
-- 
2.37.2

[Intel-gfx] [PATCH v5 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.

Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.

Changes in v2:
- Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved
  symbol errors on non X86

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c  | 5 +
 drivers/gpu/drm/nouveau/nouveau_acpi.h  | 2 ++
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 6140db756d06..1592c9cd7750 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -386,3 +386,8 @@ nouveau_acpi_edid(struct drm_device *dev, struct 
drm_connector *connector)
 
return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
 }
+
+bool nouveau_acpi_video_backlight_use_native(void)
+{
+   return acpi_video_backlight_use_native();
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h 
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 330f9b837066..3c666c30dfca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -11,6 +11,7 @@ void nouveau_register_dsm_handler(void);
 void nouveau_unregister_dsm_handler(void);
 void nouveau_switcheroo_optimus_dsm(void);
 void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
+bool nouveau_acpi_video_backlight_use_native(void);
 #else
 static inline bool nouveau_is_optimus(void) { return false; };
 static inline bool nouveau_is_v1_dsm(void) { return false; };
@@ -18,6 +19,7 @@ static inline void nouveau_register_dsm_handler(void) {}
 static inline void nouveau_unregister_dsm_handler(void) {}
 static inline void nouveau_switcheroo_optimus_dsm(void) {}
 static inline void *nouveau_acpi_edid(struct drm_device *dev, struct 
drm_connector *connector) { return NULL; }
+static inline bool nouveau_acpi_video_backlight_use_native(void) { return 
true; }
 #endif
 
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index a2141d3d9b1d..d2b8f8c13db4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -38,6 +38,7 @@
 #include "nouveau_reg.h"
 #include "nouveau_encoder.h"
 #include "nouveau_connector.h"
+#include "nouveau_acpi.h"
 
 static struct ida bl_ida;
 #define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
@@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
goto fail_alloc;
}
 
+   if (!nouveau_acpi_video_backlight_use_native()) {
+   NV_INFO(drm, "Skipping nv_backlight registration\n");
+   goto fail_alloc;
+   }
+
if (!nouveau_get_backlight_name(backlight_name, bl)) {
NV_ERROR(drm, "Failed to retrieve a unique name for the 
backlight interface\n");
goto fail_alloc;
-- 
2.37.2

[Intel-gfx] [PATCH v5 09/31] ACPI: video: Make backlight class device registration a separate step (v2)

[Hans de Goede]

On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video0 device (when acpi_video_get_backlight_type()==native).

This means that userspace briefly sees 2 devices and the disappearing of
acpi_video0 after a brief time confuses the systemd backlight level
save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this make backlight class device registration a separate step
done by a new acpi_video_register_backlight() function. The intend is for
this to be called by the drm/kms driver *after* it is done setting up its
own native backlight device. So that acpi_video_get_backlight_type() knows
if a native backlight will be available or not at acpi_video backlight
registration time, avoiding the add + remove dance.

Note the new acpi_video_register_backlight() function is also called from
a delayed work to ensure that the acpi_video backlight devices does get
registered if necessary even if there is no drm/kms driver or when it is
disabled.

Changes in v2:
- Make register_backlight_delay a module parameter, mainly so that it can
  be disabled by Nvidia binary driver users

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c | 50 ---
 include/acpi/video.h  |  2 ++
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 8545bf94866f..09dd86f86cf3 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -73,6 +73,16 @@ module_param(device_id_scheme, bool, 0444);
 static int only_lcd = -1;
 module_param(only_lcd, int, 0444);
 
+/*
+ * Display probing is known to take up to 5 seconds, so delay the fallback
+ * backlight registration by 5 seconds + 3 seconds for some extra margin.
+ */
+static int register_backlight_delay = 8;
+module_param(register_backlight_delay, int, 0444);
+MODULE_PARM_DESC(register_backlight_delay,
+   "Delay in seconds before doing fallback (non GPU driver triggered) "
+   "backlight registration, set to 0 to disable.");
+
 static bool may_report_brightness_keys;
 static int register_count;
 static DEFINE_MUTEX(register_count_mutex);
@@ -81,6 +91,9 @@ static LIST_HEAD(video_bus_head);
 static int acpi_video_bus_add(struct acpi_device *device);
 static int acpi_video_bus_remove(struct acpi_device *device);
 static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static void acpi_video_bus_register_backlight_work(struct work_struct 
*ignored);
+static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
+   acpi_video_bus_register_backlight_work);
 void acpi_video_detect_exit(void);
 
 /*
@@ -1859,8 +1872,6 @@ static int acpi_video_bus_register_backlight(struct 
acpi_video_bus *video)
if (video->backlight_registered)
return 0;
 
-   acpi_video_run_bcl_for_osi(video);
-
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
 
@@ -2086,7 +2097,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
list_add_tail(>entry, _bus_head);
mutex_unlock(_list_lock);
 
-   acpi_video_bus_register_backlight(video);
+   /*
+* The userspace visible backlight_device gets registered separately
+* from acpi_video_register_backlight().
+*/
+   acpi_video_run_bcl_for_osi(video);
acpi_video_bus_add_notify_handler(video);
 
return 0;
@@ -2125,6 +2140,11 @@ static int acpi_video_bus_remove(struct acpi_device 
*device)
return 0;
 }
 
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
+{
+   acpi_video_register_backlight();
+}
+
 static int __init is_i740(struct pci_dev *dev)
 {
if (dev->device == 0x00D1)
@@ -2235,6 +2255,18 @@ int acpi_video_register(void)
 */
register_count = 1;
 
+   /*
+* acpi_video_bus_add() skips registering the userspace visible
+* backlight_device. The intend is for this to be registered by the
+* drm/kms driver calling acpi_video_register_backlight() *after* it is
+* done setting up its own native backlight device. The delayed work
+* ensures that acpi_video_register_backlight() always gets called
+* eventually, in case there is no drm/kms driver or it is disabled.
+*/
+   if (register_backlight_delay)
+   schedule_delayed_work(_bus_register_backlight_work,
+ register_backlight_delay * HZ);
+
 leave:
mutex_unlock(_count_mutex);
return ret;
@@ -2245,6 +2277,7 @@ void acpi_video_unregister(void)
 {
mutex_lock(_count_mutex

[Intel-gfx] [PATCH v5 04/31] drm/radeon: Don't register backlight when another backlight should be used (v3)

[Hans de Goede]

Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.

Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.

Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
  a module, select ACPI_VIDEO and its deps if ACPI is enabled.
  When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
  the stubs from acpi/video.h will be used.

Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
  adjust the Kconfig changes to match this.

Acked-by: Alex Deucher 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig | 7 +++
 drivers/gpu/drm/radeon/atombios_encoders.c  | 7 +++
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95ca33938b4a..0471505e951d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -234,6 +234,13 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+   # radeon depends on ACPI_VIDEO when ACPI is enabled, for select to work
+   # ACPI_VIDEO's dependencies must also be selected.
+   select INPUT if ACPI
+   select ACPI_VIDEO if ACPI
+   # On x86 ACPI_VIDEO also needs ACPI_WMI
+   select X86_PLATFORM_DEVICES if ACPI && X86
+   select ACPI_WMI if ACPI && X86
help
  Choose this option if you have an ATI Radeon graphics card.  There
  are both PCI and AGP versions.  You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 0eae05dfb385..c841c273222e 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include 
+
 #include "atom.h"
 #include "radeon_atombios.h"
 #include "radeon.h"
@@ -209,6 +211,11 @@ void radeon_atom_backlight_init(struct radeon_encoder 
*radeon_encoder,
if (!(rdev->mode_info.firmware_flags & 
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
 
+   if (!acpi_video_backlight_use_native()) {
+   drm_info(dev, "Skipping radeon atom DIG backlight 
registration\n");
+   return;
+   }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 1a66fb969ee7..0cd32c65456c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 
+#include 
+
 #include "radeon.h"
 #include "radeon_asic.h"
 #include "radeon_legacy_encoders.h"
@@ -387,6 +389,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder 
*radeon_encoder,
return;
 #endif
 
+   if (!acpi_video_backlight_use_native()) {
+   drm_info(dev, "Skipping radeon legacy LVDS backlight 
registration\n");
+   return;
+   }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
-- 
2.37.2

[Intel-gfx] [PATCH v5 01/31] ACPI: video: Add acpi_video_backlight_use_native() helper

[Hans de Goede]

ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2 backlight devices for a single display really is undesirable.

On x86 laptops where the native GPU backlight device should be used,
the registering of other backlight devices is avoided by their drivers
using acpi_video_get_backlight_type() and only registering their backlight
if the return value matches their type.

acpi_video_get_backlight_type() uses
backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
driver is available and will never return native if this returns
false. This means that the GPU's native backlight registering code
cannot just call acpi_video_get_backlight_type() to determine if it
should register its backlight, since acpi_video_get_backlight_type() will
never return native until the native backlight has already registered.

To fix this add a new internal native function parameter to
acpi_video_get_backlight_type(), which when set to true will make
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.

And add a new acpi_video_backlight_use_native() helper, which sets this
to true, for use in native GPU backlight code.

Changes in v2:
- Replace adding a native parameter to acpi_video_get_backlight_type() with
  adding a new acpi_video_backlight_use_native() helper.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 24 
 include/acpi/video.h|  5 +
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 5d7f38016a24..5f105eaa7d30 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,8 +17,9 @@
  * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
  * sony_acpi,... can take care about backlight brightness.
  *
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * Backlight drivers can use acpi_video_get_backlight_type() to determine which
+ * driver should handle the backlight. RAW/GPU-driver backlight drivers must
+ * use the acpi_video_backlight_use_native() helper for this.
  *
  * If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module (m)
  * this file will not be compiled and acpi_video_get_backlight_type() will
@@ -571,9 +572,10 @@ static int acpi_video_backlight_notify(struct 
notifier_block *nb,
  * Arguably the native on win8 check should be done first, but that would
  * be a behavior change, which may causes issues.
  */
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
 {
static DEFINE_MUTEX(init_mutex);
+   static bool native_available;
static bool init_done;
static long video_caps;
 
@@ -593,6 +595,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
backlight_notifier_registered = true;
init_done = true;
}
+   if (native)
+   native_available = true;
mutex_unlock(_mutex);
 
if (acpi_backlight_cmdline != acpi_backlight_undef)
@@ -604,13 +608,25 @@ enum acpi_backlight_type 
acpi_video_get_backlight_type(void)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
 
-   if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
+   if (acpi_osi_is_win8() &&
+   (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
return acpi_backlight_native;
 
return acpi_backlight_video;
 }
+
+enum acpi_backlight_type acpi_video_get_backlight_type(void)
+{
+   return __acpi_video_get_backlight_type(false);
+}
 EXPORT_SYMBOL(acpi_video_get_backlight_type);
 
+bool acpi_video_backlight_use_native(void)
+{
+   return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
+}
+EXPORT_SYMBOL(acpi_video_backlight_use_native);
+
 /*
  * Set the preferred backlight interface type based on DMI info.
  * This function allows DMI blacklists to be implemented by external
diff --git a/include/acpi/video.h b/include/acpi/video.h
index db8548ff03ce..4705e339c252 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
 extern int acpi_video_get_edid(struct acpi_device *device, int type,
   int device_id, void **edid);
 extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
+extern bool acpi_video_backlight_use_native(void);
 extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
 /

[Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.

Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.

Changes in v2:
- Use drm_info(drm_dev,  ...) for log messages

Reviewed-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 681ebcda97ad..03c7966f68d6 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include 
+
 #include "intel_backlight.h"
 #include "intel_backlight_regs.h"
 #include "intel_connector.h"
@@ -952,6 +954,11 @@ int intel_backlight_device_register(struct intel_connector 
*connector)
 
WARN_ON(panel->backlight.max == 0);
 
+   if (!acpi_video_backlight_use_native()) {
+   drm_info(>drm, "Skipping intel_backlight registration\n");
+   return 0;
+   }
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
 
-- 
2.37.2

[Intel-gfx] [PATCH v5 03/31] drm/amdgpu: Don't register backlight when another backlight should be used (v3)

[Hans de Goede]

Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.

Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.

Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
  a module, select ACPI_VIDEO and its deps if ACPI is enabled.
  When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
  the stubs from acpi/video.h will be used.

Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
  adjust the Kconfig changes to match this.

Acked-by: Alex Deucher 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig   | 7 +++
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0b2ad7212ee6..95ca33938b4a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -259,6 +259,13 @@ config DRM_AMDGPU
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
select DRM_BUDDY
+   # amdgpu depends on ACPI_VIDEO when ACPI is enabled, for select to work
+   # ACPI_VIDEO's dependencies must also be selected.
+   select INPUT if ACPI
+   select ACPI_VIDEO if ACPI
+   # On x86 ACPI_VIDEO also needs ACPI_WMI
+   select X86_PLATFORM_DEVICES if ACPI && X86
+   select ACPI_WMI if ACPI && X86
help
  Choose this option if you have a recent AMD Radeon graphics card.
 
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index fa7421afb9a6..b4e3cedceaf8 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -26,6 +26,8 @@
 
 #include 
 
+#include 
+
 #include 
 #include 
 #include "amdgpu.h"
@@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct 
amdgpu_encoder *amdgpu_encode
if (!(adev->mode_info.firmware_flags & 
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
 
+   if (!acpi_video_backlight_use_native()) {
+   drm_info(dev, "Skipping amdgpu atom DIG backlight 
registration\n");
+   return;
+   }
+
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e702f0d72d53..706c67f4bda8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -90,6 +90,8 @@
 #include 
 #include 
 
+#include 
+
 #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
 
 #include "dcn/dcn_1_0_offset.h"
@@ -4033,6 +4035,11 @@ amdgpu_dm_register_backlight_device(struct 
amdgpu_display_manager *dm)
amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
 
+   if (!acpi_video_backlight_use_native()) {
+   drm_info(adev_to_drm(dm->adev), "Skipping amdgpu DM backlight 
registration\n");
+   return;
+   }
+
props.max_brightness = AMDGPU_MAX_BL_LEVEL;
props.brightness = AMDGPU_MAX_BL_LEVEL;
props.type = BACKLIGHT_RAW;
-- 
2.37.2

[Intel-gfx] [PATCH v5 00/31] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

[Hans de Goede]

Hi All,

As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/

The first step towards this is to deal with some existing technical debt
in backlight handling on x86/ACPI boards, specifically we need to stop
registering multiple /sys/class/backlight devs for a single display.

This series implements my RFC describing my plan for these cleanups:
https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/

Changes in version 5:
- Use drm_info(drm_dev, ...) in patch 2/31
- Modify "drm/i915: Call acpi_video_register_backlight()", dropping
  the global has_panel flag, replacing it with a new
  intel_acpi_video_register() helper

Changes in version 4:
- Minor tweaks to nvidia-wmi-ec-backlight changes
- Add nouveau_acpi_* wrappers around used include/acpi/video.h functions to
  fix unresolved symbol errors on non X86

Changes in version 3:
- ACPI_VIDEO can now be enabled on non X86 too, adjust various Kconfig changes
- Make the delay before doing fallback acpi_video backlight registration
  a module option (patch 9)
- Move the nvidia-wmi-ec-backlight fw API definitions to a shared header
- Add a "acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec"
  check to the nvidia-wmi-ec-backlight driver (patch 19)

Changes in version 2:
- Introduce acpi_video_backlight_use_native() helper
- Finishes the refactoring, addressing all the bits from the "Other issues"
  section of the refactor RFC

This series as submitted is based on drm-tip for CI purposes.

Assuming the last i915 patch also pass review now, I hope to push
out an immutable branch with this series on top of v6.0-rc1 and
send out a pull-request to all involved subsystems based on
this branch soon.

Regards,

Hans


Hans de Goede (31):
  ACPI: video: Add acpi_video_backlight_use_native() helper
  drm/i915: Don't register backlight when another backlight should be
used (v2)
  drm/amdgpu: Don't register backlight when another backlight should be
used (v3)
  drm/radeon: Don't register backlight when another backlight should be
used (v3)
  drm/nouveau: Don't register backlight when another backlight should be
used (v2)
  ACPI: video: Drop backlight_device_get_by_type() call from
acpi_video_get_backlight_type()
  ACPI: video: Remove acpi_video_bus from list before tearing it down
  ACPI: video: Simplify acpi_video_unregister_backlight()
  ACPI: video: Make backlight class device registration a separate step
(v2)
  ACPI: video: Remove code to unregister acpi_video backlight when a
native backlight registers
  drm/i915: Call acpi_video_register_backlight() (v3)
  drm/nouveau: Register ACPI video backlight when nv_backlight
registration fails (v2)
  drm/amdgpu: Register ACPI video backlight when skipping amdgpu
backlight registration
  drm/radeon: Register ACPI video backlight when skipping radeon
backlight registration
  platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions
to a header (v2)
  ACPI: video: Refactor acpi_video_get_backlight_type() a bit
  ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
  ACPI: video: Add Apple GMUX brightness control detection
  platform/x86: nvidia-wmi-ec-backlight: Use
acpi_video_get_backlight_type()
  platform/x86: apple-gmux: Stop calling acpi/video.h functions
  platform/x86: toshiba_acpi: Stop using
acpi_video_set_dmi_backlight_type()
  platform/x86: acer-wmi: Move backlight DMI quirks to
acpi/video_detect.c
  platform/x86: asus-wmi: Drop DMI chassis-type check from backlight
handling
  platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI
video_detect.c
  platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI
video_detect.c
  platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native]
quirks to ACPI video_detect.c
  ACPI: video: Remove acpi_video_set_dmi_backlight_type()
  ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
  ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native
quirks
  ACPI: video: Fix indentation of video_detect_dmi_table[] entries
  drm/todo: Add entry about dealing with brightness control on devices
with > 1 panel

 Documentation/gpu/todo.rst|  68 +++
 MAINTAINERS   |   1 +
 drivers/acpi/Kconfig  |   1 +
 drivers/acpi/acpi_video.c |  64 ++-
 drivers/acpi/video_detect.c   | 428 +++---
 drivers/gpu/drm/Kconfig   |  14 +
 .../gpu/drm/amd/amdgpu/atombios_encoders.c|  14 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   9 +
 drivers/gpu/drm/gma500/Kconfig|   2 +
 drivers/gpu/drm/i915/Kconfig  |   2 +
 drivers/gpu/drm/i915/display/intel_acpi.c |  27 ++

Re: [Intel-gfx] [PATCH v4 02/31] drm/i915: Don't register backlight when another backlight should be used

[Hans de Goede]

Hi All,

On 8/24/22 14:50, Jani Nikula wrote:
> On Wed, 24 Aug 2022, Hans de Goede  wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight device and acpi_video's
>> firmware acpi_video# backlight device. This relies on userspace preferring
>> firmware type backlight devices over native ones.
>>
>> Registering 2 backlight devices for a single display really is
>> undesirable, don't register the GPU's native backlight device when
>> another backlight device should be used.
>>
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
>> b/drivers/gpu/drm/i915/display/intel_backlight.c
>> index 681ebcda97ad..a4dd7924e0c1 100644
>> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
>> @@ -8,6 +8,8 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +
>>  #include "intel_backlight.h"
>>  #include "intel_backlight_regs.h"
>>  #include "intel_connector.h"
>> @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct 
>> intel_connector *connector)
>>  
>>  WARN_ON(panel->backlight.max == 0);
>>  
>> +if (!acpi_video_backlight_use_native()) {
>> +DRM_INFO("Skipping intel_backlight registration\n");
> 
> Could use drm_info with drm_device.

Ack, fixed for v5.

> Either way,
> 
> Reviewed-by: Jani Nikula 

Thank you.

> and ack for merging via whichever tree suits you best.

My plan is to create a branch with the series on top
of 6.0-rc1 and then send a pull-req to all involved trees.

So far there are no conflicts between this branch and drm-tip...

Regards,

Hans



>> +return 0;
>> +}
>> +
>>  memset(, 0, sizeof(props));
>>  props.type = BACKLIGHT_RAW;
> 

Re: [Intel-gfx] [PATCH v4 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)

[Hans de Goede]

Hi Lyude,

Thank you for the review.

On 8/24/22 19:41, Lyude Paul wrote:
> Just one tiny nitpick below:
> 
> On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight device and acpi_video's
>> firmware acpi_video# backlight device. This relies on userspace preferring
>> firmware type backlight devices over native ones.
>>
>> Registering 2 backlight devices for a single display really is
>> undesirable, don't register the GPU's native backlight device when
>> another backlight device should be used.
>>
>> Changes in v2:
>> - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved
>>   symbol errors on non X86
>>
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_acpi.c  | 5 +
>>  drivers/gpu/drm/nouveau/nouveau_acpi.h  | 2 ++
>>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
>>  3 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
>> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> index 6140db756d06..1592c9cd7750 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> @@ -386,3 +386,8 @@ nouveau_acpi_edid(struct drm_device *dev, struct 
>> drm_connector *connector)
>>  
>>  return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
>>  }
>> +
>> +bool nouveau_acpi_video_backlight_use_native(void)
>> +{
>> +return acpi_video_backlight_use_native();
>> +}
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h 
>> b/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> index 330f9b837066..3c666c30dfca 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> @@ -11,6 +11,7 @@ void nouveau_register_dsm_handler(void);
>>  void nouveau_unregister_dsm_handler(void);
>>  void nouveau_switcheroo_optimus_dsm(void);
>>  void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
>> +bool nouveau_acpi_video_backlight_use_native(void);
>>  #else
>>  static inline bool nouveau_is_optimus(void) { return false; };
>>  static inline bool nouveau_is_v1_dsm(void) { return false; };
>> @@ -18,6 +19,7 @@ static inline void nouveau_register_dsm_handler(void) {}
>>  static inline void nouveau_unregister_dsm_handler(void) {}
>>  static inline void nouveau_switcheroo_optimus_dsm(void) {}
>>  static inline void *nouveau_acpi_edid(struct drm_device *dev, struct 
>> drm_connector *connector) { return NULL; }
>> +static inline bool nouveau_acpi_video_backlight_use_native(void) { return 
>> true; }
>>  #endif
>>  
>>  #endif
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
>> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> index a2141d3d9b1d..d2b8f8c13db4 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> @@ -38,6 +38,7 @@
>>  #include "nouveau_reg.h"
>>  #include "nouveau_encoder.h"
>>  #include "nouveau_connector.h"
>> +#include "nouveau_acpi.h"
>>  
>>  static struct ida bl_ida;
>>  #define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
>> @@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
>>  goto fail_alloc;
>>  }
>>  
>> +if (!nouveau_acpi_video_backlight_use_native()) {
>> +NV_INFO(drm, "Skipping nv_backlight registration\n");
>> +goto fail_alloc;
>> +}
> 
> We should probably make this say something like "No native backlight
> interface, using ACPI instead" instead. With that fixed

But that would not be correct. If we get to this point then before
the change we would continue with registering the native backlight
interface.

In other words, the native backlight interface is known to
be available at this point so saying "No native backlight interface"
would not be correct.

The reason the registration is being skipped is because the
drivers/acpi/video_detect.c heuristics (or DMI quirk or cmdline
override) say that another method to control the backlight is
preferred and we want to stop registering the native backlight
alltogether in that case so that there is only
1 /sys/class/backlight entry (on a 1 GPU 1 panel system).

Also "using ACPI instead" is not correct, on older systems
it might e.g. by a vendor specific control method such as
the one from dell-laptop. And on newer systems i

[Intel-gfx] [PATCH v4 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries

[Hans de Goede]

The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.

Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.

But over time some entries did not event have the single space
indent in front of the ".name = ..." lines.

Make things consistent by using a single space indent for these
lines everywhere.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 48 ++---
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 789d5913c178..db2474fe58ac 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -142,17 +142,17 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Asus UL30VT */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30VT */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Asus UL30A */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30A */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
@@ -198,9 +198,9 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* GIGABYTE GB-BXBT-2807 */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* GIGABYTE GB-BXBT-2807 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
@@ -233,17 +233,17 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Sony VPCEH3U1E */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Sony VPCEH3U1E */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"),
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Xiaomi Mi Pad 2 */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Xiaomi Mi Pad 2 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
@@ -551,25 +551,25 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA401 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA401 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA502 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA502 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA503 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA503 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
-- 
2.37.2