dri-devel February 2020

dri-devel@lists.freedesktop.org

302 participants
679 discussions

[PATCH v3] drm: shmobile: Reduce include dependencies
by Andy Shevchenko 13 Oct '20

13 Oct '20

This file doesn't need everything provided by <linux/kernel.h>. All it needs are some types, which are provided by <drm/drm_mode.h>. Drop unneeded <linux/kernel.h> completely. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- v3: Drop header completely (Laurent) include/linux/platform_data/shmob_drm.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/platform_data/shmob_drm.h b/include/linux/platform_data/shmob_drm.h index … [View More]

3 3

[PATCH] drm: aspeed: Fix GENMASK misuse
by Ondrej Jirman 09 Oct '20

09 Oct '20

Arguments to GENMASK should be msb >= lsb. Signed-off-by: Ondrej Jirman <megous(a)megous.com> --- I just grepped the whole kernel tree for GENMASK argument order issues, and this is one of the three that popped up. No testing was done. drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx.h b/drivers/gpu/drm/aspeed/aspeed_gfx.h index a10358bb61ec4..095ea03e5833c 100644 --- a/drivers/gpu/drm/aspeed/… [View More]

3 2

KASAN: vmalloc-out-of-bounds Write in sys_imageblit
by syzbot 07 Oct '20

07 Oct '20

Hello, syzbot found the following crash on: HEAD commit: 6794862a Merge tag 'for-5.5-rc1-kconfig-tag' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17f407f2e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d dashboard link: https://syzkaller.appspot.com/bug?extid=26dc38a00dc05118a4e6 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. … [View More]IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+26dc38a00dc05118a4e6(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: vmalloc-out-of-bounds in fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline] BUG: KASAN: vmalloc-out-of-bounds in sys_imageblit+0x117f/0x1240 drivers/video/fbdev/core/sysimgblt.c:275 Write of size 4 at addr ffffc90008de1000 by task syz-executor.3/19698 CPU: 0 PID: 19698 Comm: syz-executor.3 Not tainted 5.5.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 __asan_report_store4_noabort+0x17/0x20 mm/kasan/generic_report.c:139 fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline] sys_imageblit+0x117f/0x1240 drivers/video/fbdev/core/sysimgblt.c:275 drm_fb_helper_sys_imageblit+0x21/0x180 drivers/gpu/drm/drm_fb_helper.c:768 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline] bit_putcs+0x9a3/0xf10 drivers/video/fbdev/core/bitblit.c:188 fbcon_putcs+0x33c/0x3e0 drivers/video/fbdev/core/fbcon.c:1353 do_update_region+0x42b/0x6f0 drivers/tty/vt/vt.c:677 invert_screen+0x2da/0x650 drivers/tty/vt/vt.c:794 highlight drivers/tty/vt/selection.c:53 [inline] clear_selection drivers/tty/vt/selection.c:81 [inline] clear_selection+0x59/0x70 drivers/tty/vt/selection.c:77 vc_do_resize+0x1163/0x1460 drivers/tty/vt/vt.c:1200 vc_resize+0x4d/0x60 drivers/tty/vt/vt.c:1304 fbcon_do_set_font+0x4a6/0x960 drivers/video/fbdev/core/fbcon.c:2599 fbcon_set_font+0x72e/0x860 drivers/video/fbdev/core/fbcon.c:2696 con_font_set drivers/tty/vt/vt.c:4538 [inline] con_font_op+0xe30/0x1270 drivers/tty/vt/vt.c:4603 vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913 tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45a7c9 Code: bd b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 8b b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fcfa0ba6c88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000072bf00 RCX: 000000000045a7c9 RDX: 0000000020000140 RSI: 0000000000004b61 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcfa0ba76d4 R13: 00000000004ab60f R14: 00000000006ede60 R15: 00000000ffffffff Memory state around the buggy address: ffffc90008de0f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffc90008de0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffc90008de1000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ^ ffffc90008de1080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ffffc90008de1100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. [View Less]

1 2

[Bug 199979] New: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control
by bugzilla-daemon＠bugzilla.kernel.org 06 Oct '20

06 Oct '20

https://bugzilla.kernel.org/show_bug.cgi?id=199979 Bug ID: 199979 Summary: amdgpu: changing pwm1_enable from 1 to 2 does not resume automatic fan control Product: Drivers Version: 2.5 Kernel Version: 4.17.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: … [View More]

1 1

KASAN: global-out-of-bounds Read in fbcon_get_font
by syzbot 30 Sep '20

30 Sep '20

Hello, syzbot found the following crash on: HEAD commit: 6cf8298d Add linux-next specific files for 20191209 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=168bbb7ae00000 kernel config: https://syzkaller.appspot.com/x/.config?x=682fc0ce6c86e3c7 dashboard link: https://syzkaller.appspot.com/bug?extid=29d4ed7f3bdedf2aa2fd compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12fff061e00000 … [View More]IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+29d4ed7f3bdedf2aa2fd(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: global-out-of-bounds in memcpy include/linux/string.h:425 [inline] BUG: KASAN: global-out-of-bounds in fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 Read of size 32 at addr ffffffff88729d80 by task syz-executor.3/9100 CPU: 1 PID: 9100 Comm: syz-executor.3 Not tainted 5.5.0-rc1-next-20191209-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 memcpy+0x24/0x50 mm/kasan/common.c:125 memcpy include/linux/string.h:425 [inline] fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 con_font_get drivers/tty/vt/vt.c:4446 [inline] con_font_op+0x20b/0x1270 drivers/tty/vt/vt.c:4605 vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913 tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45a6f9 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f30314dcc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045a6f9 RDX: 0000000000713000 RSI: 0000000000004b60 RDI: 0000000000000004 RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f30314dd6d4 R13: 00000000004c6d87 R14: 00000000004dd3e0 R15: 00000000ffffffff The buggy address belongs to the variable: fontdata_8x16+0x1000/0x1120 Memory state around the buggy address: ffffffff88729c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff88729d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffffff88729d80: fa fa fa fa 06 fa fa fa fa fa fa fa 05 fa fa fa ^ ffffffff88729e00: fa fa fa fa 06 fa fa fa fa fa fa fa 00 00 03 fa ffffffff88729e80: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches [View Less]

7 28

[Bug 198551] New: amdgpu error on shutdown or gpu intense game
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '20

24 Sep '20

https://bugzilla.kernel.org/show_bug.cgi?id=198551 Bug ID: 198551 Summary: amdgpu error on shutdown or gpu intense game Product: Drivers Version: 2.5 Kernel Version: 4.14.14-1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org … [View More]

1 5

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
by Daniel Vetter 23 Sep '20

23 Sep '20

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the … [View More]kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index d5cefb1cb2a2..058512f14772 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -2018,15 +2018,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.18.0 [View Less]

3 11

[PATCH 0/7] drm/omap: misc improvements
by Tomi Valkeinen 22 Sep '20

22 Sep '20

Hi, Misc improvements to omapdrm which have been lying around for a long time, and I've missed upstreaming them. And one new one, which makes the DSS5 HDMI pick up the color range automatically. Tomi Alejandro Hernandez (1): drm/omap: tweak HDMI DDC timings Jyri Sarha (3): drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes drm/omap: dss: platform_register_drivers() to dss.c and remove … [View More]

7 33

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
by Christian König 16 Sep '20

16 Sep '20

Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: > Hi Woody, > > sorry for the late reply, I've been off to a vacation over the holidays. > > On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: >> Regression in 5.4 kernel on 32-bit Radeon IBM T40 >> triggered by >> commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 >> Author: Christoph Hellwig <hch(a)lst.de> >> Date: Thu Aug 15 09:27:00 2019 +0200 >> … [View More]

5 5

