dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH] dma-buf: fix and rework dma_buf_poll v7
by Christian König 30 Sep '21

30 Sep '21

Daniel pointed me towards this function and there are multiple obvious problems in the implementation. First of all the retry loop is not working as intended. In general the retry makes only sense if you grab the reference first and then check the sequence values. Then we should always also wait for the exclusive fence. It's also good practice to keep the reference around when installing callbacks to fences you don't own. And last the whole implementation was unnecessary complex and rather hard to understand which could lead to probably unexpected behavior of the IOCTL. Fix all this by reworking the implementation from scratch. Dropping the whole RCU approach and taking the lock instead. Only mildly tested and needs a thoughtful review of the code. v2: fix the reference counting as well v3: keep the excl fence handling as is for stable v4: back to testing all fences, drop RCU v5: handle in and out separately v6: add missing clear of events v7: change coding style as suggested by Michel, drop unused variables Signed-off-by: Christian König <christian.koenig(a)amd.com> CC: stable(a)vger.kernel.org --- drivers/dma-buf/dma-buf.c | 152 ++++++++++++++++++-------------------- include/linux/dma-buf.h | 2 +- 2 files changed, 71 insertions(+), 83 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d217a0..6c520c9bd93c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -72,7 +72,7 @@ static void dma_buf_release(struct dentry *dentry) * If you hit this BUG() it means someone dropped their ref to the * dma-buf while still having pending operation to the buffer. */ - BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); + BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); dmabuf->ops->release(dmabuf); @@ -202,16 +202,55 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb) wake_up_locked_poll(dcb->poll, dcb->active); dcb->active = 0; spin_unlock_irqrestore(&dcb->poll->lock, flags); + dma_fence_put(fence); +} + +static bool dma_buf_poll_shared(struct dma_resv *resv, + struct dma_buf_poll_cb_t *dcb) +{ + struct dma_resv_list *fobj = dma_resv_shared_list(resv); + struct dma_fence *fence; + int i, r; + + if (!fobj) + return false; + + for (i = 0; i < fobj->shared_count; ++i) { + fence = rcu_dereference_protected(fobj->shared[i], + dma_resv_held(resv)); + dma_fence_get(fence); + r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb); + if (!r) + return true; + dma_fence_put(fence); + } + + return false; +} + +static bool dma_buf_poll_excl(struct dma_resv *resv, + struct dma_buf_poll_cb_t *dcb) +{ + struct dma_fence *fence = dma_resv_excl_fence(resv); + int r; + + if (!fence) + return false; + + dma_fence_get(fence); + r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb); + if (!r) + return true; + dma_fence_put(fence); + + return false; } static __poll_t dma_buf_poll(struct file *file, poll_table *poll) { struct dma_buf *dmabuf; struct dma_resv *resv; - struct dma_resv_list *fobj; - struct dma_fence *fence_excl; __poll_t events; - unsigned shared_count, seq; dmabuf = file->private_data; if (!dmabuf || !dmabuf->resv) @@ -225,101 +264,50 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) if (!events) return 0; -retry: - seq = read_seqcount_begin(&resv->seq); - rcu_read_lock(); - - fobj = rcu_dereference(resv->fence); - if (fobj) - shared_count = fobj->shared_count; - else - shared_count = 0; - fence_excl = dma_resv_excl_fence(resv); - if (read_seqcount_retry(&resv->seq, seq)) { - rcu_read_unlock(); - goto retry; - } - - if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) { - struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl; - __poll_t pevents = EPOLLIN; + dma_resv_lock(resv, NULL); - if (shared_count == 0) - pevents |= EPOLLOUT; + if (events & EPOLLOUT) { + struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_out; + /* Check that callback isn't busy */ spin_lock_irq(&dmabuf->poll.lock); - if (dcb->active) { - dcb->active |= pevents; - events &= ~pevents; - } else - dcb->active = pevents; + if (dcb->active) + events &= ~EPOLLOUT; + else + dcb->active = EPOLLOUT; spin_unlock_irq(&dmabuf->poll.lock); - if (events & pevents) { - if (!dma_fence_get_rcu(fence_excl)) { - /* force a recheck */ - events &= ~pevents; - dma_buf_poll_cb(NULL, &dcb->cb); - } else if (!dma_fence_add_callback(fence_excl, &dcb->cb, - dma_buf_poll_cb)) { - events &= ~pevents; - dma_fence_put(fence_excl); - } else { - /* - * No callback queued, wake up any additional - * waiters. - */ - dma_fence_put(fence_excl); + if (events & EPOLLOUT) { + if (!dma_buf_poll_shared(resv, dcb) && + !dma_buf_poll_excl(resv, dcb)) + /* No callback queued, wake up any other waiters */ dma_buf_poll_cb(NULL, &dcb->cb); - } + else + events &= ~EPOLLOUT; } } - if ((events & EPOLLOUT) && shared_count > 0) { - struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared; - int i; + if (events & EPOLLIN) { + struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_in; - /* Only queue a new callback if no event has fired yet */ + /* Check that callback isn't busy */ spin_lock_irq(&dmabuf->poll.lock); if (dcb->active) - events &= ~EPOLLOUT; + events &= ~EPOLLIN; else - dcb->active = EPOLLOUT; + dcb->active = EPOLLIN; spin_unlock_irq(&dmabuf->poll.lock); - if (!(events & EPOLLOUT)) - goto out; - - for (i = 0; i < shared_count; ++i) { - struct dma_fence *fence = rcu_dereference(fobj->shared[i]); - - if (!dma_fence_get_rcu(fence)) { - /* - * fence refcount dropped to zero, this means - * that fobj has been freed - * - * call dma_buf_poll_cb and force a recheck! - */ - events &= ~EPOLLOUT; + if (events & EPOLLIN) { + if (!dma_buf_poll_excl(resv, dcb)) + /* No callback queued, wake up any other waiters */ dma_buf_poll_cb(NULL, &dcb->cb); - break; - } - if (!dma_fence_add_callback(fence, &dcb->cb, - dma_buf_poll_cb)) { - dma_fence_put(fence); - events &= ~EPOLLOUT; - break; - } - dma_fence_put(fence); + else + events &= ~EPOLLIN; } - - /* No callback queued, wake up any additional waiters. */ - if (i == shared_count) - dma_buf_poll_cb(NULL, &dcb->cb); } -out: - rcu_read_unlock(); + dma_resv_unlock(resv); return events; } @@ -562,8 +550,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) dmabuf->owner = exp_info->owner; spin_lock_init(&dmabuf->name_lock); init_waitqueue_head(&dmabuf->poll); - dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; - dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; + dmabuf->cb_in.poll = dmabuf->cb_out.poll = &dmabuf->poll; + dmabuf->cb_in.active = dmabuf->cb_out.active = 0; if (!resv) { resv = (struct dma_resv *)&dmabuf[1]; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index efdc56b9d95f..7e747ad54c81 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -329,7 +329,7 @@ struct dma_buf { wait_queue_head_t *poll; __poll_t active; - } cb_excl, cb_shared; + } cb_in, cb_out; }; /** -- 2.25.1

3 7

[RFC PATCH v3 0/6] A drm_plane API to support HDR planes
by Harry Wentland 30 Sep '21

30 Sep '21

We are looking to enable HDR support for a couple of single-plane and multi-plane scenarios. To do this effectively we recommend new interfaces to drm_plane. The first patch gives a bit of background on HDR and why we propose these interfaces. This update is only changing the documentation, not the code. We feel that we are not close to anything resembling a consensus for the DRM/KMS API to support (multi-plane) HDR and would like to further the discussion on this. The most important bits in the RFC document are probably the sections on defining HW details and defining SW intentions. We are worried defining intricate HW details on the DRM/KMS level leads to a lot of complexity for compositors which can be avoided by rather defining SW intentions. I will be off for the entire month of August with little time to follow this thread but would like to get my updated thoughts out for discussion anyways. Shashank Sharma will help support this discussion. v3: * Only doc updates (patch 1) * Add sections on single-plane and multi-plane HDR * Describe approach to define HW details vs approach to define SW intentions * Link Jeremy Cline's excellent HDR summaries * Outline intention behind overly verbose doc * Describe FP16 use-case * Clean up links v2: * Moved RFC from cover letter to kernel doc (Daniel Vetter) * Created new color space property instead of abusing color_encoding property (Ville) * Elaborated on need for named transfer functions * Expanded on reason for SDR luminance definition * Dropped 'color' from transfer function naming * Added output_transfer_function on crtc Bhawanpreet Lakha (3): drm/color: Add transfer functions for HDR/SDR on drm_plane drm/color: Add sdr boost property drm/color: Add color space plane property Harry Wentland (3): drm/doc: Color Management and HDR10 RFC drm/color: Add output transfer function to crtc drm/amd/display: reformat YCbCr-RGB conversion matrix Documentation/gpu/rfc/color_intentions.drawio | 1 + Documentation/gpu/rfc/color_intentions.svg | 3 + Documentation/gpu/rfc/colorpipe | 1 + Documentation/gpu/rfc/colorpipe.svg | 3 + Documentation/gpu/rfc/hdr-wide-gamut.rst | 580 ++++++++++++++++++ Documentation/gpu/rfc/index.rst | 1 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +- drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 7 +- .../gpu/drm/arm/display/komeda/komeda_plane.c | 6 +- drivers/gpu/drm/arm/malidp_crtc.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 6 +- drivers/gpu/drm/armada/armada_crtc.c | 5 +- drivers/gpu/drm/armada/armada_overlay.c | 6 +- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 + drivers/gpu/drm/drm_color_mgmt.c | 177 +++++- drivers/gpu/drm/i915/display/intel_color.c | 11 +- drivers/gpu/drm/i915/display/intel_color.h | 2 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- drivers/gpu/drm/i915/display/intel_sprite.c | 6 +- .../drm/i915/display/skl_universal_plane.c | 6 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +- drivers/gpu/drm/nouveau/dispnv50/head.c | 13 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +- drivers/gpu/drm/omapdrm/omap_plane.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +- drivers/gpu/drm/stm/ltdc.c | 8 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 10 +- drivers/gpu/drm/tidss/tidss_crtc.c | 9 +- drivers/gpu/drm/tidss/tidss_plane.c | 10 +- drivers/gpu/drm/vc4/vc4_crtc.c | 16 +- include/drm/drm_color_mgmt.h | 49 +- include/drm/drm_crtc.h | 20 + include/drm/drm_plane.h | 47 +- 39 files changed, 1074 insertions(+), 60 deletions(-) create mode 100644 Documentation/gpu/rfc/color_intentions.drawio create mode 100644 Documentation/gpu/rfc/color_intentions.svg create mode 100644 Documentation/gpu/rfc/colorpipe create mode 100644 Documentation/gpu/rfc/colorpipe.svg create mode 100644 Documentation/gpu/rfc/hdr-wide-gamut.rst -- 2.32.0

8 27

[PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
by Manasi Navare 29 Sep '21

29 Sep '21

In case of a modeset where a mode gets split across mutiple CRTCs in the driver specific implementation (bigjoiner in i915) we wrongly count the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as an affected CRTC in atomic_check_only(). This triggers a warning since affected CRTCs doent match requested CRTC. To fix this in such bigjoiner configurations, we should only increment affected crtcs if that CRTC is enabled in UAPI not if it is just used internally in the driver to split the mode. Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: Daniel Stone <daniels(a)collabora.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Manasi Navare <manasi.d.navare(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 5b4547e0f775..d7acd6bbd97e 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1358,8 +1358,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) - affected_crtc |= drm_crtc_mask(crtc); + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) { + if (new_crtc_state->enable) + affected_crtc |= drm_crtc_mask(crtc); + } /* * For commits that allow modesets drivers can add other CRTCs to the -- 2.19.1

6 18

[Bug 211875] New: CPU frequency scaling lost after "WARNING: CPU: 2 PID: 2358578 at smu8_send_msg_to_smc_with_parameter+0xfe/0x140 [amdgpu]"
by bugzilla-daemon＠bugzilla.kernel.org 28 Sep '21

28 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=211875 Bug ID: 211875 Summary: CPU frequency scaling lost after "WARNING: CPU: 2 PID: 2358578 at smu8_send_msg_to_smc_with_parameter+0xfe/0x140 [amdgpu]" Product: Drivers Version: 2.5 Kernel Version: 5.11 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: erhard_f(a)mailbox.org Regression: No Created attachment 295381 --> https://bugzilla.kernel.org/attachment.cgi?id=295381&action=edit dmesg (kernel 5.11, A10-9700E) I get this on kernel 5.10.17 and it happens on 5.11 too (though a lot less often). Leaving the machine running for some hours sooner or later I get this "smu8_send_msg_to_smc_with_parameter(0x0011, 0x460) timed out after 3234846 us" in kernel dmesg and after that CPU clock frequency is hampered to the 800 MHz base clock of the A10-9700E. Setting cpu manually to performance or back to ondemand does not change a thing, clock stays down at 800 MHz. The machine does not crash and is still usable but well ... slow.. [...] ------------[ cut here ]------------ smu8_send_msg_to_smc_with_parameter(0x0011, 0x460) timed out after 3234846 us WARNING: CPU: 2 PID: 2358578 at smu8_send_msg_to_smc_with_parameter+0xfe/0x140 [amdgpu] Modules linked in: fuse rfkill input_leds joydev ext4 crc16 mbcache jbd2 hid_generic usbhid hid crc32_generic crc32_pclmul f2fs evdev amdgpu aesni_intel libaes crypto_simd cryptd snd_hda_codec_hdmi glue_helper drm_ttm_helper snd_hda_codec_realtek ttm snd_hda_codec_generic ledtrig_audio led_class r8169 fam15h_power realtek gpu_sched k10temp mdio_devres ehci_pci ehci_hcd i2c_piix4 libphy snd_hda_intel snd_intel_dspcfg i2c_algo_bit snd_hda_codec drm_kms_helper snd_hwdep cfbfillrect snd_hda_core syscopyarea xhci_pci cfbimgblt snd_pcm xhci_hcd sysfillrect sysimgblt snd_timer usbcore fb_sys_fops cfbcopyarea snd usb_common fb soundcore font fbdev video acpi_cpufreq button processor nfsd zram nct6775 auth_rpcgss zsmalloc hwmon_vid jc42 lockd hwmon grace sunrpc drm drm_panel_orientation_quirks nfs_ssc backlight CPU: 2 PID: 2358578 Comm: kworker/2:0 Not tainted 5.11.0-gentoo #2 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A320M-HDV R3.0, BIOS P3.10 06/26/2019 Workqueue: events dm_irq_work_func [amdgpu] RIP: 0010:smu8_send_msg_to_smc_with_parameter+0xfe/0x140 [amdgpu] Code: c0 48 c7 c7 a0 4b a8 c0 48 89 c1 48 f7 ea 48 89 c8 44 89 f1 48 c1 f8 3f 48 c1 fa 07 48 29 c2 49 89 d0 44 89 ea e8 db a8 e4 d5 <0f> 0b eb b3 41 bc ea ff ff ff eb ab 48 8b 7d 60 be c0 01 00 00 48 RSP: 0018:ffffb25b4015bb48 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 00009c65e3a5a2a5 RCX: ffffa23c0f512d58 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffffa23c0f512d50 RBP: ffffa23908ceec00 R08: 0000000000000000 R09: ffffb25b4015b980 R10: 0000000000000003 R11: ffffffff96e57e48 R12: 00000000ffffffc2 R13: 0000000000000011 R14: 0000000000000460 R15: ffffa2390e53128c FS: 0000000000000000(0000) GS:ffffa23c0f500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f99db4fbbc0 CR3: 0000000134f00000 CR4: 00000000001506e0 Call Trace: smum_send_msg_to_smc_with_parameter+0xbe/0xf0 [amdgpu] smu8_set_power_state_tasks+0x1d6/0x360 [amdgpu] phm_set_power_state+0x44/0x68 [amdgpu] psm_adjust_power_state_dynamic+0xb6/0x1b8 [amdgpu] ? amdgpu_fence_wait_empty+0x80/0xd0 [amdgpu] pp_dpm_dispatch_tasks+0x35/0x58 [amdgpu] dm_pp_apply_display_requirements+0x197/0x1c0 [amdgpu] dce11_update_clocks+0x8f/0xe8 [amdgpu] dc_commit_updates_for_stream+0xc2c/0x1980 [amdgpu] ? dc_link_detect_helper+0x516/0xe90 [amdgpu] dm_set_dpms_off+0x85/0xd0 [amdgpu] handle_hpd_irq+0xf1/0x148 [amdgpu] dm_irq_work_func+0x44/0x50 [amdgpu] process_one_work+0x1b8/0x318 worker_thread+0x4b/0x3a0 ? rescuer_thread+0x360/0x360 kthread+0x11c/0x138 ? __kthread_bind_mask+0x58/0x58 ret_from_fork+0x22/0x30 ---[ end trace 0fa0eb110cfd5fb7 ]--- amdgpu: smu8_send_msg_to_smc_with_parameter(0x026e) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x002f) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x0012) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x0013) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x0011) aborted; SMU still servicing msg (0x0011) [drm] amdgpu_dm_irq_schedule_work FAILED src 2 [drm] amdgpu_dm_irq_schedule_work FAILED src 2 amdgpu: smu8_send_msg_to_smc_with_parameter(0x026e) aborted; SMU still servicing msg (0x0011) [drm] amdgpu_dm_irq_schedule_work FAILED src 2 amdgpu: smu8_send_msg_to_smc_with_parameter(0x002f) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x0012) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x0013) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x0011) aborted; SMU still servicing msg (0x0011) amdgpu: smu8_send_msg_to_smc_with_parameter(0x026e) aborted; SMU still servicing msg (0x0011) [...] Some data about the machine: $ inxi -b System: Kernel: 5.11.0-gentoo x86_64 bits: 64 Desktop: MATE 1.24.0 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop Mobo: ASRock model: A320M-HDV R3.0 serial: <superuser/root required> UEFI [Legacy]: American Megatrends v: P3.10 date: 06/26/2019 CPU: Info: Quad Core AMD A10-9700E RADEON R7 10 COMPUTE CORES 4C+6G [MCP] speed: 2485 MHz min/max: 800/3000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.10 driver: amdgpu,ati unloaded: fbdev,modesetting resolution: 1920x1080~60Hz OpenGL: renderer: AMD CARRIZO (DRM 3.40.0 5.11.0-gentoo LLVM 11.0.0) v: 4.6 Mesa 20.2.6 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 12

[PATCH v2 0/2] R-Car DU: Add DSI encoder driver for V3U
by Laurent Pinchart 28 Sep '21

28 Sep '21

Hello, This patch series adds a driver for the DSI encoder found in the R-Car V3U SoC, which is the first SoC in the family that supports DSI. The driver is based on an implementation from the BSP written by Luu Hoai, with lots of further rework. If anyone is interested in the history, a broken down v1 is available from [1]. The driver has been successfully tested on the Falcon board, which connects an SN65DSI86 to the output of the DSI encoder. Further patches are needed for the ti-sn65dsi86 driver to enable usage in plain DP (non-eDP) mode, as the Falcon board has a mini-DP connector wired to the output of the SN65DSI86. This is work in progress (see [2]). [1] https://lore.kernel.org/linux-renesas-soc/189c7a07-29cd-39f4-1dec-56aa94c11… [2] https://lore.kernel.org/linux-renesas-soc/20210322030128.2283-1-laurent.pin… LUU HOAI (1): drm: rcar-du: Add R-Car DSI driver Laurent Pinchart (1): dt-bindings: display: bridge: Add binding for R-Car MIPI DSI/CSI-2 TX .../display/bridge/renesas,dsi-csi2-tx.yaml | 118 +++ MAINTAINERS | 1 + drivers/gpu/drm/rcar-du/Kconfig | 6 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 827 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 172 ++++ 6 files changed, 1125 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h -- Regards, Laurent Pinchart

6 15

[Bug 212425] New: Kernel warning at drivers/gpu/drm/ttm/ttm_bo.c:517
by bugzilla-daemon＠bugzilla.kernel.org 28 Sep '21

28 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=212425 Bug ID: 212425 Summary: Kernel warning at drivers/gpu/drm/ttm/ttm_bo.c:517 Product: Drivers Version: 2.5 Kernel Version: 5.11.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: custos.mentis(a)gmail.com Regression: No After installing today's release of kernel 5.11.9 I am getting a bunch of kernel warnings like: [ 70.902471] WARNING: CPU: 6 PID: 2147 at drivers/gpu/drm/ttm/ttm_bo.c:517 ttm_bo_release+0x2b1/0x300 [ 70.902481] Modules linked in: nls_iso8859_2 nls_cp852 vfat fat uinput ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables ip6t_REJECT nf_reject_ipv6 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables x_tables kvm_amd kvm pcspkr irqbypass sp5100_tco snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer lm92 lm63 it87 hwmon_vid fam15h_power nfsd k10temp auth_rpcgss fuse oid_registry lockd grace hid_logitech_hidpp hid_logitech_dj hid_generic sr_mod cdrom sd_mod megaraid_sas 8250 8250_base serial_core usbhid sunrpc dm_mod dax [ 70.902541] CPU: 6 PID: 2147 Comm: kmail Tainted: G W 5.11.9-acrux #9 [ 70.902554] Hardware name: To be filled by O.E.M. To be filled by O.E.M./SABERTOOTH 990FX R2.0, BIOS 2901 05/04/2016 [ 70.902556] RIP: 0010:ttm_bo_release+0x2b1/0x300 [ 70.902559] Code: e8 74 2b 2f 00 e9 d9 fd ff ff 48 8b 7d 88 b9 30 75 00 00 31 d2 be 01 00 00 00 e8 3a 52 2f 00 48 8b 45 d8 eb 9d 4c 89 e0 eb 98 <0f> 0b c7 85 9c 00 00 00 00 00 00 00 4c 89 ef e8 4b f2 ff ff 48 8d [ 70.902561] RSP: 0018:ffffaf4a83313bb8 EFLAGS: 00010202 [ 70.902566] RAX: 0000000000000001 RBX: ffff961b7553c500 RCX: 0000000000000008 [ 70.902568] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffffffffa1db5248 [ 70.902570] RBP: ffff961b7553c570 R08: ffff961ba14f7a38 R09: ffff9621dedaa3f8 [ 70.902571] R10: ffff961ac60c1250 R11: ffff961ac60c1240 R12: ffff961ac5fe5588 [ 70.902572] R13: ffff961b7553c400 R14: 0000000000000000 R15: ffff961ac5fe5f48 [ 70.902573] FS: 00007ff78c2f5f00(0000) GS:ffff9621ded80000(0000) knlGS:0000000000000000 [ 70.902575] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 70.902576] CR2: 00007ff691820000 CR3: 0000000203d5d000 CR4: 00000000000406e0 [ 70.902578] Call Trace: [ 70.902580] ttm_bo_move_accel_cleanup+0x19d/0x398 [ 70.902583] amdgpu_bo_move+0x15c/0x698 [ 70.902586] ? amdgpu_vram_mgr_new+0x373/0x3d8 [ 70.902587] ttm_bo_handle_move_mem+0x8c/0x170 [ 70.902590] ttm_bo_validate+0x147/0x178 [ 70.902592] amdgpu_bo_fault_reserve_notify+0xbf/0x148 [ 70.902594] amdgpu_ttm_fault+0x33/0x80 [ 70.902596] __do_fault+0x33/0x90 [ 70.902599] handle_mm_fault+0xdff/0x1498 [ 70.902601] exc_page_fault+0x1a5/0x500 [ 70.902604] ? exit_to_user_mode_prepare+0x5d/0x118 [ 70.902607] ? asm_exc_page_fault+0x8/0x30 [ 70.902609] asm_exc_page_fault+0x1e/0x30 [ 70.902611] RIP: 0033:0x7ff78d8f290d [ 70.902612] Code: 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 6f 46 bc f3 0f 6f 4e cc 4c 8b 4e dc 4c 8b 56 e4 4c 8b 5e ec 48 8b 4e f4 8b 56 fc <f3> 0f 7f 47 bc f3 0f 7f 4f cc 4c 89 4f dc 4c 89 57 e4 4c 89 5f ec [ 70.902614] RSP: 002b:00007ffdbd5bb838 EFLAGS: 00010207 [ 70.902616] RAX: 00007ff691820000 RBX: 0000000000000044 RCX: 3f80000000000000 [ 70.902617] RDX: 0000000000000000 RSI: 000055d1049acad4 RDI: 00007ff691820044 [ 70.902618] RBP: 000055d1049aca90 R08: 000055d103fd9a30 R09: 0000000000000000 [ 70.902619] R10: 000000003f800000 R11: 3f800000bf800000 R12: 0000000000000000 [ 70.902620] R13: 000055d103f58320 R14: 0000000000000000 R15: 0000000000000044 Apparently the warnings show after commit 7d09e9725b5dcc8d14e101de931e4969d033a6ad, which explains that the warning is triggered by "very likely a driver bug". -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH] drm/nouveau: avoid a use-after-free when BO init fails
by Jeremy Cline 28 Sep '21

28 Sep '21

nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm_bo_init() invokes the provided destructor which should de-initialize and free the memory. Thus, when nouveau_bo_init() returns an error the gem object has already been released and the memory freed by nouveau_bo_del_ttm(). Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Jeremy Cline <jcline(a)redhat.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 787d05eefd9c..d30157cc7169 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -211,10 +211,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int align, uint32_t domain, } ret = nouveau_bo_init(nvbo, size, align, domain, NULL, NULL); - if (ret) { - nouveau_bo_ref(NULL, &nvbo); + if (ret) return ret; - } /* we restrict allowed domains on nv50+ to only the types * that were requested at creation time. not possibly on -- 2.28.0

3 2

[PATCH 00/11] treewide: address gcc-11 -Wstringop-overread warnings
by Arnd Bergmann 28 Sep '21

28 Sep '21

From: Arnd Bergmann <arnd(a)arndb.de> The coming gcc release introduces a new warning for string operations reading beyond the end of a fixed-length object. After testing randconfig kernels for a while, think I have patches for any such warnings that came up on x86, arm and arm64. Most of these warnings are false-positive ones, either gcc warning about something that is entirely correct, or about something that looks suspicious but turns out to be correct after all. The two patches for the i915 driver look like something that might be actual bugs, but I am not sure about those either. We probably want some combination of workaround like the ones I post here and changes to gcc to have fewer false positives in the release. I'm posting the entire set of workaround that give me a cleanly building kernel for reference here. Arnd Arnd Bergmann (11): x86: compressed: avoid gcc-11 -Wstringop-overread warning x86: tboot: avoid Wstringop-overread-warning security: commoncap: fix -Wstringop-overread warning ath11: Wstringop-overread warning qnx: avoid -Wstringop-overread warning cgroup: fix -Wzero-length-bounds warnings ARM: sharpsl_param: work around -Wstringop-overread warning atmel: avoid gcc -Wstringop-overflow warning scsi: lpfc: fix gcc -Wstringop-overread warning drm/i915: avoid stringop-overread warning on pri_latency [RFC] drm/i915/dp: fix array overflow warning arch/arm/common/sharpsl_param.c | 4 ++- arch/x86/boot/compressed/misc.c | 2 -- arch/x86/kernel/tboot.c | 44 +++++++++++++++---------- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 6 ++-- drivers/net/wireless/ath/ath11k/mac.c | 2 +- drivers/net/wireless/atmel/atmel.c | 25 ++++++++------ drivers/scsi/lpfc/lpfc_attr.c | 6 ++-- fs/qnx4/dir.c | 11 +++---- kernel/cgroup/cgroup.c | 15 +++++++-- security/commoncap.c | 2 +- 11 files changed, 69 insertions(+), 50 deletions(-) Cc: x86(a)kernel.org Cc: Ning Sun <ning.sun(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Kalle Valo <kvalo(a)codeaurora.org> Cc: Simon Kelley <simon(a)thekelleys.org.uk> Cc: James Smart <james.smart(a)broadcom.com> Cc: "James E.J. Bottomley" <jejb(a)linux.ibm.com> Cc: Anders Larsen <al(a)alarsen.net> Cc: Tejun Heo <tj(a)kernel.org> Cc: Serge Hallyn <serge(a)hallyn.com> Cc: Imre Deak <imre.deak(a)intel.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: tboot-devel(a)lists.sourceforge.net Cc: intel-gfx(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: ath11k(a)lists.infradead.org Cc: linux-wireless(a)vger.kernel.org Cc: netdev(a)vger.kernel.org Cc: linux-scsi(a)vger.kernel.org Cc: cgroups(a)vger.kernel.org Cc: linux-security-module(a)vger.kernel.org -- 2.29.2

12 31

[Bug 85421] New: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '21

24 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=85421 Bug ID: 85421 Summary: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox. Product: Drivers Version: 2.5 Kernel Version: 3.16.3 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: htl10(a)users.sourceforge.net Regression: No Created attachment 152191 --> https://bugzilla.kernel.org/attachment.cgi?id=152191&action=edit /var/log/messages from radeon 0000:00:01.0: ring 0 stalled to reboot. I was away from the computer when the radeon dri driver crashed; I left a fair number of firefox windows on/tab, some of them may have videos (from BBC news web site) and animated gifs from another web site on; but it crashed about 5-10 minutes after I was away and I was aware of it because the laptop blipped. # lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] some excerpt from the attached logs are: ... [ 8770.250116] radeon 0000:00:01.0: ring 0 stalled for more than 10012msec [ 8770.250128] radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000056034 last fence id 0x0000000000056031 on ring 0) [ 8770.298635] radeon 0000:00:01.0: Saved 14196 dwords of commands on ring 0. [ 8770.298663] radeon 0000:00:01.0: GPU softreset: 0x0000000C ... [ 8770.313299] radeon 0000:00:01.0: GPU reset succeeded, trying to resume ... [ 8770.339724] [drm] ring test on 0 succeeded in 3 usecs [ 8770.518568] [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed (scratch(0x3010C)=0xCAFEDEAD) [ 8770.752885] [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) [ 8770.752892] [drm:cik_resume] *ERROR* cik startup failed on resume [ 8780.753181] radeon 0000:00:01.0: ring 0 stalled for more than 10001msec [ 8780.753193] radeon 0000:00:01.0: GPU lockup (waiting for 0x00000000000560f7 last fence id 0x0000000000056031 on ring 0) [ 8780.753199] [drm:cik_ib_test] *ERROR* radeon: fence wait failed (-35). [ 8780.753209] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 8780.753215] radeon 0000:00:01.0: ib ring test failed (-35). [ 8780.762131] radeon 0000:00:01.0: GPU softreset: 0x0000000C ... The kernel is a largely fedora 3.16.3-200 one grabbed from the koji srpm but with the additional patch from https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8 drv ati 7.4.0 , mesa 10.2.8, glamor from git 347ef4 . -- You are receiving this mail because: You are watching the assignee of the bug.

1 41

[PATCH] vgaarb: Use ACPI HID name to find integrated GPU
by Kai-Heng Feng 23 Sep '21

23 Sep '21

Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes the first device is an integrated GPU. However, on AMD platforms an integrated GPU can have higher PCI device number than a discrete GPU. Integrated GPU on ACPI platform generally has _DOD and _DOS method, so use that as predicate to find integrated GPU. If the new strategy doesn't work, fallback to use the first device as boot VGA. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/gpu/vga/vgaarb.c | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index 5180c5687ee5..949fde433ea2 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -50,6 +50,7 @@ #include <linux/screen_info.h> #include <linux/vt.h> #include <linux/console.h> +#include <linux/acpi.h> #include <linux/uaccess.h> @@ -1450,9 +1451,23 @@ static struct miscdevice vga_arb_device = { MISC_DYNAMIC_MINOR, "vga_arbiter", &vga_arb_device_fops }; +#if defined(CONFIG_ACPI) +static bool vga_arb_integrated_gpu(struct device *dev) +{ + struct acpi_device *adev = ACPI_COMPANION(dev); + + return adev && !strcmp(acpi_device_hid(adev), ACPI_VIDEO_HID); +} +#else +static bool vga_arb_integrated_gpu(struct device *dev) +{ + return false; +} +#endif + static void __init vga_arb_select_default_device(void) { - struct pci_dev *pdev; + struct pci_dev *pdev, *found = NULL; struct vga_device *vgadev; #if defined(CONFIG_X86) || defined(CONFIG_IA64) @@ -1505,20 +1520,26 @@ static void __init vga_arb_select_default_device(void) #endif if (!vga_default_device()) { - list_for_each_entry(vgadev, &vga_list, list) { + list_for_each_entry_reverse(vgadev, &vga_list, list) { struct device *dev = &vgadev->pdev->dev; u16 cmd; pdev = vgadev->pdev; pci_read_config_word(pdev, PCI_COMMAND, &cmd); if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) { - vgaarb_info(dev, "setting as boot device (VGA legacy resources not available)\n"); - vga_set_default_device(pdev); - break; + found = pdev; + if (vga_arb_integrated_gpu(dev)) + break; } } } + if (found) { + vgaarb_info(&found->dev, "setting as boot device (VGA legacy resources not available)\n"); + vga_set_default_device(found); + return; + } + if (!vga_default_device()) { vgadev = list_first_entry_or_null(&vga_list, struct vga_device, list); -- 2.31.1

3 6

← Newer
1
...
7
8
9
10
11
12
13
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021