ChanServ changed the topic of #linux-msm to:
pevik has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
swdefrgthfgjhk has joined #linux-msm
Daanct12 has joined #linux-msm
swdefrgthfgjhk has quit []
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
pevik has joined #linux-msm
jhovold has joined #linux-msm
pevik has quit [Ping timeout: 480 seconds]
pevik has joined #linux-msm
pespin has joined #linux-msm
<aka_[m]> lumag: hey
<aka_[m]> regarding question about UBWC, there is some code fuckery on DS where it define UBWC version to apply ubwc format on MDSS reset, otherwise code query UBWC register which is v2 for sure.
<lumag> aka_[m], let me doublecheck the code
<aka_[m]> i quered hw register from running OS and it returned v2
<aka_[m]> qcm don't even have it in dts
<aka_[m]> both are Kamorta family
<aka_[m]> lumag:
<aka_[m]> i assume dpu1 inside 4.19 tree is mainline
<aka_[m]> and i should look into sde code
<aka_[m]> here it query based on dts ubwc version
<aka_[m]> above it query based on register
<aka_[m]> m->ubwc_version is DTS config
<aka_[m]> is reg based
<aka_[m]> ubwc_version = SDE_REG_READ(&c, UBWC_DEC_HW_VERSION);
<aka_[m]> bit fucked if you ask me
<aka_[m]> im more not sure about line widths
<aka_[m]> yet it somehow works so if someone finds something wrong there will be time for fixing
<aka_[m]> how do we know how many spaces we need in yaml?
<aka_[m]> based one one yaml it looks like +2 spaces
<aka_[m]> if we go in
<aka_[m]> thing
<aka_[m]> thing inside
<aka_[m]> thing inside upper one
<lumag> aka_[m], so what the version read from the register ?
<aka_[m]> v2
<aka_[m]> cannot tell now because i haven't run os for a while on it
<aka_[m]> and im almost heading job
<aka_[m]> 10minutes and i have to go
<lumag> ack,
<lumag> Then your code is correct
<lumag> I didn't get your question regarding yaml
<lumag> Basic shift is 2
<aka_[m]> can you take a look on commit where i will align yaml with requirements?
<aka_[m]> i will squash later and maybe today send it once again after i get from job(8h from now)
<lumag> Yep, where is it?
<aka_[m]> last commit is for yaml changes requested.
<aka_[m]> i will recheck it fully once i get home.
<lumag> aka_[m], one nit, lgtm otherwise
<aka_[m]> should
<aka_[m]> $ref: /schemas/display/msm/dpu-common.yaml#
<aka_[m]> be dropped?
<aka_[m]> lumag: ah i see
<aka_[m]> great
<lumag> No, the ref is in place
<aka_[m]> will recheck if everything is fixed after job.
<aka_[m]> Any chance of getting it into 6.2?
<aka_[m]> we are almost at the end of rcs right
<lumag> yes
<lumag> I plan to send the pull request today
<lumag> Maybe tomorrow
<aka_[m]> ok i have to go, bb
<lumag> bb
<aka_[m]> ok dropped phy names in next commit
<aka_[m]> so i won't forget
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-msm
Daanct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
ajhalaney[m] has quit [Quit: Client limit exceeded: 20000]
<aka_[m]> konradybcio: so in hw_catalog i had to switch to lowercase hex right?
<konradybcio> I think that's what we concluded would be fitting with Dmitry and Rob after talking on #freedreno
<aka_[m]> im now like preparing stuff
<aka_[m]> so want be 100% sure
<aka_[m]> *101%
<konradybcio> did you rebase on 8350 and 8450? there's gonna be conflicts otherwise
<konradybcio> i'm waiting with 8996 6350 and 6375 for that precise reason
<aka_[m]> wait a sec
<aka_[m]> i had like next 17-11
<aka_[m]> or something
<konradybcio> 8[34]50 are still on the lists
<konradybcio> but looks like they're almost there
<aka_[m]> are in next
<aka_[m]> or inside lists
<konradybcio> on the lists
<aka_[m]> so now i probably won't send it at the end
<aka_[m]> ok
<aka_[m]> so i will have to redo now on Lumag patches
<aka_[m]> so i should grab latest next, do git am on his and then try to apply mine?
<aka_[m]> konradybcio:
<aka_[m]> i guess lumag is sleeping already
<konradybcio> yes that would be nice
<konradybcio> because - while it's not strictly a requirement that you do this - it's gonna make life easier for both you and fd maintainers
<aka_[m]> well, i don't see a reason to make his life harder if he answer me and provided feedback
<aka_[m]> konradybcio: thing is if it was on someone else patchseries then i won't be sure if it gets in
<aka_[m]> its still quite fucked approach
<aka_[m]> if you make patch on top of someone else and this don't get in then yours won't too
<konradybcio> well i'd say it's pretty sure that both 8350 and 8450 support will be merged modulo some minor review comments
<aka_[m]> wasnt 8350 submitted by Robert Foss?
<aka_[m]> well i see some mentions of 8350 in that series but no 8350 inside code
<aka_[m]> so 8450 is only here
<aka_[m]> and maybe Robert will submit 8350
<aka_[m]> who knows
<aka_[m]> ok so now im cleaning stuff on 1711 and will clone latest next
<aka_[m]> 1h or so
<konradybcio> I mean, ultimately it's the same people working on these things, so it doesn't matter much who sends it
<aka_[m]> same mean Linaro
<aka_[m]> and they are like team working on SoC?
<konradybcio> i meant that there's a group of people working on upstreaming qualcomm socs (conveniently called the qualcomm landing team) inside linaro who work on various IPs and don't get surprised if the series is picked up by somebody else at some point, what matters is that it gets fixed up and merged in
<aka_[m]> About ubwc version because i was asked about ds:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/GMwBYjnYbynyuaaxIdwUSoRR>)
<aka_[m]> fun thing is FLAT have description for fields we don't even appears to "use" there
<aka_[m]> even DP registers
<aka_[m]> but i guess reading them will trick hyp into crashing us
<aka_[m]> i wouldn't be suprised if HW inside was same but it had some software limitation
<aka_[m]> ok time to get going
<konradybcio> wait until you realize sdx55 is a sm8150
<aka_[m]> borked sm8150 with faulty gpu turned into modems
<aka_[m]> wait thats wrong
<aka_[m]> if 8150 had no modem, and sdx55 is 5g modem
<aka_[m]> we are getting into 4th dimension
<konradybcio> either have a modem or have armv8 cpus ;)
<konradybcio> it was 8250 that had an offsite modem though
<aka_[m]> oh really, at the end wasnt it like stupid idea to have separate modem?
<aka_[m]> like power consumption was higher
<konradybcio> yes but 8250 had sdx55m which was.. not the most power efficient
<konradybcio> it's easier to manage thermals on 2 chips than on a single dense one
<konradybcio> lessons learnt from 8994
<aka_[m]> so im gonna grab 22.11 tag right
<konradybcio> doesnt boot
<konradybcio> 18 is the last one that does
<aka_[m]> uh for rebasing patches should be enought
<konradybcio> well yes but testing is good too
<aka_[m]> there shouldn't be much changes outside
<aka_[m]> next is bad for testing, cpufreq is dying on next
<aka_[m]> since forever for me
<aka_[m]> was like 5.19 when i started first?
<konradybcio> that's not very long, 3 releases is manageable
<konradybcio> some of my 8994 patches stuck on 5.verylongago.. not very much..
<aka_[m]> wonder, can i send dts patches still if 6115 dts got into arm64 already?
<aka_[m]> wonder if there is reason
<aka_[m]> had idea of pushing once 6.2 come out
<konradybcio> you can always send patches, when they will be picked up is another topic
<konradybcio> as long as you can manage conflicts
<konradybcio> but since there are others contributing to bengal, i guess it's fine
<konradybcio> aren't*
<aka_[m]> i guess we aren't getting in our ways with Ichernev
<aka_[m]> 8450 applied without issue on next
<aka_[m]> great
<konradybcio> 6375 gpu is starting to give signs of life.. too bad it hangs quickly, this gmu_wrapper stuff is very unfortunate
<aka_[m]> no gmu on sm6115 as you know
<aka_[m]> either on sm6125
<konradybcio> a610 or 619?
<aka_[m]> 10
<konradybcio> i looked into that as well
<konradybcio> it's even worse than 619
<aka_[m]> 6115/6125/6225???
<aka_[m]> all 610
<aka_[m]> Linaro pls do gpu for qcm
<aka_[m]> qcm have a702
<aka_[m]> also should be gmu-less
<konradybcio> well i suppose linaro is doing gmu-less gpus
<konradybcio> From: <konrad.dybcio@linaro.org>
<konradybcio> Subject: hello
<aka_[m]> konradybcio: well, sm6115 dpu applied on top of sm8450 patches without issue
<aka_[m]> fuck
<aka_[m]> im scared dt-bindings title will break once again
<lumag> aka_[m], konradybcio I hope to get 8450 in. 8350... maybe. This depends on Robert, there was some feedback
<lumag> So, feel free to send your changes as well.
<aka_[m]> lumag: so i finished rebasing on top of next+8450
<aka_[m]> applied without issues
<aka_[m]> now just verifying and will send
<lumag> aka_[m], thanks!
<aka_[m]> i bit scared title for dt-bindings will be cut once again
<aka_[m]> format patch break line after 75 in title
<aka_[m]> i won't touch it
<lumag> konradybcio, sdx55 is cortex-a7, while sm8150 is armv8a, so they can not be the same thing
<lumag> Regarding 8350. I'm pushing DSI PHY changes, as they were natural while adding 8450.
<lumag> The rest comes from Robert's series
<aka_[m]> lumag: so have you noticed my comment about UBWC above?
<aka_[m]> we can assume it is v2
<lumag> aka_[m], yes. And I have marked the DPU part as R-B
<lumag> so the only remaining thing are the few fixes for dt-bindings
<aka_[m]> lumag: ok, so i can add your rb in code part before sending right
<aka_[m]> rb was after sign-off?
<aka_[m]> konradybcio: first rb then sign-off?
<lumag> R-B, then S-O
<lumag> BTW: you can change the subject to 'dt-bindings: display/msm: add support for SM6115'
<lumag> It should fit
<aka_[m]> oh great
<lumag> konradybcio, kholk, btw: any updates on tsens vs 8976 (please excuse me if I missed the message).
<lumag> (as a reminder, the question was regarding the slope data)
<aka_[m]> ok i think it won;t be that fast
<aka_[m]> damn
<aka_[m]> I think you can drop clock-names from the MDSS node.
<aka_[m]> so remove clock-names?
<aka_[m]> lumag: uh slope?
<aka_[m]> I recall having this thing changed for msm8976 because i had some crashes with it
<aka_[m]> everywhere 3200
<aka_[m]> instead
<aka_[m]> 8956 had different numbers
<aka_[m]> im not feeling bit down.
<aka_[m]> I had comments of sources not being part of bindings for dpu but i have one comment for that in mdss and it was not commented.
<aka_[m]> then, should i drop clock-names from mdss too?
<aka_[m]> i just want to be done with it and now i freak out
<aka_[m]> s/not//
<lumag> aka_[m], only for the mdss
<lumag> for the dpu they should stay
<aka_[m]> and leave them in example?
<lumag> No, you can remove them from the example too.
<lumag> And from the dts that you are going to submit at some point ;-)
<aka_[m]> and how it will know?
<lumag> Because the driver doesn't care about the particular clocks
<lumag> They are all enabled to get access to registers, etc.
<aka_[m]> ah wait mdss is top block
<aka_[m]> but we only use them in dpu/mdp?
<konradybcio> lumag: 8150 and sdx55 are mostly the same thing, the msm ids are ±1 and register maps are almost identical.. for all I care, qcom might have emulated the slow a7 on something, but I guess we won't find out
<konradybcio> b4 trailers -u -F series-email-id
<konradybcio> aka_: use b4 to apply review tags, specifically
<konradybcio> iirc, off the top of my head
<aka_[m]> lumag: and what about clock items inside mdss yaml where i had:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/amiAejXDvxkVRoTmrXePNnbc>)
<aka_[m]> for dpu it was commented that i shouldnt say from where
<aka_[m]> issue is there is disp AHB in dispcc and gcc
<konradybcio> lumag: I only have 8956, guess we have to rely on what downstream and aka's 8976 device think about it
<konradybcio> You can call them GCC AHB clock and DISPCC AHB clock
<aka_[m]> but this is also bit weird
<aka_[m]> because GCC AHB probably branches out to various AHB
<konradybcio> The GCC AHB allows the AP to talk to the MMSS
<konradybcio> If you gate it, every reg access in MMSS should fail
<aka_[m]> so to what should i change:
<aka_[m]> - description: Display AHB clock from gcc
<aka_[m]> or not change at all
<konradybcio> I.. don't know, Krzysztof is the person to ask, probably
<aka_[m]> as you know i copied other yamls
<konradybcio> That's what everybody does
<aka_[m]> well, i will leave it
<konradybcio> More or less
<aka_[m]> its same way on qcm2290
<aka_[m]> if someone wants he can fix it
<aka_[m]> its too minor to be issue
<aka_[m]> and there is no specific convention on naming
<lumag> aka_[m], in the worst case Krzysztof would ask for additional changes.
<aka_[m]> oh god pls no, im tired already, why these docs related things are worst to get going
<lumag> :-)
<lumag> aka_[m], push it to github, let's do a prereview before you do git send-email
<aka_[m]> okay
<lumag> konradybcio, compare the gcc-sm8150 vs gcc-sdx55. They do not look the same.
<konradybcio> fair
<konradybcio> i'll leave it at 'closely related' then
<lumag> konradybcio, well might be
<aka_[m]> lumag: konradybcio
<aka_[m]> applied straight from .patch
<aka_[m]> /mnt/linux/.output/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.example.dtb: dsi@5e94000: 'phy-names' is a required property
<aka_[m]> From schema: /mnt/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
<aka_[m]> thats wrong i guess?
<lumag> aka_[m], yes, ignore that. The patch missed the patchwork, so I didn't pick it up earlier.
<lumag> It should hit the linux-next tomorrow
<lumag> Just a single comment from my side based on previous krzk's feedback on 8450
<lumag> the rest lgtm
<aka_[m]> so i will remove "clock", in theory if we are under clocks: what else could you mean
<aka_[m]> ok i see on yours 8450