[{"id":1759217,"web_url":"http://patchwork.ozlabs.org/comment/1759217/","msgid":"<20170829102927.5lpjkfj2jbtpxadm@sig21.net>","list_archive_url":null,"date":"2017-08-29T10:29:27","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":3132,"url":"http://patchwork.ozlabs.org/api/people/3132/","name":"Johannes Stezenbach","email":"js@sig21.net"},"content":"Hi,\n\nOn Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote:\n> On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote:\n> > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c,\n> > isn't well optimized for system sleep.\n> > \n> > What makes this driver particularly interesting is because it's a cross-SoC\n> > driver, which sometimes means there is an ACPI PM domain attached to the i2c\n> > device and sometimes not. The driver is being used on both x86 and ARM.\n...\n> Basically, the point is to allow i2c-designware-platdrv to point its late\n> suspend and early resume callbacks, respectively, to pm_runtime_force_suspend()\n> and pm_runtime_force_resume() which then will do the right thing regardless of\n> whether or not the device is runtime suspended when system suspend starts.\n\nI'd like to point out a comment added by Hans de Goede in\nhttps://bugzilla.kernel.org/show_bug.cgi?id=193891#c99\n\n  The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is\n  attached to I2C7, these methods get executed by acpi_dev_suspend_late /\n  acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend /\n  resume callbacks it is already suspended at the time those calls happen,\n  leading to a device-suspend error and the system not suspending at all.\n\nIt's the reason for the Cherrytrail I2C7 special treatment in\ni2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c,\nhowever pm_disabled seems to be a problem for S0ix support.\nTo solve it, i2c-designware-platdrv needs to suspend after all\ndevices using ACPI OpRegions for suspend.\n\n\nJohannes","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhQfl5nFDz9s7c\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 29 Aug 2017 21:01:03 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752421AbdH2LBC (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 07:01:02 -0400","from mail.sig21.net ([80.244.240.74]:46179 \"EHLO mail.sig21.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752411AbdH2LBB (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 07:01:01 -0400","from p5ddc6bc0.dip0.t-ipconnect.de ([93.220.107.192]\n\thelo=abc.local) by mail.sig21.net with esmtpsa\n\t(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2)\n\t(envelope-from <js@sig21.net>)\n\tid 1dmdm0-0001SW-To; Tue, 29 Aug 2017 12:29:33 +0200","from js by abc.local with local (Exim 4.89)\n\t(envelope-from <js@sig21.net>)\n\tid 1dmdlv-0004Xa-FC; Tue, 29 Aug 2017 12:29:27 +0200"],"X-Greylist":"delayed 1840 seconds by postgrey-1.27 at vger.kernel.org;\n\tTue, 29 Aug 2017 07:01:01 EDT","Date":"Tue, 29 Aug 2017 12:29:27 +0200","From":"Johannes Stezenbach <js@sig21.net>","To":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>","Cc":"Ulf Hansson <ulf.hansson@linaro.org>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tlinux-acpi@vger.kernel.org, linux-pm@vger.kernel.org,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\tlinux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","Message-ID":"<20170829102927.5lpjkfj2jbtpxadm@sig21.net>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<4245176.X6JjkhnUAM@aspire.rjw.lan>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<4245176.X6JjkhnUAM@aspire.rjw.lan>","User-Agent":"NeoMutt/20170609 (1.8.3)","X-Spam-21-Score":"-2.9 (--)","X-Spam-21-Report":"No, score=-2.9 required=8.0 tests=ALL_TRUSTED=-1,\n\tBAYES_00=-1.9,\n\tKHOP_BIG_TO_CC=0.001 autolearn=ham autolearn_force=no","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759252,"web_url":"http://patchwork.ozlabs.org/comment/1759252/","msgid":"<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>","list_archive_url":null,"date":"2017-08-29T11:44:11","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":21036,"url":"http://patchwork.ozlabs.org/api/people/21036/","name":"Ulf Hansson","email":"ulf.hansson@linaro.org"},"content":"On 29 August 2017 at 12:29, Johannes Stezenbach <js@sig21.net> wrote:\n> Hi,\n>\n> On Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote:\n>> On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote:\n>> > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c,\n>> > isn't well optimized for system sleep.\n>> >\n>> > What makes this driver particularly interesting is because it's a cross-SoC\n>> > driver, which sometimes means there is an ACPI PM domain attached to the i2c\n>> > device and sometimes not. The driver is being used on both x86 and ARM.\n> ...\n>> Basically, the point is to allow i2c-designware-platdrv to point its late\n>> suspend and early resume callbacks, respectively, to pm_runtime_force_suspend()\n>> and pm_runtime_force_resume() which then will do the right thing regardless of\n>> whether or not the device is runtime suspended when system suspend starts.\n>\n> I'd like to point out a comment added by Hans de Goede in\n> https://bugzilla.kernel.org/show_bug.cgi?id=193891#c99\n>\n>   The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is\n>   attached to I2C7, these methods get executed by acpi_dev_suspend_late /\n>   acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend /\n>   resume callbacks it is already suspended at the time those calls happen,\n>   leading to a device-suspend error and the system not suspending at all.\n\nYes, that's why I moved those operation to be managed at the\n->suspend_late() in my series, and at the same time prevent the\ndirect_complete patch from executed for this device.\n\n>\n> It's the reason for the Cherrytrail I2C7 special treatment in\n> i2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c,\n> however pm_disabled seems to be a problem for S0ix support.\n> To solve it, i2c-designware-platdrv needs to suspend after all\n> devices using ACPI OpRegions for suspend.\n>\n>\n> Johannes\n\nDid you try out my series (v2) if that could fix this problem in a\nmore flexible manner?\n\nIn other words, is it fine if the device remains runtime PM enabled\nduring the entire device_suspend() phase, and also not being suspended\nuntil ->suspend_late()?\n\nKind regards\nUffe","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"S11JgchO\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhRcf5433z9s65\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 29 Aug 2017 21:44:15 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753431AbdH2LoN (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 07:44:13 -0400","from mail-io0-f171.google.com ([209.85.223.171]:33965 \"EHLO\n\tmail-io0-f171.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753110AbdH2LoM (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 07:44:12 -0400","by mail-io0-f171.google.com with SMTP id n71so17690209iod.1\n\tfor <linux-i2c@vger.kernel.org>; Tue, 29 Aug 2017 04:44:12 -0700 (PDT)","by 10.2.96.38 with HTTP; Tue, 29 Aug 2017 04:44:11 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=oIC7fTJ38ycqRagyCwWk7j8vpgKkgtG22F6uabiL6qY=;\n\tb=S11JgchOn9z9+hJUM+GMs6uJvl14uIsfYA3pPkZAYjBpcuiojIvga7DqByVLbTXlDl\n\tlSMtQFCFeztUUD36/7jXPQTihp46H1GaYPkcK5LcTjb1uNfhjHSHqUOv7iQ9Eaht0Dpd\n\t99md8F2nrqp9WQr+dNediNLLF+5fuvIorghn0=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=oIC7fTJ38ycqRagyCwWk7j8vpgKkgtG22F6uabiL6qY=;\n\tb=X90HlgPbOW9mLddar4SdkYPegpXzUn2fPSNbcWAqnO6I8l6bj/1f3hgKiQVtEeRw7+\n\tfGApaCFH6CG5RnubDW+kJ0Zy/j34H25V/S5He1LbI0IO8IqnM+jDs9XUDXPY4mbNDbUG\n\tSUJQuSr5qL03Pm+jdG4gxx7kuVsnTUajhnqIbfm0VNYXU24IM/t8dqTIbPuNqJWSiHRL\n\t+zsnUezeY6OJ31TeQcjsCmKkHRXEbMl/kB8+IXautzUbP+mZJ12Vx2OazTvTO96niYN3\n\tZiA24d1b7OaO5zD0K+JlchGboNG1TVfQgWMWwL7l9Qz7jReSHzSHNs/UdCrMf23mYUrn\n\t1MTA==","X-Gm-Message-State":"AHYfb5guJbbmEd/4HagQB60QsftHf2M+uiYwp1usznHclAFXN7JWQLDL\n\tc65yU0iEos9yLDuZ3mhi5YsRCn2rnB1o","X-Received":"by 10.36.253.194 with SMTP id m185mr3739927ith.136.1504007051797;\n\tTue, 29 Aug 2017 04:44:11 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170829102927.5lpjkfj2jbtpxadm@sig21.net>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<4245176.X6JjkhnUAM@aspire.rjw.lan>\n\t<20170829102927.5lpjkfj2jbtpxadm@sig21.net>","From":"Ulf Hansson <ulf.hansson@linaro.org>","Date":"Tue, 29 Aug 2017 13:44:11 +0200","Message-ID":"<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","To":"Johannes Stezenbach <js@sig21.net>","Cc":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tACPI Devel Maling List <linux-acpi@vger.kernel.org>,\n\t\"linux-pm@vger.kernel.org\" <linux-pm@vger.kernel.org>,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-i2c@vger.kernel.org\" <linux-i2c@vger.kernel.org>,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759358,"web_url":"http://patchwork.ozlabs.org/comment/1759358/","msgid":"<20170829135341.moanebdmbdz3ajjm@sig21.net>","list_archive_url":null,"date":"2017-08-29T13:53:41","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":3132,"url":"http://patchwork.ozlabs.org/api/people/3132/","name":"Johannes Stezenbach","email":"js@sig21.net"},"content":"On Tue, Aug 29, 2017 at 01:44:11PM +0200, Ulf Hansson wrote:\n> Did you try out my series (v2) if that could fix this problem in a\n> more flexible manner?\n> \n> In other words, is it fine if the device remains runtime PM enabled\n> during the entire device_suspend() phase, and also not being suspended\n> until ->suspend_late()?\n\nI tried to try but I also had some test patches applied\nand it hung up on suspend but I ran out of time to check why...\nI intend to try again soon.\n\nJohannes","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhVW32V34z9t2Q\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 29 Aug 2017 23:54:39 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751775AbdH2Nyh (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 09:54:37 -0400","from mail.sig21.net ([80.244.240.74]:55908 \"EHLO mail.sig21.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751180AbdH2Nyg (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 09:54:36 -0400","from p5780437e.dip0.t-ipconnect.de ([87.128.67.126] helo=zzz.local)\n\tby mail.sig21.net with esmtpsa\n\t(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2)\n\t(envelope-from <js@sig21.net>)\n\tid 1dmgxf-00027I-AR; Tue, 29 Aug 2017 15:53:52 +0200","from js by zzz.local with local (Exim 4.89)\n\t(envelope-from <js@sig21.net>)\n\tid 1dmgxZ-0002GQ-QE; Tue, 29 Aug 2017 15:53:41 +0200"],"Date":"Tue, 29 Aug 2017 15:53:41 +0200","From":"Johannes Stezenbach <js@sig21.net>","To":"Ulf Hansson <ulf.hansson@linaro.org>","Cc":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tACPI Devel Maling List <linux-acpi@vger.kernel.org>,\n\t\"linux-pm@vger.kernel.org\" <linux-pm@vger.kernel.org>,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-i2c@vger.kernel.org\" <linux-i2c@vger.kernel.org>,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","Message-ID":"<20170829135341.moanebdmbdz3ajjm@sig21.net>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<4245176.X6JjkhnUAM@aspire.rjw.lan>\n\t<20170829102927.5lpjkfj2jbtpxadm@sig21.net>\n\t<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","X-Spam-21-Score":"-2.9 (--)","X-Spam-21-Report":"No, score=-2.9 required=8.0 tests=ALL_TRUSTED=-1,\n\tBAYES_00=-1.9,\n\tKHOP_BIG_TO_CC=0.001 autolearn=ham autolearn_force=no","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759411,"web_url":"http://patchwork.ozlabs.org/comment/1759411/","msgid":"<1512684.bFXWtdU0Ox@aspire.rjw.lan>","list_archive_url":null,"date":"2017-08-29T14:43:15","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":26536,"url":"http://patchwork.ozlabs.org/api/people/26536/","name":"Rafael J. Wysocki","email":"rjw@rjwysocki.net"},"content":"On Tuesday, August 29, 2017 1:44:11 PM CEST Ulf Hansson wrote:\n> On 29 August 2017 at 12:29, Johannes Stezenbach <js@sig21.net> wrote:\n> > Hi,\n> >\n> > On Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote:\n> >> On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote:\n> >> > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c,\n> >> > isn't well optimized for system sleep.\n> >> >\n> >> > What makes this driver particularly interesting is because it's a cross-SoC\n> >> > driver, which sometimes means there is an ACPI PM domain attached to the i2c\n> >> > device and sometimes not. The driver is being used on both x86 and ARM.\n> > ...\n> >> Basically, the point is to allow i2c-designware-platdrv to point its late\n> >> suspend and early resume callbacks, respectively, to pm_runtime_force_suspend()\n> >> and pm_runtime_force_resume() which then will do the right thing regardless of\n> >> whether or not the device is runtime suspended when system suspend starts.\n> >\n> > I'd like to point out a comment added by Hans de Goede in\n> > https://bugzilla.kernel.org/show_bug.cgi?id=193891#c99\n> >\n> >   The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is\n> >   attached to I2C7, these methods get executed by acpi_dev_suspend_late /\n> >   acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend /\n> >   resume callbacks it is already suspended at the time those calls happen,\n> >   leading to a device-suspend error and the system not suspending at all.\n> \n> Yes, that's why I moved those operation to be managed at the\n> ->suspend_late() in my series, and at the same time prevent the\n> direct_complete patch from executed for this device.\n> \n> >\n> > It's the reason for the Cherrytrail I2C7 special treatment in\n> > i2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c,\n> > however pm_disabled seems to be a problem for S0ix support.\n> > To solve it, i2c-designware-platdrv needs to suspend after all\n> > devices using ACPI OpRegions for suspend.\n> >\n> >\n> > Johannes\n> \n> Did you try out my series (v2) if that could fix this problem in a\n> more flexible manner?\n> \n> In other words, is it fine if the device remains runtime PM enabled\n> during the entire device_suspend() phase, and also not being suspended\n> until ->suspend_late()?\n\nUlf, please, this is a *different* problem.\n\nCan we focus on one problem at a time?\n\nThanks,\nRafael","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhWnD29vBz9t38\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 00:52:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753850AbdH2Ov6 (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 10:51:58 -0400","from cloudserver094114.home.net.pl ([79.96.170.134]:59375 \"EHLO\n\tcloudserver094114.home.net.pl\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751928AbdH2Ov5 (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 10:51:57 -0400","from 79.184.253.199.ipv4.supernova.orange.pl (79.184.253.199)\n\t(HELO aspire.rjw.lan)\n\tby serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer\n\t0.82) id e453f414fa463015; Tue, 29 Aug 2017 16:51:54 +0200"],"From":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>","To":"Ulf Hansson <ulf.hansson@linaro.org>","Cc":"Johannes Stezenbach <js@sig21.net>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tACPI Devel Maling List <linux-acpi@vger.kernel.org>,\n\t\"linux-pm@vger.kernel.org\" <linux-pm@vger.kernel.org>,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-i2c@vger.kernel.org\" <linux-i2c@vger.kernel.org>,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","Date":"Tue, 29 Aug 2017 16:43:15 +0200","Message-ID":"<1512684.bFXWtdU0Ox@aspire.rjw.lan>","In-Reply-To":"<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<20170829102927.5lpjkfj2jbtpxadm@sig21.net>\n\t<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759418,"web_url":"http://patchwork.ozlabs.org/comment/1759418/","msgid":"<2534922.secN4LtMtD@aspire.rjw.lan>","list_archive_url":null,"date":"2017-08-29T14:49:12","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":26536,"url":"http://patchwork.ozlabs.org/api/people/26536/","name":"Rafael J. Wysocki","email":"rjw@rjwysocki.net"},"content":"On Tuesday, August 29, 2017 12:29:27 PM CEST Johannes Stezenbach wrote:\n> Hi,\n> \n> On Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote:\n> > On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote:\n> > > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c,\n> > > isn't well optimized for system sleep.\n> > > \n> > > What makes this driver particularly interesting is because it's a cross-SoC\n> > > driver, which sometimes means there is an ACPI PM domain attached to the i2c\n> > > device and sometimes not. The driver is being used on both x86 and ARM.\n> ...\n> > Basically, the point is to allow i2c-designware-platdrv to point its late\n> > suspend and early resume callbacks, respectively, to pm_runtime_force_suspend()\n> > and pm_runtime_force_resume() which then will do the right thing regardless of\n> > whether or not the device is runtime suspended when system suspend starts.\n> \n> I'd like to point out a comment added by Hans de Goede in\n> https://bugzilla.kernel.org/show_bug.cgi?id=193891#c99\n> \n>   The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is\n>   attached to I2C7, these methods get executed by acpi_dev_suspend_late /\n>   acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend /\n>   resume callbacks it is already suspended at the time those calls happen,\n>   leading to a device-suspend error and the system not suspending at all.\n> \n> It's the reason for the Cherrytrail I2C7 special treatment in\n> i2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c,\n> however pm_disabled seems to be a problem for S0ix support.\n> To solve it, i2c-designware-platdrv needs to suspend after all\n> devices using ACPI OpRegions for suspend.\n\nThat's a totally different issue from the one at hand.\n\nIt simply means that the devices using I2C for suspend/resume need to be\nsuspended *before* the I2C controller and resumed *after* it.\n\nSo this is a system suspend/resume *ordering* issue and not a runtime PM\nvs system suspend issue.\n\nIt can be addressed, for example, by doing the I2C controller's\nsuspend/resume at the noirq stage.  Has anyone tried that?\n\nThanks,\nRafael","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhWw34svRz9sR9\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 00:57:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754682AbdH2O5y (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 10:57:54 -0400","from cloudserver094114.home.net.pl ([79.96.170.134]:53964 \"EHLO\n\tcloudserver094114.home.net.pl\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1754662AbdH2O5x (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 10:57:53 -0400","from 79.184.253.199.ipv4.supernova.orange.pl (79.184.253.199)\n\t(HELO aspire.rjw.lan)\n\tby serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer\n\t0.82) id a6b7edd56b5e0b62; Tue, 29 Aug 2017 16:57:51 +0200"],"From":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>","To":"Johannes Stezenbach <js@sig21.net>","Cc":"Ulf Hansson <ulf.hansson@linaro.org>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tlinux-acpi@vger.kernel.org, linux-pm@vger.kernel.org,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\tlinux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","Date":"Tue, 29 Aug 2017 16:49:12 +0200","Message-ID":"<2534922.secN4LtMtD@aspire.rjw.lan>","In-Reply-To":"<20170829102927.5lpjkfj2jbtpxadm@sig21.net>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<4245176.X6JjkhnUAM@aspire.rjw.lan>\n\t<20170829102927.5lpjkfj2jbtpxadm@sig21.net>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759428,"web_url":"http://patchwork.ozlabs.org/comment/1759428/","msgid":"<CAPDyKFq-XDYE0xr2qONwO7_w8_jHfv5=iCwx4QdH7OHWqJ1e-Q@mail.gmail.com>","list_archive_url":null,"date":"2017-08-29T15:05:20","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":21036,"url":"http://patchwork.ozlabs.org/api/people/21036/","name":"Ulf Hansson","email":"ulf.hansson@linaro.org"},"content":"On 29 August 2017 at 16:43, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:\n> On Tuesday, August 29, 2017 1:44:11 PM CEST Ulf Hansson wrote:\n>> On 29 August 2017 at 12:29, Johannes Stezenbach <js@sig21.net> wrote:\n>> > Hi,\n>> >\n>> > On Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote:\n>> >> On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote:\n>> >> > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c,\n>> >> > isn't well optimized for system sleep.\n>> >> >\n>> >> > What makes this driver particularly interesting is because it's a cross-SoC\n>> >> > driver, which sometimes means there is an ACPI PM domain attached to the i2c\n>> >> > device and sometimes not. The driver is being used on both x86 and ARM.\n>> > ...\n>> >> Basically, the point is to allow i2c-designware-platdrv to point its late\n>> >> suspend and early resume callbacks, respectively, to pm_runtime_force_suspend()\n>> >> and pm_runtime_force_resume() which then will do the right thing regardless of\n>> >> whether or not the device is runtime suspended when system suspend starts.\n>> >\n>> > I'd like to point out a comment added by Hans de Goede in\n>> > https://bugzilla.kernel.org/show_bug.cgi?id=193891#c99\n>> >\n>> >   The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is\n>> >   attached to I2C7, these methods get executed by acpi_dev_suspend_late /\n>> >   acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend /\n>> >   resume callbacks it is already suspended at the time those calls happen,\n>> >   leading to a device-suspend error and the system not suspending at all.\n>>\n>> Yes, that's why I moved those operation to be managed at the\n>> ->suspend_late() in my series, and at the same time prevent the\n>> direct_complete patch from executed for this device.\n>>\n>> >\n>> > It's the reason for the Cherrytrail I2C7 special treatment in\n>> > i2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c,\n>> > however pm_disabled seems to be a problem for S0ix support.\n>> > To solve it, i2c-designware-platdrv needs to suspend after all\n>> > devices using ACPI OpRegions for suspend.\n>> >\n>> >\n>> > Johannes\n>>\n>> Did you try out my series (v2) if that could fix this problem in a\n>> more flexible manner?\n>>\n>> In other words, is it fine if the device remains runtime PM enabled\n>> during the entire device_suspend() phase, and also not being suspended\n>> until ->suspend_late()?\n>\n> Ulf, please, this is a *different* problem.\n\nYes, it is!\n\nJust wanted to point out that if the device remains runtime PM enabled\nthe entire device_suspend() phase, that *could* solve the problem.\n\n>\n> Can we focus on one problem at a time?\n\nYes!\n\nHowever, there is lots of things following when we try to enable the\nruntime PM centric path for ACPI. :-)\n\nKind regards\nUffe","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"KR22+S3N\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhX4k0mZ2z9sRV\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 01:05:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752534AbdH2PFY (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 11:05:24 -0400","from mail-io0-f174.google.com ([209.85.223.174]:37982 \"EHLO\n\tmail-io0-f174.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752525AbdH2PFW (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 11:05:22 -0400","by mail-io0-f174.google.com with SMTP id 81so21053894ioj.5\n\tfor <linux-i2c@vger.kernel.org>; Tue, 29 Aug 2017 08:05:22 -0700 (PDT)","by 10.2.96.38 with HTTP; Tue, 29 Aug 2017 08:05:20 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=QhMLjnwgZUargVDx79xNqGuGYv0zJ8WjCaI07vmr5eY=;\n\tb=KR22+S3Nwb0t7dFuZQYaVG1bdqd0S544pY+MymOTGxC4q2NGHe85sufsEbnEnonq8K\n\tDA1KH+ViEu9o2h/BWT12YMFdIFBvZzxhfm5urQ12zfiAr8pwIcZZ0sXAAWJcULbkwX8q\n\tEeMMXf4piwh3gmlpIikA+jtopUDG9iQXCQLnU=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=QhMLjnwgZUargVDx79xNqGuGYv0zJ8WjCaI07vmr5eY=;\n\tb=F9/qCJlsi5wspnD+w8yxtL+RTOtndNBGT+F8t40Ho6pualbBo6sIjjQNU+2+dF/H1R\n\tqSkFG7y+momXq3Rxe2SGTPP+u6yj/D9elScK5ZrRfhW0UMCnusKtBJnyPNjcQaW9Az8A\n\tEzELV20dyzDYZr4gqXc72kwHMtiqGccFHRhcZv+7zjOkvLrZfphZZxrZEBVE0ucyn8Cv\n\tJWLbaOH2tS4k/Cko43zHd+TY9FvYkAfA8sZB+9odKFEAIZuq2emT6FYFwGHpciLkZK85\n\tYIZZ88bS1qiNNCQe1KCa5HxELXL3pOgGzAiaIMb30DGNtU1sKu0Ox/W4U515vseHenWz\n\tN3rA==","X-Gm-Message-State":"AHYfb5hToHdegbG+deQWHPfQHdO8AjHvOur4Jqal3GUgScTjSj6eEo4m\n\t09XHaVZ/c6iN/gl9oRPtfis6HLoB0bwM","X-Received":"by 10.36.156.70 with SMTP id b67mr2407749ite.22.1504019121368;\n\tTue, 29 Aug 2017 08:05:21 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<1512684.bFXWtdU0Ox@aspire.rjw.lan>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<20170829102927.5lpjkfj2jbtpxadm@sig21.net>\n\t<CAPDyKFp5dpuUeRjmmSSA3sZzFVwJihmzteyCDzqG33s2Xb1ewA@mail.gmail.com>\n\t<1512684.bFXWtdU0Ox@aspire.rjw.lan>","From":"Ulf Hansson <ulf.hansson@linaro.org>","Date":"Tue, 29 Aug 2017 17:05:20 +0200","Message-ID":"<CAPDyKFq-XDYE0xr2qONwO7_w8_jHfv5=iCwx4QdH7OHWqJ1e-Q@mail.gmail.com>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","To":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>","Cc":"Johannes Stezenbach <js@sig21.net>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tACPI Devel Maling List <linux-acpi@vger.kernel.org>,\n\t\"linux-pm@vger.kernel.org\" <linux-pm@vger.kernel.org>,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-i2c@vger.kernel.org\" <linux-i2c@vger.kernel.org>,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759542,"web_url":"http://patchwork.ozlabs.org/comment/1759542/","msgid":"<5440066.jm2MzmQIeF@aspire.rjw.lan>","list_archive_url":null,"date":"2017-08-29T16:44:02","subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","submitter":{"id":26536,"url":"http://patchwork.ozlabs.org/api/people/26536/","name":"Rafael J. Wysocki","email":"rjw@rjwysocki.net"},"content":"On Tuesday, August 29, 2017 5:05:20 PM CEST Ulf Hansson wrote:\n> On 29 August 2017 at 16:43, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:\n> > On Tuesday, August 29, 2017 1:44:11 PM CEST Ulf Hansson wrote:\n> >> On 29 August 2017 at 12:29, Johannes Stezenbach <js@sig21.net> wrote:\n> >> > Hi,\n> >> >\n> >> > On Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote:\n> >> >> On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote:\n> >> >> > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c,\n> >> >> > isn't well optimized for system sleep.\n> >> >> >\n> >> >> > What makes this driver particularly interesting is because it's a cross-SoC\n> >> >> > driver, which sometimes means there is an ACPI PM domain attached to the i2c\n> >> >> > device and sometimes not. The driver is being used on both x86 and ARM.\n> >> > ...\n> >> >> Basically, the point is to allow i2c-designware-platdrv to point its late\n> >> >> suspend and early resume callbacks, respectively, to pm_runtime_force_suspend()\n> >> >> and pm_runtime_force_resume() which then will do the right thing regardless of\n> >> >> whether or not the device is runtime suspended when system suspend starts.\n> >> >\n> >> > I'd like to point out a comment added by Hans de Goede in\n> >> > https://bugzilla.kernel.org/show_bug.cgi?id=193891#c99\n> >> >\n> >> >   The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is\n> >> >   attached to I2C7, these methods get executed by acpi_dev_suspend_late /\n> >> >   acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend /\n> >> >   resume callbacks it is already suspended at the time those calls happen,\n> >> >   leading to a device-suspend error and the system not suspending at all.\n> >>\n> >> Yes, that's why I moved those operation to be managed at the\n> >> ->suspend_late() in my series, and at the same time prevent the\n> >> direct_complete patch from executed for this device.\n> >>\n> >> >\n> >> > It's the reason for the Cherrytrail I2C7 special treatment in\n> >> > i2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c,\n> >> > however pm_disabled seems to be a problem for S0ix support.\n> >> > To solve it, i2c-designware-platdrv needs to suspend after all\n> >> > devices using ACPI OpRegions for suspend.\n> >> >\n> >> >\n> >> > Johannes\n> >>\n> >> Did you try out my series (v2) if that could fix this problem in a\n> >> more flexible manner?\n> >>\n> >> In other words, is it fine if the device remains runtime PM enabled\n> >> during the entire device_suspend() phase, and also not being suspended\n> >> until ->suspend_late()?\n> >\n> > Ulf, please, this is a *different* problem.\n> \n> Yes, it is!\n> \n> Just wanted to point out that if the device remains runtime PM enabled\n> the entire device_suspend() phase, that *could* solve the problem.\n> \n> >\n> > Can we focus on one problem at a time?\n> \n> Yes!\n> \n> However, there is lots of things following when we try to enable the\n> runtime PM centric path for ACPI. :-)\n\nWhich, I guess, we won't do after all ...\n\nSo I would prefer to think about addressing problems instead of trying to\n\"enable the runtime PM centric path for ACPI\" just for the sake of it.\n\nThanks,\nRafael","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhZSZ3Dqpz9t38\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 02:52:46 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751324AbdH2Qwn (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 12:52:43 -0400","from cloudserver094114.home.net.pl ([79.96.170.134]:56677 \"EHLO\n\tcloudserver094114.home.net.pl\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751180AbdH2Qwn (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 12:52:43 -0400","from 79.184.253.199.ipv4.supernova.orange.pl (79.184.253.199)\n\t(HELO aspire.rjw.lan)\n\tby serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer\n\t0.82) id 5e2aae376714825a; Tue, 29 Aug 2017 18:52:41 +0200"],"From":"\"Rafael J. Wysocki\" <rjw@rjwysocki.net>","To":"Ulf Hansson <ulf.hansson@linaro.org>","Cc":"Johannes Stezenbach <js@sig21.net>,\n\tWolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,\n\tACPI Devel Maling List <linux-acpi@vger.kernel.org>,\n\t\"linux-pm@vger.kernel.org\" <linux-pm@vger.kernel.org>,\n\tKevin Hilman <khilman@kernel.org>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tMika Westerberg <mika.westerberg@linux.intel.com>,\n\tJisheng Zhang <jszhang@marvell.com>,\n\tJohn Stultz <john.stultz@linaro.org>, Guodong Xu <guodong.xu@linaro.org>,\n\tSumit Semwal <sumit.semwal@linaro.org>,\n\tHaojian Zhuang <haojian.zhuang@linaro.org>,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t<linux-arm-kernel@lists.infradead.org>,\n\t\"linux-i2c@vger.kernel.org\" <linux-i2c@vger.kernel.org>,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>","Subject":"Re: [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling","Date":"Tue, 29 Aug 2017 18:44:02 +0200","Message-ID":"<5440066.jm2MzmQIeF@aspire.rjw.lan>","In-Reply-To":"<CAPDyKFq-XDYE0xr2qONwO7_w8_jHfv5=iCwx4QdH7OHWqJ1e-Q@mail.gmail.com>","References":"<1503499329-28834-1-git-send-email-ulf.hansson@linaro.org>\n\t<1512684.bFXWtdU0Ox@aspire.rjw.lan>\n\t<CAPDyKFq-XDYE0xr2qONwO7_w8_jHfv5=iCwx4QdH7OHWqJ1e-Q@mail.gmail.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}}]