dri-devel May 2018

dri-devel@lists.freedesktop.org

268 participants
1833 discussions

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #27 from todd (toddsmb(a)gmail.com) --- @Chen After seeing a few responses from people I'm starting to see that this is definitely not a video driver specific issue. Not everybody is using Nouveau. I suspected it wasn't from the start because the default generic video driver for Nvidia (Nouveau) has not changed from the start of fedora 27 to the end of fedora 27, and the problem didn't start until an update somewhere in the middle. So Nouveau was never updated, yet the problem started with a newer kernel. But that could be a coincidence. So I just checked the update history on this machine and found that on 2018-02-17 there was a kernel update to 4.15.3 and there was also another important update that day which could very well be the problem. xorg-x11-server-Xorg and xorg-x11-server-common I had been out of town for a while and thus missed all updates from 4.14.16 to 4.15.3 So any packages between then I don't have a listing for. With that in mind I remember that the problem does not exist if you restart X or if you boot into text mode and then manually startX. Plus because Paul just stated that he is using KDE than I guess that pretty much eliminates the desktop environment because I use Xfce. So I think you're right. We need to report this over at freedesktop bugzilla as well. Great, more work :( I already started a post at bugzilla fedora, they said its likely kernel related so my post was closed with a note to post at bugzilla kernel. Now I gotta start a 3rd one. If I had lots of time I wouldn't mind. Perhaps we can con you into starting one over there. If you do, please post link to it. Otherwise When I get more time I will. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[PATCH v9 0/2] Enabling content-type setting for HDMI displays.
by StanLis 08 May '18

08 May '18

From: Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com> Added content type setting property to drm_connector(part 1) and enabled transmitting it with HDMI AVI infoframes for i915(part 2). Stanislav Lisovskiy (2): drm: content-type property for HDMI connector i915: content-type property for HDMI connector Documentation/gpu/drm-kms.rst | 6 +++ Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/drm_atomic.c | 4 ++ drivers/gpu/drm/drm_connector.c | 74 ++++++++++++++++++++++++++++ drivers/gpu/drm/drm_edid.c | 55 +++++++++++++++++++++ drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 24 ++++++--- include/drm/drm_connector.h | 12 +++++ include/drm/drm_edid.h | 6 +++ include/drm/drm_mode_config.h | 5 ++ include/uapi/drm/drm_mode.h | 7 +++ 11 files changed, 189 insertions(+), 6 deletions(-) -- 2.17.0

3 5

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #26 from Chen Yu (yu.c.chen(a)intel.com) --- If this is highly connected with video driver, then bugzilla freedesktop might be a better place to track this bug down since I've seldom seen any graphic driver people jumped into kernel bugzilla to track issues, and they prefer using freedesktop(at least for i915) AFAIK. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #25 from todd (toddsmb(a)gmail.com) --- I wish they let us edit our posts here. I realized I made a mistake in number 3 of comment #22. It should say "your systems default video driver" instead of Nouvaeu. Also if you're using a GPU other than Nvidia than you will obviously need to find a Intel, or AMD driver you can attempt to install. Sorry for the confusion. @paul. Thanks for info. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

1 0

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #24 from Paul van Maaren (kernel(a)vanmaaren.org) --- My laptop does not have Nvidia, and I still have the same issue. I am using F28 and KDE Plasma. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[PATCH] drm/syncobj: Use dma_fence_wait for the simple wait case
by Chris Wilson 08 May '18

08 May '18

When waiting for a single fence beneath a syncobj, forgo our open coding for waiting over multiple fences and call the driver specific dma_fence_wait_timeout(). This gives the opportunity for the driver to handle it more efficiently then the lcd of signal callbacks, and avoids the temporary allocations and array iterations. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> --- drivers/gpu/drm/drm_syncobj.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index d4f4ce484529..c0f787f7a298 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -695,6 +695,14 @@ static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, signed long ret; uint32_t signaled_count, i; + /* KISS for the common case of waiting for a single submitted fence. */ + if (count == 1 && (fence = drm_syncobj_fence_get(syncobjs[0]))) { + ret = dma_fence_wait_timeout(fence, true, timeout); + dma_fence_put(fence); + *idx = 0; + return ret; + } + entries = kcalloc(count, sizeof(*entries), GFP_KERNEL); if (!entries) return -ENOMEM; -- 2.17.0

2 1

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 --- Comment #23 from todd (toddsmb(a)gmail.com) --- I'm also curious what desktop environment you guys are running? I.E. Awesome, Cinnamon, Enlightenment, GNOME, KDE Plasma, LXDE, MATE, Openbox, Ratpoison, Xfce, ETC. Thank you. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '18

08 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 todd (toddsmb(a)gmail.com) changed: What |Removed |Added ---------------------------------------------------------------------------- Kernel Version|4.15.x |4.15.x and 4.16.x --- Comment #22 from todd (toddsmb(a)gmail.com) --- @Chen, I'm going to be tied up for a few weeks, due to a larger than normal workload. So I won't have time to mess with this bug right now. In the mean time I will try blacklisting all vid drivers and see what happens. Although I suspect it will act the same as when the X display manager is disabled by setting multi-user.target. But I know it won't be any time this week. Maybe mid next week if I'm lucky. For the time being though, there are 3 work-arounds listed here that fix the problem. 1) Change runlevel from 5 to 3 (permanent fix - see opening post + comment #6). 2) Restart your X display manager once you log in. For instance Xfce spins use Lightdm. (Temporary fix that lasts until the system is rebooted). * See comemnt #16 3) Install another video driver and blacklist Nouveau (permanent fix but a big hassle if you run secure boot). * see comment #5 for manual Nvidia driver install or see comment #7 for external repository to install Nvidia driver. I personally don't know anything about the repo listed in comment #7. Whereas in comment #5, you are downloading directly from Nvidia themselves. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[BUG] drm/vc4: vblank wait timed out
by Stefan Wahren 07 May '18

07 May '18

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? Best regards Stefan

3 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2018