From patchwork Sat Sep 8 18:29:59 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: 10593141 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 6C3A614E0 for ; Sat, 8 Sep 2018 18:30:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 585DB2A4E7 for ; Sat, 8 Sep 2018 18:30:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4CECE2A4E9; Sat, 8 Sep 2018 18:30:07 +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 E310C2A4E7 for ; Sat, 8 Sep 2018 18:30:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727607AbeIHXQp (ORCPT ); Sat, 8 Sep 2018 19:16:45 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48858 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726817AbeIHXQp (ORCPT ); Sat, 8 Sep 2018 19:16:45 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CEFFA80C3C31; Sat, 8 Sep 2018 18:30:04 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-57.ams2.redhat.com [10.36.116.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC0DC2027EA4; Sat, 8 Sep 2018 18:30:02 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown , Zhang Rui , Andy Shevchenko , Mika Westerberg , Jarkko Nikula , Wolfram Sang Cc: Hans de Goede , linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org Subject: [PATCH] i2c: designware: Resume PMICs shared with the PUNIT earlier Date: Sat, 8 Sep 2018 20:29:59 +0200 Message-Id: <20180908182959.5038-2-hdegoede@redhat.com> In-Reply-To: <20180908182959.5038-1-hdegoede@redhat.com> References: <20180908182959.5038-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Sat, 08 Sep 2018 18:30:04 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Sat, 08 Sep 2018 18:30:04 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hdegoede@redhat.com' RCPT:'' 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 After recent kernel changes Bay and Cherry Trail devices where the I2C bus to the PMIC is shared with PUNIT properly reach S0ix states when suspended. As explained in detail in the commit message of commit 9d9a152ebaa8 ("i2c: designware: Re-init controllers with pm_disabled set on resume"), the I2C controller for this bus has an effectively empty _PS3 ACPI method and thus is left in D0 during suspend. It seems to somehow automatically powerdown once S0i3 is reached, which means that it needs to be reinitialized on resume for us to be able to use it again. The referred commit adds the necessary code to re-init the controller to the drivers resume_early method. It turns out that for some devices this is too late. On a Peaq C1010 2-in-1 tablet/laptop doing the re-init from resume_early leads to the device rebooting on resume. This commit moves the re-init to resume_noirq, fixing this. Note this means that the controller re-init now happens before the early_resume handler from drivers/acpi/acpi_lpss.c runs. Which means that the controller was not put in D0 yet when we re-init, this is not a problem since the controller was never put in D3 in the first place. This has been tested on the Peaq C1010 and one other Bay Trail device and Cherry Trail device, both of which have an I2C bus shared with the PUNIT too. Fixes: 9d9a152ebaa8 ("i2c: designware: Re-init controllers with ...") Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg Acked-by: Jarkko Nikula --- drivers/i2c/busses/i2c-designware-platdrv.c | 22 ++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c index e92fdb46b5a0..3f96d048ce2d 100644 --- a/drivers/i2c/busses/i2c-designware-platdrv.c +++ b/drivers/i2c/busses/i2c-designware-platdrv.c @@ -429,8 +429,27 @@ static int dw_i2c_plat_resume(struct device *dev) { struct dw_i2c_dev *i_dev = dev_get_drvdata(dev); + if (i_dev->shared_with_punit) + return 0; + + i2c_dw_prepare_clk(i_dev, true); + i_dev->init(i_dev); + + return 0; +} + +/* + * This is only for (Intel BYT/CHT) devices where the I2C bus to the PMIC + * is shared with the SoC's PUNIT. On these devices the controller is never + * turned off by us, but is automatically powered down in hardware. So we + * need to re-init it and we need to do this as early as possible. + */ +static int dw_i2c_plat_resume_noirq(struct device *dev) +{ + struct dw_i2c_dev *i_dev = dev_get_drvdata(dev); + if (!i_dev->shared_with_punit) - i2c_dw_prepare_clk(i_dev, true); + return 0; i_dev->init(i_dev); @@ -440,6 +459,7 @@ static int dw_i2c_plat_resume(struct device *dev) static const struct dev_pm_ops dw_i2c_dev_pm_ops = { .prepare = dw_i2c_plat_prepare, .complete = dw_i2c_plat_complete, + .resume_noirq = dw_i2c_plat_resume_noirq, SET_LATE_SYSTEM_SLEEP_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume) SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL) };