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@xxxxxxxxxxxxx> 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
