dri-devel January 2022

dri-devel@lists.freedesktop.org

373 participants
842 discussions

[PATCH v5, 00/15] media: mtk-vcodec: support for MT8192 decoder
by Yunfei Dong 20 Jan '22

20 Jan '22

This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly, refactor power/clock/interrupt interfaces for mt8192 is lat and core architecture. Secondly, add new functions to get frame buffer size and resolution according to decoder capability from scp side. Then add callback function to get/put capture buffer in order to enable lat and core decoder in parallel. Then add to support MT21C compressed mode and fix v4l2-compliance fail. Next, extract H264 request api driver to let mt8183 and mt8192 use the same code, and adds mt8192 frame based h264 driver for stateless decoder. Lastly, add vp8 and vp9 stateless decoder drivers. Patches 1 refactor power/clock/interrupt interface. Patches 2~4 get frame buffer size and resolution according to decoder capability. Patches 5~6 enable lat and core decode in parallel. Patch 7~10 add to support MT21C compressed mode and fix v4l2-compliance fail. patch 11 record capture queue format type. Patch 12~13 extract h264 driver and add mt8192 frame based driver for h264 decoder. Patch 14~15 add vp8 and vp9 stateless decoder drivers. --- changes compared with v4: - fix checkpatch.pl fail. - fix kernel-doc fail. - rebase to the latest media codec driver. changes compared with v3: - remove enum mtk_chip for patch 2. - add vp8 stateless decoder drivers for patch 14. - add vp9 stateless decoder drivers for patch 15. changes compared with v2: - add new patch 11 to record capture queue format type. - separate patch 4 according to tzung-bi's suggestion. - re-write commit message for patch 5 according to tzung-bi's suggestion. changes compared with v1: - rewrite commit message for patch 12. - rewrite cover-letter message. --- Yunfei Dong (15): media: mtk-vcodec: Add vdec enable/disable hardware helpers media: mtk-vcodec: Using firmware type to separate different firmware architecture media: mtk-vcodec: get capture queue buffer size from scp media: mtk-vcodec: Read max resolution from dec_capability media: mtk-vcodec: Call v4l2_m2m_set_dst_buffered() set capture buffer buffered media: mtk-vcodec: Refactor get and put capture buffer flow media: mtk-vcodec: Refactor supported vdec formats and framesizes media: mtk-vcodec: Add format to support MT21C media: mtk-vcodec: disable vp8 4K capability media: mtk-vcodec: Fix v4l2-compliance fail media: mtk-vcodec: record capture queue format type media: mtk-vcodec: Extract H264 common code media: mtk-vcodec: support stateless H.264 decoding for mt8192 media: mtk-vcodec: support stateless VP8 decoding media: mtk-vcodec: support stateless VP9 decoding drivers/media/platform/mtk-vcodec/Makefile | 4 + .../platform/mtk-vcodec/mtk_vcodec_dec.c | 47 +- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 - .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 168 +- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 6 +- .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 14 +- .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 281 ++- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 40 +- .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 5 - .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 6 + .../media/platform/mtk-vcodec/mtk_vcodec_fw.h | 1 + .../mtk-vcodec/vdec/vdec_h264_req_common.c | 307 +++ .../mtk-vcodec/vdec/vdec_h264_req_common.h | 253 +++ .../mtk-vcodec/vdec/vdec_h264_req_if.c | 411 +--- .../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 599 +++++ .../mtk-vcodec/vdec/vdec_vp8_req_if.c | 440 ++++ .../mtk-vcodec/vdec/vdec_vp9_req_lat_if.c | 1973 +++++++++++++++++ .../media/platform/mtk-vcodec/vdec_drv_if.c | 36 +- .../media/platform/mtk-vcodec/vdec_drv_if.h | 3 + .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 36 + .../platform/mtk-vcodec/vdec_msg_queue.c | 2 + .../media/platform/mtk-vcodec/vdec_vpu_if.c | 53 +- .../media/platform/mtk-vcodec/vdec_vpu_if.h | 15 + .../media/platform/mtk-vcodec/venc_vpu_if.c | 2 +- include/linux/remoteproc/mtk_scp.h | 2 + 25 files changed, 4128 insertions(+), 581 deletions(-) create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.h create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c -- 2.25.1

2 19

[PATCH] drm: document struct drm_mode_fb_cmd2
by Simon Ser 20 Jan '22

20 Jan '22

Follow-up for the DRM_IOCTL_MODE_GETFB2 docs. Signed-off-by: Simon Ser <contact(a)emersion.fr> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Daniel Stone <daniels(a)collabora.com> --- include/uapi/drm/drm_mode.h | 83 ++++++++++++++++++++++++------------- 1 file changed, 55 insertions(+), 28 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index e1e351682872..5dbbe1393bff 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -663,41 +663,68 @@ struct drm_mode_fb_cmd { #define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */ #define DRM_MODE_FB_MODIFIERS (1<<1) /* enables ->modifer[] */ +/** + * struct drm_mode_fb_cmd2 - Frame-buffer metadata. + * + * This struct holds frame-buffer metadata. There are two ways to use it: + * + * - User-space can fill this struct and perform an &DRM_IOCTL_MODE_ADDFB2 + * ioctl to register a new frame-buffer. The new frame-buffer object ID will + * be set by the kernel in @fb_id. + * - User-space can set @fb_id and perform a &DRM_IOCTL_MODE_GETFB2 ioctl to + * fetch metadata about an existing frame-buffer. + * + * In case of planar formats, this struct allows up to 4 buffer objects with + * offsets and pitches per plane. The pitch and offset order is dictated by the + * fourcc, e.g. NV12 (https://fourcc.org/yuv.php#NV12) is described as: + * + * YUV 4:2:0 image with a plane of 8 bit Y samples followed by an + * interleaved U/V plane containing 8 bit 2x2 subsampled colour difference + * samples. + * + * So it would consist of Y as ``offsets[0]`` and UV as ``offsets[1]``. Note + * that ``offsets[0]`` will generally be 0 (but this is not required). + * + * To accommodate tiled, compressed, etc formats, a modifier can be specified. + * For more information see the "Format Modifiers" section. Note that even + * though it looks like we have a modifier per-plane, we in fact do not. The + * modifier for each plane must be identical. Thus all combinations of + * different data layouts for multi-plane formats must be enumerated as + * separate modifiers. + */ struct drm_mode_fb_cmd2 { + /** @fb_id: Object ID of the frame-buffer. */ __u32 fb_id; + /** @width: Width of the frame-buffer. */ __u32 width; + /** @height: Height of the frame-buffer. */ __u32 height; - __u32 pixel_format; /* fourcc code from drm_fourcc.h */ - __u32 flags; /* see above flags */ + /** + * @pixel_format: FourCC format code, see ``DRM_FORMAT_*`` constants in + * ``drm_fourcc.h``. + */ + __u32 pixel_format; + /** + * @flags: Frame-buffer flags (see &DRM_MODE_FB_INTERLACED and + * &DRM_MODE_FB_MODIFIERS). + */ + __u32 flags; - /* - * In case of planar formats, this ioctl allows up to 4 - * buffer objects with offsets and pitches per plane. - * The pitch and offset order is dictated by the fourcc, - * e.g. NV12 (https://fourcc.org/yuv.php#NV12) is described as: - * - * YUV 4:2:0 image with a plane of 8 bit Y samples - * followed by an interleaved U/V plane containing - * 8 bit 2x2 subsampled colour difference samples. - * - * So it would consist of Y as offsets[0] and UV as - * offsets[1]. Note that offsets[0] will generally - * be 0 (but this is not required). - * - * To accommodate tiled, compressed, etc formats, a - * modifier can be specified. The default value of zero - * indicates "native" format as specified by the fourcc. - * Vendor specific modifier token. Note that even though - * it looks like we have a modifier per-plane, we in fact - * do not. The modifier for each plane must be identical. - * Thus all combinations of different data layouts for - * multi plane formats must be enumerated as separate - * modifiers. + /** + * @handles: GEM buffer handle, one per plane. Set to 0 if the plane is + * unused. */ __u32 handles[4]; - __u32 pitches[4]; /* pitch for each plane */ - __u32 offsets[4]; /* offset of each plane */ - __u64 modifier[4]; /* ie, tiling, compress */ + /** @pitches: Pitch (aka. stride), one per plane. */ + __u32 pitches[4]; + /** @offsets: Offset into the buffer, one per plane. */ + __u32 offsets[4]; + /** + * @modifier: Format modifier, one per plane. See ``DRM_FORMAT_MOD_*`` + * constants in ``drm_fourcc.h``. All planes must use the same + * modifier. Ignored unless &DRM_MODE_FB_MODIFIERS is set in @flags. + */ + __u64 modifier[4]; }; #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01 base-commit: 37e0321ab2569b44f8a94339bf47653493ac864e -- 2.34.1

3 2

[PATCH 0/6] drm/meson: add support for AXG & MIPI-DSI
by Neil Armstrong 20 Jan '22

20 Jan '22

The Amlogic AXG SoC family has a downgraded VPU with the following changes : - Only a single OSD plane, no overlay video plane - The primary plane doesn't support HW scaling - The pixels are read directly from DDR without any Canvas module - Doesn't support HDMI or CVBS - Ouputs only with ENCL encoder to a DPI-to-DSI Synopsys DW-MIPI-DSI transceiver The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), with a custom glue managing the IP resets, clock and data input similar to the DW-HDMI Glue on other Amlogic SoCs. This adds support for the Glue managing the transceiver, mimicing the init flow provided by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital D-PHY and the Analog PHY in the proper way. The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, which pixel clock is derived and feeds the ENCL encoder and the VIU pixel reader. An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the DW-MIPI-DSI transceiver. Neil Armstrong (6): dt-bindings: display: amlogic,meson-vpu: add bindings for VPU found in AXG SoCs dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings drm/meson: add support for VPU found in AXG SoCs drm/meson: venc: add ENCL encoder setup for MIPI-DSI output drm/meson: remove useless recursive components matching drm/meson: add support for MIPI-DSI transceiver .../display/amlogic,meson-dw-mipi-dsi.yaml | 115 ++++ .../bindings/display/amlogic,meson-vpu.yaml | 36 +- drivers/gpu/drm/meson/Kconfig | 7 + drivers/gpu/drm/meson/Makefile | 1 + drivers/gpu/drm/meson/meson_crtc.c | 8 +- drivers/gpu/drm/meson/meson_drv.c | 163 ++--- drivers/gpu/drm/meson/meson_drv.h | 10 +- drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++++++++++++++++++ drivers/gpu/drm/meson/meson_plane.c | 74 ++- drivers/gpu/drm/meson/meson_registers.h | 1 + drivers/gpu/drm/meson/meson_venc.c | 230 ++++++- drivers/gpu/drm/meson/meson_venc.h | 6 + drivers/gpu/drm/meson/meson_viu.c | 50 +- drivers/gpu/drm/meson/meson_vpp.c | 6 +- drivers/gpu/drm/meson/meson_vpp.h | 2 + 15 files changed, 1176 insertions(+), 95 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c -- 2.22.0

4 21

[PATCH] drm/locking: fix drm_modeset_acquire_ctx kernel-doc
by Jani Nikula 20 Jan '22

20 Jan '22

The stack_depot member was added without kernel-doc, leading to below warning. Fix it. ./include/drm/drm_modeset_lock.h:74: warning: Function parameter or member 'stack_depot' not described in 'drm_modeset_acquire_ctx' Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Fixes: cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- include/drm/drm_modeset_lock.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h index b84693fbd2b5..ec4f543c3d95 100644 --- a/include/drm/drm_modeset_lock.h +++ b/include/drm/drm_modeset_lock.h @@ -34,6 +34,7 @@ struct drm_modeset_lock; * struct drm_modeset_acquire_ctx - locking context (see ww_acquire_ctx) * @ww_ctx: base acquire ctx * @contended: used internally for -EDEADLK handling + * @stack_depot: used internally for contention debugging * @locked: list of held locks * @trylock_only: trylock mode used in atomic contexts/panic notifiers * @interruptible: whether interruptible locking should be used. -- 2.30.2

3 4

[syzbot] WARNING in dma_map_sgtable
by syzbot 20 Jan '22

20 Jan '22

Hello, syzbot found the following issue on: HEAD commit: e3a8b6a1e70c Merge tag 'slab-for-5.17-part2' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1507e01fb00000 kernel config: https://syzkaller.appspot.com/x/.config?x=73c17fd2d4a060fe dashboard link: https://syzkaller.appspot.com/bug?extid=d03b64357793677f0080 compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d03b64357793677f0080(a)syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 1 PID: 21150 at kernel/dma/mapping.c:188 __dma_map_sg_attrs kernel/dma/mapping.c:188 [inline] WARNING: CPU: 1 PID: 21150 at kernel/dma/mapping.c:188 dma_map_sgtable+0x203/0x260 kernel/dma/mapping.c:264 Modules linked in: CPU: 1 PID: 21150 Comm: syz-executor.5 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs kernel/dma/mapping.c:188 [inline] RIP: 0010:dma_map_sgtable+0x203/0x260 kernel/dma/mapping.c:264 Code: 75 15 e8 50 b2 13 00 eb cb e8 49 b2 13 00 eb c4 e8 42 b2 13 00 eb bd e8 3b b2 13 00 0f 0b bd fb ff ff ff eb af e8 2d b2 13 00 <0f> 0b 31 ed 48 bb 00 00 00 00 00 fc ff df e9 7b ff ff ff 89 e9 80 RSP: 0018:ffffc9000969fd20 EFLAGS: 00010287 RAX: ffffffff8171ee13 RBX: dffffc0000000000 RCX: 0000000000040000 RDX: ffffc900056f9000 RSI: 000000000000079b RDI: 000000000000079c RBP: ffff888147437408 R08: ffffffff8171ece3 R09: ffffed100d4e6956 R10: ffffed100d4e6956 R11: 0000000000000000 R12: ffff888147437000 R13: ffff88806a734aa0 R14: 0000000000000000 R15: 0000000000000002 FS: 00007f009bbc7700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055555641b108 CR3: 000000001901b000 CR4: 00000000003506e0 DR0: 0000000020000100 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: <TASK> get_sg_table+0xfc/0x150 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0xf5/0x160 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xd8/0x170 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x2a0/0x2f0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f009d251fe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f009bbc7168 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f009d364f60 RCX: 00007f009d251fe9 RDX: 0000000020000040 RSI: 0000000040086200 RDI: 000000000000000b RBP: 00007f009d2ac08d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc7751fd4f R14: 00007f009bbc7300 R15: 0000000000022000 </TASK> --- 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.

1 0

[RFC] How to add hardware rotation, scaling etc to a DRM/KMS driver
by Daniel Palmer 20 Jan '22

20 Jan '22

Hi all, I've copied and pasted my way to mostly working DRM/KMS driver for a low cost ARM SoC (Sigmastar SSD202D). The hardware is 2D only. One of the devices that uses this SoC has the screen upside down so it needs the screen rotated. The hardware doesn't have bits that change the scan out direction from what I can tell (so it can't mirror/flip while feeding it to the screen) but it does have a 2D blitter style block that can take a framebuffer and flip/mirror/scale/convert the colour space into another buffer. My idea was to create a buffer for the rotated image when allocating the framebuffer and trigger the hardware to do the conversion each vblank or something. While reading the discussion about maintaining fbdev I realised maybe I should ask instead of wasting too much time on something that's wrong. I got the feeling that maybe I should just provide an interface to the blitter from userspace and userspace should be doing the rotation. I'd like to do it in the kernel so stuff like SDL1 apps just work but maybe that isn't possible? Cheers, Daniel

3 5

[PATCH 1/4] dma-buf: consolidate dma_fence subclass checking
by Christian König 20 Jan '22

20 Jan '22

Consolidate the wrapper functions to check for dma_fence subclasses in the dma_fence header. This makes it easier to document and also check the different requirements for fence containers in the subclasses. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- include/linux/dma-fence-array.h | 15 +------------ include/linux/dma-fence-chain.h | 3 +-- include/linux/dma-fence.h | 38 +++++++++++++++++++++++++++++++++ 3 files changed, 40 insertions(+), 16 deletions(-) diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h index 303dd712220f..fec374f69e12 100644 --- a/include/linux/dma-fence-array.h +++ b/include/linux/dma-fence-array.h @@ -45,19 +45,6 @@ struct dma_fence_array { struct irq_work work; }; -extern const struct dma_fence_ops dma_fence_array_ops; - -/** - * dma_fence_is_array - check if a fence is from the array subsclass - * @fence: fence to test - * - * Return true if it is a dma_fence_array and false otherwise. - */ -static inline bool dma_fence_is_array(struct dma_fence *fence) -{ - return fence->ops == &dma_fence_array_ops; -} - /** * to_dma_fence_array - cast a fence to a dma_fence_array * @fence: fence to cast to a dma_fence_array @@ -68,7 +55,7 @@ static inline bool dma_fence_is_array(struct dma_fence *fence) static inline struct dma_fence_array * to_dma_fence_array(struct dma_fence *fence) { - if (fence->ops != &dma_fence_array_ops) + if (!fence || !dma_fence_is_array(fence)) return NULL; return container_of(fence, struct dma_fence_array, base); diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h index 54fe3443fd2c..ee906b659694 100644 --- a/include/linux/dma-fence-chain.h +++ b/include/linux/dma-fence-chain.h @@ -49,7 +49,6 @@ struct dma_fence_chain { spinlock_t lock; }; -extern const struct dma_fence_ops dma_fence_chain_ops; /** * to_dma_fence_chain - cast a fence to a dma_fence_chain @@ -61,7 +60,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops; static inline struct dma_fence_chain * to_dma_fence_chain(struct dma_fence *fence) { - if (!fence || fence->ops != &dma_fence_chain_ops) + if (!fence || !dma_fence_is_chain(fence)) return NULL; return container_of(fence, struct dma_fence_chain, base); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 1ea691753bd3..775cdc0b4f24 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -587,4 +587,42 @@ struct dma_fence *dma_fence_get_stub(void); struct dma_fence *dma_fence_allocate_private_stub(void); u64 dma_fence_context_alloc(unsigned num); +extern const struct dma_fence_ops dma_fence_array_ops; +extern const struct dma_fence_ops dma_fence_chain_ops; + +/** + * dma_fence_is_array - check if a fence is from the array subclass + * @fence: the fence to test + * + * Return true if it is a dma_fence_array and false otherwise. + */ +static inline bool dma_fence_is_array(struct dma_fence *fence) +{ + return fence->ops == &dma_fence_array_ops; +} + +/** + * dma_fence_is_chain - check if a fence is from the chain subclass + * @fence: the fence to test + * + * Return true if it is a dma_fence_chain and false otherwise. + */ +static inline bool dma_fence_is_chain(struct dma_fence *fence) +{ + return fence->ops == &dma_fence_chain_ops; +} + +/** + * dma_fence_is_container - check if a fence is a container for other fences + * @fence: the fence to test + * + * Return true if this fence is a container for other fences, false otherwise. + * This is important since we can't build up large fence structure or otherwise + * we run into recursion during operation on those fences. + */ +static inline bool dma_fence_is_container(struct dma_fence *fence) +{ + return dma_fence_is_array(fence) || dma_fence_is_chain(fence); +} + #endif /* __LINUX_DMA_FENCE_H */ -- 2.25.1

2 9

[PATCH] dma-buf: dma-heap: Add a size limitation for allocation
by guangming.cao＠mediatek.com 20 Jan '22

20 Jan '22

From: Guangming <Guangming.Cao(a)mediatek.com> Currently, there is no size check for allocation. If the alloc size is larger than DRAM, it will cause OOM issue. Besides, if it runs on a process that won't be killed by OOM flow, it will cause a kernel exception finally, and we couldn't find the correct memory usage by dma-buf dump api such as "dma_buf_debug_show" since the allocation is still on going and the corresponding dmabuf is not exported. However, it sounds not simple enough to adding a count to count how many pages has been allocated before allocating done. So adding a size limitation here to prevent this case. Signed-off-by: Guangming <Guangming.Cao(a)mediatek.com> Signed-off-by: jianjiao zeng <jianjiao.zeng(a)mediatek.com> --- drivers/dma-buf/dma-heap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index 56bf5ad01ad5..8b75998a106c 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data) if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS) return -EINVAL; + if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2) + return -EINVAL; + fd = dma_heap_buffer_alloc(heap, heap_allocation->len, heap_allocation->fd_flags, heap_allocation->heap_flags); -- 2.17.1

6 23

[PULL] drm-intel-next-fixes
by Tvrtko Ursulin 20 Jan '22

20 Jan '22

Hi Dave and Daniel, A couple display fixes for the merge window. One for EHL and one for ADL-P, and both in the are of voltage swing programming. Regards, Tvrtko --- drm-intel-next-fixes-2022-01-20: - Latest updates for the EHL display voltage swing table (José Roberto de Souza) - Additional step is required when programming the ADL-P display TC voltage swing (José Roberto de Souza) The following changes since commit 6ef295e34297433c78ea02dfcf1c649a769050bb: drm/i915/ttm: ensure we unmap when purging (2022-01-10 14:00:47 +0000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-01-20 for you to fetch changes up to e26602be4869c74dd8a0f66f718b8a0ce120edb4: drm/i915/display/adlp: Implement new step in the TC voltage swing prog sequence (2022-01-17 10:19:41 +0000) ---------------------------------------------------------------- - Latest updates for the EHL display voltage swing table (José Roberto de Souza) - Additional step is required when programming the ADL-P display TC voltage swing (José Roberto de Souza) ---------------------------------------------------------------- José Roberto de Souza (2): drm/i915/display/ehl: Update voltage swing table drm/i915/display/adlp: Implement new step in the TC voltage swing prog sequence drivers/gpu/drm/i915/display/intel_ddi.c | 22 ++++++++++++++++++++++ drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 10 +++++----- drivers/gpu/drm/i915/i915_reg.h | 8 ++++++-- 3 files changed, 33 insertions(+), 7 deletions(-)

1 0

[PATCH] drm/i915: Fix vma resource freeing
by Thomas Hellström 20 Jan '22

20 Jan '22

In some cases we use leftover kfree() instead of i915_vma_resource_free(). Fix this. Fixes: Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding") Reported-by: Robert Beckett <bob.beckett(a)collabora.com> Cc: Matthew Auld <matthew.auld(a)intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/i915_vma.c | 4 ++-- drivers/gpu/drm/i915/i915_vma_resource.c | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index b959e904c4d3..b1816a835abf 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -464,7 +464,7 @@ int i915_vma_bind(struct i915_vma *vma, if (vma->resource || !vma_res) { /* Rebinding with an additional I915_VMA_*_BIND */ GEM_WARN_ON(!vma_flags); - kfree(vma_res); + i915_vma_resource_free(vma_res); } else { i915_vma_resource_init_from_vma(vma_res, vma); vma->resource = vma_res; @@ -1462,7 +1462,7 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, err_unlock: mutex_unlock(&vma->vm->mutex); err_vma_res: - kfree(vma_res); + i915_vma_resource_free(vma_res); err_fence: if (work) dma_fence_work_commit_imm(&work->base); diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c b/drivers/gpu/drm/i915/i915_vma_resource.c index 1f41c0c699eb..6426c2f8a3b4 100644 --- a/drivers/gpu/drm/i915/i915_vma_resource.c +++ b/drivers/gpu/drm/i915/i915_vma_resource.c @@ -62,7 +62,8 @@ struct i915_vma_resource *i915_vma_resource_alloc(void) */ void i915_vma_resource_free(struct i915_vma_resource *vma_res) { - kmem_cache_free(slab_vma_resources, vma_res); + if (vma_res) + kmem_cache_free(slab_vma_resources, vma_res); } static const char *get_driver_name(struct dma_fence *fence) -- 2.31.1

2 1

← Newer
1
...
40
41
42
43
44
45
46
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2022