dri-devel March 2021

dri-devel@lists.freedesktop.org

326 participants
867 discussions

[PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs
by Vivek Kasireddy 15 Apr '21

15 Apr '21

If support for Blob resources is available, then dumb BOs created by the driver can be considered as guest Blobs. And, for guest Blobs, there is no need to do any transfers or flushes but we do need to do set_scanout even if the FB has not changed as part of plane updates. Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 8 ++++++++ drivers/gpu/drm/virtio/virtgpu_object.c | 3 +++ drivers/gpu/drm/virtio/virtgpu_plane.c | 18 +++++++++++------- 3 files changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index 8502400b2f9c..5f49fb1cce65 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -64,6 +64,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, { struct drm_gem_object *gobj; struct virtio_gpu_object_params params = { 0 }; + struct virtio_gpu_device *vgdev = dev->dev_private; int ret; uint32_t pitch; @@ -79,6 +80,13 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, params.height = args->height; params.size = args->size; params.dumb = true; + + if (vgdev->has_resource_blob) { + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST; + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE; + params.blob = true; + } + ret = virtio_gpu_gem_create(file_priv, dev, &params, &gobj, &args->handle); if (ret) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 4ff1ec28e630..f648b0e24447 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -254,6 +254,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, } if (params->blob) { + if (params->blob_mem == VIRTGPU_BLOB_MEM_GUEST) + bo->guest_blob = true; + virtio_gpu_cmd_resource_create_blob(vgdev, bo, params, ents, nents); } else if (params->virgl) { diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index 4e1b17548007..3731f1a6477d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c @@ -161,10 +161,11 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, return; bo = gem_to_virtio_gpu_obj(plane->state->fb->obj[0]); - if (bo->dumb) + if (bo->dumb && !bo->guest_blob) virtio_gpu_update_dumb_bo(vgdev, plane->state, &rect); - if (plane->state->fb != old_state->fb || + if ((bo->dumb && bo->guest_blob) || + plane->state->fb != old_state->fb || plane->state->src_w != old_state->src_w || plane->state->src_h != old_state->src_h || plane->state->src_x != old_state->src_x || @@ -198,11 +199,14 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, } } - virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, - rect.x1, - rect.y1, - rect.x2 - rect.x1, - rect.y2 - rect.y1); + if (!bo->guest_blob) { + virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, + rect.x1, + rect.y1, + rect.x2 - rect.x1, + rect.y2 - rect.y1); + } + virtio_gpu_notify(vgdev); } -- 2.26.2

5 18

[PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output
by Maxime Ripard 15 Apr '21

15 Apr '21

Hi, Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on the RaspberryPi4. I took the same approach than what dw-hdmi did already, turning a bunch of functions found in that driver into helpers since they were fairly generic. However, it feels a bit clunky overall and there's a few rough edges that should be addressed in a generic manner: - while the format negociation makes sense for a bridge, it feels a bit over-engineered for a simple encoder where that setting could be a simple switch (and possibly a property?) - more importantly, whether we're choosing an YUV output or not is completely hidden away from the userspace even though it might have some effect on the visual quality output (thinking about YUV420 and YUV422 here mostly). - Similarly, the list we report is static and the userspace cannot change or force one mode over the other. We will always pick YUV444 over RGB444 if both are available for example. While the first one might just be due to a lack of helpers, the second and third ones are also feeling a bit inconsistent with how we're handling the 10/12 bit output for example Let me know what you think, Maxime Maxime Ripard (18): drm: Introduce new HDMI helpers drm/bridge: Add HDMI output fmt helper drm/bridge: dw-hdmi: Use helpers drm/vc4: txp: Properly set the possible_crtcs mask drm/vc4: crtc: Skip the TXP drm/vc4: Rework the encoder retrieval code drm/vc4: hdmi: Add full range RGB helper drm/vc4: hdmi: Use full range helper in csc functions drm/vc4: hdmi: Remove limited_rgb_range drm/vc4: hdmi: Convert to bridge drm/vc4: hdmi: Move XBAR setup to csc_setup drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines drm/vc4: hdmi: Define colorspace matrices drm/vc4: hdmi: Change CSC callback prototype drm/vc4: hdmi: Rework the infoframe prototype drm/vc4: hdmi: Support HDMI YUV output drm/vc4: hdmi: Move the pixel rate calculation to a helper drm/vc4: hdmi: Force YUV422 if the rate is too high drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 268 ++------------- drivers/gpu/drm/drm_bridge.c | 118 +++++++ drivers/gpu/drm/drm_hdmi.c | 170 +++++++++ drivers/gpu/drm/vc4/vc4_crtc.c | 59 +++- drivers/gpu/drm/vc4/vc4_drv.c | 41 +++ drivers/gpu/drm/vc4/vc4_drv.h | 26 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 399 +++++++++++++++------- drivers/gpu/drm/vc4/vc4_hdmi.h | 13 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 + drivers/gpu/drm/vc4/vc4_regs.h | 19 ++ drivers/gpu/drm/vc4/vc4_txp.c | 2 +- include/drm/drm_bridge.h | 6 + include/drm/drm_hdmi.h | 24 ++ 14 files changed, 770 insertions(+), 383 deletions(-) create mode 100644 drivers/gpu/drm/drm_hdmi.c create mode 100644 include/drm/drm_hdmi.h -- 2.30.2

4 45

[PATCH v2 00/14] drm: Fix EDID reading on ti-sn65dsi86
by Douglas Anderson 15 Apr '21

15 Apr '21

The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge. Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several times and also ended up forcing us to use the hardcoded mode at boot. With this patch series I believe EDID reading is reliable at boot now and we never use the hardcoded mode. This series is the logical successor to the 3-part series containing the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk") [1] though only one actual patch is the same between the two. This series starts out with some general / obvious fixes and moves on to some more specific and maybe controversial ones. I wouldn't object to some of the earlier ones landing if they look ready. This patch was developed against drm-misc-next on a sc7180-trogdor-lazor device. To get things booting for me, I had to use Stephen's patch [2] to keep from crashing but otherwise all the patches I needed were here. [1] https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c… [2] https://lore.kernel.org/r/161706912161.3012082.17313817257247946143@swboyd.… Changes in v2: - Removed 2nd paragraph in commit message. Douglas Anderson (14): drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable() drm/bridge: ti-sn65dsi86: Simplify refclk handling drm/bridge: ti-sn65dsi86: Remove incorrectly tagged kerneldoc comment drm/bridge: ti-sn65dsi86: Reorder remove() drm/bridge: ti-sn65dsi86: Move MIPI detach() / unregister() to detach() drm/bridge: ti-sn65dsi86: Move drm_panel_unprepare() to post_disable() drm/bridge: ti-sn65dsi86: Get rid of the useless detect() function drm/bridge: ti-sn65dsi86: Remove extra call: drm_connector_update_edid_property() drm/edid: Use the cached EDID in drm_get_edid() if eDP drm/bridge: ti-sn65dsi86: Stop caching the EDID ourselves drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided drm/bridge: ti-sn65dsi86: Print an error if we fallback to panel modes drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare drivers/gpu/drm/bridge/ti-sn65dsi86.c | 125 ++++++++++++++++---------- drivers/gpu/drm/drm_bridge.c | 3 + drivers/gpu/drm/drm_edid.c | 32 ++++++- drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 93 ++++++++++++++----- 5 files changed, 184 insertions(+), 70 deletions(-) -- 2.31.0.291.g576ba9dcdaf-goog

5 34

[PATCH 00/30] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
by Lyude Paul 14 Apr '21

14 Apr '21

Since it's been asked quite a few times on some of the various DP related patch series I've submitted to use the new DRM printk helpers, and it technically wasn't really trivial to do this before due to the lack of a consistent way to find a drm_device for an AUX channel, this patch series aims to address this. In this series we: * Clean-up potentially erroneous usages of drm_dp_aux_init() and drm_dp_aux_register() so that actual AUX registration doesn't happen until we have an associated DRM device * Clean-up any obvious errors in drivers we find along the way * Add a backpointer to the respective drm_device for an AUX channel in drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel across the tree * Add a new ratelimited print helper we'll need for converting the DP helpers over to using the new DRM printk helpers * Fix any inconsistencies with logging in drm_dp_helper.c so we always have the aux channel name printed * Prepare the various DP helpers so they can find the correct drm_device to use for logging * And finally, convert all of the DP helpers over to using drm_dbg_*() and drm_err(). Lyude Paul (30): drm/dp: Rewrap kdocs for struct drm_dp_aux drm/dp: Fixup kernel docs for struct drm_dp_aux drm/tegra: Don't register DP AUX channels before connectors drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call drm/bridge/analogix/anx78xx: Setup encoder before registering connector drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach() drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call drm/bridge/analogix/anx6345: Don't link encoder until after connector registration drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach() drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe() drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister drm/dp: Add backpointer to drm_device in drm_dp_aux drm/dp: Rewrap drm_dp_aux_register()/drm_dp_aux_init() kdocs drm/dp: Clarify DP AUX registration time drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED() drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay() drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay() drm/dp: Always print aux channel name in logs drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock() drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output() drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode() drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw() drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*() drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms() drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*() drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 5 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 + .../drm/bridge/analogix/analogix-anx6345.c | 28 +- .../drm/bridge/analogix/analogix-anx78xx.c | 28 +- .../drm/bridge/analogix/analogix_dp_core.c | 2 + .../drm/bridge/cadence/cdns-mhdp8546-core.c | 12 +- drivers/gpu/drm/bridge/tc358767.c | 21 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 19 +- drivers/gpu/drm/drm_dp_aux_dev.c | 6 + drivers/gpu/drm/drm_dp_dual_mode_helper.c | 68 ++-- drivers/gpu/drm/drm_dp_helper.c | 175 ++++---- drivers/gpu/drm/drm_dp_mst_topology.c | 377 +++++++++--------- drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 + .../drm/i915/display/intel_dp_link_training.c | 6 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +- drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 +- drivers/gpu/drm/msm/edp/edp.h | 3 +- drivers/gpu/drm/msm/edp/edp_aux.c | 5 +- drivers/gpu/drm/msm/edp/edp_ctrl.c | 8 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 27 +- drivers/gpu/drm/radeon/atombios_dp.c | 5 +- drivers/gpu/drm/tegra/dpaux.c | 12 +- drivers/gpu/drm/xlnx/zynqmp_dp.c | 5 +- include/drm/drm_dp_dual_mode_helper.h | 14 +- include/drm/drm_dp_helper.h | 59 +-- include/drm/drm_dp_mst_helper.h | 3 +- include/drm/drm_print.h | 20 +- 29 files changed, 537 insertions(+), 406 deletions(-) -- 2.29.2

6 53

[Bug 209345] New: [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
by bugzilla-daemon＠bugzilla.kernel.org 14 Apr '21

14 Apr '21

https://bugzilla.kernel.org/show_bug.cgi?id=209345 Bug ID: 209345 Summary: [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80) Product: Drivers Version: 2.5 Kernel Version: 5.8.9 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: kallisti5(a)unixzen.com Regression: No Attaching an nVidia Tesla K80 compute card to a Fedora 32 machine. Getting: nouveau 0000:08:00.0: unknown chipset (0f22d0a1) -- You are receiving this mail because: You are watching the assignee of the bug.

1 15

KASAN: use-after-free Read in bit_putcs
by syzbot 12 Apr '21

12 Apr '21

Hello, syzbot found the following crash on: HEAD commit: 0a44cac8 Merge tag 'dma-mapping-5.6' of git://git.infradea.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11bfb74ee00000 kernel config: https://syzkaller.appspot.com/x/.config?x=a61f2164c515c07f dashboard link: https://syzkaller.appspot.com/bug?extid=b308f5fd049fbbc6e74f compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+b308f5fd049fbbc6e74f(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: use-after-free in __fb_pad_aligned_buffer include/linux/fb.h:655 [inline] BUG: KASAN: use-after-free in bit_putcs_aligned drivers/video/fbdev/core/bitblit.c:96 [inline] BUG: KASAN: use-after-free in bit_putcs+0x13ee/0x1cc0 drivers/video/fbdev/core/bitblit.c:185 Read of size 1 at addr ffff8880a8087c10 by task syz-executor.2/5278 CPU: 1 PID: 5278 Comm: syz-executor.2 Not tainted 5.6.0-rc2-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+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132 __fb_pad_aligned_buffer include/linux/fb.h:655 [inline] bit_putcs_aligned drivers/video/fbdev/core/bitblit.c:96 [inline] bit_putcs+0x13ee/0x1cc0 drivers/video/fbdev/core/bitblit.c:185 fbcon_putcs+0x7b4/0xad0 drivers/video/fbdev/core/fbcon.c:1360 do_update_region+0x462/0x600 drivers/tty/vt/vt.c:677 redraw_screen+0xcc5/0x1830 drivers/tty/vt/vt.c:1011 vc_do_resize+0x12af/0x1af0 drivers/tty/vt/vt.c:1284 vc_resize+0x4f/0x60 drivers/tty/vt/vt.c:1304 vt_ioctl+0x2fa8/0x3a70 drivers/tty/vt/vt_ioctl.c:887 tty_ioctl+0xee6/0x15c0 drivers/tty/tty_io.c:2660 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl fs/ioctl.c:763 [inline] __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770 __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45c449 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:00007f74261f2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f74261f36d4 RCX: 000000000045c449 RDX: 0000000020000080 RSI: 000000000000560a RDI: 0000000000000003 RBP: 000000000076bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 000000000000066b R14: 00000000004c8fe0 R15: 000000000076bf2c Allocated by task 2919: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 __do_kmalloc_node mm/slab.c:3616 [inline] __kmalloc_node_track_caller+0x4d/0x60 mm/slab.c:3630 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0xe8/0x500 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1051 [inline] _sctp_make_chunk+0x60/0x460 net/sctp/sm_make_chunk.c:1394 sctp_make_data net/sctp/sm_make_chunk.c:1426 [inline] sctp_make_datafrag_empty+0xa3/0x5b0 net/sctp/sm_make_chunk.c:740 sctp_datamsg_from_user+0x7a8/0x1020 net/sctp/chunk.c:262 sctp_sendmsg_to_asoc+0x7a9/0x1500 net/sctp/socket.c:1844 sctp_sendmsg+0x15a1/0x3570 net/sctp/socket.c:2016 inet_sendmsg+0x147/0x310 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x4f7/0x7f0 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmsg+0x1ed/0x290 net/socket.c:2430 __do_sys_sendmsg net/socket.c:2439 [inline] __se_sys_sendmsg net/socket.c:2437 [inline] __x64_sys_sendmsg+0x7f/0x90 net/socket.c:2437 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2919: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 skb_free_head net/core/skbuff.c:592 [inline] skb_release_data+0x72f/0x8c0 net/core/skbuff.c:612 skb_release_all net/core/skbuff.c:666 [inline] __kfree_skb+0x59/0x1c0 net/core/skbuff.c:680 consume_skb+0x72/0x110 net/core/skbuff.c:839 sctp_chunk_destroy net/sctp/sm_make_chunk.c:1454 [inline] sctp_chunk_put+0x17b/0x200 net/sctp/sm_make_chunk.c:1481 sctp_chunk_free+0x59/0x60 net/sctp/sm_make_chunk.c:1468 sctp_outq_sack+0x1169/0x16a0 net/sctp/outqueue.c:1352 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:798 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1354 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1185 [inline] sctp_do_sm+0x18f3/0x5840 net/sctp/sm_sideeffect.c:1156 sctp_assoc_bh_rcv+0x494/0x770 net/sctp/associola.c:1044 sctp_inq_push+0x1ab/0x1d0 net/sctp/inqueue.c:80 sctp_backlog_rcv+0x16c/0x4b0 net/sctp/input.c:344 sk_backlog_rcv include/net/sock.h:938 [inline] __release_sock+0x1c1/0x4b0 net/core/sock.c:2437 release_sock+0x65/0x1c0 net/core/sock.c:2953 sctp_wait_for_connect+0x2f6/0x590 net/sctp/socket.c:9280 sctp_sendmsg_to_asoc+0x11ba/0x1500 net/sctp/socket.c:1870 sctp_sendmsg+0x15a1/0x3570 net/sctp/socket.c:2016 inet_sendmsg+0x147/0x310 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x4f7/0x7f0 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmsg+0x1ed/0x290 net/socket.c:2430 __do_sys_sendmsg net/socket.c:2439 [inline] __se_sys_sendmsg net/socket.c:2437 [inline] __x64_sys_sendmsg+0x7f/0x90 net/socket.c:2437 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880a8087c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 16 bytes inside of 512-byte region [ffff8880a8087c00, ffff8880a8087e00) The buggy address belongs to the page: page:ffffea0002a021c0 refcount:1 mapcount:0 mapping:ffff8880aa400a80 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0002431688 ffffea000259d648 ffff8880aa400a80 raw: 0000000000000000 ffff8880a8087000 0000000100000004 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a8087b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8880a8087b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880a8087c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880a8087c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a8087d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== --- 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.

8 17

[PATCH v2 0/5] drm/vc4: hdmi: Support the 4k @ 60Hz modes
by Maxime Ripard 12 Apr '21

12 Apr '21

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. The firmware also has a glitch at the moment and will not properly release the BSC controllers, which will make the EDID retrieval fail. We can work around this using the following config.txt options: disable_fw_kms_setup=1 hdmi_edid_file:0=1 hdmi_edid_filename:0=1366x768.bin hdmi_ignore_edid:0=1 hdmi_edid_file:1=1 hdmi_edid_filename:1=1366x768.bin hdmi_ignore_edid:1=1 A fix will come for the firmware eventually. Let me know what you think, Maxime --- Changes from v1: - Dropped the range accessors - Drop the mention of force_turbo - Reordered the SCRAMBLER_CTL register to match the offset - Removed duplicate HDMI_14_MAX_TMDS_CLK define - Warn about enable_hdmi_4kp60 only if there's some modes that can't be reached - Rework the BVB clock computation Maxime Ripard (5): drm/vc4: hvs: Make the HVS bind first drm/vc4: hdmi: Properly compute the BVB clock rate drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies drm/vc4: hdmi: Enable the scrambler drm/vc4: hdmi: Raise the maximum clock rate drivers/gpu/drm/vc4/vc4_drv.c | 11 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 101 +++++++++++++++++++++++++--- drivers/gpu/drm/vc4/vc4_hdmi.h | 8 +++ drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 + 4 files changed, 113 insertions(+), 10 deletions(-) -- 2.30.2

3 11

[PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
by Hans de Goede 12 Apr '21

12 Apr '21

After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot"), the DSI panel on a Cherry Trail based Predia Basic tablet would no longer properly light up after reboot. I've managed to reproduce this without rebooting by doing: chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\ echo 0 > /sys/class/graphics/fb0/blank Which rapidly turns the panel off and back on again. The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays used for panel on/off, since starting with MIPI-sequences version >= 3 the delays are already included inside the MIPI-sequences. The problems exposed by the "Shut down displays gracefully on reboot" change, show that using this helper for the panel_pwr_cycle_delay is not the right thing to do. This has not been noticed until now because normally the panel never is cycled off and directly on again in quick succession. Change the msleep for the panel_pwr_cycle_delay to a normal msleep() call to avoid the panel staying black after a quick off + on cycle. Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c index d5a3f69c5df3..38d5a1f3ded5 100644 --- a/drivers/gpu/drm/i915/display/vlv_dsi.c +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct intel_atomic_state *state, * FIXME As we do with eDP, just make a note of the time here * and perform the wait before the next panel power on. */ - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay); + msleep(intel_dsi->panel_pwr_cycle_delay); } static void intel_dsi_shutdown(struct intel_encoder *encoder) { struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder); - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay); + msleep(intel_dsi->panel_pwr_cycle_delay); } static bool intel_dsi_get_hw_state(struct intel_encoder *encoder, -- 2.30.2

2 6

general protection fault in drm_client_buffer_vunmap
by syzbot 11 Apr '21

11 Apr '21

Hello, syzbot found the following issue on: HEAD commit: 6147c83f Add linux-next specific files for 20201126 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=109130a5500000 kernel config: https://syzkaller.appspot.com/x/.config?x=9b91566da897c24f dashboard link: https://syzkaller.appspot.com/bug?extid=10328e8428a896b65119 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12541369500000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1365c663500000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+10328e8428a896b65119(a)syzkaller.appspotmail.com [drm] Initialized udl on minor 2 [drm:udl_get_edid_block] *ERROR* Read EDID byte 0 failed err ffffffb9 udl 1-1:0.0: [drm] Cannot find any crtc or sizes usb 1-1: USB disconnect, device number 2 general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.10.0-rc5-next-20201126-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:drm_client_buffer_vunmap+0x26/0x50 drivers/gpu/drm/drm_client.c:347 Code: 00 00 00 00 53 48 89 fb 48 83 ec 08 e8 83 8b 3f fd 48 8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 8d 73 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0e 48 8b 7b 10 48 83 c4 08 5b e9 56 61 f7 ff 48 89 RSP: 0018:ffffc90000cc7710 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff815524de RDX: 0000000000000002 RSI: 0000000000000018 RDI: 0000000000000010 RBP: ffff88801db748c8 R08: 0000000000000000 R09: ffff88801db74a17 R10: ffffed1003b6e942 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801db748d8 R14: ffff88801db74810 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f43f9d79e0 CR3: 000000000b08e000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: drm_fbdev_cleanup+0x380/0x440 drivers/gpu/drm/drm_fb_helper.c:2042 drm_fbdev_release drivers/gpu/drm/drm_fb_helper.c:2049 [inline] drm_fbdev_client_unregister+0x61/0x80 drivers/gpu/drm/drm_fb_helper.c:2376 drm_client_dev_unregister+0x239/0x3b0 drivers/gpu/drm/drm_client.c:175 drm_dev_unregister+0xe9/0x2b0 drivers/gpu/drm/drm_drv.c:942 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458 __device_release_driver+0x3bd/0x6f0 drivers/base/dd.c:1154 device_release_driver_internal drivers/base/dd.c:1185 [inline] device_release_driver+0x26/0x40 drivers/base/dd.c:1208 bus_remove_device+0x2eb/0x5a0 drivers/base/bus.c:533 device_del+0x502/0xec0 drivers/base/core.c:3113 usb_disable_device+0x35b/0x7b0 drivers/usb/core/message.c:1417 usb_disconnect.cold+0x27d/0x780 drivers/usb/core/hub.c:2218 hub_port_connect drivers/usb/core/hub.c:5074 [inline] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] port_event drivers/usb/core/hub.c:5509 [inline] hub_event+0x1c8a/0x42d0 drivers/usb/core/hub.c:5591 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2272 process_scheduled_works kernel/workqueue.c:2334 [inline] worker_thread+0x82b/0x1120 kernel/workqueue.c:2420 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Modules linked in: ---[ end trace 5e45793b7de819bc ]--- RIP: 0010:drm_client_buffer_vunmap+0x26/0x50 drivers/gpu/drm/drm_client.c:347 Code: 00 00 00 00 53 48 89 fb 48 83 ec 08 e8 83 8b 3f fd 48 8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 8d 73 18 48 --- This report 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 issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

2 2

[PATCH] drm/etnaviv: Remove useless error message
by Tian Tao 10 Apr '21

10 Apr '21

Fix the following coccicheck report: drivers/gpu/drm/etnaviv/etnaviv_gpu.c:1775:2-9: line 1775 is redundant because platform_get_irq() already prints an error Remove dev_err() messages after platform_get_irq() failures. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Signed-off-by: Zihao Tang <tangzihao1(a)hisilicon.com> Signed-off-by: Jay Fang <f.fangjian(a)huawei.com> --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index c6404b8..4645349 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1771,10 +1771,8 @@ static int etnaviv_gpu_platform_probe(struct platform_device *pdev) /* Get Interrupt: */ gpu->irq = platform_get_irq(pdev, 0); - if (gpu->irq < 0) { - dev_err(dev, "failed to get irq: %d\n", gpu->irq); + if (gpu->irq < 0) return gpu->irq; - } err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0, dev_name(gpu->dev), gpu); -- 2.7.4

2 1

← Newer
1
...
12
13
14
15
16
17
18
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2021