<aka_[m]>
Marijn: indeed there is more IPC to be shifted, will send v3 tomorrow
<Marijn[m]>
No rush, give other reviewers some time...
<aka_[m]>
yea would like to get things reviewed before v3
<Marijn[m]>
aka_: do you still need me to send MDSS for 8976?
<aka_[m]>
unless iommu drops it doesnt matter much
<aka_[m]>
we cannot utilize mdss without iommu or atleast its not happy there
<aka_[m]>
i will go for rprocs once Otto patches get pushed
<Marijn[m]>
True that... I think Konrad resent it once
<aka_[m]>
CPR maybe but it doesn't work to well with current shedulers
<aka_[m]>
*too
<Marijn[m]>
However, we could have the DTS and just not status=okay it on our boards until the iommu changes land...
<aka_[m]>
i get what you mean
<aka_[m]>
like msm8974 was
<Marijn[m]>
And posting it as a dependency may put some more pressure...
<Marijn[m]>
I was not able to look into the remaining iommu review and changes myself though, it has been too long and DPU needs way too much attention.
<Marijn[m]>
Fortunately Konrad did most of that :)
<aka_[m]>
don't force yourself summer is bad for working
<aka_[m]>
hmm i wonder if this small mismatch of ipcs is reason why wcnss keeps failing
<aka_[m]>
these are intc of remoteprocs
<aka_[m]>
so prob matters a lot
<aka_[m]>
before i had my own base dts so it was working
<aka_[m]>
albeit crashing on idle power save mode
<Marijn[m]>
ungeskriptet: you have a non-DSC dual-DSI cmdmode panel on sm8250 right? I'd love to play some with that before bringing DSC into the mix for my own devices... Did you share a kernel branch (device tree + panel drivers + other patches) before?
<Marijn[m]>
aka_: it's not that hot here... And "summer holiday" isn't exactly a thing anymore
<ungeskriptet>
Yes, it's dual DSI cmdmode panel without dsc
<aka_[m]>
this week is okay but like last one was constant 35C
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
<Marijn[m]>
ungeskriptet: oh nice, that seems to contain my latest changes to DPU, and the panel and dts look good (if you un-comment dsi1)
<Marijn[m]>
ungeskriptet: did you get it to work on dsi0 only, by also changing `has_dual_dsi=false` in the panel driver?
<ungeskriptet>
Marijn[m]: No, I did not try that yet
<Marijn[m]>
Since you commented out dsi1 in dts... you'll also need to change your driver to cope with that
<Marijn[m]>
FWIW I've used the optionality of the port node for that in my driver. If of_graph_get_remote_node() returns NULL there's no second DSI node and I only initialize on dsi0
<Marijn[m]>
(That should probably be an error later as the panel really requires dual-dsi, but helpful for back-to-back testing single vs dual DSI)
<Marijn[m]>
We're not entirely confident that a dual-DSI panel should work on only one half when DSC is involved though... But it should without DSC
<ungeskriptet>
I can try messing with the panel tomorrow
<JIaxyga[m]>
Marijn: Dsc should work on next branch?
<ungeskriptet>
I did however try using the lmdpdg generated driver since it only generates single dsi panel drivers
<ungeskriptet>
But that attempt was unsuccessful too
<Marijn[m]>
JIaxyga: DSC should work perfectly fine after the last round of reviews (as long as you hack the transfer time in the panel driver by pretending they're porches...), but it was developed with a limited scope in mind and not designed for a dual-DSI (or dual-INTF topology for that matter) at all
<Marijn[m]>
I've done multiple passes at implementing that but have yet been unsuccessful
<Marijn[m]>
ungeskriptet: if you generate a half-panel driver (you can also reuse the current one...) be sure to use half-width in the mode
<JIaxyga[m]>
Marijn[m]: It's just that I can test it on surya sm7150 as soon as I'm done with dpu
<JIaxyga[m]>
It uses single dsi as far as I understand
<JIaxyga[m]>
So there shouldn't be a problem
<Marijn[m]>
If it does you should be in luck
<Marijn[m]>
Which DPU revision does it use, is it close to sm8150 (so DPU v5.x)?