<c0d3z3r0>
mmind00: I reworked the act8846 patch but after some more testing I think that power cycling the act8846 on the radxa rock is not enough. every few reboots there is again a kernel panic. when resetting the board by reset button directly after restart I can reboot multiple times without any kernel panic
<mmind00>
c0d3z3r0: so I'd guess still something with the clocks or so
<c0d3z3r0>
mmind00: I took a look to the act8846 datasheet. pressing the reset button is the same as resetting it through software… so it should actually work. strange..
GriefNorth has quit [Ping timeout: 256 seconds]
<mmind00>
c0d3z3r0: hmm, the act8846 datasheet only mentions the regulators being turned off and on, but not if the settings are reset too [or I'm blind :-) ]
<mmind00>
c0d3z3r0: and from the RadxaRock schematics it looks like the reset-button actually toggles the PWRHOLD input of the act8846
markm has quit [Ping timeout: 272 seconds]
<mmind00>
c0d3z3r0: as it seems the undervolting of whatever happens when the other cores are powered on, can you try commenting the enable-method in the dts, try to boot and check the initial regulator output? [normally you should get output like "vcc_something: xxx mV <---> yyy mV at zzz mV" when the act8846 gets probed, so we can see what voltages it has during boot?
<c0d3z3r0>
mmind00: yes, I'll try
<c0d3z3r0>
mmind00: what enable method do you mean?
<c0d3z3r0>
mmind00: ah yeah didn't find it in rk3188-* :)
<c0d3z3r0>
mmind00: commented that out an rebooting works just nicely but there are no vcc messages
<mmind00>
c0d3z3r0: ok, so I guess we're really undervolting the cpu ... can you try enabling CONFIG_REGULATOR_DEBUG and then post a "dmesg" somewhere please?
<c0d3z3r0>
after the kernel panic timeout the restart handler did a act8846 power cycle and the voltage is again 1000 mV
<mmind00>
c0d3z3r0: hmm 1.35V would indicate it running at 1.6GHz at the time ... ist this reproducable? [i.e. is the voltage similar on all panics?)
<mmind00>
another test: after a sucessful boot, can you try a "cat 1608000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq" and see if it runs stable at 1.6GHz at all?
<c0d3z3r0>
oh bad.. most kernel panics happen before the voltage debug :/
<c0d3z3r0>
after booting the frequency is already set to 1.61 GHz
<c0d3z3r0>
mmind00: another interesting thing… the clock is running way too fast.. 2 seconds per 1 second and it sometimes skips 2 seconds at once o.O
<mmind00>
c0d3z3r0: all the time?
<c0d3z3r0>
yes
<c0d3z3r0>
and it seems to get faster… now it skips 2 seconds all the time
<c0d3z3r0>
ah no. that was my fault. i started watch without -n1. it's not getting faster but it's too fast
RokQuarry has joined #linux-rockchip
<naobsd>
with cpufreq, clocksource must not be arm generic timer
<naobsd>
^on rk3188
<naobsd>
on rk3066 there is dwc timer, on rk3288 there is arch timer, both are fixed freq, but generic timer is not fixed with cpufreq
<c0d3z3r0>
naobsd: where can this be changed?
<naobsd>
rockchip-timer should work as clocksource
<naobsd>
^on rk3188
<naobsd>
c0d3z3r0: btw, when kernel got panic during reboot? I thought it happened after power-cycle, but VDD_ARM 1.35V is strange
<c0d3z3r0>
naobsd: the kernel panic on every reboot happened because there was no power cylce. with the patch the act8846 does a power cycle on restart but it seems that this isn't enough because there are kernel panics after some (2-3) reboots
<naobsd>
well
<naobsd>
I want to know _where_ panic happen more specifically
<c0d3z3r0>
after the reboot / power cycle while booting again
<c0d3z3r0>
reboot -> power cycle -> boot -> kernel panic
<naobsd>
I see
<naobsd>
what happened if you set cpufreq 1.6G manually before reboot?
<c0d3z3r0>
cpufreq is always 1.6G. would setting it again change anything?
<naobsd>
always? with ondemand governor?
<c0d3z3r0>
yes
<naobsd>
why?
<naobsd>
(I'm talking about cpufreq just before reboot)