| Message ID | 20240225-fd-dpu-debug-timeout-v3-1-252f2b21cdcc@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | drm/msm/dpu: debug commit_done timeouts | expand |
On Sun, 25 Feb 2024 at 21:44, Abhinav Kumar <quic_abhinavk@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. > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@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; > > } > > > >
On 2/25/2024 12:57 PM, Dmitry Baryshkov wrote: > On Sun, 25 Feb 2024 at 21:44, Abhinav Kumar <quic_abhinavk@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_abhinavk@quicinc.com> >> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@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; >>> } >>> >>> > > >
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; }
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. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)