From patchwork Wed Feb 17 01:57:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Airlie X-Patchwork-Id: 8333641 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E5892C02AA for ; Wed, 17 Feb 2016 01:57:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3A9F1202FF for ; Wed, 17 Feb 2016 01:57:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 68AFE2026C for ; Wed, 17 Feb 2016 01:57:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964875AbcBQB5w (ORCPT ); Tue, 16 Feb 2016 20:57:52 -0500 Received: from mail-lb0-f182.google.com ([209.85.217.182]:35455 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933619AbcBQB5v (ORCPT ); Tue, 16 Feb 2016 20:57:51 -0500 Received: by mail-lb0-f182.google.com with SMTP id bc4so1260614lbc.2; Tue, 16 Feb 2016 17:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UIoq7H1nudAV8/p2u/iLk9I7V7EVG7Ydzv3kHIVaMiQ=; b=AR41S0dI1V8xkn/U2dd9OKra5P6WrqEatQYspohXesvYPRJGO4QEHBYOi8EfT88qNg BHvX60To/u3IXWETOj0dRL0bQzcrp8hfJu3GIln9WcAg0HLXYTNM9MMkCpRdRqgTU7vc OI0a0wS68pC9lfzHG1y+Wi9UbWcQd76ilashYWWIlGIofrNb6AEsNyIy60wrKVzzK553 Y8mkdIgB2kGMpxQo1LBR7LtEmDhhmyYd7mwZSqLF7HI0FyhoK1GfGt0MtzL72IOpGyNE sY9N+FpkonnfYk/VGZUt6bx9QhGbdq8LZkM9HaKGpG2iA0gm3rvbb+yHzco6yG+WMUSU bJVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=UIoq7H1nudAV8/p2u/iLk9I7V7EVG7Ydzv3kHIVaMiQ=; b=I3nadGlBky4L+Bptc0JR0tQic0k19OWlXwUFDSQ4EvtRtiS+gam2YQE04On7ZKSeFp cHg+m2aF3JzJjmdsveJ3GB+QV5qjlXonL5iQTVgatZHNRuc0nVaRLXyQsfM/H1Pu6c+j p4Q/26fvU0lH+Asffu5zuiIhenNYsF6nXWI6tmLOrQK6dIGm74fbVy7lGKjOzGF0XlOM htRmK6a3bwANSiwGb60n95pXYkaYxL2E5hzAXr3OR/Gg/PzCJDyhBG5TuwDhaUh6zlf1 KqQc0mUPgDKVlekkeMwBTDuSKfp7w2vGPFZGWbpU79ilSYag5afskv4MQS7y8kE+ccJm ixag== X-Gm-Message-State: AG10YORFsNMsZU8E3+6rTl4tSnZCrWtgJPbKbc4vY/zr5BDkwd9IcAsOn2f3XFpNuAtW3RFaD6SSiuGs7+r/ng== MIME-Version: 1.0 X-Received: by 10.112.159.233 with SMTP id xf9mr10936660lbb.21.1455674269472; Tue, 16 Feb 2016 17:57:49 -0800 (PST) Received: by 10.112.141.138 with HTTP; Tue, 16 Feb 2016 17:57:49 -0800 (PST) Date: Wed, 17 Feb 2016 11:57:49 +1000 Message-ID: Subject: Lenovo W541, windows 10 and ACPI PM From: Dave Airlie To: Linux ACPI , LKML , dri-devel Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP So we got a bug filed in Fedora 23 that the nvidia GPU wasn't stalling on resume from runtime poweroff. When we looked into it, we noticed the GPU wasn't powering off and the delay was from things going to hell after that. I dug out the DSDT and noticed it has special Windows 10 handling code for the SB.PCI0.PEG.VID device. Adding acpi_osi="!Windows 2013" made things work again and everyone rejoiced and had battery life again. Now what to do about this? I doubt this is restricted to the W541 laptop, I assume all Optimus laptops that support windows 10 will have this problem, so I'm not sure blacklisting on a case by case basis is going to help. More information from investigation: On Win7/8 paths, the way to poweroff the GPU is to call an ACPI _DSM on the VID device that sets a magic bit, then the next time you go into D3 the _PS3 method gets called and powers the device down. This is to make up for the lack of D3cold in Windows at the time I suspect. Now with Win10, the PCI0.PEG device has power resource methods, specifically PR3 which enables D3cold. However nouveau is bound to the VID device not the PEG device, so never attempts to power it down using those methods. I've hacked up the attached patch, and it does indeed power the device down, but I've no idea how this is meant to work in real world. Dave. From 753bbb202b8e464cb425372266042cc7d60d3513 Mon Sep 17 00:00:00 2001 From: Dave Airlie Date: Wed, 17 Feb 2016 23:21:13 +1000 Subject: [PATCH] nouveau: hack the parent power down so the GPU powers down. --- drivers/acpi/device_pm.c | 3 +++ drivers/gpu/drm/nouveau/nouveau_drm.c | 16 ++++++++++++++++ 2 files changed, 19 insertions(+) diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index cd2c3d6..8696889 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -117,6 +117,9 @@ int acpi_device_get_power(struct acpi_device *device, int *state) && result == ACPI_STATE_D0) device->parent->power.state = ACPI_STATE_D0; + if (result == ACPI_STATE_UNKNOWN) + result = device->parent ? + device->parent->power.state : ACPI_STATE_D0; *state = result; out: diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 2f2f252..d9b2bd6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -715,6 +715,14 @@ nouveau_pmops_runtime_suspend(struct device *dev) pci_disable_device(pdev); pci_ignore_hotplug(pdev); pci_set_power_state(pdev, PCI_D3cold); + { + struct acpi_device *adev; + int r; + + r = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev); + if (!r) + acpi_device_set_power(adev->parent, ACPI_STATE_D3_COLD); + } drm_dev->switch_power_state = DRM_SWITCH_POWER_DYNAMIC_OFF; return ret; } @@ -730,6 +738,14 @@ nouveau_pmops_runtime_resume(struct device *dev) if (nouveau_runtime_pm == 0) return -EINVAL; + { + struct acpi_device *adev; + int r; + + r = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev); + if (!r) + acpi_device_set_power(adev->parent, ACPI_STATE_D0); + } pci_set_power_state(pdev, PCI_D0); pci_restore_state(pdev); ret = pci_enable_device(pdev); -- 2.5.0