GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

Hi,

On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:
> Hi,
> 
> I'm having issues with the GPU/DRM drivers on a msm8916 based platform
> which is very similar to the DragonBoard 410c. In my setup, a DSI
> display is directly connected to the SoC, and the video link is stable.
> 
> However, when the host sends DCS commands down to the DSI panel (for
> instance to set the backlight brightness), the image drops out, most of
> the time only in terms of a short flicker, but sometimes it will
> completely kill the image. In the latter case, only restarting the
> Wayland compositor in userspace helps. This is also quite reproducible;
> sending a NOP command once a second would give a visual flicker in 90%
> of the cases, and it needs at most a minute to make the screen turn black.
> 
> The interesting thing is that this used to work in a v4.9 based version,
> but it broke somewhere on the way to v4.14. Unfortunately, the platform
> does not boot a vanilla kernel, so I can't really bisect this. We
> currently depend on the Linaro downstream patches which can be found here:

The major change that happened between qcomlt-4.9 and qcomlt-4.14 from a 
DSI point of view was probably the addition of runtime PM support.

The register configurations that are responsible for interleaving DCS
commands while video mode is still on should be the same.

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().

Does your device initialize a splash screen in the bootloader?

You could also compare the reg dumps between 4.9 and 4.14 by enabling
the config CONFIG_DRM_MSM_REGISTER_LOGGING and check if there are
any register configuration differences between the two.

One (rather unlikely) possibility I can think of is if somehow the
buffers used to send/receive DCS commands aren't mapped/unmapped
correctly. There have been some msm_gem changes, and the IOMMU driver
is new. That's the main reason why I'm wondering if the contents of the
DCS buffers somehow got corrupt. Is the panel initialized using DCS
commands too?

Thanks,
Archit

> 
> 
> http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.9
> 
> http://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=release/qcomlt-4.14
> 
> I've looked at the development that has happened in the area for some
> time now, but I can't really pin-point any specific commit. Also, I
> cherry-picked most of the patches to these drivers that came in after
> v4.14, but that didn't help either.
> 
> Has this has been observed before? A pointer what to investigate on
> would be very much appreciated. If there is any more information I can
> provide, please let me know.
> 
> 
> Thanks,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>