- 12 Jun, 2022 20 commits
-
-
Igor Torrente authored
Currently, the memory to the composition frame is being allocated using the kzmalloc. This comes with the limitation of maximum size of one page size(which in the x86_64 is 4Kb and 4MB for default and hugepage respectively). Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when testing some pixel formats like ARGB16161616 and the following error were showing up when running kms_plane@plane-panning-bottom-right*: [drm:vkms_composer_worker [vkms]] *ERROR* Cannot allocate memory for output frame. This problem is addessed by allocating the memory using kvzalloc that circunvents this limitation. V5: Improve the commit message and drop the debugging issues in VKMS TO-DO(Melissa Wen). Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Igor Torrente <igormtorrente@gmail.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220404204515.42144-2-igormtorrente@gmail.com
-
Tales Lelo da Aparecida authored
Fix a copypasta error. The caller of compose_plane() already checks primary_composer->map. In contrast, plane_composer->map is never verified here before handling. Fixes: 7938f421 ("dma-buf-map: Rename to iosys-map") Reviewed-by:
André Almeida <andrealmeid@riseup.net> Signed-off-by:
Tales Lelo da Aparecida <tales.aparecida@gmail.com> Signed-off-by:
-
Peter Robinson authored
Add compatible string and Kconfig options and help for bcm2711. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Peter Robinson authored
Runtime PM doesn't seem to work correctly on this driver. On top of that, commit 8b6864e3 ("drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'") hints that it most likely never did as the driver's PM ops were not hooked-up. So, in order to support regular operation with V3D on BCM2711 (Raspberry Pi 4), get rid of the PM code. PM will be reinstated once we figure out the underlying issues. Signed-off-by:
-
Peter Robinson authored
BCM2711, Raspberry Pi 4's SoC, contains a V3D core. So add its specific compatible to the bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marek Vasut authored
The rcar_mipi_dsi_parse_dt() now contains two uninitialized variables due to conversion to common drm_of_get_data_lanes_count_ep() helper. Drop them. Fixes: d643daaf ("drm/bridge: rcar: Convert to drm_of_get_data_lanes_count_ep") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> To: dri-devel@lists.freedesktop.org Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220612132152.91052-3-marex@denx.de
-
Marek Vasut authored
Initialize dsi_lanes to -1, so that in case the endpoint is missing, probe would fail as it did before the conversion, instead of depending on uninitialized variable and thus undefined behavior. Fixes: 56426faa ("drm/bridge: tc358775: Convert to drm_of_get_data_lanes_count_ep") Reported-by:
-
Marek Vasut authored
Mark empty implementations of drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep as static inline, just like the rest of empty implementations of various functions in drm_of.h . Add missing comma to drm_of_get_data_lanes_count_ep() . Fixes: fc801750 ("drm: of: Add drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep") Reported-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
Marek Vasut authored
The DSI lane count can be accessed via the dsi device pointer, make use of that. The DSI host pointer is only used in sn65dsi83_host_attach(), move the code around so that the host does not have to be cached in the driver private data. This simplifies the code further. No functional change. This has the added bonus that lt9211, tc358767, sn65dsi83 now use very similar *_mipi_dsi_host_attach() which is ripe for deduplication. Signed-off-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220524010522.528569-10-marex@denx.de
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Add helper function to count and sanitize DT "data-lanes" property and return either error or the data-lanes count. This is useful for both DSI and (e)DP "data-lanes" property. The later version of the function is an extra wrapper which handles the endpoint look up by regs, that's what majority of the drivers duplicate too, but not all of them. Reviewed-by:
-
- 11 Jun, 2022 1 commit
-
-
Douglas Anderson authored
Two blank lines are needed to make the rst valid. Fixes: 69ef4a19 ("drm: Document the power requirements for DP AUX transfers") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
-
- 10 Jun, 2022 1 commit
-
-
Antonio Borneo authored
Commit 680532c5 ("drm: adv7511: Add support for i2c_new_secondary_device") allows a device tree node to override the default addresses of the secondary i2c devices. This is useful for solving address conflicts on the i2c bus. In adv7511_init_cec_regmap() the new i2c address of cec device is read from device tree and immediately accessed, well before it is written in the proper register to override the default address. This can cause an i2c error during probe and a consequent probe failure. Once the new i2c address is read from the device tree, override the default address before any attempt to access the cec. Tested with adv7533 and stm32mp157f. Signed-off-by:
Antonio Borneo <antonio.borneo@foss.st.com> Fixes: 680532c5 ("drm: adv7511: Add support for i2c_new_secondary_device") Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220607213144.427177-1-antonio.borneo@foss.st.com
-
- 09 Jun, 2022 12 commits
-
-
Paul Kocialkowski authored
Introduces a driver for the LogiCVC display controller, a programmable logic controller optimized for use in Xilinx Zynq-7000 SoCs and other Xilinx FPGAs. The controller is mostly configured at logic synthesis time so only a subset of configuration is left for the driver to handle. The following features are implemented and tested: - LVDS 4-bit interface; - RGB565 pixel formats; - Multiple layers and hardware composition; - Layer-wide alpha mode; The following features are implemented but untested: - Other RGB pixel formats; - Layer framebuffer configuration for version 4; - Lowest-layer used as background color; - Per-pixel alpha mode. The following features are not implemented: - YUV pixel formats; - DVI, LVDS 3-bit, ITU656 and camera link interfaces; - External parallel input for layer; - Color-keying; - LUT-based alpha modes. Additional implementation-specific notes: - Panels are only enabled after the first page flip to avoid flashing a white screen. - Depth used in context of the LogiCVC driver only counts color components to match the definition of the synthesis parameters. Support is implemented for both version 3 and 4 of the controller. With version 3, framebuffers are stored in a dedicated contiguous memory area, with a base address hardcoded for each layer. This requires using a dedicated CMA pool registered at the base address and tweaking a few offset-related registers to try to use any buffer allocated from the pool. This is done on a best-effort basis to have the hardware cope with the DRM framebuffer allocation model and there is no guarantee that each buffer allocated by GEM CMA can be used for any layer. In particular, buffers allocated below the base address for a layer are guaranteed not to be configurable for that layer. See the implementation of logicvc_layer_buffer_find_setup for specifics. Version 4 allows configuring each buffer address directly, which guarantees that any buffer can be configured. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220520141555.1429041-2-paul.kocialkowski@bootlin.com
-
Daniel Vetter authored
This reverts commit fb561bf9. With commit 27599aac Author: Thomas Zimmermann <tzimmermann@suse.de> Date: Tue Jan 25 10:12:18 2022 +0100 fbdev: Hot-unplug firmware fb devices on forced removal this should be fixed properly and we can remove this somewhat hackish check here (e.g. this won't catch drm drivers if fbdev emulation isn't enabled). Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zackr@vmware.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Zack Rusin <zackr@vmware.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ilya Trukhanov <lahvuun@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Javier Martinez Canillas authored
The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. Suggested-by:
-
Javier Martinez Canillas authored
This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by:
-
Javier Martinez Canillas authored
This function just returned 0 on success or an errno code on error, but it could be useful for sysfb_init() callers to have a pointer to the device. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-2-javierm@redhat.com
-
Thomas Zimmermann authored
After moving the vmalloc() call to another file, the rsp include statement needs to be moved as well. Resolves a build warning on parisc. drivers/gpu/drm/mgag200/mgag200_g200.c: In function 'mgag200_g200_init_refclk': drivers/gpu/drm/mgag200/mgag200_g200.c:120:16: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration] Signed-off-by:
-
Miaoqian Lin authored
Since drm_prime_pages_to_sg() function return error pointers. The drm_gem_shmem_get_sg_table() function returns error pointers too. Using IS_ERR() to check the return value to fix this. Fixes: 2f2aa137 ("drm/virtio: move virtio_gpu_mem_entry initialization to new function") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220602104223.54527-1-linmq006@gmail.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Vivek Kasireddy authored
If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e515 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 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 fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasireddy@intel.comSigned-off-by:
-
Minghao Chi authored
Simplify the return expression. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Link: http://patchwork.freedesktop.org/patch/msgid/20220429054911.3851977-1-chi.minghao@zte.com.cnSigned-off-by:
-
Tom Rix authored
Smatch reports this issue qxl_kms.c:36:5: warning: symbol 'qxl_log_level' was not declared. Should it be static? qxl_log_level is defined qxl_kms.c but unused, so remove. Signed-off-by:
Tom Rix <trix@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220421142054.3751507-1-trix@redhat.comSigned-off-by:
-
Michel Dänzer authored
Instead of relying on it getting pulled in indirectly. Signed-off-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
-
Xiaomeng Tong authored
'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. Fixes: 62fb7a5e ("virtio-gpu: add 3d/virgl support") Signed-off-by:
Xiaomeng Tong <xiam0nd.tong@gmail.com> Reviewed-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220327050945.1614-1-xiam0nd.tong@gmail.com [ kraxel: minor codestyle fixup ] Signed-off-by:
-
- 08 Jun, 2022 6 commits
-
-
Christophe Leroy authored
While working at fixing powerpc headers, I ended up with the following error. drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error: conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const char *)' make[5]: *** [scripts/Makefile.build:288: drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o] Error 1 powerpc and a few other architectures have a prom_init() global function. One day or another it will conflict with the one in shadowrom.c Those being static, they can easily be renamed. Do it. While at it, also rename the ops structure as 'nvbios_prom' instead of 'nvbios_rom' in order to make it clear that it refers to the NV_PROM device. Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Joel Selvaraj authored
Add backlight property and update example to include it. Signed-off-by:
Joel Selvaraj <jo@jsfamily.in> Acked-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/BY5PR02MB70090BB5D8C7D655BEE0642FD9E09@BY5PR02MB7009.namprd02.prod.outlook.com
-
Joel Selvaraj authored
Add support for backlight. This panel supports backlight control through the QCOM WLED driver in Xiaomi Poco F1 device. Signed-off-by:
-
Geert Uytterhoeven authored
initmem_freed was removed in v2.1.124, and the underlying issue was fixed for good in commit 92b004d1 ("video/logo: prevent use of logos after they have been freed"). Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Daniel Thompson authored
Since it's inception in 2012 it has been understood that the DRM GEM CMA helpers do not depend on CMA as the backend allocator. In fact the first bug fix to ensure the cma-helpers work correctly with an IOMMU backend appeared in 2014. However currently the documentation for drm_gem_cma_create() talks about "a contiguous chunk of memory" without making clear which address space it will be a contiguous part of. Additionally the CMA introduction is actively misleading because it only contemplates the CMA backend. This matters because when the device accesses the bus through an IOMMU (and don't use the CMA backend) then the allocated memory is contiguous only in the IOVA space. This is a significant difference compared to the CMA backend and the behaviour can be a surprise even to someone who does a reasonable level of code browsing (but doesn't find all the relevant function pointers ;-) ). Improve the kernel doc comments accordingly. Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Jason Ekstrand authored
This patch is analogous to the previous sync file export patch in that it allows you to import a sync_file into a dma-buf. Unlike the previous patch, however, this does add genuinely new functionality to dma-buf. Without this, the only way to attach a sync_file to a dma-buf is to submit a batch to your driver of choice which waits on the sync_file and claims to write to the dma-buf. Even if said batch is a no-op, a submit is typically way more overhead than just attaching a fence. A submit may also imply extra synchronization with other work because it happens on a hardware queue. In the Vulkan world, this is useful for dealing with the out-fence from vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we get a set of fences (VkSemaphores) in vkQueuePresent and have to stash those as an exclusive (write) fence on the dma-buf. We handle it in Mesa today with the above mentioned dummy submit trick. This ioctl would allow us to set it directly without the dummy submit. This may also open up possibilities for GPU drivers to move away from implicit sync for their kernel driver uAPI and instead provide sync files and rely on dma-buf import/export for communicating with other implicit sync clients. We make the explicit choice here to only allow setting RW fences which translates to an exclusive fence on the dma_resv. There's no use for read-only fences for communicating with other implicit sync userspace and any such attempts are likely to be racy at best. When we got to insert the RW fence, the actual fence we set as the new exclusive fence is a combination of the sync_file provided by the user and all the other fences on the dma_resv. This ensures that the newly added exclusive fence will never signal before the old one would have and ensures that we don't break any dma_resv contracts. We require userspace to specify RW in the flags for symmetry with the export ioctl and in case we ever want to support read fences in the future. There is one downside here that's worth documenting: If two clients writing to the same dma-buf using this API race with each other, their actions on the dma-buf may happen in parallel or in an undefined order. Both with and without this API, the pattern is the same: Collect all the fences on dma-buf, submit work which depends on said fences, and then set a new exclusive (write) fence on the dma-buf which depends on said work. The difference is that, when it's all handled by the GPU driver's submit ioctl, the three operations happen atomically under the dma_resv lock. If two userspace submits race, one will happen before the other. You aren't guaranteed which but you are guaranteed that they're strictly ordered. If userspace manages the fences itself, then these three operations happen separately and the two render operations may happen genuinely in parallel or get interleaved. However, this is a case of userspace racing with itself. As long as we ensure userspace can't back the kernel into a corner, it should be fine. v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence. v3 (Jason Ekstrand): - Lock around setting shared fences as well as exclusive - Mark SIGNAL_SYNC_FILE as a read-write ioctl. - Initialize ret to 0 in dma_buf_wait_sync_file v4 (Jason Ekstrand): - Use the new dma_resv_get_singleton helper v5 (Jason Ekstrand): - Rename the IOCTLs to import/export rather than wait/signal - Drop the WRITE flag and always get/set the exclusive fence v6 (Jason Ekstrand): - Split import and export into separate patches - New commit message v7 (Daniel Vetter): - Fix the uapi header to use the right struct in the ioctl - Use a separate dma_buf_import_sync_file struct - Add kerneldoc for dma_buf_import_sync_file v8 (Jason Ekstrand): - Rebase on Christian König's fence rework v9 (Daniel Vetter): - Fix -EINVAL checks for the flags parameter - Add documentation about read/write fences - Add documentation about the expected usage of import/export and specifically call out the possible userspace race. v10 (Simon Ser): - Fix a typo in the docs Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:
Jason Ekstrand <jason.ekstrand@intel.com> Signed-off-by:
Jason Ekstrand <jason.ekstrand@collabora.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
-
