ChanServ changed the topic of #msm8937-mainline to: Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline | Bridged to #msm8937-mainline:kde.org on Matrix
lanik123[m] has joined #msm8937-mainline
<lanik123[m]> <barni2000[m]> "maybe for gpu we can also..." <- Msm8937 can't use iommu driver on gpu because it doesn't have static context bank
<barni2000[m]> ik, but we don't need smmu and iommu works fine together now
<barni2000[m]> * ik but we don't need, smmu and iommu works fine together now
<barni2000[m]> <lanik123[m]> "Msm8937 can't use iommu driver..." <- 1 line difference in downstream binding between 8937 and 8953 everything else is same. `qcom,enable-static-cb`
<barni2000[m]> after i have added montana and rolex i will update the kernel in pmos
<lanik123[m]> <barni2000[m]> "this is how it look like now..." <- Yeah, I've seen it. Very cool that they allow 2 different mmu drivers to be created on 1 bus. For SoCs like msm8937 it's very good news
<barni2000[m]> yes, vladly was tell me when i asked him about smmu stuff
<lanik123[m]> barni2000[m]: Did you do something with msm8937 problem where second cluster using sr2 pll instead of hfpll?
<barni2000[m]> lk2nd initializes the 2nd cluster
<barni2000[m]> It is similar like 8939
<barni2000[m]> 8956 uses hfpll
<barni2000[m]> i am thinking about add initialization part to a53pll later to be able to use without lk2nd
<barni2000[m]> i don't mind using lk2nd but maybe it will be a blocker in upstreaming process idk
<barni2000[m]> after 8937 and 8940 sdm439 will be the next
<lanik123[m]> <barni2000[m]> "https://github.com/msm89x7-..."; <- This node has a problem because a53pll cannot initialize hfpll in c1. a53pll can only be used for sr2pll. I don't mind why msm8939 used it on its own second cluster, but qcom in the upstream kernel identifies c1 as hf pll https://github.com/Lanik123/msm-4.19/blob/sdm439-playground/drivers/clk/qcom/clk-cpu-sdm.c#L404
<barni2000[m]> 4.9 three don't have this
<barni2000[m]> s/three/tree/
<lanik123[m]> lanik123[m]: I don't remember if I wrote here or not, but I tried changing the init from sr2 to hfpll on c1 and it worked. But after that I had problems with incorrect frequencies tables xd
<barni2000[m]> btw cpufreq is working fine on 8937 and 8940 so it is fine with a53pll
<lanik123[m]> barni2000[m]: I understand and I don't disagree everything works fine, but it seems to me that moving the c1 init to lk2nd is a very big workaround
<lanik123[m]> barni2000[m]: It's incorrect to see cpu clk only in the clock-cpu driver in 4.9 because it only contains mux clks
<barni2000[m]> init can be added for mainline driver ig but same was done for 8939 by 8916 guys
<barni2000[m]> 8952 gcc contains msm8956 bits
<lanik123[m]> lanik123[m]: As you can see, c1's init is sr2 but vdds are used from hfpll. This is because qcom are very lazy and they didn't implement separate logic for hfpll xd
<barni2000[m]> 8956 c1 is hfpll
<lanik123[m]> barni2000[m]: Yes, msm8952 (msm8937 and msm8940 also) c1 is also hfpll
<lanik123[m]> lanik123[m]: And I don't quite understand why everyone initializes it's via sr2 and later says "Oh, my second cluster is broken..."
<barni2000[m]> 2nd cluster is working fine
<lanik123[m]> barni2000[m]: Only with lk2nd where you override sr2 bits on second cluster
<barni2000[m]> but i am not sure i need to init both cluster btw
<lanik123[m]> * sr2 bits to hfpll on second
<barni2000[m]> lanik123[m]: oh yeah but same can be done in mainline driver
<barni2000[m]> pmos package has lk2nd as hard dependency because of extlinux so no worries
<barni2000[m]> for upstreaming i will disable cpufreq ig
<barni2000[m]> what do you know about psci?
<barni2000[m]> it is broken on 89x7
<lanik123[m]> barni2000[m]: I'll present changes for this (with a normal hfpll driver) and for cpr for 89x7 a bit later, but I'm not promising anything. I have almost no free time right now because of work (thanks to Sid_key)
<lanik123[m]> barni2000[m]: It's broken on all SoCs similar to msm8952 due to fw cranks, isn't it?
<barni2000[m]> yes ig
<barni2000[m]> 1 commit revert can be fixes it ig
<barni2000[m]> yep
<barni2000[m]> so osi mode should be enabled befor pm domains are defined for msm8952 like devices
<lanik123[m]> <lanik123[m]> "This one https://github.com/..."; <- LoL, old kernels use psci-0.2 as psci-1.0
<lanik123[m]> Maybe we can use arm,psci-0.2 instead of arm,psci-1.0
<barni2000[m]> yes i have tried psci-0.2 also and backtraces are disappear but pmdomains are still timeouting
<barni2000[m]> mainline doing psci-0.2 init with 1.0 init also
<barni2000[m]> there is no too much difference between them
<barni2000[m]> ig it should be downgraded to 0.2 then
<barni2000[m]> oh yeah riva also have goodix variant
<barni2000[m]> touch selection should be added for panel selection later
nationpwned[m] is now known as right_front[m]