On Freitag, 6. Oktober 2023 19:15:26 CEST Dmitry Baryshkov wrote: > On Fri, 6 Oct 2023 at 19:26, Luca Weiss <luca@xxxxxxxxx> wrote: > > On Freitag, 6. Oktober 2023 15:38:51 CEST Dmitry Baryshkov wrote: > > > On 29/09/2023 23:52, Luca Weiss wrote: > > > > On Samstag, 23. September 2023 23:49:10 CEST Dmitry Baryshkov wrote: > > > >> Experimental support for MSM8953, which has MDP5 v1.16. It looks like > > > >> trimmed down version of MSM8996. Less SSPP, LM and PP blocks. No DSC, > > > >> etc. > > > > > > > > Hi Dmitry, > > > > > > > > As written on IRC, on sdm632-fairphone-fp3 with this DPU patches the > > > > screen is initializing and displaying stuff :) But there's some > > > > errors, > > > > which presumably are the reason that the screen is only updating a few > > > > times per second. > > > > > > > > [ 22.774205] [drm:dpu_kms_hw_init:1164] dpu hardware > > > > revision:0x10100000 > > > > [ 23.099806] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:657] [dpu > > > > error]enc31 intf1 ctl start interrupt wait failed [ 23.099821] > > > > [drm:dpu_kms_wait_for_commit_done:495] [dpu error]wait for commit done > > > > returned -22 > > > > > > > > These messages appear about 13 times per second but as I mentioned, > > > > the > > > > screen *is* updating (slowly) there. > > > > > > For my understanding, does it work with the MDP5 driver? > > > > Not perfectly, but it does work. What I mean is that the panel is running > > at 30Hz (shown e.g. with kmscube) instead of the 60Hz it should run at. > Interesting. If you have register dumps, it might be interesting to > compare them. > For DPU you can get them from debugfs/dri/0/kms. For MDP5 it is > necessary to hook snapshotting first. The patch will be appreciated > though ;-) Hi Dmitry, Unfortunately I can't offer anything here, and I definitely have no clue how I would hook up the snapshotting on mdp5 ;) > > Also, the CTL timeouts look familiar to what we saw on the FP while > hacking it. I can suppose that it is a generic issue, just manifesting > more visibly on the older platforms. > > > One of the comments I got is that mdp5 is essentially unmaintained so I > > should try DPU ;) > > I'd say, it is mostly in the fixes-only mode. > > > Also I can ask someone with a video-mode panel to test, maybe it works > > better there. At least good to have more data points? > > Yes, please. Testing video panels would prove that the whole pipeline > is working and we have only CMD-related issues. So I asked someone with a msm8953 device with video mode panel and they said it worked :) There appears to be some messages like this when you power off/on the display > [ 236.302432] msm_dsi 1a94000.dsi: [drm:dsi_cmds2buf_tx [msm]] *ERROR* wait for video done timed out > [ 236.382427] msm_dsi 1a94000.dsi: [drm:dsi_cmds2buf_tx [msm]] *ERROR* wait for video done timed out But this might be also a panel driver issue or something. But after a bit it seems to recover and everything's running fine afterwards again. Apparently with mdp5 e.g. these errors exists also so nothing's flawless. > [ 66.104403] [drm:mdp5_irq_error_handler [msm]] *ERROR* errors: 04000000 > [ 77.396452] [drm:mdp5_irq_error_handler [msm]] *ERROR* errors: 04000000 > [ 79.941532] [drm:mdp5_irq_error_handler [msm]] *ERROR* errors: 04000000 > [ 544.170901] [drm:mdp5_irq_error_handler [msm]] *ERROR* errors: 04000000 But apparently other than that it's running fine. Another quote: "and it can wake up just little bit slower" So generally I'd say it's fine on video mode, just broken in cmd mode - at least on my panel. Also in the meantime I've figured out my "panel stuck on 30Hz issue", the panel driver didn't call mipi_dsi_dcs_set_tear_on so no TE signal was sent from the panel to the mdss, so some fallback code in Linux was only running it at 30Hz then. Regards Luca > > > Regards > > Luca > > > > > > Also you for sure forgot to add "qcom,msm8953-mdp5" to the > > > > msm_mdp5_dpu_migration list, without this DPU is never even considered > > > > for > > > > 8953.
