On 08/28/2015 12:24 PM, Keerthy wrote:
On Thursday 27 August 2015 10:36 PM, Grygorii Strashko wrote:
On 08/27/2015 07:38 PM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [150827 06:42]:
Hi Tony,
On 08/26/2015 09:10 PM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [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.
My dra7-evm failed to boot on "2b186e5 Add linux-next specific files
for 20150827"
and this change restores boot.
Will wait for confirmation from Keerthy.
I confirm that with this patch the boot crash is fixed.
Tested-by: Keerthy <j-keerthy@xxxxxx>
Without this patch i see this crash during boot:
Thanks, Keerthy.
I'll update and resend this new patch version.
--
regards,
-grygorii
--
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
