Hi,
Am 13.09.2018 um 12:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
I have done further tests on the Pyra and
a) the problem with pwm_bl goes away if I comment out the keyboard backlight (timer8) from DT and keep timer9 only. It can still independently be triggered by modprobing snd_soc_omap_abe_twl6040
b) it appears that the problem is already triggered by modprobe and does not go away by modprobe -r, so it is unlikely a cleanup problem before reboot.
All this indicates that some clock dividers or switches are not properly controlled.
But I have still not found what makes the significant difference between Pyra and uevm setup.
Having done more experiments, I found the following.
I see the problem on Pyra even when only modprobing pwm_omap_dmtimer but not pwm_bl. So the problem is indeed in omap timer/pwm management and not outside.
This means the backlight pwm isn't even active and I have checked that there are no calls to pwm_omap_dmtimer_config() or pwm_omap_dmtimer_enable() because pwm_bl isn't loaded.
A simple run through pwm_omap_dmtimer_probe() by modprobe pwm_omap_dmtimer suffices to trigger the reboot problem afterwards.
Next, I tried to inject printk() into pwm_omap_dmtimer_probe() to isolate where the problem starts.
It turns out that disabling the call
dm_timer = pdata->request_by_node(timer);
in drivers/pwm/pwm-omap-dmtimer.c suffices to make the problem go away. Of course without working PWM even if I modprobe pwm_bl.
This seems to call _omap_dm_timer_request().
The deepest level I could identify is the call to
pm_runtime_get_sync(&timer->pdev->dev);
in omap_dm_timer_enable().
If I make omap_dm_timer_enable() return 0 before this call, I can reboot without problems.
The call sequence known to trigger the problem is so far:
pwm_omap_dmtimer_probe() dm_timer = pdata->request_by_node(timer); omap_dm_timer_request_by_node(); _omap_dm_timer_request(); omap_dm_timer_enable() pm_runtime_get_sync(&timer->pdev->dev);
So it is a pm_runtime problem for timer8 (and others).
But not really in the pwm-omap-dmtimer and timer-ti-dm drivers but it collides with something else (which is on the Pyra but not on the OMAP5EVM).
I had thought about adding printk into pm_runtime_get_sync but this is no longer specific to the dm-timers. The same would be for printk in the hwmods for timers.
Any suggestions how to find out what the second factor could be?
BR and thanks, Nikolaus