Re: backend-drm and scanning really large resolutions
by Pekka Paalanen 12 Sep '20

12 Sep '20

Adding Rob back in CC, I don't know if he is subscribed to wayland-devel@. You forgot to CC dri-devel@ too. On Tue, 11 Feb 2020 17:18:52 -0500 Xiaowen Wu <wxiaowen(a)codeaurora.org> wrote: > Hi Rob, > > If the vendor driver doesn't have the hwpipe sub-object and kms plane is > one-to-one mapped to hwpipe (sspp), > do you think if below approach is acceptable if we still want to > virtualize the kms plane to support 4K/8K scanout? > > 1. At kms atomic check … [View More]before calling drm_atomic_helper_check, depending > on scanout width of plane A in state, add idle planes B (C,D,...) > into the same atomic state, backup and then modify > src_x/src_w/crtc_x/crtc_w of plane A and the affected planes B (C,D,...) > to meet scanout > width limits, and set crtc/fb of the affected planes B (C,D,...) same as > plane A. > > 2. At plane's state duplicate function, check if plane's > src_x/src_w/crtc_x/crtc_w are updated at step 1), if so revert the > change to > plane A's backup value to allow plane A's scanout to update again. These > value will again be updated in step 1) so nothing really changes > if plane A continues updating. > > 3. If plane A's scanout is updated or detached from crtc, detach > affected planes B (C,D,...) in the same atomic state in step 1) and then > run step 1) again. > > 4. If user want to commit plane B (C,D,...), the commit/test will fail > if planes are already used as sister plane of plane A. This failure is > same > as insufficient hwpipe from plane B (C,D,...). > > With above change, any downstream driver can support virtualized plane. > Also as the above approach is generic and not h/w specific, we can make > it a helper function and it's up to vendor to choose if they want to use > or not, if they don't have logic like drm/msm/disp/mdp5/mdp5_plane in > their downstream driver. > > Conceptional above changes didn't borrow hwpipe resources from other > plane but borrow planes themselves directly, however from user point of > view > they should not feel any difference. > > What do you think? > > BR, > Xiaowen Wu > > > On Tue Jan 21, 2020 at 4:12 PM Rob Clark <robdclark at gmail.com> wrote: > > On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <matt.hoosier at > > gmail.com> wrote: > >> > >> Hi all, > >> > >> I'm confronting a situation where the hardware with which I work is > >> capable of driving connectors at 4K or 8K, but doing so requires > >> bonding the scanning of multiple planes together. > >> > >> The scenario is that you'd have a big primary framebuffer whose size > >> is too large for an individual hardware scanning pipeline on the > >> display controller to traverse within its maximum allowed clock rate. > >> > >> The hardware supplier's approach is to assign multiple planes, which > >> in the KMS driver map to hardware scanning pipelines, to each be > >> responsible for scanning a smaller section of the framebuffer. The > >> planes are all assigned to the same CRTC, and in concert with each > >> other they cover the whole area of the framebuffer and CRTC. > >> > >> This sounds a little bit wild to me. I hadn't been aware it's even > >> legal to have more than one plane treated a the source of scanout for > >> a single framebuffer. Maybe that distinction isn't really relevant > >> nowadays with universal plane support. > >> > > > > fwiw, have a look at drm/msm/disp/mdp5/mdp5_plane, which will allocate > > one or two hwpipe's from the devices global atomic state, depending on > > scanout width.. the hwpipe (sspp) is the physical resource behind a > > plane, so essentially the kms planes are virtualized. At some point > > if you have too many wide layers, the atomic test step will fail due > > to insufficient hwpipe's. But this sort of scenario is the reason for > > the test step. > > > > BR, > > -R > > > >> I'm wondering if anybody here knows whether this a legit approach for > >> a compositor's DRM backend to take? > >> > _______________________________________________ > wayland-devel mailing list > wayland-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel [View Less]

3 2

← Newer
1
2
3
4
5
6
7
8
9
...
68
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2020