01:18 <flamingradian[m]> There are quite a few iommu patches that are waiting for the maintainer

01:34 <flamingradian[m]> or perhaps for "dt-bindings: arm-smmu: fix clocks/clock-names schema" to get fixed

07:35 <aka_[m]> Regarding 8976 first I should document lacking compatibles, then add tree, document board and then add board dts right? About mdss names i should name mdp/dsi with mdss_ before right?

07:36 <aka_[m]> Is there any way to run bindings check with only one dtb? Scrolling entire output is pain

07:36 <aka_[m]> bamse:

07:38 <Marijn[m]> aka_ bamse: note that kholk @_oftc_kholk:matrix.organnounced that he'll send his updated, improved and (almost?) feature-complete series for 8976/8956 over the weekend

07:39 <aka_[m]> Marijn: how many times already?

07:40 <aka_[m]> I've been hearing it for like one and half year already

07:40 <Marijn[m]> 3*

07:40 <aka_[m]> Atleast 3

07:40 <aka_[m]> I can date back to 5.15

07:41 <Marijn[m]> The public branch that you seem to have - at least in part - based your series on is on 5.13

07:41 <aka_[m]> Wrong my last js on 5.17

07:42 <aka_[m]> And tested now on 6.0.5

07:42 <Marijn[m]> Sorry, strip a one out of that. 5.3-rc2

07:43 <aka_[m]> That was last branch by Angelo which was ugly atleast

07:53 <aka_[m]> Im not sure if I can call it brave or insulting assuming I haven't done anything else that rebasing someone's else broken code for past almost 2y,but if you guys will feel superior Thanks to being first I will let you be, and just throw my few coins if I manage to spot some mistakes, because you know everyone makes them.

08:06 <Marijn[m]> aka_: Have you been "rebasing someone[-'s] else['s] broken code", or have you written this patch from scratch?

08:07 <aka_[m]> Dts is pretty much on top of 8953 one with removed and added pieces

08:07 <aka_[m]> There is more things to do but they require works in gcc and pinctrl

08:07 <Marijn[m]> That's what Angelo's DT is, too (based on an older SoC that 8953 was also based on, since 8953 isn't even there for more than a year)

08:07 <Marijn[m]> Yeah, I had to do some reverts in gcc ;)

08:15 <aka_[m]> Issue I have with Angelo is that he cannot be trusted(msm8998,sdm660, Helio x10 done already?) and jumping straight in once i find some determination to do something is not nice, Im quite anxious so things like sending patches is quite fearsome to me and then you see "hehe go away dumb kido I have stuff working for like 2y don't interfere"

08:33 <kholk> aka_: that was definitely not nice :)))

08:35 <kholk> but feel free to go on with your series, what I said was not in any way about stopping the upstreaming of anyone's code.

08:37 <Marijn[m]> aka_: You're more than free to - welcome even! - to collaborate on patches. Help other pull patch series over the finish line if you know they exist out in the wild, rather than writing "your own" from scratch

08:37 <aka_[m]> I'm going to have break and rebase dpu patches for SM6115, so go ahead and send yours but I fear you have too much things and it will end exactly same way like other patches-multiple resends

08:38 <aka_[m]> That's why I wanted to know what you have so I might know what I can work on.

08:39 <aka_[m]> Marijn[m]: I haven't seen any single of these 2y old done patches because your branches are hidden

08:40 <Marijn[m]> aka_: Sure, that's totally on me for promising you to send it - heck, even make the reworked series a bit more visible - apologies about that

08:40 <aka_[m]> All I seen was iommu asid patch and gcc within last 2y

08:41 <aka_[m]> Needed ofc but there is no reason to stop adding rest of hardware and for display we can use llvmpipe at first

08:42 <aka_[m]> Not everything has to come at once as you probably want

08:42 <Marijn[m]> aka_: Cool, send 6115! I only have 6125/6350/6375 so I don't think we're going to overlap

