05:12 <mani_s> konradybcio, yes

05:12 <mani_s> because our SoCs support L1 and it works without issues with other drives

10:51 <warpme> guys: i just updated mainline 6.18-rc5 to 6.18-rc6 on qcs6490 board and....boot hangs like this https://gist.github.com/warpme/f1c167d34fbcc46977ac5e2358fbc8c1 Only change is kernel r5->rc6 Is this known regression?

12:22 <konradybcio> warpme: please add `earlycon` to cmdline

12:22 <konradybcio> sorry no, keep_bootcon

12:43 <warpme> @konradybcio : oh you know: if only change of rc5->rc6 breaks device booting then - for me - this is pure regression

12:45 <warpme> i'm not sure about: what will be most efficient deal with this.... Alwas I can imply wait for rc7 with hope it will magically resolved....

12:45 <konradybcio> your logs stop at the time of "proper" console driver kicking in (which disables earlycon, which the cmdline addition I suggested would prevent) and getting logs from that crash would surely help in resolving that!

12:45 <konradybcio> alternatively you can use git bisect to find the offending commit

12:47 <warpme> indeed - console related changes was my first thought. but - afaik - there was no changes in this area between rc5 and rc6 - isn't ?

12:57 <warpme> when i comparing with working rc5 i see next to last failing line (legacy bootconsole [qcom_geni0] disabled) is rcu stuff. so maybe thing is related to https://www.phoronix.com/news/Linux-6.18-ARM64-Atomics-Issue ?

19:32 <valpackett> for me, audio broke in next-20251118 (fine in next-20251114) 0.o

19:34 <valpackett> btw, as travmurav said that only sc7180 ever had properly deep sleep upstream, i went to read the commits related to that soc..

19:35 <valpackett> didn't find anything extraordinary but found that only sc7180 and 7280 have `.pm = &snd_soc_pm_ops` set in sound/soc/qcom

19:35 <valpackett> setting that doesn't seem to break anything on hamoa (on top of next-20251114..)

19:43 <valpackett> also camcc-sc7180.c is the only camcc with runtime pm ops (and according to pm_genpd_summary, camcc is holding up mmcx..)

21:14 <valpackett> there seems to have been some power usage regression (?) i get 4.2W on next-20251003 and 5W on next-20251114 (screen-on idle)

21:15 <valpackett> (both with aspm force) what's weird is that diffing the aspm related lspci output there's a lil difference *only* on the first (wifi) root port

21:15 <valpackett> new: ClockPM- Surprise+ LLActRep+ BwNot+ ASPMOptComp+ old: ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp+

21:15 <valpackett> wtf is Surprise even??

21:19 <valpackett> Surprise Down Error Reporting, apparently

22:06 <valpackett> also a really weird thing on this kernel is that CPU power domains show up as if always stuck in sleep lol

22:43 <valpackett> oh it is actually 'failed to register cpuidle driver'

23:28 <valpackett> oh ffs, it's the third time I've debugged a regression introduced by someone from Intel :D

23:29 <valpackett> cpuidle: state 1: exit latency 680000 > target residency 600000 → driver rejected

23:29 <valpackett> 76934e495cdc "cpuidle: Add sanity check for exit latency and target residency"

23:35 <mmediouni[m]> Random hexagon question: where's the DMA documentation and is there anything regarding the v1 DMA descriptors that isn't supported on v68? Currently backporting some code back to that and the HW choked on the DMA descriptors I gave

23:35 <mmediouni[m]> Or should I rather use the v0 descriptors there?

23:36 <mmediouni[m]> And if this isn't the right place to ask, where should I ask?