<narmstrong>
konradybcio: looking downstream code, cmd mode pclk calculation is totally different, is there a CMD mode panel working with upstream dsi support ?
<Marijn[m]>
narmstrong: we have Sony xperia 5 on sm8150
<narmstrong>
Marijn[m]: with upstream panel driver ?
<Marijn[m]>
narmstrong: ehh... I haven't ~bothered~ found the time to clean and send it yet
<Marijn[m]>
But I can share it with you
<Marijn[m]>
Sofef01 or sofef03 from Samsung
<Marijn[m]>
(with custom undocumented DCS from downstream 🤮, obviously)
<Marijn[m]>
But it is working, that's why I've been trying to get sm8150 Xperia 1 with DSC 1.1 to work, knowing that the hardware is at least functioning...
<narmstrong>
Marijn[m]: ok good to know ! If you can point me to the panel driver it could help me :-)
anholt has quit [Remote host closed the connection]
anholt has joined #linux-msm
flto has quit [Remote host closed the connection]
<narmstrong>
Marijn[m]: ok so toi had to add massive porches to achieve the right pclk, but with a proper calculation this shouldn’t be needed since porches are unused in cmd mode anyway, only the pclk/bitrate is
flto has joined #linux-msm
<Marijn[m]>
narmstrong: Yep, this panel is also used on the Sony Xperia 10 II (sm6125) where the resulting clockrate from those porches works fine to achieve 60Hz (and the higher rates used here is impossible because its clocks cannot go as high as sm8150)
<Marijn[m]>
narmstrong: thanks for the info, I did not know that yet. I should read up on DSI CMDmode pixel data streaming,that's where I suspect DSC is breaking currently without really having any knowledge in that area. How does cmdmode signify where the border of a scanline and frame is? Or well, those concepts might not make sense as cmdmode is supposed to support ROI/damage-region updates, so arbitrary sizes/areas of pixels?
<Marijn[m]>
In any case, both those phones have different "dsi phy timings" downstream
<narmstrong>
Marijn[m]: yep cmd mode sends the full frame raw directly to the panel controller video ram, so it must be fast enough to avoid tearing
<Marijn[m]>
Raw as in there are no pixels inbetween any of it, except maybe pitch for alignment?
<Marijn[m]>
qcom,mdss-dsi-panel-phy-timings is what I am referring to
<narmstrong>
No idea for that
<narmstrong>
Phy timings are calculated from bitrate
<Marijn[m]>
Looks like downstream precalculates them and puts the values in DT, it writes these random-appearing params to registers straight away
<Marijn[m]>
narmstrong: Are you already looking at the code in mainline that is supposed to calculate pixel / bit (or is it byte?) clock? Should DSI do that based on panel dimensions? And should/does it already take reduced rate for DSC into account?
<Marijn[m]>
narmstrong: maybe it'd make sense to remove the porches entirely from cmdmode panel drivers (the ones we'll have to submit) if it's irrelevant?
<Marijn[m]>
Looks like mainline knows exactly what qcom,mdss-dsi-panel-phy-timings contains/means, now to transpose that and make sure these values are in sync for us at least
<narmstrong>
Yep I’m looking at it, there’s cmd mode panel drivers upstream and they don’t have porches at all
<Marijn[m]>
narmstrong: ack, I don't see any (searching for `.hsync_start` pretty much all hits seem to have extra porches), but Xperia 10II with sofef01 is fine without (neither in hvsync/hvtotal nor the clock property)
<Marijn[m]>
narmstrong: Do you think dsi_link_clk_set_rate_6g, dsi_calc_pclk, dsi_get_pclk_rate and friends should take into account reduced bandwidth for DSC?
<Marijn[m]>
narmstrong: Sony Xperia 5 is not happy without porches though, and sticks at 30fps...