ChanServ changed the topic of #linux-msm to:
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]
Daanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
anholt has quit [Remote host closed the connection]
mani_s- is now known as mani_s
anholt has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daaanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
<aka_[m]> lumag: sorry for interrupting, any ideas on when dpu bindings get merged?
<aka_[m]> I see Robert send 8350 and it might get bit messy when multiple ppl would like to send hw_catalog changes.
<aka_[m]> I guess sdm730 guys would want to get something too
<lumag> aka_[m], I plan to start collecting patches for 6.2 early next week, so I'd pull it in.
<aka_[m]> ok great, any chance to get anything in after you are done with that?
<aka_[m]> based on feedback on Robert's patches DPU/MDSS part should be separate commits right?
<lumag> 8350 missed the bindings altogether. sc8280xp bindings were based on older bindings, but I hope bamse will rebase/rework his patches on top of the mentioned series
<lumag> aka_[m], ideally yes. Also it would give krzk/robh the ability to review them separately.
<lumag> and for the driver parts too. The mdss is a generic part now, so it can come in a separate patch.
<lumag> Note: I intend to get https://patchwork.freedesktop.org/patch/489578/?series=105162&rev=1 in, so that there will be less magic.
<aka_[m]> i will have code addition there too
<aka_[m]> for ubwc format hardcoding?
<aka_[m]> or something
<lumag> yes
<lumag> Maybe it would make sense to move this to some kind of per-binding data. This would imply that each new platform should get an entry there
<aka_[m]> so in future i guess we might have easy 3 or 4 dpu version additions.
<aka_[m]> SM6115/SM7150/SM6125
* lumag is looking forward for those patches
<konradybcio> 8996 6350 6375 too 😝
<konradybcio> though the latter two still await some dpu changes
<aka_[m]> good im content with stuff which is already in
<lumag> :-)
<aka_[m]> only this 14nm phy byte_intf stuff but maybe org author will send it once again
<lumag> aka_[m], the div by two?
<aka_[m]> yea
<lumag> I need to find the time and peace, to sit and to check older kernels for this particular item.
<lumag> Or somebody can go over them and verify the patch.
<lumag> The problem for me was that it touches 8916, but we are 100% sure that 8916 works
<aka_[m]> isnt 8916 28nm phy?
<aka_[m]> and byte vs byte_intf
<konradybcio> yes 8916 is 28
<aka_[m]> sdm660 is 14nm and appears to ship with it
<aka_[m]> there probably was something with that clock as it got some comment on it
<lumag> aka_[m], konradybcio I think the patch claimed that this should be done for all the PHYs >= 14nm
<aka_[m]> issue versioning on downstream is different
<aka_[m]> other phys which are lower than 14 are unaffected
<lumag> Lower than 14nm yes.
<lumag> Starting from sdm845
<aka_[m]> and only few of 14nm have byte_intf clock from clock controller
<lumag> So, the question is open at least for 8996 and 660
<aka_[m]> not sure about 8996 but indeed 660
<lumag> 8996 is v1, so it doesn't have the byte_intf clock
<lumag> I think 8998 might also have v2, but we don't have dsi support on that platform
<aka_[m]> best probably would be to observe what android does
<lumag> iow, check downstream
<lumag> aka_[m], on which platform do you observe the issue?
<lumag> I went through and checked downstream kernels.
<lumag> The original ones working with 8998 & 660 (4.4) and later kernel didn't have such logic.
<lumag> It was added only in the display techpack.
<lumag> abhinav__, do you have any additional information on this topic ^^
<lumag> So, anyway, what I would suggest: add byte_intf_div to shared timings, return 2 or 1 there, depending on the PHY type, then pass the divider to the ops->link_set_rate function.
<lumag> This way we can have fine grained control over the divider, which would allow us to experiment.
<Marijn[m]> > <@aka_:matrix.org> lumag: sorry for interrupting, any ideas on when dpu bindings get merged?... (full message at <https://matrix.org/_matrix/media/r0/download/matrix.org/HhWPYuFGSxqcNyoVbZDoflbA>)
<Marijn[m]> > <@aka_:matrix.org> so in future i guess we might have easy 3 or 4 dpu version additions.
<Marijn[m]> > SM6115/SM7150/SM6125
<Marijn[m]> What's the plan, replace the `hw_rev` `switch`-`case` with a per-SoC/platform match?
<lumag> Marijn[m], Yes, seeing that it's too easy to miss the switch when adding the mdss entry, I think it would be useful to move the parameters to the match->data
<Marijn[m]> lumag: Yeah I must've also missed it, seems so simple to just look at the catalog which is self-contained... Turns out we have another switch on `HW_VER` elsewhere...
<Marijn[m]> Can we somehow move that into the catalog list to make this more obvious?
<lumag> Marijn[m], Yeah, abhinav asked this. But I see no good way to do this. The msm_mdss module is used both with mdp5 and dpu drivers.
<lumag> So it can not look into dpu catalog
<konradybcio> lumag does db820c boot for you on recent next?
<lumag> konradybcio, I haven't tried -next itself.
<konradybcio> my 8996 just so happens to randomly die after mmc probes..
<lumag> konradybcio, try maxcpus=2
<konradybcio> tried =1
<konradybcio> and without cpu clocks
<konradybcio> and opps
<konradybcio> also tried clk/pd_ignore_unused and disabling regulator cleanup
<lumag> disable adsp/mss_pil
<konradybcio> disabled
<lumag> Hmm.
<konradybcio> well it's gonna take some bisecting then
<lumag> ack
<konradybcio> (unless it randomly decides to work next time i pull it out of the drawer)
<Marijn[m]> lumag: In that case we may need to split the tables? It starts with HW ver 5,0,0 anyway which is sm8150, nothing above that uses mdp5 anyway right?
<lumag> Unfortunately the 820 is a foster child. I have spent several last months looking into its power system and related items.
<lumag> Marijn[m], I'd probably prefer a small local version of hw catalog, including just ubwc ver & related parameters.
<lumag> Tied into the of_device_id.data
<Marijn[m]> lumag: or can we generalize the hw catalog to work for all drivers?
<lumag> Marijn[m], ugh
<lumag> please no
marvin24 has quit [Ping timeout: 480 seconds]
marvin24 has joined #linux-msm
<anholt> thinking of db820c, did I hear some stuff recently about mmu work on it? any hope of per process page tables?
anholt has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
<aka_[m]> <lumag> "aka_, on which platform do you..." <- Just like Loic(?) SM6115 for me and Qcm2290 for him(same base design)
<aka_[m]> Display in video mode based on Novatek Nt36672 controller or something
<aka_[m]> Could anyone with 660 get clock rate for dsi clocks?
<aka_[m]> 6125 owners claims its working
<aka_[m]> And 6150 has no known mainline fork
anholt has joined #linux-msm