ChanServ changed the topic of #linux-msm to:
<flamingradian[m]> There are quite a few iommu patches that are waiting for the maintainer
<flamingradian[m]> or perhaps for "dt-bindings: arm-smmu: fix clocks/clock-names schema" to get fixed
tomf has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
<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?
<aka_[m]> Is there any way to run bindings check with only one dtb? Scrolling entire output is pain
<aka_[m]> bamse:
<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
<aka_[m]> Marijn: how many times already?
<aka_[m]> I've been hearing it for like one and half year already
<Marijn[m]> 3*
<aka_[m]> Atleast 3
<aka_[m]> I can date back to 5.15
<Marijn[m]> The public branch that you seem to have - at least in part - based your series on is on 5.13
<aka_[m]> Wrong my last js on 5.17
<aka_[m]> And tested now on 6.0.5
<Marijn[m]> Sorry, strip a one out of that. 5.3-rc2
<aka_[m]> That was last branch by Angelo which was ugly atleast
djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
<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.
pevik has joined #linux-msm
<Marijn[m]> aka_: Have you been "rebasing someone[-'s] else['s] broken code", or have you written this patch from scratch?
<aka_[m]> Dts is pretty much on top of 8953 one with removed and added pieces
<aka_[m]> There is more things to do but they require works in gcc and pinctrl
<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)
<Marijn[m]> Yeah, I had to do some reverts in gcc ;)
<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"
<kholk> aka_: that was definitely not nice :)))
<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.
<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
<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
<aka_[m]> That's why I wanted to know what you have so I might know what I can work on.
<aka_[m]> Marijn[m]: I haven't seen any single of these 2y old done patches because your branches are hidden
<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
<aka_[m]> All I seen was iommu asid patch and gcc within last 2y
<aka_[m]> Needed ofc but there is no reason to stop adding rest of hardware and for display we can use llvmpipe at first
<aka_[m]> Not everything has to come at once as you probably want
<Marijn[m]> aka_: Cool, send 6115! I only have 6125/6350/6375 so I don't think we're going to overlap
<aka_[m]> We will
<aka_[m]> Do a610
<Marijn[m]> Well, I do have multiple patches that will break DPU hw catalog, but that's on the driver side
<aka_[m]> Because Im not into non-gmu part, rest override i have completed
<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 :)
<aka_[m]> Well, you will need it on 665
<aka_[m]> So will I on 662
<aka_[m]> And maybe 680 folks too if someone starts mainlining it
<kholk> re: Helio X10 - that's on LKML, check linux-mediatek
<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.
<Marijn[m]> Having a trustworthy display would be nice before doing GPU
<aka_[m]> kholk: And it's like v8 right, that's why I wanted to do something, to not wait till 2024
<aka_[m]> As you know ds 3.10 devices are dying on Android because ebpf
<kholk> no, it's v2
<Marijn[m]> aka_[m]: They are dying on 6.0.0 too because of messed up defconfig and strange requirements from Android 13 ;)
<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.
pespin has joined #linux-msm
<bamse> aka_[m]: yeah, now in the future you can do "make CHECK_DTBS=y qcom/foo.dtb"
<kholk> bamse: what?! upstream?! we've just pushed a change for `make dtbs_chack DTB_FILES=<files>`
<kholk> literally today
<z3ntu> it's a bit buggy still but yes it exists since some weeks at least
<z3ntu> I think it was first applied maybe even half a year ago but reverted because of problems but it has landed again
<kholk> ah, looks like I have to bring good news to my colleagues
<kholk> thanks btw
<CosmicPenguin> Anybody semi-seriously working on QCS610 for upstream?
pevik has quit [Ping timeout: 480 seconds]
<bamse> kholk: cool, didn't know it was that fresh...and i had missed the revert/reapply dance :)
pevik has joined #linux-msm
pevik has quit [Ping timeout: 480 seconds]
<Marijn[m]> So it finally landed? I have so far always been picking to my branches and using `make VALIDATE_DT=1 qcom/<soc>-<board>-<device>.dtb` 🙃
<Marijn[m]> And it usually fails with a cryptic error message without checking DT :)
<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
<konradybcio> CosmicPenguin, is it shipping anywhere, or just magic devboards?
<lumag> kholk, DTB_FILES=... sounds like hack to me
<lumag> kholk, could you point me to the patch please?
<Marijn[m]> Oh lumag you weren't even CC'd on this despite working on re-enabling it previously?
pespin_ has joined #linux-msm
pespin_ has quit []
pespin has quit [Ping timeout: 480 seconds]
<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
<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?
jhovold has quit [Ping timeout: 480 seconds]