Hi Tero,
Am 12.09.2018 um 19:19 schrieb Tero Kristo t-kristo@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@atomide.com:
- H. Nikolaus Schaller hns@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@letux:~# more /etc/modprobe.d/pwm.conf blacklist pwm_omap_dmtimer blacklist snd_soc_omap_abe_twl6040 root@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