<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.
<flamingradian[m]>
and the frequencies are set in the driver, in the v1 series
jhugo has quit [Quit: Connection closed for inactivity]
<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?
<krzk>
Not needed? Not caring? It's only for power optimization and thus not needed for basic (decent) work?
<krzk>
abhinav__: lumag: ^^ also for you, I missed you are here as well
<konradybcio>
krzk power optimization + keeping display alive with the rest of the soc offline
<konradybcio>
krzk should we use regulator-xyz or xyz-regulator after all?
<aka_[m]>
sgerhold: any chance i can still find you there
<bryanodonoghue>
flamingradian[m] cphy_rx_src is fine to set because AFAIR nothing has it as aparent
<bryanodonoghue>
but the other _src clocks should be parents of the relevant non "_src" names
<bryanodonoghue>
ie. vfe0_src shouldn't appear in your list
<bryanodonoghue>
if you need to set vfe0
<bryanodonoghue>
just have a vfe0 clock and set that
<flamingradian[m]>
ok, I'll try it, thanks!
<bryanodonoghue>
np
linusw has quit [Quit: Connection closed for inactivity]
<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?
<aka_[m]>
for now i kinda hacked all required clock enablement in probe but thats not proper management for sure xD
<aka_[m]>
it would be fun tho also have some stub driver supplying q6afecc with current rates by reading lpass_cc region
<aka_[m]>
but thats annoying because we depend on lpass to be up to read region of it
<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
<steev>
well, i'm able to boot with ipa not causeing rcu stalls
<elder>
RCU stalls with IPA on c630?
<elder>
Please at me...
<steev>
elder: using the debian 6.10 kernel, if ipa isn't blacklisted, theres an rcu stall
<elder>
Can you point me at some discussion about it?
<elder>
So I can investigate?
<elder>
What's it doing when the stall occurs? Does it occur on systems without IPA or something?
<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
<steev>
sources for the kernel, iirc, lumag also saw the rcu stall with just the 6.10 from debian
<elder>
OK. So calebccff can share a log or something, perhaps?
<elder>
I'd really like to investigate.
<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)
<steev>
unfortunately, the c630 is the only device i have with ipa
<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)
<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..
<steev>
i haven't tested that here, but i could
srinik has joined #linux-msm
<calebccff>
elder: steev: i can boot a USB drive if you want w/ UART?
<elder>
All I want is a log of some kind, and ideally, a stack trace for where things get stuck
<calebccff>
maybe you can get the same output with `earlycon=efifb,ram keep_bootcon clk_ignore_unused pd_ignore_unused initcall_blacklist=uhhwhateverdisplaydriverstuff`
<calebccff>
e.g. only log to efifb, forever
<steev>
i can try that
<flamingradian[m]>
bryanodonoghue: btw, cphy_rx_src is used by vfeX_cphy_rx, so I can remove cphy_rx_src
<steev>
calebccff: so, adding those... i can't hit it
<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.