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: <20190506084648.GA270@basecamp>
Date:   Mon, 6 May 2019 04:46:48 -0400
From:   Brian Masney <masneyb@...tation.org>
To:     Linus Walleij <linus.walleij@...aro.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 Mon, May 06, 2019 at 08:42:36AM +0200, Linus Walleij wrote:
> 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.

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