* Grygorii Strashko <grygorii.stras...@ti.com> [150827 06:42]:
> Hi Tony,
>
> On 08/26/2015 09:10 PM, Tony Lindgren wrote:
> > * Grygorii Strashko <grygorii.stras...@ti.com> [150826 11:01]:
> >> Now Kernel fails to boot 50% of times (form build to build) with
> >> RT-patchset applied due to the following race - on late boot
> >> stages deferred_probe_work_func races with omap_device_late_ini
> >>
> >> late_initcall
> >> - deferred_probe_initcal() tries to re-probe all pending driver's probe.
> >> [In general, It's NOT expected to probe any other built-in drivers
> >> after
> >> deferred_probe_initcal() is finished, because most of
> >> late_initcall_sync/late_initcall functions expected that all driver
> >> or probed or deferred already.]
> >>
> >> - later on, some driver is probing in this case It's could cpsw.c
> >> (but could be any other drivers)
> >> cpsw_init
> >> - platform_driver_register
> >> - really_probe
> >> - driver_bound
> >> - driver_deferred_probe_trigger
> >> and boot proceed.
> >> So, at this moment we have deferred_probe_work_func scheduled.
> >>
> >> late_initcall_sync
> >> - omap_device_late_init
> >> - omap_device_idle
> >>
> >> CPU1 CPU2
> >> - deferred_probe_work_func
> >> - really_probe
> >> - omap_hsmmc_probe
> >> - pm_runtime_get_sync
> >> late_initcall_sync
> >> - omap_device_late_init
> >> if (od->_driver_status !=
> >> BUS_NOTIFY_BOUND_DRIVER) {
> >> if (od->_state ==
> >> OMAP_DEVICE_STATE_ENABLED) {
> >> -
> >> omap_device_idle [ops - IP is disabled, ]
> >> - [fail]
> >> - pm_runtime_put_sync
> >> - omap_hsmmc_runtime_suspend [ooops!]
> >
> > OK idling of unclaimed devices should not happen for deferred probe,
> > it should only happen when there's no driver and no probing happening.
> >
> >> Lets remove just remove omap_device_late_init completely as suggested
> >> by Tero Kristo:
> >>
> >> "How about remove omap_device_late_init call completely. I don't think
> >> it does anything useful at the moment; none of the omap devices get
> >> enabled outside runtime_pm, so there should be no need to explicitly
> >> disable the devices."
> >
> > I think this is still needed from PM point of view as otherwise we
> > don't idle any devices that don't have a driver available. Or am I
> > missing something?
> >
> > To me it seems the bug is relying on the BUS_NOTIFY_BOUND_DRIVER is
> > not set in the deferred probe case.
> >
>
>
> What do you think about below alternative?
>
> diff --git a/arch/arm/mach-omap2/omap_device.c
> b/arch/arm/mach-omap2/omap_device.c
> index 4cb8fd9..72ebc4c 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -901,7 +901,8 @@ static int __init omap_device_late_idle(struct device
> *dev, void *data)
> if (od->hwmods[i]->flags & HWMOD_INIT_NO_IDLE)
> return 0;
>
> - if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER) {
> + if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER &&
> + od->_driver_status != BUS_NOTIFY_BIND_DRIVER) {
> if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
> dev_warn(dev, "%s: enabled but no driver. Idling\n",
> __func__);
Seems better to me if it really fixes the issue.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
