Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 31 Dec 2019 22:50:27 -0500
From:   Brian Masney <masneyb@onstation.org>
To:     jeffrey.l.hugo@gmail.com, robdclark@gmail.com
Cc:     freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
        sean@poorly.run
Subject: Re: [PATCH RFC v2] drm/msm/mdp5: enable autorefresh
Message-ID: <20200101035027.GA9348@onstation.org>
References: <20191230020053.26016-1-masneyb@onstation.org>
 <20191230020053.26016-2-masneyb@onstation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191230020053.26016-2-masneyb@onstation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@onstation.org>
> Suggested-by: Jeffrey Hugo <jeffrey.l.hugo@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