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

H. Nikolaus Schaller hns at goldelico.com
Sat Sep 15 17:50:11 CEST 2018


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?

BR and thanks,
Nikolaus



More information about the Letux-kernel mailing list