- Linaro-mm-sig - lists.linaro.org

Re: [PATCH v2 09/12] dt-bindings: media: st: dcmi: add DMA-MDMA chaining properties

by Rob Herring (Arm)

On Tue, 06 Jan 2026 12:34:37 +0100, Alain Volmat wrote: > Add properties update and new sram property necessary in order > to enable the DMA-MDMA chaining. > > Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> > > --- > Change in v2: > - correct typo (phandles -> phandle) > - remove explanation about generic binding sram.yaml > --- > Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org>

1 month

1
0
0 0

Re: [PATCH v2 4/5] accel/thames: Add IOCTL for job submission

by Randy Dunlap

On 1/14/26 12:46 AM, Tomeu Vizoso wrote: > Using the DRM GPU scheduler infrastructure, with a scheduler for each > core. > > Contexts are created in all cores, and buffers mapped to all of them as > well, so all cores are ready to execute any job. > > The job submission code was initially based on Panfrost. > > v2: > - Add thames_accel.h UAPI header (Robert Nelson). > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > drivers/accel/thames/Makefile | 1 + > drivers/accel/thames/thames_core.c | 6 + > drivers/accel/thames/thames_drv.c | 19 ++ > drivers/accel/thames/thames_job.c | 463 ++++++++++++++++++++++++++++++++++++ > drivers/accel/thames/thames_job.h | 51 ++++ > drivers/accel/thames/thames_rpmsg.c | 52 ++++ > include/uapi/drm/thames_accel.h | 54 +++++ > 7 files changed, 646 insertions(+) > > diff --git a/include/uapi/drm/thames_accel.h b/include/uapi/drm/thames_accel.h > index 0a5a5e5f6637ab474e9effbb6db29c1dd95e56b5..5b35e50826ed95bfcc3709bef33416d2b6d11c70 100644 > --- a/include/uapi/drm/thames_accel.h > +++ b/include/uapi/drm/thames_accel.h > @@ -75,6 +78,55 @@ struct drm_thames_bo_mmap_offset { > __u64 offset; > }; > > +/** > + * struct drm_thames_job - A job to be run on the NPU > + * > + * The kernel will schedule the execution of this job taking into account its > + * dependencies with other jobs. All tasks in the same job will be executed > + * sequentially on the same core, to benefit from memory residency in SRAM. > + */ Please make these comments full-fledged kernel-doc comments. E.g.: > +struct drm_thames_job { > + /** Input: BO handle for kernel. */ /** @kernel: input: BO handle for kernel. */ > + __u32 kernel; > + > + /** Input: Size in bytes of the compiled kernel. */ > + __u32 kernel_size; > + > + /** Input: BO handle for params BO. */ > + __u32 params; > + > + /** Input: Size in bytes of the params BO. */ > + __u32 params_size; > + > + /** Input: Pointer to a u32 array of the BOs that are read by the job. */ > + __u64 in_bo_handles; > + > + /** Input: Pointer to a u32 array of the BOs that are written to by the job. */ > + __u64 out_bo_handles; > + > + /** Input: Number of input BO handles passed in (size is that times 4). */ > + __u32 in_bo_handle_count; > + > + /** Input: Number of output BO handles passed in (size is that times 4). */ > + __u32 out_bo_handle_count; > +}; > + > +/** > + * struct drm_thames_submit - ioctl argument for submitting commands to the NPU. > + * > + * The kernel will schedule the execution of these jobs in dependency order. > + */ Same here. > +struct drm_thames_submit { > + /** Input: Pointer to an array of struct drm_thames_job. */ > + __u64 jobs; > + > + /** Input: Number of jobs passed in. */ > + __u32 job_count; > + > + /** Reserved, must be zero. */ > + __u32 pad; > +}; > + -- ~Randy

1 month

1
0
0 0

Re: [PATCH v2 2/5] accel/thames: Add driver for the C7x DSPs in TI SoCs

by Randy Dunlap

On 1/14/26 12:46 AM, Tomeu Vizoso wrote: > Some SoCs from Texas Instruments contain DSPs that can be used for > general compute tasks. > > This driver provides a drm/accel UABI to userspace for submitting jobs > to the DSP cores and managing the input, output and intermediate memory. > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > Documentation/accel/thames/index.rst | 28 +++++ > MAINTAINERS | 9 ++ > drivers/accel/Kconfig | 1 + > drivers/accel/Makefile | 3 +- > drivers/accel/thames/Kconfig | 26 +++++ > drivers/accel/thames/Makefile | 9 ++ > drivers/accel/thames/thames_core.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_core.h | 53 +++++++++ > drivers/accel/thames/thames_device.c | 93 ++++++++++++++++ > drivers/accel/thames/thames_device.h | 46 ++++++++ > drivers/accel/thames/thames_drv.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_drv.h | 21 ++++ > drivers/accel/thames/thames_ipc.h | 204 +++++++++++++++++++++++++++++++++++ > drivers/accel/thames/thames_rpmsg.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_rpmsg.h | 27 +++++ > 15 files changed, 984 insertions(+), 1 deletion(-) > > diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile > index 1d3a7251b950f39e2ae600a2fc07a3ef7e41831e..8472989cbe22746f1e7292d2401fa0f7424a6c15 100644 > --- a/drivers/accel/Makefile > +++ b/drivers/accel/Makefile > @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/ > obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/ > obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/ > obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/ > -obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > \ No newline at end of file > +obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > +obj-$(CONFIG_DRM_ACCEL_THAMES) += thames/ > \ No newline at end of file Please eliminate these warnings. > diff --git a/drivers/accel/thames/thames_ipc.h b/drivers/accel/thames/thames_ipc.h> new file mode 100644 > index 0000000000000000000000000000000000000000..60297b4bc2ffd990315cb735a96a23429d390f43 > --- /dev/null > +++ b/drivers/accel/thames/thames_ipc.h > @@ -0,0 +1,204 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright 2026 Texas Instruments Incorporated - https://www.ti.com/ > + * > + * This header defines the RPMSG message structures exchanged between > + * the Linux kernel (host) and the C7x DSP (remote) firmware for the > + * Thames DRM/accel driver. > + */ > + > +#ifndef _THAMES_IPC_H > +#define _THAMES_IPC_H > + > +#ifdef __KERNEL__ > +#include <linux/types.h> > +#else > +#include <stdint.h> > +typedef uint8_t __u8; > +typedef uint16_t __u16; > +typedef uint32_t __u32; > +typedef uint64_t __u64; > +#endif > + > +#define THAMES_SERVICE_NAME "thames-service" > + > +/** > + * @THAMES_MSG_TYPE: Simplified message type enumeration > + */ "/**" means "this is kernel-doc format", which should look like: /** * enum thames_msg_type - Simplified message type enumeration */ and then each enum value should be documented as well. > +enum thames_msg_type { > + /* --- Host (Kernel) -> Remote (DSP) --- */ > + THAMES_MSG_PING = 0x100, /* Ping message to test communication */ > + THAMES_MSG_CONTEXT_OP, /* Create/destroy context */ > + THAMES_MSG_BO_OP, /* Map/unmap buffer objects */ > + THAMES_MSG_SUBMIT_JOB, /* Submit job for execution */ > + > + /* --- Remote (DSP) -> Host (Kernel) --- */ > + THAMES_MSG_PING_RESPONSE = 0x200, > + THAMES_MSG_CONTEXT_OP_RESPONSE, > + THAMES_MSG_BO_OP_RESPONSE, > + THAMES_MSG_SUBMIT_JOB_RESPONSE, > +}; > + > +/** > + * @THAMES_CONTEXT_OP: Context operation types * enum thames_context_op - Context operations types > + */ > +enum thames_context_op { > + THAMES_CONTEXT_CREATE = 0, > + THAMES_CONTEXT_DESTROY, > +}; > + > +/** > + * @THAMES_BO_OP: Buffer Object operation types * enum thames_bo_op - Buffer Object operation types > + */ > +enum thames_bo_op { > + THAMES_BO_MAP = 0, > + THAMES_BO_UNMAP, > +}; > + > +/** > + * @THAMES_RESP_STATUS: Response status codes * enum thames_resp_status - Response status codes > + */ > +enum thames_resp_status { > + THAMES_RESP_SUCCESS = 0, > + THAMES_RESP_ERR_GENERIC = 1, > + THAMES_RESP_ERR_NOMEM = 2, > + THAMES_RESP_ERR_INVAL = 3, > + THAMES_RESP_ERR_NO_CTX = 4, > + THAMES_RESP_ERR_MMU = 5, > + THAMES_RESP_ERR_JOB_TIMEOUT = 6, > +}; Or you could just use "/*" so that they aren't considered as kernel-doc. -- ~Randy

1 month

1
0
0 0

Re: [PATCH v2 2/5] accel/thames: Add driver for the C7x DSPs in TI SoCs

by Andrew Davis

On 1/14/26 2:46 AM, Tomeu Vizoso wrote: > Some SoCs from Texas Instruments contain DSPs that can be used for > general compute tasks. > > This driver provides a drm/accel UABI to userspace for submitting jobs > to the DSP cores and managing the input, output and intermediate memory. > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > Documentation/accel/thames/index.rst | 28 +++++ > MAINTAINERS | 9 ++ > drivers/accel/Kconfig | 1 + > drivers/accel/Makefile | 3 +- > drivers/accel/thames/Kconfig | 26 +++++ > drivers/accel/thames/Makefile | 9 ++ > drivers/accel/thames/thames_core.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_core.h | 53 +++++++++ > drivers/accel/thames/thames_device.c | 93 ++++++++++++++++ > drivers/accel/thames/thames_device.h | 46 ++++++++ > drivers/accel/thames/thames_drv.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_drv.h | 21 ++++ > drivers/accel/thames/thames_ipc.h | 204 +++++++++++++++++++++++++++++++++++ > drivers/accel/thames/thames_rpmsg.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_rpmsg.h | 27 +++++ > 15 files changed, 984 insertions(+), 1 deletion(-) > > diff --git a/Documentation/accel/thames/index.rst b/Documentation/accel/thames/index.rst > new file mode 100644 > index 0000000000000000000000000000000000000000..ca8391031f226f7ef1dc210a356c86acbe126c6f > --- /dev/null > +++ b/Documentation/accel/thames/index.rst > @@ -0,0 +1,28 @@ > +.. SPDX-License-Identifier: GPL-2.0-only > + > +============================================================ > + accel/thames Driver for the C7x DSPs from Texas Instruments > +============================================================ > + > +The accel/thames driver supports the C7x DSPs inside some Texas Instruments SoCs > +such as the J722S. These can be used as accelerators for various workloads, > +including machine learning inference. > + > +This driver controls the power state of the hardware via :doc:`remoteproc </staging/remoteproc>` > +and communicates with the firmware running on the DSP via :doc:`rpmsg_virtio </staging/rpmsg_virtio>`. > +The kernel driver itself allocates buffers, manages contexts, and submits jobs > +to the DSP firmware. Buffers are mapped by the DSP itself using its MMU, > +providing memory isolation among different clients. > + > +The source code for the firmware running on the DSP is available at: > +https://gitlab.freedesktop.org/tomeu/thames_firmware/. > + > +Everything else is done in userspace, as a Gallium driver (also called thames) > +that is part of the Mesa3D project: https://docs.mesa3d.org/teflon.html > + > +If there is more than one core that advertises the same rpmsg_virtio service > +name, the driver will load balance jobs between them with drm-gpu-scheduler. > + > +Hardware currently supported: > + > +* J722S > diff --git a/MAINTAINERS b/MAINTAINERS > index dc731d37c8feeff25613c59fe9c929927dadaa7e..a3fc809c797269d0792dfe5202cc1b49f6ff57e9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7731,6 +7731,15 @@ F: Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml > F: drivers/accel/rocket/ > F: include/uapi/drm/rocket_accel.h > > +DRM ACCEL DRIVER FOR TI C7x DSPS > +M: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > +L: dri-devel(a)lists.freedesktop.org > +S: Supported > +T: git https://gitlab.freedesktop.org/drm/misc/kernel.git > +F: Documentation/accel/thames/ > +F: drivers/accel/thames/ > +F: include/uapi/drm/thames_accel.h > + > DRM COMPUTE ACCELERATORS DRIVERS AND FRAMEWORK > M: Oded Gabbay <ogabbay(a)kernel.org> > L: dri-devel(a)lists.freedesktop.org > diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig > index bdf48ccafcf21b2fd685ec963e39e256196e6e17..cb49c71cd4e4a4220624f7041a75ba950a1a2ee1 100644 > --- a/drivers/accel/Kconfig > +++ b/drivers/accel/Kconfig > @@ -30,5 +30,6 @@ source "drivers/accel/habanalabs/Kconfig" > source "drivers/accel/ivpu/Kconfig" > source "drivers/accel/qaic/Kconfig" > source "drivers/accel/rocket/Kconfig" > +source "drivers/accel/thames/Kconfig" > > endif > diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile > index 1d3a7251b950f39e2ae600a2fc07a3ef7e41831e..8472989cbe22746f1e7292d2401fa0f7424a6c15 100644 > --- a/drivers/accel/Makefile > +++ b/drivers/accel/Makefile > @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/ > obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/ > obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/ > obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/ > -obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > \ No newline at end of file > +obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > +obj-$(CONFIG_DRM_ACCEL_THAMES) += thames/ > \ No newline at end of file > diff --git a/drivers/accel/thames/Kconfig b/drivers/accel/thames/Kconfig > new file mode 100644 > index 0000000000000000000000000000000000000000..50e0b6ac2a16a942ba8463333991f5b0161b99ac > --- /dev/null > +++ b/drivers/accel/thames/Kconfig > @@ -0,0 +1,26 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +config DRM_ACCEL_THAMES > + tristate "Thames (support for TI C7x DSP accelerators)" > + depends on DRM_ACCEL > + depends on TI_K3_R5_REMOTEPROC || COMPILE_TEST COMPILE_TEST part shouldn't be needed here, TI_K3_R5_REMOTEPROC can be built under COMPILE_TEST so TI_K3_R5_REMOTEPROC would just be enabled to test. > + depends on RPMSG > + depends on MMU > + select DRM_SCHED > + select DRM_GEM_SHMEM_HELPER > + help > + Choose this option if you have a Texas Instruments SoC that contains > + C7x DSP cores that can be used as compute accelerators. This includes > + SoCs such as the AM62A, J721E, J721S2, and J784S4. > + > + The C7x DSP cores can be used for general-purpose compute acceleration > + and are exposed through the DRM accel subsystem. > + > + The interface exposed to userspace is described in > + include/uapi/drm/thames_accel.h and is used by the Thames userspace > + driver in Mesa3D. > + > + If unsure, say N. > + > + To compile this driver as a module, choose M here: the > + module will be called thames. > diff --git a/drivers/accel/thames/Makefile b/drivers/accel/thames/Makefile > new file mode 100644 > index 0000000000000000000000000000000000000000..7ccd8204f0f5ea800f30e84b319f355be948109d > --- /dev/null > +++ b/drivers/accel/thames/Makefile > @@ -0,0 +1,9 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +obj-$(CONFIG_DRM_ACCEL_THAMES) := thames.o > + > +thames-y := \ > + thames_core.o \ > + thames_device.o \ > + thames_drv.o \ > + thames_rpmsg.o > diff --git a/drivers/accel/thames/thames_core.c b/drivers/accel/thames/thames_core.c > new file mode 100644 > index 0000000000000000000000000000000000000000..92af1d68063116bcfa28a33960cbe829029fc1bf > --- /dev/null > +++ b/drivers/accel/thames/thames_core.c > @@ -0,0 +1,155 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* Copyright 2026 Texas Instruments Incorporated - https://www.ti.com/ */ > + > +#include "linux/remoteproc.h" > +#include <linux/dev_printk.h> > +#include <linux/err.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/platform_device.h> > +#include <linux/completion.h> > +#include <linux/jiffies.h> > +#include <linux/rpmsg.h> > + > +#include "thames_core.h" > +#include "thames_device.h" > +#include "thames_rpmsg.h" > + > +/* Shift to convert bytes to megabytes (divide by 1048576) */ > +#define THAMES_BYTES_TO_MB_SHIFT 20 Seems unused/unneeded. [...] > + > +static const struct rpmsg_device_id thames_rpmsg_id_table[] = { { .name = THAMES_SERVICE_NAME }, > + {} }; > + Some odd formatting here. > +static struct rpmsg_driver thames_rpmsg_driver = { > + .drv = { > + .name = "thames", > + .owner = THIS_MODULE, Above line shoulnd't be needed. Andrew

1 month

1
0
0 0

Re: [PATCH v2 1/5] arm64: dts: ti: k3-j722s-ti-ipc-firmware: Add memory pool for DSP i/o buffers

by Andrew Davis

On 1/14/26 2:46 AM, Tomeu Vizoso wrote: > This memory region is used by the DRM/accel driver to allocate addresses > for buffers that are used for communication with the DSP cores and for > their intermediate results. > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > arch/arm64/boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi > index 3fbff927c4c08bce741555aa2753a394b751144f..b80d2a5a157ad59eaed8e57b22f1f4bce4765a85 100644 > --- a/arch/arm64/boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi > @@ -42,6 +42,11 @@ c7x_0_memory_region: memory@a3100000 { > no-map; > }; > > + c7x_iova_pool: iommu-pool@a7000000 { > + reg = <0x00 0xa7000000 0x00 0x18200000>; > + no-map; Could you expand on why this carveout is needed? The C7 NPU has a full MMU and should be able to work with any buffer Linux allocates from any address, even non-contiguous buffers too. Communication should already happen over the existing RPMSG channels without needing extra buffers. And space for intermediate results should be provided dynamically by the drivers (I believe that would match how GPUs without dedicated memory handle getting intermediate buffers space from system memory these days, but do correct me if I'm wrong about that one). Andrew > + }; > + > c7x_1_dma_memory_region: memory@a4000000 { > compatible = "shared-dma-pool"; > reg = <0x00 0xa4000000 0x00 0x100000>; > @@ -151,13 +156,15 @@ &main_r5fss0_core0 { > &c7x_0 { > mboxes = <&mailbox0_cluster2 &mbox_c7x_0>; > memory-region = <&c7x_0_dma_memory_region>, > - <&c7x_0_memory_region>; > + <&c7x_0_memory_region>, > + <&c7x_iova_pool>; > status = "okay"; > }; > > &c7x_1 { > mboxes = <&mailbox0_cluster3 &mbox_c7x_1>; > memory-region = <&c7x_1_dma_memory_region>, > - <&c7x_1_memory_region>; > + <&c7x_1_memory_region>, > + <&c7x_iova_pool>; > status = "okay"; > }; >

1 month

1
0
0 0

types: reuse common phys_vec type instead of DMABUF open‑coded variant

by Leon Romanovsky

From: Leon Romanovsky <leonro(a)nvidia.com> After commit fcf463b92a08 ("types: move phys_vec definition to common header"), we can use the shared phys_vec type instead of the DMABUF‑specific dma_buf_phys_vec, which duplicated the same structure and semantics. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Alex, According to diffstat, VFIO is the subsystem with the largest set of changes, so it would be great if you could take it through your tree. The series is based on the for-7.0/blk-pvec shared branch from Jens: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-… Thanks --- Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-kernel(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Cc: kvm(a)vger.kernel.org To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> To: Yishai Hadas <yishaih(a)nvidia.com> To: Shameer Kolothum <skolothumtho(a)nvidia.com> To: Ankit Agrawal <ankita(a)nvidia.com> To: Alex Williamson <alex(a)shazbot.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Jens Axboe <axboe(a)kernel.dk> --- drivers/dma-buf/dma-buf-mapping.c | 6 +++--- drivers/iommu/iommufd/io_pagetable.h | 2 +- drivers/iommu/iommufd/iommufd_private.h | 5 ++--- drivers/iommu/iommufd/pages.c | 4 ++-- drivers/iommu/iommufd/selftest.c | 2 +- drivers/vfio/pci/nvgrace-gpu/main.c | 2 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 8 ++++---- include/linux/dma-buf-mapping.h | 2 +- include/linux/dma-buf.h | 10 ---------- include/linux/vfio_pci_core.h | 13 ++++++------- 10 files changed, 21 insertions(+), 33 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index b7352e609fbd..174677faa577 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -33,8 +33,8 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, } static unsigned int calc_sg_nents(struct dma_iova_state *state, - struct dma_buf_phys_vec *phys_vec, - size_t nr_ranges, size_t size) + struct phys_vec *phys_vec, size_t nr_ranges, + size_t size) { unsigned int nents = 0; size_t i; @@ -91,7 +91,7 @@ struct dma_buf_dma { */ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, struct p2pdma_provider *provider, - struct dma_buf_phys_vec *phys_vec, + struct phys_vec *phys_vec, size_t nr_ranges, size_t size, enum dma_data_direction dir) { diff --git a/drivers/iommu/iommufd/io_pagetable.h b/drivers/iommu/iommufd/io_pagetable.h index 14cd052fd320..27e3e311d395 100644 --- a/drivers/iommu/iommufd/io_pagetable.h +++ b/drivers/iommu/iommufd/io_pagetable.h @@ -202,7 +202,7 @@ struct iopt_pages_dmabuf_track { struct iopt_pages_dmabuf { struct dma_buf_attachment *attach; - struct dma_buf_phys_vec phys; + struct phys_vec phys; /* Always PAGE_SIZE aligned */ unsigned long start; struct list_head tracker; diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h index eb6d1a70f673..6ac1965199e9 100644 --- a/drivers/iommu/iommufd/iommufd_private.h +++ b/drivers/iommu/iommufd/iommufd_private.h @@ -20,7 +20,6 @@ struct iommu_group; struct iommu_option; struct iommufd_device; struct dma_buf_attachment; -struct dma_buf_phys_vec; struct iommufd_sw_msi_map { struct list_head sw_msi_item; @@ -718,7 +717,7 @@ int __init iommufd_test_init(void); void iommufd_test_exit(void); bool iommufd_selftest_is_mock_dev(struct device *dev); int iommufd_test_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, - struct dma_buf_phys_vec *phys); + struct phys_vec *phys); #else static inline void iommufd_test_syz_conv_iova_id(struct iommufd_ucmd *ucmd, unsigned int ioas_id, @@ -742,7 +741,7 @@ static inline bool iommufd_selftest_is_mock_dev(struct device *dev) } static inline int iommufd_test_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, - struct dma_buf_phys_vec *phys) + struct phys_vec *phys) { return -EOPNOTSUPP; } diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c index dbe51ecb9a20..bababd564cf9 100644 --- a/drivers/iommu/iommufd/pages.c +++ b/drivers/iommu/iommufd/pages.c @@ -1077,7 +1077,7 @@ static int pfn_reader_user_update_pinned(struct pfn_reader_user *user, } struct pfn_reader_dmabuf { - struct dma_buf_phys_vec phys; + struct phys_vec phys; unsigned long start_offset; }; @@ -1460,7 +1460,7 @@ static struct dma_buf_attach_ops iopt_dmabuf_attach_revoke_ops = { */ static int sym_vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, - struct dma_buf_phys_vec *phys) + struct phys_vec *phys) { typeof(&vfio_pci_dma_buf_iommufd_map) fn; int rc; diff --git a/drivers/iommu/iommufd/selftest.c b/drivers/iommu/iommufd/selftest.c index 550ff36dec3a..989d8c4c60a7 100644 --- a/drivers/iommu/iommufd/selftest.c +++ b/drivers/iommu/iommufd/selftest.c @@ -2002,7 +2002,7 @@ static const struct dma_buf_ops iommufd_test_dmabuf_ops = { }; int iommufd_test_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, - struct dma_buf_phys_vec *phys) + struct phys_vec *phys) { struct iommufd_test_dma_buf *priv = attachment->dmabuf->priv; diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c index 84d142a47ec6..a0f4edd6a30b 100644 --- a/drivers/vfio/pci/nvgrace-gpu/main.c +++ b/drivers/vfio/pci/nvgrace-gpu/main.c @@ -784,7 +784,7 @@ nvgrace_gpu_write(struct vfio_device *core_vdev, static int nvgrace_get_dmabuf_phys(struct vfio_pci_core_device *core_vdev, struct p2pdma_provider **provider, unsigned int region_index, - struct dma_buf_phys_vec *phys_vec, + struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges) { diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c index d4d0f7d08c53..9a84c238c013 100644 --- a/drivers/vfio/pci/vfio_pci_dmabuf.c +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c @@ -14,7 +14,7 @@ struct vfio_pci_dma_buf { struct vfio_pci_core_device *vdev; struct list_head dmabufs_elm; size_t size; - struct dma_buf_phys_vec *phys_vec; + struct phys_vec *phys_vec; struct p2pdma_provider *provider; u32 nr_ranges; u8 revoked : 1; @@ -94,7 +94,7 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = { * will fail if it is currently revoked */ int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, - struct dma_buf_phys_vec *phys) + struct phys_vec *phys) { struct vfio_pci_dma_buf *priv; @@ -116,7 +116,7 @@ int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, } EXPORT_SYMBOL_FOR_MODULES(vfio_pci_dma_buf_iommufd_map, "iommufd"); -int vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, +int vfio_pci_core_fill_phys_vec(struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges, phys_addr_t start, phys_addr_t len) @@ -148,7 +148,7 @@ EXPORT_SYMBOL_GPL(vfio_pci_core_fill_phys_vec); int vfio_pci_core_get_dmabuf_phys(struct vfio_pci_core_device *vdev, struct p2pdma_provider **provider, unsigned int region_index, - struct dma_buf_phys_vec *phys_vec, + struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges) { diff --git a/include/linux/dma-buf-mapping.h b/include/linux/dma-buf-mapping.h index a3c0ce2d3a42..09bde3f748e4 100644 --- a/include/linux/dma-buf-mapping.h +++ b/include/linux/dma-buf-mapping.h @@ -9,7 +9,7 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, struct p2pdma_provider *provider, - struct dma_buf_phys_vec *phys_vec, + struct phys_vec *phys_vec, size_t nr_ranges, size_t size, enum dma_data_direction dir); void dma_buf_free_sgt(struct dma_buf_attachment *attach, struct sg_table *sgt, diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 0bc492090237..400a5311368e 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -531,16 +531,6 @@ struct dma_buf_export_info { void *priv; }; -/** - * struct dma_buf_phys_vec - describe continuous chunk of memory - * @paddr: physical address of that chunk - * @len: Length of this chunk - */ -struct dma_buf_phys_vec { - phys_addr_t paddr; - size_t len; -}; - /** * DEFINE_DMA_BUF_EXPORT_INFO - helper macro for exporters * @name: export-info name diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h index 706877f998ff..2ac288bb2c60 100644 --- a/include/linux/vfio_pci_core.h +++ b/include/linux/vfio_pci_core.h @@ -28,7 +28,6 @@ struct vfio_pci_core_device; struct vfio_pci_region; struct p2pdma_provider; -struct dma_buf_phys_vec; struct dma_buf_attachment; struct vfio_pci_eventfd { @@ -62,25 +61,25 @@ struct vfio_pci_device_ops { int (*get_dmabuf_phys)(struct vfio_pci_core_device *vdev, struct p2pdma_provider **provider, unsigned int region_index, - struct dma_buf_phys_vec *phys_vec, + struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges); }; #if IS_ENABLED(CONFIG_VFIO_PCI_DMABUF) -int vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, +int vfio_pci_core_fill_phys_vec(struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges, phys_addr_t start, phys_addr_t len); int vfio_pci_core_get_dmabuf_phys(struct vfio_pci_core_device *vdev, struct p2pdma_provider **provider, unsigned int region_index, - struct dma_buf_phys_vec *phys_vec, + struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges); #else static inline int -vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, +vfio_pci_core_fill_phys_vec(struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges, phys_addr_t start, phys_addr_t len) @@ -89,7 +88,7 @@ vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, } static inline int vfio_pci_core_get_dmabuf_phys( struct vfio_pci_core_device *vdev, struct p2pdma_provider **provider, - unsigned int region_index, struct dma_buf_phys_vec *phys_vec, + unsigned int region_index, struct phys_vec *phys_vec, struct vfio_region_dma_range *dma_ranges, size_t nr_ranges) { return -EOPNOTSUPP; @@ -228,6 +227,6 @@ static inline bool is_aligned_for_order(struct vm_area_struct *vma, } int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment, - struct dma_buf_phys_vec *phys); + struct phys_vec *phys); #endif /* VFIO_PCI_CORE_H */ --- base-commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b change-id: 20260107-convert-to-pvec-bf04dfcf3d12 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 month

2
2
0 0

Re: [PATCH 2/5] accel/thames: Add driver for the C7x DSPs in TI SoCs

by Jani Nikula

On Tue, 13 Jan 2026, Tomeu Vizoso <tomeu(a)tomeuvizoso.net> wrote: > diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile > index 1d3a7251b950f39e2ae600a2fc07a3ef7e41831e..8472989cbe22746f1e7292d2401fa0f7424a6c15 100644 > --- a/drivers/accel/Makefile > +++ b/drivers/accel/Makefile > @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/ > obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/ > obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/ > obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/ > -obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > \ No newline at end of file > +obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > +obj-$(CONFIG_DRM_ACCEL_THAMES) += thames/ > \ No newline at end of file Maybe add the newline while at it. > diff --git a/drivers/accel/thames/thames_core.c b/drivers/accel/thames/thames_core.c > new file mode 100644 > index 0000000000000000000000000000000000000000..92af1d68063116bcfa28a33960cbe829029fc1bf > --- /dev/null > +++ b/drivers/accel/thames/thames_core.c > @@ -0,0 +1,155 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* Copyright 2026 Texas Instruments Incorporated - https://www.ti.com/ */ > + > +#include "linux/remoteproc.h" Ditto here about <> not "". -- Jani Nikula, Intel

1 month

1
0
0 0

Re: [PATCH 4/5] accel/thames: Add IOCTL for job submission

by Jani Nikula

On Tue, 13 Jan 2026, Tomeu Vizoso <tomeu(a)tomeuvizoso.net> wrote: > +#include "linux/dev_printk.h" Random drive-by comment, please use <> instead of "" for include/ headers. > +#include <drm/drm_file.h> > +#include <drm/drm_gem.h> > +#include <drm/drm_print.h> > +#include <drm/thames_accel.h> > +#include <linux/platform_device.h> In general, I think it will make everyone's life easier in the long run if the include directives are grouped and sorted. BR, Jani. -- Jani Nikula, Intel

1 month

1
0
0 0

Re: [PATCH 02/10] dma-buf: add dma_fence_is_initialized function

by Christian König

On 1/14/26 10:53, Tvrtko Ursulin wrote: > \ > On 13/01/2026 15:16, Christian König wrote: >> Some driver use fence->ops to test if a fence was initialized or not. >> The problem is that this utilizes internal behavior of the dma_fence >> implementation. >> >> So better abstract that into a function. >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 13 +++++++------ >> drivers/gpu/drm/qxl/qxl_release.c | 2 +- >> include/linux/dma-fence.h | 12 ++++++++++++ >> 3 files changed, 20 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> index 0a0dcbf0798d..b97f90bbe8b9 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c >> @@ -278,9 +278,10 @@ void amdgpu_job_free_resources(struct amdgpu_job *job) >> unsigned i; >> /* Check if any fences were initialized */ >> - if (job->base.s_fence && job->base.s_fence->finished.ops) >> + if (job->base.s_fence && >> + dma_fence_is_initialized(&job->base.s_fence->finished)) >> f = &job->base.s_fence->finished; >> - else if (job->hw_fence && job->hw_fence->base.ops) >> + else if (dma_fence_is_initialized(&job->hw_fence->base)) >> f = &job->hw_fence->base; >> else >> f = NULL; >> @@ -297,11 +298,11 @@ static void amdgpu_job_free_cb(struct drm_sched_job *s_job) >> amdgpu_sync_free(&job->explicit_sync); >> - if (job->hw_fence->base.ops) >> + if (dma_fence_is_initialized(&job->hw_fence->base)) >> dma_fence_put(&job->hw_fence->base); >> else >> kfree(job->hw_fence); >> - if (job->hw_vm_fence->base.ops) >> + if (dma_fence_is_initialized(&job->hw_vm_fence->base)) >> dma_fence_put(&job->hw_vm_fence->base); >> else >> kfree(job->hw_vm_fence); >> @@ -335,11 +336,11 @@ void amdgpu_job_free(struct amdgpu_job *job) >> if (job->gang_submit != &job->base.s_fence->scheduled) >> dma_fence_put(job->gang_submit); >> - if (job->hw_fence->base.ops) >> + if (dma_fence_is_initialized(&job->hw_fence->base)) >> dma_fence_put(&job->hw_fence->base); >> else >> kfree(job->hw_fence); >> - if (job->hw_vm_fence->base.ops) >> + if (dma_fence_is_initialized(&job->hw_vm_fence->base)) >> dma_fence_put(&job->hw_vm_fence->base); >> else >> kfree(job->hw_vm_fence); >> diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c >> index 7b3c9a6016db..b38ae0b25f3c 100644 >> --- a/drivers/gpu/drm/qxl/qxl_release.c >> +++ b/drivers/gpu/drm/qxl/qxl_release.c >> @@ -146,7 +146,7 @@ qxl_release_free(struct qxl_device *qdev, >> idr_remove(&qdev->release_idr, release->id); >> spin_unlock(&qdev->release_idr_lock); >> - if (release->base.ops) { >> + if (dma_fence_is_initialized(&release->base)) { >> WARN_ON(list_empty(&release->bos)); >> qxl_release_free_list(release); >> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h >> index eea674acdfa6..371aa8ecf18e 100644 >> --- a/include/linux/dma-fence.h >> +++ b/include/linux/dma-fence.h >> @@ -274,6 +274,18 @@ void dma_fence_release(struct kref *kref); >> void dma_fence_free(struct dma_fence *fence); >> void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq); >> +/** >> + * dma_fence_is_initialized - test if fence was initialized >> + * @fence: fence to test >> + * >> + * Return: True if fence was initialized, false otherwise. Works correctly only >> + * when memory backing the fence structure is zero initialized on allocation. >> + */ >> +static inline bool dma_fence_is_initialized(struct dma_fence *fence) >> +{ >> + return fence && !!fence->ops; > > This patch should precede the one adding RCU protection to fence->ops. And that one then needs to add a rcu_dereference() here. Good point. > At which point however it would start exploding? When we start setting the ops pointer to NULL in the next patch. > Which also means the new API is racy by definition and can give false positives if fence would be to be signaled as someone is checking. Oh, that is a really really good point. I haven't thought about that because all current users would check the fence only after it is signaled. > Hmm.. is the new API too weak, being able to only be called under very limited circumstances? Yes, exactly that. All callers use this only to decide on the correct cleanup path. So the fence is either fully signaled or was never initialized in the first place. > Would it be better to solve it in the drivers by tracking state? The alternative I had in mind was to use another DMA_FENCE_FLAG_... for that. I will probably use that approach instead, just to make it extra defensive. Thanks, Christian. > > Regards, > > Tvrtko > >> +} >> + >> /** >> * dma_fence_put - decreases refcount of the fence >> * @fence: fence to reduce refcount of >

1 month

1
0
0 0

Re: [PATCH] i2c: qcom-geni: make sure I2C hub controllers can't use SE DMA

by Wolfram Sang

On Wed, Oct 29, 2025 at 07:07:42PM +0100, Neil Armstrong wrote: > The I2C Hub controller is a simpler GENI I2C variant that doesn't > support DMA at all, add a no_dma flag to make sure it nevers selects > the SE DMA mode with mappable 32bytes long transfers. > > Fixes: cacd9643eca7 ("i2c: qcom-geni: add support for I2C Master Hub variant") > Signed-off-by: Neil Armstrong <neil.armstrong(a)linaro.org> > Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> > Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya(a)oss.qualcomm.com>> Applied to for-current, thanks!

1 month

1
0
0 0

Re: [PATCH 10/10] drm/sched: use inline locks for the drm-sched-fence v2

by Christian König

On 1/13/26 17:12, Philipp Stanner wrote: > On Tue, 2026-01-13 at 16:16 +0100, Christian König wrote: >> Using the inline lock is now the recommended way for dma_fence implementations. >> >> For the scheduler fence use the inline lock for the scheduled fence part >> and then the lock from the scheduled fence as external lock for the finished fence. >> >> This way there is no functional difference, except for saving the space >> for the separate lock. >> >> v2: re-work the patch to avoid any functional difference > > *cough cough* > >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> --- >> drivers/gpu/drm/scheduler/sched_fence.c | 6 +++--- >> include/drm/gpu_scheduler.h | 4 ---- >> 2 files changed, 3 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c >> index 724d77694246..112677231f9a 100644 >> --- a/drivers/gpu/drm/scheduler/sched_fence.c >> +++ b/drivers/gpu/drm/scheduler/sched_fence.c >> @@ -217,7 +217,6 @@ struct drm_sched_fence *drm_sched_fence_alloc(struct drm_sched_entity *entity, >> >> fence->owner = owner; >> fence->drm_client_id = drm_client_id; >> - spin_lock_init(&fence->lock); >> >> return fence; >> } >> @@ -230,9 +229,10 @@ void drm_sched_fence_init(struct drm_sched_fence *fence, >> fence->sched = entity->rq->sched; >> seq = atomic_inc_return(&entity->fence_seq); >> dma_fence_init(&fence->scheduled, &drm_sched_fence_ops_scheduled, >> - &fence->lock, entity->fence_context, seq); >> + NULL, entity->fence_context, seq); >> dma_fence_init(&fence->finished, &drm_sched_fence_ops_finished, >> - &fence->lock, entity->fence_context + 1, seq); >> + dma_fence_spinlock(&fence->scheduled), > > I think while you are correct that this is no functional difference, it > is still a bad idea which violates the entire idea of your series: > > All fences are now independent from each other and the fence context – > except for those two. > > Some fences are more equal than others ;) Yeah, I was going back and forth once more if I should keep this patch at all or just drop it. > By implementing this, you would also show to people browsing the code > that it can be a good idea or can be done to have fences share locks. > Do you want that? Good question. For almost all cases we don't want this, but once more the scheduler is special. In the scheduler we have two fences in one, the scheduled one and the finished one. So here it technically makes sense to have this construct to be defensive. But on the other hand it has no practical value because it still doesn't allow us to unload the scheduler module. We would need a much wider rework for being able to do that. So maybe I should just really drop this patch or at least keep it back until we had time to figure out what the next steps are. > As far as I have learned from you and our discussions, that would be a > very bombastic violation of the sacred "dma-fence-rules". Well using the inline fence is "only" a strong recommendation. It's not as heavy as the signaling rules because when you mess up those you can easily kill the whole system. > I believe it's definitely worth sacrificing some bytes so that those > two fences get fully decoupled. Who will have it on their radar that > they are special? Think about future reworks. This doesn't even save any bytes, my thinking was more that this is the more defensive approach should anybody use the spinlock pointer from the scheduler fence to do some locking. > Besides that, no objections from my side. Thanks, Christian. > > > P. > >> + entity->fence_context + 1, seq); >> } >> >> module_init(drm_sched_fence_slab_init); >> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h >> index 78e07c2507c7..ad3704685163 100644 >> --- a/include/drm/gpu_scheduler.h >> +++ b/include/drm/gpu_scheduler.h >> @@ -297,10 +297,6 @@ struct drm_sched_fence { >> * belongs to. >> */ >> struct drm_gpu_scheduler *sched; >> - /** >> - * @lock: the lock used by the scheduled and the finished fences. >> - */ >> - spinlock_t lock; >> /** >> * @owner: job owner for debugging >> */ >

1 month

1
0
0 0

Re: [PATCH v2 2/2] dma-buf: system_heap: account for system heap allocation in memcg

by Christian König

On 1/13/26 22:32, Eric Chanudet wrote: > The system dma-buf heap lets userspace allocate buffers from the page > allocator. However, these allocations are not accounted for in memcg, > allowing processes to escape limits that may be configured. > > Pass __GFP_ACCOUNT for system heap allocations, based on the > dma_heap.mem_accounting parameter, to use memcg and account for them. > > Signed-off-by: Eric Chanudet <echanude(a)redhat.com> > --- > drivers/dma-buf/heaps/system_heap.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c > index 4c782fe33fd497a74eb5065797259576f9b651b6..139b50df64ed4c4a6fdd69f25fe48324fbe2c481 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -52,6 +52,8 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; > static const unsigned int orders[] = {8, 4, 0}; > #define NUM_ORDERS ARRAY_SIZE(orders) > > +extern bool mem_accounting; Please define that in some header. Apart from that looks good technically. But after the discussion it sounds more and more like we don't want to account device driver allocated memory in memcg at all. Regards, Christian. > + > static int dup_sg_table(struct sg_table *from, struct sg_table *to) > { > struct scatterlist *sg, *new_sg; > @@ -320,14 +322,17 @@ static struct page *alloc_largest_available(unsigned long size, > { > struct page *page; > int i; > + gfp_t flags; > > for (i = 0; i < NUM_ORDERS; i++) { > if (size < (PAGE_SIZE << orders[i])) > continue; > if (max_order < orders[i]) > continue; > - > - page = alloc_pages(order_flags[i], orders[i]); > + flags = order_flags[i]; > + if (mem_accounting) > + flags |= __GFP_ACCOUNT; > + page = alloc_pages(flags, orders[i]); > if (!page) > continue; > return page; >

1 month

1
0
0 0

Independence for dma_fences! v5

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. Especially the first patch still needs a Reviewed-by, apart from that I think I've addressed all review comments and problems. Please review and comment, Christian.

1 month

2
13
0 0

Re: [PATCH 0/5] New DRM accel driver for Texas Instruments' C7x DSPs

by Christian König

On 1/13/26 18:44, Tomeu Vizoso wrote: > This series adds a new DRM/Accel driver that supports the C7x DSPs > inside some Texas Instruments SoCs such as the J722S. These can be used > as accelerators for various workloads, including machine learning > inference. > > This driver controls the power state of the hardware via remoteproc and > communicates with the firmware running on the DSP via rpmsg_virtio. The > kernel driver itself allocates buffers, manages contexts, and submits > jobs to the DSP firmware. Buffers are mapped by the DSP itself using its > MMU, providing memory isolation among different clients. > > The source code for the firmware running on the DSP is available at: > https://gitlab.freedesktop.org/tomeu/thames_firmware/. > > Everything else is done in userspace, as a Gallium driver (also called > thames) that is part of the Mesa3D project: https://docs.mesa3d.org/teflon.html > > If there is more than one core that advertises the same rpmsg_virtio > service name, the driver will load balance jobs between them with > drm-gpu-scheduler. I only took 5 minutes to skim over it, so no full review. You have the classic mistake of allocating memory in the run_job callback of the scheduler, but that is trivial to fix. Apart from that looks pretty solid to me. Regards, Christian. > > Userspace portion of the driver: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39298 > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > Tomeu Vizoso (5): > arm64: dts: ti: k3-j722s-ti-ipc-firmware: Add memory pool for DSP i/o buffers > accel/thames: Add driver for the C7x DSPs in TI SoCs > accel/thames: Add IOCTLs for BO creation and mapping > accel/thames: Add IOCTL for job submission > accel/thames: Add IOCTL for memory synchronization > > Documentation/accel/thames/index.rst | 28 ++ > MAINTAINERS | 9 + > .../boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi | 11 +- > drivers/accel/Kconfig | 1 + > drivers/accel/Makefile | 3 +- > drivers/accel/thames/Kconfig | 26 ++ > drivers/accel/thames/Makefile | 11 + > drivers/accel/thames/thames_core.c | 161 +++++++ > drivers/accel/thames/thames_core.h | 53 +++ > drivers/accel/thames/thames_device.c | 93 +++++ > drivers/accel/thames/thames_device.h | 46 ++ > drivers/accel/thames/thames_drv.c | 180 ++++++++ > drivers/accel/thames/thames_drv.h | 21 + > drivers/accel/thames/thames_gem.c | 407 ++++++++++++++++++ > drivers/accel/thames/thames_gem.h | 45 ++ > drivers/accel/thames/thames_ipc.h | 204 +++++++++ > drivers/accel/thames/thames_job.c | 463 +++++++++++++++++++++ > drivers/accel/thames/thames_job.h | 51 +++ > drivers/accel/thames/thames_rpmsg.c | 276 ++++++++++++ > drivers/accel/thames/thames_rpmsg.h | 27 ++ > 20 files changed, 2113 insertions(+), 3 deletions(-) > --- > base-commit: 27927a79b3c6aebd18f38507a8160294243763dc > change-id: 20260113-thames-334127a2d91d > > Best regards,

1 month

1
0
0 0

Re: [PATCH 4/5] accel/thames: Add IOCTL for job submission

by Christian König

On 1/13/26 18:44, Tomeu Vizoso wrote: > Using the DRM GPU scheduler infrastructure, with a scheduler for each > core. > > Contexts are created in all cores, and buffers mapped to all of them as > well, so all cores are ready to execute any job. > > The job submission code was initially based on Panfrost. > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > drivers/accel/thames/Makefile | 1 + > drivers/accel/thames/thames_core.c | 6 + > drivers/accel/thames/thames_drv.c | 19 ++ > drivers/accel/thames/thames_job.c | 463 ++++++++++++++++++++++++++++++++++++ > drivers/accel/thames/thames_job.h | 51 ++++ > drivers/accel/thames/thames_rpmsg.c | 52 ++++ > 6 files changed, 592 insertions(+) > > diff --git a/drivers/accel/thames/Makefile b/drivers/accel/thames/Makefile > index 0051e319f2e4966de72bc342d5b6e40b2890c006..b6c4516f8250e3d442f22e80d609cb1be2970128 100644 > --- a/drivers/accel/thames/Makefile > +++ b/drivers/accel/thames/Makefile > @@ -7,4 +7,5 @@ thames-y := \ > thames_device.o \ > thames_drv.o \ > thames_gem.o \ > + thames_job.o \ > thames_rpmsg.o > diff --git a/drivers/accel/thames/thames_core.c b/drivers/accel/thames/thames_core.c > index 92af1d68063116bcfa28a33960cbe829029fc1bf..5b96b25d287096803e034fcd4261d51795871543 100644 > --- a/drivers/accel/thames/thames_core.c > +++ b/drivers/accel/thames/thames_core.c > @@ -13,6 +13,7 @@ > > #include "thames_core.h" > #include "thames_device.h" > +#include "thames_job.h" > #include "thames_rpmsg.h" > > /* Shift to convert bytes to megabytes (divide by 1048576) */ > @@ -115,11 +116,16 @@ int thames_core_init(struct thames_core *core) > if (err) > return err; > > + err = thames_job_init(core); > + if (err) > + return err; > + > return 0; > } > > void thames_core_fini(struct thames_core *core) > { > + thames_job_fini(core); > thames_rpmsg_fini(core); > } > > diff --git a/drivers/accel/thames/thames_drv.c b/drivers/accel/thames/thames_drv.c > index 29a80b9747ae84778b09f5dbd5b8d6d596f1947a..bf7355832241d5a671e196f465d891effaa4a8fb 100644 > --- a/drivers/accel/thames/thames_drv.c > +++ b/drivers/accel/thames/thames_drv.c > @@ -14,6 +14,7 @@ > #include "thames_drv.h" > #include "thames_core.h" > #include "thames_gem.h" > +#include "thames_job.h" > #include "thames_ipc.h" > > static struct platform_device *drm_dev; > @@ -38,8 +39,22 @@ static int thames_open(struct drm_device *dev, struct drm_file *file) > > file->driver_priv = thames_priv; > > + ret = thames_job_open(thames_priv); > + if (ret) > + goto err_free; > + > + ret = thames_context_create(thames_priv); > + if (ret) { > + dev_err(dev->dev, "Failed to create context for client: %d", ret); > + goto err_close_job; > + } > + > return 0; > > +err_close_job: > + thames_job_close(thames_priv); > +err_free: > + kfree(thames_priv); > err_put_mod: > module_put(THIS_MODULE); > return ret; > @@ -49,6 +64,9 @@ static void thames_postclose(struct drm_device *dev, struct drm_file *file) > { > struct thames_file_priv *thames_priv = file->driver_priv; > > + thames_context_destroy(thames_priv); > + > + thames_job_close(thames_priv); > kfree(thames_priv); > module_put(THIS_MODULE); > } > @@ -57,6 +75,7 @@ static const struct drm_ioctl_desc thames_drm_driver_ioctls[] = { > #define THAMES_IOCTL(n, func) DRM_IOCTL_DEF_DRV(THAMES_##n, thames_ioctl_##func, 0) > THAMES_IOCTL(BO_CREATE, bo_create), > THAMES_IOCTL(BO_MMAP_OFFSET, bo_mmap_offset), > + THAMES_IOCTL(SUBMIT, submit), > }; > > DEFINE_DRM_ACCEL_FOPS(thames_accel_driver_fops); > diff --git a/drivers/accel/thames/thames_job.c b/drivers/accel/thames/thames_job.c > new file mode 100644 > index 0000000000000000000000000000000000000000..bd8f8fa1783cf10c5e71c8f2ce5fcc880a9b150b > --- /dev/null > +++ b/drivers/accel/thames/thames_job.c > @@ -0,0 +1,463 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* Copyright 2019 Linaro, Ltd, Rob Herring <robh(a)kernel.org> */ > +/* Copyright 2019 Collabora ltd. */ > +/* Copyright 2024-2025 Tomeu Vizoso <tomeu(a)tomeuvizoso.net> */ > +/* Copyright 2026 Texas Instruments Incorporated - https://www.ti.com/ */ > + > +#include "linux/dev_printk.h" > +#include <drm/drm_file.h> > +#include <drm/drm_gem.h> > +#include <drm/drm_print.h> > +#include <drm/thames_accel.h> > +#include <linux/platform_device.h> > + > +#include "thames_core.h" > +#include "thames_device.h" > +#include "thames_drv.h" > +#include "thames_gem.h" > +#include "thames_job.h" > +#include "thames_rpmsg.h" > + > +#define JOB_TIMEOUT_MS 500 > + > +static struct thames_job *to_thames_job(struct drm_sched_job *sched_job) > +{ > + return container_of(sched_job, struct thames_job, base); > +} > + > +static const char *thames_fence_get_driver_name(struct dma_fence *fence) > +{ > + return "thames"; > +} > + > +static const char *thames_fence_get_timeline_name(struct dma_fence *fence) > +{ > + return "thames"; > +} > + > +static const struct dma_fence_ops thames_fence_ops = { > + .get_driver_name = thames_fence_get_driver_name, > + .get_timeline_name = thames_fence_get_timeline_name, > +}; > + > +static struct dma_fence *thames_fence_create(struct thames_core *core) > +{ > + struct dma_fence *fence; > + > + fence = kzalloc(sizeof(*fence), GFP_KERNEL); Oh yeah, that is the classic mistake :) You should not allocate any memory in the schedulers job_run() callback! The best solution is to split your kzalloc() from the dma_fence_init() and allocate memory when creating the job. The alternative is to use GFP_ATOMIC, but that is not really nice since it digs into the atomic reserve without a good reason. For things like core dumps and debugging output you can also use GFP_NOWAIT, but keep in mind that this can trivially fail so it is not good for things fences. Regards, Christian. > + if (!fence) > + return ERR_PTR(-ENOMEM); > + > + dma_fence_init(fence, &thames_fence_ops, &core->fence_lock, core->fence_context, > + ++core->emit_seqno); > + > + return fence; > +} > + > +static void thames_job_hw_submit(struct thames_core *core, struct thames_job *job) > +{ > + int ret; > + > + /* Don't queue the job if a reset is in progress */ > + if (atomic_read(&core->reset.pending)) > + return; > + > + ret = thames_rpmsg_send_submit_job(core, job->file_priv->context_id, job->job_id, > + to_thames_bo(job->kernel)->iova, job->kernel_size, > + to_thames_bo(job->params)->iova, job->params_size, > + &job->ipc_sequence); > + > + if (ret) { > + dev_err(core->dev, "Failed to submit kernel to DSP core %d\n", core->index); > + return; > + } > +} > + > +static int thames_acquire_object_fences(struct drm_gem_object **bos, int bo_count, > + struct drm_sched_job *job, bool is_write) > +{ > + int i, ret; > + > + for (i = 0; i < bo_count; i++) { > + ret = dma_resv_reserve_fences(bos[i]->resv, 1); > + if (ret) > + return ret; > + > + ret = drm_sched_job_add_implicit_dependencies(job, bos[i], is_write); > + if (ret) > + return ret; > + } > + > + return 0; > +} > + > +static void thames_attach_object_fences(struct drm_gem_object **bos, int bo_count, > + struct dma_fence *fence) > +{ > + int i; > + > + for (i = 0; i < bo_count; i++) > + dma_resv_add_fence(bos[i]->resv, fence, DMA_RESV_USAGE_WRITE); > +} > + > +static int thames_job_push(struct thames_job *job) > +{ > + struct thames_device *tdev = job->tdev; > + struct drm_gem_object **bos; > + struct ww_acquire_ctx acquire_ctx; > + int ret = 0; > + > + dev_dbg(tdev->ddev.dev, "Pushing job with %u in BOs and %u out BOs\n", job->in_bo_count, > + job->out_bo_count); > + bos = kvmalloc_array(job->in_bo_count + job->out_bo_count, sizeof(void *), GFP_KERNEL); > + memcpy(bos, job->in_bos, job->in_bo_count * sizeof(void *)); > + memcpy(&bos[job->in_bo_count], job->out_bos, job->out_bo_count * sizeof(void *)); > + > + ret = drm_gem_lock_reservations(bos, job->in_bo_count + job->out_bo_count, &acquire_ctx); > + if (ret) > + goto err; > + > + scoped_guard(mutex, &tdev->sched_lock) > + { > + drm_sched_job_arm(&job->base); > + > + job->inference_done_fence = dma_fence_get(&job->base.s_fence->finished); > + > + ret = thames_acquire_object_fences(job->in_bos, job->in_bo_count, &job->base, > + false); > + if (ret) > + goto err_unlock; > + > + ret = thames_acquire_object_fences(job->out_bos, job->out_bo_count, &job->base, > + true); > + if (ret) > + goto err_unlock; > + > + kref_get(&job->refcount); /* put by scheduler job completion */ > + > + drm_sched_entity_push_job(&job->base); > + } > + > + thames_attach_object_fences(job->out_bos, job->out_bo_count, job->inference_done_fence); > + > +err_unlock: > + drm_gem_unlock_reservations(bos, job->in_bo_count + job->out_bo_count, &acquire_ctx); > +err: > + kvfree(bos); > + > + return ret; > +} > + > +static void thames_job_cleanup(struct kref *ref) > +{ > + struct thames_job *job = container_of(ref, struct thames_job, refcount); > + struct thames_device *tdev = job->tdev; > + unsigned int i; > + > + dma_fence_put(job->done_fence); > + dma_fence_put(job->inference_done_fence); > + > + ida_free(&tdev->job_ida, job->job_id); > + > + if (job->kernel) > + drm_gem_object_put(job->kernel); > + > + if (job->params) > + drm_gem_object_put(job->params); > + > + if (job->in_bos) { > + for (i = 0; i < job->in_bo_count; i++) > + drm_gem_object_put(job->in_bos[i]); > + > + kvfree(job->in_bos); > + } > + > + if (job->out_bos) { > + for (i = 0; i < job->out_bo_count; i++) > + drm_gem_object_put(job->out_bos[i]); > + > + kvfree(job->out_bos); > + } > + > + kfree(job); > +} > + > +static void thames_job_put(struct thames_job *job) > +{ > + kref_put(&job->refcount, thames_job_cleanup); > +} > + > +static void thames_job_free(struct drm_sched_job *sched_job) > +{ > + struct thames_job *job = to_thames_job(sched_job); > + > + drm_sched_job_cleanup(sched_job); > + > + thames_job_put(job); > +} > + > +static struct thames_core *sched_to_core(struct thames_device *tdev, > + struct drm_gpu_scheduler *sched) > +{ > + unsigned int core; > + > + for (core = 0; core < tdev->num_cores; core++) { > + if (&tdev->cores[core].sched == sched) > + return &tdev->cores[core]; > + } > + > + return NULL; > +} > + > +static struct dma_fence *thames_job_run(struct drm_sched_job *sched_job) > +{ > + struct thames_job *job = to_thames_job(sched_job); > + struct thames_device *tdev = job->tdev; > + struct thames_core *core = sched_to_core(tdev, sched_job->sched); > + struct dma_fence *fence = NULL; > + > + if (unlikely(job->base.s_fence->finished.error)) > + return NULL; > + > + fence = thames_fence_create(core); > + if (IS_ERR(fence)) > + return fence; > + > + if (job->done_fence) > + dma_fence_put(job->done_fence); > + job->done_fence = dma_fence_get(fence); > + > + scoped_guard(mutex, &core->job_lock) > + { > + core->in_flight_job = job; > + thames_job_hw_submit(core, job); > + } > + > + return fence; > +} > + > +static void thames_reset(struct thames_core *core, struct drm_sched_job *bad) > +{ > + if (!atomic_read(&core->reset.pending)) > + return; > + > + drm_sched_stop(&core->sched, bad); > + scoped_guard(mutex, &core->job_lock) core->in_flight_job = NULL; > + thames_core_reset(core); > + atomic_set(&core->reset.pending, 0); > + drm_sched_start(&core->sched, 0); > +} > + > +static enum drm_gpu_sched_stat thames_job_timedout(struct drm_sched_job *sched_job) > +{ > + struct thames_job *job = to_thames_job(sched_job); > + struct thames_device *tdev = job->tdev; > + struct thames_core *core = sched_to_core(tdev, sched_job->sched); > + > + if (!core) { > + dev_err(tdev->ddev.dev, "Failed to find core for timed out job\n"); > + return DRM_GPU_SCHED_STAT_NONE; > + } > + > + dev_err(core->dev, "Job %u timed out on DSP core %d\n", job->job_id, core->index); > + > + atomic_set(&core->reset.pending, 1); > + thames_reset(core, sched_job); > + > + return DRM_GPU_SCHED_STAT_RESET; > +} > + > +static void thames_reset_work(struct work_struct *work) > +{ > + struct thames_core *core; > + > + core = container_of(work, struct thames_core, reset.work); > + thames_reset(core, NULL); > +} > + > +static const struct drm_sched_backend_ops thames_sched_ops = { .run_job = thames_job_run, > + .timedout_job = thames_job_timedout, > + .free_job = thames_job_free }; > + > +int thames_job_init(struct thames_core *core) > +{ > + struct drm_sched_init_args args = { > + .ops = &thames_sched_ops, > + .num_rqs = DRM_SCHED_PRIORITY_COUNT, > + .credit_limit = 1, > + .timeout = msecs_to_jiffies(JOB_TIMEOUT_MS), > + .name = dev_name(core->dev), > + .dev = core->dev, > + }; > + int ret; > + > + INIT_WORK(&core->reset.work, thames_reset_work); > + spin_lock_init(&core->fence_lock); > + mutex_init(&core->job_lock); > + > + core->reset.wq = alloc_ordered_workqueue("thames-reset-%d", 0, core->index); > + if (!core->reset.wq) > + return -ENOMEM; > + > + core->fence_context = dma_fence_context_alloc(1); > + > + args.timeout_wq = core->reset.wq; > + ret = drm_sched_init(&core->sched, &args); > + if (ret) { > + dev_err(core->dev, "Failed to create scheduler: %d.", ret); > + destroy_workqueue(core->reset.wq); > + return ret; > + } > + > + return 0; > +} > + > +void thames_job_fini(struct thames_core *core) > +{ > + drm_sched_fini(&core->sched); > + > + cancel_work_sync(&core->reset.work); > + destroy_workqueue(core->reset.wq); > +} > + > +int thames_job_open(struct thames_file_priv *thames_priv) > +{ > + struct thames_device *tdev = thames_priv->tdev; > + struct drm_gpu_scheduler **scheds = > + kmalloc_array(tdev->num_cores, sizeof(*scheds), GFP_KERNEL); > + unsigned int core; > + int ret; > + > + for (core = 0; core < tdev->num_cores; core++) > + scheds[core] = &tdev->cores[core].sched; > + > + ret = drm_sched_entity_init(&thames_priv->sched_entity, DRM_SCHED_PRIORITY_NORMAL, scheds, > + tdev->num_cores, NULL); > + if (WARN_ON(ret)) > + return ret; > + > + return 0; > +} > + > +void thames_job_close(struct thames_file_priv *thames_priv) > +{ > + struct drm_sched_entity *entity = &thames_priv->sched_entity; > + > + kfree(entity->sched_list); > + drm_sched_entity_destroy(entity); > +} > + > +static int thames_ioctl_submit_job(struct drm_device *dev, struct drm_file *file, > + struct drm_thames_job *job) > +{ > + struct thames_device *tdev = to_thames_device(dev); > + struct thames_file_priv *file_priv = file->driver_priv; > + struct thames_job *tjob = NULL; > + int ret = 0; > + > + tjob = kzalloc(sizeof(*tjob), GFP_KERNEL); > + if (!tjob) > + return -ENOMEM; > + > + kref_init(&tjob->refcount); > + > + tjob->tdev = tdev; > + tjob->file_priv = file_priv; > + > + tjob->job_id = ida_alloc_min(&tdev->job_ida, 1, GFP_KERNEL); > + if (tjob->job_id < 0) > + goto out_put_job; > + > + ret = drm_sched_job_init(&tjob->base, &file_priv->sched_entity, 1, NULL, file->client_id); > + if (ret) > + goto out_put_job; > + > + tjob->kernel = drm_gem_object_lookup(file, job->kernel); > + if (!tjob->kernel) { > + ret = -ENOENT; > + goto out_cleanup_job; > + } > + > + tjob->kernel_size = job->kernel_size; > + > + if (job->params) { > + tjob->params = drm_gem_object_lookup(file, job->params); > + if (!tjob->params) { > + ret = -ENOENT; > + goto out_cleanup_job; > + } > + tjob->params_size = job->params_size; > + } > + > + ret = drm_gem_objects_lookup(file, u64_to_user_ptr(job->in_bo_handles), > + job->in_bo_handle_count, &tjob->in_bos); > + if (ret) > + goto out_cleanup_job; > + > + tjob->in_bo_count = job->in_bo_handle_count; > + > + ret = drm_gem_objects_lookup(file, u64_to_user_ptr(job->out_bo_handles), > + job->out_bo_handle_count, &tjob->out_bos); > + if (ret) > + goto out_cleanup_job; > + > + tjob->out_bo_count = job->out_bo_handle_count; > + > + ret = thames_job_push(tjob); > + > +out_cleanup_job: > + if (ret) > + drm_sched_job_cleanup(&tjob->base); > +out_put_job: > + thames_job_put(tjob); > + > + return ret; > +} > + > +#define THAMES_MAX_JOBS_PER_SUBMIT 256 > + > +int thames_ioctl_submit(struct drm_device *dev, void *data, struct drm_file *file) > +{ > + struct drm_thames_submit *args = data; > + struct drm_thames_job *jobs; > + size_t jobs_size; > + int ret = 0; > + unsigned int i = 0; > + > + if (args->pad) > + return -EINVAL; > + > + if (args->job_count == 0) > + return -EINVAL; > + > + if (args->job_count > THAMES_MAX_JOBS_PER_SUBMIT) { > + dev_err(dev->dev, "Job count %u exceeds maximum %u\n", args->job_count, > + THAMES_MAX_JOBS_PER_SUBMIT); > + return -EINVAL; > + } > + > + jobs_size = array_size(args->job_count, sizeof(*jobs)); > + if (jobs_size == SIZE_MAX) > + return -EINVAL; > + > + jobs = kvmalloc_array(args->job_count, sizeof(*jobs), GFP_KERNEL); > + if (!jobs) > + return -ENOMEM; > + > + if (copy_from_user(jobs, u64_to_user_ptr(args->jobs), jobs_size)) { > + ret = -EFAULT; > + drm_dbg(dev, "Failed to copy incoming job array\n"); > + goto exit; > + } > + > + for (i = 0; i < args->job_count; i++) { > + ret = thames_ioctl_submit_job(dev, file, &jobs[i]); > + if (ret) > + break; > + } > + > +exit: > + kvfree(jobs); > + > + return ret; > +} > diff --git a/drivers/accel/thames/thames_job.h b/drivers/accel/thames/thames_job.h > new file mode 100644 > index 0000000000000000000000000000000000000000..3bfd2c779d9b783624a25e6d06368f3e1daf569e > --- /dev/null > +++ b/drivers/accel/thames/thames_job.h > @@ -0,0 +1,51 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* Copyright 2024-2025 Tomeu Vizoso <tomeu(a)tomeuvizoso.net> */ > +/* Copyright 2026 Texas Instruments Incorporated - https://www.ti.com/ */ > + > +#ifndef __THAMES_JOB_H__ > +#define __THAMES_JOB_H__ > + > +#include <drm/drm_drv.h> > +#include <drm/gpu_scheduler.h> > + > +#include "thames_core.h" > +#include "thames_drv.h" > + > +struct thames_job { > + struct drm_sched_job base; > + > + struct thames_device *tdev; > + struct thames_file_priv *file_priv; > + > + u32 job_id; > + u32 ipc_sequence; > + > + struct drm_gem_object *kernel; > + size_t kernel_size; > + > + struct drm_gem_object *params; > + size_t params_size; > + > + struct drm_gem_object **in_bos; > + u32 in_bo_count; > + > + struct drm_gem_object **out_bos; > + u32 out_bo_count; > + > + /* Fence to be signaled by drm-sched once its done with the job */ > + struct dma_fence *inference_done_fence; > + > + /* Fence to be signaled by rpmsg handler when the job is complete. */ > + struct dma_fence *done_fence; > + > + struct kref refcount; > +}; > + > +int thames_ioctl_submit(struct drm_device *dev, void *data, struct drm_file *file); > + > +int thames_job_init(struct thames_core *core); > +void thames_job_fini(struct thames_core *core); > +int thames_job_open(struct thames_file_priv *thames_priv); > +void thames_job_close(struct thames_file_priv *thames_priv); > + > +#endif > diff --git a/drivers/accel/thames/thames_rpmsg.c b/drivers/accel/thames/thames_rpmsg.c > index a25465295a177877c5ca2b3c93f52d8288863797..9747690e0f84fe00d605ad0e708d597da2240d97 100644 > --- a/drivers/accel/thames/thames_rpmsg.c > +++ b/drivers/accel/thames/thames_rpmsg.c > @@ -11,6 +11,7 @@ > #include "thames_core.h" > #include "thames_device.h" > #include "thames_ipc.h" > +#include "thames_job.h" > > #define THAMES_PING_TEST_PATTERN 0xDEADBEEF > #define THAMES_PING_TIMEOUT_MS 5000 > @@ -71,6 +72,36 @@ static int thames_rpmsg_callback(struct rpmsg_device *rpdev, void *data, int len > ida_free(&core->tdev->ipc_seq_ida, hdr->seq); > break; > > + case THAMES_MSG_SUBMIT_JOB_RESPONSE: { > + struct thames_job *job; > + > + scoped_guard(mutex, &core->job_lock) > + { > + job = core->in_flight_job; > + if (!job) { > + dev_err(&rpdev->dev, > + "Received job response but no job in flight\n"); > + ida_free(&core->tdev->ipc_seq_ida, hdr->seq); > + return -EINVAL; > + } > + > + if (hdr->seq != job->ipc_sequence) { > + dev_err(&rpdev->dev, > + "Job response sequence mismatch: got %u, expected %u\n", > + hdr->seq, job->ipc_sequence); > + ida_free(&core->tdev->ipc_seq_ida, hdr->seq); > + return -EINVAL; > + } > + > + dma_fence_signal(job->done_fence); > + core->in_flight_job = NULL; > + } > + > + ida_free(&core->tdev->ipc_seq_ida, hdr->seq); > + > + break; > + } > + > default: > dev_warn(&rpdev->dev, "Unknown message type: %u\n", hdr->type); > break; > @@ -191,6 +222,27 @@ int thames_rpmsg_send_unmap_bo(struct thames_core *core, u32 context_id, u32 bo_ > return thames_rpmsg_send_raw(core, &msg, sizeof(msg)); > } > > +int thames_rpmsg_send_submit_job(struct thames_core *core, u32 context_id, u32 job_id, > + u64 kernel_iova, u64 kernel_size, u64 args_iova, u64 args_size, > + u32 *sequence) > +{ > + struct thames_msg_submit_job msg = {}; > + > + msg.hdr.type = THAMES_MSG_SUBMIT_JOB; > + msg.hdr.seq = ida_alloc(&core->tdev->ipc_seq_ida, GFP_KERNEL); > + msg.hdr.len = sizeof(msg); > + msg.context_id = context_id; > + msg.job_id = job_id; > + msg.kernel_iova = kernel_iova; > + msg.kernel_size = kernel_size; > + msg.args_iova = args_iova; > + msg.args_size = args_size; > + > + *sequence = msg.hdr.seq; > + > + return thames_rpmsg_send_raw(core, &msg, sizeof(msg)); > +} > + > int thames_rpmsg_ping_test(struct thames_core *core) > { > const u32 test_data = THAMES_PING_TEST_PATTERN; >

1 month

1
0
0 0

Re: [PATCH 2/5] accel/thames: Add driver for the C7x DSPs in TI SoCs

by Robert Nelson

On Tue, Jan 13, 2026 at 11:45 AM Tomeu Vizoso <tomeu(a)tomeuvizoso.net> wrote: > > Some SoCs from Texas Instruments contain DSPs that can be used for > general compute tasks. > > This driver provides a drm/accel UABI to userspace for submitting jobs > to the DSP cores and managing the input, output and intermediate memory. > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > Documentation/accel/thames/index.rst | 28 +++++ > MAINTAINERS | 9 ++ > drivers/accel/Kconfig | 1 + > drivers/accel/Makefile | 3 +- > drivers/accel/thames/Kconfig | 26 +++++ > drivers/accel/thames/Makefile | 9 ++ > drivers/accel/thames/thames_core.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_core.h | 53 +++++++++ > drivers/accel/thames/thames_device.c | 93 ++++++++++++++++ > drivers/accel/thames/thames_device.h | 46 ++++++++ > drivers/accel/thames/thames_drv.c | 156 +++++++++++++++++++++++++++ > drivers/accel/thames/thames_drv.h | 21 ++++ > drivers/accel/thames/thames_ipc.h | 204 +++++++++++++++++++++++++++++++++++ > drivers/accel/thames/thames_rpmsg.c | 155 ++++++++++++++++++++++++++ > drivers/accel/thames/thames_rpmsg.h | 27 +++++ > 15 files changed, 985 insertions(+), 1 deletion(-) > > diff --git a/Documentation/accel/thames/index.rst b/Documentation/accel/thames/index.rst > new file mode 100644 > index 0000000000000000000000000000000000000000..ca8391031f226f7ef1dc210a356c86acbe126c6f > --- /dev/null > +++ b/Documentation/accel/thames/index.rst > @@ -0,0 +1,28 @@ > +.. SPDX-License-Identifier: GPL-2.0-only > + > +============================================================ > + accel/thames Driver for the C7x DSPs from Texas Instruments > +============================================================ > + > +The accel/thames driver supports the C7x DSPs inside some Texas Instruments SoCs > +such as the J722S. These can be used as accelerators for various workloads, > +including machine learning inference. > + > +This driver controls the power state of the hardware via :doc:`remoteproc </staging/remoteproc>` > +and communicates with the firmware running on the DSP via :doc:`rpmsg_virtio </staging/rpmsg_virtio>`. > +The kernel driver itself allocates buffers, manages contexts, and submits jobs > +to the DSP firmware. Buffers are mapped by the DSP itself using its MMU, > +providing memory isolation among different clients. > + > +The source code for the firmware running on the DSP is available at: > +https://gitlab.freedesktop.org/tomeu/thames_firmware/. > + > +Everything else is done in userspace, as a Gallium driver (also called thames) > +that is part of the Mesa3D project: https://docs.mesa3d.org/teflon.html > + > +If there is more than one core that advertises the same rpmsg_virtio service > +name, the driver will load balance jobs between them with drm-gpu-scheduler. > + > +Hardware currently supported: > + > +* J722S > diff --git a/MAINTAINERS b/MAINTAINERS > index dc731d37c8feeff25613c59fe9c929927dadaa7e..a3fc809c797269d0792dfe5202cc1b49f6ff57e9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7731,6 +7731,15 @@ F: Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml > F: drivers/accel/rocket/ > F: include/uapi/drm/rocket_accel.h > > +DRM ACCEL DRIVER FOR TI C7x DSPS > +M: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > +L: dri-devel(a)lists.freedesktop.org > +S: Supported > +T: git https://gitlab.freedesktop.org/drm/misc/kernel.git > +F: Documentation/accel/thames/ > +F: drivers/accel/thames/ > +F: include/uapi/drm/thames_accel.h Oh where is this "thames_accel.h" ? ;) 2026-01-13T18:16:11.881084Z 01E drivers/accel/thames/thames_drv.c:8:10: fatal error: drm/thames_accel.h: No such file or directory 2026-01-13T18:16:11.881086Z 01E 8 | #include <drm/thames_accel.h> 2026-01-13T18:16:11.881087Z 01E | ^~~~~~~~~~~~~~~~~~~~ 2026-01-13T18:16:11.881115Z 01E compilation terminated. 2026-01-13T18:16:11.884552Z 01E make[8]: *** [scripts/Makefile.build:287: drivers/accel/thames/thames_drv.o] Error 1 2026-01-13T18:16:11.884694Z 01E make[7]: *** [scripts/Makefile.build:544: drivers/accel/thames] Error 2 2026-01-13T18:16:11.884926Z 01E make[6]: *** [scripts/Makefile.build:544: drivers/accel] Error 2 2026-01-13T18:16:11.884976Z 01E make[6]: *** Waiting for unfinished jobs.... $ find . | grep thames_accel.h $ grep -R "thames_accel.h" ./* ./drivers/accel/thames/Kconfig: include/uapi/drm/thames_accel.h and is used by the Thames userspace ./drivers/accel/thames/thames_job.c:#include <drm/thames_accel.h> ./drivers/accel/thames/thames_drv.c:#include <drm/thames_accel.h> ./drivers/accel/thames/thames_gem.c:#include <drm/thames_accel.h> ./MAINTAINERS:F: include/uapi/drm/thames_accel.h Regards, -- Robert Nelson https://rcn-ee.com/

1 month

1
0
0 0

[PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared buffers

by Leon Romanovsky

This series implements a dma-buf “revoke” mechanism: to allow a dma-buf exporter to explicitly invalidate (“kill”) a shared buffer after it has been distributed to importers, so that further CPU and device access is prevented and importers reliably observe failure. Today, dma-buf effectively provides “if you have the fd, you can keep using the memory indefinitely.” That assumption breaks down when an exporter must reclaim, reset, evict, or otherwise retire backing memory after it has been shared. Concrete cases include GPU reset and recovery where old allocations become unsafe to access, memory eviction/overcommit where backing storage must be withdrawn, and security or isolation situations where continued access must be prevented. While drivers can sometimes approximate this with exporter-specific fencing and policy, there is no core dma-buf state transition that communicates “this buffer is no longer valid; fail access” across all access paths. The change in this series is to introduce a core “revoked” state on the dma-buf object and a corresponding exporter-triggered revoke operation. Once a dma-buf is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or mmap the buffer fail in a consistent way. In addition, the series aims to invalidate existing access as much as the kernel allows: device mappings are torn down where possible so devices and IOMMUs cannot continue DMA. The semantics are intentionally simple: revoke is a one-way, permanent transition for the lifetime of that dma-buf instance. From a compatibility perspective, users that never invoke revoke are unaffected, and exporters that adopt it gain a core-supported enforcement mechanism rather than relying on ad hoc driver behavior. The intent is to keep the interface minimal and avoid imposing policy; the series provides the mechanism to terminate access, with policy remaining in the exporter and higher-level components. BTW, see this megathread [1] for additional context. Ironically, it was posted exactly one year ago. [1] https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@linux.intel.co… Thanks Cc: linux-rdma(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: kvm(a)vger.kernel.org Cc: iommu(a)lists.linux.dev To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Leon Romanovsky <leon(a)kernel.org> To: Sumit Semwal <sumit.semwal(a)linaro.org> To: Christian König <christian.koenig(a)amd.com> To: Alex Williamson <alex(a)shazbot.org> To: Kevin Tian <kevin.tian(a)intel.com> To: Joerg Roedel <joro(a)8bytes.org> To: Will Deacon <will(a)kernel.org> To: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Leon Romanovsky (4): dma-buf: Introduce revoke semantics vfio: Use dma-buf revoke semantics iommufd: Require DMABUF revoke semantics iommufd/selftest: Reuse dma-buf revoke semantics drivers/dma-buf/dma-buf.c | 36 ++++++++++++++++++++++++++++++++---- drivers/iommu/iommufd/pages.c | 2 +- drivers/iommu/iommufd/selftest.c | 12 ++++-------- drivers/vfio/pci/vfio_pci_dmabuf.c | 27 ++++++--------------------- include/linux/dma-buf.h | 31 +++++++++++++++++++++++++++++++ 5 files changed, 74 insertions(+), 34 deletions(-) --- base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 month

3
13
0 0

Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf

by Christoph Hellwig

On Fri, Jan 09, 2026 at 10:10:57AM +0800, Ming Lei wrote: > On Thu, Jan 08, 2026 at 11:17:03AM +0100, Christoph Hellwig wrote: > > On Thu, Jan 08, 2026 at 10:19:18AM +0800, Ming Lei wrote: > > > > The feature is in no way nvme specific. nvme is just the initial > > > > underlying driver. It makes total sense to support this for any high > > > > performance block device, and to pass it through file systems. > > > > > > But why does FS care the dma buffer attachment? Since high performance > > > host controller is exactly the dma buffer attachment point. > > > > I can't parse what you're trying to say here. > > dma buffer attachment is simply none of FS's business. The file systems should indeed never do a dma buffer attachment itself, but that's not the point. > > But even when not stacking, the registration still needs to go > > through the file system even for a single device, never mind multiple > > controlled by the file system. > > dma_buf can have multiple importers, so why does it have to go through FS for > single device only? > > If the registered buffer is attached to single device before going > through FS, it can not support stacking block device, and it can't or not > easily to use for multiple block device, no matter if they are behind same > host controller or multiple. Because the file system, or the file_operations instance to be more specific, is the only entity that known what block device(s) or other DMA capable device(s) like (R)NIC a file maps to.

1 month

1
0
0 0

Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf

by Christoph Hellwig

On Thu, Jan 08, 2026 at 10:19:18AM +0800, Ming Lei wrote: > > The feature is in no way nvme specific. nvme is just the initial > > underlying driver. It makes total sense to support this for any high > > performance block device, and to pass it through file systems. > > But why does FS care the dma buffer attachment? Since high performance > host controller is exactly the dma buffer attachment point. I can't parse what you're trying to say here. > If the callback is added in `struct file_operations` for wiring dma buffer > and the importer(host contrller), you will see it is hard to let it cross device > mapper/raid or other stackable block devices. Why? But even when not stacking, the registration still needs to go through the file system even for a single device, never mind multiple controlled by the file system.

1 month, 1 week

1
0
0 0

Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf

by Christian König

On 1/4/26 02:42, Ming Lei wrote: > On Thu, Dec 04, 2025 at 02:10:25PM +0100, Christoph Hellwig wrote: >> On Thu, Dec 04, 2025 at 12:09:46PM +0100, Christian König wrote: >>>> I find the naming pretty confusing a well. But what this does is to >>>> tell the file system/driver that it should expect a future >>>> read_iter/write_iter operation that takes data from / puts data into >>>> the dmabuf passed to this operation. >>> >>> That explanation makes much more sense. >>> >>> The remaining question is why does the underlying file system / driver >>> needs to know that it will get addresses from a DMA-buf? >> >> This eventually ends up calling dma_buf_dynamic_attach and provides >> a way to find the dma_buf_attachment later in the I/O path. > > Maybe it can be named as ->dma_buf_attach()? For wiring dma-buf and the > importer side(nvme). Yeah that would make it much more cleaner. Also some higher level documentation would certainly help. > But I am wondering why not make it as one subsystem interface, such as nvme > ioctl, then the whole implementation can be simplified a lot. It is reasonable > because subsystem is exactly the side for consuming/importing the dma-buf. Yeah that it might be better if it's more nvme specific came to me as well. Regards, Christian. > > > Thanks, > Ming >

1 month, 1 week

2
1
0 0

Re: [PATCH] dma-buf: system_heap: account for system heap allocation in memcg

by Christian König

On 12/19/25 16:58, Maxime Ripard wrote: > On Fri, Dec 19, 2025 at 02:50:50PM +0100, Christian König wrote: >> On 12/19/25 11:25, Maxime Ripard wrote: >>> On Mon, Dec 15, 2025 at 03:53:22PM +0100, Christian König wrote: >>>> On 12/15/25 14:59, Maxime Ripard wrote: >> ... >>>>>>> The shared ownership is indeed broken, but it's not more or less broken >>>>>>> than, say, memfd + udmabuf, and I'm sure plenty of others. >>>>>>> >>>>>>> So we really improve the common case, but only make the "advanced" >>>>>>> slightly more broken than it already is. >>>>>>> >>>>>>> Would you disagree? >>>>>> >>>>>> I strongly disagree. As far as I can see there is a huge chance we >>>>>> break existing use cases with that. >>>>> >>>>> Which ones? And what about the ones that are already broken? >>>> >>>> Well everybody that expects that driver resources are *not* accounted to memcg. >>> >>> Which is a thing only because these buffers have never been accounted >>> for in the first place. >> >> Yeah, completely agree. By not accounting it for such a long time we >> ended up with people depending on this behavior. >> >> Not nice, but that's what it is. >> >>> So I guess the conclusion is that we shouldn't >>> even try to do memory accounting, because someone somewhere might not >>> expect that one of its application would take too much RAM in the >>> system? >> >> Well we do need some kind of solution to the problem. Either having >> some setting where you say "This memcg limit is inclusive/exclusive >> device driver allocated memory" or have a completely separate limit >> for device driver allocated memory. > > A device driver memory specific limit sounds like a good idea because it > would make it easier to bridge the gap with dmem. Completely agree, but that approach was rejected by the cgroups people. I mean we can already use udmabuf to allocate memcg accounted system memory which then can be imported into device drivers. So I don't see much reason why we should account dma-buf heaps and driver interfaces to memcg as well, we just need some way to limit them. Regards, Christian. > > Happy holidays, > Maxime

1 month, 1 week

1
0
0 0

Re: [RFC v2 01/11] file: add callback for pre-mapping dmabuf

by Christoph Hellwig

On Tue, Jan 06, 2026 at 07:51:12PM +0000, Pavel Begunkov wrote: >> But I am wondering why not make it as one subsystem interface, such as nvme >> ioctl, then the whole implementation can be simplified a lot. It is reasonable >> because subsystem is exactly the side for consuming/importing the dma-buf. > > It's not an nvme specific interface, and so a file op was much more > convenient. It is the much better abstraction. Also the nvme subsystems is not an actor, and registering things to the subsystems does not work. The nvme controller is the entity that does the dma mapping, and this interface works very well for that.

1 month, 1 week

1
0
0 0

Re: [PATCH 09/12] dt-bindings: media: st: dcmi: add DMA-MDMA chaining properties

by Rob Herring

On Thu, Dec 18, 2025 at 07:44:49PM +0100, Alain Volmat wrote: > Add properties update and new sram property necessary in order > to enable the DMA-MDMA chaining. > > Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> > --- > Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > index 34147127192f..ccaa2d0a2669 100644 > --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > @@ -27,11 +27,14 @@ properties: > - const: mclk > > dmas: > - maxItems: 1 > + minItems: 1 > + maxItems: 2 > > dma-names: > items: > - const: tx > + - const: mdma_tx > + minItems: 1 > > resets: > maxItems: 1 > @@ -40,6 +43,14 @@ properties: > minItems: 1 > maxItems: 2 > > + sram: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: > + phandles to a reserved SRAM region which is used as temporary phandle to... > + storage memory between DMA and MDMA engines. > + The region should be defined as child nodes of the AHB SRAM node > + as per the generic bindings in Documentation/devicetree/bindings/sram/sram.yaml Drop this sentence. Rob

1 month, 2 weeks

1
0
0 0

Re: [PATCH] dma-buf: system_heap: account for system heap allocation in memcg

by T.J. Mercier

On Fri, Dec 19, 2025 at 7:19 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > Hi, > > On Tue, Dec 16, 2025 at 11:06:59AM +0900, T.J. Mercier wrote: > > On Mon, Dec 15, 2025 at 7:51 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > > On Fri, Dec 12, 2025 at 08:25:19AM +0900, T.J. Mercier wrote: > > > > On Fri, Dec 12, 2025 at 4:31 AM Eric Chanudet <echanude(a)redhat.com> wrote: > > > > > > > > > > The system dma-buf heap lets userspace allocate buffers from the page > > > > > allocator. However, these allocations are not accounted for in memcg, > > > > > allowing processes to escape limits that may be configured. > > > > > > > > > > Pass the __GFP_ACCOUNT for our allocations to account them into memcg. > > > > > > > > We had a discussion just last night in the MM track at LPC about how > > > > shared memory accounted in memcg is pretty broken. Without a way to > > > > identify (and possibly transfer) ownership of a shared buffer, this > > > > makes the accounting of shared memory, and zombie memcg problems > > > > worse. :\ > > > > > > Are there notes or a report from that discussion anywhere? > > > > The LPC vids haven't been clipped yet, and actually I can't even find > > the recorded full live stream from Hall A2 on the first day. So I > > don't think there's anything to look at, but I bet there's probably > > nothing there you don't already know. > > Ack, thanks for looking at it still :) > > > > The way I see it, the dma-buf heaps *trivial* case is non-existent at > > > the moment and that's definitely broken. Any application can bypass its > > > cgroups limits trivially, and that's a pretty big hole in the system. > > > > Agree, but if we only charge the first allocator then limits can still > > easily be bypassed assuming an app can cause an allocation outside of > > its cgroup tree. > > > > I'm not sure using static memcg limits where a significant portion of > > the memory can be shared is really feasible. Even with just pagecache > > being charged to memcgs, we're having trouble defining a static memcg > > limit that is really useful since it has to be high enough to > > accomodate occasional spikes due to shared memory that might or might > > not be charged (since it can only be charged to one memcg - it may be > > spread around or it may all get charged to one memcg). So excessive > > anonymous use has to get really bad before it gets punished. > > > > What I've been hearing lately is that folks are polling memory.stat or > > PSI or other metrics and using that to take actions (memory.reclaim / > > killing / adjust memory.high) at runtime rather than relying on > > memory.high/max behavior with a static limit. > > But that's only side effects of a buffer being shared, right? (which, > for a buffer sharing mechanism is still pretty important, but still) > > > > The shared ownership is indeed broken, but it's not more or less broken > > > than, say, memfd + udmabuf, and I'm sure plenty of others. > > > > One thing that's worse about system heap buffers is that unlike memfd > > the memory isn't reclaimable. So without killing all users there's > > currently no way to deal with the zombie issue. Harry's proposing > > reparenting, but I don't think our current interfaces support that > > because we'd have to mess with the page structs behind system heap > > dmabufs to change the memcg during reparenting. > > > > Ah... but udmabuf pins the memfd pages, so you're right that memfd + > > udmabuf isn't worse. > > > > > So we really improve the common case, but only make the "advanced" > > > slightly more broken than it already is. > > > > > > Would you disagree? > > > > I think memcg limits in this case just wouldn't be usable because of > > what I mentioned above. In our common case the allocator is in a > > different cgroup tree than the real users of the buffer. > > So, my issue with this is that we want to fix not only dma-buf itself, > but every device buffer allocation mechanism, so also v4l2, drm, etc. > > So we'll need a lot of infrastructure and rework outside of dma-buf to > get there, and figuring out how to solve the shared buffer accounting is > indeed one of them, but was so far considered kind the thing to do last > last time we discussed. > > What I get from that discussion is that we now consider it a > prerequisite, and given how that topic has been advancing so far, one > that would take a couple of years at best to materialize into something > useful and upstream. > > Thus, it blocks all the work around it for years. > > Would you be open to merging patches that work on it but only enabled > through a kernel parameter for example (and possibly taint the kernel?)? > That would allow to work towards that goal while not being blocked by > the shared buffer accounting, and not affecting the general case either. > > Maxime Hi Maxime, A kernel param or a CONFIG sound like a good compromise to allow work to progress. I'd be happy to add my R-B to that.

1 month, 3 weeks

1
0
0 0

Re: [PATCH 01/12] media: stm32: dcmi: Switch from __maybe_unused to pm_sleep_ptr()

by kernel test robot

Hi Alain, kernel test robot noticed the following build warnings: [auto build test WARNING on atorgue-stm32/stm32-next] [also build test WARNING on robh/for-next linus/master v6.19-rc1 next-20251219] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Alain-Volmat/media-stm32-dcm… base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next patch link: https://lore.kernel.org/r/20251218-stm32-dcmi-dma-chaining-v1-1-39948ca6cbf… patch subject: [PATCH 01/12] media: stm32: dcmi: Switch from __maybe_unused to pm_sleep_ptr() config: arc-allyesconfig (https://download.01.org/0day-ci/archive/20251221/202512210044.xNNW6QJZ-lkp@…) compiler: arc-linux-gcc (GCC) 15.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251221/202512210044.xNNW6QJZ-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512210044.xNNW6QJZ-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/media/platform/st/stm32/stm32-dcmi.c:2127:12: warning: 'dcmi_resume' defined but not used [-Wunused-function] 2127 | static int dcmi_resume(struct device *dev) | ^~~~~~~~~~~ >> drivers/media/platform/st/stm32/stm32-dcmi.c:2116:12: warning: 'dcmi_suspend' defined but not used [-Wunused-function] 2116 | static int dcmi_suspend(struct device *dev) | ^~~~~~~~~~~~ vim +/dcmi_resume +2127 drivers/media/platform/st/stm32/stm32-dcmi.c 2115 > 2116 static int dcmi_suspend(struct device *dev) 2117 { 2118 /* disable clock */ 2119 pm_runtime_force_suspend(dev); 2120 2121 /* change pinctrl state */ 2122 pinctrl_pm_select_sleep_state(dev); 2123 2124 return 0; 2125 } 2126 > 2127 static int dcmi_resume(struct device *dev) 2128 { 2129 /* restore pinctl default state */ 2130 pinctrl_pm_select_default_state(dev); 2131 2132 /* clock enable */ 2133 pm_runtime_force_resume(dev); 2134 2135 return 0; 2136 } 2137 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 month, 3 weeks

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig