Hi All,
On cherrytrail tablets / laptops the backlight typically
is controlled by the lpss pwm module, this is listed
as an acpi device with a HID of 80862288. All 3 cherrytrail
devices I've access to have the following dsdt code for this:
Device (PWM1)
{
Name (_HID, "80862288") // _HID: Hardware ID
Name (_CID, "80862288") // _CID: Compatible ID
Name (_DDN, "Intel(R) PWM Controller #1 - 80862288") // _DDN: DOS D
<snip>
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}
Return (0x0F)
}
<snip>
}
Notice the OSID == One, OSID is something, well really stupid
(sorry I've no nicer word for this) in cherrytrail ACPI tables,
where one can often choose which OS to configure the tables for
in the BIOS typically one can choose between Android and Win8.1
(this is mixed with the typical _OSI calls setting OSYS).
For added fun, OSID sometimes changes depending on things like
the EFI system partition having an EFI/Boot/bootx64.efi present
or not. If present then the firmware assumes it is booting windows
10 and will set OSID to One. On another device it is simply
always One, so on these devices _STA for the "80862288" device
returns 0, no matching platform device gets created and the
pwm-lpss-platfrom driver does not bind to the pwm controller.
Which causes none working backlight control, there are 8, yes
EIGHT acpi_video# backlight interfaces which get registered
if the pwm controller is not found by the i915 driver, but none
of them works.
I'm guessing that in Windows 10 if the i915 opregion specifies
that pwm should be used that the windows graphics drivers then
"simply" directly accesses the pwm controller itself.
Unless we want to do the same, we are going to need some way
to override the _STA result for a device and get the acpi
bus to re-enumerate the device after we've done the override.
Regards,
Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
