From patchwork Sun Sep 23 13:58:10 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 10611729 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 91779913 for ; Sun, 23 Sep 2018 13:58:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7FEFA29F08 for ; Sun, 23 Sep 2018 13:58:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 73F9E29F20; Sun, 23 Sep 2018 13:58:29 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI 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 2079F29F08 for ; Sun, 23 Sep 2018 13:58:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726266AbeIWT4C (ORCPT ); Sun, 23 Sep 2018 15:56:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49980 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726168AbeIWT4C (ORCPT ); Sun, 23 Sep 2018 15:56:02 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 59699308FF22; Sun, 23 Sep 2018 13:58:28 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4363817F3E; Sun, 23 Sep 2018 13:58:26 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown , Andy Shevchenko , Mika Westerberg , Jarkko Nikula , Wolfram Sang Cc: Hans de Goede , Adrian Hunter , linux@endlessm.com, linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org Subject: [PATCH v2 5/7] ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller Date: Sun, 23 Sep 2018 15:58:10 +0200 Message-Id: <20180923135812.29574-6-hdegoede@redhat.com> In-Reply-To: <20180923135812.29574-1-hdegoede@redhat.com> References: <20180923135812.29574-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Sun, 23 Sep 2018 13:58:28 +0000 (UTC) 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 some Bay Trail systems the GPU ACPI fwnode has power-resources which point to the PMIC, which is connected over the LPSS I2C5 controller. This one was quite nasty to debug, unlike on CHT where the same problem leads to errors like these: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 On BYT the read-modify-write done by drivers/acpi/pmic/intel_pmic_xpower.c on the AXP288 PMIC register to change the power-resource state *seems* to succeed. But in reality, because the I2C controller has not been resumed yet, the read silently fails and returns the wrong value, where as the write does succeed, writing back the wrong value for all the other power-resources in the same register, turning off a bunch of them. Which of course does not end well. This commit adds a RPM consumer link from the GPU (which has a LNXVIDEO HID) to the BYT LPSS I2C5 controller, so that the I2C controller gets resumed before the GPU is resumed and thus before we try to change the power-resource. Signed-off-by: Hans de Goede Tested-by: Jarkko Nikula --- Note I'm also submitting an independent patch to the i2c-designware driver to catch the case of i2c transfers being done before the drivers resume() method has completed, to make debugging future similar problems easier. --- drivers/acpi/acpi_lpss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index fe37fd67331d..75672004db87 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -473,6 +473,7 @@ struct lpss_device_links { static const struct lpss_device_links lpss_device_links[] = { {"808622C1", "7", "80860F14", "3", DL_FLAG_PM_RUNTIME}, {"808622C1", "7", "LNXVIDEO", NULL, DL_FLAG_PM_RUNTIME}, + {"80860F41", "5", "LNXVIDEO", NULL, DL_FLAG_PM_RUNTIME}, }; static bool hid_uid_match(struct acpi_device *adev,