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

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb at 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.

Yours,
Linus Walleij