ChanServ changed the topic of #linux-msm to:
eberman has joined #linux-msm
eberman is now known as reclaim
reclaim is now known as eberman
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<aka_[m]> github is full of things which ain't supposed to be there
<aka_[m]> tho things are way too modern for my likings
Daanct12 has joined #linux-msm
pespin has joined #linux-msm
srinik has joined #linux-msm
<marc|gonzalez> lumag: konradybcio: for msm8998 HDMI TX support (and the $!*& TDP158), I'm not in any rush. v6.11 cutoff is missed anyway. So there are 7-9 weeks left to bake something acceptable for v6.12
<marc|gonzalez> rawoul wrote the HDMI PHY driver 3 years ago, and it seems to work as expected. So I haven't done much on it, other than remove debug/temp code.
<marc|gonzalez> For now, I just need to address lumag's remark of renaming the regulators to match the 8996 binding.
<lumag> marc|gonzalez, I'm fine with your TX patch contents (that's what I mean by my 'calculations' comment: that it looks more or less consistent with msm8996). Just few minor things (also note that you need to update bindings and maybe DT parts).
<marc|gonzalez> lumag: should I "merge" the HDMI PHY patch into the HDMI TX series?
<marc|gonzalez> I was "afraid" to do that because it might hold up the whole series
<marc|gonzalez> But all the DT is handled in the HDMI TX series
<lumag> Unless vkoul or bamse object, I'd prefer to see a single series with 2 bindings patches, HDMI TX, HDMI PHY and DT changes.
<marc|gonzalez> OK, it's just that, the bigger the series, the harder it is to merge
<marc|gonzalez> And you know how frustrating it is to build consensus
<lumag> I know that this makes a work of maintainers slightly harder, but on the other hand, it makes it easier to check that it's consistent.
<lumag> Otherwise it's easy to end up with the driver and DT being merged from diverged series.
<marc|gonzalez> lumag: your point makes a lot of sense
<lumag> I know that some maintainers disagree with me :-D
<marc|gonzalez> I just avoided it for the reason I stated
<lumag> Greg being a famous example.
<marc|gonzalez> GKH?
<lumag> yeah, but it's like 6 patches, not 16.
<lumag> Yeah
<marc|gonzalez> Maybe I can fully split in 2 series?
<marc|gonzalez> TX proper vs PHY?
<lumag> marc|gonzalez, this will work too. But then TX has a dependency on PHY. Especially on the DT side.
<marc|gonzalez> But TX DT points to PHY DT
<lumag> So single series works better
<marc|gonzalez> precisely
<marc|gonzalez> OK. I think I'll reroll the 2 series into 1
<marc|gonzalez> What patch number do I use, series latest + 1
<marc|gonzalez> ?
<marc|gonzalez> Also what order of patches? PHY binding, TX binding, GPIO DT, HDMI DT, PHY driver? (just add the PHY driver at the end of current series?)
<lumag> bindings, drivers, DTS.
<marc|gonzalez> Thanks, I would have gotten it wrong.
<marc|gonzalez> So many conventions to keep track of...
<marc|gonzalez> I'm getting too old for this
<marc|gonzalez> lumag: BTW, the HDMI TX series is getting no comments. Does that mean it's reaching consensus, or that no one cares anymore? :)
<lumag> marc|gonzalez, lol. you can't be that old
<marc|gonzalez> I'm 750 you insensitive clod! :) my full name is merlin gandalf yoda
<lumag> And who do you think caused all the chaos?
<aka_[m]> aaaaaa
<aka_[m]> im going to fuckup again
<lumag> marc|gonzalez, could you please point me to the HDMI TX driver changes?
<lumag> I mean DT and bindings are nice, but I'd also like to merge the driver together with bindings.
<aka_[m]> would that result in some epic fail?
<lumag> Damn, I was caught again.
<lumag> The PHY driver patch contains tx changes too.
<marc|gonzalez> "could you please point me to the HDMI TX driver changes?" not sure what you mean.
<lumag> aka_[m], what's the issue? I just see that get_maintainers.pl complains that the cover letter isn't a patch (and it really isn't)
<lumag> marc|gonzalez, I was expecting two patches: one for HDMI PHY and another one for HDMI TX drivers.
<aka_[m]> before it didn't throw it for 10 times
<aka_[m]> when i sent it from old tree
<marc|gonzalez> aaaaah I think I see what you mean
<lumag> As you are hopefully going to repost the series, please split the driver patch
<aka_[m]> ok lets risk
<marc|gonzalez> drivers/gpu/drm/msm/hdmi/hdmi.c is a TX change, not a PHY change
<aka_[m]> i guess im going to piss off Krzysztof once again
<lumag> marc|gonzalez, "drm/msm: add msm8998 hdmi phy/pll support"
<aka_[m]> lumag: ?
<lumag> there is no word about the HDMI TX changes
<aka_[m]> ah to Marc
<lumag> so please split it.
<lumag> aka_[m], excuse me.
<lumag> What command are you executing? Is it some kind of script?
<lumag> Or just get_maintainer.pl *patch ?
<aka_[m]> git send-email --to-cover --cc-cover qcom-icc-6/*.patch --cc phone-devel@vger.kernel.org --cc ~postmarketos/upstreaming@lists.sr.ht --cc-cmd='scripts/get_maintainer.pl --norolestats qcom-icc-6/*.patch'
<aka_[m]> i should have switch to b4 i know
<marc|gonzalez> lumag: the only TX relevant change seems to be: +{ .compatible = "qcom,hdmi-tx-8998", .data = &hdmi_tx_8974_config },
<lumag> marc|gonzalez, yes. But it's not a PHY support. Or you can mention that in the subject and body.
<aka_[m]> perl-io-socket-ssl >_>
<marc|gonzalez> I can split into a single patch, but the commit message will be terse.
<lumag> (I'm fine with the latter option, just make sure that next time I look for msm8998 HDMI TX, I stumble upon the correct patch)
<lumag> aka_[m], I'm fine with the PHY + TX patch, if it's described properly.
<lumag> ugh, that was marc|gonzalez
<lumag> aka_[m], It makes me wonder, what has happened to your host.
<aka_[m]> arch so broken it seems
<aka_[m]> Need MIME::Base64 and Authen::SASL todo auth at /usr/lib/git-core/git-send-email line 1655.
<aka_[m]> internet says i also need... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/AfTBXYVUyNfKEHVgSCfQFTrY>)
<konradybcio> create a python virtualenv and grab recent dtschema yamllint b4 and off you go :P
<aka_[m]> schema is also kinda fucked on arch
<aka_[m]> i had to modify something regarding its name
<konradybcio> that's why i'm suggesting a python virtualenv
<konradybcio> (virtualenv ~/venv && source ~/venv/bin/activate)
<konradybcio> and you can pip like in the good ol days
ektor5 has quit [Quit: WeeChat 4.3.4]
ektor5 has joined #linux-msm
Daanct12 has quit [Quit: WeeChat 4.3.3]
srinik has quit [Remote host closed the connection]
srinik has joined #linux-msm
<krzk> konradybcio: pipx works the same, doesn't it?
<konradybcio> krzk venv "works for me", never used pipx before, may explore it one day..
deathmist1 is now known as deathmist
ungeskriptet has quit [Quit: Contact: https://david-w.eu]
ungeskriptet has joined #linux-msm
marc|gonzalez has quit [Quit: Leaving.]
ungeskriptet has quit [Quit: Contact: https://david-w.eu]
pespin_ has joined #linux-msm
pespin has quit [Ping timeout: 480 seconds]
<calebccff> pipx i think is just a venv per package + wrappers
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #linux-msm
<aka_[m]> konradybcio: have you got audio up on j606?
<konradybcio> no
srinik has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
pespin_ has quit [Remote host closed the connection]