05:57 <aka_[m]> bhsharma: to avoid duplication here is my wip repo for SM6115 dts

05:57 <aka_[m]> https://github.com/Kiciuk/linux/commits/sm6115/next-dts

05:59 <bhsharma> aka_[m]: Cool. Thanks for sharing the same..

06:00 <bhsharma> aka_[m]: I have the debug uart on the qcom board, so needed to enable it to see uart console logs

06:01 <bhsharma> aka_[m]: I have few interconnect support patches as well, which I had prepared for sm4250 and work on my qcom board. Will post them shortly as well

06:01 <aka_[m]> bhsharma: That's nice, I haven't touch ICC yet

06:01 <aka_[m]> Wonder if ICC generator will work

06:01 <bhsharma> aka_[m]: Overall sm6115 patches (present in linux-next) look great. Thanks for your work :)

06:01 <aka_[m]> Tho there is some binding calling one of master's vert_dev

06:02 <aka_[m]> No idea what is that

06:02 <aka_[m]> Maybe some legacy binding

06:02 <bhsharma> yes, that seems like legacy downstream stuff ..

06:03 <aka_[m]> Issue is I was unable to find it anywhere else

06:03 <aka_[m]> Most work was done by ichernev: i just did display side and some clock fixes, not much

06:04 <bhsharma> aka_[m]: Did you try the tsens and cpu_freq stuff yet? I can see you add the dts nodes for the same in your tree

06:05 <aka_[m]> Yes, cpufreq works on stable

06:05 <aka_[m]> Fucked on next

06:05 <aka_[m]> 5.19 cpufreq was working well

06:06 <bhsharma> aka_[m]: Also can I rebase my changes on top of your tree - which would bring me to the question - when are you planning to post the dts changes (I can see several changes similar to what I had done for sm4250) and would be useful for Linaro as well

06:06 <aka_[m]> Probably this week

06:06 <aka_[m]> If I get Konrad to review my local i might send it even tomorrow

06:07 <bhsharma> aka_[m]: That's great. Glad to see tsens / cpufreq working fine

06:08 <aka_[m]> I would have to test on 6.2 yet but it was working on 5.19

06:08 <bhsharma> konradybcio, is now with Linaro, so we can nudge him a little :P

06:08 <aka_[m]> He has 662 tab too

06:08 <bhsharma> Expensive hobby :)

06:14 <aka_[m]> Tho even if u would send it, I guess submitting for 6.2 is already closed

06:14 <aka_[m]> *if i

06:17 <bhsharma> right, that would be my guess as well.

16:08 <mort_> next kernel problem: qcom-camss will sometimes give me frames as expected, but other times, it will never give me any frames. When it doesn't work, these two messages appear in the dmesg log when I exit the process which opened the video device:

16:08 <mort_> [ 234.956356] qcom-camss 1b0ac00.camss: VFE sof timeout

16:08 <mort_> [ 235.468609] qcom-camss 1b0ac00.camss: VFE reg update timeout

16:43 <mort_> nevermind, I didn't figure out what was wrong but I went back to an earlier iteration of my devicetree and now it's good

19:49 <z3ntu> mort_: just curious, what was the change?

19:49 <mort_> honestly, I don't know

19:51 <mort_> starting from a devicetree which works for linux 4.9, I had adapted it to work with linux 5.10 by just trying to incorporate as many changes from the upstream apq8016-sbc.dtsi between 4.9 and 5.10 as possible, and someone else had adapted it to work with linux 5.7 with as few changes from our 4.9 dts as possible and I adapted that to work with 5.10

19:51 <mort_> with as few changes as possible

19:52 <mort_> the first devicetree has a camera which always works, the second has a camera which works 50% of the time

19:56 <mort_> neither drivers nor .dtsi files are very stable between kernel versions and most of the time, the changes seem pretty arbitrary, like when a bunch of nodes were changed to not have a leading 0 in the address part of their name (so sdhci@0blah -> sdhci@blah) or when apq8016-sbc-soc-pins.dtsi and apq8016-sbc-pmic-pins.dtsi were merged into

19:56 <mort_> apq8016-sbc.dtsi or when pm8916-msm8916.dtsi was introduced whose only purpose is to include pm8916.dtsi and msm8916.dtsi and define some node which used to be in another .dtsi

20:28 <aka_[m]> krzk: any chance you are there now?