putti_ has joined #linux-exynos
Putti has quit [Ping timeout: 272 seconds]
wwilly has quit [Ping timeout: 272 seconds]
genii has quit [Quit: Bedtime. See you soon.]
chewitt has quit [Quit: Adios!]
mszyprow|home has joined #linux-exynos
putti_ has joined #linux-exynos
putti_ has quit [Changing host]
putti_ is now known as Putti
wwilly has joined #linux-exynos
<wwilly> mszyprow|home: ok, let me know, I'm really curious
<mszyprow|home> wwilly: it looks that there is a bug in the regulator code for coupled regulators, which results in setting too low voltage. your patch decreases the clocks rate for fsys bus (200MHz cannot be derived from 666MHz, so i efectively sets 166mhz), what 'fixes' its operation on too low voltage
<mszyprow|home> wwilly: but still, that's only a theory
<wwilly> uhm ok
<mszyprow|home> wwilly: I'm checking it now
<wwilly> what is your formula to derive the frequency? is there any code for that?
<wwilly> I haven't dig that yet
<mszyprow|home> wwilly: you need to check the clock tree from the PLLs to the individual clocks
<mszyprow|home> wwilly: there are only integer dividers there
<wwilly> uhm ok
<mszyprow|home> wwilly: so from 666MHz you can derive only 222MHz (div 3), 166.6MHz (div 4), 133MHz (div 5), 111MHz (div 6), ...
<mszyprow|home> wwilly: if you set 200MHz, clock framework will round it down to the nearest possible value -> 166MHz
<wwilly> ah yes ok
<wwilly> so you have only one divider here
<mszyprow|home> wwilly: some paths have more than one divider
<mszyprow|home> wwilly: but there are only integer dividers
<mszyprow|home> wwilly: so it doesn't matter how many of them are there
<wwilly> ... yes
<wwilly> :)
<wwilly> hope there is not a math test for my job after the PhD ah ha
<mszyprow|home> :)
<wwilly> so I test your suggestion about removing regulator-coupled-*
<wwilly> mszyprow|home: if you pop a patch, you mind to add reported-by or something similar? :)
<mszyprow|home> wwilly: of course
<wwilly> thx
<wwilly> I still the report bug mail, than I never sent, do you want me to send it, or you want to find a fix first and use this mail as cover support to your patch?
<mszyprow|home> wwilly: first please check if my assumption is correct, so if increasing the min voltage fixes your issue
<wwilly> with https://pastebin.com/ZymAwbP9, still got the problem of NETDEV WATCHDOG
<wwilly> I put back the stuff and change voltage now
<wwilly> mszyprow|home: with https://pastebin.com/Ka14UriM, still got the problem of NETDEV WATCHDOG
<mszyprow|home> wwilly: okay, could you try to remove the regulator-coupled-* properties then?
<wwilly> mszyprow|home: 2020-05-27-10-14-26 <wwilly> with https://pastebin.com/ZymAwbP9, still got the problem of NETDEV WATCHDOG
<mszyprow|home> hmm, then it looks that this is a different issue then
<mszyprow|home> wwilly: could you check if something such simple as https://pastebin.com/WjvZcrmt fixes it?
<wwilly> ah ha, was just trying something similar
<wwilly> mszyprow|home: https://pastebin.com/T2QPEKYx still the same prob
<mszyprow|home> hmm
<mszyprow|home> could you try adding opp-shared to to fsys2 opp node?
<mszyprow|home> it looks that this property seems to be responsible for the change
<wwilly> mszyprow|home: still the same prob https://pastebin.com/AX0SgydP
<mszyprow|home> I give up, wtf
<wwilly> what about number of entry of diverging in bus_fsys_apb_opp_table and bus_fsys2_opp_table? and the one needed in bus_fsys?
<mszyprow|home> wwilly: one more test: could you get back to https://pastebin.com/raw/UM6Z3XSa but remove the opp-shared prop?
<wwilly> I don't know, I haven't read the code behind, I don't understand it yet
<wwilly> mszyprow|home: https://pastebin.com/6kvK745J still have prob
<mszyprow|home> wwilly: okay, so it looks that enabling the shared-opp and aligning fsys with fsys_apb fixes your issue
<mszyprow|home> good to know
<wwilly> yes
<mszyprow|home> I need to learn the code then
<wwilly> ok
<wwilly> is it maybe because of number of entry as well?
<wwilly> ah ok you don't know the code behind
<wwilly> mszyprow|home: https://pastebin.com/QZFZXPtW seems to be working
<wwilly> I let a bit more running, pinging from to, with ssh and rsync something a bit more to check
<wwilly> but yes, opp-shared and table selection seems to be the prob
<mszyprow|home> wwilly: you may drop the changes to fsys2
<wwilly> uhm?
<wwilly> my change in fsys2 is commented out
<mszyprow|home> indeed
<mszyprow|home> I missed that
<wwilly> :)
<wwilly> pause café pour moi, à plus
<wwilly> mszyprow|home: yes it is working just with https://pastebin.com/QZFZXPtW
<mszyprow|home> wwilly: my last idea to check: https://pastebin.com/8ZUssmzW (without opp-shared, with reduced numer of opps in fsys2 table used also by fsys)
chewitt has joined #linux-exynos
<wwilly> mszyprow|home: https://pastebin.com/RQsc3V4b still got problem
Putti has quit [Read error: Connection reset by peer]
Putti has joined #linux-exynos
<mszyprow|home> wwilly: one more idea: https://pastebin.com/njKtQQBF
<wwilly> mszyprow|home: not better
LiquidAcid has joined #linux-exynos
<mszyprow|home> wwilly: I've checked the code, it doesn't make sense...
<wwilly> mszyprow|home: would you mind to dd your sd card to have the same u-boot? or it could be something about hardware board revision?
<wwilly> ok will have a look
<mszyprow|home> wwilly: precompiled uboot binary is there
Putti has joined #linux-exynos
Putti has quit [Changing host]
genii has joined #linux-exynos
wwilly_ has joined #linux-exynos
wwilly has quit [Ping timeout: 256 seconds]
mszyprow|home has quit [Ping timeout: 260 seconds]
mszyprow|home has joined #linux-exynos
LiquidAcid has quit [Quit: Leaving]
libv has quit [Ping timeout: 246 seconds]
libv has joined #linux-exynos
genii_ has joined #linux-exynos
genii has quit [Ping timeout: 256 seconds]
genii_ is now known as genii
mszyprow|home has quit [Ping timeout: 240 seconds]