ahalaney has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
lumag_ has quit [Remote host closed the connection]
lumag_ has joined #linux-msm
<lumag_>
konradybcio, I have a long standing question. Noting that you care about 8994/899. Do you have any plans on adding dsi pll support on those two platforms? At this moment we have the DSI PHY support, but not the PLL code. Also I see that none of the upstream dts files list mdp block. Are there any obstacles currently?
<konradybcio>
I have some stuff locally, but, and this is a huge but that has been holding this project back for 1+ year, there's no iommu for 8994
<konradybcio>
It shares the same IP block as 74
<konradybcio>
It depends on Angelo's secure ctx patches that have been rejected as far as few years ago because people didn't know how ridiculous qcom was back then
<konradybcio>
It also needs more love for 74/94 specifics
<konradybcio>
Well, in fact 8916 would also use it but 8916 has a proper smmu block that's only slightly retarded by the firmware
<konradybcio>
So the issues didn't manifest on there
<konradybcio>
Marijn can say something about how sad 20nmdsipll is too
<konradybcio>
And this week i moved to enter university so I have less time to work on this stuff
<konradybcio>
So, basically we need 8974(94) iommu done before we can proceed
<konradybcio>
And that hasn't been solved since 2013
<konradybcio>
There was an attempt once but he have up it seems
<minecrell>
konradybcio: I would argue the SMMU on 8916 is even more "retarded" by the firmware, given that you need an entirely separate driver
<konradybcio>
8916 uses a driver that was meant for 74 with some additions
<konradybcio>
At least downstream
<minecrell>
ah you're talking about the 8974 fun and not the hypervisor fun, nevermind then :D
<konradybcio>
Yeah
<konradybcio>
"fun" as you put it :P
<Marijn[m]>
<konradybcio> "Marijn can say something about..." <- lumag we have an unfinished, untested 20nm dsi pll driver. It's waiting for working smmu before we can test and finalize it, unfortunately
<konradybcio>
Perhaps bamse would be interested in this 8974/94 iommu thread
<Marijn[m]>
lumag:: thanks for reviewing the other dsi patches just this moment. Any idea if msm drm-next is still alive?
<lumag_>
konradybcio, Marijn[m] ok, thank you for your explanations
<lumag_>
I'll send my staged patches for the msm-next branch to robclark this weekend, after testing. Had a flue for the last two weeks and a pretty hard time before that.
<lumag_>
regarding 8974/94, I just don't have hardware to test, so that's why I asked you for the status.
<robclark>
lumag_: fwiw, I'm just making a pass thru patchworks now
<lumag_>
I was puzzling me for some time, why we do have the phy driver, but not the PLL driver.
<lumag_>
robclark, ah.
<lumag_>
So am I :-D
<Marijn[m]>
lumag_: Staged as in, you're the sub-maintainer for the DSI part and accumulated a bunch of patches/ Or do you have some goodies for [79]4 as well?
<konradybcio>
you're not missing out on much, 8994 was the greatest soc of the time on paper but turned out to be tied with shoestrings which just so happened to become lava due to all the heat the 20nm abomination generated
<Marijn[m]>
robclark: Thanks, appreciated :)
<konradybcio>
but yeah, we should definitely support that upstream
<lumag_>
Marijn[m], as a sub-maintainer and tester
<konradybcio>
my android port for lumia 950/xl still awaits gpu and we have to solve the iommu/dsipll parts before that :(
<konradybcio>
i got it to run headlessly, but that's of little use
<lumag_>
robclark, so would you like the staging branch from me this round?
<robclark>
lumag_: I can skip over the dsi ones ;-) either way I'll update status to 'Under Review' when I apply things
<lumag_>
robclark, ok
<konradybcio>
also, io_start gotta go from dsi host code
<konradybcio>
8992 vs 8994 conflicts, and so does 6125 vs 8something50
<konradybcio>
the registers are different but the hw version is the same
<lumag_>
konradybcio, register offset?
<lumag_>
register base
<konradybcio>
let's see if i can find it real quick
<robclark>
lumag_: I already pushed a few ones from gpu side of things to msm-next-staging.. I kinda want to get a couple of those backported to CrOS kernel in next few days (before release branch) since I think they should help with some intermittent / hard-to-reproduce crashes (ie. things I can tell are happening from crash telemetry but not necessarily reproduce myself)
<minecrell>
robclark: Could you make sure the a3xx fix still gets into 5.15? We talked about it at some point and AFAICT it was not picked up yet as fixes
<robclark>
minecrell: was that the devfreq one? I have that applied locally
<minecrell>
robclark: yep, thanks :)
<lumag_>
robclark, I'm going to push my dsi+dp+mdp/dpu branch after some more testing
<robclark>
minecrell: np
<robclark>
lumag_: sounds good.. I'm only pushing to msm-next-staging so far, so I'll pull the two branches together tomorrow
<lumag_>
konradybcio, ah, I see. IP version is the same. I'll think about it. It might be hard to do that.
<konradybcio>
first thing that comes to my mind is match based on compatible, if legacy compatible is found, try matching based on ip ver..
<lumag_>
konradybcio, yep
<lumag_>
like we do for phys
<minecrell>
konradybcio: why is this not taken from the device tree :(
<konradybcio>
because it was written "way back when" :P
<Marijn[m]>
minecrell: It's only used to distinguish phy/ctl 0/1
<Marijn[m]>
I don't see any other uses and would vouch for a different way of using DT? to specify who's DSI 0 and who's DSI 1, instead of relying on register base addresses?
<lumag_>
minecrell, because, I think, the dts maintainers did not like the qcom,cell-id approach
<Marijn[m]>
But they do like hardcoding seemingly-variable base addresses in drivers? 🤷
<lumag_>
Marijn[m], yep
<minecrell>
my spontaneous (naive) suggestion would be phys = <&dsi0_phy>, <&dsi1_phy>; on the node that needs to know what is phy 0/1
<lumag_>
then the host would need to tell DSI (which is already probed, up and running at this moment), which ID does it have.
<lumag_>
... to tell PHY ....
<minecrell>
Hm, FWIW another dumb idea: Similar to the consistent numbering of mmc/i2c/spi etc buses, add it to the aliases node and get the number from there, like dsi-phy0 = &dsi_phy0
<minecrell>
¯\_(ツ)_/¯
<konradybcio>
i disagree
<konradybcio>
if you start using aliases to order things you will quickly get into the exynos world
<konradybcio>
where nothing works without aliases
<lumag_>
Also note that is is not only for the PHYs. the dsi manager also would like to distinguish dsi0 and dsi1.
<lumag_>
Not to mention dsi_bind() putting the dsi into priv->dsi[] array
<lumag_>
I've tried hard to remove id from dsi/dsi_phy at some point.
<lumag_>
Few patches still hanging locally. But I got stuck at the few places where that id matters.
<Marijn[m]>
lumag_: Clock tree in the phy?
<bamse>
konradybcio: noted, would be nice to figure out the last pieces of the iommu
<Marijn[m]>
lumag_: I started working on some patches to get rid of the naming of the parents and instead use hw ptrs... Should probably finish it at some point
<bamse>
konradybcio: but, did angelo ever come up with some clean patches for that?
<konradybcio>
yes
<konradybcio>
get in touch with him
<konradybcio>
he has 8976 (and by extension 8953 and friends) iommu done
<konradybcio>
but also he has little time lately
<konradybcio>
but i guess you two can figure something out :)
<bamse>
konradybcio: but isn't 8976 the same craziness as sdm660? which is very different from 8974?
<Marijn[m]>
lumag_: There was that misnumbering in 8916 iirc, we can also fix that with clock references in DT I suppose?
<bamse>
konradybcio: or it's just the same as 8916?
<konradybcio>
no, 8976 had "msm-smmu-v2"
<bamse>
konradybcio: it doesn't matter what hardware it has
<konradybcio>
660 has "arm-smmu-v2 qualcomm we-aren't-paid-enough edition"
<lumag_>
Marijn[m], I think that was 8064
<konradybcio>
8064 has "v0"
<konradybcio>
8994/74 has "v1"
<bamse>
konradybcio: is has nothing to do with how much they are paying for the smmu block, it has everything to do with what they put in the secure world
<lumag_>
Marijn[m], would be great, I did not have time to work on that.
<Marijn[m]>
lumag_: Same thing, I keep mixing up these SoC names and their layout 🥴
<konradybcio>
yeah they made a mess and then backed out of it
<konradybcio>
8250 is much saner
<bamse>
konradybcio: for those early ones, yeah there's hardware limitations as well
<bamse>
konradybcio: anything since 845 seems nice
<bamse>
konradybcio: pretty nice at least ;)
<bamse>
konradybcio: now that we have the qcom workarounds in place
<lumag_>
Marijn[m], you can send those patches per the driver, once any of them are finished. No need to convert all the patches.
svarbanov has quit [Ping timeout: 480 seconds]
<minecrell>
nice but only with workarounds
<minecrell>
so not so nice after all :)
<Marijn[m]>
lumag_: Main issue is adding the helper to clk-provider.h - and first up fixing formatting issues there. Seems clang-format does a good job but isn't used everywhere consistently
<kholk[m]>
uuuuh... I got spammed to get on IRC immediately!
<Marijn[m]>
kholk: ^^ - iommu is priority -1 :D
<kholk[m]>
so yes we do have fairly ok code for MSM8976 IOMMU, which should be fine for a range of SoCs
<kholk[m]>
as Konrad said, 8953 family and such
<bamse>
kholk[m]: konradybcio wants you to come here and promise that your going to deliver the iommu patches ;)
<kholk[m]>
partially even to 8974
<bamse>
kholk[m]: intersting
<kholk[m]>
bamse: hahahaha well that's another story!
<minecrell>
the 8976 iommu stuff looks pretty much like the 8916 one, at least in the downstream device tree
<kholk[m]>
everyone in SoMainline has access to that code
<kholk[m]>
so I'm not reeeally needed for that :D
<Marijn[m]>
kholk: I'm sure it's public on at least _some_ branch
<kholk[m]>
bamse: jokes apart - for 8974, there's a little more code to add on top
<bamse>
minecrell: the primary thing with that generation is that the stream mapping is not accessible
<kholk[m]>
but not much
<kholk[m]>
I'd expect something like 30 lines or.. something like that - I don't very clearly remember that tho.
<bamse>
minecrell: then we have some intersting freaks, where stream mapping is read-only/write-crash or read-only/write-ignore
<Marijn[m]>
kholk[m]: If it has your S-o-B I might as well send it then ;)
<kholk[m]>
Marijn: you forwardported the code
<bamse>
kholk[m]: it's been a long time since i looked at it, but if you have something i can try to review it
<kholk[m]>
I'm not sure that your forwardport is up on public branches
<z3ntu>
I say yes please to 8974 iommu, it's been a problem for so many years
<bamse>
kholk[m]: that said, if you're going to spend time on something, i would like to see the cpr dt binding update respun :)
<kholk[m]>
by the way, sorry for missing every now and then - job taking my life
<kholk[m]>
yeah Bjorn, I desire to respin that CPR stuff asap
<Marijn[m]>
kholk[m]: I don't remember this causing any conflicts of significance 😅
<bamse>
kholk[m]: i know how it is, even though i'm poking at the kernel on a daily basis...that 8974 iommu has been sitting forever
<bamse>
kholk[m]: nice, because we have some eyes on 8996 right now, so i would like for them eyes to see what we can do based on your patches
<kholk[m]>
8996 CPR?
<bamse>
yes
<kholk[m]>
that's probably gonna require a minimal amount of code to get 100% right on my CPR3/4/H patches
<kholk[m]>
I'll try to find some time asap
<bamse>
kholk[m]: right, i agree with that...so if we can just land the stuff you have, then we should be almost there
<Marijn[m]>
kholk: If I cancel our meetings, woudl that buy you enough time?
<kholk[m]>
Marijn, not really, the meetings would anyway be very short and I could in any case do the CPR stuff while in the meeting
<kholk[m]>
but...
<kholk[m]>
I should be free tomorrow for an hour or two
<kholk[m]>
I think I can do something fast, at least... the CPR stuff was very stupid
<kholk[m]>
meaning that it shouldn't require much time to fix
<kholk[m]>
eventually, if I find that it requires more time than what I have
<kholk[m]>
perhaps I can send it without the YAML stuff
<kholk[m]>
so that the guys can get their hands on my huge code base
<bamse>
kholk[m]: you should come work for me instead, then i could give you hours to work on stuff like this
<kholk[m]>
hehehe
<bamse>
might even get a couple of days ;)
<kholk[m]>
when I was looking for a job, I didn't see any Linaro offer, otherwise I would've gladly applied
<kholk[m]>
so I went for another well known company :P
<bamse>
kholk[m]: damn it
<bamse>
maybe there's a next time :)
<kholk[m]>
maybe :))
<Marijn[m]>
Maybe ^^
svarbanov has joined #linux-msm
<lumag_>
Marijn[m], robclark I think we should hold the https://patchwork.freedesktop.org/patch/453434/ for one cycle, as clock patches are going in only into 5.16. Does that sound good to you?
<robclark>
wfm
<lumag_>
ack
<Marijn[m]>
lumag_: Yeah it might be better to wait out until we're sure all the DT patches landed
<Marijn[m]>
Maybe let Stephen know we're taking it through msm's drm tree, no need for him to pick it up in clk
<lumag_>
kholk[m], msm8998 still needs to be resent because of Rob Herring's comment
<kholk[m]>
lumag_: yeah, I know...
<lumag_>
kholk[m], ok :-)
<kholk[m]>
heh, again sorry for missing every now and then
<lumag_>
n/p :-)
<konradybcio>
bamse will linaro look for any year2 uni student internships next summer? :P
<konradybcio>
speaking of msm8996
<konradybcio>
would be nice to finally pinpoint the cause of sdhci not working, too..
<konradybcio>
as for CPR, 8996 has a specific aging algo that we once stumbled upon and I think Angelo even touched it, but let's first get the driver in
<konradybcio>
so uh don't test 8996 too much on the current revision, or you may see instabilities
<lumag_>
konradybcio, we would be happy to test 8996 CPR support if you have something ready.
<lumag_>
or even not ready :-D
<konradybcio>
i can only vaguely remember something, but I don't think Angelo is very keen on doing anything more than there currently is before the big part gets in.. ..after so many months..
<lumag_>
konradybcio, Yes, I remmember his cover message.
<bamse>
konradybcio: i honestly had missed that we did internships at linaro...but i would be happy to discuss that further with you :)
<konradybcio>
i just started year1 like 11h ago, but i'll surely be up for something after 1st or 2nd semester, i'm on a faculty that's famous for intense learning :p
<bamse>
konradybcio: let's land the cpr as angelo has it right now, just need an ack from Rob on the bindings
<bamse>
konradybcio: didn't know the "school year" started that late
<konradybcio>
academic year starts oct 1 in poland
<bamse>
konradybcio: my kids has been in school for 1.5 month already
<konradybcio>
school year starts sept 1
<bamse>
that said, i don't remember when we started the year at the university in sweden...
<konradybcio>
also didn't know you have kids :P
<bamse>
:)
cxl000 has quit [Remote host closed the connection]
cxl000 has joined #linux-msm
cmeerw has quit [Ping timeout: 480 seconds]
lumag__ has joined #linux-msm
lumag_ has quit [Read error: Connection reset by peer]