<warpme>
if my hypothesis with regulator spike is correct - it will be enough to make sure that with @loki666 commit regulator is not re-programmed when kernel initiates pmic. Do we know what are conditions triggering regulator re-programming (touching at all) at kernel init of axp717 pmic?
Net147 has quit []
Net147 has joined #linux-sunxi
<loki666>
With the patch reverted, do you also see the last line where kernel bring back regulator to 1.5v ?
ity1 has quit []
ity has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
loki666 something is wrong: it bring q.1
<apritzel>
... brings 1.16V up to 1.5
<apritzel>
1.16 is still some LPDDR4 value, I guess, so I'd blame Syterkit
<apritzel>
and the glitch is probably less of a problem than the wrong voltage to begin with
<apritzel>
1.16 is too little, but also the training is done with that level, so the timing tolerances are different
<apritzel>
is it the wrong regulator? DRAM is on the 717, right? your log seems to suggest it's on the 323?
<apritzel>
warpme in general I believe your regulator setup might be not right, how did you come up with the values?
<apritzel>
warpme yes I saw that, but the kernel clearly read that regulator as 1.16V, and those printfs are just printfs
<apritzel>
My money is on a misnamed or mislabelled regulator
<warpme>
apritzel : do you believe syter will successfuly init (and simple test) ddr3 ram supplied with 1.16v (instead of required 1.5v)?
<warpme>
indeed - wrong regulator might explain
<apritzel>
if the kernel adjusts the DRAM regulator, that's always wrong - because it's too late and might produce a glitch
<warpme>
but why it works ok without loki666 commit?
<apritzel>
warpme: the chips are DDR3L, so they only require 1.35V. And yes, the BSP just got that wrong.
<apritzel>
but I indeed doubt that 1.16V would work, so i guess it's just wrongly named DRAM in the DT
<warpme>
vendor boot0 says: [310]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
<warpme>
so i still think it is ddr3 (not lp)
<apritzel>
DDR3L is the same as DDR3, just better selected or tuned to work with a lower voltage
<apritzel>
please note that this is different from LPDDR3
<warpme>
ah ok - clear
<apritzel>
which requires a different init algorithm
<apritzel>
you *can* run DDR3L with 1.5V, but it wastes energy. I guess for a TV box they dont care
<apritzel>
anyway,your log suggests that the rail adjusted in on the secondary PMIC: the AXP323
<apritzel>
and I dont know why the ramp patch breaks that, but adjusting 1.16 to 1.5 sounds fishy anyway
<apritzel>
and as mentioned, anything named DRAM would be wrong at this point anyway
<apritzel>
warpme: also please note that I found the regulators on the X96QPro+ to be quite different from the Avaota
<apritzel>
I have some ideas for the values, based on dumping the AXP registers from the running BSP, but still it's not consistent
<apritzel>
it seems like the BSP doesn't use many rails at all, so some might not matter
<warpme>
Indeed i think we have 2 things in parallel here: 1)wrong label(s) in dt (or even wrong setups of regulators); 2)incorrect ramp values in dt. I assume: when we will have ramp values the same like those set/used by syter (or default by axp cold power-on) - we should have booting device with loki666 commit - right?
<warpme>
issue is that vendor dt is too difficult to deduce some regulators mapping (e.g. dram vdd)....
<apritzel>
the vendor *DT* is borderline useless to deduce the voltages, because they treat the regulator setup differently than mainline
<apritzel>
either the voltages are set by the bootloader, or sometimes by the management core
<apritzel>
so the DT just encodes the range from the data sheet, which is somewhat pointless
<warpme>
alternative solution might be modification of loki666 patch in a way that: it not changes regulator ramp setup if dt don't have regulator ramp values defined. I think this should be default bahavior...
<apritzel>
no, that's what we had before, and I think wens rightly argued that would be wrong, because the ramp is a
<apritzel>
property of the AXP rail, and not a board choice
<apritzel>
I believe the patch is a red herring, it just changes the behaviour slightly, and we got away with it before
<apritzel>
but somewhat is wrong to begin with
<warpme>
"either the voltages are set by the bootloader, or sometimes by the management core" - isn't 2nd a case of here (i see bl31 initiates & uses e906 management arisc core)
<apritzel>
I saw that on other boards, I think many A64 boards used that "ARISC controls the PMIC model"
<apritzel>
but here I dont think it's happening,because the PMIC values were mostly untouched after boot
<apritzel>
maybe it something that they removed from the tablet BSP?
<apritzel>
also I saw error messages in the BSP log that suggest that the I2C access doesnt work at all
<warpme>
re "no, that's what we had before" - if so i think moving away from assumption that: kernel changes more aspects than defined in dt (except those unavoidable/required) - is bad idea. imho it may potentially create much more issues than solution(s). (btw: what it solves?)
<apritzel>
it solves a reproducible instability with DVFS on the H700 boards
<warpme>
oop sorry - i should say: "moving into model" instead of "moving away from assumption"
<apritzel>
and that ramp aspect is defined in the data sheet, we were just (wrongly) ignoring that before
<warpme>
well - if we will go into logic: "set ramp if defined in dt" else "dont touch ramp" - fix should also work?
<apritzel>
thee ramp *value* (640mV/us) is fixed, so it doesn't belong in the DT
<warpme>
oh when i was asking "btw: what it solves?" - i was not asking about loki666 patch - but rather about model where kernel changes more aspects than defined in dt (except those unavoidable/required) :-)
<apritzel>
the ramp cannot be turned off, just slowed even more
<apritzel>
before the kernel assumed that programming the new voltage would be in effect immediately
<apritzel>
which is not the case
<apritzel>
and lead to the DVFS instability, because the frequency was bumped up before the voltage has reached its target
<apritzel>
so that's a clear bug which needs fixing
bauen1_ has joined #linux-sunxi
parthiban has quit [Quit: Leaving]
<warpme>
oh - so i was understanding ramp a bit differently: slope of output voltage change is dependent on filtering capacity doing filtering at output rail. As regulator has finite and defined current supply - effective slope depends on used elements in hw design. This must be reflected in dt as changing freq. must be delayed more than time required to get target voltage. getting target voltage depends on slope. slope depends on filtering
<warpme>
capacity on output rail. filtering capacity depends on hw design (usually filtering capacitors used by board designer). If hw design is reference design - then slope has also "standard" value - but such assumption might be frequently false positive. by this - imho - defining ramp in dt make sense (and has sense only when we know hw design...)
bauen1 has quit [Ping timeout: 480 seconds]
<warpme>
i think good rule of thumb - when we don't know hw design - is: starting with high ramp then decreasing in steps till instability happens then add 50% safety margin.
<warpme>
high ramp -> i mean low slope
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
warpme has joined #linux-sunxi
<apritzel>
so yeah, that's something different I think. The delay here is built into the PMIC, when you say: set 1.5V, it will take a while
apritzel_ has quit [Read error: Connection reset by peer]
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<loki666>
Actually I don't understand how only AXP717 requires these ramp delay in the driver... (DT ramp delay is for external delay due to HW design... Filtering cap on rails etc...). I mean an change in voltage is never instantaneous, it cannot be.
Robot_ has quit []
<apritzel>
loki666 I think that's a misunderstanding: the delay we are talking about here is in the PMIC itself, and that's only for the 717
<apritzel>
that's why we did not NOT put it in the DT
<apritzel>
I guess the voltage change can be very quick? compared to the 717 delay
<apritzel>
checked the 717 data sheet again: that delay is called DVM and *can* be turned off, but its enabled by default
apritzel_ has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
<apritzel_>
the 323/313 does not support this
apritzel has joined #linux-sunxi
apritzel_ has quit [Read error: Connection reset by peer]
ftg has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
apritzel has quit [Quit: CoreIRC for Android - www.coreirc.com]