10:42 <z3ntu> How can it be handled sanely in driver/dts that camcc driver, touching any clocks requires turning on power domain, otherwise clock will be stuck on off? One solution is of course to just dump `power-domains = <&camcc TITAN_TOP_GDSC>;` anywhere a camcc clock gets used or is there a better solution than this?

10:42 <z3ntu> (cc konradybcio)

10:43 <z3ntu> I guess if all clocks are off then also power-domain can be turned off but otherwise probably needs to stay on. Adding this power-domains on camcc node itself probably doesn't work due to circular dependency? And would also force it to be always on?

11:01 <z3ntu> Ah and actually this power domain I think requires a clock from gcc to be on :) Fun dependencies

11:36 <konradybcio> we have a solution for the reverse (gdsc.cxcs) but for this.. I think like you said, you'll have to add the power-domain to all camcc clock consumers

11:36 <konradybcio> (which makes sense anyway, it needs to be on for camss access)

12:53 <SanchayanMaity> Hello... I have a dragonboard 845c and using Yocto kirkstone to build and flash image. Running into boot failure. Logs are here https://paste.sr.ht/~sanchayanmaity/b90a7d438177c81252088d62ec94388a2beb665a. Can someone help me with what might be source of errors seen during boot? It boots up and then takes a long time after 5s mark and eventually getting stuck.

12:55 <konradybcio> [ 14.319105] platform 17d43000.cpufreq: deferred probe pending

12:55 <konradybcio> [ 14.330291] platform a800000.usb: deferred probe pending

12:55 <konradybcio> [ 14.324924] platform a600000.usb: deferred probe pending

12:55 <konradybcio> do you have gcc and rpmhcc?

13:17 <SanchayanMaity> @konradybcio Are you referring to device tree entries?

13:17 <konradybcio> no, config options

13:17 <konradybcio> or modules if you use them

13:25 <SanchayanMaity> Have not looked into that. It builds the kernel specified from meta-qcom and did not have to look into that so far. This was working till a day ago and suddenly broke so stymied.

13:42 <SanchayanMaity> From what I see meta-qcom just uses the defconfig for arm64 and the so called config fragments do not have any gcc/rpmhcc AFAICT

14:10 <dv_> ndec: is rpmhcc part of a generated yocto sdk when meta-qcom is in layers.conf ?

14:35 <konradybcio> you can use `./scripts/extract-ikconfig <path/to/kernel/image>` to assess the configuration it was compiled with

14:35 <konradybcio> you'll find it in any linux kernel source

18:01 <narmstrong> Marijn[m]: I took your suggestions and replaced by the grammer in usage: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/284

18:02 <narmstrong> Marijn[m]: the -P grammar is probably false

18:03 <narmstrong> but the idea is here

18:46 <Mis012[m]> bamse: eh, hrd says that `TLMM_ETM_MODE` is clocked by `gcc_tlmm_ahb_clk`

18:47 <Mis012[m]> seems very unlikely that clock would be off during normal device operation?

18:50 <Mis012[m]> it does seem to be conveniently in it's own 0x1000 block

18:53 <Mis012[m]> but at least static smmu configuration has 0x3400000 through 0x4000000 all as RW for HLOS

18:53 <Mis012[m]> so either it's getting blocked dynamically or it's done with XPUs

19:01 <Mis012[m]> hm, I was looking at 845 static config, not 8998

19:03 <Mis012[m]> so 0x3407000 through 0x4000000

19:03 <Mis012[m]> basically the same thing

19:47 <Marijn[m]> narmstrong: Interesting, I didn't expect anyone to find the time to bother patching that up, will take a look soonñ

19:47 <Marijn[m]> s/soonñ/soon!/

19:48 <Marijn[m]> narmstrong: did you also find a moment to look at my DSC register dumps, or continue figuring out where and why vsync runs at half the panel refresh rate?