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

H. Nikolaus Schaller hns at goldelico.com
Thu Sep 13 12:16:47 CEST 2018


Hi Tero,

> Am 12.09.2018 um 19:19 schrieb Tero Kristo <t-kristo at ti.com>:
> 
> On 12/09/18 19:17, H. Nikolaus Schaller wrote:
>> Hi Tony,
>>> Am 12.09.2018 um 02:03 schrieb Tony Lindgren <tony at atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns at goldelico.com> [180911 18:28]:
>>>>> BTW: blacklisting pwm_bl makes CLKACTIVITY_DPLL_ABE_X2_CLK
>>>>> show the right value but reboot still can't transition
>>>>> dpll_abe_ck to 'locked'.
>>>> 
>>>> After adding back all modules except pwm_omap_dmtimer the problem
>>>> comes back to the Pyra. And adding a omap-dmtimer-pwm to the omap5-uevm.dts
>>>> does make CLKACTIVITY_DPLL_ABE_X2_CLK become 0x803 as I see on the
>>>> Pyra, but it still handles reboots properly.
>>>> 
>>>> More test results to come tomorrow.
>>> 
>>> OK good to hear you got it narrowed down.
>> I have further narrowed it down to
>> root at letux:~# more /etc/modprobe.d/pwm.conf
>> blacklist pwm_omap_dmtimer
>> blacklist snd_soc_omap_abe_twl6040
>> root at letux:~#
>> which always reboots fine (tested with letux-4.18.7 and 4.19-rc1 and 4.14.58).
>> Either
>> 	modprobe pwm_omap_dmtimer
>> OR (!)
>> 	modprobe snd_soc_omap_abe_twl6040
>> before "reboot" makes the Pyra boot hang with the dpll_abe_ck failure.
>> Generally it reminds me a little of the pinctrl and generic-adc-battery
>> drivers problem where it turned out that the main problem was a write-out-of-bounds
>> in generic-adc-battery so that it did occur only if drivers were loaded in a
>> specifc sequence.
>> But this here is more reproducible. On the Pyra.
>> I am still trying to reproduce the effect on the omap5evm by amending
>> the mainline DTS. It does reboot with these modules loaded...
>> What I alread wonder is what
>> - dpll_abe_ck setup
>> - pwm_omap_dmtimer
>> - snd_soc_omap_abe_twl6040
> 
> They are most likely using the same source clock (dpll_abe_ck.)
> 
> - Some PWMs (GPtimers) use ABE as clock source, depending on DT config you might be using a PWM which uses ABE clocks

Intersting!

Pyra uses timer9 for display backlight PWM and timer8 for keyboard backlight PWM.

Table 23-3: timer8 (and 5-7) gets ICLK and RST from ABE while timer9 (and others) gets them from L4_PER.

And Table 3-242 also lists McBSP which are not activated on the evm. This makes another difference.
Figure 3-37 is also informative.
 
> - Also TWL6040 uses ABE clock as source, as it is used for audio

So as a working hypothesis, these drivers might do conflicting clock enable/reset activities
or prevent them from being disabled during preparation for reboot.

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.

BR and thanks,
Nikolaus



More information about the Letux-kernel mailing list