From: Tony Lindgren <tony@atomide.com> To: Ulf Hansson <ulf.hansson@linaro.org> Cc: "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: Thu, 28 Jan 2016 08:58:10 -0800 [thread overview] Message-ID: <20160128165810.GA19432@atomide.com> (raw) In-Reply-To: <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com> Hi, * Ulf Hansson <ulf.hansson@linaro.org> [160128 06:30]: > On 27 January 2016 at 00:52, Tony Lindgren <tony@atomide.com> wrote: > > * Rafael J. Wysocki <rafael@kernel.org> [160126 15:38]: > >> On Wed, Jan 27, 2016 at 12:22 AM, Tony Lindgren <tony@atomide.com> wrote: > >> > * Rafael J. Wysocki <rafael@kernel.org> [160126 15:15]: > >> >> On Tue, Jan 26, 2016 at 11:48 PM, Tony Lindgren <tony@atomide.com> wrote: > >> >> > Hi, > >> >> > > >> >> > Looks like commit 5de85b9d57ab ("PM / runtime: Re-init runtime > >> >> > PM states at probe error and driver unbind") broke PM on at least > > I need to understand the issue here in a bit more detail, could you > please try to fill out some of my gaps!? > > In *what way* did it break PM? The MMC hardware will not get idled properly any longer blocking any deeper idle states. > Did the driver not probe successfully the second try? If so, what happened. It probes fine after a -EPROBE_DEFER on the vmmc i2c regulator. But the PM runtime usecounts are wrong. > >> >> > omap3. It seems we now need to additionally also call > >> >> > pm_runtime_dont_use_autosuspend() to get things working again? > >> >> > > >> >> > The following fixes idling on omap3, but I'm wondering if we > >> >> > should do something in pm_runtime_reinit() instead? > > I understand this as the second (or third, forth, whatever) probing > attempt actually succeeds, right!? Right. > Is the issue you are seeing, that the device never becomes runtime > suspended due to commit 5de85b9d57ab ("PM / runtime: Re-init runtime > PM states at probe error and driver unbind")? Correct. > >> > Looks like we have RPM_ACTIVE set in pm_runtime_reinit() if that > >> > gives any clues. > > That's a good clue. Although, there could be several reasons to why. > > Rafael has pointed out one valid potential case, but I want to be sure > that's really what happening here. > > *If* the problem is that the device doesn't becomes runtime suspended, > that will anyway be prevented as long as the autosuspend_delay has > been set to a negative value. That's why I wonder whether this really > is the case here. That seems to be the case here. In device driver probe, commenting out pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY) also makes things work again. So one of the failing cases seems to be: 1. Device driver probe sets pm_runtime_set_autosuspend_delay() 2. Device driver probe initially fails with -EPROBE_DEFER 3. PM runtime usecounts get messed up > For omap3, I assume there's a PM domain (the so called hwmod) being > attached to the omap_hsmmc device at device registration point!? Correct. It uses the notifiers like bus code does in general. FYI, most SoCs don't have hardware based autoidle signaling between the interconnect and the interconnect targets. So the hwmod code is still needed until we have converted it into a proper interconnect + module target drivers. > In that path depending on a specific hwmod flag, the device will be > given the an initial *active* runtime PM status, via invoking > pm_runtime_set_active(). > > *If* that's the case, it affects the probing sequence, as the > pm_runtime_get_sync() won't trigger the ->runtime_resume() callbacks > to be invoked in the first probe attempt. It has worked since pm runtime. And it works with MMC as as a loadable module just fine when no -EPROBE_DEFER happens. > Moreover, according to the data I received in this regression report > so far, it seems like probing the second time has *always* been done > with the device in runtime PM active state. Could that be the reason > to why it "happens" to work? Not correct. I think that speculation is not related to the $subject regression at all. BTW, do you have some hardware to test with that has PM runtime implemnted and actually working with mainline kernel? Regards, Tony
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: Thu, 28 Jan 2016 08:58:10 -0800 [thread overview] Message-ID: <20160128165810.GA19432@atomide.com> (raw) In-Reply-To: <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com> Hi, * Ulf Hansson <ulf.hansson@linaro.org> [160128 06:30]: > On 27 January 2016 at 00:52, Tony Lindgren <tony@atomide.com> wrote: > > * Rafael J. Wysocki <rafael@kernel.org> [160126 15:38]: > >> On Wed, Jan 27, 2016 at 12:22 AM, Tony Lindgren <tony@atomide.com> wrote: > >> > * Rafael J. Wysocki <rafael@kernel.org> [160126 15:15]: > >> >> On Tue, Jan 26, 2016 at 11:48 PM, Tony Lindgren <tony@atomide.com> wrote: > >> >> > Hi, > >> >> > > >> >> > Looks like commit 5de85b9d57ab ("PM / runtime: Re-init runtime > >> >> > PM states at probe error and driver unbind") broke PM on at least > > I need to understand the issue here in a bit more detail, could you > please try to fill out some of my gaps!? > > In *what way* did it break PM? The MMC hardware will not get idled properly any longer blocking any deeper idle states. > Did the driver not probe successfully the second try? If so, what happened. It probes fine after a -EPROBE_DEFER on the vmmc i2c regulator. But the PM runtime usecounts are wrong. > >> >> > omap3. It seems we now need to additionally also call > >> >> > pm_runtime_dont_use_autosuspend() to get things working again? > >> >> > > >> >> > The following fixes idling on omap3, but I'm wondering if we > >> >> > should do something in pm_runtime_reinit() instead? > > I understand this as the second (or third, forth, whatever) probing > attempt actually succeeds, right!? Right. > Is the issue you are seeing, that the device never becomes runtime > suspended due to commit 5de85b9d57ab ("PM / runtime: Re-init runtime > PM states at probe error and driver unbind")? Correct. > >> > Looks like we have RPM_ACTIVE set in pm_runtime_reinit() if that > >> > gives any clues. > > That's a good clue. Although, there could be several reasons to why. > > Rafael has pointed out one valid potential case, but I want to be sure > that's really what happening here. > > *If* the problem is that the device doesn't becomes runtime suspended, > that will anyway be prevented as long as the autosuspend_delay has > been set to a negative value. That's why I wonder whether this really > is the case here. That seems to be the case here. In device driver probe, commenting out pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY) also makes things work again. So one of the failing cases seems to be: 1. Device driver probe sets pm_runtime_set_autosuspend_delay() 2. Device driver probe initially fails with -EPROBE_DEFER 3. PM runtime usecounts get messed up > For omap3, I assume there's a PM domain (the so called hwmod) being > attached to the omap_hsmmc device at device registration point!? Correct. It uses the notifiers like bus code does in general. FYI, most SoCs don't have hardware based autoidle signaling between the interconnect and the interconnect targets. So the hwmod code is still needed until we have converted it into a proper interconnect + module target drivers. > In that path depending on a specific hwmod flag, the device will be > given the an initial *active* runtime PM status, via invoking > pm_runtime_set_active(). > > *If* that's the case, it affects the probing sequence, as the > pm_runtime_get_sync() won't trigger the ->runtime_resume() callbacks > to be invoked in the first probe attempt. It has worked since pm runtime. And it works with MMC as as a loadable module just fine when no -EPROBE_DEFER happens. > Moreover, according to the data I received in this regression report > so far, it seems like probing the second time has *always* been done > with the device in runtime PM active state. Could that be the reason > to why it "happens" to work? Not correct. I think that speculation is not related to the $subject regression at all. BTW, do you have some hardware to test with that has PM runtime implemnted and actually working with mainline kernel? Regards, Tony
next prev parent reply other threads:[~2016-01-28 16:58 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 [this message] 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 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=20160128165810.GA19432@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=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.