From: Suman Anna <s-anna@ti.com> To: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Tony Lindgren <tony@atomide.com>, Felipe Balbi <balbi@ti.com>, Kevin Hilman <khilman@linaro.org>, Rajendra Nayak <rnayak@ti.com>, "Bedia, Vaibhav" <vaibhav.bedia@ti.com>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Mark Jackson <mpfj-list@newflow.co.uk>, Sourav Poddar <sourav.poddar@ti.com>, Paul Walmsley <paul@pwsan.com> Subject: Re: Boot hang regression 3.10.0-rc4 -> 3.10.0 Date: Thu, 11 Jul 2013 19:40:47 -0500 [thread overview] Message-ID: <51DF508F.3050703@ti.com> (raw) In-Reply-To: <51DE8215.5060306@ti.com> On 07/11/2013 04:59 AM, Grygorii Strashko wrote: > Hi, > > On 07/11/2013 09:32 AM, Tony Lindgren wrote: >> * Felipe Balbi <balbi@ti.com> [130710 09:18]: >>> >>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: >>>> how about something like below ? It makes omap_device/hwmod and >>>> pm_runtime agree on the initial state of the device and will prevent >>>> ->runtime_resume() from being called on first pm_runtime_get*() done >>>> during probe. >>>> >>>> This is similar to what PCI bus does (if you look at pci_pm_init()). >>>> >>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f >>>> Author: Felipe Balbi <balbi@ti.com> >>>> Date: Wed Jul 10 18:50:16 2013 +0300 >>>> >>>> arm: omap2plus: unidle devices which are about to probe >>>> >>>> in order to make HWMOD and pm_runtime agree on the >>>> initial state of the device, we will unidle the device >>>> and call pm_runtime_set_active() to tell pm_runtime >>>> that the device is really active. > Don't think that it's good idea ( > I've checked some driver's and think this patch will enable some devices > unpredictably: > - hwspinlock > - mailbox > - iommu > - ipu > All above devices need to be enabled on demand only (no > pm_runtime_get*() calls in probe). More over, some of them have very > specific enabling sequence - like ipu). > > May be Summan can say more on that. Indeed, this is a problem for any of the slave processor devices. mailbox and iommu would be slaves to the remoteproc and the drivers have a specific sequence of bringing up a processor. The current hwmod/omap_device code is such that these devices will be left in reset and the driver code use the omap_device_(de)assert_hardreset API together with omap_device_enable code to bring up the devices. The remoteproc driver also needs to assert the resets (there are other problems associated with using omap_device_idle for remoteproc and iommu) for bringing up the devices after a suspend sequence. hwspinlock and mailbox may get away since they are in CORE domain, but definitely an issue for iommu and remoteproc. I would think that this would also affect other compute devices like IVAHD, ISS, SGX. regards Suman > >>>> >>>> By the time driver's probe() is reached, a call to >>>> pm_runtime_get_sync() will not cause driver's >>>> ->runtime_resume() method to be called at first, only >>>> after a successful ->runtime_suspend(). >>>> >>>> Signed-off-by: Felipe Balbi <balbi@ti.com> >>> >>> btw, this is RFC, haven't tested at all. >> >> Yes it does not compile, then removing the extra ; at the end >> of the functions, it oopses with a NULL pointer exception. >> >> Regards, >> >> Tony >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Suman Anna) To: linux-arm-kernel@lists.infradead.org Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0 Date: Thu, 11 Jul 2013 19:40:47 -0500 [thread overview] Message-ID: <51DF508F.3050703@ti.com> (raw) In-Reply-To: <51DE8215.5060306@ti.com> On 07/11/2013 04:59 AM, Grygorii Strashko wrote: > Hi, > > On 07/11/2013 09:32 AM, Tony Lindgren wrote: >> * Felipe Balbi <balbi@ti.com> [130710 09:18]: >>> >>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote: >>>> how about something like below ? It makes omap_device/hwmod and >>>> pm_runtime agree on the initial state of the device and will prevent >>>> ->runtime_resume() from being called on first pm_runtime_get*() done >>>> during probe. >>>> >>>> This is similar to what PCI bus does (if you look at pci_pm_init()). >>>> >>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f >>>> Author: Felipe Balbi <balbi@ti.com> >>>> Date: Wed Jul 10 18:50:16 2013 +0300 >>>> >>>> arm: omap2plus: unidle devices which are about to probe >>>> >>>> in order to make HWMOD and pm_runtime agree on the >>>> initial state of the device, we will unidle the device >>>> and call pm_runtime_set_active() to tell pm_runtime >>>> that the device is really active. > Don't think that it's good idea ( > I've checked some driver's and think this patch will enable some devices > unpredictably: > - hwspinlock > - mailbox > - iommu > - ipu > All above devices need to be enabled on demand only (no > pm_runtime_get*() calls in probe). More over, some of them have very > specific enabling sequence - like ipu). > > May be Summan can say more on that. Indeed, this is a problem for any of the slave processor devices. mailbox and iommu would be slaves to the remoteproc and the drivers have a specific sequence of bringing up a processor. The current hwmod/omap_device code is such that these devices will be left in reset and the driver code use the omap_device_(de)assert_hardreset API together with omap_device_enable code to bring up the devices. The remoteproc driver also needs to assert the resets (there are other problems associated with using omap_device_idle for remoteproc and iommu) for bringing up the devices after a suspend sequence. hwspinlock and mailbox may get away since they are in CORE domain, but definitely an issue for iommu and remoteproc. I would think that this would also affect other compute devices like IVAHD, ISS, SGX. regards Suman > >>>> >>>> By the time driver's probe() is reached, a call to >>>> pm_runtime_get_sync() will not cause driver's >>>> ->runtime_resume() method to be called at first, only >>>> after a successful ->runtime_suspend(). >>>> >>>> Signed-off-by: Felipe Balbi <balbi@ti.com> >>> >>> btw, this is RFC, haven't tested at all. >> >> Yes it does not compile, then removing the extra ; at the end >> of the functions, it oopses with a NULL pointer exception. >> >> Regards, >> >> Tony >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
next prev parent reply other threads:[~2013-07-12 0:46 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-04 13:25 Boot hang regression 3.10.0-rc4 -> 3.10.0 Mark Jackson 2013-07-04 13:25 ` Mark Jackson 2013-07-04 15:14 ` Mark Jackson 2013-07-04 15:14 ` Mark Jackson 2013-07-04 16:00 ` Mark Jackson 2013-07-04 16:00 ` Mark Jackson 2013-07-05 8:11 ` Bedia, Vaibhav 2013-07-05 8:11 ` Bedia, Vaibhav 2013-07-05 11:59 ` Tony Lindgren 2013-07-05 11:59 ` Tony Lindgren 2013-07-05 13:20 ` Bedia, Vaibhav 2013-07-05 13:20 ` Bedia, Vaibhav 2013-07-05 13:31 ` Bedia, Vaibhav 2013-07-05 13:31 ` Bedia, Vaibhav 2013-07-08 11:25 ` Tony Lindgren 2013-07-08 11:25 ` Tony Lindgren 2013-07-08 12:16 ` Tony Lindgren 2013-07-08 12:16 ` Tony Lindgren 2013-07-08 12:41 ` Rajendra Nayak 2013-07-08 12:41 ` Rajendra Nayak 2013-07-08 13:10 ` Tony Lindgren 2013-07-08 13:10 ` Tony Lindgren 2013-07-08 13:20 ` Rajendra Nayak 2013-07-08 13:20 ` Rajendra Nayak 2013-07-08 13:25 ` Rajendra Nayak 2013-07-08 13:25 ` Rajendra Nayak 2013-07-08 13:35 ` Felipe Balbi 2013-07-08 13:35 ` Felipe Balbi 2013-07-09 5:33 ` Rajendra Nayak 2013-07-09 5:33 ` Rajendra Nayak 2013-07-09 6:42 ` Felipe Balbi 2013-07-09 6:42 ` Felipe Balbi 2013-07-09 7:19 ` Rajendra Nayak 2013-07-09 7:19 ` Rajendra Nayak 2013-07-09 7:40 ` Felipe Balbi 2013-07-09 7:40 ` Felipe Balbi 2013-07-09 18:59 ` Grygorii Strashko 2013-07-09 18:59 ` Grygorii Strashko 2013-07-09 19:41 ` Felipe Balbi 2013-07-09 19:41 ` Felipe Balbi 2013-07-10 12:16 ` Grygorii Strashko 2013-07-10 12:16 ` Grygorii Strashko 2013-07-10 12:25 ` Felipe Balbi 2013-07-10 12:25 ` Felipe Balbi 2013-07-10 8:22 ` Kevin Hilman 2013-07-10 8:22 ` Kevin Hilman 2013-07-10 12:10 ` Tony Lindgren 2013-07-10 12:10 ` Tony Lindgren 2013-07-10 12:27 ` Tony Lindgren 2013-07-10 12:27 ` Tony Lindgren 2013-07-10 14:26 ` Tony Lindgren 2013-07-10 14:26 ` Tony Lindgren 2013-07-10 16:07 ` Felipe Balbi 2013-07-10 16:07 ` Felipe Balbi 2013-07-10 16:11 ` Felipe Balbi 2013-07-10 16:11 ` Felipe Balbi 2013-07-11 6:32 ` Tony Lindgren 2013-07-11 6:32 ` Tony Lindgren 2013-07-11 9:59 ` Grygorii Strashko 2013-07-11 9:59 ` Grygorii Strashko 2013-07-12 0:40 ` Suman Anna [this message] 2013-07-12 0:40 ` Suman Anna 2013-07-15 6:44 ` Rajendra Nayak 2013-07-15 6:44 ` Rajendra Nayak 2013-07-15 10:01 ` Rajendra Nayak 2013-07-15 10:01 ` Rajendra Nayak 2013-07-15 19:23 ` Suman Anna 2013-07-15 19:23 ` Suman Anna 2013-07-16 6:30 ` Rajendra Nayak 2013-07-16 6:30 ` Rajendra Nayak 2013-07-11 9:17 ` Rajendra Nayak 2013-07-11 9:17 ` Rajendra Nayak 2013-07-11 9:26 ` Felipe Balbi 2013-07-11 9:26 ` Felipe Balbi 2013-07-11 10:16 ` [PATCH] arm: omap2plus: unidle devices which are about to probe Felipe Balbi 2013-07-11 10:16 ` Felipe Balbi 2013-07-12 11:58 ` Grygorii Strashko 2013-07-12 11:58 ` Grygorii Strashko 2013-07-12 12:10 ` Felipe Balbi 2013-07-12 12:10 ` Felipe Balbi 2013-07-12 12:27 ` Rajendra Nayak 2013-07-12 12:27 ` Rajendra Nayak 2013-07-13 22:21 ` Kevin Hilman 2013-07-13 22:21 ` Kevin Hilman 2013-07-11 9:59 ` Boot hang regression 3.10.0-rc4 -> 3.10.0 Grygorii Strashko 2013-07-11 9:59 ` Grygorii Strashko 2013-07-16 10:27 ` Grygorii Strashko 2013-07-16 10:27 ` Grygorii Strashko 2013-07-17 7:10 ` Rajendra Nayak 2013-07-17 7:10 ` Rajendra Nayak 2013-07-11 6:18 ` Rajendra Nayak 2013-07-11 6:18 ` Rajendra Nayak 2013-07-11 6:24 ` Tony Lindgren 2013-07-11 6:24 ` Tony Lindgren 2013-07-11 9:11 ` Rajendra Nayak 2013-07-11 9:11 ` Rajendra Nayak
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=51DF508F.3050703@ti.com \ --to=s-anna@ti.com \ --cc=balbi@ti.com \ --cc=grygorii.strashko@ti.com \ --cc=khilman@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=mpfj-list@newflow.co.uk \ --cc=paul@pwsan.com \ --cc=rnayak@ti.com \ --cc=sourav.poddar@ti.com \ --cc=tony@atomide.com \ --cc=vaibhav.bedia@ti.com \ /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.