Boot hang regression 3.10.0-rc4 -> 3.10.0

[Grygorii Strashko]

Hi,

On 07/11/2013 09:32 AM, Tony Lindgren wrote:
> * Felipe Balbi <balbi at 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 at 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.

>>>
>>>      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 at 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
>