02:17 <flamingradian[m]> bryanodonoghue: For SDM670 camss, what do you want me to do about cphy_rx_src, vfe0_src, vfe1_src, vfe_lite_src? They need set frequencies, otherwise something can't power on.

02:22 <flamingradian[m]> and the frequencies are set in the driver, in the v1 series

08:36 <krzk> konradybcio: robclark: maybe you know - none of recent platforms like sm8550 or sm8650 have display RSC (SDE_RSCC) in DTS (that's 0x0af20000) responsible for clock and bandwidth votes in display. Downstream has also dedicated driver for this. My questions: why we ignore it completely?

08:37 <krzk> Not needed? Not caring? It's only for power optimization and thus not needed for basic (decent) work?

08:47 <krzk> abhinav__: lumag: ^^ also for you, I missed you are here as well

13:39 <konradybcio> krzk power optimization + keeping display alive with the rest of the soc offline

13:40 <konradybcio> krzk should we use regulator-xyz or xyz-regulator after all?

14:10 <aka_[m]> sgerhold: any chance i can still find you there

14:14 <bryanodonoghue> flamingradian[m] cphy_rx_src is fine to set because AFAIR nothing has it as aparent

14:14 <bryanodonoghue> but the other _src clocks should be parents of the relevant non "_src" names

14:15 <bryanodonoghue> ie. vfe0_src shouldn't appear in your list

14:15 <bryanodonoghue> if you need to set vfe0

14:15 <bryanodonoghue> just have a vfe0 clock and set that

14:15 <flamingradian[m]> ok, I'll try it, thanks!

14:15 <bryanodonoghue> np

15:43 <aka_[m]> lumag: so sgerhold suggested to do firmware detection and clock fallback i kinda have fallback done in place, how weird would be adding clks to apq8016_sbc via devm_clk_bulk_get_optional and if these are not there use set_sysclk and otherwise utilize q6afecc for clock managing?

15:43 <aka_[m]> for now i kinda hacked all required clock enablement in probe but thats not proper management for sure xD

15:47 <aka_[m]> it would be fun tho also have some stub driver supplying q6afecc with current rates by reading lpass_cc region

15:48 <aka_[m]> but thats annoying because we depend on lpass to be up to read region of it

16:22 <steev> lumag: it's not coresight that causes the rcu stalls with ipa on c630; using the defconfig those modules are enabled, and i'm able to boot just fine. it's something else going on

16:22 <steev> well, i'm able to boot with ipa not causeing rcu stalls

16:47 <elder> RCU stalls with IPA on c630?

16:48 <elder> Please at me...

16:50 <steev> elder: using the debian 6.10 kernel, if ipa isn't blacklisted, theres an rcu stall

16:51 <elder> Can you point me at some discussion about it?

16:51 <elder> So I can investigate?

16:51 <elder> What's it doing when the stall occurs? Does it occur on systems without IPA or something?

16:57 <steev> elder: booting. no, i only see them with ipa; it'll also happen if you modprobe ipa after the boot. though it freezes at that point, and while calebccff has debug connected to his, i did not modify mine to do so. fwiw, looking back in my logs of irc on #aarch64-laptops i've seen this issue as far back as 2022 (5.19-rc4?); it's basically only with a heavily modular kernel build like debian does. while i'm using my own patched up debian

16:57 <steev> sources for the kernel, iirc, lumag also saw the rcu stall with just the 6.10 from debian

16:58 <elder> OK. So calebccff can share a log or something, perhaps?

16:58 <elder> I'd really like to investigate.

16:59 <steev> that, i'm not sure - it looks like on 7/25 lumag confirmed he can also see the issue with IPA (in this channel)

16:59 <steev> unfortunately, the c630 is the only device i have with ipa

17:01 <steev> i don't know if caleb has an easy way to test debian on there (and as i said, i don't see it with the defconfig, only with a massively modular config like debian uses)

17:14 <elder> I *do* happen to know about one scenario where there is a race that I reported years ago to Qualcomm, related to an synchronization step handled between the modem and the AP. To fix it, the modem firmware would need to be modified. Qualcomm wasn't keen to fix it. Chrome OS addressed it by building IPA into the kernel I think..

17:15 <steev> i haven't tested that here, but i could

17:26 <calebccff> elder: steev: i can boot a USB drive if you want w/ UART?

17:27 <elder> All I want is a log of some kind, and ideally, a stack trace for where things get stuck

17:27 <calebccff> maybe you can get the same output with `earlycon=efifb,ram keep_bootcon clk_ignore_unused pd_ignore_unused initcall_blacklist=uhhwhateverdisplaydriverstuff`

17:27 <calebccff> e.g. only log to efifb, forever

17:27 <steev> i can try that

17:31 <flamingradian[m]> bryanodonoghue: btw, cphy_rx_src is used by vfeX_cphy_rx, so I can remove cphy_rx_src

17:33 <steev> calebccff: so, adding those... i can't hit it

17:33 <steev> specifically earlycon/keep_bootcon/initcall_bl

17:34 <calebccff> ah :/

17:38 <abhinav__> krzk Hi, RSCC hw is used mainly for power optimization and typically more beneficial for command mode panel cases for idle enter/exit. we have very primitive command mode support in upstream msm driver so far. hence we have not enabled rscc yet. we have a long way to go in terms of improving command mode support.