Hi, small addendum - there must be another factor involved.
Am 11.09.2018 um 20:20 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 11.09.2018 um 18:26 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 11.09.2018 um 15:07 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Tero,
After kernel has booted, there is a single difference in CM_ABE_CLKSTCTRL.
The relevant bit is: CLKACTIVITY_DPLL_ABE_X2_CLK
After reboot, there are bigger differences not wiped out by u-boot.
So the question is what disturbs this clock, especially as CLKACTIVITY_DPLL_ABE_X2_ seems to say that the clock is active (on Pyra) but not on EVM (I had expected the reverse to be more likely).
CM_ABE_CLKSTCTRL remains 0x803 on Pyra and 0x3 on EVM
Well, if we see the same setup by U-Boot after power-on it must be kernel + DTS. Or is this a false conclusion?
So I started to deconfigure kernel subsystems completely:
- all twl6040 / abe / aess
- all OMAP3 & OMAP4
- all wireless (wl1837 uses some external functional clocks)
- all sound
And I have checked U-Boot and DTS sources but did not find Pyra specific overwrites for any system clock or abe or dpll related registers.
Then I did rm /lib/modules (the most critical ones are configured into the kernel so that I can still boot), and interestingly the CLKACTIVITY_DPLL_ABE_X2_CLK is now the same (0x3) on Pyra and OMAP5EVM. And "reboot" works.
So I can now simply modprobe blacklist them one after the other to find out which one is conflicting.
Bingo!
root@letux:~# more /etc/modprobe.d/blacklist.conf blacklist pwm_omap_dmtimer root@letux:~#
makes the problem go away.
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.
Why don't you see this on omap5uevm even if these modules are loaded? I assume there is usually no panel connected that makes use of pwm_bl and pwm_omap_dmtimer. And there is no compatible = "ti,omap-dmtimer-pwm"; in omap5-board-common.dtsi or omap5-uevm.dts. This is a hardware difference between Pyra and OMAP5EVM.
So I think it is now up to you to help me to find out why pwm_omap_dmtimer can influence the dpll_abe_ck...
BR and thanks, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel