Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()

[Hans de Goede]

Hi,

On 6/2/24 5:57 PM, Andy Shevchenko wrote:
> Make two APIs look similar. Hence convert match_string() to be
> a 2-argument macro. In order to avoid unneeded churn, convert
> all users as well. There is no functional change intended.
> 
> Signed-off-by: Andy Shevchenko 
> ---
> 
> Compile tested with `make allyesconfig` and `make allmodconfig`
> on x86_64, arm, aarch64, powerpc64 (8 builds total).
> 
> I guess the best is to apply it to Linus' tree directly.
> And now it seems a good timing as there are no new users
> of this API either in v6.10-rcX, or in Linux Next.
> 
> But if you think differently, tell me.

Thanks, the drivers/platform/x86 bits look good to me:

Acked-by: Hans de Goede 

Regards,

Hans




>  arch/powerpc/xmon/xmon.c  |  5 ++--
>  arch/x86/kernel/cpu/mtrr/if.c |  4 +--
>  crypto/asymmetric_keys/pkcs7_verify.c |  4 +--
>  drivers/acpi/scan.c   |  4 +--
>  drivers/ata/pata_hpt366.c |  2 +-
>  drivers/ata/pata_hpt37x.c |  2 +-
>  drivers/base/property.c   |  6 ++--
>  drivers/char/ipmi/ipmi_msghandler.c   |  2 +-
>  drivers/char/ipmi/ipmi_si_hardcode.c  |  2 +-
>  drivers/clk/bcm/clk-bcm2835.c |  4 +--
>  drivers/clk/rockchip/clk.c|  4 +--
>  drivers/clk/tegra/clk-tegra124-emc.c  |  7 ++---
>  drivers/cpufreq/amd-pstate.c  |  4 +--
>  drivers/cpufreq/intel_pstate.c|  2 +-
>  .../intel/qat/qat_common/adf_cfg_services.c   |  5 ++--
>  .../gpu/drm/drm_panel_orientation_quirks.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_pipe_crc.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |  4 +--
>  drivers/gpu/drm/nouveau/dispnv50/crc.c|  2 +-
>  drivers/hwmon/ltc4282.c   | 14 -
>  drivers/hwmon/nct6775-platform.c  |  6 ++--
>  drivers/hwtracing/intel_th/msu.c  |  2 +-
>  drivers/i2c/busses/i2c-i801.c |  4 +--
>  drivers/leds/leds-sun50i-a100.c   |  2 +-
>  drivers/mfd/omap-usb-host.c   |  2 +-
>  drivers/mmc/host/sdhci-xenon-phy.c| 13 -
>  drivers/mtd/nand/raw/nand_macronix.c  | 10 ++-
>  .../net/ethernet/chelsio/cxgb4/cudbg_lib.c|  6 ++--
>  .../net/wireless/intel/iwlwifi/mvm/debugfs.c  |  2 +-
>  drivers/pci/pcie/aer.c|  2 +-
>  drivers/phy/mediatek/phy-mtk-tphy.c   |  8 ++---
>  drivers/phy/tegra/xusb.c  |  4 +--
>  drivers/pinctrl/mvebu/pinctrl-armada-37xx.c   |  6 ++--
>  drivers/pinctrl/pinmux.c  |  6 ++--
>  drivers/platform/x86/hp/hp-wmi.c  | 29 +++
>  drivers/platform/x86/msi-ec.c |  4 +--
>  drivers/power/supply/ab8500_btemp.c   |  2 +-
>  drivers/power/supply/ab8500_chargalg.c|  2 +-
>  drivers/power/supply/ab8500_charger.c |  2 +-
>  drivers/power/supply/ab8500_fg.c  |  2 +-
>  drivers/staging/gdm724x/gdm_tty.c |  5 ++--
>  .../int340x_thermal/processor_thermal_rfim.c  |  4 +--
>  .../processor_thermal_wt_req.c|  2 +-
>  drivers/usb/common/common.c   |  8 ++---
>  drivers/usb/dwc3/dwc3-rtk.c   |  2 +-
>  drivers/usb/typec/class.c | 14 -
>  drivers/usb/typec/tipd/core.c |  3 +-
>  drivers/video/fbdev/pxafb.c   |  4 +--
>  fs/bcachefs/compress.c|  2 +-
>  fs/bcachefs/opts.c|  4 +--
>  fs/bcachefs/util.c|  4 +--
>  fs/ubifs/auth.c   |  8 ++---
>  include/linux/string.h| 12 +++-
>  kernel/cgroup/rdma.c  |  2 +-
>  kernel/sched/debug.c  |  2 +-
>  kernel/trace/trace.c  |  4 +--
>  kernel/trace/trace_osnoise.c  |  4 +--
>  lib/dynamic_debug.c   |  5 ++--
>  lib/string_helpers.c  |  6 ++--
>  mm/mempolicy.c|  4 +--
>  mm/vmpressure.c   |  4 +--
>  security/apparmor/lsm.c   |  9 +++---
>  security/integrity/ima/ima_main.c |  2 +-
>  security/integrity/ima/ima_policy.c   |  2 +-
>  sound/firewire/oxfw/oxfw.c|  2 +-
>  sound/pci/oxygen/oxygen_mixer.c   |  2 +-
>  sound/soc/codecs/max98088.c   |  2 +-
>  sound/soc/codecs/max98095.c   |  2 +-
>  sound/soc/soc-dapm.c  

