04:28 <ValPackett[m]> wooo got cpu idle working. basically copying the entire msm8953 setup. force psci domains patch is required but then also the cluster states before cluster power collapse (hmmmm)

04:34 <ValPackett[m]> (are we just not getting to that last level?)

04:46 <ValPackett[m]> msm8916 doesn't do cluster power collapse, maybe it's like "dont do it with only 1 cluster"

04:51 <ValPackett[m]> so interesting. downstream msm8953-pm.dtsi vs msm8917-pm.dtsi.. somehow the 8917 has cluster gdhs ahead of retention, with a larger latency specified for retention??

04:53 <ValPackett[m]> <ValPackett[m]> "msm8916 doesn't do cluster power..." <- right `qcom,notify-rpm` is what system-pc has on a multi cluster soc and cluster-pc on a single cluster, that must be the thingy that wakes it up from "everything is asleep"

05:04 <travmurav[m]> fwiw I don't exactly remember how it works but on 8916 "generation" there are SPM for each cpu, cluster and inter-cluster icc, if present, and they'd collapse their own things + if they got fully collapsed, notify... (full message at <https://matrix.org/oftc/media/v1/media/download/AYT52n5efPrGed_DADS48TuSXlYBQkyxF_6OpwMc9nq7kcn7EYs9YVMTE-Ad_pWTl7RIwM_Q8T6p-YgTjrMo3iVCeVB_53eAAG1hdHJpeC5vcmcvVFJrd21XUW1meUNHWEpTeE56WXRjaFRD>)

05:04 <travmurav[m]> so there will probably be different handling in having icc or not

05:06 <travmurav[m]> but also I recommend making sure to measure power when you test suspend, 8916 """"updated psci firmware"""" would actually jump power usage up from runtime idle if you vote all resources off properly before going into suspend xD

05:07 <travmurav[m]> I guess cpuidle shouldn't be as bad

05:09 <travmurav[m]> but fwiw on 8916 for cpuidle states they directly swap in SPM state machine code to change the behavior of wfi

05:09 <travmurav[m]> not sure when did they move away from that to psci and to what extent

05:22 <ValPackett[m]> travmuravthanks for the info, any tips on measuring the power usage?

05:22 <ValPackett[m]> btw while you're here, any thoughts on `include <motorola-carrier-channel-ids.dtsi>` in the common `msm89xx-mtp` ADTBs?

05:22 <ValPackett[m]> (see msgs above)

05:23 <travmurav[m]> measuring power -> probably want something like multimeter/current meter on the battery terminals to know your changes actually bring the power down (if your fuelgauge reports power measurement, thats good enough too)

05:24 <travmurav[m]> wrt carrier ids -> if some dtb in lk2nd needs it (contains a device that needs it) then it's completely fine to add the include with ids, but mass add I'd like to avoid

05:26 <travmurav[m]> so if you need to add it for something, feel free to make a pr (though I didn't have time to sift through those for a while now, hope I can get to the backlog soon)

05:30 <ValPackett[m]> seems like all the 89x7 motos need it so it'd be msm8917-mtp (nora), msm8920-mtp (nora&jeter), msm8937-mtp (cedric&hannah&montana&jeter)

16:35 <NekoCWD[m]> Hehe. Camera on agassi (actually testing wireless display app from fossdem :D)

16:49 <NekoCWD[m]> MirrorHall on agassi