On 2/25/2024 12:57 PM, Dmitry Baryshkov wrote:
On Sun, 25 Feb 2024 at 21:44, Abhinav Kumar <quic_abhin...@quicinc.com> wrote:



On 2/25/2024 6:12 AM, Dmitry Baryshkov wrote:
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
To allow us to identify the DPU block that gets stuck, include the
actual CTL_FLUSH value into the timeout message.


the flush register shall also be part of the coredump in patch 3. so why
is this needed?

I'd prefer to keep it. The devcoredump captures all registers, while
CTL_FLUSH points to the actual bit without the need to analyze the
coredump. At the very least, it allows us to analyze whether the issue
is the same or not (compare SSPP_DMA2 on c630 vs LM_1 on sdm660)
without looking into the dump.


Ok, sg


Reviewed-by: Abhinav Kumar <quic_abhin...@quicinc.com>


Signed-off-by: Dmitry Baryshkov <dmitry.barysh...@linaro.org>
---
   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 2aa72b578764..6058706f03e4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -480,7 +480,7 @@ static int dpu_encoder_phys_vid_wait_for_commit_done(
               (hw_ctl->ops.get_flush_register(hw_ctl) == 0),
               msecs_to_jiffies(50));
       if (ret <= 0) {
-             DPU_ERROR("vblank timeout\n");
+             DPU_ERROR("vblank timeout: %x\n", 
hw_ctl->ops.get_flush_register(hw_ctl));
               return -ETIMEDOUT;
       }





Reply via email to