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?
<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>
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
<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.