ChanServ changed the topic of #linux-msm to:
megatradeusa[m] has quit [autokilled: Spambot. Mail support@oftc.net if you think this is in error. (2022-08-19 00:04:06)]
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
pevik_ has joined #linux-msm
<lumag> aka_[m], yes, I was going to resend them at some point (I was out of office for the last few weeks)
<lumag> Feel free to use Rob & abhinav & me as the maintainer for the new dpu bindings
<aka_[m]> Thankies.
<aka_[m]> If i want to send DPU bindings should i make them the way they should look after your patch series?
<aka_[m]> and skip mdss documenting or just have to wait till your patches get into next before sending mine
<lumag> aka_[m], there was a note from krzk that he doesn't like that approach.
<lumag> So, please base them on the current tree and I'll check that when rebasing my changes
<aka_[m]> okay.
<aka_[m]> Out of wonder, while your patches have mdss split, why we cannot have on yaml for DPU too?
<aka_[m]> s/on/one/
<aka_[m]> in case of sm6115 i would almost copy qcm2290 yaml because both platforms base on same internal design(kamorta?)
<lumag> aka_[m], you can extend the existing yaml with additional compats
<lumag> Regarding using the single file. Well, I'm not sure. I fear that we might end up with the hell of if's so, I decided to split away the common part (dpu-common.yaml) and leave all platform-specifics in place.
<lumag> We can merge them later if we see that it makes sense.
<lumag> I'll review this part before v3
<aka_[m]> <lumag> "aka_, you can extend the..." <- That would be great.
<aka_[m]> I won't need to deal with example right?
<lumag> aka_[m], up to you. You can add the second example, or just leave the first once
<lumag> *one
<aka_[m]> If so I should progress on getting dpu patches out, earlier, better.
<aka_[m]> The small thing is 2290 yaml have maintainer in it and no idea if it won't prompt him if I add SM6115 driver and assign maintainership to him
<lumag> aka_[m], aks lpoulain ;-)
<lumag> But generally such things are acceptable
<aka_[m]> i haven't managed to find him there on any platform like telegram, and my anxiety bit kicks when i have to write email xD
<lumag> aka_[m], hint: lpoulain on IRC
<lumag> Just DM him
<lumag> but generally emails are the preferred method of communication here. Because they don't ask you to answer as soon as possible
<aka_[m]> <lumag> "Just DM him" <- tried 2 diff irc no response
Daanct12 has quit [Remote host closed the connection]
pg12_ has quit []
pg12 has joined #linux-msm
sergi8 has quit []
<aka_[m]> bamse: in this patch series
<aka_[m]> Should i also change dispcc-sm6115.c to sm6115-dispcc.c or i can leave it as it is to keep it consistent?
<aka_[m]> pretty much commits to review
<bamse> consistency is preferred
<aka_[m]> so leave dispcc-sm6115.c and just do vendor,soc-ip for bindings?
<aka_[m]> i wanted to send it today before going to bed.
<bamse> in general it's vendor,soc-ip...for clocks it's mixed
<bamse> but yeah dispcc-sm6115.c and qcom,sm6115-dispcc sounds good
<aka_[m]> now im bit unsure i created patches with format patch v2 can i just send them like old ones or i have to pass some -option into git-send email?
<aka_[m]> i have some script which does it automatically
<aka_[m]> ok whatever shipped already
<aka_[m]> hope i won't have for third time
pevik_ has quit [Quit: Lost terminal]
Daanct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
<aka_[m]> bamse: and i send with your address on @linaro.org....
<bamse> aka_[m]: yes
<aka_[m]> v3 inc?
<bamse> aka_[m]: it all goes into linux-arm-msm and ends up in patchwork
<aka_[m]> i mean in maintainer of bindings
<bamse> ahh, well, you can put that as either @linaro or @kernel.org
<aka_[m]> is linaro still valid then?
<bamse> for now
<aka_[m]> one good thing atleast.
<aka_[m]> Tomorrow may force myself for DPU stuff