svarbanov__ has quit [Read error: Connection reset by peer]
f_ is now known as f_estive
<z3ntu1>
lumag: would you mind checking the last commits for genpd at https://github.com/z3ntu/linux/commits/qcom-msm8974-6.7-wip-cpufreq-clean/ ? I didn't runtime-test it yet, it may be necessary to adjust some remoteproc drivers (adsp, mss, wcnss) to handle the new setup but otherwise I think it should be fine?
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
jhovold has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
z3ntu1, I think it might be better to call dev_pm_domain_detach() instead
<lumag>
then we can use the same code path.
<lumag>
also the mx,cx -> cx,mx change doesn't look 100% correct. I mean, in all the cases we should first bump mx domain (memory), then cx (logic).
<z3ntu1>
lumag: Are you sure APQ8084 devices support voltage-corner on pma8084_s7 (VDDGFX)? Grepping through my 8974 msm-3.4 sources I don't see this defined/used on apq8084, just in msm8974pro-pma8084*.dtsi
<lumag>
z3ntu1, hah. It is S6+S7, see apq8084-regulators.dtsi
<z3ntu1>
also not via voltage-corner or anything, just plain voltage?
svarbanov_ has quit [Read error: Connection reset by peer]
<lumag>
So msm8974pro+pma8084 != apq8084 (from the compat point of view)
<lumag>
z3ntu1, corner
svarbanov_ has joined #linux-msm
<z3ntu1>
so we'd need qcom,msm8974pro-pma8084-rpmpd or something? Or qcom,msm8974-pma8084-rpmpd if we don't want to have the pro in there
<lumag>
yep
<lumag>
Well, we have qcom,msm8974pro
<lumag>
So qcom,msm8974pro-pma8084-rpmpd makes sense
<lumag>
heh. Who would have guessed. CLIDR register is bogus on msm8974.
<lumag>
It tells me that there is L1 Dcache and L2 Dcache + Icache.
<lumag>
Ah, no, it's me being not accurate enough.
<lumag>
ok, L1 DCache + ICache and L2 Unified
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<minecrell>
lumag: Well we could add an intermediary OPP table for MX that translates "performance state" -> "raw voltage". Conceptually a power domain is like a shared regulator where consumers agree on abstract performance levels instead of an exact voltage. If this is the case for MX downstream (i.e. all consumers downstream a fixed amount of voltages that
<minecrell>
could be translated into a level numbering scheme) then IMO it could still fit better as power domain for consistency (even though it would need some extra code)
<z3ntu1>
lumag: no clue about that cache stuff :D is it relevant for anything I'm doing?
<aka_[m]>
Luca Weiss: what is status of audio on fp3?
<minecrell>
"leave MX as is" doesn't work either because we'll need MX "active-only" for cpufreq and the regulator driver doesn't support that
<z3ntu1>
aka_: speaker works with https://github.com/msm8953-mainline/linux/pull/137 but I'd need to resolve audio situation 8953 upstream and then (re)write the amplifier driver to get it upstream, and honestly no time for this right now...
<lumag>
minecrell, on which platform? Do you expect that the regualtors will be switched off?
svarbanov_ has quit [Read error: Connection reset by peer]
<minecrell>
lumag: still talking about 8974/8226
<lumag>
z3ntu1, cacheinfo = device entry point for L2 cahce
<z3ntu1>
aka_: and there doesn't seem to be any effort from other 8953 people to push anything upstream really
<minecrell>
you need to have cpufreq related power domain votes active-only or cpuidle won't work properly
svarbanov_ has joined #linux-msm
<aka_[m]>
Vladimir working on camera
<aka_[m]>
there is prob noone besides him
svarbanov_ has quit [Read error: Connection reset by peer]
<aka_[m]>
and u
<lumag>
aka_[m], and bryanodonoghue
<aka_[m]>
lumag: bryan doing 8953?
svarbanov_ has joined #linux-msm
<lumag>
aka_[m], no :-)
<aka_[m]>
regarding FP3
<aka_[m]>
it looks it uses slimbus for analog
<lumag>
rather being general camera man
<aka_[m]>
which should probably be closer to apq8096 card
<lumag>
minecrell, but cpuidle should be handled by SPM?
<aka_[m]>
on non-psci probably
<aka_[m]>
tho qcom still probably used spm long after
<minecrell>
lumag: in deepest cpuidle mode the SPM does a "handshake" with RPM, which will then drop all "active-only" votes
<lumag>
minecrell, I mean, it already handles PMIC transitions for all the idle states
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
So, if I understand correctly, the SAW / krait / kryo regualtors should handle the active state, but then when the core is going idle, there will be SPM transition, which touches PMIC.
<minecrell>
lumag: If you're running at max cpufreq and the device is idle the power consumption should be similar/better than at min cpufreq, because all the CPU related votes (regulator, power domain, interconnect) are dropped while the CPU is in deep idle
<minecrell>
but that works only if those RPM votes are made with "active-only"
<minecrell>
lumag: yes, the dedicated CPU regulators are handled directly by SPM
<minecrell>
but shared resources are controlled by RPM
<lumag>
minecrell, oh, you mean adding support for QCOM_SMD_RPM_SLEEP_STATE to regulators
<minecrell>
lumag: QCOM_SMD_RPM_ACTIVE_STATE in this case but basically yes :p
<lumag>
minecrell, we are writing ACTIVE_STATE. So we should be programming SLEEP_STATE too?
<lumag>
Maybe konradybcio or bamse have some ideas here
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<minecrell>
lumag: The RPM is a bit funny if you write ACTIVE_STATE only. Then it interprets it as active+sleep. Once you have written SLEEP_STATE for a resource the first time it's then considered separately
<minecrell>
So in other words the regulator driver currently does active+sleep votes always
<minecrell>
while rpmpd supports active-only via the _AO power domain variants
<lumag>
minecrell, we have set_suspend_voltage() and all related stuff.
<minecrell>
lumag: it's not the same, that is for system suspend
<minecrell>
active-only is cpuidle
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
minecrell, well, we can duplicate regulators too, but that sounds like a crazy idea.
<lumag>
Maybe just duplicating MX
<lumag>
will be enough
<minecrell>
lumag: would expect it's at least as complicated/controversial as adding a voltage OPP table for mx in rpmpd, if not more (because you need to "merge" voltages/currents/... for the two regulators which is normally done by the regulator core)
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
Funnier thing: declare _ao as a child of _sleep regulator ;-)
<lumag>
Two possible issues against wrapping regulator in genpd. First one, I fear we can end up with genpd reentrancy issues.
<lumag>
The path genpd -> regulator -> some other devices -> genpd seems quite possible
<minecrell>
lumag: oh no I'm not talking about wrapping. We would just send the voltage directly in rpmpd like it sends corners/levels atm :p
svarbanov_ has quit [Read error: Connection reset by peer]
<minecrell>
but I haven't fully finished investigating if downstream votes for a "dynamic" voltage somewhere, that couldn't be declared in the OPP table
<lumag>
minecrell, interesting hack.
<lumag>
Well, I'd invoke konradybcio here
<lumag>
What about summing the load? I think for RPM regulators we send the mA to RPM, letting it decide the mode.
<lumag>
also it's a bit unclear, where do these values come from.
<minecrell>
lumag: I'd hope the load isn't even used for MX
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
true
<lumag>
I'd still lean to defining MX_SLEEP regulator, but this is probably up to you & maintainers. I agree that MX is a power domain, although it is controlled via the voltage value.
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<minecrell>
lumag: Not completely sure either, but I think having it as power domain would reduce special casing in the consumer drivers
<z3ntu1>
minecrell, lumag : Do you think you can figure out a solution for MX (8974 & 8226 I guess) sometime soon, or should I try to get the single-pd driver changes for remoteproc accepted upstream?
<z3ntu1>
At the very least I want to get the current rpmpd changes upstream so we can build on top and only add MX once that's ready, but converting dts(i) needs to wait until either remoteproc driver is happy with single-pd or we get second power domain for that
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<minecrell>
z3ntu1: it's a bit tricky I guess since if you submit the simple-pd changes we'll never be able to remove them again for DT compat :p
<minecrell>
I think the first step for figuring out what to do about the MX is to create a full list for what and how MX is used downstream on all affected platforms (I hope that's not too many, 8974, 8226 and maybe 8210 I guess?), i.e. which consumers use active-only variant or not, which voltages, is there current/load anywhere
<minecrell>
kinda need this independent of whether it ends up being represented as regulator or power domain
<z3ntu1>
this is what I see in my msm-3.4 tree for 8974:
svarbanov_ has quit [Read error: Connection reset by peer]
<minecrell>
We'll need to look at the driver code to see what they do. Although I'd expect that the remoteprocs basically just need a temporary high state like on the other platforms, which one exactly probably doesn't matter
<minecrell>
so I guess that leaves cpr, which is probably fun
svarbanov_ has quit [Remote host closed the connection]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<minecrell>
cpr on 8610 looks straightforward
svarbanov_ has quit [Read error: Connection reset by peer]
<z3ntu1>
minecrell: yeah so these regulators are only used in cpr (only 8610&8226), mss & wcnss drivers
svarbanov_ has joined #linux-msm
<minecrell>
but ugh CPR is such a mess on 8226, iirc this was one of the reasons I didn't move forward with the patch
<z3ntu1>
would it be a bad idea to worry about cpr later and only focus on remoteproc now? would be shoot ourselves in the foot for later?
<minecrell>
In case of my rpmpd proposal I'd need to prove that we just have a fixed amount of voltages that are being used for MX, which would allow translating them to performance states used by power domains
<minecrell>
In general this seems to be the case
<minecrell>
but there is some funky stuff with voltages for cpr on 8226 that I don't get, in fact some parts of it look fundamentally broken to me so maybe the downstream DT is even wrong...
<z3ntu1>
remind me, cpr is the thing to slightly reduce core voltage where possible without going too low to crash the cpu core?
<aka_[m]>
probably its good when it works
<aka_[m]>
but it ain't
<minecrell>
z3ntu1: yes
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<minecrell>
it's based on a mixture of dynamic monitoring at runtime and calibration values in the fuses
<minecrell>
The voltage table in msm8226-regulator.dtsi doesn't make any sense to me since there are some voltages that are higher than the qcom,vdd-mx-vmax...
<minecrell>
maybe those variants don't actually exist ¯\_(ツ)_/¯
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<z3ntu1>
minecrell: at least 8226 seems to use this thing: VDD_MX_VMIN_APC_CORNER_CEILING:Equal to PVS corner ceiling voltage
<minecrell>
right, which would mean the voltages in qcom,cpr-voltage-ceiling
<minecrell>
which makes sense because mx always must be >= other power domains
<z3ntu1>
Also mss driver sets min=1050000, max=1150000. And wcnss driver has nominal_min=950000, max_voltage=1150000
<minecrell>
and there are some entries in qcom,pvs-voltage-table which have a value larger than 1280000
<z3ntu1>
I don't see any load things in mss driver, wcnss driver has 0 as uA_load in some struct
<aka_[m]>
1.28V?
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<aka_[m]>
even shit like 8976 caps at 1.2
<minecrell>
z3ntu1: that's also kind of funny since I don't see how the max=1150000 works for remoteproc when you boot with max cpufreq...
<minecrell>
argh this is such a mess
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
z3ntu1, for higher frequencies. Have you checked the 8b8d7c57c7a1008073b6c3594788eb9dfb9dde35 from msm-3.10?
<aka_[m]>
im kinda getting lost
<aka_[m]>
is it same like msm8953 gpu situation?
<aka_[m]>
there can be gfx_ldo on 8953 but all my 8953 devices have it fused out
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
<lumag>
heh. I've done the cacheinfo implementation. This almost begs me to go to the office and reattach apq8064 device to the lab (heh, 5 hours before the NY here).
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #linux-msm
svarbanov has quit [Remote host closed the connection]