Re: [Nouveau] [REGRESSION]: acpi/nouveau: Hardware unavailable upon resume or suspend fails

[Hans de Goede]

Hi,

On 11/10/23 17:58, Owen T. Heisler wrote:
> Hi everyone,
> 
> On 11/10/23 06:52, Kai-Heng Feng wrote:
>> On Fri, Nov 10, 2023 at 2:19 PM Hans de Goede  wrote:
>>> On 11/10/23 07:09, Kai-Heng Feng wrote:
>>>> On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler  wrote:
>>>>> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
>>>>> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
>>>>> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124
>>>>
>>>> Thanks for the bug report. Do you prefer to continue the discussion
>>>> here, on gitlab or on bugzilla?
> 
> Kai-Heng, you're welcome and thank you too. By email is fine with me.
> 
>>> Owen, as Kai-Heng said thank you for reporting this.
> 
> Hans, you're welcome, and thanks for your help too.
> 
>>>>> ## Reproducing
>>>>>
>>>>> 1. Boot system to framebuffer console.
>>>>> 2. Run `systemctl suspend`. If undocked without secondary display,
>>>>> suspend fails. If docked with secondary display, suspend succeeds.
>>>>> 3. Resume from suspend if applicable.
>>>>> 4. System is now in a broken state.
>>>>
>>>> So I guess we need to put those devices to ACPI D3 for suspend. Let's
>>>> discuss this on your preferred platform.
>>>
>>> Ok, so I was already sort of afraid we might see something like this
>>> happening because of:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89c290ea758911e660878e26270e084d862c03b0
>>>
>>> As I mentioned during the review of that, it might be better to
>>> not touch the video-card ACPI power-state at all and instead
>>> only do acpi_device_fix_up_power() on the child devices.
>>
>> Or the child devices need to be put to D3 during suspend.
>>
>>> Owen, attached are 2 patches which implement only
>>> calling acpi_device_fix_up_power() on the child devices,
>>> can you build a v6.6 kernel with these 2 patches added
>>> on top please and see if that fixes things ?
> 
> Yes, with those patches v6.6 suspend works normally. That's great, thanks!
> 
> I tested with v6.6 with the 2 patches at 
> <https://lore.kernel.org/regressions/a592ce0c-64f0-477d-80fa-8f5a52ba2...@redhat.com/>
>  using 
> <https://gitlab.freedesktop.org/drm/nouveau/uploads/788d7faf22ba2884dcc09d7be931e813/v6.6-config1>.
>  I tested both docked and un-docked, just in case.
> 
> Tested-by: Owen T. Heisler 
> 
>>> Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
>>> is still resolved after applying these patches ?
>>
>> Yes. Thanks for the patch.
>>
>> If this patch also fixes Owen's issue, then
>> Tested-by: Kai-Heng Feng 

Re: [Nouveau] [REGRESSION]: acpi/nouveau: Hardware unavailable upon resume or suspend fails

[Hans de Goede]

Hi All,

On 11/10/23 07:09, Kai-Heng Feng wrote:
> Hi Owen,
> 
> On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler  wrote:
>>
>> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
>> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
>> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124
> 
> Thanks for the bug report. Do you prefer to continue the discussion
> here, on gitlab or on bugzilla?

Owen, as Kai-Heng said thank you for reporting this.

