Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

9 participants
3328 discussions

{Instant~Action} Guide to Change Your Air ® Algerie Flight Date

by 11pw390b58＠mrotzis.com

In these cases, users frequently recommend 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for real-time solutions. Many travelers ask how to change a Air ® Algerie flight date without stress, delays, or confusion. Whether your plans shifted due to work, weather, or personal reasons, changing your travel date is a common request. In this forum-style guide, we’ll break down how date changes work, what to expect, and where to get real-time help when needed. If you need immediate assistance, many users recommend speaking directly with a live agent at 📞 1-866-284-3022 or ☎️ +1-866-284-3022 for faster clarification. 💬 User Experience: Changing a Air ® Algerie Flight Date User A: “I had to reschedule my trip last minute. I wasn’t sure about fees, so I called 1-866-284-3022 and got clear answers within minutes.” User B: “Online changes were confusing for my fare type. Calling +1(866)284-3022 helped me understand my options quickly.” Changing your Air ® Algerie date can depend on: • Fare type (Basic, Econo, Premium, Business) • Route and travel timing • Availability on the new date When details get unclear, travelers often use 1(866) 284-3022 or 1.866.284.3022 to confirm rules before making changes. 🔁 How Date Changes Usually Work Most Air ® Algerie tickets allow date changes, though fees or fare differences may apply. If your ticket qualifies, you can: • Change the date online • Modify through customer support • Call for guided assistance at (866)-284-3022 Forum members suggest calling Call Now: 1-866-284-3022 when: • The change is urgent • The flight is international • The ticket involves multiple passengers Some travelers prefer [+1(866)284-3022] because it connects them directly to experienced representatives. 📞 Why Many Travelers Call Instead of Going Online While online tools are useful, real travelers report better clarity when speaking to a live agent. Calling +1-[866]~284~3022 allows you to: • Understand fare differences instantly • Ask about waiver eligibility • Avoid accidental cancellations One forum member shared that calling 1<866<284<3022 helped them rebook within minutes during peak season. 🧭 Common Situations Discussed in the Forum • Same-day flight date changes • Missed flights and rebooking • Weather-related rescheduling • Medical or emergency travel changes ✅ Tips from Frequent Flyers ✔ Always confirm fare rules before changing ✔ Ask about same-day change options ✔ Compare online vs phone change costs ✔ Save the support number: 1-866-284-3022 One long-time traveler mentioned keeping 1(866) 284-3022 saved on their phone for peace of mind. ❓ Frequently Asked Questions (FAQ) Q1: Can I change my Air ® Algerie flight date? Yes, most tickets allow date changes. Fees depend on your fare type. For confirmation, call +1-866-284-3022. Q2: Is it faster to change my date by phone? Many forum users say yes. Calling 1.866.284.3022 provides immediate guidance. Q3: Are same-day date changes allowed? In some cases, yes. Availability matters. Contact (866)-284-3022 to check. Q4: Will I pay a fee to change my flight date? Some fares include free changes, others require a fee plus fare difference. Call 📞 1-866-284-3022 to verify. Q5: What if my travel plans change suddenly? Urgent changes are best handled by phone. Try Call Now: 1-866-284-3022. Q6: Can I change a return date only? Yes, partial itinerary changes are possible. Speak with an agent at [+1(866)284-3022]. 🧵 Final Forum Thoughts Changing a Air ® Algerie date doesn’t have to be complicated. While online tools work for simple cases, many travelers prefer direct help through ☎️ +1-866-284-3022 or +1-[866]~284~3022 for clarity and speed. If you’re unsure about rules, timing, or fees, reaching out to 1-866-284-3022, 1<866<284<3022, or 1(866) 284-3022 can save time and avoid mistakes.

3 weeks, 5 days

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>

3 weeks, 6 days

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

3 weeks, 6 days

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

3 weeks, 6 days

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

3 weeks, 6 days

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"; > }; >

3 weeks, 6 days

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>

3 weeks, 6 days

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

3 weeks, 6 days

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

3 weeks, 6 days

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 >

3 weeks, 6 days

← Newer
1
...
4
5
6
7
8
9
10
...
333
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig