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-7d30c49fee2d@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-652f50343158@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 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 + .../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 +- .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/acer-wmi.c | 66 --- drivers/platform/x86/apple-gmux.c | 3 - drivers/platform/x86/asus-nb-wmi.c | 21 - drivers/platform/x86/asus-wmi.c | 13 - drivers/platform/x86/asus-wmi.h | 2 - drivers/platform/x86/eeepc-wmi.c | 25 +- .../platform/x86/nvidia-wmi-ec-backlight.c | 82 +--- drivers/platform/x86/samsung-laptop.c | 87 ---- drivers/platform/x86/toshiba_acpi.c | 16 - include/acpi/video.h | 9 +- .../x86/nvidia-wmi-ec-backlight.h | 76 ++++ 32 files changed, 588 insertions(+), 507 deletions(-) create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h -- 2.37.2
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-7d30c49fee2d@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-652f50343158@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 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 + .../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 +- .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/acer-wmi.c | 66 --- drivers/platform/x86/apple-gmux.c | 3 - drivers/platform/x86/asus-nb-wmi.c | 21 - drivers/platform/x86/asus-wmi.c | 13 - drivers/platform/x86/asus-wmi.h | 2 - drivers/platform/x86/eeepc-wmi.c | 25 +- .../platform/x86/nvidia-wmi-ec-backlight.c | 82 +--- drivers/platform/x86/samsung-laptop.c | 87 ---- drivers/platform/x86/toshiba_acpi.c | 16 - include/acpi/video.h | 9 +- .../x86/nvidia-wmi-ec-backlight.h | 76 ++++ 32 files changed, 588 insertions(+), 507 deletions(-) create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h -- 2.37.2
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-7d30c49fee2d@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-652f50343158@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 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 + .../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 +- .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/acer-wmi.c | 66 --- drivers/platform/x86/apple-gmux.c | 3 - drivers/platform/x86/asus-nb-wmi.c | 21 - drivers/platform/x86/asus-wmi.c | 13 - drivers/platform/x86/asus-wmi.h | 2 - drivers/platform/x86/eeepc-wmi.c | 25 +- .../platform/x86/nvidia-wmi-ec-backlight.c | 82 +--- drivers/platform/x86/samsung-laptop.c | 87 ---- drivers/platform/x86/toshiba_acpi.c | 16 - include/acpi/video.h | 9 +- .../x86/nvidia-wmi-ec-backlight.h | 76 ++++ 32 files changed, 588 insertions(+), 507 deletions(-) create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h -- 2.37.2
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-7d30c49fee2d@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-652f50343158@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 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 + .../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 +- .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/acer-wmi.c | 66 --- drivers/platform/x86/apple-gmux.c | 3 - drivers/platform/x86/asus-nb-wmi.c | 21 - drivers/platform/x86/asus-wmi.c | 13 - drivers/platform/x86/asus-wmi.h | 2 - drivers/platform/x86/eeepc-wmi.c | 25 +- .../platform/x86/nvidia-wmi-ec-backlight.c | 82 +--- drivers/platform/x86/samsung-laptop.c | 87 ---- drivers/platform/x86/toshiba_acpi.c | 16 - include/acpi/video.h | 9 +- .../x86/nvidia-wmi-ec-backlight.h | 76 ++++ 32 files changed, 588 insertions(+), 507 deletions(-) create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h -- 2.37.2
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-7d30c49fee2d@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-652f50343158@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 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 + .../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 +- .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/acer-wmi.c | 66 --- drivers/platform/x86/apple-gmux.c | 3 - drivers/platform/x86/asus-nb-wmi.c | 21 - drivers/platform/x86/asus-wmi.c | 13 - drivers/platform/x86/asus-wmi.h | 2 - drivers/platform/x86/eeepc-wmi.c | 25 +- .../platform/x86/nvidia-wmi-ec-backlight.c | 82 +--- drivers/platform/x86/samsung-laptop.c | 87 ---- drivers/platform/x86/toshiba_acpi.c | 16 - include/acpi/video.h | 9 +- .../x86/nvidia-wmi-ec-backlight.h | 76 ++++ 32 files changed, 588 insertions(+), 507 deletions(-) create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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); /* * Note: The value returned by acpi_video_handles_brightness_key_presses() @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void) { return acpi_backlight_vendor; } +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) { } -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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); /* * Note: The value returned by acpi_video_handles_brightness_key_presses() @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void) { return acpi_backlight_vendor; } +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) { } -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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); /* * Note: The value returned by acpi_video_handles_brightness_key_presses() @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void) { return acpi_backlight_vendor; } +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) { } -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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); /* * Note: The value returned by acpi_video_handles_brightness_key_presses() @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void) { return acpi_backlight_vendor; } +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) { } -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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); /* * Note: The value returned by acpi_video_handles_brightness_key_presses() @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void) { return acpi_backlight_vendor; } +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) { } -- 2.37.2
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 <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pwm.h> #include <linux/string_helpers.h> +#include <acpi/video.h> + #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(&i915->drm, "Skipping intel_backlight registration\n"); + return 0; + } + memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; -- 2.37.2
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 <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pwm.h> #include <linux/string_helpers.h> +#include <acpi/video.h> + #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(&i915->drm, "Skipping intel_backlight registration\n"); + return 0; + } + memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; -- 2.37.2
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 <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pwm.h> #include <linux/string_helpers.h> +#include <acpi/video.h> + #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(&i915->drm, "Skipping intel_backlight registration\n"); + return 0; + } + memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; -- 2.37.2
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 <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pwm.h> #include <linux/string_helpers.h> +#include <acpi/video.h> + #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(&i915->drm, "Skipping intel_backlight registration\n"); + return 0; + } + memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; -- 2.37.2
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 <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pwm.h> #include <linux/string_helpers.h> +#include <acpi/video.h> + #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(&i915->drm, "Skipping intel_backlight registration\n"); + return 0; + } + memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; -- 2.37.2
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pci.h> +#include <acpi/video.h> + #include <drm/drm_crtc_helper.h> #include <drm/amdgpu_drm.h> #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 <drm/drm_gem_atomic_helper.h> #include <drm/drm_plane_helper.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pci.h> +#include <acpi/video.h> + #include <drm/drm_crtc_helper.h> #include <drm/amdgpu_drm.h> #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 <drm/drm_gem_atomic_helper.h> #include <drm/drm_plane_helper.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pci.h> +#include <acpi/video.h> + #include <drm/drm_crtc_helper.h> #include <drm/amdgpu_drm.h> #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 <drm/drm_gem_atomic_helper.h> #include <drm/drm_plane_helper.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pci.h> +#include <acpi/video.h> + #include <drm/drm_crtc_helper.h> #include <drm/amdgpu_drm.h> #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 <drm/drm_gem_atomic_helper.h> #include <drm/drm_plane_helper.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/pci.h> +#include <acpi/video.h> + #include <drm/drm_crtc_helper.h> #include <drm/amdgpu_drm.h> #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 <drm/drm_gem_atomic_helper.h> #include <drm/drm_plane_helper.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_file.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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 <drm/drm_util.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_file.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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 <drm/drm_util.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_file.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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 <drm/drm_util.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_file.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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 <drm/drm_util.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_file.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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 <drm/drm_util.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(®ister_count_mutex); - if (register_count) { - mutex_lock(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_list_lock); - } - mutex_unlock(®ister_count_mutex); + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_unregister_backlight(video); + mutex_unlock(&video_list_lock); } bool acpi_video_handles_brightness_key_presses(void) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(®ister_count_mutex); - if (register_count) { - mutex_lock(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_list_lock); - } - mutex_unlock(®ister_count_mutex); + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_unregister_backlight(video); + mutex_unlock(&video_list_lock); } bool acpi_video_handles_brightness_key_presses(void) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(®ister_count_mutex); - if (register_count) { - mutex_lock(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_list_lock); - } - mutex_unlock(®ister_count_mutex); + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_unregister_backlight(video); + mutex_unlock(&video_list_lock); } bool acpi_video_handles_brightness_key_presses(void) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(®ister_count_mutex); - if (register_count) { - mutex_lock(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_list_lock); - } - mutex_unlock(®ister_count_mutex); + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_unregister_backlight(video); + mutex_unlock(&video_list_lock); } bool acpi_video_handles_brightness_key_presses(void) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(®ister_count_mutex); - if (register_count) { - mutex_lock(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_list_lock); - } - mutex_unlock(®ister_count_mutex); + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_unregister_backlight(video); + mutex_unlock(&video_list_lock); } bool acpi_video_handles_brightness_key_presses(void) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video->entry, &video_bus_head); mutex_unlock(&video_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(&video_bus_register_backlight_work, + register_backlight_delay * HZ); + leave: mutex_unlock(®ister_count_mutex); return ret; @@ -2245,6 +2277,7 @@ void acpi_video_unregister(void) { mutex_lock(®ister_count_mutex); if (register_count) { + cancel_delayed_work_sync(&video_bus_register_backlight_work); acpi_bus_unregister_driver(&acpi_video_bus); register_count = 0; may_report_brightness_keys = false; @@ -2253,6 +2286,17 @@ void acpi_video_unregister(void) } EXPORT_SYMBOL(acpi_video_unregister); +void acpi_video_register_backlight(void) +{ + struct acpi_video_bus *video; + + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_register_backlight(video); + mutex_unlock(&video_list_lock); +} +EXPORT_SYMBOL(acpi_video_register_backlight); + void acpi_video_unregister_backlight(void) { struct acpi_video_bus *video; diff --git a/include/acpi/video.h b/include/acpi/video.h index 4705e339c252..0625806d3bbd 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -53,6 +53,7 @@ enum acpi_backlight_type { #if IS_ENABLED(CONFIG_ACPI_VIDEO) extern int acpi_video_register(void); extern void acpi_video_unregister(void); +extern void acpi_video_register_backlight(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); @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device, #else static inline int acpi_video_register(void) { return -ENODEV; } static inline void acpi_video_unregister(void) { return; } +static inline void acpi_video_register_backlight(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) { -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video->entry, &video_bus_head); mutex_unlock(&video_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(&video_bus_register_backlight_work, + register_backlight_delay * HZ); + leave: mutex_unlock(®ister_count_mutex); return ret; @@ -2245,6 +2277,7 @@ void acpi_video_unregister(void) { mutex_lock(®ister_count_mutex); if (register_count) { + cancel_delayed_work_sync(&video_bus_register_backlight_work); acpi_bus_unregister_driver(&acpi_video_bus); register_count = 0; may_report_brightness_keys = false; @@ -2253,6 +2286,17 @@ void acpi_video_unregister(void) } EXPORT_SYMBOL(acpi_video_unregister); +void acpi_video_register_backlight(void) +{ + struct acpi_video_bus *video; + + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_register_backlight(video); + mutex_unlock(&video_list_lock); +} +EXPORT_SYMBOL(acpi_video_register_backlight); + void acpi_video_unregister_backlight(void) { struct acpi_video_bus *video; diff --git a/include/acpi/video.h b/include/acpi/video.h index 4705e339c252..0625806d3bbd 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -53,6 +53,7 @@ enum acpi_backlight_type { #if IS_ENABLED(CONFIG_ACPI_VIDEO) extern int acpi_video_register(void); extern void acpi_video_unregister(void); +extern void acpi_video_register_backlight(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); @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device, #else static inline int acpi_video_register(void) { return -ENODEV; } static inline void acpi_video_unregister(void) { return; } +static inline void acpi_video_register_backlight(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) { -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video->entry, &video_bus_head); mutex_unlock(&video_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(&video_bus_register_backlight_work, + register_backlight_delay * HZ); + leave: mutex_unlock(®ister_count_mutex); return ret; @@ -2245,6 +2277,7 @@ void acpi_video_unregister(void) { mutex_lock(®ister_count_mutex); if (register_count) { + cancel_delayed_work_sync(&video_bus_register_backlight_work); acpi_bus_unregister_driver(&acpi_video_bus); register_count = 0; may_report_brightness_keys = false; @@ -2253,6 +2286,17 @@ void acpi_video_unregister(void) } EXPORT_SYMBOL(acpi_video_unregister); +void acpi_video_register_backlight(void) +{ + struct acpi_video_bus *video; + + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_register_backlight(video); + mutex_unlock(&video_list_lock); +} +EXPORT_SYMBOL(acpi_video_register_backlight); + void acpi_video_unregister_backlight(void) { struct acpi_video_bus *video; diff --git a/include/acpi/video.h b/include/acpi/video.h index 4705e339c252..0625806d3bbd 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -53,6 +53,7 @@ enum acpi_backlight_type { #if IS_ENABLED(CONFIG_ACPI_VIDEO) extern int acpi_video_register(void); extern void acpi_video_unregister(void); +extern void acpi_video_register_backlight(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); @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device, #else static inline int acpi_video_register(void) { return -ENODEV; } static inline void acpi_video_unregister(void) { return; } +static inline void acpi_video_register_backlight(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) { -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video->entry, &video_bus_head); mutex_unlock(&video_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(&video_bus_register_backlight_work, + register_backlight_delay * HZ); + leave: mutex_unlock(®ister_count_mutex); return ret; @@ -2245,6 +2277,7 @@ void acpi_video_unregister(void) { mutex_lock(®ister_count_mutex); if (register_count) { + cancel_delayed_work_sync(&video_bus_register_backlight_work); acpi_bus_unregister_driver(&acpi_video_bus); register_count = 0; may_report_brightness_keys = false; @@ -2253,6 +2286,17 @@ void acpi_video_unregister(void) } EXPORT_SYMBOL(acpi_video_unregister); +void acpi_video_register_backlight(void) +{ + struct acpi_video_bus *video; + + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_register_backlight(video); + mutex_unlock(&video_list_lock); +} +EXPORT_SYMBOL(acpi_video_register_backlight); + void acpi_video_unregister_backlight(void) { struct acpi_video_bus *video; diff --git a/include/acpi/video.h b/include/acpi/video.h index 4705e339c252..0625806d3bbd 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -53,6 +53,7 @@ enum acpi_backlight_type { #if IS_ENABLED(CONFIG_ACPI_VIDEO) extern int acpi_video_register(void); extern void acpi_video_unregister(void); +extern void acpi_video_register_backlight(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); @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device, #else static inline int acpi_video_register(void) { return -ENODEV; } static inline void acpi_video_unregister(void) { return; } +static inline void acpi_video_register_backlight(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) { -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video->entry, &video_bus_head); mutex_unlock(&video_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(&video_bus_register_backlight_work, + register_backlight_delay * HZ); + leave: mutex_unlock(®ister_count_mutex); return ret; @@ -2245,6 +2277,7 @@ void acpi_video_unregister(void) { mutex_lock(®ister_count_mutex); if (register_count) { + cancel_delayed_work_sync(&video_bus_register_backlight_work); acpi_bus_unregister_driver(&acpi_video_bus); register_count = 0; may_report_brightness_keys = false; @@ -2253,6 +2286,17 @@ void acpi_video_unregister(void) } EXPORT_SYMBOL(acpi_video_unregister); +void acpi_video_register_backlight(void) +{ + struct acpi_video_bus *video; + + mutex_lock(&video_list_lock); + list_for_each_entry(video, &video_bus_head, entry) + acpi_video_bus_register_backlight(video); + mutex_unlock(&video_list_lock); +} +EXPORT_SYMBOL(acpi_video_register_backlight); + void acpi_video_unregister_backlight(void) { struct acpi_video_bus *video; diff --git a/include/acpi/video.h b/include/acpi/video.h index 4705e339c252..0625806d3bbd 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -53,6 +53,7 @@ enum acpi_backlight_type { #if IS_ENABLED(CONFIG_ACPI_VIDEO) extern int acpi_video_register(void); extern void acpi_video_unregister(void); +extern void acpi_video_register_backlight(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); @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device, #else static inline int acpi_video_register(void) { return -ENODEV; } static inline void acpi_video_unregister(void) { return; } +static inline void acpi_video_register_backlight(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) { -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&backlight_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, &video_caps, NULL); - INIT_WORK(&backlight_notify_work, - acpi_video_backlight_notify_work); - backlight_nb.notifier_call = acpi_video_backlight_notify; - backlight_nb.priority = 0; - if (backlight_register_notifier(&backlight_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(&backlight_nb); -} -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&backlight_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, &video_caps, NULL); - INIT_WORK(&backlight_notify_work, - acpi_video_backlight_notify_work); - backlight_nb.notifier_call = acpi_video_backlight_notify; - backlight_nb.priority = 0; - if (backlight_register_notifier(&backlight_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(&backlight_nb); -} -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&backlight_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, &video_caps, NULL); - INIT_WORK(&backlight_notify_work, - acpi_video_backlight_notify_work); - backlight_nb.notifier_call = acpi_video_backlight_notify; - backlight_nb.priority = 0; - if (backlight_register_notifier(&backlight_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(&backlight_nb); -} -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&backlight_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, &video_caps, NULL); - INIT_WORK(&backlight_notify_work, - acpi_video_backlight_notify_work); - backlight_nb.notifier_call = acpi_video_backlight_notify; - backlight_nb.priority = 0; - if (backlight_register_notifier(&backlight_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(&backlight_nb); -} -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&backlight_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, &video_caps, NULL); - INIT_WORK(&backlight_notify_work, - acpi_video_backlight_notify_work); - backlight_nb.notifier_call = acpi_video_backlight_notify; - backlight_nb.priority = 0; - if (backlight_register_notifier(&backlight_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(&backlight_nb); -} -- 2.37.2
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 <hdegoede@redhat.com> --- 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 <linux/pci.h> #include <linux/acpi.h> +#include <acpi/video.h> #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(&i915->drm, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + struct intel_panel *panel = &to_intel_connector(connector)->panel; + + if (panel->backlight.funcs && !panel->backlight.device) { + acpi_video_register_backlight(); + break; + } + } + drm_connector_list_iter_end(&conn_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
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 <hdegoede@redhat.com> --- 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 <linux/pci.h> #include <linux/acpi.h> +#include <acpi/video.h> #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(&i915->drm, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + struct intel_panel *panel = &to_intel_connector(connector)->panel; + + if (panel->backlight.funcs && !panel->backlight.device) { + acpi_video_register_backlight(); + break; + } + } + drm_connector_list_iter_end(&conn_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
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 <hdegoede@redhat.com> --- 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 <linux/pci.h> #include <linux/acpi.h> +#include <acpi/video.h> #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(&i915->drm, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + struct intel_panel *panel = &to_intel_connector(connector)->panel; + + if (panel->backlight.funcs && !panel->backlight.device) { + acpi_video_register_backlight(); + break; + } + } + drm_connector_list_iter_end(&conn_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
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 <hdegoede@redhat.com> --- 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 <linux/pci.h> #include <linux/acpi.h> +#include <acpi/video.h> #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(&i915->drm, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + struct intel_panel *panel = &to_intel_connector(connector)->panel; + + if (panel->backlight.funcs && !panel->backlight.device) { + acpi_video_register_backlight(); + break; + } + } + drm_connector_list_iter_end(&conn_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
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 <hdegoede@redhat.com> --- 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 <linux/pci.h> #include <linux/acpi.h> +#include <acpi/video.h> #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(&i915->drm, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { + struct intel_panel *panel = &to_intel_connector(connector)->panel; + + if (panel->backlight.funcs && !panel->backlight.device) { + acpi_video_register_backlight(); + break; + } + } + drm_connector_list_iter_end(&conn_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
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 <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_device.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_device.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_device.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_device.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <drm/drm_device.h> #include <drm/radeon_drm.h> +#include <acpi/video.h> + #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
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 <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <ddadap@nvidia.com> L: platform-driver-x86@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 <kbusch@kernel.org> 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 <linux/backlight.h> #include <linux/mod_devicetable.h> #include <linux/module.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> -/** - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved. + */ + +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H + +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7" + +/** + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE. + */ +struct wmi_brightness_args { + u32 mode; + u32 val; + u32 ret; + u32 ignored[3]; +}; + +#endif -- 2.37.2
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 <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <ddadap@nvidia.com> L: platform-driver-x86@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 <kbusch@kernel.org> 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 <linux/backlight.h> #include <linux/mod_devicetable.h> #include <linux/module.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> -/** - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved. + */ + +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H + +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7" + +/** + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE. + */ +struct wmi_brightness_args { + u32 mode; + u32 val; + u32 ret; + u32 ignored[3]; +}; + +#endif -- 2.37.2
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 <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <ddadap@nvidia.com> L: platform-driver-x86@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 <kbusch@kernel.org> 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 <linux/backlight.h> #include <linux/mod_devicetable.h> #include <linux/module.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> -/** - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved. + */ + +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H + +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7" + +/** + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE. + */ +struct wmi_brightness_args { + u32 mode; + u32 val; + u32 ret; + u32 ignored[3]; +}; + +#endif -- 2.37.2
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 <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <ddadap@nvidia.com> L: platform-driver-x86@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 <kbusch@kernel.org> 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 <linux/backlight.h> #include <linux/mod_devicetable.h> #include <linux/module.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> -/** - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved. + */ + +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H + +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7" + +/** + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE. + */ +struct wmi_brightness_args { + u32 mode; + u32 val; + u32 ret; + u32 ignored[3]; +}; + +#endif -- 2.37.2
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 <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <ddadap@nvidia.com> L: platform-driver-x86@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 <kbusch@kernel.org> 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 <linux/backlight.h> #include <linux/mod_devicetable.h> #include <linux/module.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> -/** - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved. + */ + +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H + +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7" + +/** + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE. + */ +struct wmi_brightness_args { + u32 mode; + u32 val; + u32 ret; + u32 ignored[3]; +}; + +#endif -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&init_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/dmi.h> #include <linux/module.h> #include <linux/pci.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/workqueue.h> #include <acpi/video.h> @@ -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), &args }; + acpi_status status; + + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); + 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, &video_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 select INPUT if ACPI + select X86_PLATFORM_DEVICES if ACPI + select ACPI_WMI if ACPI select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI select SYNC_FILE diff --git a/include/acpi/video.h b/include/acpi/video.h index 0625806d3bbd..91578e77ac4e 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -48,6 +48,7 @@ enum acpi_backlight_type { acpi_backlight_video, acpi_backlight_vendor, acpi_backlight_native, + acpi_backlight_nvidia_wmi_ec, }; #if IS_ENABLED(CONFIG_ACPI_VIDEO) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/dmi.h> #include <linux/module.h> #include <linux/pci.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/workqueue.h> #include <acpi/video.h> @@ -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), &args }; + acpi_status status; + + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); + 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, &video_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 select INPUT if ACPI + select X86_PLATFORM_DEVICES if ACPI + select ACPI_WMI if ACPI select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI select SYNC_FILE diff --git a/include/acpi/video.h b/include/acpi/video.h index 0625806d3bbd..91578e77ac4e 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -48,6 +48,7 @@ enum acpi_backlight_type { acpi_backlight_video, acpi_backlight_vendor, acpi_backlight_native, + acpi_backlight_nvidia_wmi_ec, }; #if IS_ENABLED(CONFIG_ACPI_VIDEO) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/dmi.h> #include <linux/module.h> #include <linux/pci.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/workqueue.h> #include <acpi/video.h> @@ -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), &args }; + acpi_status status; + + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); + 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, &video_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 select INPUT if ACPI + select X86_PLATFORM_DEVICES if ACPI + select ACPI_WMI if ACPI select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI select SYNC_FILE diff --git a/include/acpi/video.h b/include/acpi/video.h index 0625806d3bbd..91578e77ac4e 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -48,6 +48,7 @@ enum acpi_backlight_type { acpi_backlight_video, acpi_backlight_vendor, acpi_backlight_native, + acpi_backlight_nvidia_wmi_ec, }; #if IS_ENABLED(CONFIG_ACPI_VIDEO) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/dmi.h> #include <linux/module.h> #include <linux/pci.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/workqueue.h> #include <acpi/video.h> @@ -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), &args }; + acpi_status status; + + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); + 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, &video_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 select INPUT if ACPI + select X86_PLATFORM_DEVICES if ACPI + select ACPI_WMI if ACPI select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI select SYNC_FILE diff --git a/include/acpi/video.h b/include/acpi/video.h index 0625806d3bbd..91578e77ac4e 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -48,6 +48,7 @@ enum acpi_backlight_type { acpi_backlight_video, acpi_backlight_vendor, acpi_backlight_native, + acpi_backlight_nvidia_wmi_ec, }; #if IS_ENABLED(CONFIG_ACPI_VIDEO) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/dmi.h> #include <linux/module.h> #include <linux/pci.h> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/workqueue.h> #include <acpi/video.h> @@ -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), &args }; + acpi_status status; + + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); + 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, &video_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 select INPUT if ACPI + select X86_PLATFORM_DEVICES if ACPI + select ACPI_WMI if ACPI select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI select SYNC_FILE diff --git a/include/acpi/video.h b/include/acpi/video.h index 0625806d3bbd..91578e77ac4e 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -48,6 +48,7 @@ enum acpi_backlight_type { acpi_backlight_video, acpi_backlight_vendor, acpi_backlight_native, + acpi_backlight_nvidia_wmi_ec, }; #if IS_ENABLED(CONFIG_ACPI_VIDEO) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/export.h> #include <linux/acpi.h> +#include <linux/apple-gmux.h> #include <linux/backlight.h> #include <linux/dmi.h> #include <linux/module.h> @@ -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/export.h> #include <linux/acpi.h> +#include <linux/apple-gmux.h> #include <linux/backlight.h> #include <linux/dmi.h> #include <linux/module.h> @@ -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/export.h> #include <linux/acpi.h> +#include <linux/apple-gmux.h> #include <linux/backlight.h> #include <linux/dmi.h> #include <linux/module.h> @@ -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/export.h> #include <linux/acpi.h> +#include <linux/apple-gmux.h> #include <linux/backlight.h> #include <linux/dmi.h> #include <linux/module.h> @@ -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/export.h> #include <linux/acpi.h> +#include <linux/apple-gmux.h> #include <linux/backlight.h> #include <linux/dmi.h> #include <linux/module.h> @@ -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
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 <ddadap@nvidia.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> +#include <acpi/video.h> /** * 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, &source); - 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
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 <ddadap@nvidia.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> +#include <acpi/video.h> /** * 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, &source); - 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
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 <ddadap@nvidia.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> +#include <acpi/video.h> /** * 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, &source); - 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
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 <ddadap@nvidia.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> +#include <acpi/video.h> /** * 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, &source); - 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
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 <ddadap@nvidia.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> #include <linux/types.h> #include <linux/wmi.h> +#include <acpi/video.h> /** * 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, &source); - 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
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 <hdegoede@redhat.com> --- 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 <linux/delay.h> #include <linux/pci.h> #include <linux/vga_switcheroo.h> -#include <acpi/video.h> #include <asm/io.h> /** @@ -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
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 <hdegoede@redhat.com> --- 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 <linux/delay.h> #include <linux/pci.h> #include <linux/vga_switcheroo.h> -#include <acpi/video.h> #include <asm/io.h> /** @@ -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
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 <hdegoede@redhat.com> --- 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 <linux/delay.h> #include <linux/pci.h> #include <linux/vga_switcheroo.h> -#include <acpi/video.h> #include <asm/io.h> /** @@ -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
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 <hdegoede@redhat.com> --- 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 <linux/delay.h> #include <linux/pci.h> #include <linux/vga_switcheroo.h> -#include <acpi/video.h> #include <asm/io.h> /** @@ -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
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 <hdegoede@redhat.com> --- 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 <linux/delay.h> #include <linux/pci.h> #include <linux/vga_switcheroo.h> -#include <acpi/video.h> #include <asm/io.h> /** @@ -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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_id non_acer_quirks[] __initconst = { {} }; -static int __init -video_set_backlight_video_vendor(const struct dmi_system_id *d) -{ - interface->capability &= ~ACER_CAP_BRIGHTNESS; - pr_info("Brightness must be controlled by generic video driver\n"); - return 0; -} - -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = { - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 4750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Extensa 5235", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 5760", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5741", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"), - }, - }, - { - /* - * Note no video_set_backlight_video_vendor, we must use the - * acer interface, as there is no native backlight interface. - */ - .ident = "Acer KAV80", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"), - }, - }, - {} -}; - /* Find which quirks are needed for a particular vendor/ model pair */ static void __init find_quirks(void) { @@ -2477,9 +2414,6 @@ static int __init acer_wmi_init(void) set_quirks(); - if (dmi_check_system(video_vendor_dmi_table)) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) interface->capability &= ~ACER_CAP_BRIGHTNESS; -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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_id non_acer_quirks[] __initconst = { {} }; -static int __init -video_set_backlight_video_vendor(const struct dmi_system_id *d) -{ - interface->capability &= ~ACER_CAP_BRIGHTNESS; - pr_info("Brightness must be controlled by generic video driver\n"); - return 0; -} - -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = { - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 4750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Extensa 5235", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 5760", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5741", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"), - }, - }, - { - /* - * Note no video_set_backlight_video_vendor, we must use the - * acer interface, as there is no native backlight interface. - */ - .ident = "Acer KAV80", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"), - }, - }, - {} -}; - /* Find which quirks are needed for a particular vendor/ model pair */ static void __init find_quirks(void) { @@ -2477,9 +2414,6 @@ static int __init acer_wmi_init(void) set_quirks(); - if (dmi_check_system(video_vendor_dmi_table)) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) interface->capability &= ~ACER_CAP_BRIGHTNESS; -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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_id non_acer_quirks[] __initconst = { {} }; -static int __init -video_set_backlight_video_vendor(const struct dmi_system_id *d) -{ - interface->capability &= ~ACER_CAP_BRIGHTNESS; - pr_info("Brightness must be controlled by generic video driver\n"); - return 0; -} - -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = { - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 4750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Extensa 5235", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 5760", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5741", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"), - }, - }, - { - /* - * Note no video_set_backlight_video_vendor, we must use the - * acer interface, as there is no native backlight interface. - */ - .ident = "Acer KAV80", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"), - }, - }, - {} -}; - /* Find which quirks are needed for a particular vendor/ model pair */ static void __init find_quirks(void) { @@ -2477,9 +2414,6 @@ static int __init acer_wmi_init(void) set_quirks(); - if (dmi_check_system(video_vendor_dmi_table)) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) interface->capability &= ~ACER_CAP_BRIGHTNESS; -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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_id non_acer_quirks[] __initconst = { {} }; -static int __init -video_set_backlight_video_vendor(const struct dmi_system_id *d) -{ - interface->capability &= ~ACER_CAP_BRIGHTNESS; - pr_info("Brightness must be controlled by generic video driver\n"); - return 0; -} - -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = { - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 4750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Extensa 5235", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 5760", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5741", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"), - }, - }, - { - /* - * Note no video_set_backlight_video_vendor, we must use the - * acer interface, as there is no native backlight interface. - */ - .ident = "Acer KAV80", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"), - }, - }, - {} -}; - /* Find which quirks are needed for a particular vendor/ model pair */ static void __init find_quirks(void) { @@ -2477,9 +2414,6 @@ static int __init acer_wmi_init(void) set_quirks(); - if (dmi_check_system(video_vendor_dmi_table)) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) interface->capability &= ~ACER_CAP_BRIGHTNESS; -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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_id non_acer_quirks[] __initconst = { {} }; -static int __init -video_set_backlight_video_vendor(const struct dmi_system_id *d) -{ - interface->capability &= ~ACER_CAP_BRIGHTNESS; - pr_info("Brightness must be controlled by generic video driver\n"); - return 0; -} - -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = { - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 4750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Extensa 5235", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer TravelMate 5760", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5750", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"), - }, - }, - { - .callback = video_set_backlight_video_vendor, - .ident = "Acer Aspire 5741", - .matches = { - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"), - }, - }, - { - /* - * Note no video_set_backlight_video_vendor, we must use the - * acer interface, as there is no native backlight interface. - */ - .ident = "Acer KAV80", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "Acer"), - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"), - }, - }, - {} -}; - /* Find which quirks are needed for a particular vendor/ model pair */ static void __init find_quirks(void) { @@ -2477,9 +2414,6 @@ static int __init acer_wmi_init(void) set_quirks(); - if (dmi_check_system(video_vendor_dmi_table)) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) interface->capability &= ~ACER_CAP_BRIGHTNESS; -- 2.37.2
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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/platform/x86/asus-wmi.h index b302415bf1d9..30770e411301 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_power; bool wmi_backlight_native; bool wmi_backlight_set_devstate; bool wmi_force_als_set; diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index ce86d84ee796..32d9f0ba6be3 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -96,11 +96,6 @@ static struct quirk_entry quirk_asus_et2012_type3 = { .store_backlight_power = true, }; -static struct quirk_entry quirk_asus_x101ch = { - /* We need this when ACPI function doesn't do this well */ - .wmi_backlight_power = true, -}; - static struct quirk_entry *quirks; static void et2012_quirks(void) @@ -151,25 +146,7 @@ static const struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_unknown, }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. X101CH", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"), - }, - .driver_data = &quirk_asus_x101ch, - }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. 1015CX", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"), - }, - .driver_data = &quirk_asus_x101ch, - }, - {}, + {} }; static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code, -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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/platform/x86/asus-wmi.h index b302415bf1d9..30770e411301 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_power; bool wmi_backlight_native; bool wmi_backlight_set_devstate; bool wmi_force_als_set; diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index ce86d84ee796..32d9f0ba6be3 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -96,11 +96,6 @@ static struct quirk_entry quirk_asus_et2012_type3 = { .store_backlight_power = true, }; -static struct quirk_entry quirk_asus_x101ch = { - /* We need this when ACPI function doesn't do this well */ - .wmi_backlight_power = true, -}; - static struct quirk_entry *quirks; static void et2012_quirks(void) @@ -151,25 +146,7 @@ static const struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_unknown, }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. X101CH", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"), - }, - .driver_data = &quirk_asus_x101ch, - }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. 1015CX", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"), - }, - .driver_data = &quirk_asus_x101ch, - }, - {}, + {} }; static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code, -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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/platform/x86/asus-wmi.h index b302415bf1d9..30770e411301 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_power; bool wmi_backlight_native; bool wmi_backlight_set_devstate; bool wmi_force_als_set; diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index ce86d84ee796..32d9f0ba6be3 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -96,11 +96,6 @@ static struct quirk_entry quirk_asus_et2012_type3 = { .store_backlight_power = true, }; -static struct quirk_entry quirk_asus_x101ch = { - /* We need this when ACPI function doesn't do this well */ - .wmi_backlight_power = true, -}; - static struct quirk_entry *quirks; static void et2012_quirks(void) @@ -151,25 +146,7 @@ static const struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_unknown, }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. X101CH", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"), - }, - .driver_data = &quirk_asus_x101ch, - }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. 1015CX", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"), - }, - .driver_data = &quirk_asus_x101ch, - }, - {}, + {} }; static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code, -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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/platform/x86/asus-wmi.h index b302415bf1d9..30770e411301 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_power; bool wmi_backlight_native; bool wmi_backlight_set_devstate; bool wmi_force_als_set; diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index ce86d84ee796..32d9f0ba6be3 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -96,11 +96,6 @@ static struct quirk_entry quirk_asus_et2012_type3 = { .store_backlight_power = true, }; -static struct quirk_entry quirk_asus_x101ch = { - /* We need this when ACPI function doesn't do this well */ - .wmi_backlight_power = true, -}; - static struct quirk_entry *quirks; static void et2012_quirks(void) @@ -151,25 +146,7 @@ static const struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_unknown, }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. X101CH", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"), - }, - .driver_data = &quirk_asus_x101ch, - }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. 1015CX", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"), - }, - .driver_data = &quirk_asus_x101ch, - }, - {}, + {} }; static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code, -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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/platform/x86/asus-wmi.h index b302415bf1d9..30770e411301 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_power; bool wmi_backlight_native; bool wmi_backlight_set_devstate; bool wmi_force_als_set; diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index ce86d84ee796..32d9f0ba6be3 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -96,11 +96,6 @@ static struct quirk_entry quirk_asus_et2012_type3 = { .store_backlight_power = true, }; -static struct quirk_entry quirk_asus_x101ch = { - /* We need this when ACPI function doesn't do this well */ - .wmi_backlight_power = true, -}; - static struct quirk_entry *quirks; static void et2012_quirks(void) @@ -151,25 +146,7 @@ static const struct dmi_system_id asus_quirks[] = { }, .driver_data = &quirk_asus_unknown, }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. X101CH", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"), - }, - .driver_data = &quirk_asus_x101ch, - }, - { - .callback = dmi_matched, - .ident = "ASUSTeK Computer INC. 1015CX", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"), - }, - .driver_data = &quirk_asus_x101ch, - }, - {}, + {} }; static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code, -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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 = &quirk_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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 = &quirk_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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 = &quirk_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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 = &quirk_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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 = &quirk_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 = &quirk_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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N150P"), - DMI_MATCH(DMI_BOARD_NAME, "N150P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "X360", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "X360"), - DMI_MATCH(DMI_BOARD_NAME, "X360"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "N250P", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N250P"), - DMI_MATCH(DMI_BOARD_NAME, "N250P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, { .callback = samsung_dmi_matched, .ident = "730U3E/740U3E", @@ -1654,15 +1574,8 @@ static int __init samsung_init(void) samsung->handle_backlight = true; samsung->quirks = quirks; -#ifdef CONFIG_ACPI - if (samsung->quirks->broken_acpi_video) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (samsung->quirks->use_native_backlight) - acpi_video_set_dmi_backlight_type(acpi_backlight_native); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) samsung->handle_backlight = false; -#endif ret = samsung_platform_init(samsung); if (ret) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N150P"), - DMI_MATCH(DMI_BOARD_NAME, "N150P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "X360", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "X360"), - DMI_MATCH(DMI_BOARD_NAME, "X360"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "N250P", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N250P"), - DMI_MATCH(DMI_BOARD_NAME, "N250P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, { .callback = samsung_dmi_matched, .ident = "730U3E/740U3E", @@ -1654,15 +1574,8 @@ static int __init samsung_init(void) samsung->handle_backlight = true; samsung->quirks = quirks; -#ifdef CONFIG_ACPI - if (samsung->quirks->broken_acpi_video) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (samsung->quirks->use_native_backlight) - acpi_video_set_dmi_backlight_type(acpi_backlight_native); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) samsung->handle_backlight = false; -#endif ret = samsung_platform_init(samsung); if (ret) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N150P"), - DMI_MATCH(DMI_BOARD_NAME, "N150P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "X360", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "X360"), - DMI_MATCH(DMI_BOARD_NAME, "X360"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "N250P", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N250P"), - DMI_MATCH(DMI_BOARD_NAME, "N250P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, { .callback = samsung_dmi_matched, .ident = "730U3E/740U3E", @@ -1654,15 +1574,8 @@ static int __init samsung_init(void) samsung->handle_backlight = true; samsung->quirks = quirks; -#ifdef CONFIG_ACPI - if (samsung->quirks->broken_acpi_video) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (samsung->quirks->use_native_backlight) - acpi_video_set_dmi_backlight_type(acpi_backlight_native); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) samsung->handle_backlight = false; -#endif ret = samsung_platform_init(samsung); if (ret) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N150P"), - DMI_MATCH(DMI_BOARD_NAME, "N150P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "X360", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "X360"), - DMI_MATCH(DMI_BOARD_NAME, "X360"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "N250P", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N250P"), - DMI_MATCH(DMI_BOARD_NAME, "N250P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, { .callback = samsung_dmi_matched, .ident = "730U3E/740U3E", @@ -1654,15 +1574,8 @@ static int __init samsung_init(void) samsung->handle_backlight = true; samsung->quirks = quirks; -#ifdef CONFIG_ACPI - if (samsung->quirks->broken_acpi_video) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (samsung->quirks->use_native_backlight) - acpi_video_set_dmi_backlight_type(acpi_backlight_native); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) samsung->handle_backlight = false; -#endif ret = samsung_platform_init(samsung); if (ret) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N150P"), - DMI_MATCH(DMI_BOARD_NAME, "N150P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "X360", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "X360"), - DMI_MATCH(DMI_BOARD_NAME, "X360"), - }, - .driver_data = &samsung_broken_acpi_video, - }, - { - .callback = samsung_dmi_matched, - .ident = "N250P", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), - DMI_MATCH(DMI_PRODUCT_NAME, "N250P"), - DMI_MATCH(DMI_BOARD_NAME, "N250P"), - }, - .driver_data = &samsung_use_native_backlight, - }, - { - .callback = samsung_dmi_matched, - .ident = "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"), - }, - .driver_data = &samsung_broken_acpi_video, - }, { .callback = samsung_dmi_matched, .ident = "730U3E/740U3E", @@ -1654,15 +1574,8 @@ static int __init samsung_init(void) samsung->handle_backlight = true; samsung->quirks = quirks; -#ifdef CONFIG_ACPI - if (samsung->quirks->broken_acpi_video) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (samsung->quirks->use_native_backlight) - acpi_video_set_dmi_backlight_type(acpi_backlight_native); - if (acpi_video_get_backlight_type() != acpi_backlight_vendor) samsung->handle_backlight = false; -#endif ret = samsung_platform_init(samsung); if (ret) -- 2.37.2
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_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 <linux/workqueue.h> #include <acpi/video.h> -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_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 <linux/workqueue.h> #include <acpi/video.h> -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_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 <linux/workqueue.h> #include <acpi/video.h> -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_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 <linux/workqueue.h> #include <acpi/video.h> -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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(&video_list_lock); - list_for_each_entry(video, &video_bus_head, entry) - acpi_video_bus_unregister_backlight(video); - mutex_unlock(&video_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 <linux/workqueue.h> #include <acpi/video.h> -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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <wse@tuxedocomputers.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <wse@tuxedocomputers.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <wse@tuxedocomputers.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <wse@tuxedocomputers.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <wse@tuxedocomputers.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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 <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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-hdegoede@redhat.com/ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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-hdegoede@redhat.com/ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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-hdegoede@redhat.com/ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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-hdegoede@redhat.com/ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
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-hdegoede@redhat.com/ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- 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
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/107755/ State : warning == Summary == Error: dim checkpatch failed 9770bde2adbd ACPI: video: Add acpi_video_backlight_use_native() helper -:112: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #112: FILE: include/acpi/video.h:59: +extern bool acpi_video_backlight_use_native(void); -:120: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #120: FILE: include/acpi/video.h:81: } +static inline bool acpi_video_backlight_use_native(void) total: 0 errors, 0 warnings, 2 checks, 73 lines checked 7bbb7b4364f8 drm/i915: Don't register backlight when another backlight should be used (v2) 21ff8de3d743 drm/amdgpu: Don't register backlight when another backlight should be used (v3) 4660f062ab74 drm/radeon: Don't register backlight when another backlight should be used (v3) 8f0a985ccd2d drm/nouveau: Don't register backlight when another backlight should be used (v2) a9d8a2239032 ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() 827cedc90abe ACPI: video: Remove acpi_video_bus from list before tearing it down c46374a7c084 ACPI: video: Simplify acpi_video_unregister_backlight() 2c0dca45608a ACPI: video: Make backlight class device registration a separate step (v2) -:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #52: FILE: drivers/acpi/acpi_video.c:83: +MODULE_PARM_DESC(register_backlight_delay, + "Delay in seconds before doing fallback (non GPU driver triggered) " -:155: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #155: FILE: include/acpi/video.h:56: +extern void acpi_video_register_backlight(void); total: 0 errors, 0 warnings, 2 checks, 112 lines checked ba74631acf23 ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers 0442c6a6fbfa drm/i915: Call acpi_video_register_backlight() (v3) 89fc23bf53df drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2) 2098c614c444 drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration 012baaa975af drm/radeon: Register ACPI video backlight when skipping radeon backlight registration 9a316e427d90 platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2) Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in <module> from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:119: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #119: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 166 lines checked db397e31e959 ACPI: video: Refactor acpi_video_get_backlight_type() a bit 0746f167fbf6 ACPI: video: Add Nvidia WMI EC brightness control detection (v3) 8ded49115792 ACPI: video: Add Apple GMUX brightness control detection e7b522538f54 platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type() da5dc93cfd1d platform/x86: apple-gmux: Stop calling acpi/video.h functions 359a75cc8d2f platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() ab7d1912a362 platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c 99c3efe84b91 platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling f95c29c199a2 platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c 5acb614534dc platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c 17d1c19d714c platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c 7803178f9be6 ACPI: video: Remove acpi_video_set_dmi_backlight_type() debf21872658 ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk db35244fef1b ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks 1ab23762426c ACPI: video: Fix indentation of video_detect_dmi_table[] entries 3d4776063cd8 drm/todo: Add entry about dealing with brightness control on devices with > 1 panel -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdegoede@redhat.com/ total: 0 errors, 1 warnings, 0 checks, 74 lines checked
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/107755/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:223:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:225:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:318:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB" +drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:318:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB" +drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:318:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB" +drivers/gpu/drm/radeon/atombios_encoders.c:1078:52: expected unsigned short [addressable] [assigned] [usertype] usInitInfo +drivers/gpu/drm/radeon/atombios_encoders.c:1078:52: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:1078:52: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:1084:62: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:1084:62: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:1084:62: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:1086:62: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:1086:62: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:1086:62: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:1088:62: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:1088:62: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:1088:62: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:1135:52: warning: too many warnings +drivers/gpu/drm/radeon/atombios_encoders.c:388:27: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:388:27: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:388:27: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:444:38: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:444:38: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:444:38: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:517:59: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:517:59: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:517:59: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:527:50: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:527:50: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:527:50: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:533:50: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:533:50: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:533:50: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:603:46: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:603:46: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:603:46: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:628:46: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:628:46: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:628:46: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:876:46: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:876:46: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:876:46: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:913:46: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:913:46: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:913:46: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/radeon/atombios_encoders.c:936:46: expected unsigned short [addressable] [assigned] [usertype] usPixelClock +drivers/gpu/drm/radeon/atombios_encoders.c:936:46: got restricted __le16 [usertype] +drivers/gpu/drm/radeon/atombios_encoders.c:936:46: warning: incorrect type in assignment (different base types) +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:104:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:106:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:110:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:111:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:120:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:127:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:152:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:154:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:155:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:156:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:158:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:27:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:29:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:32:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:36:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:38:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:41:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:54:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:56:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:59:15: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:72:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:74:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:75:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:76:9: warning: unreplaced symbol 'old' +
[-- Attachment #1: Type: text/plain, Size: 8540 bytes --] == Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/107755/ State : success == Summary == CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107755v1 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/index.html Participating hosts (38 -> 35) ------------------------------ Missing (3): bat-dg2-8 bat-rpls-2 fi-hsw-4770 Known issues ------------ Here are the changes found in Patchwork_107755v1 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@i915_pm_backlight@basic-brightness: - fi-bsw-kefka: [PASS][1] -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-kefka/igt@i915_pm_backlight@basic-brightness.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-bsw-kefka/igt@i915_pm_backlight@basic-brightness.html * igt@i915_selftest@live@gt_engines: - bat-dg1-6: [PASS][3] -> [INCOMPLETE][4] ([i915#4418]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-dg1-6/igt@i915_selftest@live@gt_engines.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html * igt@i915_selftest@live@hangcheck: - fi-hsw-g3258: [PASS][5] -> [INCOMPLETE][6] ([i915#3303] / [i915#4785]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-hsw-g3258/igt@i915_selftest@live@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-hsw-g3258/igt@i915_selftest@live@hangcheck.html * igt@runner@aborted: - fi-hsw-g3258: NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#4312] / [i915#6246]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-hsw-g3258/igt@runner@aborted.html #### Possible fixes #### * igt@core_hotunplug@unbind-rebind: - fi-ivb-3770: [FAIL][8] -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-ivb-3770/igt@core_hotunplug@unbind-rebind.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-ivb-3770/igt@core_hotunplug@unbind-rebind.html * igt@gem_exec_suspend@basic-s0@smem: - {bat-rplp-1}: [DMESG-WARN][10] ([i915#2867]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-rplp-1/igt@gem_exec_suspend@basic-s0@smem.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/bat-rplp-1/igt@gem_exec_suspend@basic-s0@smem.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions: - fi-bsw-kefka: [FAIL][12] ([i915#6298]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html #### Warnings #### * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: [FAIL][14] ([fdo#103375]) -> [INCOMPLETE][15] ([i915#5982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html - fi-elk-e7500: [INCOMPLETE][16] ([i915#6598] / [i915#6601] / [i915#6648]) -> [INCOMPLETE][17] ([i915#6598] / [i915#6648]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-elk-e7500/igt@i915_suspend@basic-s3-without-i915.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-elk-e7500/igt@i915_suspend@basic-s3-without-i915.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867 [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418 [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982 [i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246 [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257 [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298 [i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380 [i915#6530]: https://gitlab.freedesktop.org/drm/intel/issues/6530 [i915#6579]: https://gitlab.freedesktop.org/drm/intel/issues/6579 [i915#6598]: https://gitlab.freedesktop.org/drm/intel/issues/6598 [i915#6601]: https://gitlab.freedesktop.org/drm/intel/issues/6601 [i915#6648]: https://gitlab.freedesktop.org/drm/intel/issues/6648 Build changes ------------- * Linux: CI_DRM_12025 -> Patchwork_107755v1 CI-20190529: 20190529 CI_DRM_12025: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_107755v1: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits dcb253de416d drm/todo: Add entry about dealing with brightness control on devices with > 1 panel 0693d1e4160d ACPI: video: Fix indentation of video_detect_dmi_table[] entries 3dc1ab4f6532 ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks baf8ec8c4e08 ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk 22e02f0682d8 ACPI: video: Remove acpi_video_set_dmi_backlight_type() a065026855a3 platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c 1e0d0ee9fa5d platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c a5637f478514 platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c 85e765a53f78 platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling 18254a3375e8 platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c a70d889be4d2 platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() 4bd5de41b8de platform/x86: apple-gmux: Stop calling acpi/video.h functions 504ca6c6f603 platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type() 2dd8881f0aa2 ACPI: video: Add Apple GMUX brightness control detection e094a651d72d ACPI: video: Add Nvidia WMI EC brightness control detection (v3) c053f9f49ba6 ACPI: video: Refactor acpi_video_get_backlight_type() a bit bf6434bd7c43 platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2) 4b0784addd38 drm/radeon: Register ACPI video backlight when skipping radeon backlight registration d75ddf0d7e6f drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration 945afbc25747 drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2) 36d81d3183f9 drm/i915: Call acpi_video_register_backlight() (v3) 3dc3f76a30aa ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers 04128a8901c9 ACPI: video: Make backlight class device registration a separate step (v2) 5f285d37ec6a ACPI: video: Simplify acpi_video_unregister_backlight() 189b7f335ac9 ACPI: video: Remove acpi_video_bus from list before tearing it down db2bba94dcd0 ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() 6f5e65f7d87a drm/nouveau: Don't register backlight when another backlight should be used (v2) b8bf18759df0 drm/radeon: Don't register backlight when another backlight should be used (v3) bfa741acc99e drm/amdgpu: Don't register backlight when another backlight should be used (v3) 426f8a2ce3d3 drm/i915: Don't register backlight when another backlight should be used (v2) 152630e9e122 ACPI: video: Add acpi_video_backlight_use_native() helper == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/index.html [-- Attachment #2: Type: text/html, Size: 9398 bytes --]
Thanks, Hans.
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
On 8/25/22 9:37 AM, 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 .
>
> Changes in v2:
> - Add missing Nvidia copyright header
> - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
>
> Suggested-by: Daniel Dadap <ddadap@nvidia.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <ddadap@nvidia.com>
> L: platform-driver-x86@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 <kbusch@kernel.org>
> 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 <linux/backlight.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h>
> #include <linux/types.h>
> #include <linux/wmi.h>
>
> -/**
> - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved.
> + */
> +
> +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +
> +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
> +
> +/**
> + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
> + */
> +struct wmi_brightness_args {
> + u32 mode;
> + u32 val;
> + u32 ret;
> + u32 ignored[3];
> +};
> +
> +#endif
Thanks, Hans.
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
On 8/25/22 9:37 AM, 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 .
>
> Changes in v2:
> - Add missing Nvidia copyright header
> - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
>
> Suggested-by: Daniel Dadap <ddadap@nvidia.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <ddadap@nvidia.com>
> L: platform-driver-x86@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 <kbusch@kernel.org>
> 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 <linux/backlight.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h>
> #include <linux/types.h>
> #include <linux/wmi.h>
>
> -/**
> - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved.
> + */
> +
> +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +
> +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
> +
> +/**
> + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
> + */
> +struct wmi_brightness_args {
> + u32 mode;
> + u32 val;
> + u32 ret;
> + u32 ignored[3];
> +};
> +
> +#endif
Thanks, Hans.
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
On 8/25/22 9:37 AM, 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 .
>
> Changes in v2:
> - Add missing Nvidia copyright header
> - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
>
> Suggested-by: Daniel Dadap <ddadap@nvidia.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <ddadap@nvidia.com>
> L: platform-driver-x86@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 <kbusch@kernel.org>
> 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 <linux/backlight.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h>
> #include <linux/types.h>
> #include <linux/wmi.h>
>
> -/**
> - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved.
> + */
> +
> +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +
> +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
> +
> +/**
> + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
> + */
> +struct wmi_brightness_args {
> + u32 mode;
> + u32 val;
> + u32 ret;
> + u32 ignored[3];
> +};
> +
> +#endif
Thanks, Hans.
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
On 8/25/22 9:37 AM, 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 .
>
> Changes in v2:
> - Add missing Nvidia copyright header
> - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
>
> Suggested-by: Daniel Dadap <ddadap@nvidia.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <ddadap@nvidia.com>
> L: platform-driver-x86@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 <kbusch@kernel.org>
> 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 <linux/backlight.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h>
> #include <linux/types.h>
> #include <linux/wmi.h>
>
> -/**
> - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved.
> + */
> +
> +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +
> +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
> +
> +/**
> + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
> + */
> +struct wmi_brightness_args {
> + u32 mode;
> + u32 val;
> + u32 ret;
> + u32 ignored[3];
> +};
> +
> +#endif
Thanks, Hans.
Reviewed-by: Daniel Dadap <ddadap@nvidia.com>
On 8/25/22 9:37 AM, 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 .
>
> Changes in v2:
> - Add missing Nvidia copyright header
> - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
>
> Suggested-by: Daniel Dadap <ddadap@nvidia.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <ddadap@nvidia.com>
> L: platform-driver-x86@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 <kbusch@kernel.org>
> 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 <linux/backlight.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h>
> #include <linux/types.h>
> #include <linux/wmi.h>
>
> -/**
> - * 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 &enum 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 &enum 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 000000000000..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 CORPORATION. All rights reserved.
> + */
> +
> +#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
> +
> +#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
> +
> +/**
> + * 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 &enum 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 &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
> + */
> +struct wmi_brightness_args {
> + u32 mode;
> + u32 val;
> + u32 ret;
> + u32 ignored[3];
> +};
> +
> +#endif
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 <rafael.j.wysocki@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > 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 <linux/dmi.h> > #include <linux/module.h> > #include <linux/pci.h> > +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> > #include <linux/types.h> > #include <linux/workqueue.h> > #include <acpi/video.h> > @@ -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. > +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), &args }; > + acpi_status status; > + > + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, > + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); > + 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, > &video_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 > select INPUT if ACPI > + select X86_PLATFORM_DEVICES if ACPI > + select ACPI_WMI if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI > select SYNC_FILE > diff --git a/include/acpi/video.h b/include/acpi/video.h > index 0625806d3bbd..91578e77ac4e 100644 > --- a/include/acpi/video.h > +++ b/include/acpi/video.h > @@ -48,6 +48,7 @@ enum acpi_backlight_type { > acpi_backlight_video, > acpi_backlight_vendor, > acpi_backlight_native, > + acpi_backlight_nvidia_wmi_ec, > }; > > #if IS_ENABLED(CONFIG_ACPI_VIDEO)
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 <rafael.j.wysocki@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > 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 <linux/dmi.h> > #include <linux/module.h> > #include <linux/pci.h> > +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> > #include <linux/types.h> > #include <linux/workqueue.h> > #include <acpi/video.h> > @@ -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. > +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), &args }; > + acpi_status status; > + > + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, > + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); > + 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, > &video_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 > select INPUT if ACPI > + select X86_PLATFORM_DEVICES if ACPI > + select ACPI_WMI if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI > select SYNC_FILE > diff --git a/include/acpi/video.h b/include/acpi/video.h > index 0625806d3bbd..91578e77ac4e 100644 > --- a/include/acpi/video.h > +++ b/include/acpi/video.h > @@ -48,6 +48,7 @@ enum acpi_backlight_type { > acpi_backlight_video, > acpi_backlight_vendor, > acpi_backlight_native, > + acpi_backlight_nvidia_wmi_ec, > }; > > #if IS_ENABLED(CONFIG_ACPI_VIDEO)
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 <rafael.j.wysocki@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > 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 <linux/dmi.h> > #include <linux/module.h> > #include <linux/pci.h> > +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> > #include <linux/types.h> > #include <linux/workqueue.h> > #include <acpi/video.h> > @@ -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. > +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), &args }; > + acpi_status status; > + > + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, > + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); > + 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, > &video_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 > select INPUT if ACPI > + select X86_PLATFORM_DEVICES if ACPI > + select ACPI_WMI if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI > select SYNC_FILE > diff --git a/include/acpi/video.h b/include/acpi/video.h > index 0625806d3bbd..91578e77ac4e 100644 > --- a/include/acpi/video.h > +++ b/include/acpi/video.h > @@ -48,6 +48,7 @@ enum acpi_backlight_type { > acpi_backlight_video, > acpi_backlight_vendor, > acpi_backlight_native, > + acpi_backlight_nvidia_wmi_ec, > }; > > #if IS_ENABLED(CONFIG_ACPI_VIDEO)
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 <rafael.j.wysocki@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > 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 <linux/dmi.h> > #include <linux/module.h> > #include <linux/pci.h> > +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> > #include <linux/types.h> > #include <linux/workqueue.h> > #include <acpi/video.h> > @@ -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. > +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), &args }; > + acpi_status status; > + > + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, > + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); > + 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, > &video_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 > select INPUT if ACPI > + select X86_PLATFORM_DEVICES if ACPI > + select ACPI_WMI if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI > select SYNC_FILE > diff --git a/include/acpi/video.h b/include/acpi/video.h > index 0625806d3bbd..91578e77ac4e 100644 > --- a/include/acpi/video.h > +++ b/include/acpi/video.h > @@ -48,6 +48,7 @@ enum acpi_backlight_type { > acpi_backlight_video, > acpi_backlight_vendor, > acpi_backlight_native, > + acpi_backlight_nvidia_wmi_ec, > }; > > #if IS_ENABLED(CONFIG_ACPI_VIDEO)
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 <rafael.j.wysocki@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > 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 <linux/dmi.h> > #include <linux/module.h> > #include <linux/pci.h> > +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> > #include <linux/types.h> > #include <linux/workqueue.h> > #include <acpi/video.h> > @@ -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. > +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), &args }; > + acpi_status status; > + > + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, > + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); > + 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, > &video_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 > select INPUT if ACPI > + select X86_PLATFORM_DEVICES if ACPI > + select ACPI_WMI if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI > select SYNC_FILE > diff --git a/include/acpi/video.h b/include/acpi/video.h > index 0625806d3bbd..91578e77ac4e 100644 > --- a/include/acpi/video.h > +++ b/include/acpi/video.h > @@ -48,6 +48,7 @@ enum acpi_backlight_type { > acpi_backlight_video, > acpi_backlight_vendor, > acpi_backlight_native, > + acpi_backlight_nvidia_wmi_ec, > }; > > #if IS_ENABLED(CONFIG_ACPI_VIDEO)
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 <rafael.j.wysocki@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/dmi.h> >> #include <linux/module.h> >> #include <linux/pci.h> >> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >> #include <linux/types.h> >> #include <linux/workqueue.h> >> #include <acpi/video.h> >> @@ -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), &args }; >> + acpi_status status; >> + >> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >> + 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, >> &video_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 >> select INPUT if ACPI >> + select X86_PLATFORM_DEVICES if ACPI >> + select ACPI_WMI if ACPI >> select ACPI_VIDEO if ACPI >> select ACPI_BUTTON if ACPI >> select SYNC_FILE >> diff --git a/include/acpi/video.h b/include/acpi/video.h >> index 0625806d3bbd..91578e77ac4e 100644 >> --- a/include/acpi/video.h >> +++ b/include/acpi/video.h >> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >> acpi_backlight_video, >> acpi_backlight_vendor, >> acpi_backlight_native, >> + acpi_backlight_nvidia_wmi_ec, >> }; >> #if IS_ENABLED(CONFIG_ACPI_VIDEO) >
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 <rafael.j.wysocki@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/dmi.h> >> #include <linux/module.h> >> #include <linux/pci.h> >> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >> #include <linux/types.h> >> #include <linux/workqueue.h> >> #include <acpi/video.h> >> @@ -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), &args }; >> + acpi_status status; >> + >> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >> + 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, >> &video_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 >> select INPUT if ACPI >> + select X86_PLATFORM_DEVICES if ACPI >> + select ACPI_WMI if ACPI >> select ACPI_VIDEO if ACPI >> select ACPI_BUTTON if ACPI >> select SYNC_FILE >> diff --git a/include/acpi/video.h b/include/acpi/video.h >> index 0625806d3bbd..91578e77ac4e 100644 >> --- a/include/acpi/video.h >> +++ b/include/acpi/video.h >> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >> acpi_backlight_video, >> acpi_backlight_vendor, >> acpi_backlight_native, >> + acpi_backlight_nvidia_wmi_ec, >> }; >> #if IS_ENABLED(CONFIG_ACPI_VIDEO) >
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 <rafael.j.wysocki@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/dmi.h> >> #include <linux/module.h> >> #include <linux/pci.h> >> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >> #include <linux/types.h> >> #include <linux/workqueue.h> >> #include <acpi/video.h> >> @@ -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), &args }; >> + acpi_status status; >> + >> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >> + 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, >> &video_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 >> select INPUT if ACPI >> + select X86_PLATFORM_DEVICES if ACPI >> + select ACPI_WMI if ACPI >> select ACPI_VIDEO if ACPI >> select ACPI_BUTTON if ACPI >> select SYNC_FILE >> diff --git a/include/acpi/video.h b/include/acpi/video.h >> index 0625806d3bbd..91578e77ac4e 100644 >> --- a/include/acpi/video.h >> +++ b/include/acpi/video.h >> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >> acpi_backlight_video, >> acpi_backlight_vendor, >> acpi_backlight_native, >> + acpi_backlight_nvidia_wmi_ec, >> }; >> #if IS_ENABLED(CONFIG_ACPI_VIDEO) >
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 <rafael.j.wysocki@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/dmi.h> >> #include <linux/module.h> >> #include <linux/pci.h> >> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >> #include <linux/types.h> >> #include <linux/workqueue.h> >> #include <acpi/video.h> >> @@ -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), &args }; >> + acpi_status status; >> + >> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >> + 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, >> &video_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 >> select INPUT if ACPI >> + select X86_PLATFORM_DEVICES if ACPI >> + select ACPI_WMI if ACPI >> select ACPI_VIDEO if ACPI >> select ACPI_BUTTON if ACPI >> select SYNC_FILE >> diff --git a/include/acpi/video.h b/include/acpi/video.h >> index 0625806d3bbd..91578e77ac4e 100644 >> --- a/include/acpi/video.h >> +++ b/include/acpi/video.h >> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >> acpi_backlight_video, >> acpi_backlight_vendor, >> acpi_backlight_native, >> + acpi_backlight_nvidia_wmi_ec, >> }; >> #if IS_ENABLED(CONFIG_ACPI_VIDEO) >
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 <rafael.j.wysocki@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/dmi.h> >> #include <linux/module.h> >> #include <linux/pci.h> >> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >> #include <linux/types.h> >> #include <linux/workqueue.h> >> #include <acpi/video.h> >> @@ -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), &args }; >> + acpi_status status; >> + >> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >> + 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, >> &video_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 >> select INPUT if ACPI >> + select X86_PLATFORM_DEVICES if ACPI >> + select ACPI_WMI if ACPI >> select ACPI_VIDEO if ACPI >> select ACPI_BUTTON if ACPI >> select SYNC_FILE >> diff --git a/include/acpi/video.h b/include/acpi/video.h >> index 0625806d3bbd..91578e77ac4e 100644 >> --- a/include/acpi/video.h >> +++ b/include/acpi/video.h >> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >> acpi_backlight_video, >> acpi_backlight_vendor, >> acpi_backlight_native, >> + acpi_backlight_nvidia_wmi_ec, >> }; >> #if IS_ENABLED(CONFIG_ACPI_VIDEO) >
On 8/29/22 06:41, Hans de Goede wrote: > 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 <rafael.j.wysocki@intel.com> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> --- >>> 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 <linux/dmi.h> >>> #include <linux/module.h> >>> #include <linux/pci.h> >>> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >>> #include <linux/types.h> >>> #include <linux/workqueue.h> >>> #include <acpi/video.h> >>> @@ -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 :) That is fair. Reviewed-by: Daniel Dadap <ddadap@nvidia.com> > 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), &args }; >>> + acpi_status status; >>> + >>> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >>> + 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, >>> &video_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 >>> select INPUT if ACPI >>> + select X86_PLATFORM_DEVICES if ACPI >>> + select ACPI_WMI if ACPI >>> select ACPI_VIDEO if ACPI >>> select ACPI_BUTTON if ACPI >>> select SYNC_FILE >>> diff --git a/include/acpi/video.h b/include/acpi/video.h >>> index 0625806d3bbd..91578e77ac4e 100644 >>> --- a/include/acpi/video.h >>> +++ b/include/acpi/video.h >>> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >>> acpi_backlight_video, >>> acpi_backlight_vendor, >>> acpi_backlight_native, >>> + acpi_backlight_nvidia_wmi_ec, >>> }; >>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
On 8/29/22 06:41, Hans de Goede wrote: > 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 <rafael.j.wysocki@intel.com> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> --- >>> 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 <linux/dmi.h> >>> #include <linux/module.h> >>> #include <linux/pci.h> >>> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >>> #include <linux/types.h> >>> #include <linux/workqueue.h> >>> #include <acpi/video.h> >>> @@ -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 :) That is fair. Reviewed-by: Daniel Dadap <ddadap@nvidia.com> > 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), &args }; >>> + acpi_status status; >>> + >>> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >>> + 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, >>> &video_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 >>> select INPUT if ACPI >>> + select X86_PLATFORM_DEVICES if ACPI >>> + select ACPI_WMI if ACPI >>> select ACPI_VIDEO if ACPI >>> select ACPI_BUTTON if ACPI >>> select SYNC_FILE >>> diff --git a/include/acpi/video.h b/include/acpi/video.h >>> index 0625806d3bbd..91578e77ac4e 100644 >>> --- a/include/acpi/video.h >>> +++ b/include/acpi/video.h >>> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >>> acpi_backlight_video, >>> acpi_backlight_vendor, >>> acpi_backlight_native, >>> + acpi_backlight_nvidia_wmi_ec, >>> }; >>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
On 8/29/22 06:41, Hans de Goede wrote: > 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 <rafael.j.wysocki@intel.com> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> --- >>> 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 <linux/dmi.h> >>> #include <linux/module.h> >>> #include <linux/pci.h> >>> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >>> #include <linux/types.h> >>> #include <linux/workqueue.h> >>> #include <acpi/video.h> >>> @@ -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 :) That is fair. Reviewed-by: Daniel Dadap <ddadap@nvidia.com> > 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), &args }; >>> + acpi_status status; >>> + >>> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >>> + 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, >>> &video_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 >>> select INPUT if ACPI >>> + select X86_PLATFORM_DEVICES if ACPI >>> + select ACPI_WMI if ACPI >>> select ACPI_VIDEO if ACPI >>> select ACPI_BUTTON if ACPI >>> select SYNC_FILE >>> diff --git a/include/acpi/video.h b/include/acpi/video.h >>> index 0625806d3bbd..91578e77ac4e 100644 >>> --- a/include/acpi/video.h >>> +++ b/include/acpi/video.h >>> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >>> acpi_backlight_video, >>> acpi_backlight_vendor, >>> acpi_backlight_native, >>> + acpi_backlight_nvidia_wmi_ec, >>> }; >>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
On 8/29/22 06:41, Hans de Goede wrote: > 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 <rafael.j.wysocki@intel.com> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> --- >>> 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 <linux/dmi.h> >>> #include <linux/module.h> >>> #include <linux/pci.h> >>> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >>> #include <linux/types.h> >>> #include <linux/workqueue.h> >>> #include <acpi/video.h> >>> @@ -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 :) That is fair. Reviewed-by: Daniel Dadap <ddadap@nvidia.com> > 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), &args }; >>> + acpi_status status; >>> + >>> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >>> + 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, >>> &video_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 >>> select INPUT if ACPI >>> + select X86_PLATFORM_DEVICES if ACPI >>> + select ACPI_WMI if ACPI >>> select ACPI_VIDEO if ACPI >>> select ACPI_BUTTON if ACPI >>> select SYNC_FILE >>> diff --git a/include/acpi/video.h b/include/acpi/video.h >>> index 0625806d3bbd..91578e77ac4e 100644 >>> --- a/include/acpi/video.h >>> +++ b/include/acpi/video.h >>> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >>> acpi_backlight_video, >>> acpi_backlight_vendor, >>> acpi_backlight_native, >>> + acpi_backlight_nvidia_wmi_ec, >>> }; >>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
On 8/29/22 06:41, Hans de Goede wrote: > 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 <rafael.j.wysocki@intel.com> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> --- >>> 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 <linux/dmi.h> >>> #include <linux/module.h> >>> #include <linux/pci.h> >>> +#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h> >>> #include <linux/types.h> >>> #include <linux/workqueue.h> >>> #include <acpi/video.h> >>> @@ -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 :) That is fair. Reviewed-by: Daniel Dadap <ddadap@nvidia.com> > 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), &args }; >>> + acpi_status status; >>> + >>> + status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0, >>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf); >>> + 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, >>> &video_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 >>> select INPUT if ACPI >>> + select X86_PLATFORM_DEVICES if ACPI >>> + select ACPI_WMI if ACPI >>> select ACPI_VIDEO if ACPI >>> select ACPI_BUTTON if ACPI >>> select SYNC_FILE >>> diff --git a/include/acpi/video.h b/include/acpi/video.h >>> index 0625806d3bbd..91578e77ac4e 100644 >>> --- a/include/acpi/video.h >>> +++ b/include/acpi/video.h >>> @@ -48,6 +48,7 @@ enum acpi_backlight_type { >>> acpi_backlight_video, >>> acpi_backlight_vendor, >>> acpi_backlight_native, >>> + acpi_backlight_nvidia_wmi_ec, >>> }; >>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
[-- Attachment #1: Type: text/plain, Size: 31929 bytes --] == Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/107755/ State : success == Summary == CI Bug Log - changes from CI_DRM_12025_full -> Patchwork_107755v1_full ==================================================== Summary ------- **SUCCESS** No regressions found. Participating hosts (10 -> 12) ------------------------------ Additional (2): shard-rkl shard-tglu Known issues ------------ Here are the changes found in Patchwork_107755v1_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb2/igt@gem_exec_balancer@parallel-keep-in-fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb6/igt@gem_exec_balancer@parallel-keep-in-fence.html * igt@gem_exec_balancer@parallel-ordering: - shard-kbl: NOTRUN -> [FAIL][3] ([i915#6117]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl7/igt@gem_exec_balancer@parallel-ordering.html * igt@gem_exec_capture@capture-recoverable: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#6344]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@gem_exec_capture@capture-recoverable.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@gem_exec_fair@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-apl3/igt@gem_exec_fair@basic-none-solo@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-apl8/igt@gem_exec_fair@basic-none-solo@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@gem_exec_fair@basic-none@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@gem_exec_fair@basic-none@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-glk9/igt@gem_exec_fair@basic-pace-share@rcs0.html * igt@gem_exec_params@no-bsd: - shard-tglb: NOTRUN -> [SKIP][12] ([fdo#109283]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@gem_exec_params@no-bsd.html * igt@gem_exec_params@secure-non-root: - shard-tglb: NOTRUN -> [SKIP][13] ([fdo#112283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@gem_exec_params@secure-non-root.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +5 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl7/igt@gem_lmem_swapping@parallel-random-verify.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@gem_pread@exhaustion.html * igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted: - shard-tglb: NOTRUN -> [SKIP][16] ([i915#4270]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted.html * igt@gem_softpin@evict-snoop-interruptible: - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109312]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb7/igt@gem_softpin@evict-snoop-interruptible.html * igt@gem_userptr_blits@vma-merge: - shard-kbl: NOTRUN -> [FAIL][18] ([i915#3318]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@gem_userptr_blits@vma-merge.html * igt@gen7_exec_parse@basic-rejected: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb7/igt@gen7_exec_parse@basic-rejected.html * igt@gen9_exec_parse@allowed-single: - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#5566] / [i915#716]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-glk1/igt@gen9_exec_parse@allowed-single.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-glk8/igt@gen9_exec_parse@allowed-single.html * igt@gen9_exec_parse@basic-rejected-ctx-param: - shard-tglb: NOTRUN -> [SKIP][22] ([i915#2527] / [i915#2856]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@gen9_exec_parse@basic-rejected-ctx-param.html * igt@i915_pm_rpm@modeset-pc8-residency-stress: - shard-tglb: NOTRUN -> [SKIP][23] ([fdo#109506] / [i915#2411]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@i915_pm_rpm@modeset-pc8-residency-stress.html * igt@kms_big_fb@4-tiled-addfb-size-overflow: - shard-tglb: NOTRUN -> [SKIP][24] ([i915#5286]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_big_fb@4-tiled-addfb-size-overflow.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip: - shard-tglb: NOTRUN -> [SKIP][25] ([fdo#111615]) +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html * igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][26] ([fdo#109271] / [i915#3886]) [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-apl2/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs: - shard-kbl: NOTRUN -> [SKIP][27] ([fdo#109271] / [i915#3886]) +14 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl7/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs_cc: - shard-tglb: NOTRUN -> [SKIP][28] ([i915#3689] / [i915#6095]) +2 similar issues [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb7/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs_cc.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-tglb: NOTRUN -> [SKIP][29] ([i915#3689] / [i915#3886]) [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-c-bad-pixel-format-yf_tiled_ccs: - shard-tglb: NOTRUN -> [SKIP][30] ([fdo#111615] / [i915#3689]) +1 similar issue [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb7/igt@kms_ccs@pipe-c-bad-pixel-format-yf_tiled_ccs.html * igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs: - shard-tglb: NOTRUN -> [SKIP][31] ([i915#3689]) [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs.html * igt@kms_ccs@pipe-d-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs_cc: - shard-tglb: NOTRUN -> [SKIP][32] ([i915#6095]) +2 similar issues [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-4_tiled_dg2_rc_ccs_cc.html * igt@kms_chamelium@dp-hpd-fast: - shard-tglb: NOTRUN -> [SKIP][33] ([fdo#109284] / [fdo#111827]) +2 similar issues [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_chamelium@dp-hpd-fast.html * igt@kms_chamelium@hdmi-audio: - shard-kbl: NOTRUN -> [SKIP][34] ([fdo#109271] / [fdo#111827]) +17 similar issues [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@kms_chamelium@hdmi-audio.html * igt@kms_content_protection@dp-mst-lic-type-1: - shard-tglb: NOTRUN -> [SKIP][35] ([i915#3116] / [i915#3299]) [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_content_protection@dp-mst-lic-type-1.html * igt@kms_content_protection@srm: - shard-kbl: NOTRUN -> [TIMEOUT][36] ([i915#1319] / [i915#6637]) +2 similar issues [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl4/igt@kms_content_protection@srm.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-tglb: NOTRUN -> [SKIP][37] ([fdo#109274] / [fdo#111825]) [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions: - shard-glk: [PASS][38] -> [FAIL][39] ([i915#2346]) [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-glk6/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-glk7/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html * igt@kms_flip@2x-plain-flip-ts-check-interruptible: - shard-tglb: NOTRUN -> [SKIP][40] ([fdo#109274] / [fdo#111825] / [i915#3637]) +3 similar issues [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb7/igt@kms_flip@2x-plain-flip-ts-check-interruptible.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling@pipe-a-valid-mode: - shard-tglb: NOTRUN -> [SKIP][41] ([i915#2672]) [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling@pipe-a-valid-mode.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][42] ([i915#2672] / [i915#3555]) +1 similar issue [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-downscaling@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][43] ([i915#3555]) [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-downscaling@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-32bpp-yftile-downscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][44] ([i915#2672]) +4 similar issues [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb7/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-32bpp-yftile-downscaling@pipe-a-valid-mode.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-blt: - shard-tglb: NOTRUN -> [SKIP][45] ([fdo#109280] / [fdo#111825]) +13 similar issues [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen: - shard-apl: NOTRUN -> [SKIP][46] ([fdo#109271]) +13 similar issues [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-apl2/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-tglb: NOTRUN -> [SKIP][47] ([i915#6497]) +4 similar issues [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-tiling-4: - shard-tglb: NOTRUN -> [SKIP][48] ([i915#5439]) [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-tiling-4.html * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-kbl: [PASS][49] -> [FAIL][50] ([i915#1188]) [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-kbl7/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl7/igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1.html * igt@kms_hdr@static-toggle: - shard-tglb: NOTRUN -> [SKIP][51] ([i915#3555]) [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb7/igt@kms_hdr@static-toggle.html * igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1: - shard-iclb: [PASS][52] -> [SKIP][53] ([i915#5235]) +2 similar issues [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb6/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1.html [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5@pipe-c-edp-1.html * igt@kms_psr2_sf@overlay-plane-move-continuous-sf: - shard-tglb: NOTRUN -> [SKIP][54] ([i915#2920]) [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_psr2_sf@overlay-plane-move-continuous-sf.html * igt@kms_psr2_su@page_flip-p010: - shard-kbl: NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#658]) +4 similar issues [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@kms_psr2_su@page_flip-p010.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-tglb: NOTRUN -> [FAIL][56] ([i915#132] / [i915#3467]) [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_writeback@writeback-check-output: - shard-kbl: NOTRUN -> [SKIP][57] ([fdo#109271] / [i915#2437]) [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl7/igt@kms_writeback@writeback-check-output.html * igt@kms_writeback@writeback-fb-id: - shard-apl: NOTRUN -> [SKIP][58] ([fdo#109271] / [i915#2437]) [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-apl2/igt@kms_writeback@writeback-fb-id.html * igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame: - shard-tglb: NOTRUN -> [SKIP][59] ([i915#2530]) [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame.html * igt@perf@polling-parameterized: - shard-tglb: [PASS][60] -> [FAIL][61] ([i915#5639]) [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-tglb7/igt@perf@polling-parameterized.html [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb2/igt@perf@polling-parameterized.html * igt@prime_nv_api@i915_self_import_to_different_fd: - shard-tglb: NOTRUN -> [SKIP][62] ([fdo#109291]) +2 similar issues [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@prime_nv_api@i915_self_import_to_different_fd.html * igt@prime_vgem@basic-userptr: - shard-tglb: NOTRUN -> [SKIP][63] ([fdo#109295] / [i915#3301]) [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@prime_vgem@basic-userptr.html * igt@prime_vgem@coherency-gtt: - shard-tglb: NOTRUN -> [SKIP][64] ([fdo#109295] / [fdo#111656]) [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@prime_vgem@coherency-gtt.html * igt@sysfs_clients@busy: - shard-tglb: NOTRUN -> [SKIP][65] ([i915#2994]) [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb3/igt@sysfs_clients@busy.html * igt@sysfs_clients@fair-7: - shard-kbl: NOTRUN -> [SKIP][66] ([fdo#109271] / [i915#2994]) +3 similar issues [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl7/igt@sysfs_clients@fair-7.html * igt@tools_test@sysfs_l3_parity: - shard-kbl: NOTRUN -> [SKIP][67] ([fdo#109271]) +325 similar issues [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-kbl1/igt@tools_test@sysfs_l3_parity.html #### Possible fixes #### * igt@gem_ctx_persistence@smoketest: - shard-iclb: [FAIL][68] ([i915#5099]) -> [PASS][69] [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb6/igt@gem_ctx_persistence@smoketest.html [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@gem_ctx_persistence@smoketest.html * igt@gem_eio@unwedge-stress: - shard-tglb: [FAIL][70] ([i915#5784]) -> [PASS][71] [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-tglb5/igt@gem_eio@unwedge-stress.html [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb6/igt@gem_eio@unwedge-stress.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [FAIL][72] ([i915#2842]) -> [PASS][73] +1 similar issue [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-tglb5/igt@gem_exec_fair@basic-pace@vcs1.html [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-tglb6/igt@gem_exec_fair@basic-pace@vcs1.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [DMESG-WARN][74] ([i915#5566] / [i915#716]) -> [PASS][75] [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-apl7/igt@gen9_exec_parse@allowed-single.html [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-apl2/igt@gen9_exec_parse@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [FAIL][76] ([i915#454]) -> [PASS][77] [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb3/igt@i915_pm_dc@dc6-psr.html [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb7/igt@i915_pm_dc@dc6-psr.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1: - shard-glk: [FAIL][78] ([i915#79]) -> [PASS][79] [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1.html [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1.html * igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1: - shard-iclb: [SKIP][80] ([i915#5176]) -> [PASS][81] +1 similar issue [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb3/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1.html [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb7/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1.html * igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1: - shard-iclb: [SKIP][82] ([i915#5235]) -> [PASS][83] +2 similar issues [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb2/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1.html [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb5/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5@pipe-b-edp-1.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [SKIP][84] ([fdo#109441]) -> [PASS][85] +1 similar issue [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb3/igt@kms_psr@psr2_cursor_blt.html [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html #### Warnings #### * igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf: - shard-iclb: [SKIP][86] ([i915#658]) -> [SKIP][87] ([i915#2920]) [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb3/igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf.html [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf.html * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb: - shard-iclb: [SKIP][88] ([i915#2920]) -> [SKIP][89] ([i915#658]) [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb.html [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb5/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-big-fb.html * igt@kms_psr2_su@page_flip-p010: - shard-iclb: [SKIP][90] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [FAIL][91] ([i915#5939]) [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-iclb6/igt@kms_psr2_su@page_flip-p010.html [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-iclb2/igt@kms_psr2_su@page_flip-p010.html * igt@runner@aborted: - shard-apl: ([FAIL][92], [FAIL][93]) ([fdo#109271] / [i915#3002] / [i915#4312] / [i915#5257] / [i915#6599]) -> [FAIL][94] ([i915#3002] / [i915#4312] / [i915#5257] / [i915#6599]) [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-apl7/igt@runner@aborted.html [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/shard-apl6/igt@runner@aborted.html [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/shard-apl7/igt@runner@aborted.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274 [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280 [fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283 [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291 [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295 [fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302 [fdo#109303]: https://bugs.freedesktop.org/show_bug.cgi?id=109303 [fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307 [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308 [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309 [fdo#109312]: https://bugs.freedesktop.org/show_bug.cgi?id=109312 [fdo#109313]: https://bugs.freedesktop.org/show_bug.cgi?id=109313 [fdo#109314]: https://bugs.freedesktop.org/show_bug.cgi?id=109314 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506 [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068 [fdo#111314]: https://bugs.freedesktop.org/show_bug.cgi?id=111314 [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614 [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615 [fdo#111644]: https://bugs.freedesktop.org/show_bug.cgi?id=111644 [fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656 [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054 [fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283 [i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155 [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188 [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319 [i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132 [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397 [i915#1769]: https://gitlab.freedesktop.org/drm/intel/issues/1769 [i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839 [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849 [i915#1902]: https://gitlab.freedesktop.org/drm/intel/issues/1902 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346 [i915#2410]: https://gitlab.freedesktop.org/drm/intel/issues/2410 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#2434]: https://gitlab.freedesktop.org/drm/intel/issues/2434 [i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437 [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527 [i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530 [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658 [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672 [i915#2705]: https://gitlab.freedesktop.org/drm/intel/issues/2705 [i915#280]: https://gitlab.freedesktop.org/drm/intel/issues/280 [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842 [i915#2846]: https://gitlab.freedesktop.org/drm/intel/issues/2846 [i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856 [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920 [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994 [i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002 [i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063 [i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116 [i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281 [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282 [i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297 [i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318 [i915#3323]: https://gitlab.freedesktop.org/drm/intel/issues/3323 [i915#3376]: https://gitlab.freedesktop.org/drm/intel/issues/3376 [i915#3467]: https://gitlab.freedesktop.org/drm/intel/issues/3467 [i915#3469]: https://gitlab.freedesktop.org/drm/intel/issues/3469 [i915#3528]: https://gitlab.freedesktop.org/drm/intel/issues/3528 [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558 [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637 [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689 [i915#3742]: https://gitlab.freedesktop.org/drm/intel/issues/3742 [i915#3828]: https://gitlab.freedesktop.org/drm/intel/issues/3828 [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886 [i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989 [i915#404]: https://gitlab.freedesktop.org/drm/intel/issues/404 [i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070 [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#426]: https://gitlab.freedesktop.org/drm/intel/issues/426 [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4369]: https://gitlab.freedesktop.org/drm/intel/issues/4369 [i915#4387]: https://gitlab.freedesktop.org/drm/intel/issues/4387 [i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525 [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4877]: https://gitlab.freedesktop.org/drm/intel/issues/4877 [i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991 [i915#5099]: https://gitlab.freedesktop.org/drm/intel/issues/5099 [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176 [i915#5182]: https://gitlab.freedesktop.org/drm/intel/issues/5182 [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235 [i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257 [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286 [i915#5287]: https://gitlab.freedesktop.org/drm/intel/issues/5287 [i915#5288]: https://gitlab.freedesktop.org/drm/intel/issues/5288 [i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289 [i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439 [i915#5461]: https://gitlab.freedesktop.org/drm/intel/issues/5461 [i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566 [i915#5639]: https://gitlab.freedesktop.org/drm/intel/issues/5639 [i915#5723]: https://gitlab.freedesktop.org/drm/intel/issues/5723 [i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784 [i915#5939]: https://gitlab.freedesktop.org/drm/intel/issues/5939 [i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095 [i915#6117]: https://gitlab.freedesktop.org/drm/intel/issues/6117 [i915#6227]: https://gitlab.freedesktop.org/drm/intel/issues/6227 [i915#6230]: https://gitlab.freedesktop.org/drm/intel/issues/6230 [i915#6245]: https://gitlab.freedesktop.org/drm/intel/issues/6245 [i915#6301]: https://gitlab.freedesktop.org/drm/intel/issues/6301 [i915#6334]: https://gitlab.freedesktop.org/drm/intel/issues/6334 [i915#6335]: https://gitlab.freedesktop.org/drm/intel/issues/6335 [i915#6344]: https://gitlab.freedesktop.org/drm/intel/issues/6344 [i915#6412]: https://gitlab.freedesktop.org/drm/intel/issues/6412 [i915#6433]: https://gitlab.freedesktop.org/drm/intel/issues/6433 [i915#6497]: https://gitlab.freedesktop.org/drm/intel/issues/6497 [i915#6524]: https://gitlab.freedesktop.org/drm/intel/issues/6524 [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658 [i915#6599]: https://gitlab.freedesktop.org/drm/intel/issues/6599 [i915#6637]: https://gitlab.freedesktop.org/drm/intel/issues/6637 [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716 [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79 Build changes ------------- * Linux: CI_DRM_12025 -> Patchwork_107755v1 CI-20190529: 20190529 CI_DRM_12025: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_107755v1: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/index.html [-- Attachment #2: Type: text/html, Size: 33302 bytes --]
On Thu, 25 Aug 2022, Hans de Goede <hdegoede@redhat.com> 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 > > 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 <hdegoede@redhat.com> Apologies for the delay. I truly appreciate the effort you've put into this series, and I'm looking forward to seeing the next steps in drm! Reviewed-by: Jani Nikula <jani.nikula@intel.com> And ack for merging via whichever tree you think best. > --- > 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 <linux/pci.h> > #include <linux/acpi.h> > +#include <acpi/video.h> > > #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(&i915->drm, &conn_iter); > + drm_for_each_connector_iter(connector, &conn_iter) { > + struct intel_panel *panel = &to_intel_connector(connector)->panel; > + > + if (panel->backlight.funcs && !panel->backlight.device) { > + acpi_video_register_backlight(); > + break; > + } > + } > + drm_connector_list_iter_end(&conn_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); -- Jani Nikula, Intel Open Source Graphics Center
On Thu, 25 Aug 2022, Hans de Goede <hdegoede@redhat.com> 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 > > 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 <hdegoede@redhat.com> Apologies for the delay. I truly appreciate the effort you've put into this series, and I'm looking forward to seeing the next steps in drm! Reviewed-by: Jani Nikula <jani.nikula@intel.com> And ack for merging via whichever tree you think best. > --- > 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 <linux/pci.h> > #include <linux/acpi.h> > +#include <acpi/video.h> > > #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(&i915->drm, &conn_iter); > + drm_for_each_connector_iter(connector, &conn_iter) { > + struct intel_panel *panel = &to_intel_connector(connector)->panel; > + > + if (panel->backlight.funcs && !panel->backlight.device) { > + acpi_video_register_backlight(); > + break; > + } > + } > + drm_connector_list_iter_end(&conn_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); -- Jani Nikula, Intel Open Source Graphics Center
On Thu, 25 Aug 2022, Hans de Goede <hdegoede@redhat.com> 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 > > 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 <hdegoede@redhat.com> Apologies for the delay. I truly appreciate the effort you've put into this series, and I'm looking forward to seeing the next steps in drm! Reviewed-by: Jani Nikula <jani.nikula@intel.com> And ack for merging via whichever tree you think best. > --- > 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 <linux/pci.h> > #include <linux/acpi.h> > +#include <acpi/video.h> > > #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(&i915->drm, &conn_iter); > + drm_for_each_connector_iter(connector, &conn_iter) { > + struct intel_panel *panel = &to_intel_connector(connector)->panel; > + > + if (panel->backlight.funcs && !panel->backlight.device) { > + acpi_video_register_backlight(); > + break; > + } > + } > + drm_connector_list_iter_end(&conn_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); -- Jani Nikula, Intel Open Source Graphics Center
On Thu, 25 Aug 2022, Hans de Goede <hdegoede@redhat.com> 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 > > 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 <hdegoede@redhat.com> Apologies for the delay. I truly appreciate the effort you've put into this series, and I'm looking forward to seeing the next steps in drm! Reviewed-by: Jani Nikula <jani.nikula@intel.com> And ack for merging via whichever tree you think best. > --- > 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 <linux/pci.h> > #include <linux/acpi.h> > +#include <acpi/video.h> > > #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(&i915->drm, &conn_iter); > + drm_for_each_connector_iter(connector, &conn_iter) { > + struct intel_panel *panel = &to_intel_connector(connector)->panel; > + > + if (panel->backlight.funcs && !panel->backlight.device) { > + acpi_video_register_backlight(); > + break; > + } > + } > + drm_connector_list_iter_end(&conn_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); -- Jani Nikula, Intel Open Source Graphics Center
On Thu, 25 Aug 2022, Hans de Goede <hdegoede@redhat.com> 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 > > 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 <hdegoede@redhat.com> Apologies for the delay. I truly appreciate the effort you've put into this series, and I'm looking forward to seeing the next steps in drm! Reviewed-by: Jani Nikula <jani.nikula@intel.com> And ack for merging via whichever tree you think best. > --- > 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 <linux/pci.h> > #include <linux/acpi.h> > +#include <acpi/video.h> > > #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(&i915->drm, &conn_iter); > + drm_for_each_connector_iter(connector, &conn_iter) { > + struct intel_panel *panel = &to_intel_connector(connector)->panel; > + > + if (panel->backlight.funcs && !panel->backlight.device) { > + acpi_video_register_backlight(); > + break; > + } > + } > + drm_connector_list_iter_end(&conn_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); -- Jani Nikula, Intel Open Source Graphics Center
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 <jani.nikula@intel.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <linux/pwm.h>
> #include <linux/string_helpers.h>
>
> +#include <acpi/video.h>
> +
> #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(&i915->drm, "Skipping intel_backlight registration\n");
> + return 0;
> + }
> +
> memset(&props, 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?
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 <jani.nikula@intel.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <linux/pwm.h>
> #include <linux/string_helpers.h>
>
> +#include <acpi/video.h>
> +
> #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(&i915->drm, "Skipping intel_backlight registration\n");
> + return 0;
> + }
> +
> memset(&props, 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?
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 <jani.nikula@intel.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <linux/pwm.h>
> #include <linux/string_helpers.h>
>
> +#include <acpi/video.h>
> +
> #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(&i915->drm, "Skipping intel_backlight registration\n");
> + return 0;
> + }
> +
> memset(&props, 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?
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 <jani.nikula@intel.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> 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 <linux/pwm.h>
> #include <linux/string_helpers.h>
>
> +#include <acpi/video.h>
> +
> #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(&i915->drm, "Skipping intel_backlight registration\n");
> + return 0;
> + }
> +
> memset(&props, 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?
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 <jani.nikula@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/pwm.h> >> #include <linux/string_helpers.h> >> >> +#include <acpi/video.h> >> + >> #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(&i915->drm, "Skipping intel_backlight registration\n"); >> + return 0; >> + } >> + >> memset(&props, 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-7b9791c86d2e@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/acpi/video_detect.c index 0d9064a9804c..660ea46fbee8 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromebook(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -724,7 +730,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) * block on older devices without acpi-video support native * is usually not the best choice. */ - if (acpi_osi_is_win8() && native_available) + if (native_available && (acpi_osi_is_win8() || is_chromebook())) return acpi_backlight_native; else return acpi_backlight_video; The ACPI video bus is a pretty standard thing (and part of the ACPI standard), still I would not be surprised if it is missing from the ACPI tables on some Chromebooks, so a slightly bigger hammer approach would be: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0d9064a9804c..ff950be472a7 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromeos_firmware(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -713,6 +719,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (apple_gmux_present()) return acpi_backlight_apple_gmux; + /* On Chromebooks always use native if available */ + if (is_chromeos_firmware() && native_available) + return acpi_backlight_native; + /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* I assume you are more familiar with Chromebooks ACPI tables (or at least are better capable to sample a couple of them) so I will leave which approach to take is best up to you. Regards, Hans
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 <jani.nikula@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/pwm.h> >> #include <linux/string_helpers.h> >> >> +#include <acpi/video.h> >> + >> #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(&i915->drm, "Skipping intel_backlight registration\n"); >> + return 0; >> + } >> + >> memset(&props, 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-7b9791c86d2e@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/acpi/video_detect.c index 0d9064a9804c..660ea46fbee8 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromebook(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -724,7 +730,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) * block on older devices without acpi-video support native * is usually not the best choice. */ - if (acpi_osi_is_win8() && native_available) + if (native_available && (acpi_osi_is_win8() || is_chromebook())) return acpi_backlight_native; else return acpi_backlight_video; The ACPI video bus is a pretty standard thing (and part of the ACPI standard), still I would not be surprised if it is missing from the ACPI tables on some Chromebooks, so a slightly bigger hammer approach would be: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0d9064a9804c..ff950be472a7 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromeos_firmware(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -713,6 +719,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (apple_gmux_present()) return acpi_backlight_apple_gmux; + /* On Chromebooks always use native if available */ + if (is_chromeos_firmware() && native_available) + return acpi_backlight_native; + /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* I assume you are more familiar with Chromebooks ACPI tables (or at least are better capable to sample a couple of them) so I will leave which approach to take is best up to you. Regards, Hans
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 <jani.nikula@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/pwm.h> >> #include <linux/string_helpers.h> >> >> +#include <acpi/video.h> >> + >> #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(&i915->drm, "Skipping intel_backlight registration\n"); >> + return 0; >> + } >> + >> memset(&props, 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-7b9791c86d2e@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/acpi/video_detect.c index 0d9064a9804c..660ea46fbee8 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromebook(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -724,7 +730,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) * block on older devices without acpi-video support native * is usually not the best choice. */ - if (acpi_osi_is_win8() && native_available) + if (native_available && (acpi_osi_is_win8() || is_chromebook())) return acpi_backlight_native; else return acpi_backlight_video; The ACPI video bus is a pretty standard thing (and part of the ACPI standard), still I would not be surprised if it is missing from the ACPI tables on some Chromebooks, so a slightly bigger hammer approach would be: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0d9064a9804c..ff950be472a7 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromeos_firmware(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -713,6 +719,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (apple_gmux_present()) return acpi_backlight_apple_gmux; + /* On Chromebooks always use native if available */ + if (is_chromeos_firmware() && native_available) + return acpi_backlight_native; + /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* I assume you are more familiar with Chromebooks ACPI tables (or at least are better capable to sample a couple of them) so I will leave which approach to take is best up to you. Regards, Hans
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 <jani.nikula@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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 <linux/pwm.h> >> #include <linux/string_helpers.h> >> >> +#include <acpi/video.h> >> + >> #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(&i915->drm, "Skipping intel_backlight registration\n"); >> + return 0; >> + } >> + >> memset(&props, 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-7b9791c86d2e@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/acpi/video_detect.c index 0d9064a9804c..660ea46fbee8 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromebook(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -724,7 +730,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) * block on older devices without acpi-video support native * is usually not the best choice. */ - if (acpi_osi_is_win8() && native_available) + if (native_available && (acpi_osi_is_win8() || is_chromebook())) return acpi_backlight_native; else return acpi_backlight_video; The ACPI video bus is a pretty standard thing (and part of the ACPI standard), still I would not be surprised if it is missing from the ACPI tables on some Chromebooks, so a slightly bigger hammer approach would be: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0d9064a9804c..ff950be472a7 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromeos_firmware(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -713,6 +719,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (apple_gmux_present()) return acpi_backlight_apple_gmux; + /* On Chromebooks always use native if available */ + if (is_chromeos_firmware() && native_available) + return acpi_backlight_native; + /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* I assume you are more familiar with Chromebooks ACPI tables (or at least are better capable to sample a couple of them) so I will leave which approach to take is best up to you. Regards, Hans
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display (rev2) URL : https://patchwork.freedesktop.org/series/107755/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107755/revisions/2/mbox/ not applied Applying: ACPI: video: Add acpi_video_backlight_use_native() helper Using index info to reconstruct a base tree... M drivers/acpi/video_detect.c M include/acpi/video.h Falling back to patching base and 3-way merge... Auto-merging include/acpi/video.h CONFLICT (content): Merge conflict in include/acpi/video.h Auto-merging drivers/acpi/video_detect.c CONFLICT (content): Merge conflict in drivers/acpi/video_detect.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 ACPI: video: Add acpi_video_backlight_use_native() helper When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.
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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> --- 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 video). */ - if (google_cros_ec_present() && native_available) + if ((video_caps & ACPI_VIDEO_BACKLIGHT) && !acpi_osi_is_win8()) + return acpi_backlight_video; + + /* Use native backlight control if available */ + if (native_available) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> --- 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 video). */ - if (google_cros_ec_present() && native_available) + if ((video_caps & ACPI_VIDEO_BACKLIGHT) && !acpi_osi_is_win8()) + return acpi_backlight_video; + + /* Use native backlight control if available */ + if (native_available) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> --- 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 video). */ - if (google_cros_ec_present() && native_available) + if ((video_caps & ACPI_VIDEO_BACKLIGHT) && !acpi_osi_is_win8()) + return acpi_backlight_video; + + /* Use native backlight control if available */ + if (native_available) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> --- 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 video). */ - if (google_cros_ec_present() && native_available) + if ((video_caps & ACPI_VIDEO_BACKLIGHT) && !acpi_osi_is_win8()) + return acpi_backlight_video; + + /* Use native backlight control if available */ + if (native_available) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> --- 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 video). */ - if (google_cros_ec_present() && native_available) + if ((video_caps & ACPI_VIDEO_BACKLIGHT) && !acpi_osi_is_win8()) + return acpi_backlight_video; + + /* Use native backlight control if available */ + if (native_available) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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.
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.
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.
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.
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.
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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-7b9791c86d2e@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
On 10/25/2022 15: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 > > 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. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. > > 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 >
On 10/25/2022 15: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 > > 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. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. > > 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 >
On 10/25/2022 15: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 > > 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. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. > > 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 >
On 10/25/2022 15: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 > > 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. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. > > 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 >
On 10/25/2022 15: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 > > 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. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. > > 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 >
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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-7b9791c86d2e@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
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. > 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).
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. > 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).
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. > 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).
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. > 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).
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. > 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).
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display (rev3) URL : https://patchwork.freedesktop.org/series/107755/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107755/revisions/3/mbox/ not applied Applying: ACPI: video: Add acpi_video_backlight_use_native() helper Using index info to reconstruct a base tree... M drivers/acpi/video_detect.c M include/acpi/video.h Falling back to patching base and 3-way merge... Auto-merging include/acpi/video.h CONFLICT (content): Merge conflict in include/acpi/video.h Auto-merging drivers/acpi/video_detect.c CONFLICT (content): Merge conflict in drivers/acpi/video_detect.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 ACPI: video: Add acpi_video_backlight_use_native() helper When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
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() >= 2018) && native_available) return acpi_backlight_native; else return acpi_backlight_video; Although I think that will result in the same behavior as my patch below, and then my patch below would be cleaner... ### Also note that there actually already is a DMI quirk for the X201s, forcing ACPI video backlight control there. This is not strictly necessary, but when we first started using native by default on (back then) newer laptops some users of script everything yourself window-managers like i3 complained that they were relying on the in kernel handling of brightness key presses, which only works when using the acpi backlight control method... If that quirk matches your device then fixing the acpi_video_get_backlight_type() heuristics is not going to help. In that case we might decide to just drop the quirk though, since it was never really necessary in the first place; or change it to native, which may also help the X210 case? Regards, Hans From 31fa1f5e60b32a5e239023a2f0f5a6d457175e5a Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Tue, 25 Oct 2022 20:38:56 +0200 Subject: [PATCH] ACPI: video: Fix acpi_video_get_backlight_type() on coreboot laptops On laptops flashed with Coreboot the ACPI tables will often not have ACPI Video Bus backlight control, which was causing acpi_video_get_backlight_type() to return vendor even though GPU native backlight control is available and should be used. Rework acpi_video_get_backlight_type() so as to not rely on the presence of ACPI Video Bus backlight control to decide if native backlight control should be used. Note this may break things on old laptops where the vendor interface should actually be used, in case these have been flashed with Coreboot causing their BIOS-date year to match the check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video_detect.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 9cd8797d12bb..2fe0fd22a7ac 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -718,30 +718,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. + * On older systems the backlight was typically connected to the EC + * rather then to the GPU, so GPU native control may not work there. + * Prefer native on devices designed for Windows 8+, Chromebooks and + * laptops with a BIOS from 2018 or later (for misc. Coreboot models). */ - if (google_cros_ec_present() && native_available) + if (native_available && (acpi_osi_is_win8() || + google_cros_ec_present() || + dmi_get_bios_year() >= 2018)) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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() >= 2018) && native_available) return acpi_backlight_native; else return acpi_backlight_video; Although I think that will result in the same behavior as my patch below, and then my patch below would be cleaner... ### Also note that there actually already is a DMI quirk for the X201s, forcing ACPI video backlight control there. This is not strictly necessary, but when we first started using native by default on (back then) newer laptops some users of script everything yourself window-managers like i3 complained that they were relying on the in kernel handling of brightness key presses, which only works when using the acpi backlight control method... If that quirk matches your device then fixing the acpi_video_get_backlight_type() heuristics is not going to help. In that case we might decide to just drop the quirk though, since it was never really necessary in the first place; or change it to native, which may also help the X210 case? Regards, Hans From 31fa1f5e60b32a5e239023a2f0f5a6d457175e5a Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Tue, 25 Oct 2022 20:38:56 +0200 Subject: [PATCH] ACPI: video: Fix acpi_video_get_backlight_type() on coreboot laptops On laptops flashed with Coreboot the ACPI tables will often not have ACPI Video Bus backlight control, which was causing acpi_video_get_backlight_type() to return vendor even though GPU native backlight control is available and should be used. Rework acpi_video_get_backlight_type() so as to not rely on the presence of ACPI Video Bus backlight control to decide if native backlight control should be used. Note this may break things on old laptops where the vendor interface should actually be used, in case these have been flashed with Coreboot causing their BIOS-date year to match the check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video_detect.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 9cd8797d12bb..2fe0fd22a7ac 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -718,30 +718,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. + * On older systems the backlight was typically connected to the EC + * rather then to the GPU, so GPU native control may not work there. + * Prefer native on devices designed for Windows 8+, Chromebooks and + * laptops with a BIOS from 2018 or later (for misc. Coreboot models). */ - if (google_cros_ec_present() && native_available) + if (native_available && (acpi_osi_is_win8() || + google_cros_ec_present() || + dmi_get_bios_year() >= 2018)) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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() >= 2018) && native_available) return acpi_backlight_native; else return acpi_backlight_video; Although I think that will result in the same behavior as my patch below, and then my patch below would be cleaner... ### Also note that there actually already is a DMI quirk for the X201s, forcing ACPI video backlight control there. This is not strictly necessary, but when we first started using native by default on (back then) newer laptops some users of script everything yourself window-managers like i3 complained that they were relying on the in kernel handling of brightness key presses, which only works when using the acpi backlight control method... If that quirk matches your device then fixing the acpi_video_get_backlight_type() heuristics is not going to help. In that case we might decide to just drop the quirk though, since it was never really necessary in the first place; or change it to native, which may also help the X210 case? Regards, Hans From 31fa1f5e60b32a5e239023a2f0f5a6d457175e5a Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Tue, 25 Oct 2022 20:38:56 +0200 Subject: [PATCH] ACPI: video: Fix acpi_video_get_backlight_type() on coreboot laptops On laptops flashed with Coreboot the ACPI tables will often not have ACPI Video Bus backlight control, which was causing acpi_video_get_backlight_type() to return vendor even though GPU native backlight control is available and should be used. Rework acpi_video_get_backlight_type() so as to not rely on the presence of ACPI Video Bus backlight control to decide if native backlight control should be used. Note this may break things on old laptops where the vendor interface should actually be used, in case these have been flashed with Coreboot causing their BIOS-date year to match the check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video_detect.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 9cd8797d12bb..2fe0fd22a7ac 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -718,30 +718,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. + * On older systems the backlight was typically connected to the EC + * rather then to the GPU, so GPU native control may not work there. + * Prefer native on devices designed for Windows 8+, Chromebooks and + * laptops with a BIOS from 2018 or later (for misc. Coreboot models). */ - if (google_cros_ec_present() && native_available) + if (native_available && (acpi_osi_is_win8() || + google_cros_ec_present() || + dmi_get_bios_year() >= 2018)) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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() >= 2018) && native_available) return acpi_backlight_native; else return acpi_backlight_video; Although I think that will result in the same behavior as my patch below, and then my patch below would be cleaner... ### Also note that there actually already is a DMI quirk for the X201s, forcing ACPI video backlight control there. This is not strictly necessary, but when we first started using native by default on (back then) newer laptops some users of script everything yourself window-managers like i3 complained that they were relying on the in kernel handling of brightness key presses, which only works when using the acpi backlight control method... If that quirk matches your device then fixing the acpi_video_get_backlight_type() heuristics is not going to help. In that case we might decide to just drop the quirk though, since it was never really necessary in the first place; or change it to native, which may also help the X210 case? Regards, Hans From 31fa1f5e60b32a5e239023a2f0f5a6d457175e5a Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Tue, 25 Oct 2022 20:38:56 +0200 Subject: [PATCH] ACPI: video: Fix acpi_video_get_backlight_type() on coreboot laptops On laptops flashed with Coreboot the ACPI tables will often not have ACPI Video Bus backlight control, which was causing acpi_video_get_backlight_type() to return vendor even though GPU native backlight control is available and should be used. Rework acpi_video_get_backlight_type() so as to not rely on the presence of ACPI Video Bus backlight control to decide if native backlight control should be used. Note this may break things on old laptops where the vendor interface should actually be used, in case these have been flashed with Coreboot causing their BIOS-date year to match the check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video_detect.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 9cd8797d12bb..2fe0fd22a7ac 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -718,30 +718,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. + * On older systems the backlight was typically connected to the EC + * rather then to the GPU, so GPU native control may not work there. + * Prefer native on devices designed for Windows 8+, Chromebooks and + * laptops with a BIOS from 2018 or later (for misc. Coreboot models). */ - if (google_cros_ec_present() && native_available) + if (native_available && (acpi_osi_is_win8() || + google_cros_ec_present() || + dmi_get_bios_year() >= 2018)) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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() >= 2018) && native_available) return acpi_backlight_native; else return acpi_backlight_video; Although I think that will result in the same behavior as my patch below, and then my patch below would be cleaner... ### Also note that there actually already is a DMI quirk for the X201s, forcing ACPI video backlight control there. This is not strictly necessary, but when we first started using native by default on (back then) newer laptops some users of script everything yourself window-managers like i3 complained that they were relying on the in kernel handling of brightness key presses, which only works when using the acpi backlight control method... If that quirk matches your device then fixing the acpi_video_get_backlight_type() heuristics is not going to help. In that case we might decide to just drop the quirk though, since it was never really necessary in the first place; or change it to native, which may also help the X210 case? Regards, Hans From 31fa1f5e60b32a5e239023a2f0f5a6d457175e5a Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Tue, 25 Oct 2022 20:38:56 +0200 Subject: [PATCH] ACPI: video: Fix acpi_video_get_backlight_type() on coreboot laptops On laptops flashed with Coreboot the ACPI tables will often not have ACPI Video Bus backlight control, which was causing acpi_video_get_backlight_type() to return vendor even though GPU native backlight control is available and should be used. Rework acpi_video_get_backlight_type() so as to not rely on the presence of ACPI Video Bus backlight control to decide if native backlight control should be used. Note this may break things on old laptops where the vendor interface should actually be used, in case these have been flashed with Coreboot causing their BIOS-date year to match the check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video_detect.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 9cd8797d12bb..2fe0fd22a7ac 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -718,30 +718,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. + * On older systems the backlight was typically connected to the EC + * rather then to the GPU, so GPU native control may not work there. + * Prefer native on devices designed for Windows 8+, Chromebooks and + * laptops with a BIOS from 2018 or later (for misc. Coreboot models). */ - if (google_cros_ec_present() && native_available) + if (native_available && (acpi_osi_is_win8() || + google_cros_ec_present() || + dmi_get_bios_year() >= 2018)) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; } -- 2.37.3
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.
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. 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. So, it feels like there's two choices:
1) Make a default policy decision, but then allow that decision to be
altered later on (eg, when a vendor-specific platform driver has been
loaded) - you've said this poses additional complexities.
2) Move the knowledge of whether or not there's a vendor interface into
the core code. Basically take every platform driver that exposes a
vendor interface, and move the detection code into the core.
I think any other approach is going to result in machines that
previously worked no longer working (and you can't just make the
vendor/native split dependent on the Coreboot DMI BIOS string, because
there are some Coreboot platforms that implement the vendor interface
for compatibility, and you also can't ask all Coreboot users to update
their firmware to fix things)
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.
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. 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. So, it feels like there's two choices:
1) Make a default policy decision, but then allow that decision to be
altered later on (eg, when a vendor-specific platform driver has been
loaded) - you've said this poses additional complexities.
2) Move the knowledge of whether or not there's a vendor interface into
the core code. Basically take every platform driver that exposes a
vendor interface, and move the detection code into the core.
I think any other approach is going to result in machines that
previously worked no longer working (and you can't just make the
vendor/native split dependent on the Coreboot DMI BIOS string, because
there are some Coreboot platforms that implement the vendor interface
for compatibility, and you also can't ask all Coreboot users to update
their firmware to fix things)
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.
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. 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. So, it feels like there's two choices:
1) Make a default policy decision, but then allow that decision to be
altered later on (eg, when a vendor-specific platform driver has been
loaded) - you've said this poses additional complexities.
2) Move the knowledge of whether or not there's a vendor interface into
the core code. Basically take every platform driver that exposes a
vendor interface, and move the detection code into the core.
I think any other approach is going to result in machines that
previously worked no longer working (and you can't just make the
vendor/native split dependent on the Coreboot DMI BIOS string, because
there are some Coreboot platforms that implement the vendor interface
for compatibility, and you also can't ask all Coreboot users to update
their firmware to fix things)
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.
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. 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. So, it feels like there's two choices:
1) Make a default policy decision, but then allow that decision to be
altered later on (eg, when a vendor-specific platform driver has been
loaded) - you've said this poses additional complexities.
2) Move the knowledge of whether or not there's a vendor interface into
the core code. Basically take every platform driver that exposes a
vendor interface, and move the detection code into the core.
I think any other approach is going to result in machines that
previously worked no longer working (and you can't just make the
vendor/native split dependent on the Coreboot DMI BIOS string, because
there are some Coreboot platforms that implement the vendor interface
for compatibility, and you also can't ask all Coreboot users to update
their firmware to fix things)
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.
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. 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. So, it feels like there's two choices:
1) Make a default policy decision, but then allow that decision to be
altered later on (eg, when a vendor-specific platform driver has been
loaded) - you've said this poses additional complexities.
2) Move the knowledge of whether or not there's a vendor interface into
the core code. Basically take every platform driver that exposes a
vendor interface, and move the detection code into the core.
I think any other approach is going to result in machines that
previously worked no longer working (and you can't just make the
vendor/native split dependent on the Coreboot DMI BIOS string, because
there are some Coreboot platforms that implement the vendor interface
for compatibility, and you also can't ask all Coreboot users to update
their firmware to fix things)
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display (rev4) URL : https://patchwork.freedesktop.org/series/107755/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107755/revisions/4/mbox/ not applied Applying: ACPI: video: Add acpi_video_backlight_use_native() helper Using index info to reconstruct a base tree... M drivers/acpi/video_detect.c M include/acpi/video.h Falling back to patching base and 3-way merge... Auto-merging include/acpi/video.h CONFLICT (content): Merge conflict in include/acpi/video.h Auto-merging drivers/acpi/video_detect.c CONFLICT (content): Merge conflict in drivers/acpi/video_detect.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 ACPI: video: Add acpi_video_backlight_use_native() helper When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
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 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 ? Can you please provide the following info for your laptop: 1. Output of "ls /sys/class/backlight" with 6.0 (working setup) 2. Output of "ls /sys/class/backlight" with 6.1 (non-working setup) 3. dmidecode output, so that I can check if this quirk: { .callback = video_detect_force_video, /* ThinkPad X201s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), }, }, will trigger. 4. An acpidump. Although you already said that you have removed the ACPI video bus bits, so I guess I can just assume that the ACPI_VIDEO_BACKLIGHT flag won't get set. Regards, Hans p.s. This thread has made me wonder if the 6.1 changes don't cause regressions on other laptops flashed with a CoreOS BIOS, I will start a mail-thread asking for testing on the CoreOS mailinglist.
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 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 ? Can you please provide the following info for your laptop: 1. Output of "ls /sys/class/backlight" with 6.0 (working setup) 2. Output of "ls /sys/class/backlight" with 6.1 (non-working setup) 3. dmidecode output, so that I can check if this quirk: { .callback = video_detect_force_video, /* ThinkPad X201s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), }, }, will trigger. 4. An acpidump. Although you already said that you have removed the ACPI video bus bits, so I guess I can just assume that the ACPI_VIDEO_BACKLIGHT flag won't get set. Regards, Hans p.s. This thread has made me wonder if the 6.1 changes don't cause regressions on other laptops flashed with a CoreOS BIOS, I will start a mail-thread asking for testing on the CoreOS mailinglist.
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 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 ? Can you please provide the following info for your laptop: 1. Output of "ls /sys/class/backlight" with 6.0 (working setup) 2. Output of "ls /sys/class/backlight" with 6.1 (non-working setup) 3. dmidecode output, so that I can check if this quirk: { .callback = video_detect_force_video, /* ThinkPad X201s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), }, }, will trigger. 4. An acpidump. Although you already said that you have removed the ACPI video bus bits, so I guess I can just assume that the ACPI_VIDEO_BACKLIGHT flag won't get set. Regards, Hans p.s. This thread has made me wonder if the 6.1 changes don't cause regressions on other laptops flashed with a CoreOS BIOS, I will start a mail-thread asking for testing on the CoreOS mailinglist.
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 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 ? Can you please provide the following info for your laptop: 1. Output of "ls /sys/class/backlight" with 6.0 (working setup) 2. Output of "ls /sys/class/backlight" with 6.1 (non-working setup) 3. dmidecode output, so that I can check if this quirk: { .callback = video_detect_force_video, /* ThinkPad X201s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), }, }, will trigger. 4. An acpidump. Although you already said that you have removed the ACPI video bus bits, so I guess I can just assume that the ACPI_VIDEO_BACKLIGHT flag won't get set. Regards, Hans p.s. This thread has made me wonder if the 6.1 changes don't cause regressions on other laptops flashed with a CoreOS BIOS, I will start a mail-thread asking for testing on the CoreOS mailinglist.
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 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 ? Can you please provide the following info for your laptop: 1. Output of "ls /sys/class/backlight" with 6.0 (working setup) 2. Output of "ls /sys/class/backlight" with 6.1 (non-working setup) 3. dmidecode output, so that I can check if this quirk: { .callback = video_detect_force_video, /* ThinkPad X201s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), }, }, will trigger. 4. An acpidump. Although you already said that you have removed the ACPI video bus bits, so I guess I can just assume that the ACPI_VIDEO_BACKLIGHT flag won't get set. Regards, Hans p.s. This thread has made me wonder if the 6.1 changes don't cause regressions on other laptops flashed with a CoreOS BIOS, I will start a mail-thread asking for testing on the CoreOS mailinglist.
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. > > 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 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, and you're not taking that into account in the video_detect code.
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. > > 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 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, and you're not taking that into account in the video_detect code.
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. > > 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 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, and you're not taking that into account in the video_detect code.
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. > > 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 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, and you're not taking that into account in the video_detect code.
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. > > 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 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, and you're not taking that into account in the video_detect code.
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
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
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
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
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
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. 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).
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. 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).
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. 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).
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. 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).
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. 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).
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.
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.
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.
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.
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.
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 wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > 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". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
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 wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > 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". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
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 wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > 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". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
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 wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > 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". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
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 wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > 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". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
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
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
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
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
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
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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?
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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?
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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?
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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?
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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?
Hi,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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
Hi,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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
Hi,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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
Hi,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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
Hi,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 10/27/22 14:09, Rafael J. Wysocki wrote:
> > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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.
Sure.
My point is that if it doesn't work OOTB for someone, and say it used
to, they can use the above workaround and report back.
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 10/27/22 14:09, Rafael J. Wysocki wrote:
> > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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.
Sure.
My point is that if it doesn't work OOTB for someone, and say it used
to, they can use the above workaround and report back.
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 10/27/22 14:09, Rafael J. Wysocki wrote:
> > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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.
Sure.
My point is that if it doesn't work OOTB for someone, and say it used
to, they can use the above workaround and report back.
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 10/27/22 14:09, Rafael J. Wysocki wrote:
> > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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.
Sure.
My point is that if it doesn't work OOTB for someone, and say it used
to, they can use the above workaround and report back.
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 10/27/22 14:09, Rafael J. Wysocki wrote:
> > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> 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.
Sure.
My point is that if it doesn't work OOTB for someone, and say it used
to, they can use the above workaround and report back.
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 <hdegoede@redhat.com> 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 changed back.
-The following laptop models actually use a vendor backlight control method,
while also having a native backlight entry under /sys/class/backlight:
Asus EeePC 901 -> native backlight confirmed to also work
Dell Latitude D610 -> native backlight confirmed to work better then vendor
Sony Vaio PCG-FRV3 -> native backlight not tested
Note these will keep working the same as before in 6.1, independent of
the revert. I've tracked these seperately because they will likely be
affected by future changes to the heuristics.
Regards,
Hans
p.s.
My plan is to try again with 6.2 by making native be preferred over vendor
(when native is available). It looks like native tends to work well when
available even on systems so old that the don't have acpi_video
backlight control support.
I do plan to do another blogpost asking people to explicitly test
that native works on laptops with a combination of vendor + native
backlight control available.
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 <hdegoede@redhat.com> 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 changed back.
-The following laptop models actually use a vendor backlight control method,
while also having a native backlight entry under /sys/class/backlight:
Asus EeePC 901 -> native backlight confirmed to also work
Dell Latitude D610 -> native backlight confirmed to work better then vendor
Sony Vaio PCG-FRV3 -> native backlight not tested
Note these will keep working the same as before in 6.1, independent of
the revert. I've tracked these seperately because they will likely be
affected by future changes to the heuristics.
Regards,
Hans
p.s.
My plan is to try again with 6.2 by making native be preferred over vendor
(when native is available). It looks like native tends to work well when
available even on systems so old that the don't have acpi_video
backlight control support.
I do plan to do another blogpost asking people to explicitly test
that native works on laptops with a combination of vendor + native
backlight control available.
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 <hdegoede@redhat.com> 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 changed back.
-The following laptop models actually use a vendor backlight control method,
while also having a native backlight entry under /sys/class/backlight:
Asus EeePC 901 -> native backlight confirmed to also work
Dell Latitude D610 -> native backlight confirmed to work better then vendor
Sony Vaio PCG-FRV3 -> native backlight not tested
Note these will keep working the same as before in 6.1, independent of
the revert. I've tracked these seperately because they will likely be
affected by future changes to the heuristics.
Regards,
Hans
p.s.
My plan is to try again with 6.2 by making native be preferred over vendor
(when native is available). It looks like native tends to work well when
available even on systems so old that the don't have acpi_video
backlight control support.
I do plan to do another blogpost asking people to explicitly test
that native works on laptops with a combination of vendor + native
backlight control available.
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 <hdegoede@redhat.com> 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 changed back.
-The following laptop models actually use a vendor backlight control method,
while also having a native backlight entry under /sys/class/backlight:
Asus EeePC 901 -> native backlight confirmed to also work
Dell Latitude D610 -> native backlight confirmed to work better then vendor
Sony Vaio PCG-FRV3 -> native backlight not tested
Note these will keep working the same as before in 6.1, independent of
the revert. I've tracked these seperately because they will likely be
affected by future changes to the heuristics.
Regards,
Hans
p.s.
My plan is to try again with 6.2 by making native be preferred over vendor
(when native is available). It looks like native tends to work well when
available even on systems so old that the don't have acpi_video
backlight control support.
I do plan to do another blogpost asking people to explicitly test
that native works on laptops with a combination of vendor + native
backlight control available.
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 <hdegoede@redhat.com> 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 changed back.
-The following laptop models actually use a vendor backlight control method,
while also having a native backlight entry under /sys/class/backlight:
Asus EeePC 901 -> native backlight confirmed to also work
Dell Latitude D610 -> native backlight confirmed to work better then vendor
Sony Vaio PCG-FRV3 -> native backlight not tested
Note these will keep working the same as before in 6.1, independent of
the revert. I've tracked these seperately because they will likely be
affected by future changes to the heuristics.
Regards,
Hans
p.s.
My plan is to try again with 6.2 by making native be preferred over vendor
(when native is available). It looks like native tends to work well when
available even on systems so old that the don't have acpi_video
backlight control support.
I do plan to do another blogpost asking people to explicitly test
that native works on laptops with a combination of vendor + native
backlight control available.