Re: GPU/DRM issue with DSI commands on msm 8916

[Daniel Mack <daniel@zonque.org>]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel