Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
3680 discussions

Re: [PATCH 1/4] media: videobuf2: finish prepared buffers in VIDIOC_REMOVE_BUFS

by Tomasz Figa

Hi Karl, On Mon, Oct 19, 2026 at 4:14 PM Karl Mehltretter <kmehltretter(a)gmail.com> wrote: > > VIDIOC_PREPARE_BUF leaves a buffer DEQUEUED after calling buf_prepare() > and the prepare() memory operation. VIDIOC_REMOVE_BUFS accepts that state > but frees the buffer without calling the matching finish operations. > > With VIDEO_ADV_DEBUG, vivid reports: > > unbalanced counters for queue 000000009fa716f8, buffer 0: > buf_prepare: 1 buf_finish: 0 > prepare: 1 finish: 0 > > Finish prepared buffers before freeing them, as queue cancellation does. > > Fixes: a3293a85381e ("media: v4l2: Add REMOVE_BUFS ioctl") > Assisted-by: LLM > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> > --- > drivers/media/common/videobuf2/videobuf2-core.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) Thanks for the patch. Please take a look at my comments inline. > > diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c > index b0a6084f17573..460eaf4e82f78 100644 > --- a/drivers/media/common/videobuf2/videobuf2-core.c > +++ b/drivers/media/common/videobuf2/videobuf2-core.c > @@ -1746,6 +1746,19 @@ int vb2_core_remove_bufs(struct vb2_queue *q, unsigned int start, unsigned int c > goto unlock; > } > } > + > + /* A buffer can be prepared without being queued. Finish it first. */ > + for (i = start; i < start + count; i++) { > + struct vb2_buffer *vb = vb2_get_buffer(q, i); > + > + if (!vb->prepared) > + continue; > + > + __vb2_buf_mem_finish(vb); > + call_void_vb_qop(vb, buf_finish, vb); > + vb->prepared = 0; > + } > + __vb2_queue_cancel() does much more than that, especially all the media request handling. In addition, this open coded handling just causes code duplication. Would it make more sense to refactor the relevant part of the buffer cancelation loop from __vb2_queue_cancel() into a helper function and call it here instead? Best, Tomasz > __vb2_queue_free(q, start, count); > dprintk(q, 2, "%u buffers removed\n", count); > > -- > 2.47.3 >

1 week, 3 days

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

by Christian König

On 10/21/26 11:08, Val Packett wrote: > Introduce a new ioctl that allows userspace to register an eventfd to get > notified when a dma-buf is released. > > The current use case comes from virtio-gpu device backends wishing to add > support for guest-owned buffers with host handles (CREATE_GUEST_HANDLE): > > * guest creates a guest-only blob resource on the virtgpu > * host creates a udmabuf from the iovecs sent by the guest > * guest attaches the resource to a cross-domain socket send operation > * guest immediately releases the resource (no longer needed by the guest) > * host sends the udmabuf to the compositor, but needs to delay responding > to the resource release request until the resource is *actually* free > on the host side, i.e. the compositor no longer uses it Interesting use case you have here. It doesn't sound to crazy, e.g. it can't deadlock the kernel or anything like that which we often see with dma-fence. > Signed-off-by: Val Packett <val(a)invisiblethingslab.com> > --- > > More background on the use case with extra links: > https://lore.kernel.org/virtio-comment/20260903021442.423274-1-val@invisibl… > > Funnily enough, gntdev-dmabuf (which is used on Xen hosts instead of > udmabuf for this) offers "a way" to "poll" for these release events > on its dmabufs (IOCTL_GNTDEV_DMABUF_EXP_WAIT_RELEASED), but it's unusable: > > * it's a blocking wait!! > * release does not happen while you still have the fd open, so: > * you can't just timeout and restart, you'd need the fd to restart; > * and the only way to even close the fd is from a different thread, > after some arbitrary timeout when hopefully the wait has started. Oh that made my day :D > The buffer lifecycle coordination we need this for applies to KVM as well > and it generally doesn't make sense to have this as a provider-specific > thing since it's not related to the provider in any way, it's just > something we want from dmabufs in general. I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble. The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released. If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation. Regards, Christian. > > Thanks, > ~val > > --- > drivers/dma-buf/dma-buf.c | 24 ++++++++++++++++++++++++ > include/linux/dma-buf.h | 3 +++ > include/uapi/linux/dma-buf.h | 1 + > 3 files changed, 28 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 36cdc342627e..1321fee73656 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -17,6 +17,7 @@ > #include <linux/dma-fence.h> > #include <linux/dma-fence-unwrap.h> > #include <linux/anon_inodes.h> > +#include <linux/eventfd.h> > #include <linux/export.h> > #include <linux/debugfs.h> > #include <linux/list.h> > @@ -185,6 +186,11 @@ static void dma_buf_release(struct dentry *dentry) > if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) > dma_resv_fini(dmabuf->resv); > > + if (dmabuf->release_eventfd) { > + eventfd_signal(dmabuf->release_eventfd); > + eventfd_ctx_put(dmabuf->release_eventfd); > + } > + > WARN_ON(!list_empty(&dmabuf->attachments)); > module_put(dmabuf->owner); > kfree(dmabuf->name); > @@ -537,6 +543,21 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf, > } > #endif > > +static long dma_buf_set_release_eventfd(struct dma_buf *dmabuf, > + u32 fd) > +{ > + struct eventfd_ctx *ev_fd_ctx = eventfd_ctx_fdget(fd); > + > + if (IS_ERR(ev_fd_ctx)) > + return PTR_ERR(ev_fd_ctx); > + > + if (dmabuf->release_eventfd) > + eventfd_ctx_put(dmabuf->release_eventfd); > + > + dmabuf->release_eventfd = ev_fd_ctx; > + return 0; > +} > + > static long dma_buf_ioctl(struct file *file, > unsigned int cmd, unsigned long arg) > { > @@ -587,6 +608,9 @@ static long dma_buf_ioctl(struct file *file, > return dma_buf_import_sync_file(dmabuf, (const void __user *)arg); > #endif > > + case DMA_BUF_IOCTL_SET_RELEASE_EVENTFD: > + return dma_buf_set_release_eventfd(dmabuf, (u32)arg); > + > default: > return -ENOTTY; > } > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index d15b2b31d3c9..07b4a589a793 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -429,6 +429,9 @@ struct dma_buf { > > __poll_t active; > } cb_in, cb_out; > + > + /** @release_eventfd: for userspace release notification */ > + struct eventfd_ctx *release_eventfd; > }; > > /** > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h > index e827c9d20c5d..566dea778ad0 100644 > --- a/include/uapi/linux/dma-buf.h > +++ b/include/uapi/linux/dma-buf.h > @@ -179,5 +179,6 @@ struct dma_buf_import_sync_file { > #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64) > #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file) > #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file) > +#define DMA_BUF_IOCTL_SET_RELEASE_EVENTFD _IOW(DMA_BUF_BASE, 4, __u32) > > #endif

1 week, 3 days

Re: [PATCH 09/13] drm/msm/dcp: Register DCP display pipeline

by Krzysztof Kozlowski

On 15/10/2026 09:38, Jayant Shekhar wrote: > The DCP firmware exposes display resources through capabilities rather than > through host-visible display registers. The MSM DRM backend therefore needs > to build its KMS objects from the firmware capabilities and device-tree > display graph. > > Complete DCP KMS registration, including power and IOMMU integration, > capability handling, display-graph parsing, and creation of DRM planes, > CRTCs, encoders, bridges, and connectors. > > Signed-off-by: Jayant Shekhar <jayant.shekhar(a)oss.qualcomm.com> > Assisted-by: LLM Your tag is the last one. Best regards, Krzysztof

1 week, 3 days

Re: [PATCH 09/13] drm/msm/dcp: Register DCP display pipeline

by Krzysztof Kozlowski

