GPU/DRM issue with DSI commands on msm 8916

Daniel Mack daniel at zonque.org
Mon Apr 16 17:06:23 UTC 2018


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


More information about the dri-devel mailing list