Hi Archit, On Monday, April 09, 2018 03:08 PM, Archit Taneja wrote: >>> You could comment out the pm_runtime_put_sync() calls in >>> drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got >>> reset during put_sync and weren't restored correctly after get_sync(). >> >> That was my first suspicion too, but unfortunately, that's not the culprit. >> I think it would be good to comment out the put_sync() calls in > drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c and > drivers/gpu/drm/msm/msm_drv.c too, since there is a parent-child > hierarchy between DSI > and the top level MDSS block. Commenting out the put_syncs() just > in put_sync() might still result in the MDSS GDSC to switch off. I spent some more time debugging this today and it turns out that calling into dsi_link_clk_enable() from msm_dsi_host_xfer_prepare() is already causing the drop-outs, even when no command buffers, DMA transfers etc. are involved. I then drilled further down and it showed that at least clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate); in dsi_link_clk_enable_6g() one of the culprits. If I don't touch the clocks anymore after the initialization is done, everything is fine. That rules out all other components such as GPU and IOMMU, but I still don't grok what's going on, because I can't see a big difference in the relevant clock functions in the dsi driver and the clock drivers between 4.9 and 4.14. Any idea? I'll do some more debugging tomorrow. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
