Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

[Brian Masney <masneyb-1iNe0GrtECGEi8DpZVb4nw@public.gmane.org>]

On Mon, May 06, 2019 at 08:42:36AM +0200, Linus Walleij wrote:
> On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:
> 
> > mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which
> > is causing this stack trace to be dumped into the system log several
> > times:
> >
> >     WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
> >     [CRTC:49:crtc-0] vblank wait timed out
> >     Modules linked in:
> >     CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191
> >     Hardware name: Generic DT based system
> >     Workqueue: events deferred_probe_work_func
> >     [<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14)
> >     [<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c)
> >     [<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4)
> >     [<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88)
> >     [<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290)
> >     [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40)
> >     [<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140)
> >     [<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c)
> >     [<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4)
> 
> I recently merged this patch:
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b3198c38f02d54a5e964258a2180d502abe6eaf0
> 
> I noticed that DSI is sometimes way slower than a monitor, even  in HS mode.
> On the MCDE this happened on the first screen update, which was slower
> than 50ms.
> 
> Check if your vblanks are simply slow, try bumping this timeout even higher,
> I spent weeks finding this issue which boils down to an assumption that
> the vblank will be fired from something like a monitor at 50 or 60 HZ
> ~20 ms so 50ms seemed like a good timeout at the time.
> 
> On a DSI display this is dubious, absolutely in LP mode, and even
> in HS mode.

That did not fix the issue for me, and I went as high as 5 seconds.
That's good to know though since I would have likely ran into that same
issue down the line.

Brian
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno