<lumag_>
Marijn[m], not so much time for now for deduplication unfortunately. Getting wide planes and multirect is more important at this point.
<lumag_>
I'm waiting for kholk[m]'s patchset, which would bring in 8998 support into dpu. I hope to be able to test dpu1 on sdm660 at that point (same mdp generation as 8998). The only significant differences to sdm845 being that multirect is supported only on DMA planes and the availability of cursor (= lightweight dma) planes.
<lumag_>
Then can come 8996: older scaler version, which is not supported in DPU at this point, RGB planes (= DMA planes with several additional features), etc.
<lumag_>
This way we can leave mdp5 to support really old hardware (like 8916): cursor implemented through LM registers rather than SSPP plane, SMP, no multirect, etc.
Danct12 has joined #linux-msm
<lumag_>
I'm not sure if we should take the last step of bringing in all hw into dpu. On one hand it seems plausible, to drop the mdp5 driver. This would allow us to merge most of mdp4/mdp5 shared code into mdp4 itself. On the other hand, it would add additional complications to dpu1
<lumag_>
Which is already a bit of nightmare
pevik_ has joined #linux-msm
<deathmist>
lumag_: I'm resending the 8998 dpu patches today as angelo is "a bit busy" still, any preference on which tree I base them on? I'm going for next/master currently after testing
pevik_ has quit [Remote host closed the connection]
pevik_ has joined #linux-msm
<lumag_>
deathmist, I'd prefer msm/next. There should be no significant difference though.
<lumag_>
deathmist, yes, drm tree was merged into the Linus'es tree. So, feel free to choose any of them.
<lumag_>
looks good on the first glance. I'll take a thorough look later.
<lumag_>
thank you
<abhinav___>
Marijn[m]: agree with dmitry, lets hold on to deduplication . in addition to wide planes and multirect, I am also working on adding writeback support to DPU within this month. after that we can take this up
<abhinav___>
lumag_: are there any 8998 specific boards to validate dpu support ? Also since 8998 is one of the few chipsets supporting native HDMI ( after 8996 ) , if someone validates HDMI with this it will be great
<ndec>
abhinav___: my set-top-box at home runs 8998.. but i doubt my kids will let me try something like that ;)
<bamse>
ndec: why, you will still get hdmi out of it!
<ndec>
well, my understand of abhinav___ statement, is that hdmi 'might work' :)
<ndec>
*ing
<bamse>
if it does you will get a shot at the Tested-by toplist, if it doesn't...well you have a nice oppotunity to fix it :)
<lumag_>
Samsung Galaxy S8 uses 8998 and it has HDMI adapter
<bamse>
but is that native hdmi?
<bamse>
well presumably they run the hdmi lines to some mux thing...
<lumag_>
I'd suppose it it (using slimport)
<Mis012[m]>
the msm8998 HDMI also lets you mux the i2c lines as BLSP i2c and the HPD as an interrupt, which would be really cool if anyone actually bothered to put a plain HDMI port on something with DP alt mode :P
<aka_[m]>
uh isnt slimport some proprietary stuff from idk analogix?
<aka_[m]>
and these old ANX chips were mostly secondary dsi interface->anx->some usb glue
<bamse>
lumag_: sounds plausible to get working then
<Mis012[m]>
I think slimport becomes HDMI again on the other side, so if it's transparent enough it should work
<lumag_>
It should be either slimport or DP, but I don't think think 8998 had DP.
<aka_[m]>
it should all newer chips have DP inside soc
<Mis012[m]>
8998 had has alt mode, not standalone DP
<Mis012[m]>
*has
<Mis012[m]>
s/had// I mean
<bamse>
aka_[m]: 8084 had native dp...
<lumag_>
aka_[m], I think nexus7 (8064) had HDMI -> anx -> SlimPort
<bamse>
or edp perhaps?
<bamse>
native still though
<lumag_>
8074/8084 had eDP
<Mis012[m]>
pretty sure 8998 has native DP with alt mode, but no standalone DP
<aka_[m]>
Mis012[m]: so you mean by there is no directly dp connector somewhere?
<Mis012[m]>
yep
<bamse>
aka_[m]: there's actually no DP PHY either, if that's the case
<lumag_>
ah. S8 has Type-C
<aka_[m]>
type-c is just connector >_>
<Mis012[m]>
there is are HDMI pins though, which are probably easier to retrofit a connector to than the PCI-E pins :P
<bamse>
aka_[m]: so you have USB and DP controllers both connected to the same PHY, which will mux out signals depending on negotiated mode
<Mis012[m]>
right, they call is DPUSBPHY or USBDPPHY iirc xD
<abhinav___>
8998 supported HDMI and DP
<Mis012[m]>
*it
<aka_[m]>
uh i know there is DP PLL which is connected to DPU? and then to usb3 dwc(?)
<Mis012[m]>
they probably can't use the DWC PHY though
<bamse>
aka_[m]: both of those deals with the "digital" part of USB and DP
<Mis012[m]>
that one is USB only
<Mis012[m]>
bamse: pretty sure DWC offers a PHY as well
<bamse>
Mis012[m]: the dwc phy deals with high speed usb...the qmp is typically what's used to deal with the superspeed lines, which can either carry usb or dp (or hdmi etc) traffic
<bamse>
Mis012[m]: yes they do
<Mis012[m]>
bamse: you probably didn't hear my rant about AMD is doing with DWC USB IP cores did you
<Mis012[m]>
safe to say x86 is sed
<aka_[m]>
out of curiosity can one just merge few commits out of entire patch serie to next?
<aka_[m]>
Or all patches in serie have to be merged at once?
<lumag_>
aka_[m], it depends.
<aka_[m]>
lets say Luca's msm8953&fairphone commits.
<aka_[m]>
its bunch of dt-bindings but not all apply
<bamse>
aka_[m]: there's nothing preventing a maintainer from picking parts of a series, we do it all the time
<bamse>
aka_[m]: but if part of the series doesn't apply, it's quite likely that said maintainer will ignore you, instead of trying to figure out what parts is applicable
<aka_[m]>
and whats best way to ensure it all apply?
<aka_[m]>
Do it based on latest -next?
<konradybcio>
https://pastebin.com/W2a9NMtk this took me almost 200 lines of debug prints and a year to find, but it fixes nand problems on mdm9607..
<konradybcio>
otherwise dma gets locked up and everything drops registers and the cpu commits sepuku
<Mis012[m]>
is that the pinephone "totally just a modem"?
<konradybcio>
btw the "it took me a year" is not ironic, it's actually almost a year to the day..
<bamse>
aka_[m]: make it easy for the maintainer to just click "merge"
<konradybcio>
yes, the pinemodem
<aka_[m]>
bamse: oh so you guys have fancy GUI tools for that.
<bamse>
i have a shortcut in mutt
<Mis012[m]>
konradybcio: since it uses test keys, I hope someone is working on u-boot already :P
<konradybcio>
i'd rather get useful linux on it before playing with bootloaders
<konradybcio>
stock lk is not terrible, it can jump to linux and that's all it needs to do
<Mis012[m]>
u-boot can replace the other parts as well
<Mis012[m]>
so sbl, then you have ATF for TZ,,,
<Mis012[m]>
*...
<konradybcio>
then edk2 for win10iot :)
<Mis012[m]>
🤮
<lumag_>
abhinav___, for 8998 we never ported HDMI support. So one would have to do that before testing mdp5 or dpu with hdmi
<lumag_>
abhinav___, which platform were you using when writing 8998 hdmi support downstream?
<abhinav___>
lumag_: i used the same board ndec is referring to as I had done most of the hdmi development work on that product
<abhinav___>
lumag_: yes, I am aware we need to port hdmi support to DPU. so far i was not aware of any upstream based board
<lumag_>
abhinav___, porting to DPU would be easy.
<ndec>
abhinav___: it's not using the native hdmi on this product, no? isn't there a bridge?
<lumag_>
porting to 8998 would be an interesting task :-D
<abhinav___>
ndec: on 8998 its native HDMI
<abhinav___>
no bridge
<lumag_>
abhinav___, some kind of set-top-box?
<bamse>
lumag_: 1-2 years ago we discussed getting 8998 in shape upstream, but that discussion evaporated
<konradybcio>
cpr/cpufreq/spm was sent 1-2y ago :P
<konradybcio>
btw we have an icc driver for 8998, expect it on the lists soon, have to rebase it against next
<ndec>
lumag_: a french isp is using 8998 on their set top box, which happens to be the one i have.. they have publicly announced the soc they use. they even have a kernel patchset :)
<lumag_>
:-D
<bamse>
konradybcio: sounds good, and whenever angelo can resubmit the cpr/cpufreq stuff my promise to review that still stands
<bamse>
konradybcio: although it's been a while now, so it will be some more work to refresh my memory on that platform...
<bamse>
aka_[m]: so to be more concrete, makes sure your patches applies on linux-next and if some subset can be merged while other parts can't yet because of some external dependency, just split it in multiple series
anholt has quit [Remote host closed the connection]