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
<NekoCWD[m]> <ValPackett[m]> "huh? i never had to do that..." <- There is 8937 on prada
<semf[m]> stk3x1x isnt in mainline so no light/proximity for ugg\
<semf[m]> eee
<semf[m]> where to find i^2c gpio pins in dt
<barni2000[m]> <semf[m]> "stk3x1x isnt in mainline so no..." <- It is mainlined
<barni2000[m]> stk3310 stk3311 etc
<barni2000[m]> No matter which compatible you use it will work
<barni2000[m]> It is compatible with all register compatible variant driver will log if the device id is unknown
<semf[m]> oh
<semf[m]> oop
<barni2000[m]> 6.13 update finally merged so audio stuff will be available soon in the repo
<semf[m]> neat
<semf[m]> was waiting for merge so i could build my branch
<barni2000[m]> If someone have device with speak through headphone out and have little time. could have investigate why the noises in headphone out. it causes static noise when no pcm available and on switching. This is only issue with headphone out so issue will be in the driver somewhere
<barni2000[m]> * If someone have device with speak through headphone out and have little time. They could investigate why the noises in headphone out. it causes static noise when no pcm available and on switching. This is only issue with headphone out so issue will be in the driver somewhere
<barni2000[m]> * If someone have device with speak through headphone out and have little time. They could investigate why the noises in headphone out. There are static noise when no pcm available and pop noises on switching. This is only issue with headphone out so issue will be in the driver somewhere
<barni2000[m]> why we have got `unexpected rsp message for` `ASM_DATA_CMD_READ_V2 0x00010DAC` and `ASM_DATA_CMD_WRITE_V2 0x00010DAB`?
<barni2000[m]> I am checking the downstream code but i don't see them at `BASIC_RSP_RESULT` handling, upstream throw this message there.
<barni2000[m]> Maybe this is related
<barni2000[m]> the two opcode is implemented at upstream in q6asm.c so i guess wrong BASIC_RSP_RESULT handling could cause these messages
<barni2000[m]> Val Packett: i have forgot to tell at psci fix review cluster name was asked to be named like this `cluster_sleep_0: cluster-sleep-0 {`
Daanct12 has joined #msm8937-mainline
Danct12 has quit [Read error: Connection reset by peer]
<barni2000[m]> was cluster_gdhs is necessary for psci fix?
<barni2000[m]> as far as i know none of the SoCs are defining it at upstream
<ValPackett[m]> ok i'll rename it, coincidentally i'm trying to measure and tune power usage rn
<ValPackett[m]> msm8916 uses it cluster_pwrdn: cluster-gdhs
<barni2000[m]> there were some useful information about it on the mail list i will search for it
<ValPackett[m]> i've just found https://lkml.iu.edu/hypermail/linux/kernel/1906.0/02754.html for the latencies
<ValPackett[m]> but min-residency-us was clearly way too low everywhere and msm8916 seems to just pull out 2000/6000 of nowhere as some kind of "reasonable" value ig
<barni2000[m]> 2. Omit cluster-sleep-0 and cluster-sleep-1. I doubt anyone will notice
<barni2000[m]> the minor difference in power consumption. The most important idle
<barni2000[m]> state is the deepest "power collapse" (PC) state.
<barni2000[m]> cpr is the most important for power saving
<ValPackett[m]> if we just try to PC the cluster on 8917 (the only cluster → whole system) it never wakes up lol
<barni2000[m]> sad
<barni2000[m]> ok in that case naming should be fixed
<barni2000[m]> btw fg will be broken by suspend
<ValPackett[m]> well, sad- we need to investigate more. idk at all how exactly waking up from the deepest whole system collapse works
<ValPackett[m]> hmmm how exactly broken?
<barni2000[m]> are you using dpi?
<barni2000[m]> * are you using dpu?
<ValPackett[m]> dpu?
<barni2000[m]> msm.prefer_mdp5=false
<ValPackett[m]> never touched that
<ValPackett[m]> so far i'm just trying to get cpuidle to actually reduce battery drain and not increase it lol
<barni2000[m]> maybe saw also needed idk
<barni2000[m]> * maybe `saw, * saw` also
<ValPackett[m]> barni2000[m]: even on 8916 those are just `status = "reserved"; /* Controlled by PSCI firmware */`
<barni2000[m]> it seems psci is working on 8940 with force
<ValPackett[m]> OK finally can confirm an improvement, 0.68 discharge rate with no idle states → 0.59 with just cpu pc
<barni2000[m]> what is needed for sleep CONFIG_SUSPEND?
<ValPackett[m]> no idea, wanted to ask you :D
<barni2000[m]> let me check in msm8953 config
<barni2000[m]> ig SUSPEND is enough
<barni2000[m]> it seems it recompiles everything :(
<ValPackett[m]> aaand adding `cluster_ret` screws it up with 0.9 rate —actually— this isn't really what it's supposed to be, where did `0x41000033` come from, there was no `qcom,psci-mode = <3>;` for the cluster
<barni2000[m]> it is explained somewhere in the reviews
<ValPackett[m]> in the reviews it's actually correct 0x41000023 heh
<barni2000[m]> <barni2000[m]> "https://lore.kernel.org/all/..."; <- this
<ValPackett[m]> yea. i think i screwed up somehow, that 3 wasn't anywhere else oops
<ValPackett[m]> oh oops it freezes with 0x41000023
<ValPackett[m]> did they.......... mark cluster retention as worse than cluster pwdn/gdhs so that their algorithm would never pick it because it's broken??? 0.o
<barni2000[m]> maybe it was just defined because algorithm search for it but it is not using it
<barni2000[m]> suspend is working fine on 8940
<barni2000[m]> what is the difference for original state?
<barni2000[m]> i should check it on 8937
<barni2000[m]> maybe 8917 also should work
<ValPackett[m]> okaay let me rebuild with config suspend
<barni2000[m]> you should use dpu because mdp5 is broken
<barni2000[m]> it is blocking 2nd suspend
<barni2000[m]> 8937 also works
<ValPackett[m]> hm, success: 3 even with mdp5