>> ## Reproducing
>>
>> 1. Boot system to framebuffer console.
>> 2. Run `systemctl suspend`. If undocked without secondary display,
>> suspend fails. If docked with secondary display, suspend succeeds.
>> 3. Resume from suspend if applicable.
>> 4. System is now in a broken state.
> 
> So I guess we need to put those devices to ACPI D3 for suspend. Let's
> discuss this on your preferred platform.

Ok, so I was already sort of afraid we might see something like this
happening because of:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89c290ea758911e660878e26270e084d862c03b0

As I mentioned during the review of that, it might be better to
not touch the video-card ACPI power-state at all and instead
only do acpi_device_fix_up_power() on the child devices.

Owen, attached are 2 patches which implement only
calling acpi_device_fix_up_power() on the child devices,
can you build a v6.6 kernel with these 2 patches added
on top please and see if that fixes things ?

Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
is still resolved after applying these patches ?

Regards,

Hans

From 68a819101c580bb89f34a31196ace81244ca8eb5 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Fri, 10 Nov 2023 12:52:39 +0100
Subject: [PATCH 1/2] ACPI: PM: Add acpi_device_fix_up_power_children()
 function

In some cases it is necessary to fix-up the power-state of an ACPI
device's children without touching the ACPI device itself add
a new acpi_device_fix_up_power_children() function for this.

Signed-off-by: Hans de Goede 
---
 drivers/acpi/device_pm.c | 13 +
 include/acpi/acpi_bus.h  |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index f007116a8427..3b4d048c4941 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -397,6 +397,19 @@ void acpi_device_fix_up_power_extended(struct acpi_device *adev)
 }
 EXPORT_SYMBOL_GPL(acpi_device_fix_up_power_extended);
 
+/**
+ * acpi_device_fix_up_power_children - Force a device's children into D0.
+ * @adev: Parent device object whose children's power state is to be fixed up.
+ *
+ * Call acpi_device_fix_up_power() for @adev's children so long as they
+ * are reported as present and enabled.
+ */
+void acpi_device_fix_up_power_children(struct acpi_device *adev)
+{
+	acpi_dev_for_each_child(adev, fix_up_power_if_applicable, NULL);
+}
+EXPORT_SYMBOL_GPL(acpi_device_fix_up_power_children);
+
 int acpi_device_update_power(struct acpi_device *device, int *state_p)
 {
 	int state;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 254685085c82..0b7eab0ef7d7 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -539,6 +539,7 @@ int acpi_device_set_power(struct acpi_device *device, int state);
 int acpi_bus_init_power(struct acpi_device *device);
 int acpi_device_fix_up_power(struct acpi_device *device);
 void acpi_device_fix_up_power_extended(struct acpi_device *adev);
+void acpi_device_fix_up_power_children(struct acpi_device *adev);
 int acpi_bus_update_power(acpi_handle handle, int *state_p);
 int acpi_device_update_power(struct acpi_device *device, int *state_p);
 bool acpi_bus_power_manageable(acpi_handle handle);
-- 
2.41.0

From 33e2d55917ac7082e8d98dc2a678a856f8d48352 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Fri, 10 Nov 2023 13:10:02 +0100
Subject: [PATCH 2/2] ACPI: video: Use acpi_device_fix_up_power_children()

Commit 89c290ea7589 ("ACPI: video: Put ACPI video and its child devices
into D0 on boot") introduced calling acpi_device_fix_up_power_extended()
on the video card for which the ACPI video bus is the companion device.

This unnecessarily touches the power-state of the GPU itself, while
the issue it tries to address only requires calling _PS0 on the child
devices.

Touching the power-state of the GPU itself is causing suspend / resume
issues on e.g. a Lenovo ThinkPad W530.

Instead use acpi_device_fix_up_power_children(), which only touches
the child devices, to fix this.

Fixes: 89c290ea7589 ("ACPI: video: Put ACPI video and its child devices into D0 on boot")
Reported-by: Owen T. Heisler 
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218124
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c | 2 +-
 1 file changed, 1 insertion(+), 1

Re: [Nouveau] [PATCH v2 6/9] PCI: Rename is_thunderbolt to is_tunneled

[Hans de Goede]

Hi,

On 11/3/23 20:07, Mario Limonciello wrote:
> The `is_thunderbolt` bit has been used to indicate that a PCIe device
> contained the Intel VSEC which is used by various parts of the kernel
> to change behavior. To later allow usage with USB4 controllers as well,
> rename this to `is_tunneled`.
> 
> Signed-off-by: Mario Limonciello 

Here is my ack for the trivial drivers/platform/x86/apple-gmux.c change:

Acked-by: Hans de Goede 

Bjorn, feel free to route this through the PCI tree.

Regards,

Hans




> ---
>  drivers/pci/pci.c | 2 +-
>  drivers/pci/probe.c   | 2 +-
>  drivers/platform/x86/apple-gmux.c | 2 +-
>  include/linux/pci.h   | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 59c01d68c6d5..d9aa5a39f585 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3032,7 +3032,7 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
>   return true;
>  
>   /* Even the oldest 2010 Thunderbolt controller supports D3. */
> - if (bridge->is_thunderbolt)
> + if (bridge->is_tunneled)
>   return true;
>  
>   /* Platform might know better if the bridge supports D3 */
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 795534589b98..518413d15402 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1597,7 +1597,7 @@ static void set_pcie_thunderbolt(struct pci_dev *dev)
>   /* Is the device part of a Thunderbolt controller? */
>   vsec = pci_find_vsec_capability(dev, PCI_VENDOR_ID_INTEL, 
> PCI_VSEC_ID_INTEL_TBT);
>   if (vsec)
> - dev->is_thunderbolt = 1;
> + dev->is_tunneled = 1;
>  }
>  
>  static void set_pcie_untrusted(struct pci_dev *dev)
> diff --git a/drivers/platform/x86/apple-gmux.c 
> b/drivers/platform/x86/apple-gmux.c
> index 1417e230edbd..20315aa4463a 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c
> @@ -774,7 +774,7 @@ static int gmux_resume(struct device *dev)
>  
>  static int is_thunderbolt(struct device *dev, void *data)
>  {
> - return to_pci_dev(dev)->is_thunderbolt;
> + return to_pci_dev(dev)->is_tunneled;
>  }
>  
>  static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 439c2dac8a3e..b1724f25fb02 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -440,7 +440,7 @@ struct pci_dev {
>   unsigned intis_virtfn:1;
>   unsigned intis_hotplug_bridge:1;
>   unsigned intshpc_managed:1; /* SHPC owned by shpchp */
> - unsigned intis_thunderbolt:1;   /* Thunderbolt controller */
> + unsigned intis_tunneled:1;  /* Tunneled TBT or USB4 link */
>   unsigned intno_command_complete:1;  /* No command completion */
>   /*
>* Devices marked being untrusted are the ones that can potentially

Re: [Nouveau] [PATCH 6.2 regression fix] drm/nouveau/kms: Fix backlight registration

[Hans de Goede]

Hi,

On 3/29/23 00:23, Lyude Paul wrote:
> Reviewed-by: Lyude Paul 
> 
> (Also note to Mark: this is my way of letting you know someone fixed the
> regression with backlight controls upstream, looking into the weird bright
> screen after resume issue)

Thanks.

I have pushed this to drm-misc-fixes now.

I'll also submit a downstream Fedora kernel pull-req with this
to get this resolved in the Fedora kernels .

Regards,

Hans



> 
> On Sun, 2023-03-26 at 22:54 +0200, Hans de Goede wrote:
>> The nouveau code used to call drm_fb_helper_initial_config() from
>> nouveau_fbcon_init() before calling drm_dev_register(). This would
>> probe all connectors so that drm_connector->status could be used during
>> backlight registration which runs from nouveau_connector_late_register().
>>
>> After commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
>> the fbdev emulation code, which now is a drm-client, can only run after
>> drm_dev_register(). So during backlight registration the connectors are
>> not probed yet and the drm_connector->status == connected check in
>> nv50_backlight_init() would now always fail.
>>
>> Replace the drm_connector->status == connected check with
>> a drm_helper_probe_detect() == connected check to fix nv_backlight
>> no longer getting registered because of this.
>>
>> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
>> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/202
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
>> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> index 40409a29f5b6..91b5ecc57538 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> @@ -33,6 +33,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "nouveau_drv.h"
>>  #include "nouveau_reg.h"
>> @@ -299,8 +300,12 @@ nv50_backlight_init(struct nouveau_backlight *bl,
>>  struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>>  struct nvif_object *device = >client.device.object;
>>  
>> +/*
>> + * Note when this runs the connectors have not been probed yet,
>> + * so nv_conn->base.status is not set yet.
>> + */
>>  if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) 
>> - 1)) ||
>> -nv_conn->base.status != connector_status_connected)
>> +drm_helper_probe_detect(_conn->base, NULL, false) != 
>> connector_status_connected)
>>  return -ENODEV;
>>  
>>  if (nv_conn->type == DCB_CONNECTOR_eDP) {
> 

[Nouveau] [PATCH 6.2 regression fix] drm/nouveau/kms: Fix backlight registration

[Hans de Goede]

The nouveau code used to call drm_fb_helper_initial_config() from
nouveau_fbcon_init() before calling drm_dev_register(). This would
probe all connectors so that drm_connector->status could be used during
backlight registration which runs from nouveau_connector_late_register().

After commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
the fbdev emulation code, which now is a drm-client, can only run after
drm_dev_register(). So during backlight registration the connectors are
not probed yet and the drm_connector->status == connected check in
nv50_backlight_init() would now always fail.

Replace the drm_connector->status == connected check with
a drm_helper_probe_detect() == connected check to fix nv_backlight
no longer getting registered because of this.

Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/202
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 40409a29f5b6..91b5ecc57538 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_reg.h"
@@ -299,8 +300,12 @@ nv50_backlight_init(struct nouveau_backlight *bl,
struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nvif_object *device = >client.device.object;
 
+   /*
+* Note when this runs the connectors have not been probed yet,
+* so nv_conn->base.status is not set yet.
+*/
if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) 
- 1)) ||
-   nv_conn->base.status != connector_status_connected)
+   drm_helper_probe_detect(_conn->base, NULL, false) != 
connector_status_connected)
return -ENODEV;
 
