On 15/09/18 18:50, H. Nikolaus Schaller wrote:
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?
Have you traced the reset signals on your board? How is sys_nreswarm connected for example compared to omap5uevm board? What happens if you replace the warm reset with a cold reset? Try replacing the warm reset from omap4_prminst_global_warm_sw_reset() with cold reset (just change the bit used to reset the device.)
It looks like in case of pyra, the resets are not passed in properly, leaving some pieces of HW (like ABE) in bad state. None of the register level settings should impact the result of warm reset in ideal world, however there are some warm reset erratas in place for the device which call for proper routing of reset signals on the board itself, and might have impact.
Have you looked at the errata documents whether any of those apply to your design?
-Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki