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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkda=JTfKC4z=1Gmt1BE5adwd8XGZ4ERTgapWX_BN9TFESw@mail.gmail.com>
Date:   Mon, 6 May 2019 08:42:36 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Brian Masney <masneyb@...tation.org>
Cc:     Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        freedreno@...ts.freedesktop.org, Dave Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

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