dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[Bug 213391] New: AMDGPU retries page fault with some specific processes amdgpu: [gfxhub0] retry page fault until *ERROR* ring gfx timeout, but soft recovered
by bugzilla-daemon＠bugzilla.kernel.org 19 Nov '21

19 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=213391 Bug ID: 213391 Summary: AMDGPU retries page fault with some specific processes amdgpu: [gfxhub0] retry page fault until *ERROR* ring gfx timeout, but soft recovered Product: Drivers Version: 2.5 Kernel Version: Linux 5.12.9-arch-1-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: samy(a)lahfa.xyz Regression: No Hi, I just updated recently from mainstream Kernel 5.11.16 to 5.12.9 and I've ran into this issue, I've also updated the Mesa driver from mesa-git (21.1.0_devel.137307.f8e5f945b8f-1) to mesa-git (21.2.0_devel.140633.c04f20e7e01-1). Current kernel parameters : /vmlinuz-linux zfs=zroot/ROOT/default rw loglevel=3 quiet radeon.si_support=0 amdgpu.si_support=1 radeon.cik_support=0 amdgpu.cik_support=1 My computer is a Thinkpad T495 laptop (AMD Ryzen 7 3700 Pro with an iGPU RX VEGA 10, 16GB DDR4 3200Mhz) the very important bit of information is that the BIOS reserves up to 2GB of DDR4 RAM for the iGPU VRAM, I currently have setup 1GB (1024MB) of RAM in my BIOS for the iGPU, I'm thinking the page fault retries could be linked to this in someways. I think this has a higher chance of happening when my RAM memory is under heavy load and the system is swapping quite a lot too. (I have 12.3GB of Swap on a NVMe PCIe 3.0) At present, I cannot reproduce this issue consistently yet, however it has been happening with web browsers Qutebrowser (more with Qutebrowser) and also happened only once with Chromium (made the X11 server crash and the computer completely froze, kernel was still responsive to SysReq keys hence I could get out of that tricky situation safely). I'll be uploading both logs of the crashes I have encountered along with an lspci and other logs files that could be useful. Kind regards, Lahfa Samy -- 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 40

[PATCH 00/11] drm/msm/dpu: cleanup plane state
by Dmitry Baryshkov 18 Nov '21

18 Nov '21

This is a cleanup part of the DPU multirect patchset [1], split away to ease review and merging per Abhinav's request. Currently significant part of atomic plane state is stored in the drm_plane's subclass rather than drm_plane_state's subclass. Move it either to the drm_plane_state or even to the on-stack allocation. [1] https://lore.kernel.org/linux-arm-msm/20210705012115.4179824-1-dmitry.barys…

3 24

[PATCH] drm/i915/vlv_dsi: Double pixelclock on read-back for dual-link panels
by Hans de Goede 18 Nov '21

18 Nov '21

In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk() for dual-link panels. This fixes the following WARN triggering: i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.adjusted_mode.crtc_clock (expected 235710, found 118056) i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in port_clock (expected 235710, found 118056) ------------[ cut here ]------------ pipe state doesn't match! WARNING: CPU: 3 PID: 136 at drivers/gpu/drm/i915/display/intel_display.c:9125 intel_display_finish_reset+0x1bd3/0x2050 [i915] ... This has been tested on a Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC) tablet, with a 1536x2048 dual-link DSI panel. Note this fix was taken from icl_dsi.c which does the same in its get_config(). Cc: Tsuchiya Yuto <kitakar(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/i915/display/vlv_dsi.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c index 3e646a58b38a..2b7909bc52ff 100644 --- a/drivers/gpu/drm/i915/display/vlv_dsi.c +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c @@ -1265,7 +1265,9 @@ static void intel_dsi_get_config(struct intel_encoder *encoder, struct intel_crtc_state *pipe_config) { struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); + struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder); u32 pclk; + drm_dbg_kms(&dev_priv->drm, "\n"); pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI); @@ -1277,6 +1279,9 @@ static void intel_dsi_get_config(struct intel_encoder *encoder, pclk = vlv_dsi_get_pclk(encoder, pipe_config); } + if (intel_dsi->dual_link) + pclk *= 2; + if (pclk) { pipe_config->hw.adjusted_mode.crtc_clock = pclk; pipe_config->port_clock = pclk; -- 2.31.1

2 2

[PATCH v6 0/5] CMDQ refinement of Mediatek DRM driver
by jason-jh.lin 17 Nov '21

17 Nov '21

Change in v6: 1. Drop the redundant checking of cmdq_vblank_cnt . 2. fix the indent. Change in v5: 1. Move mbox_free_channel to a independent patch. Change in v4: 1. Add cmdq_vblank_cnt initial value to 3. 2. Move mtk_drm_cmdq_pkt_create to the same define scope with mtk_drm_cmdq_pkt_destroy. Change in v3: 1. Revert "drm/mediatek: clear pending flag when cmdq packet is done" and add it after the CMDQ refinement patches. 2. Change the remove of struct cmdq_client to remove the pointer of struct cmdq_client. 3. Fix pkt buf alloc once but free many times. Changes in v2: 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy() when CONFIG_MTK_CMDQ is reachable. Chun-Kuang Hu (4): drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb drm/mediatek: Remove the pointer of struct cmdq_client drm/mediatek: Detect CMDQ execution timeout drm/mediatek: Add cmdq_handle in mtk_crtc Yongqiang Niu (1): drm/mediatek: Clear pending flag when cmdq packet is done jason-jh.lin (1): drm/mediatek: Add mbox_free_channel in mtk_drm_crtc_destroy drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 175 ++++++++++++++++++++---- 1 file changed, 151 insertions(+), 24 deletions(-) -- 2.18.0

3 8

[PATCH v5 0/6] CMDQ refinement of Mediatek DRM driver
by jason-jh.lin 17 Nov '21

17 Nov '21

These refinements include using standard mailbox callback interface, timeout detection, and a fixed cmdq_handle. Change in v5: 1. Move mbox_free_channel to a independent patch. Change in v4: 1. Add cmdq_vblank_cnt initial value to 3. 2. Move mtk_drm_cmdq_pkt_create to the same define scope with mtk_drm_cmdq_pkt_destroy. Change in v3: 1. Revert "drm/mediatek: clear pending flag when cmdq packet is done" and add it after the CMDQ refinement patches. 2. Change the remove of struct cmdq_client to remove the pointer of struct cmdq_client. 3. Fix pkt buf alloc once but free many times. Changes in v2: 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy() when CONFIG_MTK_CMDQ is reachable. Chun-Kuang Hu (4): drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb drm/mediatek: Remove the pointer of struct cmdq_client drm/mediatek: Detect CMDQ execution timeout drm/mediatek: Add cmdq_handle in mtk_crtc Yongqiang Niu (1): drm/mediatek: Clear pending flag when cmdq packet is done. jason-jh.lin (1): drm/mediatek: Add mbox_free_channel in mtk_drm_crtc_destroy drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 174 ++++++++++++++++++++---- 1 file changed, 150 insertions(+), 24 deletions(-) -- 2.18.0

3 12

[RFC PATCH 0/8] GPU memory tracepoints
by Gurchetan Singh 17 Nov '21

17 Nov '21

This is latest iteration of GPU memory tracepoints [1]. In the past, there were questions about the "big picture" of memory accounting [2], especially given related work on dma-buf heaps and DRM cgroups [3]. Also, there was a desire for a non-driver specific solution. The great news is the dma-buf heaps work as recently landed [4]. It uses sys-fs and the plan is to use it in conjunction with the tracepoint solution [5]. We're aiming for the GPU tracepoint to calculate totals per DRM-instance (a proxy for per-process on Android) and per-DRM device. The cgroups work looks terrific too and hopefully we can deduplicate code once that's merged. Though that's abit of an implementation detail, so long as the "GPU tracepoints" + "dma-buf heap stats" plan sounds good for Android. This series modifies the GPU memory tracepoint API in a non-breaking fashion (patch 1), and adds accounting via the GEM subsystem (patches 2 --> 7). Given the multiple places where memory events happen, there's a bunch trace events scattered in various places. The hardest part is allocation, where each driver has their own API. If there's a better way, do say so. The last patch is incomplete; we would like general feedback before proceeding further. [1] https://lore.kernel.org/lkml/20200302235044.59163-1-zzyiwei@google.com/ [2] https://lists.freedesktop.org/archives/dri-devel/2021-January/295120.html [3] https://www.spinics.net/lists/cgroups/msg27867.html [4] https://www.spinics.net/lists/linux-doc/msg97788.html [5] https://source.android.com/devices/graphics/implement-dma-buf-gpu-mem Gurchetan Singh (8): tracing/gpu: modify gpu_mem_total drm: add new tracepoint fields to drm_device and drm_file drm: add helper functions for gpu_mem_total and gpu_mem_instance drm: start using drm_gem_trace_gpu_mem_total drm: start using drm_gem_trace_gpu_mem_instance drm: track real and fake imports in drm_prime_member drm: trace memory import per DRM file drm: trace memory import per DRM device drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/drm_gem.c | 65 +++++++++++++++++++++++++++++++++- drivers/gpu/drm/drm_internal.h | 4 +-- drivers/gpu/drm/drm_prime.c | 22 +++++++++--- include/drm/drm_device.h | 16 +++++++++ include/drm/drm_file.h | 16 +++++++++ include/drm/drm_gem.h | 7 ++++ include/trace/events/gpu_mem.h | 61 +++++++++++++++++++++---------- 8 files changed, 166 insertions(+), 26 deletions(-) -- 2.25.1

5 18

[Bug 214859] New: drm-amdgpu-init-iommu~fd-device-init.patch introduce bug
by bugzilla-daemon＠bugzilla.kernel.org 17 Nov '21

17 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=214859 Bug ID: 214859 Summary: drm-amdgpu-init-iommu~fd-device-init.patch introduce bug Product: Drivers Version: 2.5 Kernel Version: 5.14.15 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: towo(a)siduction.org Regression: No After commit d60096b3b2c2..cd8cc7d31b49 100644 drm-amdgpu-init-iommu~fd-device-init.patch Kernel 5.14.15 on most Ryzen Notebooks X cant't start really. There is a long time, before x is starting, dmesg is spammed with failure messages like Okt 28 10:28:08 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 28b4 wait reg 28c6 Okt 28 10:28:21 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706 Okt 28 10:28:34 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 28b4 wait reg 28c6 Okt 28 10:28:47 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706 Okt 28 10:29:01 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 28b4 wait reg 28c6 Okt 28 10:29:14 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706 Okt 28 10:29:27 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 28b4 wait reg 28c6 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706 and/or Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: [gfxhub0] no-retry page fault (src_id:0 ring:128 vmid:0 pasid:0, for process pid 0 thread pid 0) Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: in page starting at address 0x0000000000872000 from IH client 0x1b (UTCL2) Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00040D00 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: Faulty UTCL2 client ID: CPG (0x6) Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: MORE_FAULTS: 0x0 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: WALKER_ERROR: 0x0 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: PERMISSION_FAULTS: 0x0 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: MAPPING_ERROR: 0x1 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: RW: 0x1 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: [gfxhub0] no-retry page fault (src_id:0 ring:128 vmid:0 pasid:0, for process pid 0 thread pid 0) Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: in page starting at address 0x0000000000872000 from IH client 0x1b (UTCL2) Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00040D00 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: Faulty UTCL2 client ID: CPG (0x6) Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: MORE_FAULTS: 0x0 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: WALKER_ERROR: 0x0 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: PERMISSION_FAULTS: 0x0 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: MAPPING_ERROR: 0x1 Okt 28 10:29:40 kernel: ^[[0;1;39mamdgpu 0000:04:00.0: amdgpu: RW: 0x1 Reverting that commit and the kernel is back working normal. Here the related reports from our users (ignore the nvidia posts). https://forum.siduction.org/index.php?topic=8439.0 -- 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 9

[PATCH v7 00/20] Add MediaTek SoC DRM (vdosys1) support for mt8195
by Nancy.Lin 17 Nov '21

17 Nov '21

The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. Add DRM and these modules support by the patches below: Changes in v7: - rebase on vdosys0 series v12 (ref[5]) - add dma description in ethdr binding document. - refine vdosys1 bit definition of mmsys routing table. - separate merge modification into 3 pathces. - separate mutex modification into 2 patches. - add plane color coding for mdp_rdma csc. - move mdp_rdma pm control to ovl_adaptor. - fix reviewer comment in v6. Changes in v6: - rebase on kernel-5.15-rc1. - change mbox label to gce0 for dts node of vdosys1. - modify mmsys reset num for mt8195. - rebase on vdosys0 series v10. (ref [5]) - use drm to bring up ovl_adaptor driver. - move drm iommu/mutex check from kms init to drm bind. - modify rdma binding doc location. (Documentation/devicetree/bindings/arm/) - modify for reviewer's comment in v5. Changes in v5: - add mmsys reset controller reference. Changes in v4: - use merge common driver for merge1~4. - refine ovl_adaptor rdma driver. - use ovl_adaptor ddp_comp function instead of ethdr. - modify for reviewer's comment in v3. Changes in v3: - modify for reviewer's comment in v2. - add vdosys1 2 pixels align limit. - add mixer odd offset support. Changes in v2: - Merge PSEUDO_OVL and ETHDR into one DRM component. - Add mmsys config API for vdosys1 hardware setting. - Add mmsys reset control using linux reset framework. Signed-off-by: Nancy.Lin <nancy.lin(a)mediatek.com> This series are based on the following patch: [1] arm64: dts: Add Mediatek SoC MT8195 and evaluation board dts and Makefile https://patchwork.kernel.org/project/linux-mediatek/patch/20210601075350.31… [2] arm64: dts: mt8195: add IOMMU and smi nodes https://patchwork.kernel.org/project/linux-mediatek/patch/20210615173233.26… [3] [01/24] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU https://patchwork.kernel.org/project/linux-mediatek/patch/20210630023504.18… [4] Add gce support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/list/?series=537069 [5] Add MediaTek SoC DRM (vdosys0) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/list/?series=570497 [6] [v8,1/2] dt-bindings: reset: mt8195: add toprgu reset-controller header file https://patchwork.kernel.org/project/linux-mediatek/patch/20210806023606.16… [7] [v3,2/7] dt-bindings: mediatek: Add #reset-cells to mmsys system controller https://patchwork.kernel.org/project/linux-mediatek/patch/20210825122613.v3… [8] [v4,6/7] soc: mediatek: mmsys: Add reset controller support https://patchwork.kernel.org/project/linux-mediatek/patch/20210930103105.v4… Nancy.Lin (20): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: mediatek: add vdosys1 MERGE property for mt8195 dt-bindings: mediatek: add ethdr definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit arm64: dts: mt8195: add display node for vdosys1 soc: mediatek: add mtk-mmsys support for mt8195 vdosys1 soc: mediatek: add mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: add cmdq support of mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1 soc: mediatek: change the mutex defines and the mutex_mod type soc: mediatek: add mtk-mutex support for mt8195 vdosys1 drm/mediatek: add display MDP RDMA support for MT8195 drm/mediatek: add display merge advance config API for MT8195 drm/mediatek: add display merge start/stop API for cmdq support drm/mediatek: add display merge mute/unmute support for MT8195 drm/mediatek: add ETHDR support for MT8195 drm/mediatek: add mediatek-drm plane color encoding info drm/mediatek: add ovl_adaptor support for MT8195 drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support drm/mediatek: add mediatek-drm of vdosys1 support for MT8195 .../arm/mediatek/mediatek,mdp-rdma.yaml | 77 ++++ .../display/mediatek/mediatek,ethdr.yaml | 147 ++++++ .../display/mediatek/mediatek,merge.yaml | 4 + arch/arm64/boot/dts/mediatek/mt8195.dtsi | 222 +++++++++ drivers/gpu/drm/mediatek/Makefile | 5 +- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 28 ++ drivers/gpu/drm/mediatek/mtk_disp_merge.c | 99 +++- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 436 ++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 35 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 339 ++++++++++---- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 10 +- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_plane.h | 1 + drivers/gpu/drm/mediatek/mtk_ethdr.c | 399 ++++++++++++++++ drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 316 +++++++++++++ drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 20 + drivers/soc/mediatek/mt8195-mmsys.h | 199 ++++++++ drivers/soc/mediatek/mtk-mmsys.c | 80 +++- drivers/soc/mediatek/mtk-mmsys.h | 12 + drivers/soc/mediatek/mtk-mutex.c | 296 +++++++----- include/dt-bindings/reset/mt8195-resets.h | 12 + include/linux/soc/mediatek/mtk-mmsys.h | 22 + 26 files changed, 2574 insertions(+), 245 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h -- 2.18.0

2 34

[PATCH] drm/nouveau/core: fix the uninitialized use in nvkm_ioctl_map()
by Yizhuo Zhai 16 Nov '21

16 Nov '21

In function nvkm_ioctl_map(), the variable "type" could be uninitialized if "nvkm_object_map()" returns error code, however, it does not check the return value and directly use the "type" in the if statement, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003(a)ucr.edu> --- drivers/gpu/drm/nouveau/nvkm/core/ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c index d777df5a64e6..7f2e8482f167 100644 --- a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c +++ b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c @@ -266,6 +266,8 @@ nvkm_ioctl_map(struct nvkm_client *client, ret = nvkm_object_map(object, data, size, &type, &args->v0.handle, &args->v0.length); + if (ret) + return ret; if (type == NVKM_OBJECT_MAP_IO) args->v0.type = NVIF_IOCTL_MAP_V0_IO; else -- 2.17.1

2 3

Deploying new iterator interface for dma-buf
by Christian König 16 Nov '21

16 Nov '21

Hopefully the last round for this. Added dma_resv_iter_begin/end as requested by Daniel. Fixed a bunch of problems pointed out by the CI systems and found a few more myselve. Please review and/or comment, Christian.

4 59

← Newer
1
...
10
11
12
13
14
15
16
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021