Cover Letter Detail
Show a cover letter.
GET /api/covers/807362/?format=api
{ "id": 807362, "url": "http://patchwork.ozlabs.org/api/covers/807362/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-i2c/cover/1551534.5XKjjnxbAy@aspire.rjw.lan/", "project": { "id": 35, "url": "http://patchwork.ozlabs.org/api/projects/35/?format=api", "name": "Linux I2C development", "link_name": "linux-i2c", "list_id": "linux-i2c.vger.kernel.org", "list_email": "linux-i2c@vger.kernel.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<1551534.5XKjjnxbAy@aspire.rjw.lan>", "list_archive_url": null, "date": "2017-08-30T00:00:27", "name": "[RFT,v2,0/3] PM / ACPI / i2c: Runtime PM aware system sleep handling", "submitter": { "id": 26536, "url": "http://patchwork.ozlabs.org/api/people/26536/?format=api", "name": "Rafael J. Wysocki", "email": "rjw@rjwysocki.net" }, "mbox": "http://patchwork.ozlabs.org/project/linux-i2c/cover/1551534.5XKjjnxbAy@aspire.rjw.lan/mbox/", "series": [ { "id": 507, "url": "http://patchwork.ozlabs.org/api/series/507/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-i2c/list/?series=507", "date": "2017-08-30T00:07:20", "name": "PM / ACPI / i2c: Runtime PM aware system sleep handling", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/507/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/807362/comments/", "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 3xhmRJ2ltMz9s81\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 10:22:20 +1000 (AEST)", "(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751440AbdH3AWQ (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 20:22:16 -0400", "from cloudserver094114.home.net.pl ([79.96.170.134]:64227 \"EHLO\n\tcloudserver094114.home.net.pl\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751297AbdH3AWO (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 20:22:14 -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 c2210ef4377c05d9; Wed, 30 Aug 2017 02:22:12 +0200" ], "From": "\"Rafael J. Wysocki\" <rjw@rjwysocki.net>", "To": "linux-pm@vger.kernel.org", "Cc": "Wolfram Sang <wsa@the-dreams.de>, linux-acpi@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\tJohannes Stezenbach <js@sig21.net>, linux-i2c@vger.kernel.org,\n\tUlf Hansson <ulf.hansson@linaro.org>,\n\tGreg Kroah-Hartman <gregkh@linuxfoundation.org>", "Subject": "[RFT][PATCH v2 0/3] PM / ACPI / i2c: Runtime PM aware system sleep\n\thandling", "Date": "Wed, 30 Aug 2017 02:00:27 +0200", "Message-ID": "<1551534.5XKjjnxbAy@aspire.rjw.lan>", "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" }, "content": "Hi,\n\nThe point here is to avoid runtime resuming i2c designware devices during\nsystem suspend in the generic ACPI PM domain and the ACPI LPSS driver if\nthat is not necessary. The ordering issue between i2c designware and\nother devices relying on it for their PM is not addressed here (but it can\nbe addressed on top of this to some extent).\n\nFor this to work, the ACPI PM domain and the LPSS driver (which also has to\nwork with i2c-designware-platdrv) have to track the status of the device in\norder to handle it correctly regardless of whether or not the device is\nruntime-suspended when system suspend starts.\n\nThe primary problem with that is that acpi_subsys_suspend() has to decide\nwhether or not to runtime resume the device and then\nacpi_subsys_suspend_late/resume_early() (and their counterparts in the ACPI\nLPSS driver) need to know whether or not to run acpi_dev_suspend_late/resume_early(), respectively.\n\nIn order to make that decision, acpi_subsys_suspend() needs to know (a) if\nthe power state of the device has to be updated (in which case the device\nshould be runtime resumed) and (b) if the driver's callbacks that will be\nrun subsequently can cope with a runtime suspended device. The former can\nbe figured out from the check done in acpi_subsys_prepare() (the result of it\nneeds to be saved), but the latter is only known to the driver, so it needs a\nway to tell the code above it about that. Hence, the SAFE_SUSPEND flag\nintroduced by the first patch.\n\nThe second patch simply reworks the ACPI PM domain and the ACPI LPSS driver\nto carry out all the checks etc as needed.\n\nThe third one finally updates i2c-designware-platdrv (details in the changelog).\n\nThe cases to consider are the following: i2c-designware-platdrv without ACPI\n(either the ACPI PM domain or the ACPI LPSS driver), i2c-designware-platdrv\nwith the generic ACPI PM domain (direct_complete set or unset) and\ni2c-designware-platdrv with the ACPI LPSS driver (direct_complete set or unset).\n\nFirst, for i2c-designware-platdrv without ACPI, the first two patches don't\nmatter and the third one moves the callbacks to a later phase of suspend\nand an earlier phase of resume and drops ->prepare and ->complete. The effect\nof dropping ->prepare is that it will not return 1 any more, so the core will\nnever set power.direct_complete for this device. The effect of the other\nchange is that system suspend will always call dw_i2c_plat_suspend() after\nall invocations of dw_i2c_plat_resume() by runtime resume and system resume\nwill always call the latter before any post-resume runtime PM operations.\nIf the device is not runtime-suspended before system suspend, dw_i2c_plat_suspend()\n(executed as the ->suspend_late callback) will see the \"suspended\" flag unset\nand it will suspend the device. Otherwise, it will see the \"suspended\" flag set\nand it will return early, but it will set \"suspend_skipped\". During system resume,\ndw_i2c_plat_resume() will always see \"suspended\" set (it won't see \"suspended\"\nset when invoked as the runtime resume callback), but if it sees \"suspend_skipped\"\nset (which can only be set during system suspend), it will return early (it\nneeds to clear \"suspend_skipped\" then in case it is invoked shortly as the\nruntime resume callback). Otherwise, it will resume the device.\n\nNext, consider i2c-designware-platdrv with the ACPI PM domain and say that the\ndevice is not runtime-suspended when system suspend is started. In that case\nthe core will not set power.direct_complete for the device and\nacpi_subsys_suspend() will run. It will see that the device is not runtime-\nsuspended, so it will only update power.update_state (the driver's ->suspend\ncallback could be run too, but it is not present). During late suspend,\nacpi_subsys_suspend_late() will be called. It will run the driver's\n->suspend_late callback (which will suspend the device, because it will see\n\"suspended\" unset) and because power.update_state is set,\nacpi_dev_suspend_late() will be called to change the power state and wakeup\nsettings of the device. During resume, acpi_subsys_resume_early() will\nsee power.update_state set, so it will call acpi_dev_resume_early() to power-up\nthe device and it will call the driver's ->resume_early (which will see\n\"suspend_skipped\" unset, so it will resume the device).\n\nIf the device is runtime-suspended when system suspend starts, there are a\nfew possibilities. If the device's power state doesn't need to be updated,\nthe PM domain's ->prepare will return 1 and the core may or may not set\npower.direct_complete for the device. If it is set, the callbacks will\nnot be invoked and the PM domain's ->complete will queue up runtime resume\nof the device to update its power state. If power.direct_complete is not set,\nacpi_subsys_suspend() will run again, but this time the device *is* runtime-\nsuspended. Then, as a rule, power.update_state will not be set and the\nfunction will return without doing anything (so far, so good). Next, (unless\nthe device is runtime resumed in the meantime) acpi_dev_suspend_late() will\ncall the driver's ->suspend_late (which will see \"suspended\" set, so it will\nreturn early) and then it will return early because of power.update_state\nunset. During resume, acpi_subsys_resume_early() will skip powering up\nthe device and will call the driver's ->resume_early (which will see\n\"suspend_skipped\" set and will return early), so still OK.\n\nIf the device is runtime-suspended when system suspend starts, but its power\nsettings need to be updated, the bus type's ->prepare will return 0 and\npower.direct_complete will not be set for the device, so acpi_subsys_suspend()\nwill run. However, this time it will see power.update_state set, so it will\nruntime resume the device. From this point on, this case is analogous to the\none when the device was not runtime-suspended to start with.\n\nThe \"i2c-designware-platdrv with the ACPI LPSS driver\" case should be analogous\nto the one with the generic ACPI PM domain if I haven't overlooked anything,\nso to my eyes it should work.\n\nPlease test if you can and let me know if anything breaks.\n\nThanks,\nRafael" }