From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D773C04AAB for ; Mon, 6 May 2019 08:46:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 62375205C9 for ; Mon, 6 May 2019 08:46:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=onstation.org header.i=@onstation.org header.b="MbrvW8fl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726304AbfEFIqu (ORCPT ); Mon, 6 May 2019 04:46:50 -0400 Received: from onstation.org ([52.200.56.107]:48060 "EHLO onstation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbfEFIqu (ORCPT ); Mon, 6 May 2019 04:46:50 -0400 Received: from localhost (c-98-239-145-235.hsd1.wv.comcast.net [98.239.145.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: masneyb) by onstation.org (Postfix) with ESMTPSA id ADD7F3E941; Mon, 6 May 2019 08:46:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=onstation.org; s=default; t=1557132409; bh=xI56e4hzg4jsRuD6zEwMlE664g9qNhVDQ6VNP1rTbBo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MbrvW8flOyL19oI0XQSJXHxCE4aknvmEvXhDIrAnh2i+7wuAD1LOHt7sh+PzCSKsZ 6w54mSq6UnjAv9pT7IriI5tFztg2ea6akIdw++qmqmwJAItsPw4o6CkTgYry+K6eqJ bI0/YPJ1okYTxaDvcGPjj3HqDlx8j3eEeBrTA90U= Date: Mon, 6 May 2019 04:46:48 -0400 From: Brian Masney To: Linus Walleij Cc: Rob Clark , Sean Paul , "open list:DRM PANEL DRIVERS" , MSM , freedreno@lists.freedesktop.org, Dave Airlie , Daniel Vetter , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support Message-ID: <20190506084648.GA270@basecamp> References: <20190505130413.32253-1-masneyb@onstation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 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 > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x78/0x8c) > > [] (dump_stack) from [] (__warn.part.3+0xb8/0xd4) > > [] (__warn.part.3) from [] (warn_slowpath_fmt+0x64/0x88) > > [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (mdp5_complete_commit+0x14/0x40) > > [] (mdp5_complete_commit) from [] (msm_atomic_commit_tail+0xa8/0x140) > > [] (msm_atomic_commit_tail) from [] (commit_tail+0x40/0x6c) > > [] (drm_atomic_helper_commit) from [] (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