Merge tag 'platform-drivers-x86-v6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver updates from Hans de Goede:

 - AMD Platform Management Framework (PMF) driver with AMT and QnQF
   support

 - AMD PMC: Improved logging for debugging s2idle issues

 - Big refactor of the ACPI/x86 backlight handling, ensuring that we
   only register 1 /sys/class/backlight device per LCD panel

 - Microsoft Surface:
    - Surface Laptop Go 2 support
    - Surface Pro 8 HID sensor support

 - Asus WMI:
    - Lots of cleanups
    - Support for TUF RGB keyboard backlight control
    - Add support for ROG X13 tablet mode

 - Siemens Simatic: IPC227G and IPC427G support

 - Toshiba ACPI laptop driver: Fan hwmon and battery ECO mode support

 - tools/power/x86/intel-speed-select: Various improvements

 - Various cleanups

 - Various small bugfixes

* tag 'platform-drivers-x86-v6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (153 commits)
  platform/x86: use PLATFORM_DEVID_NONE instead of -1
  platform/x86/amd: pmc: Dump idle mask during "check" stage instead
  platform/x86/intel/wmi: thunderbolt: Use dev_groups callback
  platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks
  platform/surface: Split memcpy() of struct ssam_event flexible array
  platform/x86: compal-laptop: Get rid of a few forward declarations
  platform/x86: intel-uncore-freq: Use sysfs_emit() to instead of scnprintf()
  platform/x86: dell-smbios-base: Use sysfs_emit()
  platform/x86/amd/pmf: Remove unused power_delta instances
  platform/x86/amd/pmf: install notify handler after acpi init
  Documentation/ABI/testing/sysfs-amd-pmf: Add ABI doc for AMD PMF
  platform/x86/amd/pmf: Add sysfs to toggle CnQF
  platform/x86/amd/pmf: Add support for CnQF
  platform/x86/amd: pmc: Fix build without debugfs
  platform/x86: hp-wmi: Support touchpad on/off
  platform/x86: int3472/discrete: Drop a forward declaration
  platform/x86: toshiba_acpi: change turn_on_panel_on_resume to static
  platform/x86: wmi: Drop forward declaration of static functions
  platform/x86: toshiba_acpi: Remove duplicate include
  platform/x86: msi-laptop: Change DMI match / alias strings to fix module autoloading
  ...

1 files changed, 68 insertions, 0 deletions

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 513b20ccef1e..7ff89559b3b7 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -715,6 +715,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
 ===========