GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

On Monday 09 April 2018 04:28 PM, Daniel Mack wrote:
> Hi Archit,
> 
> Thanks a lot for your reply.
> 
> On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote:
>> On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:
>>> 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.
> 
> Yeah, I think so too. I compared a lot of code but couldn't really find
> anything either. At least, the command buffer contents and lengths are
> identical.
> 
>> 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.

> 
>> Does your device initialize a splash screen in the bootloader?
> 
> It does, but that's the case for either of the two kernels. Do you think
> that matters? And as you mention it - I'm building the driver as module,
> because when built into the kernel, the msm driver fails to initialize
> the hardware, and the console is flooded with the following message:

The bootloader may have configured some additional registers that the
DSI driver in the kernel doesn't touch. On 4.9, these registers would
have retained their state since we don't do any PM stuff. On 4.14, these
registers would probably lose their state, which results in a difference
in behavior. This can be avoided by commenting all the put_sync() calls
as mentioned above.

> 
> [   63.356837] dsi_err_worker: status=4
> 
>> 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.
> 
> I did that, and there a quite a number of changes, mostly because the
> KMS bits have changed a lot. Given that I'm not too familiar with this
> driver stack, I'm not sure what exactly to look at.

Mostly to check if there were any changes in the DSI register writes,
and maybe writes to the MDP5 INTF blocks.

> 
>> 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.
> 
> That may well be, but I can't really see what's wrong in that area.
> Which iommu driver are you referring to, exactly?

On 4.9, this driver is used:
drivers/iommu/qcom

On 4.14 we use:
drivers/iommu/qcom_iommu.c
> 
>> Is the panel initialized using DCS
>> commands too?
> 
> Yes, and that works. The thing is that the commands do in fact reach the
> panel and cause the desired effect, it's just that as a side effect, the
> display very likely drops out when a command is sent. The registers that
> are modified through msm_writel() by and between
> msm_dsi_host_xfer_prepare() and msm_dsi_host_xfer_restore() are exactly
> the same though. So it must be that some other part (the GPU or the
> KMS?) doesn't like the fact that the DSI core mangles with the hardware
> state in some way.

It seems unlikely that sending a DCS command via DSI core would affect
MDP or the GPU. It feels like sending the DCS commands is causing the
DSI lanes to be temporarily in an invalid state, resulting in the
flicker.

> 
> What hardware are all these changes developed and tested on, btw? I
> guess it might be worth looking into differences between these platforms
> and my own.

The releases are mostly tested on DB600c, DB410c and DB820c. On DB410c,
DSI is mostly tested using the hdmi bridge output, and the splash screen
isn't enabled in the bootloader (LK),

Thanks,
Archit

> 
> 
> Again, thanks!
> Daniel
>