ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<z3ntu1> lumag: is there any news on this apq8064 cpufreq series? https://lore.kernel.org/linux-arm-msm/20231002185940.1271800-1-dmitry.baryshkov@linaro.org/T/ I think a part of that would be quite useful for msm8974 also
Caterpillar has quit [Quit: Konversation terminated!]
f_ has quit [Ping timeout: 480 seconds]
Caterpillar has joined #linux-msm
<lumag> z3ntu1, no. I didn't have time for reworking the cache part. First I have to finish the cacheinfo part.
<lumag> msm8974 was indeed the next goal after 8064.
<z3ntu1> Okay, maybe I'll send an initial version for msm8974 without l2 scaling, seems to be stable enough ™️
<z3ntu1> (or at least as long as I don't go to the higher 2.26GHz-2.45GHz frequencies, there something seems to be missing since the device is crashing a bit randomly..)
f_ has joined #linux-msm
<z3ntu1> Anybody have a link for downstream qcs404 sources?
<aka_[m]> msm-4.14 i believe
<z3ntu1> aka_: thanks
<lumag> z3ntu1, If I remember correctly, msm8974 requires the krait regulator for cores / etc.
<lumag> SAW2 changes were reviewed except 04/11, so maybe bamse (or konradybcio) can comment here.
<z3ntu1> qcom,hfpll and qcom,krait-cc-v2 and hooking up everything appear to be enough for the most part
<z3ntu1> definitely not complete though
<lumag> z3ntu1, see arch/arm/mach-msm/krait-regulator.c in msm-3.10
<z3ntu1> yeah that's missing in my changes so far
<z3ntu1> same with l2 scaling, and probably some other stuff I'm not really aware of
<f_> aka_[m]: I didn't know this channel was logged
<f_> it wasn't mentionned in the channel topic?
<f_> In fact, the channel topic contains nothing...hmm
<lumag> I checked the db8074 schematics. pm8841 supplies s5/s6/s7/s8 as a gang to the apq8074 as a VDD_APCC_n. krait-regulator performs switching for the phases.
f_[mtrx] has joined #linux-msm
<lumag> Note, that apq8084 and msm8974pro have slightly different settings there.
<lumag> z3ntu1, interesting. So s5-s8 are controlled through SPM, but there is also a separate special handling for PFM<->PFM transitions (krait-regulator-pmic.c)
<z3ntu1> lumag: see https://github.com/z3ntu/linux/commits/qcom-msm8974-6.7-wip-cpufreq-clean what I have now, seems to work stable on one msm8974pro device I'm testing on
<z3ntu1> Will test on my collection of 8974 devices also soonish
<lumag> z3ntu1, I can try testing that on apq8074.
<lumag> btw, are the tables only targeting the msm8974pro or msm8974 too?
<z3ntu1> I think it should be okay for both but can't recall what I did when I made this table
<z3ntu1> lumag: At some point I scripted the generation of this giant list of values: https://github.com/z3ntu/linux/commit/7d724997677750f393dde663a9eb965c82708a6a
<lumag> heh
<konradybcio> Luca Weiss: im not reviewing that :)
<z3ntu1> this is the script in case it might be useful to anyone https://git.sr.ht/~z3ntu/linux-cpufreq-converter/tree
<lumag> z3ntu1, interesting, the cpufreq tables are the same for all variants, including pro
<z3ntu1> damn I wrote that script 2 years ago, time flies
<konradybcio> lumag: i would guesstimate that it's down to the soc revision?
<lumag> konradybcio, ?
<konradybcio> Please remind me.. are 8974pro revisions mirroring 8974ac?
<konradybcio> Or.. 8974ab? I.. don't know..
<lumag> z3ntu1, for hfpll we might need separate compat entry (pls check against qcs404)
<z3ntu1> lumag: I checked https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/LE.UM.4.2.1.c25/drivers/clk/qcom/clk-cpu-qcs405.c?ref_type=heads#L714 and that's a completely different value compared to mainline (at least to my eyes)
<z3ntu1> konradybcio: 8974 = Snapdragon 800
<z3ntu1> konradybcio: 8974pro = Snapdragon 801 = 8974ab-{aa,ab,ac}
<lumag> z3ntu1, that's user_val (see also user_vco_mask)
<lumag> and config seems to be retained from the bootloader.
<lumag> So you will need a separate compat for 8974 (a good idea anyway)
<aka_[m]> user_val 99% of time is just ouputs
<aka_[m]> sometimes fractional enable
<aka_[m]> vco mask bit 21
<aka_[m]> one could add vco_table to clk driver
<z3ntu1> lumag: right, damn this variable naming, downstream .config_reg = 0x10, and mainline .config_reg = 0x14,
<lumag> :-)
<z3ntu1> lumag: but what do you mean is different for 8974 apart from what I changed in https://github.com/z3ntu/linux/commit/bc1fdc8f6cf219c4f5b3da022e27b7f024104444 ?
<lumag> they might be different. Please doublecheck them
<lumag> z3ntu1, exactly that change
<lumag> I'm not sure how that affects qcs404
<z3ntu1> tbh I've got no clue where this value comes from, the commit adding the driver https://github.com/z3ntu/linux/commit/cb546b797a0da4dbb1a0c76a2a357921887b6189 mentions MSM8974 only but I can't find any trace of this value ever being used in msm8974 downstream
<z3ntu1> in 2012 it was set to the value I see in all my downstream trees https://github.com/LineageOS/android_kernel_fairphone_msm8974/commit/a77b7f30f3c8a810eee3627dd22b76de36929fab
<aka_[m]> PLL_CONFIG_CTL RESET_VALUE 0x04D0405D
<lumag> z3ntu1, yep
<z3ntu1> lumag: but yeah not touching qcs404 is probably a good idea, the folks over there need to figure out what they want
<lumag> But currently "qcom,hfpll" is used for qcs404
<lumag> :-)
<z3ntu1> (which is also a bad idea :P)
<lumag> Other than that looks good to me.
<z3ntu1> shall we give that one also a proper compatible?
<lumag> qcom,hfpll-config-val = <0x04D0405D>;
<lumag> qcom,hfpll-user-vco-mask = <0x00100000>;
<z3ntu1> aka_: yes for msm8974pro the value was moved to dt, msm8974-original has it in .c only
<aka_[m]> ah qcs
<aka_[m]> thing noone even test on anymore
<lumag> z3ntu1, interesting. We might need to switch 8841 regulators to be controlled as power domains instead
<lumag> because L2 is controlled via the s2_corner_ao
<lumag> = rpmpd
<lumag> L2 voltage
<z3ntu1> oh, seems 8974 still has no rpmpd upstream, I made some patches at some point but it was quite unclear what should actually be modelled as power domain and what not
<z3ntu1> and it actually even includes pm8841_s2 :)
<z3ntu1> mal: ^ msm8974 power domain fun ;)
<z3ntu1> lumag: if you know what should be a pd there, please finish up my patch, I really got stuck there deciding what should be what, and what would even work the way rpmpd works
<lumag> z3ntu1, I think this is correct
<lumag> And GFX too
<z3ntu1> yeah VDDGFX hasn't been added to the array, just the other part is added
<lumag> z3ntu1, more important, adsp and mss should be converted to domains
<z3ntu1> lumag: One thing to look out for with 8974 is also that some devices use pma8084 pmic instead of pm8841/pm8941
<z3ntu1> not sure how much that's relevant for rpmpd
<lumag> It is, because gfx becomes s7 IIUC
<konradybcio> Luca Weiss: i think i had a patch for it years ago
<z3ntu1> vdd-gfx-supply = <&pma8084_s7_floor_corner>;
<minecrell> z3ntu1: imo VDD_MX should also be a power domain for consistency with newer platforms. It needs some fun/thoughts though since downstream still uses it with raw voltages (not sure if it maybe actually accepts corners too)
<z3ntu1> minecrell: yeah I think that was the point why I stopped looking into this :P
<konradybcio> let's only keep what rpm exports in rpmpd..
<minecrell> konradybcio: well this is meaningless since for RPM there are just regulators
<minecrell> smd-regulator and rpmpd use the same interface
<minecrell> it was just decided that modelling the "corners" as power domains is better suited than hacking this into the regulator core (which is probably reasonable)
<minecrell> also, as I mentioned somewhere before VDD_MX as regulator on 8974/8226 doesn't work either because smd-regulator doesn't support "active-only", only rpmpd does
<mal> that affects the modem and wcnss patches for msm8226 which I have waiting for decision what to do with that one regulator
<z3ntu1> lumag: so for pma8084 we'd need CX = (.., SMPA, CORNER, 2); and GFX = (..., SMPA, CORNER, 7)? And then two different rpmpd compatibles, one I guess msm8974-pm8841 and one msm8974-pma8084 one? Or do you think there's some other way to do this?
<z3ntu1> and if somebody implements whatever MX would need, it's SMPB+1 for pm8841; and SMPB+1 for pma8084
<z3ntu1> s/SMPB/SMPA/
<lumag> z3ntu1, yes. Maybe it is easier to use msm8974 for pm8941 and apq8084 for pma8084.
<lumag> For MX I'm not sure we can do that. In the end, I think, we send voltage indices for regulators and 'performance values' for corners.
<lumag> So it's easier to leave MX as is
telent has quit [Quit: The Lounge - https://thelounge.chat]
telent has joined #linux-msm
<z3ntu1> But for the phones with msm8974pro+pma8084 they'd overwrite rpmpd compatible in the dts to apq8084-rpmpd then?
<z3ntu1> lumag: At least samsung-klte uses pma8084
<lumag> z3ntu1, yes
<lumag> Another option might be to define qcom,pm8941-rpmpd and qcom,pma8084-rpmpd
<z3ntu1> lumag That would make a tiny bit more sense but not sure how good it is to deviate from the current naming scheme
<lumag> konradybcio, krzk: your opinion ^^
<konradybcio> Hmm i think neither are great.. it comes down to a soc+pmic combo
<lumag> konradybcio, so, qcom,msm8974-pm8841-rpmpd, qcom,msm8974-pma8084-rpmpd and qcom,apq8084-rpmpd (same as msm8974-pma8084)?
<konradybcio> I think in this case we can just use msm8974 and apq8084, but e.g. 8909 shipped with like 3 or 4 different sets of pmics
<z3ntu1> konradybcio: so you're saying msm8974+pma8084 should use qcom,apq8084-rpmpd compatible?
<z3ntu1> and msm8974+pm8841/pm8941 should use qcom,msm8974-rpmpd?
<konradybcio> yes i think that's the best way to solve this case
<konradybcio> Maybe 8974pro could get a fallback
<konradybcio> 8974pro, 8084
<lumag> 8974pro used both
<lumag> s/both/either of them