From: Tony Lindgren <tony@atomide.com> To: Ulf Hansson <ulf.hansson@linaro.org> Cc: Alan Stern <stern@rowland.harvard.edu>, "Rafael J. Wysocki" <rafael@kernel.org>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Kevin Hilman <khilman@baylibre.com>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, Linux OMAP Mailing List <linux-omap@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Date: Tue, 2 Feb 2016 08:35:36 -0800 [thread overview] Message-ID: <20160202163536.GU19432@atomide.com> (raw) In-Reply-To: <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com> Hi, * Ulf Hansson <ulf.hansson@linaro.org> [160202 02:43]: > > For the omap_hsmmc and likely also other omap drivers, which needs more > than one attempt to ->probe() (returning -EPROBE_DEFER), this commit > causes a regression at the PM domain level (omap hwmod). > > The reason is that the drivers don't put back the device into low power > state while bailing out in ->probe to return -EPROBE_DEFER. This leads to > that pm_runtime_reinit() in driver core, is re-initializing the runtime PM > status from RPM_ACTIVE to RPM_SUSPENDED. Yup, that's the bug here. It seems that we never call the runtime_suspend callback at the end of a first failed device driver probe if the driver has set pm_runtime_use_autosuspend. Only rpm_idle runtime_idle callback gets called. So the device stays on. This does not happen if pm_runtime_dont_use_autosuspend() is added to the end of the device driver probe before pm_runtime_put_sync(). > The next ->probe() attempt then triggers the ->runtime_resume() callback > to be invoked, which means this happens two times in a row. At the PM > domain level (omap hwmod) this is being treated as an error and thus the > runtime PM status of the device isn't correctly synchronized with the > runtime PM core. That's a valid error though, let's not remove it. The reason why we call runtime_resume() twice is because runtime_suspend callback never gets called like I explain above. > In the end, ->probe() anyway succeeds (as the driver don't checks the > error code from the runtime PM APIs), but results in that the PM domain > always stays powered on. This because of the runtime PM core believes the > device is RPM_SUSPENDED. FYI, the following allows runtime_suspend callback to get called at the end of a failed driver probe so the hardware state matches the PM runtime state. Need to debug more. Regards, Tony 8< ------------ --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2232,6 +2232,7 @@ err_irq: dma_release_channel(host->tx_chan); if (host->rx_chan) dma_release_channel(host->rx_chan); + pm_runtime_dont_use_autosuspend(host->dev); pm_runtime_put_sync(host->dev); pm_runtime_disable(host->dev); if (host->dbclk)
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Date: Tue, 2 Feb 2016 08:35:36 -0800 [thread overview] Message-ID: <20160202163536.GU19432@atomide.com> (raw) In-Reply-To: <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com> Hi, * Ulf Hansson <ulf.hansson@linaro.org> [160202 02:43]: > > For the omap_hsmmc and likely also other omap drivers, which needs more > than one attempt to ->probe() (returning -EPROBE_DEFER), this commit > causes a regression at the PM domain level (omap hwmod). > > The reason is that the drivers don't put back the device into low power > state while bailing out in ->probe to return -EPROBE_DEFER. This leads to > that pm_runtime_reinit() in driver core, is re-initializing the runtime PM > status from RPM_ACTIVE to RPM_SUSPENDED. Yup, that's the bug here. It seems that we never call the runtime_suspend callback at the end of a first failed device driver probe if the driver has set pm_runtime_use_autosuspend. Only rpm_idle runtime_idle callback gets called. So the device stays on. This does not happen if pm_runtime_dont_use_autosuspend() is added to the end of the device driver probe before pm_runtime_put_sync(). > The next ->probe() attempt then triggers the ->runtime_resume() callback > to be invoked, which means this happens two times in a row. At the PM > domain level (omap hwmod) this is being treated as an error and thus the > runtime PM status of the device isn't correctly synchronized with the > runtime PM core. That's a valid error though, let's not remove it. The reason why we call runtime_resume() twice is because runtime_suspend callback never gets called like I explain above. > In the end, ->probe() anyway succeeds (as the driver don't checks the > error code from the runtime PM APIs), but results in that the PM domain > always stays powered on. This because of the runtime PM core believes the > device is RPM_SUSPENDED. FYI, the following allows runtime_suspend callback to get called at the end of a failed driver probe so the hardware state matches the PM runtime state. Need to debug more. Regards, Tony 8< ------------ --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2232,6 +2232,7 @@ err_irq: dma_release_channel(host->tx_chan); if (host->rx_chan) dma_release_channel(host->rx_chan); + pm_runtime_dont_use_autosuspend(host->dev); pm_runtime_put_sync(host->dev); pm_runtime_disable(host->dev); if (host->dbclk)
next prev parent reply other threads:[~2016-02-02 16:35 UTC|newest] Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-26 22:48 PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Tony Lindgren 2016-01-26 22:48 ` Tony Lindgren 2016-01-26 22:50 ` Tony Lindgren 2016-01-26 22:50 ` Tony Lindgren 2016-01-26 23:14 ` Rafael J. Wysocki 2016-01-26 23:14 ` Rafael J. Wysocki 2016-01-26 23:22 ` Tony Lindgren 2016-01-26 23:22 ` Tony Lindgren 2016-01-26 23:37 ` Rafael J. Wysocki 2016-01-26 23:37 ` Rafael J. Wysocki 2016-01-26 23:52 ` Tony Lindgren 2016-01-26 23:52 ` Tony Lindgren 2016-01-27 7:54 ` Rafael J. Wysocki 2016-01-27 7:54 ` Rafael J. Wysocki 2016-01-27 8:17 ` Ulf Hansson 2016-01-27 8:17 ` Ulf Hansson 2016-01-27 15:19 ` Tony Lindgren 2016-01-27 15:19 ` Tony Lindgren 2016-01-27 22:51 ` Rafael J. Wysocki 2016-01-27 22:51 ` Rafael J. Wysocki 2016-01-28 14:29 ` Ulf Hansson 2016-01-28 14:29 ` Ulf Hansson 2016-01-28 16:58 ` Tony Lindgren 2016-01-28 16:58 ` Tony Lindgren 2016-02-01 16:44 ` Ulf Hansson 2016-02-01 16:44 ` Ulf Hansson 2016-02-01 18:11 ` Tony Lindgren 2016-02-01 18:11 ` Tony Lindgren 2016-02-01 22:06 ` Tony Lindgren 2016-02-01 22:06 ` Tony Lindgren 2016-02-01 22:17 ` Rafael J. Wysocki 2016-02-01 22:17 ` Rafael J. Wysocki 2016-02-01 22:29 ` Tony Lindgren 2016-02-01 22:29 ` Tony Lindgren 2016-02-01 23:10 ` Rafael J. Wysocki 2016-02-01 23:10 ` Rafael J. Wysocki 2016-02-01 23:28 ` Tony Lindgren 2016-02-01 23:28 ` Tony Lindgren 2016-02-01 23:44 ` Tony Lindgren 2016-02-01 23:44 ` Tony Lindgren 2016-02-01 23:49 ` Alan Stern 2016-02-01 23:49 ` Alan Stern 2016-02-02 3:05 ` Tony Lindgren 2016-02-02 3:05 ` Tony Lindgren 2016-02-02 10:07 ` Ulf Hansson 2016-02-02 10:07 ` Ulf Hansson 2016-02-02 10:42 ` Ulf Hansson 2016-02-02 10:42 ` Ulf Hansson 2016-02-02 16:23 ` Alan Stern 2016-02-02 16:23 ` Alan Stern 2016-02-02 16:35 ` Tony Lindgren [this message] 2016-02-02 16:35 ` Tony Lindgren 2016-02-02 20:47 ` Ulf Hansson 2016-02-02 20:47 ` Ulf Hansson 2016-02-02 23:41 ` Tony Lindgren 2016-02-02 23:41 ` Tony Lindgren 2016-02-03 10:23 ` Ulf Hansson 2016-02-03 10:23 ` Ulf Hansson 2016-02-03 10:25 ` Ulf Hansson 2016-02-03 10:25 ` Ulf Hansson 2016-02-03 12:18 ` Rafael J. Wysocki 2016-02-03 12:18 ` Rafael J. Wysocki 2016-02-03 14:58 ` Ulf Hansson 2016-02-03 14:58 ` Ulf Hansson 2016-02-03 15:45 ` Alan Stern 2016-02-03 15:45 ` Alan Stern 2016-02-03 16:09 ` Tony Lindgren 2016-02-03 16:09 ` Tony Lindgren 2016-02-03 16:24 ` Ulf Hansson 2016-02-03 16:24 ` Ulf Hansson 2016-02-03 17:01 ` Tony Lindgren 2016-02-03 17:01 ` Tony Lindgren 2016-02-03 17:16 ` Rafael J. Wysocki 2016-02-03 17:16 ` Rafael J. Wysocki 2016-02-03 16:27 ` Tony Lindgren 2016-02-03 16:27 ` Tony Lindgren 2016-02-03 18:02 ` Ulf Hansson 2016-02-03 18:02 ` Ulf Hansson 2016-02-03 18:28 ` Tony Lindgren 2016-02-03 18:28 ` Tony Lindgren 2016-02-03 18:37 ` Ulf Hansson 2016-02-03 18:37 ` Ulf Hansson 2016-02-03 18:45 ` Tony Lindgren 2016-02-03 18:45 ` Tony Lindgren 2016-02-03 21:51 ` Tony Lindgren 2016-02-03 21:51 ` Tony Lindgren 2016-02-02 16:15 ` Alan Stern 2016-02-02 16:15 ` Alan Stern 2016-02-02 16:49 ` Tony Lindgren 2016-02-02 16:49 ` Tony Lindgren 2016-02-02 18:05 ` Tony Lindgren 2016-02-02 18:05 ` Tony Lindgren 2016-02-02 18:43 ` Alan Stern 2016-02-02 18:43 ` Alan Stern 2016-02-02 18:54 ` Tony Lindgren 2016-02-02 18:54 ` Tony Lindgren 2016-02-02 19:16 ` Alan Stern 2016-02-02 19:16 ` Alan Stern 2016-02-02 21:03 ` Tony Lindgren 2016-02-02 21:03 ` Tony Lindgren 2016-02-02 21:45 ` Alan Stern 2016-02-02 21:45 ` Alan Stern 2016-02-02 23:46 ` Tony Lindgren 2016-02-02 23:46 ` Tony Lindgren 2016-02-03 13:06 ` Rafael J. Wysocki 2016-02-03 13:06 ` Rafael J. Wysocki 2016-02-03 16:36 ` Tony Lindgren 2016-02-03 16:36 ` Tony Lindgren 2016-02-03 15:48 ` Alan Stern 2016-02-03 15:48 ` Alan Stern 2016-02-03 16:37 ` Tony Lindgren 2016-02-03 16:37 ` Tony Lindgren 2016-02-03 17:18 ` Rafael J. Wysocki 2016-02-03 17:18 ` Rafael J. Wysocki 2016-02-03 17:22 ` Tony Lindgren 2016-02-03 17:22 ` Tony Lindgren 2016-02-03 17:27 ` Rafael J. Wysocki 2016-02-03 17:27 ` Rafael J. Wysocki 2016-02-04 10:20 ` Ulf Hansson 2016-02-04 10:20 ` Ulf Hansson 2016-02-04 16:04 ` Alan Stern 2016-02-04 16:04 ` Alan Stern 2016-02-04 17:20 ` Tony Lindgren 2016-02-04 17:20 ` Tony Lindgren 2016-02-04 21:11 ` Ulf Hansson 2016-02-04 21:11 ` Ulf Hansson 2016-02-04 22:09 ` Alan Stern 2016-02-04 22:09 ` Alan Stern 2016-02-04 22:34 ` Ulf Hansson 2016-02-04 22:34 ` Ulf Hansson 2016-02-05 1:08 ` Tony Lindgren 2016-02-05 1:08 ` Tony Lindgren 2016-02-05 6:54 ` Ulf Hansson 2016-02-05 6:54 ` Ulf Hansson 2016-02-05 19:10 ` Tony Lindgren 2016-02-05 19:10 ` Tony Lindgren 2016-02-02 18:47 ` Tony Lindgren 2016-02-02 18:47 ` Tony Lindgren 2016-02-02 20:24 ` Ulf Hansson 2016-02-02 20:24 ` Ulf Hansson 2016-02-02 21:24 ` Alan Stern 2016-02-02 21:24 ` Alan Stern 2016-02-02 21:39 ` Tony Lindgren 2016-02-02 21:39 ` Tony Lindgren 2016-02-03 13:03 ` Rafael J. Wysocki 2016-02-03 13:03 ` Rafael J. Wysocki 2016-02-03 16:49 ` Tony Lindgren 2016-02-03 16:49 ` Tony Lindgren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160202163536.GU19432@atomide.com \ --to=tony@atomide.com \ --cc=khilman@baylibre.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=rafael.j.wysocki@intel.com \ --cc=rafael@kernel.org \ --cc=stern@rowland.harvard.edu \ --cc=ulf.hansson@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.