On 15/10/2026 09:38, Jayant Shekhar wrote: > The DCP firmware exposes display resources through capabilities rather than > through host-visible display registers. The MSM DRM backend therefore needs > to build its KMS objects from the firmware capabilities and device-tree > display graph. ... > + > + remote_np = of_graph_get_remote_port_parent(ep_np); > + of_node_put(ep_np); > + if (!remote_np) > + continue; > + > + if (!of_device_is_available(remote_np)) { > + of_node_put(remote_np); > + continue; > + } > + > + if (of_node_name_prefix(remote_np, "dsi")) { Where did you document the ABI? > + if (dsi_idx >= ARRAY_SIZE(dpu_kms->dsi_bridge)) { > + dev_err(dev->dev, "too many DSI outputs\n"); > + ret = -E2BIG; > + goto out; > + } Best regards, Krzysztof

1 week, 3 days

Re: [RFC PATCH 0/6] iommufd: harden DMA-BUF PAL setup and release

by Jason Gunthorpe

On Tue, Oct 20, 2026 at 10:16:26PM +1100, Alistair Popple wrote: > I haven't had a chance to look at these patches yet, but if some of them are > fixing bugs in Jason's series it might be best for us to fold them into that > series, with correct attribution of course. Anyway I will take a closer look in > the morning. Are any fixing bugs in tree right now? I think one of them is already applied from someone else.. Jason

1 week, 3 days

Re: [PATCH RFC 03/26] dma-buf: Add dma_buf_mapping_attach()

by Christian König

On 10/16/26 22:26, Karl Mehltretter wrote: > On Tue, Feb 17, 2026 at 08:11:34PM -0400, Jason Gunthorpe wrote: >> + match_args.attach = attach; >> + if (dmabuf->ops->match_mapping) { >> + ret = dmabuf->ops->match_mapping(&match_args); >> + } >> + >> attach->dmabuf = dmabuf; >> attach->importer_ops = importer_ops; >> attach->importer_priv = importer_priv; > > I may misunderstand the intended contract. match_mapping() runs while the > attachment is still zeroed and without dmabuf->resv held. > > Patch 11's amdgpu callback needs importer_ops and importer_priv, so its XGMI > match cannot work here. Patch 12's VFIO callback asserts dmabuf->resv and > reads priv->vdev, which cleanup changes under that lock. > > Should the core initialize the attachment and hold dmabuf->resv for > match_mapping(), or should callbacks avoid attachment and lock-protected > state? Right. This completely misplaced. The matching can't be done at attachment time, but rather needs to be done before creating a mapping while holding the resv lock so that the matching decision can't change. Regards, Christian. > > Thanks, > Karl

1 week, 4 days

Re: [PATCH] dma-buf: Fix IOVA offset when linking phys vecs to sgt

by Christian König

On 10/20/26 11:19, Yili Zhang wrote: > Hi Sumit, Christian, > > Gentle ping on this patch. > > It has two Reviewed-by tags from Dawid and Leon, but I don't see the fix in > v7.3. Since the 7.4 merge window is now open, could it be queued for v7.4? > > I'm happy to resend with the collected Reviewed-by tags if that helps. I've just pushed it to drm-misc-fixes. Sorry I'm way to busy at the moment. Regards, Christian. > > Thanks, > Yili

1 week, 4 days

Re: [PATCH v3 1/2] drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind

by Christian König

On 10/20/26 09:14, Philipp Stanner wrote: > On Tue, 2026-07-21 at 09:21 +0100, André Draszik wrote: >> > > […] > >> >> >> --- >> v3: >> - Philipp: update kerneldoc, add Fixes: >> >> v2: new patch >> --- >> drivers/gpu/drm/drm_crtc.c | 15 ++++++++++++--- >> 1 file changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c >> index 63ead8ba6756..e8e80c936852 100644 >> --- a/drivers/gpu/drm/drm_crtc.c >> +++ b/drivers/gpu/drm/drm_crtc.c >> @@ -493,14 +493,23 @@ EXPORT_SYMBOL(__drmm_crtc_alloc_with_planes); >> * drm_crtc_cleanup - Clean up the core crtc usage >> * @crtc: CRTC to cleanup >> * >> - * This function cleans up @crtc and removes it from the DRM mode setting >> - * core. Note that the function does *not* free the crtc structure itself, >> - * this is the responsibility of the caller. >> + * This function cleans up @crtc and removes it from the DRM mode setting core, >> + * after first waiting an RCU grace period to ensure @crtc->dev can safely be >> + * dereferenced by our dma_fence_ops. >> + * >> + * Note that the function does *not* free the crtc structure itself, this is the >> + * responsibility of the caller. >> */ >> void drm_crtc_cleanup(struct drm_crtc *crtc) >> { >> struct drm_device *dev = crtc->dev; >> >> + /* Ensure our dma_fence_ops remain valid for an RCU grace period after >> + * the fence is signaled. This is necessary because our dma_fence_ops >> + * dereference crtc->dev. >> + */ >> + synchronize_rcu(); >> + >> /* Note that the crtc_list is considered to be static; should we >> * remove the drm_crtc at runtime we would have to decrement all >> * the indices on the drm_crtc after us in the crtc_list. > > > Seems we forgot [1] this patch. Sorry about that. > > This fix also looks fine to me (for now) since it's what the dma_fence > contract currently demands. > > I'm a bit nervous about a synchronize_rcu() being in every cleanup > path, but I suspect it's the most reasonable thing to do now. > > Let's wait a day or two to see if anyone has fundamental objections. > Could someone with some CRTC knowledge give it an R-b? Otherwise I'd > push it this week. I just picked them up and I'm about to push them to drm-misc-fixes. Regards, Christian. > > > Regards, > Philipp > > > [1] https://lore.kernel.org/dri-devel/73fc12734386c9bebc9cf6d3cea4c5f8e125255e.…

1 week, 4 days

[PATCH v11 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the Requester chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, and treat a client with ATS enabled as translating unless its driver declares per-mapping ATS. This completes the P2PDMA side; dma-buf and mlx5 follow separately. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v11: - Applied the client ATS policy in pci_p2pdma_distance_many() too, as local Sashiko pointed out. - Read the ATS Enable bit once per query, so the class and the ATS policy always agree. - Documented that pcim_p2pdma_set_ats_per_mapping() needs a successful pcim_p2pdma_init(). - The path diagnostics no longer read ACS Control or the bridge bus range, and they report a failed cache store. - Added a KUnit case for Direct Translated P2P without a redirect. - Clarified the Relaxed Ordering and diagnostics commit messages. - Honored device-specific ACS redirection, such as Zhaoxin Downstream Ports, in a new first patch with a KUnit case, as local Sashiko pointed out. Relaxed Ordering Completions are redirected at such a port too. - Clarified in the documentation that a quirk also redirects Relaxed Ordering Completions and that Translation Blocking applies only to upstream Requests, and labelled the ACS routing debug line with its class, as local Sashiko pointed out. - Treated ACS registers that read as all ones as unreadable, and named ports that a quirk redirects instead of suggesting pci=disable_acs_redir= for them, as local Sashiko pointed out. - Ignored ACS quirks of endpoints, which only describe traffic between their own functions. - Link to v10: https://patch.msgid.link/20261012-fix-p2p-acs-v4-0-v10-0-6ffe7b7a4517@nvidi… Changes in v10: - Fixed the Relaxed Ordering description: a Completion carries the attribute of its Request (PCIe r7.0 sec 2.2.9.1). - Used the PCIe terms Requester and Completer for TLPs, ACS and ports; client and provider remain for P2PDMA objects. - Rebased on pci/p2pdma, which includes the prerequisite P2PDMA fixes. - Added a topology example to the path divergence patch. - Removed a repeated sentence from the disable_acs_redir documentation. - Explained the path divergence in the documentation. - Link to v9: https://patch.msgid.link/20261001-fix-p2p-acs-v4-0-v9-0-1a8e0f50ddd9@nvidia… Changes in v9: - Removed dmabuf patches for now. - Removed mlx5 per-mapping ATS declaration for now; it comes back with the dmabuf patches. - Link to v8: https://patch.msgid.link/20260928-fix-p2p-acs-v4-0-v8-0-404453b9c435@nvidia… Changes in v8: - Added extra Reviewed-by from Logan. - Added patches to take care of ATS per-device vs. per-mapping option - Link to v7: https://patch.msgid.link/20260920-fix-p2p-acs-v4-0-v7-0-ca0828ab697c@nvidia… Changes in v7: - Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing after p2pmem fix. - Split dmabuf patch. - Tushar retested the series, so added his Tested-by. - Added Logan's ROB tags and fixed minor documentation issues pointed by him. - Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi… Changes in v6: - Changed DMABUF to use callbacks and not directly stored pointer. - Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia… Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (19): PCI/P2PDMA: Honor device-specific ACS redirection PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing PCI/P2PDMA: Let a client declare that it selects ATS per mapping PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled PCI/P2PDMA: Test the routing of clients with ATS enabled Documentation/admin-guide/kernel-parameters.txt | 11 +- Documentation/driver-api/pci/p2pdma.rst | 105 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 942 +++++++++++++++-- drivers/pci/pci.c | 8 +- drivers/pci/pci.h | 57 ++ drivers/pci/pci_acs_test.c | 1225 +++++++++++++++++++++++ drivers/pci/quirks.c | 8 +- include/linux/pci-p2pdma.h | 12 +- 10 files changed, 2292 insertions(+), 92 deletions(-) --- base-commit: 36038f0e8377ef316b723d0d85b1510bc64069ab change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 week, 4 days

Re: [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs

by Laurent Pinchart

On Mon, Oct 19, 2026 at 09:14:07AM +0200, Karl Mehltretter wrote: > UVC and vivid access imported DMA-BUFs with the CPU without cache > synchronization. On a Pi 400, captured data remained in the CPU cache > while physical RAM was stale. > > Add an opt-in queue flag to bracket CPU access from buf_prepare() through > buf_finish(). The allocator cannot imply CPU use because some vb2-vmalloc > drivers pass buffers to hardware. Patch 1 balances finish operations in > VIDIOC_REMOVE_BUFS so removing prepared buffers closes this interval. This seems completely wrong. > This follows the per-queue flag proposed here: > https://lists.openwall.net/linux-kernel/2024/06/20/236 > > Based on Linux 7.3. Tests cover the same code on these earlier bases: > > - Pi 400, 7.3-rc4, all four patches: eight 640x480 YUYV frames per run, > imported CMA DMA-BUFs with a DRM device mapping: > > Path Runs Stale frames > UVC, vb2-vmalloc 12 0/96 > vivid, vb2-vmalloc 12 0/96 > vivid, vb2-dma-contig 12 0/96 > > All six lifecycle cases passed with both vivid allocators. Read-only > output USERPTR passed. The test added no warnings or failed CPU-access > callbacks. A control without the DRM mapping found 4/16 stale frames. > > - SAM9X75 (ARMv5), 6.18 backport of all four patches: the baseline > PREPARE_BUF/REMOVE_BUFS imbalance was fixed. USERPTR and six lifecycle > cases passed. All 128 vivid and 96 UVC frames matched RAM, with 100/100 > begin/end calls. The baseline was already coherent. > > - BeagleV Ahead (RISC-V), 7.3-rc7, patches 1, 2 and 4: read-only USERPTR, > six traced lifecycle cases and 60 repeats passed with balanced callbacks > and no kernel diagnostics. A vendor 5.10 backport of patches 2 and 3 > captured 96 UVC frames without stale data, with 100/100 begin/end calls. > Its baseline was already coherent. > > Karl Mehltretter (4): > media: videobuf2: finish prepared buffers in VIDIOC_REMOVE_BUFS > media: videobuf2: add opt-in DMA-BUF CPU access > media: uvcvideo: synchronize imported DMA-BUFs for CPU access > media: vivid: synchronize imported DMA-BUFs for CPU access > > .../media/common/videobuf2/videobuf2-core.c | 96 ++++++++++++++++++- > .../common/videobuf2/videobuf2-dma-contig.c | 5 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 5 +- > .../common/videobuf2/videobuf2-vmalloc.c | 5 +- > drivers/media/test-drivers/vivid/vivid-core.c | 1 + > drivers/media/usb/uvc/uvc_queue.c | 1 + > include/media/videobuf2-core.h | 12 ++- > 7 files changed, 116 insertions(+), 9 deletions(-) > > > base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222 -- Regards, Laurent Pinchart

1 week, 5 days

← Newer
1
2
3
4
5
6
7
...
368
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig