00:49 <bryanodonoghue> calebccff debugcc is more accurate

00:49 <bryanodonoghue> since it measures

00:49 <bryanodonoghue> debugfs just shows what was requested

00:50 <bryanodonoghue> actually sounds like debugcc has a bug tbh

00:50 <bryanodonoghue> 24 MHz on MCLK is what I'd expect to see

00:50 <bryanodonoghue> debugcc "should" be measuring

00:50 <bryanodonoghue> so maybe it *is* measuring but is messing up the interpretation of the results for sdm845

00:51 <bryanodonoghue> that's be my guess anyway

00:52 <calebccff> bryanodonoghue: yeah i guess it's a coinflip between debugcc and the camcc driver itself... Given that mclk0 and the csi0phytimer clocks are both /4 despite coming from different PLLs I guess debugcc could be the issue

00:59 <bryanodonoghue> I'd be surprised if it weren't generating 24MHz

01:01 <bryanodonoghue> what about the rest of the debugcc clocks ?

01:03 <bryanodonoghue> maybe cam_cc.div_val = 0x02 would work

09:03 <aka_[m]> Any ideas when Konrad will be online?

09:41 <z3ntu> aka_: https://dontasktoask.com/ ?

10:08 <aka_[m]> Luca Weiss: bro

10:09 <aka_[m]> Maybe Konrad is retaking his exams so he might not be there for a while

12:34 <marc|gonzalez> robher, krzk: could you give a quick look at "[PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop". It's the last bit holding back the series, according to Kalle.

15:31 <marc|gonzalez> lumag: will try getting HDMI 1.4 to work on my board.

15:32 <marc|gonzalez> rawoul tells me you might have unmerged submissions?

15:40 <aka_[m]> Luca Weiss: so maybe you can guide me a bit

15:40 <aka_[m]> https://lists.sr.ht/~postmarketos/upstreaming/patches/50987#feedback-335103:527-663

15:40 <aka_[m]> this comment is only strictly about &apps_smsm 10, 9 being in single line?

16:01 <z3ntu> aka_: yes, match the style of foo and foo-names, so put a newline after <&apps_sms 10>,

16:01 <z3ntu> so that foo and foo-names are both two lines essentially

19:57 <abhinav__> bamse hi, can you pls take a look at https://patchwork.kernel.org/project/linux-arm-msm/patch/20240426142442.7769-1-quic_vvalluru@quicinc.com/ ? I have given a couple of minor comments but rest lgtm

20:06 <calebccff> bryanodonoghue: yeah seems like debugcc was to blame... so im really stuck at cam_cc_ife_0_clk_src: rcg didn't update its configuration.

20:08 <aka_[m]> calebccff: have you tried this patch for shared rcgs?

20:08 <aka_[m]> it should be quite top

20:08 <aka_[m]> https://patchwork.kernel.org/project/linux-arm-msm/patch/20240502224703.103150-1-swboyd@chromium.org/

20:10 <calebccff> aka_[m]: will give it a whirl

20:16 <calebccff> aka_[m]: nada, doesn't change anything

20:16 <calebccff> this is happening in the set rate callback anyways, but I thin kthat patch is for the enable cb

20:17 <calebccff> as in, it fixes a bug when enable is called without set_rate being called first

20:53 <calebccff> very confused now... it's somehow trying to set_rate on ife_0_clk_src from the csiphy set_clk_rates() function which calls clk_set_rate on a different clock?? https://p.calebs.dev/3b1cd2@raw

20:54 <calebccff> anways the clock seems to get enabled as we want, not sure if the rate is correct though https://p.calebs.dev/8910c8@raw

20:54 <calebccff> or if any of these are coorect

20:55 <calebccff> i know the C-PHY values for some clocks are quite different to D-PHY

23:14 <bamse> abhinav__: nice! needs to be respun, so provided some feedback...but looking forward to merge v3

23:15 <bamse> abhinav__: attempted to boot my rb3gen2 and modetest reports the 3rd output :) don't have anything connected at this point though, so couldn't test it fully

23:17 <abhinav__> bamse nice !

23:17 <abhinav__> thanks