On 07/11/2013 04:59 AM, Grygorii Strashko wrote: > Hi, > > On 07/11/2013 09:32 AM, Tony Lindgren wrote: >> * Felipe Balbi <balbi@xxxxxx> [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@xxxxxx> >>>> 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@xxxxxx> >>> >>> 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@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
