On Mon, 27 Feb 2017 15:25:32 +0100, Hans de Goede wrote: > > Hi, > > On 27-02-17 14:30, Rafael J. Wysocki wrote: > > +Mika & Andy > > > > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote: > >> Several cherrytrail devices (all of which ship with windows 10) hide the > >> lpss pwm controller in ACPI, typically the _STA method looks like this: > >> > >> Method (_STA, 0, NotSerialized) // _STA: Status > >> { > >> If (OSID == One) > >> { > >> Return (Zero) > >> } > >> > >> Return (0x0F) > >> } > >> > >> Where OSID is some dark magic seen in all cherrytrail ACPI tables making > >> the machine behave differently depending on which OS it *thinks* it is > >> booting, this gets set in a number of ways which we cannot control, on > >> some newer machines it simple hardcoded to "One" aka win10. > >> > >> This causes the PWM controller to get hidden, which means Linux cannot > >> control the backlight level on cht based tablets / laptops. > >> > >> Since loading the driver for this does no harm (the only in kernel user > >> of it is the i915 driver, which will only use it when it needs it), this > >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT > >> for the 80862288 device, fixing the lack of backlight control. > >> > >> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > >> --- > >> drivers/acpi/bus.c | 25 +++++++++++++++++++++++++ > >> 1 file changed, 25 insertions(+) > >> > >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c > >> index 95855cb..483d4d0 100644 > >> --- a/drivers/acpi/bus.c > >> +++ b/drivers/acpi/bus.c > >> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle handle, > >> return status; > >> } > >> > >> +/* > >> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because > >> + * some recent windows drivers bind to one device but poke at multiple > >> + * devices at the same time, so the others get hidden. > >> + * We work around this by always reporting ACPI_STA_DEFAULT for these > >> + * devices. Note this MUST only be done for devices where this is safe. > >> + */ > >> +static const struct acpi_device_id always_present_device_ids[] = { > >> + /* > >> + * Cherrytrail pwm directly poked by GPU driver in win10, > >> + * but Linux uses a separate pwm driver, harmless if not used. > >> + */ > >> + { "80862288", }, > >> + { } > >> +}; > >> + > >> int acpi_bus_get_status(struct acpi_device *device) > >> { > >> acpi_status status; > >> unsigned long long sta; > >> > >> + /* acpi_match_device_ids checks status, so start with default */ > >> + acpi_set_device_status(device, ACPI_STA_DEFAULT); > > > > This shouldn't be done in a "get" routine. > > With this you mean the acpi_match_device_ids() check I assume ? > (acpi_bus_get_status already calls acpi_set_device_status()) > > > Ideally, a scan handler should do that or similar. > > The problem is that drivers/acpi/scan.c: acpi_bus_attach() > calls acpi_bus_get_status() and if it does not set > the status to present acpi_bus_attach() exits without bothering > with attaching scan handlers, which is why I ended up doing this > here. Oh, this is interesting, please let me join to the party. We've hit a similar problem, but for other one: namely, it's INT0002 that is found on a few CHT devices. It's never bound properly by a similar reason, where _STA is always zero on Linux: Method (_STA, 0, NotSerialized) // _STA: Status { If (SOCS <= 0x04) { Return (0x0F) } Else { Return (Zero) } } The device is supposed to be a "virtual GPIO" stuff, and the driver hasn't been upstreamed from Intel. Due to the lack of this driver (and it's binding), the machine gets spurious IRQ#9 after the PM resume, and it locks up at the second time of PM. thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx