From patchwork Fri Oct 28 12:30:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Wu X-Patchwork-Id: 9401873 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2305D6022E for ; Fri, 28 Oct 2016 12:31:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EEC092A7BB for ; Fri, 28 Oct 2016 12:31:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CFDD82A7ED; Fri, 28 Oct 2016 12:31:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_TVD_MIME_EPI, UPPERCASE_50_75 autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B28D42A7BB for ; Fri, 28 Oct 2016 12:31:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755731AbcJ1MbT (ORCPT ); Fri, 28 Oct 2016 08:31:19 -0400 Received: from lekensteyn.nl ([178.21.112.251]:54339 "EHLO lekensteyn.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753763AbcJ1MbP (ORCPT ); Fri, 28 Oct 2016 08:31:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=mZOqaMEsT7lr7gzJp+E2D/gJ+y8hg/t+V1aWagveZFU=; b=H0o05Ia1QCt15jeYR7B9zT2gUDq4AXHNJd8Q0eLy5YevVJ49ygW6J8kap9ebv3BtYdm286AvfTUvc4tpyC4U44duPaaAvLsPNCgzAR17HBNcJQvseoaHu+hQO+7ReEfkHY7lWlEvz7wHa5X8cs7MQwr+JkmFIIKRyGX0/9p1RnLOT4i52PCMMVzXd9/ILrku1EBkdgX4k/L2LsbvWxCpQyuQoqtLTuhIWAPA/RgXI70Vh6FfyZ8mNINl9bN3PLrZdd+/LAuxeVe0WRvTL9Waa+lonayX4ZD0sxCRESNYKExpmj/GblXfippwdMW5ZJrXnWX18oeKIy0oHY95giC90A==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c06J1-0001r8-V7; Fri, 28 Oct 2016 14:31:01 +0200 Date: Fri, 28 Oct 2016 14:30:41 +0200 From: Peter Wu To: Mika Westerberg Cc: Rick Kerkhof , linux-acpi@vger.kernel.org, nouveau@lists.freedesktop.org, linux-pci@vger.kernel.org, Robert Moore , Lv Zheng Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources Message-ID: <20161028123041.GB1521@al> References: <20161027081748.GX1476@lahna.fi.intel.com> <20161027090604.GB27017@al> <20161027093011.GZ1476@lahna.fi.intel.com> <20161027095508.GA1476@lahna.fi.intel.com> <20161027160648.GF27017@al> <20161028085630.GD1476@lahna.fi.intel.com> <20161028110930.GA1521@al> <20161028111907.GD23812@lahna.fi.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161028111907.GD23812@lahna.fi.intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Oct 28, 2016 at 02:19:07PM +0300, Mika Westerberg wrote: > On Fri, Oct 28, 2016 at 01:09:30PM +0200, Peter Wu wrote: > > On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote: > > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > > > > > No, there are not. Here is the recursive directory listing: > > > > > > > > > > Are you able to try the following patch and send me dmesg (or attach it > > > > > to that bug)? It should show if the ACPI core even tries to add those > > > > > power resources. > > > > > > > > So Rick has tested this patch now on top of 4.8.4 (mainline fails to > > > > boot due to a kbuild issue which I reported elsewhere), but the output > > > > is empty. That seems to indicate that flags.power_resources is unset. > > > > > > Is it completely empty or is it empty just for RP05? It should print out > > > all devices with power resources. > > > > \NVP2 and \NVP3 are the only power resources under RP05 and defined in > > SSDT1, there are no others. > > We should probably add a debug print before checking > flags.power_resources just to be sure the patch is correctly applied. It was correctly applied. I did some testing with QEMU, it seems that the \_OSI check is problematic. Removing it makes things work again. To reproduce: 1. Build the kernel with the attached config (minconfig with ACPI and printk stuff enabled) and debug patch. 2. Compile the attached ASL file to AML (iasl ssdt1.dsl). (You can remove the If(\_OSI(...)) check to see the difference. 3. Boot QEMU and watch the dmesg for the debug prints. Alternatively, just boot QEMU with this SSDT and check against any Linux distro and inspect /sys/bus/pci/devices/0000:00:01.3/firmware_node/. Tested with Linux v4.8.5, QEMU 2.7.0, iasl 20160831. The SSDT structure is adapted from Ricks SSDT1 file and modified for the 00:01.3 device in QEMU. The QEMU command I used was: qemu-system-x86_64 -m 1G -M pc,accel=kvm -nographic \ -kernel arch/x86/boot/bzImage -serial file:/dev/stdout \ -acpitable file=ssdt1.aml \ -append 'console=ttyS0 acpi.aml_debug_output=1' diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index fcd4ce6..64d6308 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -143,20 +143,26 @@ int acpi_extract_power_resources(union acpi_object *package, unsigned int start, if (element->type != ACPI_TYPE_LOCAL_REFERENCE) { err = -ENODATA; + pr_warn("ACPI: Unsupported element type: %d\n", element->type); break; } rhandle = element->reference.handle; if (!rhandle) { err = -ENODEV; + pr_warn("ACPI: referenced handle not found!\n"); break; } err = acpi_add_power_resource(rhandle); - if (err) + if (err) { + acpi_handle_warn(rhandle, "acpi_add_power_resource failed!\n"); break; + } err = acpi_power_resources_list_add(rhandle, list); - if (err) + if (err) { + acpi_handle_warn(rhandle, "acpi_power_resources_list_add failed!\n"); break; + } } if (err) acpi_power_resources_list_free(list); @@ -441,6 +447,9 @@ void acpi_power_add_remove_device(struct acpi_device *adev, bool add) acpi_power_expose_hide(adev, &adev->wakeup.resources, &wakeup_attr_group, add); + acpi_handle_info(adev->handle, "Adding power resources for %s? %d\n", + dev_name(&adev->dev), adev->power.flags.power_resources); + if (!adev->power.flags.power_resources) return; diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index e878fc7..d71673d 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -930,6 +930,9 @@ static void acpi_bus_init_power_state(struct acpi_device *device, int state) && package->package.count) { int err = acpi_extract_power_resources(package, 0, &ps->resources); + acpi_handle_info(device->handle, + "acpi_extract_power_resources result for %s: %d\n", + dev_name(&device->dev), err); if (!err) device->power.flags.power_resources = 1; }