if (nv_conn->type == DCB_CONNECTOR_eDP) {
-- 
2.39.1

Re: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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

[Nouveau] [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: [Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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
  

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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);
 /

[Nouveau] [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

[Nouveau] [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

[Nouveau] [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: [Nouveau] [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: [Nouveau] [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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v3 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 150ef8214c73..9b84657f8f6a 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

[Nouveau] [PATCH v3 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 891138d47def..4545f9f1a5b1 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

Re: [Nouveau] [PATCH v4 11/31] drm/i915: Call acpi_video_register_backlight() (v2)

[Hans de Goede]

Hi,

On 8/24/22 14:47, Jani Nikula wrote:
> On Wed, 24 Aug 2022, Hans de Goede  wrote:
>> 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
>>
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/display/intel_display.c | 8 
>>  drivers/gpu/drm/i915/display/intel_panel.c   | 3 +++
>>  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
>>  3 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 6103b02c081f..2bb53efdb149 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -9088,6 +9088,14 @@ void intel_display_driver_register(struct 
>> drm_i915_private *i915)
>>  /* Must be done after probing outputs */
>>  intel_opregion_register(i915);
>>  acpi_video_register();
>> +/*
>> + * Only call this if i915 is driving the internal panel. If the internal
>> + * panel is not driven by i915 then another GPU driver may still 
>> register
>> + * a native backlight driver later and this should only be called after
>> + * any native backlights have been registered.
>> + */
>> +if (i915->have_panel)
>> +acpi_video_register_backlight();
> 
> Apologies for procrastinating the review.
> 
> Please let's not add new flags like have_panel to i915; we're trying to
> clean it up instead.
> 
> The code here needs to iterate over the connectors to decide. Maybe
> better abstracted a function.

So something like add a i915_have_panel() helper which iterates over all
the connectors and then of 1 of them is of the LVDS / eDP / DSI type
return true ?

Regards,

Hans



>>  intel_audio_init(i915);
>>  
>> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
>> b/drivers/gpu/drm/i915/display/intel_panel.c
>> index 237a40623dd7..4536c527f50c 100644
>> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>> @@ -646,8 +646,11 @@ intel_panel_mode_valid(struct intel_connector 
>> *connector,
>>  
>>  int intel_panel_init(struct intel_connector *connector)
>>  {
>> +struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>>  struct intel_panel *panel = >panel;
>>  
>> +dev_priv->have_panel = true;
>> +
>>  intel_backlight_init_funcs(panel);
>>  
>>  drm_dbg_kms(connector->base.dev,
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 69ce6db6a7c1..14b0dcaf25c2 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -756,6 +756,8 @@ struct drm_i915_private {
>>  
>>  bool ipc_enabled;
>>  
>> +bool have_panel;
>> +
>>  struct intel_audio_private audio;
>>  
>>  struct i915_pmu pmu;
> 

[Nouveau] [PATCH v4 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

[Nouveau] [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

[Nouveau] [PATCH v4 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/

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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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
  

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 11/31] drm/i915: Call acpi_video_register_backlight() (v2)

[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

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_display.c | 8 
 drivers/gpu/drm/i915/display/intel_panel.c   | 3 +++
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6103b02c081f..2bb53efdb149 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9088,6 +9088,14 @@ void intel_display_driver_register(struct 
drm_i915_private *i915)
/* Must be done after probing outputs */
intel_opregion_register(i915);
acpi_video_register();
+   /*
+* Only call this if i915 is driving the internal panel. If the internal
+* panel is not driven by i915 then another GPU driver may still 
register
+* a native backlight driver later and this should only be called after
+* any native backlights have been registered.
+*/
+   if (i915->have_panel)
+   acpi_video_register_backlight();
 
intel_audio_init(i915);
 
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 237a40623dd7..4536c527f50c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -646,8 +646,11 @@ intel_panel_mode_valid(struct intel_connector *connector,
 
 int intel_panel_init(struct intel_connector *connector)
 {
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
 
+   dev_priv->have_panel = true;
+
intel_backlight_init_funcs(panel);
 
drm_dbg_kms(connector->base.dev,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69ce6db6a7c1..14b0dcaf25c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -756,6 +756,8 @@ struct drm_i915_private {
 
bool ipc_enabled;
 
+   bool have_panel;
+
struct intel_audio_private audio;
 
struct i915_pmu pmu;
-- 
2.37.2

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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);
 /

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

[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.

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");
+   return 0;
+   }
+
memset(, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
 
-- 
2.37.2

[Nouveau] [PATCH v4 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

[Nouveau] [PATCH v4 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 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

Note the i915 patches (patch 2 and 12 still need a review/ack, and
I've dropped the previouw review of the nouveau patches because of
changes there. Please review.

This series as submitted is based on drm-tip for CI purposes.
I also have an immutable branch based on 6.0-rc1 with these
same patches available here:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=backlight-detect-refactor-v4
assuming the i915 patches also pass review I hope to 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
  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() (v2)
  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 +

Re: [Nouveau] [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper

[Hans de Goede]

Hi Daniel,

On 8/17/22 22:18, Daniel Dadap wrote:
> On 8/17/22 10:05 AM, Hans de Goede wrote:



>>> One further potential difficulty that I anticipate is that not all dynamic 
>>> mux systems use the EC backlight driver (or a similar, GPU-agnostic 
>>> driver), and rather have whichever GPU happens to be connected at the time 
>>> be responsible for the backlight. I had initially thought that supporting 
>>> the EC backlight interface was a requirement for OEMs to implement dynamic 
>>> mux support, but I recently learned this is not true in all cases. On 
>>> Windows, this requires coordinating the backlight controls of the two GPU 
>>> drivers across a mux switch, to load the state of the switched-away-from 
>>> GPU and set it on the switched-to GPU. I imagine for these systems we may 
>>> need to do some similar save/restore, probably managed by vga-switcheroo, 
>>> but it would require having both GPU drivers register their own native 
>>> backlight handlers (and possibly while one of them is not connected to the 
>>> panel).
>> Right, systems where the backlight control basically gets muxed from one GPU 
>> to the other GPU together with the panel's video-data lines exist. Currently 
>> Linux already register both native GPU backlight handlers in this case. e.g. 
>> /sys/class/backlight/intel_backlight and /sys/class/backlight/nouveau_bl.
>>
>> Userspace (atleast GNOME) has code which checks which GPU is actually 
>> connected to the panel using the panel's drm connector's status on each GPU 
>> (only one of which should report connected) and then uses the backlight 
>> interface associated with the connected connector.
>>
>>> Dynamic mux switching isn't actually supported on Linux, yet, so we should 
>>> be able to kick this particular can a little further down the road, but in 
>>> the meantime we should probably start planning for how best to handle this 
>>> sort of system under the "only one backlight handler per panel" model. 
>>> Maybe the vga-switcheroo handler can register its own backlight handler, 
>>> that then negotiates the actual backlight settings between the relevant GPU 
>>> drivers, possibly through a new vga-switcheroo client callback. I'll have 
>>> to think about this a bit more.
>> The "only one backlight handler per panel" model is actualy "only one 
>> backlight handler per panel"-connector since the new API uses drm properties 
>> on the drm connector object. With 2 GPUs both using their native backlight 
>> control there will be 2 connectors and userspace will/must use the one which 
>> is actually reporting that it is connected to the panel so this will work 
>> fine.
> 
> 
> That is a useful distinction. Would it fall under userspace's reponsibility, 
> then, to keep the brightness level synchronized across drm_connectors that 
> share a panel via a mux when performing a switch?

Yes typically the 2 different GPU drivers know nothing about the other GPU and 
I think it would be good to keep things that way. When switching userspace will 
see a disconnect on the panel connector on one GPU and then a connect on the 
connector on the other GPU at which point it knows that it should set the 
brightness on the now connected connector instead of on the old one.

> I suppose it's a cleaner design to leave it up to userspace to select which 
> backlight interface to manipulate.

Ack.

> That is a harder decision for userspace to make with the existing design, 
> which doesn't cleanly map sysfs backlight interfaces to individual 
> connectors, but if the UAPI is going to change to a drm_connector property, 
> backlight interfaces are obviously strongly correlated with the connectors.

Right.

>  I'm not sure how easy it is for userspace to solve the problem of 
> maintaining consistent brightness levels across a mux switch for an OLED 
> panel, where there really isn't a concept of a "backlight" to speak of, but I 
> suppose it wouldn't be any easier to do that in the kernel (e.g. with 
> vga-switcheroo).

The OLED brightness is send over DP-aux to the panel AFAIK, so as long as both 
drivers export the raw range of the panel's setting and don't try to get smart 
and scale or whatever then their should be a 1:1 mapping. Ideally for something 
like this both drivers would be using some shared drm-helper code / library to 
talk to the backlight, thus guaranteeing that both drivers interpret the scale 
the same.


>> If anything the nvidia-wmi-ec-backlight case is a but more tricky, the "only 
>> one backlight handler per panel" thing is actually more of a "only one 
>> 

[Nouveau] Question about selecting ACPI_VIDEO for nouveau on non X86 platforms

[Hans de Goede]

Hi All,

Since 6.0-rc1 it is possible for ACPI_VIDEO to be enabled on non X86
platforms. I already send an email about this being a possible problem
for nouveau, when nouveau is builtin and apci_video is a module:

https://lore.kernel.org/linux-acpi/a385b626-217f-25be-f076-7478da3d1...@redhat.com/

"""
I just noticed this change:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=038275d227841d4978ceceb397b584b4b39f2b50

--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -210,7 +210,7 @@ config ACPI_TINY_POWER_BUTTON_SIGNAL
 
 config ACPI_VIDEO
tristate "Video"
-   depends on X86 && BACKLIGHT_CLASS_DEVICE
+   depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
select THERMAL
help

I think this is going to cause random-config build errors because
at the nouveau driver calls acpi_video functions and it expects
those functions to either be there or to get the stubs.

This is an issue when acpi_video is build as a module and the
i915 / nouveau code is builtin.

To avoid this issue nouveau does a select on ACPI_VIDEO,
here is the code from drivers/gpu/drm/nouveau/Kconfig

# Similar to i915, we need to select ACPI_VIDEO and it's dependencies
select BACKLIGHT_CLASS_DEVICE if ACPI && X86
select INPUT if ACPI && X86
select THERMAL if ACPI && X86
select ACPI_VIDEO if ACPI && X86

notice the if ACPI && X86, since ACPI_VIDEO can now be selected
on ARM, this can lead to ACPI_VIDEO being enabled as
module (so no stubs) while nouveau can be builtin which will
lead to unresolved symbol errors in nouveau when building the zImage.

I believe that to fix this the conditions after the select must
be changed from "if ACPI && X86" to just "if ACPI"
"""

I was looking at a lkp warning in my backlight refactor series
which is explained by the above today:

https://lore.kernel.org/lkml/202208231625.ichjrxdi-...@intel.com/

and while working on fixing this I noticed that nouveau not
only assumes ACPI[_VIDEO] is only available on X86 in its Kconfig
but also in other places:

drivers/gpu/drm/nouveau/Kbuild:

ifdef CONFIG_X86
nouveau-$(CONFIG_ACPI) += nouveau_acpi.o
endif

drivers/gpu/drm/nouveau/nouveau_acpi.h:

#if defined(CONFIG_ACPI) && defined(CONFIG_X86)
bool nouveau_is_optimus(void);
...
#else
static inline bool nouveau_is_optimus(void) { return false; };
...
#endif

Since currently the only nouveau dep on acpi_video is
inside nouveau_acpi.c the not building + stubbing of
nouveau_acpi.c is saving us from the problem which I expected
in my mail quoted above.

The backlight refactor series breaks this though, because
it adds calls to:
acpi_video_backlight_use_native()
acpi_video_register_backlight()

to nouveau outside of the drivers/gpu/drm/nouveau/nouveau_acpi.c
file.

To fix this for the next version of the backlight refactor series
I have added wrappers for:
acpi_video_backlight_use_native()
acpi_video_register_backlight()
to nouveau_acpi.?

After thinking about this a bit this seemed by far the cleanest
and consistent with how the current nouveau code is abstracting
other ACPI use, so this makes the backlight changes consistent
with existing nouveau practices.

Lyude, because of these changes I've dropped your Reviewed-by.
I'll send out a new version 4 series sometime today, can you
please re-review the 2 nouveau patches?

###

My first instinct to fix this, was to adjust the nouveau Kconfig bits
selecting ACPI_VIDEO to take into account that it now is available
on non X86 too:

diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 03d12caf9e26..26b895a49b9c 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -16,10 +16,10 @@ config DRM_NOUVEAU
select MXM_WMI if ACPI && X86
select POWER_SUPPLY
# Similar to i915, we need to select ACPI_VIDEO and it's dependencies
-   select BACKLIGHT_CLASS_DEVICE if ACPI && X86
-   select INPUT if ACPI && X86
-   select THERMAL if ACPI && X86
-   select ACPI_VIDEO if ACPI && X86
+   select BACKLIGHT_CLASS_DEVICE if ACPI
+   select INPUT if ACPI
+   select THERMAL if ACPI
+   select ACPI_VIDEO if ACPI
select SND_HDA_COMPONENT if SND_HDA_CORE
help
  Choose this option for open-source NVIDIA support.

We could still make this change together with Kbuild +
nouveau_acpi.h to build on non x86 too. This might be good to
prepare for some aarch64 devices which may use some of the
ACPI bits, they may need e.g. acpi_video_get_edid().

OTOH this might cause unexpected issue so it might be better
to wait with making such a change until it is actually
necessary.

Regards,

Hans

Re: [Nouveau] [PATCH v3 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header

[Hans de Goede]

Hi,

On 8/18/22 21:38, Daniel Dadap wrote:
> 
> On 8/18/22 1:42 PM, Hans de Goede wrote:
>> Move the WMI interface definitions to a header, so that the definitions
>> can be shared with drivers/acpi/video_detect.c .
>>
>> Suggested-by: Daniel Dadap 
>> Signed-off-by: Hans de Goede 
>> ---
>>   MAINTAINERS   |  1 +
>>   .../platform/x86/nvidia-wmi-ec-backlight.c    | 66 +
>>   .../x86/nvidia-wmi-ec-backlight.h | 70 +++
>>   3 files changed, 72 insertions(+), 65 deletions(-)
>>   create mode 100644 
>> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8a5012ba6ff9..8d59c6e9b4db 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -14526,6 +14526,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..e84e1d629b14 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 ig

Re: [Nouveau] [PATCH v3 09/31] ACPI: video: Make backlight class device registration a separate step (v2)

[Hans de Goede]

Hi,

On 8/18/22 22:07, Daniel Dadap wrote:
> 
> On 8/18/22 1:42 PM, Hans de Goede wrote:
>> 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);
> 
> 
> Would it make sense to make this parameter writable from userspace, e.g. so 
> that it can be set by a udev rule rather than relying on a riskier kernel 
> command line edit? Then again, that probably makes things more complicated, 
> since you'd have to check the parameter again when the worker fires, and 
> changing the parameter to a non-zero value from either zero or a different 
> non-zero value would be too weird. And making a separate writable parameter 
> to allow userspace to turn the worker into a noop despite it being enabled 
> when the kernel was initially loaded seems wrong, too.

Right, you have pretty much described yourself why making this parameter
runtime configurable is not really feasible :)

Regards,

Hans



> 
> 
>> +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

[Nouveau] [PATCH v3 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/

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

[Nouveau] [PATCH v3 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 a871ee69fcb2..66ea650fb45f 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

[Nouveau] [PATCH v3 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 84ae22670e54..ce6d89fcdc0e 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

[Nouveau] [PATCH v3 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 66ea650fb45f..84ae22670e54 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

[Nouveau] [PATCH v3 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 ce6d89fcdc0e..150ef8214c73 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

[Nouveau] [PATCH v3 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 1574ff837e31..a871ee69fcb2 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

[Nouveau] [PATCH v3 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 4545f9f1a5b1..1574ff837e31 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