mirror of
https://github.com/torvalds/linux.git
synced 2024-11-15 16:41:58 +00:00
1b7f37e127
Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor();
acpi_video_unregister();
The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx:
1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
and i915)
2) acpi-video does NOT call acpi_video_register()
3) acpi_vendor loads (lets assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister -> not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx
1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
for the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||
|---|---|---|
| .. | ||
| acpica | ||
| apei | ||
| ac.c | ||
| acpi_cmos_rtc.c | ||
| acpi_extlog.c | ||
| acpi_ipmi.c | ||
| acpi_lpss.c | ||
| acpi_memhotplug.c | ||
| acpi_pad.c | ||
| acpi_platform.c | ||
| acpi_processor.c | ||
| battery.c | ||
| battery.h | ||
| bgrt.c | ||
| blacklist.c | ||
| bus.c | ||
| button.c | ||
| container.c | ||
| custom_method.c | ||
| debugfs.c | ||
| device_pm.c | ||
| dock.c | ||
| ec_sys.c | ||
| ec.c | ||
| event.c | ||
| fan.c | ||
| glue.c | ||
| hed.c | ||
| internal.h | ||
| Kconfig | ||
| Makefile | ||
| numa.c | ||
| nvs.c | ||
| osl.c | ||
| pci_irq.c | ||
| pci_link.c | ||
| pci_root.c | ||
| pci_slot.c | ||
| power.c | ||
| proc.c | ||
| processor_core.c | ||
| processor_driver.c | ||
| processor_idle.c | ||
| processor_perflib.c | ||
| processor_thermal.c | ||
| processor_throttling.c | ||
| reboot.c | ||
| resource.c | ||
| sbs.c | ||
| sbshc.c | ||
| sbshc.h | ||
| scan.c | ||
| sleep.c | ||
| sleep.h | ||
| sysfs.c | ||
| tables.c | ||
| thermal.c | ||
| utils.c | ||
| video_detect.c | ||
| video.c | ||
| wakeup.c | ||