<Marijn[m]>
ungeskriptet adomerle Molly Sophia (apologies to anyone I forgot): dual-DSI dual-DSC (via active-CTL) is now working properly on CMD-mode panels! The changes I had to make since reporting an issue at drm/msm are extremely minimal, you'll be surprised :)
<ungeskriptet>
Marijn[m]: Oh wow, thanks a lot for fixing it!
<ungeskriptet>
(Cc: luka177[m])
<Marijn[m]>
jessica_24: might also want to see ^
<Marijn[m]>
And abhinav__ who helped me go through the registers some time, too :)
<Marijn[m]>
Definitely drop the hardcoded clock :)
<Marijn[m]>
At least on cmdmode panels, if you don't forget to include a fake porch (something that resembles a transfer delay) you'll end up with slower frames, but TE should prevent tearing at least
<abhinav__>
Marijn[m] thanks for the investigation, its a bit strange. for bonded dsi, it should be enough only if you flush master, but in your case only flushing both master and slave is working then?
<abhinav__>
similarly by sourcing your clocks from DSI1, you are operating in dual dsi mode not bonded dsi mode then
<Marijn[m]>
Yeah both master and slave INTFs need to be flushed. Reminder that this is an active-CTL platform where things might work differently?
<Marijn[m]>
abhinav__: the assumption is that one of the muxes somewhere is simply wrong, which might cause DSI1 to not tick and never send pixels
<abhinav__>
Marijn[m] we need to program both interfaces but flush only one
<abhinav__>
something is missing .... let me check more and update you
<abhinav__>
regarding DSI1, so usually in bonded DSI case, we need to program the PLL0 to drive two interfaces, I think something is missing in the PLL0 programming then
<Marijn[m]>
abhinav__: indeed seems like it, though I'm currently unable to check the registers downstream. Let me know if there's anything obvious to check/add
<Marijn[m]>
abhinav__: do you remember `dsi_adjust_pclk_for_compression()`? We currently divide the value by 2 in `is_bonded_dsi` _after_ calculation, but maybe we should do that to `mode->hdisplay` before calculation so that the "transfer overhead" remains the same
<Marijn[m]>
Now panel drivers have to account for multiplying it by 2
<abhinav__>
lumag ^^ for you as well, does flushing both interfaces explicitly fix your unstable image issue?
<abhinav__>
Marijn[m] I will cross-check if something was missed with respect to this aspect,
<lumag>
abhinav__, note the video vs CMD difference. In video mode we already flush both of them.
<abhinav__>
lumag we wont hit
<abhinav__>
/*
<abhinav__>
* For single flush cases (dual-ctl or pp-split), skip setting the
<abhinav__>
* flush bit for the slave intf, since both intfs use same ctl
<abhinav__>
* and HW will only flush the master.
<abhinav__>
*/
<abhinav__>
if (dpu_encoder_phys_vid_needs_single_flush(phys_enc) &&
<Marijn[m]>
abhinav__: that quoted comment makes little sense: it says dual-ctl, then later says that both intfs use the same ctl (so there's only one)?
aklimov has joined #linux-msm
<abhinav__>
I think it should be "dual-intf"
<Marijn[m]>
That makes more sense - someone should PR a fix for that :)
pespin has quit []
dliviu has quit []
dliviu has joined #linux-msm
Caterpillar has quit [Quit: Konversation terminated!]