<oliv3r[m]>
Anybody know what a S5P 4418 is? (it's an exynos 4 I guess) but it's not really used in a product (other then maybe a nanoPi. Reason for asking, is that the datasheet is actually quite complete, so it may actually give hints on the previous chips (4412 is not that far in terms of numbering) It also appears that the 4418 seems closer related to the 4415; and may be worse then 4412
<oliv3r[m]>
but the datasheet looks interesting
<krzk>
oliv3r[m]: you mean the nexell chip?
<krzk>
oliv3r[m]: it's a different company chip, made by guys either related to Samsung LSI or using their specification
<krzk>
oliv3r[m]: so the documentation and some parts of IP blocks look quite similar, but in general it is different than exynos4
<memeka>
mszyprow: ping
<mszyprow>
memeka: pong
<memeka>
How to set the clocks? I tried using those 2 clocks I use in my patch
<memeka>
But it’s not working
<memeka>
Clk is set to 400
<memeka>
Even with my patch, changing devfreq triggers the code in the patch and clock is set ok, but after a suspend goes back to 400mhz
<memeka>
I tried assign-clocks dout_aclk_g3d, fout_vpll
<memeka>
And assign-parent-clock fout_vpll
<memeka>
Gave an error that cannot assign parent
<mszyprow>
that's a bit strange
<mszyprow>
the assigned-* should work
<mszyprow>
could you show me the properties you have tried?
<oliv3r[m]>
krzk: ah that explains; still is it reasonable to asume, that nexcell was the basis for s5pv110 (exynos 3)? E.g. samsung bought nexcell? I'm just supprised by the datasheet date; 2014
<oliv3r[m]>
if this is the case, it's not far fetched to think that some IP is simply re-used; especially the 'in house developed' blocks
<oliv3r[m]>
so the datasheet, still contains potentially interesting and useful information I recon?
<mszyprow>
memeka: does this suspend/resume 400mhz issue happen with the odroidxu4-5.4-y branch from your public git with exynos_defconfig? If so, I can easily check it
<memeka>
mszyprow: the config is very close to exynos_defconfig, just a bit trimmed (eg remove exynos3/4, chrome hardware, some wifi etc)
<mszyprow>
memeka: let me check it
<memeka>
Mali is arm not panfrost, but you don’t need binary driver, just play with devfreq0 governor (simple_ondemand and performance) and check clocks to see g3d is 177/600 MHz
<memeka>
Then sleep and g3d/fout_vpll is 400mhz
<krzk>
oliv3r[m]: no, the Nexel chips are quite recent, they are newer than S5Pv210... they appeared around 2016, I think
<krzk>
oliv3r[m]: I doubt that the datasheet will contain anything useful for Exynos. It is only for Nexell.
<mszyprow>
oliv3r[m]: there are some ip blocks common like uart or i2c, but docs for them are already public afair
<oliv3r[m]>
that is sad; I saw some pmu registers and stuff that appeared to align quite nicely; the PMU stuff is all missing from the 4210 and 4412 datasheets I have found
<oliv3r[m]>
I'm currently trying to decipher the iROM of a 4412 (for the learning experience) and I found a few mistery bits/registers, so anything that could give some information would be usefull
<oliv3r[m]>
I have a feeling of course what some bits and parts could potentially be doing
<oliv3r[m]>
one thing that seemed interesting (before the mmc boot option was not discovered) was to potentially load u-boot-spl in the sram, and set the resume SRAM pointer to it; but alas, the decrpyption bit is in the way there :) (but only due to a flag it seems, it jumps without decrpting anything)
<mszyprow>
memeka: I hope I will check it later today
<memeka>
mszyprow: thx
<mszyprow>
memeka: fixed
<memeka>
mszyprow: that was fast!
<mszyprow>
memeka: well, it turned out to be the first thing I've checked
<mszyprow>
memeka: I'm still surprised that most PLLs were reset to default values during suspend/resume cycle and noone noticed that
<memeka>
mszyprow: one more thing
<mszyprow>
memeka: but maybe this was related to the fact that suspend/resume was broken for so long
<memeka>
mszyprow: is there a way to set mali_clk instead if the aclk_g3d and vpll?
<mszyprow>
yes, all the clocks in the path needs to have CLK_SET_RATE_PARENT flag set
<memeka>
mszyprow: yeah suspend didn’t really work until recently so no surprise there :) it’s the first time I’m really testing it, and if some .config stuff changes then suspend stops working (2W usage in suspend and never return to life)
<mszyprow>
memeka: if you have such config which breaks suspend, send it to me
<memeka>
mszyprow: all the clocks in the path (there are 5-6 of them i think), or just those 2?
<mszyprow>
memeka: all until the PLL
<mszyprow>
memeka: for example EPLL (audio path) clocks already have this flag
<memeka>
mszyprow: thx will try that Monday; also will send .config when I change it, I think I erased the broken ones :D
<memeka>
Thx again
<mszyprow>
memeka: but indeed, it would make sense to add CLK_SET_RATE_PARENT flag to all clocks on this path: mout_sclk_vpll -> mout_aclk_g3d -> dout_aclk_g3d -> mout_sw_aclk_g3d -> mout_user_aclk_g3d -> g3d
<memeka>
Yup those ones
<mszyprow>
so mali driver will change the rate of the vpll
<mszyprow>
memeka: done, tested, works even after reverting your "mali/midgard: devfreq: fix clk_set_rate for Odroid XU3/4" workaround
<mszyprow>
memeka: btw, it would really make sense to properly send your 'clk: samsung: exynos5420: add VPLL rate table' patch to mainline
<mszyprow>
memeka: as the rest of the fixes somehow rely on it