ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
cxl000 has quit [Quit: Leaving]
ldts__ has joined #linux-msm
ldts_ has quit [Ping timeout: 480 seconds]
pevik_ has joined #linux-msm
pevik__ has joined #linux-msm
cxl000 has joined #linux-msm
<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?
<z3ntu> (cc konradybcio)
<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?
swdefrgthfgjhk has quit [Quit: ZNC -]
swdefrgthfgjhk has joined #linux-msm
<z3ntu> Ah and actually this power domain I think requires a clock from gcc to be on :) Fun dependencies
swdefrgthfgjhk has quit [Ping timeout: 480 seconds]
swdefrgthfgjhk has joined #linux-msm
<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
<konradybcio> (which makes sense anyway, it needs to be on for camss access)
swdefrgthfgjhk has quit [Ping timeout: 480 seconds]
swdefrgt- has joined #linux-msm
svarbanov has quit [Remote host closed the connection]
SanchayanMaity has joined #linux-msm
<SanchayanMaity> Hello... I have a dragonboard 845c and using Yocto kirkstone to build and flash image. Running into boot failure. Logs are here 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.
<konradybcio> [ 14.319105] platform 17d43000.cpufreq: deferred probe pending
<konradybcio> [ 14.330291] platform a800000.usb: deferred probe pending
<konradybcio> [ 14.324924] platform a600000.usb: deferred probe pending
<konradybcio> do you have gcc and rpmhcc?
<SanchayanMaity> @konradybcio Are you referring to device tree entries?
<konradybcio> no, config options
<konradybcio> or modules if you use them
<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.
pespin has joined #linux-msm
<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
<dv_> ndec: is rpmhcc part of a generated yocto sdk when meta-qcom is in layers.conf ?
<konradybcio> you can use `./scripts/extract-ikconfig <path/to/kernel/image>` to assess the configuration it was compiled with
<konradybcio> you'll find it in any linux kernel source
svarbanov has joined #linux-msm
pevik__ has quit [Remote host closed the connection]
pevik_ has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
deathmist2 has quit [Remote host closed the connection]
deathmist2 has joined #linux-msm
<narmstrong> Marijn[m]: I took your suggestions and replaced by the grammer in usage:
<narmstrong> Marijn[m]: the -P grammar is probably false
<narmstrong> but the idea is here
Rayyan has left #linux-msm [#linux-msm]
Rayyan has joined #linux-msm
<Mis012[m]> bamse: eh, hrd says that `TLMM_ETM_MODE` is clocked by `gcc_tlmm_ahb_clk`
<Mis012[m]> seems very unlikely that clock would be off during normal device operation?
<Mis012[m]> it does seem to be conveniently in it's own 0x1000 block
<Mis012[m]> but at least static smmu configuration has 0x3400000 through 0x4000000 all as RW for HLOS
<Mis012[m]> so either it's getting blocked dynamically or it's done with XPUs
<Mis012[m]> hm, I was looking at 845 static config, not 8998
<Mis012[m]> so 0x3407000 through 0x4000000
<Mis012[m]> basically the same thing
pespin_ has joined #linux-msm
pespin has quit [Ping timeout: 480 seconds]
<Marijn[m]> narmstrong: Interesting, I didn't expect anyone to find the time to bother patching that up, will take a look soonñ
<Marijn[m]> s/soonñ/soon!/
<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?