ACPI / LPSS: Only call pwm_add_table() for Bay Trail PWM if PMIC HRV is 2
authorHans de Goede <hdegoede@redhat.com>
Fri, 13 Apr 2018 12:54:17 +0000 (14:54 +0200)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>
Thu, 10 May 2018 14:54:40 +0000 (16:54 +0200)
commitc975e472ec12392a0c34de1350e634310f8a1dea
tree35c011f7b3d1c426fa7d5b89411665c17fd12cee
parent75bc37fefc4471e718ba8e651aa74673d4e0a9eb
ACPI / LPSS: Only call pwm_add_table() for Bay Trail PWM if PMIC HRV is 2

The Point of View mobii wintab p800w Bay Trail tablet comes with a Crystal
Cove PMIC, yet uses the LPSS PWM for backlight control, rather then the
Crystal Cove's PWM, so we need to call pwm_add_table() to add a
pwm_backlight mapping for the LPSS pwm despite there being an INT33FD
ACPI device present.

On all Bay Trail devices the _HRV object of the INT33FD ACPI device
will normally return 2, to indicate the Bay Trail variant of the CRC
PMIC is present, except on this tablet where _HRV is 0xffff. I guess this
is a hack to make the windows Crystal Cove PWM driver not bind.

Out of the 44 DSTDs with an INT33FD device in there which I have (from
different model devices) only the pov mobii wintab p800w uses 0xffff for
the HRV.

The byt_pwm_setup code calls acpi_dev_present to check for the presence
of a INT33FD ACPI device which indicates that a CRC PMIC is present and
if the INT33FD ACPI device is present then byt_pwm_setup will not add
a pwm_backlight mapping for the LPSS pwm, so that the CRC PWM will get
used instead.

acpi_dev_present has a hrv parameter, this commit make us pass 2 instead
of -1, so that things still match on normal tablets, but on this special
case with its _HRV of 0xffff, the check will now fail so that the
pwm_backlight mapping for the LPSS pwm gets added fixing backlight
brightness control on this device.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/acpi/acpi_lpss.c