-
Hans de Goede authored
Some Toshibas have a broken acpi-video interface for brightness control, so far these have been using a special workaround in drivers/acpi/acpi_video.c which gets activated by the disable_backlight_sysfs_if module-param/quirks. The recent x86/acpi backlight refactoring has broken this workaround: 1. This workaround relies on acpi_video_get_backlight_type() returning acpi_video so that the acpi_video code actually runs; and 2. this relies on the actual native GPU driver to offer the sysfs backlight interface to userspace. After the refactor this breaks since the native driver will no longer register its backlight-device if acpi_video_get_backlight_type() does not return native and making it return native breaks 1. Keeping the acpi_video backlight handling on resume active, while not using it to set the brightness, is necessary because it does a _BCM call on resume which is necessary to turn the panel back on on resume. Looking at the DSDT shows that this _BCM call results in a Toshiba HCI_SET HCI_LCD_BRIGHTNESS call, which turns the panel back on. This commit makes toshiba_acpi do a HCI_SET HCI_PANEL_POWER_ON call on resume on the affected models, so that the (now broken) acpi_video disable_backlight_sysfs_if workaround will no longer be necessary. Note this uses HCI_PANEL_POWER_ON instead of HCI_LCD_BRIGHTNESS to avoid changing the configured brightness level. Tested-by: Arvid Norlander <lkml@vorpal.se> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
3cb1f40d