08:42 <aka_[m]> We will

08:42 <aka_[m]> Do a610

08:43 <Marijn[m]> Well, I do have multiple patches that will break DPU hw catalog, but that's on the driver side

08:43 <aka_[m]> Because Im not into non-gmu part, rest override i have completed

08:43 <Marijn[m]> aka_: Are you asking me/us to do a610? Sure, that's planned but you see I have multiple patch series/areas going on :)

08:43 <aka_[m]> Well, you will need it on 665

08:44 <aka_[m]> So will I on 662

08:44 <aka_[m]> And maybe 680 folks too if someone starts mainlining it

08:44 <kholk> re: Helio X10 - that's on LKML, check linux-mediatek

08:45 <Marijn[m]> aka_: Hence I'm asking if you have already done it or will do it. As you may or may not have noticed here in linux-msm _and_ on the mailing lists, all our Sony devices have cmdmode panels and DPU breaks everywhere in different and spectacular ways.

08:45 <Marijn[m]> Having a trustworthy display would be nice before doing GPU

08:46 <aka_[m]> kholk: And it's like v8 right, that's why I wanted to do something, to not wait till 2024

08:46 <aka_[m]> As you know ds 3.10 devices are dying on Android because ebpf

08:47 <kholk> no, it's v2

08:48 <Marijn[m]> aka_[m]: They are dying on 6.0.0 too because of messed up defconfig and strange requirements from Android 13 ;)

08:49 <Marijn[m]> I tried fixing the in-tree defconfigs and even got the patches merged depite the mainainer stating that they weren't used... Google keeps their own Android defconfigs out of tree and they should just remove these if they're broken, IMO.

15:40 <bamse> aka_[m]: yeah, now in the future you can do "make CHECK_DTBS=y qcom/foo.dtb"

16:05 <kholk> bamse: what?! upstream?! we've just pushed a change for `make dtbs_chack DTB_FILES=<files>`

16:06 <kholk> literally today

16:06 <z3ntu> it's a bit buggy still but yes it exists since some weeks at least

16:07 <z3ntu> I think it was first applied maybe even half a year ago but reverted because of problems but it has landed again

16:08 <kholk> ah, looks like I have to bring good news to my colleagues

16:10 <kholk> thanks btw

16:42 <CosmicPenguin> Anybody semi-seriously working on QCS610 for upstream?

17:34 <bamse> kholk: cool, didn't know it was that fresh...and i had missed the revert/reapply dance :)

18:27 <Marijn[m]> So it finally landed? I have so far always been picking https://lore.kernel.org/linux-arm-msm/20220623144357.297252-1-dmitry.baryshkov@linaro.org/ to my branches and using `make VALIDATE_DT=1 qcom/<soc>-<board>-<device>.dtb` 🙃

18:27 <Marijn[m]> And it usually fails with a cryptic error message without checking DT :)

18:29 <mal> bamse: did you see my message from about 2 days ago about msm8226 and some other platforms failing on 6.1 rcs, needs adding of two missing driver patches or reverting some dts changes

19:19 <konradybcio> CosmicPenguin, is it shipping anywhere, or just magic devboards?

19:51 <lumag> kholk, DTB_FILES=... sounds like hack to me

19:52 <lumag> kholk, could you point me to the patch please?

19:52 <Marijn[m]> Oh lumag you weren't even CC'd on this despite working on re-enabling it previously?

20:37 <CosmicPenguin> konradybcio: There are some thundersoft boards I think, but I don't think there are any commercial boards shipping. Its mostly an iot/industrial soc

20:48 <DylanVanAssche> srinik: I see that the FastRPC driver can already attach the SENSORS_PD. FASTRPC_IOCTL_INIT_ATACH_SNS already exist like on downstream. I tried to talk to it, but it never asks for the sensor data to initialize the sensor stuff. Has this been tested/used on SDM845, I cannot find much online?