[Letux-kernel] OMAP5: Debugging kernel not starting... (and clock: dpll_abe_ck failed transition to 'locked')

Tero Kristo t-kristo at ti.com
Mon Sep 17 09:30:25 CEST 2018


On 15/09/18 18:50, H. Nikolaus Schaller wrote:
> Hi,
> 
>> Am 13.09.2018 um 12:16 schrieb H. Nikolaus Schaller <hns at 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


More information about the Letux-kernel mailing list