[PATCH RFC v2] drm/msm/mdp5: enable autorefresh

Brian Masney masneyb at onstation.org
Wed Jan 1 03:50:27 UTC 2020


On Sun, Dec 29, 2019 at 09:00:53PM -0500, Brian Masney wrote:
> Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
> support"), command-mode panels began throwing the following errors:
> 
>     msm fd900000.mdss: pp done time out, lm=0
> 
> Let's fix this by enabling the autorefresh feature that's available in
> the MDP starting at version 1.0. This will cause the MDP to
> automatically send a frame to the panel every time the panel invokes the
> TE signal, which will trigger the PP_DONE IRQ. This requires only
> sending a single START signal for command-mode panels.
> 
> This gives us a counter for command-mode panels that we can use to
> implement async commit support for the MDP5 in a follow up patch.
> 
> Signed-off-by: Brian Masney <masneyb at onstation.org>
> Suggested-by: Jeffrey Hugo <jeffrey.l.hugo at gmail.com>
> Fixes: 2d99ced787e3 ("drm/msm: async commit support")
> ---
> Changes since v1:
> - Send a single start command to kick off the pipeline.
> 
> The reason I marked this patch as a RFC is that the display during some
> small percentage of boots will stop updating after a minute or so, and
> the ping pong IRQs stop. Most of the time it works with no issues and I
> haven't been able to find a way to reproduce the issue. I tried
> suspending the phone by toggling /sys/power/state since I thought that
> the issue could potentially be related to power management.

After working to get the IOMMU up on msm8974, I suspect that the issue
that I describe above is caused by a device probe deferral, which
explains the intermittent nature of what I'm seeing. First driver load
sets up the autorefresh registers, sends a single START signal, then a
-EPROBE_DEFER is thrown later on. Second driver load lost the state, and
sends a second START signal and overloads the DSI.

If that's the case, then potentially the solution may be to do
both of the following:

1) Disable autorefresh when the driver is unloaded.
2) Before sending the START signal, check to make sure that autorefresh
   is actually disabled.

I likely won't be able to work on any this until Sunday evening.

Brian



More information about the dri-devel mailing list