dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: agraf@suse.de, dri-devel <dri-devel@lists.freedesktop.org>,
	Stefan Schake <stschake@gmail.com>
Subject: Re: [BUG] drm/vc4: vblank wait timed out
Date: Sat, 5 May 2018 14:24:42 +0200	[thread overview]
Message-ID: <20180505142442.219ae265@bbrezillon> (raw)
In-Reply-To: <193337267.127065.1525520845157@email.1und1.de>

On Sat, 5 May 2018 13:47:25 +0200 (CEST)
Stefan Wahren <stefan.wahren@i2se.com> wrote:

> Hi,
> 
> after submit of the latest bcm2835 clock fixes, i thought this issue has been fixed. But i've seen this issue with current mainline 4.17-rc3 (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP Boot). Strangly i couldn't reproduce this issue with same kernel but using only the Foundation bootloader (without U-Boot TFTP Boot).
> 
> U-Boot version: 2018.03
> 
> I triggered the warning using my HDMI switch:
> 
> [  198.304572] ------------[ cut here ]------------
> [  198.304693] WARNING: CPU: 0 PID: 10 at drivers/gpu/drm/drm_atomic_helper.c:1351 drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0
> [  198.304703] [CRTC:68:crtc-2] vblank wait timed out
> [  198.304751] Modules linked in: bcm2835_rng rng_core vchiq(C)
> [  198.304790] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G         C        4.17.0-rc3+ #1
> [  198.304796] Hardware name: BCM2835
> [  198.304817] Workqueue: events output_poll_execute
> [  198.304867] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24)
> [  198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28)
> [  198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104)
> [  198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50)
> [  198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0)
> [  198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8)
> [  198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c)
> [  198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60)
> [  198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc)
> [  198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144)
> [  198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c)
> [  198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60)
> [  198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4)
> [  198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20)
> [  198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38)
> [  198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c)
> [  198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368)
> [  198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418)
> [  198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c)
> [  198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> [  198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8)
> [  198.305562] 9fa0:                                     00000000 00000000 00000000 00000000
> [  198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [  198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [  198.305630] ---[ end trace 9c4071c657268b83 ]---
> 
> I also dumped clk_summary in both cases, but they were identical.
> 
> Are their any helpful information, which i can provide?

I doubt this will fix your problem, but can you try with this patch
[1] applied?

Also, is u-boot touching PLLH or anything related to HDMI?

[1]https://patchwork.kernel.org/patch/10207159/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-05-05 12:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-05 11:47 [BUG] drm/vc4: vblank wait timed out Stefan Wahren
2018-05-05 12:24 ` Boris Brezillon [this message]
2018-05-05 17:32   ` Stefan Wahren
2018-05-05 17:29 ` Stefan Schake
2018-05-05 17:44   ` Stefan Wahren
2018-05-05 18:00     ` Boris Brezillon
2018-05-05 23:56       ` Stefan Wahren
2018-05-07  7:11         ` Boris Brezillon
2018-05-07 20:30           ` Stefan Wahren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180505142442.219ae265@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=agraf@suse.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=stefan.wahren@i2se.com \
    --cc=stschake@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox