* [PATCH 2/8] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Yong Wu, Yunfei Dong,
Florent Tomasin, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
From: John Stultz <jstultz@google.com>
This allows drivers who don't want to create their own
DMA-BUF exporter to be able to allocate DMA-BUFs directly
from existing DMA-BUF Heaps.
There is some concern that the premise of DMA-BUF heaps is
that userland knows better about what type of heap memory
is needed for a pipeline, so it would likely be best for
drivers to import and fill DMA-BUFs allocated by userland
instead of allocating one themselves, but this is still
up for debate.
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
[Yong: Fix the checkpatch alignment warning]
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
[Florent: Rebase]
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
[Ketil: Rebase]
---
drivers/dma-buf/dma-heap.c | 80 ++++++++++++++++++++++++++++++--------
include/linux/dma-heap.h | 6 +++
2 files changed, 70 insertions(+), 16 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 9fd365ddbd517..854d40d789ff2 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -57,12 +57,24 @@ module_param(mem_accounting, bool, 0444);
MODULE_PARM_DESC(mem_accounting,
"Enable cgroup-based memory accounting for dma-buf heap allocations (default=false).");
-static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
- u32 fd_flags,
- u64 heap_flags)
+/**
+ * dma_heap_buffer_alloc - Allocate dma-buf from a dma_heap
+ * @heap: DMA-Heap to allocate from
+ * @len: size to allocate in bytes
+ * @fd_flags: flags to set on returned dma-buf fd
+ * @heap_flags: flags to pass to the dma heap
+ *
+ * This is for internal dma-buf allocations only. Free returned buffers with dma_buf_put().
+ */
+struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
+ u32 fd_flags,
+ u64 heap_flags)
{
- struct dma_buf *dmabuf;
- int fd;
+ if (fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
+ return ERR_PTR(-EINVAL);
+
+ if (heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
+ return ERR_PTR(-EINVAL);
/*
* Allocations from all heaps have to begin
@@ -70,9 +82,20 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
*/
len = PAGE_ALIGN(len);
if (!len)
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
+
+ return heap->ops->allocate(heap, len, fd_flags, heap_flags);
+}
+EXPORT_SYMBOL_NS_GPL(dma_heap_buffer_alloc, "DMA_BUF_HEAP");
- dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
+static int dma_heap_bufferfd_alloc(struct dma_heap *heap, size_t len,
+ u32 fd_flags,
+ u64 heap_flags)
+{
+ struct dma_buf *dmabuf;
+ int fd;
+
+ dmabuf = dma_heap_buffer_alloc(heap, len, fd_flags, heap_flags);
if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);
@@ -110,15 +133,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
if (heap_allocation->fd)
return -EINVAL;
- if (heap_allocation->fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
- return -EINVAL;
-
- if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
- return -EINVAL;
-
- fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
- heap_allocation->fd_flags,
- heap_allocation->heap_flags);
+ fd = dma_heap_bufferfd_alloc(heap, heap_allocation->len,
+ heap_allocation->fd_flags,
+ heap_allocation->heap_flags);
if (fd < 0)
return fd;
@@ -317,6 +334,36 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
}
EXPORT_SYMBOL_NS_GPL(dma_heap_add, "DMA_BUF_HEAP");
+/**
+ * dma_heap_find - get the heap registered with the specified name
+ * @name: Name of the DMA-Heap to find
+ *
+ * Returns:
+ * The DMA-Heap with the provided name.
+ *
+ * NOTE: DMA-Heaps returned from this function MUST be released using
+ * dma_heap_put() when the user is done to enable the heap to be unloaded.
+ */
+struct dma_heap *dma_heap_find(const char *name)
+{
+ struct dma_heap *h;
+
+ mutex_lock(&heap_list_lock);
+ list_for_each_entry(h, &heap_list, list) {
+ if (!kref_get_unless_zero(&h->refcount))
+ continue;
+
+ if (!strcmp(h->name, name)) {
+ mutex_unlock(&heap_list_lock);
+ return h;
+ }
+ dma_heap_put(h);
+ }
+ mutex_unlock(&heap_list_lock);
+ return NULL;
+}
+EXPORT_SYMBOL_NS_GPL(dma_heap_find, "DMA_BUF_HEAP");
+
static void dma_heap_release(struct kref *ref)
{
struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
@@ -341,6 +388,7 @@ void dma_heap_put(struct dma_heap *heap)
{
kref_put(&heap->refcount, dma_heap_release);
}
+EXPORT_SYMBOL_NS_GPL(dma_heap_put, "DMA_BUF_HEAP");
static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
{
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index ff57741700f5f..c3351f8a1f8cf 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -46,8 +46,14 @@ const char *dma_heap_get_name(struct dma_heap *heap);
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
+struct dma_heap *dma_heap_find(const char *name);
+
void dma_heap_put(struct dma_heap *heap);
+struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
+ u32 fd_flags,
+ u64 heap_flags);
+
extern bool mem_accounting;
#endif /* _DMA_HEAPS_H */
--
2.43.0
^ permalink raw reply related
* [PATCH 3/8] drm/panthor: De-duplicate FW memory section sync
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
Handle the sync to device of FW memory sections inside
panthor_fw_init_section_mem() so that the callers do not have to.
This small improvement is also critical for protected FW sections,
so we avoid issuing memory transactions to protected memory from
CPU running in normal mode.
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
---
drivers/gpu/drm/panthor/panthor_fw.c | 22 ++++++----------------
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
index be0da5b1f3abf..0d07a133dc3af 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.c
+++ b/drivers/gpu/drm/panthor/panthor_fw.c
@@ -446,6 +446,7 @@ static void panthor_fw_init_section_mem(struct panthor_device *ptdev,
struct panthor_fw_section *section)
{
bool was_mapped = !!section->mem->kmap;
+ struct sg_table *sgt;
int ret;
if (!section->data.size &&
@@ -464,6 +465,11 @@ static void panthor_fw_init_section_mem(struct panthor_device *ptdev,
if (!was_mapped)
panthor_kernel_bo_vunmap(section->mem);
+
+ /* An sgt should have been requested when the kernel BO was GPU-mapped. */
+ sgt = to_panthor_bo(section->mem->obj)->dmap.sgt;
+ if (!drm_WARN_ON_ONCE(&ptdev->base, !sgt))
+ dma_sync_sgtable_for_device(ptdev->base.dev, sgt, DMA_TO_DEVICE);
}
/**
@@ -626,7 +632,6 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
section_size = hdr.va.end - hdr.va.start;
if (section_size) {
u32 cache_mode = hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_CACHE_MODE_MASK;
- struct panthor_gem_object *bo;
u32 vm_map_flags = 0;
u64 va = hdr.va.start;
@@ -663,14 +668,6 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
}
panthor_fw_init_section_mem(ptdev, section);
-
- bo = to_panthor_bo(section->mem->obj);
-
- /* An sgt should have been requested when the kernel BO was GPU-mapped. */
- if (drm_WARN_ON_ONCE(&ptdev->base, !bo->dmap.sgt))
- return -EINVAL;
-
- dma_sync_sgtable_for_device(ptdev->base.dev, bo->dmap.sgt, DMA_TO_DEVICE);
}
if (hdr.va.start == CSF_MCU_SHARED_REGION_START)
@@ -724,17 +721,10 @@ panthor_reload_fw_sections(struct panthor_device *ptdev, bool full_reload)
struct panthor_fw_section *section;
list_for_each_entry(section, &ptdev->fw->sections, node) {
- struct sg_table *sgt;
-
if (!full_reload && !(section->flags & CSF_FW_BINARY_IFACE_ENTRY_WR))
continue;
panthor_fw_init_section_mem(ptdev, section);
-
- /* An sgt should have been requested when the kernel BO was GPU-mapped. */
- sgt = to_panthor_bo(section->mem->obj)->dmap.sgt;
- if (!drm_WARN_ON_ONCE(&ptdev->base, !sgt))
- dma_sync_sgtable_for_device(ptdev->base.dev, sgt, DMA_TO_DEVICE);
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
From: Florent Tomasin <florent.tomasin@arm.com>
This patch allows Panthor to allocate buffer objects from a
protected heap. The Panthor driver should be seen as a consumer
of the heap and not an exporter.
Protected memory buffers needed by the Panthor driver:
- On CSF FW load, the Panthor driver must allocate a protected
buffer object to hold data to use by the FW when in protected
mode. This protected buffer object is owned by the device
and does not belong to a process.
- On CSG creation, the Panthor driver must allocate a protected
suspend buffer object for the FW to store data when suspending
the CSG while in protected mode. The kernel owns this allocation
and does not allow user space mapping. The format of the data
in this buffer is only known by the FW and does not need to be
shared with other entities.
The driver will retrieve the protected heap using the name of the
heap provided to the driver as module parameter.
If the heap is not yet available, the panthor driver will defer
the probe until created. It is an integration error to provide
a heap name that does not exist or is never created.
Panthor is calling the DMA heap allocation function
and obtains a DMA buffer from it. This buffer is then
registered to GEM and imported.
Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
Co-developed-by: Ketil Johnsen <ketil.johnsen@arm.com>
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
---
Documentation/gpu/panthor.rst | 47 +++++++++++++++
drivers/gpu/drm/panthor/Kconfig | 1 +
drivers/gpu/drm/panthor/panthor_device.c | 28 ++++++++-
drivers/gpu/drm/panthor/panthor_device.h | 6 ++
drivers/gpu/drm/panthor/panthor_fw.c | 29 ++++++++-
drivers/gpu/drm/panthor/panthor_fw.h | 2 +
drivers/gpu/drm/panthor/panthor_gem.c | 77 ++++++++++++++++++++++--
drivers/gpu/drm/panthor/panthor_gem.h | 16 ++++-
drivers/gpu/drm/panthor/panthor_heap.c | 2 +
drivers/gpu/drm/panthor/panthor_sched.c | 11 +++-
10 files changed, 208 insertions(+), 11 deletions(-)
diff --git a/Documentation/gpu/panthor.rst b/Documentation/gpu/panthor.rst
index 7a841741278fb..be20eadea6dd5 100644
--- a/Documentation/gpu/panthor.rst
+++ b/Documentation/gpu/panthor.rst
@@ -54,3 +54,50 @@ sync object arrays and heap chunks. Because they are all allocated and pinned
at creation time, only `panthor-resident-memory` is necessary to tell us their
size. `panthor-active-memory` shows the size of kernel BO's associated with
VM's and groups currently being scheduled for execution by the GPU.
+
+Panthor Protected Memory Integration
+=====================================
+
+Panthor requires the platform to provide a protected DMA HEAP.
+This DMA heap must be identifiable via a string name.
+The name is defined by the system integrator, it could be hard coded
+in the heap driver, defined by a module parameter of the heap driver
+or else.
+
+.. code-block:: none
+
+ User
+ ┌─────────────────────────────┐
+ | Application |
+ └─────────────▲───────────────┘
+ | | |
+ | DMA-BUF | | Protected
+ | | | Job Submission
+ --------|---------|----------|---------
+ Kernel | | |
+ | | |
+ | | DMA-BUF |
+ ┌───────▼─────────────┐ ┌─▼───────┐
+ | DMA PROTECTED HEAP |◄───| Panthor |
+ | (Vendor specific) | | |
+ └─────────────────────┘ └─────────┘
+ | |
+ --------|--------------------|---------
+ HW | |
+ | |
+ ┌───────▼───────────────┐ ┌─▼───┐
+ | Trusted FW | | |
+ | Protected Memory ◄──► GPU |
+ └───────────────────────┘ └─────┘
+
+To configure Panthor to use the protected memory heap, pass the protected memory
+heap string name as module parameter of the Panthor module.
+
+Example:
+
+ .. code-block:: shell
+
+ insmod panthor.ko protected_heap_name=“vendor_protected_heap"
+
+If `protected_heap_name` module parameter is not provided, Panthor will not support
+protected job execution.
diff --git a/drivers/gpu/drm/panthor/Kconfig b/drivers/gpu/drm/panthor/Kconfig
index 911e7f4810c39..fb0bad9a0fd2b 100644
--- a/drivers/gpu/drm/panthor/Kconfig
+++ b/drivers/gpu/drm/panthor/Kconfig
@@ -7,6 +7,7 @@ config DRM_PANTHOR
depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE
depends on MMU
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DMABUF_HEAPS
select DRM_EXEC
select DRM_GPUVM
select DRM_SCHED
diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
index bc62a498a8a84..3a5cdfa99e5fe 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -5,7 +5,9 @@
/* Copyright 2025 ARM Limited. All rights reserved. */
#include <linux/clk.h>
+#include <linux/dma-heap.h>
#include <linux/mm.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_domain.h>
#include <linux/pm_runtime.h>
@@ -27,6 +29,10 @@
#include "panthor_regs.h"
#include "panthor_sched.h"
+MODULE_PARM_DESC(protected_heap_name, "DMA heap name, from which to allocate protected buffers");
+static char *protected_heap_name;
+module_param(protected_heap_name, charp, 0444);
+
static int panthor_gpu_coherency_init(struct panthor_device *ptdev)
{
BUILD_BUG_ON(GPU_COHERENCY_NONE != DRM_PANTHOR_GPU_COHERENCY_NONE);
@@ -127,6 +133,9 @@ void panthor_device_unplug(struct panthor_device *ptdev)
panthor_gpu_unplug(ptdev);
panthor_pwr_unplug(ptdev);
+ if (ptdev->protm.heap)
+ dma_heap_put(ptdev->protm.heap);
+
pm_runtime_dont_use_autosuspend(ptdev->base.dev);
pm_runtime_put_sync_suspend(ptdev->base.dev);
@@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
return ret;
}
+ /* If a protected heap name is specified but not found, defer the probe until created */
+ if (protected_heap_name && strlen(protected_heap_name)) {
+ ptdev->protm.heap = dma_heap_find(protected_heap_name);
+ if (!ptdev->protm.heap) {
+ drm_warn(&ptdev->base,
+ "Protected heap \'%s\' not (yet) available - deferring probe",
+ protected_heap_name);
+ ret = -EPROBE_DEFER;
+ goto err_rpm_put;
+ }
+ }
+
ret = panthor_hw_init(ptdev);
if (ret)
- goto err_rpm_put;
+ goto err_dma_heap_put;
ret = panthor_pwr_init(ptdev);
if (ret)
@@ -343,6 +364,11 @@ int panthor_device_init(struct panthor_device *ptdev)
err_rpm_put:
pm_runtime_put_sync_suspend(ptdev->base.dev);
+
+err_dma_heap_put:
+ if (ptdev->protm.heap)
+ dma_heap_put(ptdev->protm.heap);
+
return ret;
}
diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
index 5cba272f9b4de..d51fec97fc5fa 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -7,6 +7,7 @@
#define __PANTHOR_DEVICE_H__
#include <linux/atomic.h>
+#include <linux/dma-heap.h>
#include <linux/io-pgtable.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
@@ -329,6 +330,11 @@ struct panthor_device {
struct list_head node;
} gems;
#endif
+ /** @protm: Protected mode related data. */
+ struct {
+ /** @heap: Pointer to the protected heap */
+ struct dma_heap *heap;
+ } protm;
};
struct panthor_gpu_usage {
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
index 0d07a133dc3af..1aba29b9779b6 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.c
+++ b/drivers/gpu/drm/panthor/panthor_fw.c
@@ -500,6 +500,7 @@ panthor_fw_alloc_queue_iface_mem(struct panthor_device *ptdev,
mem = panthor_kernel_bo_create(ptdev, ptdev->fw->vm, SZ_8K,
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
PANTHOR_VM_KERNEL_AUTO_VA,
@@ -534,6 +535,26 @@ panthor_fw_alloc_suspend_buf_mem(struct panthor_device *ptdev, size_t size)
{
return panthor_kernel_bo_create(ptdev, panthor_fw_vm(ptdev), size,
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
+ DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC,
+ PANTHOR_VM_KERNEL_AUTO_VA,
+ "suspend_buf");
+}
+
+/**
+ * panthor_fw_alloc_protm_suspend_buf_mem() - Allocate a protm suspend buffer
+ * for a command stream group.
+ * @ptdev: Device.
+ * @size: Size of the protm suspend buffer.
+ *
+ * Return: A valid pointer in case of success, an ERR_PTR() otherwise.
+ */
+struct panthor_kernel_bo *
+panthor_fw_alloc_protm_suspend_buf_mem(struct panthor_device *ptdev, size_t size)
+{
+ return panthor_kernel_bo_create(ptdev, panthor_fw_vm(ptdev), size,
+ DRM_PANTHOR_BO_NO_MMAP,
+ DRM_PANTHOR_KBO_PROTECTED_HEAP,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC,
PANTHOR_VM_KERNEL_AUTO_VA,
"FW suspend buffer");
@@ -547,6 +568,7 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
ssize_t vm_pgsz = panthor_vm_page_size(ptdev->fw->vm);
struct panthor_fw_binary_section_entry_hdr hdr;
struct panthor_fw_section *section;
+ u32 kbo_flags = 0;
u32 section_size;
u32 name_len;
int ret;
@@ -585,10 +607,13 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
return -EINVAL;
}
- if (hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_PROT) {
+ if ((hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_PROT) && !ptdev->protm.heap) {
drm_warn(&ptdev->base,
"Firmware protected mode entry is not supported, ignoring");
return 0;
+ } else if ((hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_PROT) && ptdev->protm.heap) {
+ drm_info(&ptdev->base, "Firmware protected mode entry supported");
+ kbo_flags = DRM_PANTHOR_KBO_PROTECTED_HEAP;
}
if (hdr.va.start == CSF_MCU_SHARED_REGION_START &&
@@ -653,7 +678,7 @@ static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
section->mem = panthor_kernel_bo_create(ptdev, panthor_fw_vm(ptdev),
section_size,
- DRM_PANTHOR_BO_NO_MMAP,
+ DRM_PANTHOR_BO_NO_MMAP, kbo_flags,
vm_map_flags, va, "FW section");
if (IS_ERR(section->mem))
return PTR_ERR(section->mem);
diff --git a/drivers/gpu/drm/panthor/panthor_fw.h b/drivers/gpu/drm/panthor/panthor_fw.h
index fbdc21469ba32..0cf3761abf789 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.h
+++ b/drivers/gpu/drm/panthor/panthor_fw.h
@@ -509,6 +509,8 @@ panthor_fw_alloc_queue_iface_mem(struct panthor_device *ptdev,
u32 *input_fw_va, u32 *output_fw_va);
struct panthor_kernel_bo *
panthor_fw_alloc_suspend_buf_mem(struct panthor_device *ptdev, size_t size);
+struct panthor_kernel_bo *
+panthor_fw_alloc_protm_suspend_buf_mem(struct panthor_device *ptdev, size_t size);
struct panthor_vm *panthor_fw_vm(struct panthor_device *ptdev);
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
index 13295d7a593df..08fe4a5e43817 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.c
+++ b/drivers/gpu/drm/panthor/panthor_gem.c
@@ -20,12 +20,17 @@
#include <drm/drm_print.h>
#include <drm/panthor_drm.h>
+#include <uapi/linux/dma-heap.h>
+
#include "panthor_device.h"
#include "panthor_drv.h"
#include "panthor_fw.h"
#include "panthor_gem.h"
#include "panthor_mmu.h"
+MODULE_IMPORT_NS("DMA_BUF");
+MODULE_IMPORT_NS("DMA_BUF_HEAP");
+
void panthor_gem_init(struct panthor_device *ptdev)
{
int err;
@@ -466,7 +471,6 @@ static void panthor_gem_free_object(struct drm_gem_object *obj)
}
drm_gem_object_release(obj);
-
kfree(bo);
drm_gem_object_put(vm_root_gem);
}
@@ -1026,6 +1030,7 @@ panthor_gem_create(struct drm_device *dev, size_t size, uint32_t flags,
}
panthor_gem_debugfs_set_usage_flags(bo, usage_flags);
+
return bo;
err_put:
@@ -1033,6 +1038,54 @@ panthor_gem_create(struct drm_device *dev, size_t size, uint32_t flags,
return ERR_PTR(ret);
}
+static struct panthor_gem_object *
+panthor_gem_create_protected(struct panthor_device *ptdev, size_t size,
+ uint32_t flags, struct panthor_vm *exclusive_vm,
+ u32 usage_flags)
+{
+ struct dma_buf *dma_bo = NULL;
+ struct drm_gem_object *gem_obj;
+ struct panthor_gem_object *bo;
+ int ret;
+
+ if (!ptdev->protm.heap)
+ return ERR_PTR(-EINVAL);
+
+ if (flags != DRM_PANTHOR_BO_NO_MMAP)
+ return ERR_PTR(-EINVAL);
+
+ if (!exclusive_vm)
+ return ERR_PTR(-EINVAL);
+
+ dma_bo = dma_heap_buffer_alloc(ptdev->protm.heap, size, DMA_HEAP_VALID_FD_FLAGS,
+ DMA_HEAP_VALID_HEAP_FLAGS);
+ if (IS_ERR(dma_bo))
+ return ERR_PTR(PTR_ERR(dma_bo));
+
+ gem_obj = drm_gem_prime_import(&ptdev->base, dma_bo);
+ if (IS_ERR(gem_obj)) {
+ ret = PTR_ERR(gem_obj);
+ goto err_free_dma_bo;
+ }
+
+ bo = to_panthor_bo(gem_obj);
+ bo->flags = flags;
+
+ panthor_gem_debugfs_set_usage_flags(bo, usage_flags);
+
+ bo->exclusive_vm_root_gem = panthor_vm_root_gem(exclusive_vm);
+ drm_gem_object_get(bo->exclusive_vm_root_gem);
+ bo->base.resv = bo->exclusive_vm_root_gem->resv;
+
+ return bo;
+
+err_free_dma_bo:
+ if (dma_bo)
+ dma_buf_put(dma_bo);
+
+ return ERR_PTR(ret);
+}
+
struct drm_gem_object *
panthor_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
@@ -1242,12 +1295,17 @@ void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo)
{
struct panthor_device *ptdev;
struct panthor_vm *vm;
+ struct dma_buf *dma_bo = NULL;
if (IS_ERR_OR_NULL(bo))
return;
ptdev = container_of(bo->obj->dev, struct panthor_device, base);
vm = bo->vm;
+
+ if (bo->flags & DRM_PANTHOR_KBO_PROTECTED_HEAP)
+ dma_bo = bo->obj->import_attach->dmabuf;
+
panthor_kernel_bo_vunmap(bo);
drm_WARN_ON(bo->obj->dev,
@@ -1257,6 +1315,10 @@ void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo)
if (vm == panthor_fw_vm(ptdev))
panthor_gem_unpin(to_panthor_bo(bo->obj));
drm_gem_object_put(bo->obj);
+
+ if (dma_bo)
+ dma_buf_put(dma_bo);
+
panthor_vm_put(vm);
kfree(bo);
}
@@ -1267,6 +1329,7 @@ void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo)
* @vm: VM to map the GEM to.
* @size: Size of the buffer object.
* @bo_flags: Combination of drm_panthor_bo_flags flags.
+ * @kbo_flags: Combination of drm_panthor_kbo_flags flags.
* @vm_map_flags: Combination of drm_panthor_vm_bind_op_flags (only those
* that are related to map operations).
* @gpu_va: GPU address assigned when mapping to the VM.
@@ -1278,8 +1341,8 @@ void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo)
*/
struct panthor_kernel_bo *
panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm,
- size_t size, u32 bo_flags, u32 vm_map_flags,
- u64 gpu_va, const char *name)
+ size_t size, u32 bo_flags, u32 kbo_flags,
+ u32 vm_map_flags, u64 gpu_va, const char *name)
{
struct panthor_kernel_bo *kbo;
struct panthor_gem_object *bo;
@@ -1296,13 +1359,19 @@ panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm,
if (vm == panthor_fw_vm(ptdev))
debug_flags |= PANTHOR_DEBUGFS_GEM_USAGE_FLAG_FW_MAPPED;
- bo = panthor_gem_create(&ptdev->base, size, bo_flags, vm, debug_flags);
+ if (kbo_flags & DRM_PANTHOR_KBO_PROTECTED_HEAP) {
+ bo = panthor_gem_create_protected(ptdev, size, bo_flags, vm, debug_flags);
+ } else {
+ bo = panthor_gem_create(&ptdev->base, size, bo_flags, vm, debug_flags);
+ }
+
if (IS_ERR(bo)) {
ret = PTR_ERR(bo);
goto err_free_kbo;
}
kbo->obj = &bo->base;
+ kbo->flags = kbo_flags;
if (vm == panthor_fw_vm(ptdev)) {
ret = panthor_gem_pin(bo);
diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h
index ae0491d0b1216..b0eb5b465981a 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.h
+++ b/drivers/gpu/drm/panthor/panthor_gem.h
@@ -153,6 +153,17 @@ enum panthor_gem_reclaim_state {
PANTHOR_GEM_UNRECLAIMABLE,
};
+/**
+ * enum drm_panthor_kbo_flags - Kernel buffer object flags, passed at creation time
+ */
+enum drm_panthor_kbo_flags {
+ /**
+ * @DRM_PANTHOR_KBO_PROTECTED_HEAP: The buffer object will be allocated
+ * from a DMA-Buf protected heap.
+ */
+ DRM_PANTHOR_KBO_PROTECTED_HEAP = (1 << 0),
+};
+
/**
* struct panthor_gem_object - Driver specific GEM object.
*/
@@ -233,6 +244,9 @@ struct panthor_kernel_bo {
* @kmap: Kernel CPU mapping of @gem.
*/
void *kmap;
+
+ /** @flags: Combination of drm_panthor_kbo_flags flags. */
+ u32 flags;
};
#define to_panthor_bo(obj) container_of_const(obj, struct panthor_gem_object, base)
@@ -310,7 +324,7 @@ panthor_kernel_bo_vunmap(struct panthor_kernel_bo *bo)
struct panthor_kernel_bo *
panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm,
- size_t size, u32 bo_flags, u32 vm_map_flags,
+ size_t size, u32 bo_flags, u32 kbo_flags, u32 vm_map_flags,
u64 gpu_va, const char *name);
void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo);
diff --git a/drivers/gpu/drm/panthor/panthor_heap.c b/drivers/gpu/drm/panthor/panthor_heap.c
index 1ee30dc7066f7..3183c74451fb0 100644
--- a/drivers/gpu/drm/panthor/panthor_heap.c
+++ b/drivers/gpu/drm/panthor/panthor_heap.c
@@ -151,6 +151,7 @@ static int panthor_alloc_heap_chunk(struct panthor_heap_pool *pool,
chunk->bo = panthor_kernel_bo_create(pool->ptdev, pool->vm, heap->chunk_size,
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC,
PANTHOR_VM_KERNEL_AUTO_VA,
"Tiler heap chunk");
@@ -556,6 +557,7 @@ panthor_heap_pool_create(struct panthor_device *ptdev, struct panthor_vm *vm)
pool->gpu_contexts = panthor_kernel_bo_create(ptdev, vm, bosize,
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC,
PANTHOR_VM_KERNEL_AUTO_VA,
"Heap pool");
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index 41d6369fa9c05..5ee386338005c 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -3529,6 +3529,7 @@ group_create_queue(struct panthor_group *group,
queue->ringbuf = panthor_kernel_bo_create(group->ptdev, group->vm,
args->ringbuf_size,
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
PANTHOR_VM_KERNEL_AUTO_VA,
@@ -3560,6 +3561,7 @@ group_create_queue(struct panthor_group *group,
queue->profiling.slot_count *
sizeof(struct panthor_job_profiling_data),
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
PANTHOR_VM_KERNEL_AUTO_VA,
@@ -3618,9 +3620,11 @@ static void add_group_kbo_sizes(struct panthor_device *ptdev,
if (drm_WARN_ON(&ptdev->base, ptdev != group->ptdev))
return;
- group->fdinfo.kbo_sizes += group->suspend_buf->obj->size;
- group->fdinfo.kbo_sizes += group->protm_suspend_buf->obj->size;
group->fdinfo.kbo_sizes += group->syncobjs->obj->size;
+ group->fdinfo.kbo_sizes += group->suspend_buf->obj->size;
+
+ if (group->protm_suspend_buf)
+ group->fdinfo.kbo_sizes += group->protm_suspend_buf->obj->size;
for (i = 0; i < group->queue_count; i++) {
queue = group->queues[i];
@@ -3701,7 +3705,7 @@ int panthor_group_create(struct panthor_file *pfile,
}
suspend_size = csg_iface->control->protm_suspend_size;
- group->protm_suspend_buf = panthor_fw_alloc_suspend_buf_mem(ptdev, suspend_size);
+ group->protm_suspend_buf = panthor_fw_alloc_protm_suspend_buf_mem(ptdev, suspend_size);
if (IS_ERR(group->protm_suspend_buf)) {
ret = PTR_ERR(group->protm_suspend_buf);
group->protm_suspend_buf = NULL;
@@ -3712,6 +3716,7 @@ int panthor_group_create(struct panthor_file *pfile,
group_args->queues.count *
sizeof(struct panthor_syncobj_64b),
DRM_PANTHOR_BO_NO_MMAP,
+ 0,
DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
PANTHOR_VM_KERNEL_AUTO_VA,
--
2.43.0
^ permalink raw reply related
* [PATCH 5/8] drm/panthor: Minor scheduler refactoring
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
From: Florent Tomasin <florent.tomasin@arm.com>
Refactor parts of the group scheduling logic into new helper functions.
This will simplify addition of the protected mode feature.
Remove redundant assignments of csg_slot.
Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
Co-developed-by: Ketil Johnsen <ketil.johnsen@arm.com>
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
---
drivers/gpu/drm/panthor/panthor_sched.c | 135 +++++++++++++++---------
1 file changed, 86 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index 5ee386338005c..987072bd867c4 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -1934,6 +1934,12 @@ static void csgs_upd_ctx_init(struct panthor_csg_slots_upd_ctx *ctx)
memset(ctx, 0, sizeof(*ctx));
}
+static void csgs_upd_ctx_ring_doorbell(struct panthor_csg_slots_upd_ctx *ctx,
+ u32 csg_id)
+{
+ ctx->update_mask |= BIT(csg_id);
+}
+
static void csgs_upd_ctx_queue_reqs(struct panthor_device *ptdev,
struct panthor_csg_slots_upd_ctx *ctx,
u32 csg_id, u32 value, u32 mask)
@@ -1944,7 +1950,8 @@ static void csgs_upd_ctx_queue_reqs(struct panthor_device *ptdev,
ctx->requests[csg_id].value = (ctx->requests[csg_id].value & ~mask) | (value & mask);
ctx->requests[csg_id].mask |= mask;
- ctx->update_mask |= BIT(csg_id);
+
+ csgs_upd_ctx_ring_doorbell(ctx, csg_id);
}
static int csgs_upd_ctx_apply_locked(struct panthor_device *ptdev,
@@ -1961,8 +1968,12 @@ static int csgs_upd_ctx_apply_locked(struct panthor_device *ptdev,
while (update_slots) {
struct panthor_fw_csg_iface *csg_iface;
u32 csg_id = ffs(update_slots) - 1;
+ u32 req_mask = ctx->requests[csg_id].mask;
update_slots &= ~BIT(csg_id);
+ if (!req_mask)
+ continue;
+
csg_iface = panthor_fw_get_csg_iface(ptdev, csg_id);
panthor_fw_update_reqs(csg_iface, req,
ctx->requests[csg_id].value,
@@ -1979,6 +1990,9 @@ static int csgs_upd_ctx_apply_locked(struct panthor_device *ptdev,
int ret;
update_slots &= ~BIT(csg_id);
+ if (!req_mask)
+ continue;
+
csg_iface = panthor_fw_get_csg_iface(ptdev, csg_id);
ret = panthor_fw_csg_wait_acks(ptdev, csg_id, req_mask, &acked, 100);
@@ -2266,12 +2280,76 @@ tick_ctx_cleanup(struct panthor_scheduler *sched,
}
}
+static void
+tick_ctx_evict_group(struct panthor_scheduler *sched,
+ struct panthor_csg_slots_upd_ctx *upd_ctx,
+ struct panthor_group *group)
+{
+ struct panthor_device *ptdev = sched->ptdev;
+
+ if (drm_WARN_ON(&ptdev->base, group->csg_id < 0))
+ return;
+
+ csgs_upd_ctx_queue_reqs(ptdev, upd_ctx, group->csg_id,
+ group_can_run(group) ?
+ CSG_STATE_SUSPEND : CSG_STATE_TERMINATE,
+ CSG_STATE_MASK);
+}
+
+
+static void
+tick_ctx_reschedule_group(struct panthor_scheduler *sched,
+ struct panthor_csg_slots_upd_ctx *upd_ctx,
+ struct panthor_group *group,
+ int new_csg_prio)
+{
+ struct panthor_device *ptdev = sched->ptdev;
+ struct panthor_fw_csg_iface *csg_iface;
+ struct panthor_csg_slot *csg_slot;
+
+ if (group->csg_id < 0)
+ return;
+
+ csg_iface = panthor_fw_get_csg_iface(ptdev, group->csg_id);
+ csg_slot = &sched->csg_slots[group->csg_id];
+
+ if (csg_slot->priority != new_csg_prio) {
+ panthor_fw_update_reqs(csg_iface, endpoint_req,
+ CSG_EP_REQ_PRIORITY(new_csg_prio),
+ CSG_EP_REQ_PRIORITY_MASK);
+ csgs_upd_ctx_queue_reqs(ptdev, upd_ctx, group->csg_id,
+ csg_iface->output->ack ^ CSG_ENDPOINT_CONFIG,
+ CSG_ENDPOINT_CONFIG);
+ }
+}
+
+static void
+tick_ctx_schedule_group(struct panthor_scheduler *sched,
+ struct panthor_sched_tick_ctx *ctx,
+ struct panthor_csg_slots_upd_ctx *upd_ctx,
+ struct panthor_group *group,
+ int csg_id, int csg_prio)
+{
+ struct panthor_device *ptdev = sched->ptdev;
+ struct panthor_fw_csg_iface *csg_iface = panthor_fw_get_csg_iface(ptdev, csg_id);
+
+ group_bind_locked(group, csg_id);
+ csg_slot_prog_locked(ptdev, csg_id, csg_prio);
+
+ csgs_upd_ctx_queue_reqs(ptdev, upd_ctx, csg_id,
+ group->state == PANTHOR_CS_GROUP_SUSPENDED ?
+ CSG_STATE_RESUME : CSG_STATE_START,
+ CSG_STATE_MASK);
+ csgs_upd_ctx_queue_reqs(ptdev, upd_ctx, csg_id,
+ csg_iface->output->ack ^ CSG_ENDPOINT_CONFIG,
+ CSG_ENDPOINT_CONFIG);
+}
+
static void
tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *ctx)
{
struct panthor_group *group, *tmp;
struct panthor_device *ptdev = sched->ptdev;
- struct panthor_csg_slot *csg_slot;
int prio, new_csg_prio = MAX_CSG_PRIO, i;
u32 free_csg_slots = 0;
struct panthor_csg_slots_upd_ctx upd_ctx;
@@ -2282,42 +2360,12 @@ tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *c
for (prio = PANTHOR_CSG_PRIORITY_COUNT - 1; prio >= 0; prio--) {
/* Suspend or terminate evicted groups. */
list_for_each_entry(group, &ctx->old_groups[prio], run_node) {
- bool term = !group_can_run(group);
- int csg_id = group->csg_id;
-
- if (drm_WARN_ON(&ptdev->base, csg_id < 0))
- continue;
-
- csg_slot = &sched->csg_slots[csg_id];
- csgs_upd_ctx_queue_reqs(ptdev, &upd_ctx, csg_id,
- term ? CSG_STATE_TERMINATE : CSG_STATE_SUSPEND,
- CSG_STATE_MASK);
+ tick_ctx_evict_group(sched, &upd_ctx, group);
}
/* Update priorities on already running groups. */
list_for_each_entry(group, &ctx->groups[prio], run_node) {
- struct panthor_fw_csg_iface *csg_iface;
- int csg_id = group->csg_id;
-
- if (csg_id < 0) {
- new_csg_prio--;
- continue;
- }
-
- csg_slot = &sched->csg_slots[csg_id];
- csg_iface = panthor_fw_get_csg_iface(ptdev, csg_id);
- if (csg_slot->priority == new_csg_prio) {
- new_csg_prio--;
- continue;
- }
-
- panthor_fw_csg_endpoint_req_update(ptdev, csg_iface,
- CSG_EP_REQ_PRIORITY(new_csg_prio),
- CSG_EP_REQ_PRIORITY_MASK);
- csgs_upd_ctx_queue_reqs(ptdev, &upd_ctx, csg_id,
- csg_iface->output->ack ^ CSG_ENDPOINT_CONFIG,
- CSG_ENDPOINT_CONFIG);
- new_csg_prio--;
+ tick_ctx_reschedule_group(sched, &upd_ctx, group, new_csg_prio--);
}
}
@@ -2354,28 +2402,17 @@ tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *c
for (prio = PANTHOR_CSG_PRIORITY_COUNT - 1; prio >= 0; prio--) {
list_for_each_entry(group, &ctx->groups[prio], run_node) {
int csg_id = group->csg_id;
- struct panthor_fw_csg_iface *csg_iface;
+ int csg_prio = new_csg_prio--;
- if (csg_id >= 0) {
- new_csg_prio--;
+ if (csg_id >= 0)
continue;
- }
csg_id = ffs(free_csg_slots) - 1;
if (drm_WARN_ON(&ptdev->base, csg_id < 0))
break;
- csg_iface = panthor_fw_get_csg_iface(ptdev, csg_id);
- csg_slot = &sched->csg_slots[csg_id];
- group_bind_locked(group, csg_id);
- csg_slot_prog_locked(ptdev, csg_id, new_csg_prio--);
- csgs_upd_ctx_queue_reqs(ptdev, &upd_ctx, csg_id,
- group->state == PANTHOR_CS_GROUP_SUSPENDED ?
- CSG_STATE_RESUME : CSG_STATE_START,
- CSG_STATE_MASK);
- csgs_upd_ctx_queue_reqs(ptdev, &upd_ctx, csg_id,
- csg_iface->output->ack ^ CSG_ENDPOINT_CONFIG,
- CSG_ENDPOINT_CONFIG);
+ tick_ctx_schedule_group(sched, ctx, &upd_ctx, group, csg_id, csg_prio);
+
free_csg_slots &= ~BIT(csg_id);
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH 6/8] drm/panthor: Explicit expansion of locked VM region
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
Currently the panthor_vm_lock_region() function will implicitly expand
an already locked VM region. This can be problematic because the caller
do not reliably know if it needs to call panthor_vm_unlock_region()
or not.
Worth noting, there is currently no known issues with this as the code
is written today.
This change introduces panthor_vm_expand_region() which will only work
if there is already a locked VM region. This again means that the
original lock and unlock functions can work as a pair. This pairing is
needed for subsequent protected memory changes.
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
---
drivers/gpu/drm/panthor/panthor_mmu.c | 69 +++++++++++++++++++--------
1 file changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index fc930ee158a52..07f54176ec1bf 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -1701,15 +1701,36 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
struct panthor_device *ptdev = vm->ptdev;
int ret = 0;
- /* sm_step_remap() can call panthor_vm_lock_region() to account for
- * the wider unmap needed when doing a partial huge page unamp. We
- * need to ignore the lock if it's already part of the locked region.
- */
- if (start >= vm->locked_region.start &&
- start + size <= vm->locked_region.start + vm->locked_region.size)
- return 0;
+ if (drm_WARN_ON(&ptdev->base, vm->locked_region.size))
+ return -EINVAL;
+
+ mutex_lock(&ptdev->mmu->as.slots_lock);
+ if (vm->as.id >= 0 && size) {
+ /* Lock the region that needs to be updated */
+ gpu_write64(ptdev, AS_LOCKADDR(vm->as.id),
+ pack_region_range(ptdev, &start, &size));
+
+ /* If the lock succeeded, update the locked_region info. */
+ ret = as_send_cmd_and_wait(ptdev, vm->as.id, AS_COMMAND_LOCK);
+ }
- /* sm_step_remap() may need a locked region that isn't a strict superset
+ if (!ret) {
+ vm->locked_region.start = start;
+ vm->locked_region.size = size;
+ }
+ mutex_unlock(&ptdev->mmu->as.slots_lock);
+
+ return ret;
+}
+
+static int panthor_vm_expand_region(struct panthor_vm *vm, u64 start, u64 size)
+{
+ struct panthor_device *ptdev = vm->ptdev;
+ u64 end;
+ int ret = 0;
+
+ /* This function is here to handle the following case:
+ * sm_step_remap() may need a locked region that isn't a strict superset
* of the original one because of having to extend unmap boundaries beyond
* it to deal with partial unmaps of transparent huge pages. What we want
* in those cases is to lock the union of both regions. The new region must
@@ -1717,16 +1738,24 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
* boundaries in a remap operation can only shift up or down respectively,
* but never otherwise.
*/
- if (vm->locked_region.size) {
- u64 end = max(vm->locked_region.start + vm->locked_region.size,
- start + size);
- drm_WARN_ON_ONCE(&vm->ptdev->base, (start + size <= vm->locked_region.start) ||
- (start >= vm->locked_region.start + vm->locked_region.size));
+ /* This function can only expand an already locked region */
+ if (drm_WARN_ON(&ptdev->base, !vm->locked_region.size))
+ return -EINVAL;
- start = min(start, vm->locked_region.start);
- size = end - start;
- }
+ /* Early out if requested range is already locked */
+ if (start >= vm->locked_region.start &&
+ start + size <= vm->locked_region.start + vm->locked_region.size)
+ return 0;
+
+ end = max(vm->locked_region.start + vm->locked_region.size,
+ start + size);
+
+ drm_WARN_ON_ONCE(&ptdev->base, (start + size <= vm->locked_region.start) ||
+ (start >= vm->locked_region.start + vm->locked_region.size));
+
+ start = min(start, vm->locked_region.start);
+ size = end - start;
mutex_lock(&ptdev->mmu->as.slots_lock);
if (vm->as.id >= 0 && size) {
@@ -2252,11 +2281,13 @@ static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op,
unmap_hugepage_align(&op->remap, &unmap_start, &unmap_range);
/* If the range changed, we might have to lock a wider region to guarantee
- * atomicity. panthor_vm_lock_region() bails out early if the new region
- * is already part of the locked region, so no need to do this check here.
+ * atomicity.
*/
if (!unmap_vma->evicted) {
- panthor_vm_lock_region(vm, unmap_start, unmap_range);
+ ret = panthor_vm_expand_region(vm, unmap_start, unmap_range);
+ if (ret)
+ return ret;
+
panthor_vm_unmap_pages(vm, unmap_start, unmap_range);
}
--
2.43.0
^ permalink raw reply related
* [PATCH 7/8] drm/panthor: Add support for entering and exiting protected mode
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, Paul Toadere,
Samuel Percival, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
From: Florent Tomasin <florent.tomasin@arm.com>
This patch modifies the Panthor driver code to allow handling
of the GPU HW protected mode enter and exit.
The logic added by this patch includes:
- the mechanisms needed for entering and exiting protected mode.
- the handling of protected mode IRQs and FW interactions.
- the scheduler changes needed to decide when to enter
protected mode based on CSG scheduling.
Note that the submission of a protected mode jobs are done
from the user space.
The following is a summary of how protected mode is entered
and exited:
- When the GPU detects a protected mode job needs to be
executed, an IRQ is sent to the CPU to notify the kernel
driver that the job is blocked until the GPU has entered
protected mode. The entering of protected mode is controlled
by the kernel driver.
- The Mali Panthor CSF driver will schedule a tick and evaluate
which CS in the CSG to schedule on slot needs protected mode.
If the priority of the CSG is not sufficiently high, the
protected mode job will not progress until the CSG is
scheduled at top priority.
- The Panthor scheduler notifies the GPU that the blocked
protected jobs will soon be able to progress.
- Once all CSG and CS slots are updated, the scheduler
requests the GPU to enter protected mode and waits for
it to be acknowledged.
- If successful, all protected mode jobs will resume execution
while normal mode jobs block until the GPU exits
protected mode, or the kernel driver rotates the CSGs
and forces the GPU to exit protected mode.
- If unsuccessful, the scheduler will request a GPU reset.
- When a protected mode job is suspended as a result of
the CSGs rotation, the GPU will send an IRQ to the CPU
to notify that the protected mode job needs to resume.
This sequence will continue so long the user space is
submitting protected mode jobs.
Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
Co-developed-by: Paul Toadere <paul.toadere@arm.com>
Signed-off-by: Paul Toadere <paul.toadere@arm.com>
Co-developed-by: Samuel Percival <samuel.percival@arm.com>
Signed-off-by: Samuel Percival <samuel.percival@arm.com>
Co-developed-by: Ketil Johnsen <ketil.johnsen@arm.com>
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
---
drivers/gpu/drm/panthor/panthor_device.c | 1 +
drivers/gpu/drm/panthor/panthor_device.h | 9 +
drivers/gpu/drm/panthor/panthor_fw.c | 86 ++++++++-
drivers/gpu/drm/panthor/panthor_fw.h | 5 +
drivers/gpu/drm/panthor/panthor_gpu.c | 14 +-
drivers/gpu/drm/panthor/panthor_gpu.h | 6 +
drivers/gpu/drm/panthor/panthor_mmu.c | 10 +
drivers/gpu/drm/panthor/panthor_sched.c | 224 +++++++++++++++++++++--
8 files changed, 339 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
index 3a5cdfa99e5fe..449f17b0f4c5c 100644
--- a/drivers/gpu/drm/panthor/panthor_device.c
+++ b/drivers/gpu/drm/panthor/panthor_device.c
@@ -207,6 +207,7 @@ int panthor_device_init(struct panthor_device *ptdev)
ptdev->soc_data = of_device_get_match_data(ptdev->base.dev);
+ init_rwsem(&ptdev->protm.lock);
init_completion(&ptdev->unplug.done);
ret = drmm_mutex_init(&ptdev->base, &ptdev->unplug.lock);
if (ret)
diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
index d51fec97fc5fa..ebeec45cf60a1 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -334,6 +334,15 @@ struct panthor_device {
struct {
/** @heap: Pointer to the protected heap */
struct dma_heap *heap;
+
+ /**
+ * @lock: Lock to prevent VM operations during protected mode.
+ *
+ * The MMU will not execute commands when the GPU is in
+ * protected mode, so we use this RW lock to sync access
+ * between VM_BIND and GPU protected mode.
+ */
+ struct rw_semaphore lock;
} protm;
};
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
index 1aba29b9779b6..281556530ddab 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.c
+++ b/drivers/gpu/drm/panthor/panthor_fw.c
@@ -1057,7 +1057,9 @@ static void panthor_fw_init_global_iface(struct panthor_device *ptdev)
GLB_CFG_PROGRESS_TIMER |
GLB_CFG_POWEROFF_TIMER |
GLB_IDLE_EN |
- GLB_IDLE;
+ GLB_IDLE |
+ GLB_PROTM_ENTER |
+ GLB_PROTM_EXIT;
if (panthor_fw_has_glb_state(ptdev))
glb_iface->input->ack_irq_mask |= GLB_STATE_MASK;
@@ -1456,6 +1458,88 @@ static void panthor_fw_ping_work(struct work_struct *work)
}
}
+int panthor_fw_protm_enter(struct panthor_device *ptdev)
+{
+ struct panthor_fw_global_iface *glb_iface;
+ u32 acked;
+ u32 status;
+ int ret;
+
+ down_write(&ptdev->protm.lock);
+
+ glb_iface = panthor_fw_get_glb_iface(ptdev);
+
+ panthor_fw_toggle_reqs(glb_iface, req, ack, GLB_PROTM_ENTER);
+ gpu_write(ptdev, CSF_DOORBELL(CSF_GLB_DOORBELL_ID), 1);
+
+ ret = panthor_fw_glb_wait_acks(ptdev, GLB_PROTM_ENTER, &acked, 4000);
+ if (ret) {
+ drm_err(&ptdev->base, "Wait for FW protected mode acknowledge timed out");
+ up_write(&ptdev->protm.lock);
+ return ret;
+ }
+
+ /* Wait for the GPU to actually enter protected mode.
+ * There would be some time gap between FW sending the
+ * ACK for GLB_PROTM_ENTER and GPU entering protected mode.
+ */
+ if (gpu_read_poll_timeout(ptdev, GPU_STATUS, status,
+ (status & GPU_STATUS_PROTM_ACTIVE) ||
+ ((glb_iface->input->req ^ glb_iface->output->ack) &
+ GLB_PROTM_EXIT),
+ 10, 500000)) {
+ drm_err(&ptdev->base, "Wait for GPU protected mode enter timed out");
+ ret = -ETIMEDOUT;
+ }
+
+ up_write(&ptdev->protm.lock);
+
+ return ret;
+}
+
+void panthor_fw_protm_exit(struct panthor_device *ptdev)
+{
+ struct panthor_fw_global_iface *glb_iface = panthor_fw_get_glb_iface(ptdev);
+
+ /* Acknowledge the protm exit. */
+ panthor_fw_update_reqs(glb_iface, req, glb_iface->output->ack, GLB_PROTM_EXIT);
+}
+
+int panthor_fw_protm_exit_wait_event_timeout(struct panthor_device *ptdev)
+{
+ struct panthor_fw_global_iface *glb_iface = panthor_fw_get_glb_iface(ptdev);
+ int ret = 0;
+
+ /* Send PING request to force an exit */
+ panthor_fw_toggle_reqs(glb_iface, req, ack, GLB_PING);
+ gpu_write(ptdev, CSF_DOORBELL(CSF_GLB_DOORBELL_ID), 1);
+
+ ret = wait_event_timeout(ptdev->fw->req_waitqueue,
+ !(gpu_read(ptdev, GPU_STATUS) & GPU_STATUS_PROTM_ACTIVE),
+ msecs_to_jiffies(500));
+
+ if (!ret) {
+ drm_err(&ptdev->base, "Wait for forced protected mode exit timed out");
+ panthor_device_schedule_reset(ptdev);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+void panthor_fw_protm_exit_sync(struct panthor_device *ptdev)
+{
+ u32 status;
+
+ /* Busy-wait (5ms) for FW to exit protected mode on its own */
+ if (!gpu_read_poll_timeout(ptdev, GPU_STATUS, status,
+ !(status & GPU_STATUS_PROTM_ACTIVE), 10,
+ 5000))
+ return;
+
+ panthor_fw_protm_exit_wait_event_timeout(ptdev);
+}
+
/**
* panthor_fw_init() - Initialize FW related data.
* @ptdev: Device.
diff --git a/drivers/gpu/drm/panthor/panthor_fw.h b/drivers/gpu/drm/panthor/panthor_fw.h
index 0cf3761abf789..cf6193eadea12 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.h
+++ b/drivers/gpu/drm/panthor/panthor_fw.h
@@ -502,6 +502,11 @@ int panthor_fw_glb_wait_acks(struct panthor_device *ptdev, u32 req_mask, u32 *ac
void panthor_fw_ring_csg_doorbells(struct panthor_device *ptdev, u32 csg_slot);
+int panthor_fw_protm_enter(struct panthor_device *ptdev);
+void panthor_fw_protm_exit(struct panthor_device *ptdev);
+void panthor_fw_protm_exit_sync(struct panthor_device *ptdev);
+int panthor_fw_protm_exit_wait_event_timeout(struct panthor_device *ptdev);
+
struct panthor_kernel_bo *
panthor_fw_alloc_queue_iface_mem(struct panthor_device *ptdev,
struct panthor_fw_ringbuf_input_iface **input,
diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
index 2ab444ee8c710..e93042eaf3fc8 100644
--- a/drivers/gpu/drm/panthor/panthor_gpu.c
+++ b/drivers/gpu/drm/panthor/panthor_gpu.c
@@ -100,8 +100,11 @@ static void panthor_gpu_irq_handler(struct panthor_device *ptdev, u32 status)
fault_status, panthor_exception_name(ptdev, fault_status & 0xFF),
address);
}
- if (status & GPU_IRQ_PROTM_FAULT)
+ if (status & GPU_IRQ_PROTM_FAULT) {
drm_warn(&ptdev->base, "GPU Fault in protected mode\n");
+ panthor_gpu_disable_protm_fault_interrupt(ptdev);
+ panthor_device_schedule_reset(ptdev);
+ }
spin_lock(&ptdev->gpu->reqs_lock);
if (status & ptdev->gpu->pending_reqs) {
@@ -367,6 +370,10 @@ int panthor_gpu_soft_reset(struct panthor_device *ptdev)
unsigned long flags;
spin_lock_irqsave(&ptdev->gpu->reqs_lock, flags);
+
+ /** Re-enable the protm_irq_fault when reset is complete */
+ ptdev->gpu->irq.mask |= GPU_IRQ_PROTM_FAULT;
+
if (!drm_WARN_ON(&ptdev->base,
ptdev->gpu->pending_reqs & GPU_IRQ_RESET_COMPLETED)) {
ptdev->gpu->pending_reqs |= GPU_IRQ_RESET_COMPLETED;
@@ -427,3 +434,8 @@ void panthor_gpu_resume(struct panthor_device *ptdev)
panthor_hw_l2_power_on(ptdev);
}
+void panthor_gpu_disable_protm_fault_interrupt(struct panthor_device *ptdev)
+{
+ scoped_guard(spinlock_irqsave, &ptdev->gpu->reqs_lock)
+ ptdev->gpu->irq.mask &= ~GPU_IRQ_PROTM_FAULT;
+}
diff --git a/drivers/gpu/drm/panthor/panthor_gpu.h b/drivers/gpu/drm/panthor/panthor_gpu.h
index 12c263a399281..ca66c73f543e6 100644
--- a/drivers/gpu/drm/panthor/panthor_gpu.h
+++ b/drivers/gpu/drm/panthor/panthor_gpu.h
@@ -54,4 +54,10 @@ int panthor_gpu_soft_reset(struct panthor_device *ptdev);
void panthor_gpu_power_changed_off(struct panthor_device *ptdev);
int panthor_gpu_power_changed_on(struct panthor_device *ptdev);
+/**
+ * panthor_gpu_disable_protm_fault_interrupt() - Disable GPU_PROTECTED_FAULT interrupt
+ * @ptdev: Device.
+ */
+void panthor_gpu_disable_protm_fault_interrupt(struct panthor_device *ptdev);
+
#endif
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index 07f54176ec1bf..702f537905b56 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -31,6 +31,7 @@
#include <linux/sizes.h>
#include "panthor_device.h"
+#include "panthor_fw.h"
#include "panthor_gem.h"
#include "panthor_gpu.h"
#include "panthor_heap.h"
@@ -1704,8 +1705,12 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
if (drm_WARN_ON(&ptdev->base, vm->locked_region.size))
return -EINVAL;
+ down_read(&ptdev->protm.lock);
+
mutex_lock(&ptdev->mmu->as.slots_lock);
if (vm->as.id >= 0 && size) {
+ panthor_fw_protm_exit_sync(ptdev);
+
/* Lock the region that needs to be updated */
gpu_write64(ptdev, AS_LOCKADDR(vm->as.id),
pack_region_range(ptdev, &start, &size));
@@ -1720,6 +1725,9 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
}
mutex_unlock(&ptdev->mmu->as.slots_lock);
+ if (ret)
+ up_read(&ptdev->protm.lock);
+
return ret;
}
@@ -1805,6 +1813,8 @@ static void panthor_vm_unlock_region(struct panthor_vm *vm)
vm->locked_region.start = 0;
vm->locked_region.size = 0;
mutex_unlock(&ptdev->mmu->as.slots_lock);
+
+ up_read(&ptdev->protm.lock);
}
static void panthor_mmu_irq_handler(struct panthor_device *ptdev, u32 status)
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index 987072bd867c4..acb04250c7def 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -308,6 +308,15 @@ struct panthor_scheduler {
*/
struct list_head stopped_groups;
} reset;
+
+ /** @protm: Protected mode related fields. */
+ struct {
+ /** @protected_mode: True if GPU is in protected mode. */
+ bool protected_mode;
+
+ /** @active_group: The active protected group. */
+ struct panthor_group *active_group;
+ } protm;
};
/**
@@ -570,6 +579,16 @@ struct panthor_group {
/** @fatal_queues: Bitmask reflecting the queues that hit a fatal exception. */
u32 fatal_queues;
+ /**
+ * @protm_pending_queues: Bitmask reflecting the queues that are waiting
+ * on a CS_PROTM_PENDING.
+ *
+ * The GPU will set the bit associated to the queue pending protected mode
+ * when a PROT_REGION command is executing or when trying to resume previously
+ * suspended protected mode jobs.
+ */
+ u32 protm_pending_queues;
+
/** @tiler_oom: Mask of queues that have a tiler OOM event to process. */
atomic_t tiler_oom;
@@ -1176,6 +1195,7 @@ queue_resume_timeout(struct panthor_queue *queue)
* @ptdev: Device.
* @csg_id: Group slot ID.
* @cs_id: Queue slot ID.
+ * @protm_ack: Acknowledge pending protected mode queues
*
* Program a queue slot with the queue information so things can start being
* executed on this queue.
@@ -1472,6 +1492,34 @@ csg_slot_prog_locked(struct panthor_device *ptdev, u32 csg_id, u32 priority)
return 0;
}
+static void
+cs_slot_process_protm_pending_event_locked(struct panthor_device *ptdev,
+ u32 csg_id, u32 cs_id)
+{
+ struct panthor_scheduler *sched = ptdev->scheduler;
+ struct panthor_csg_slot *csg_slot = &sched->csg_slots[csg_id];
+ struct panthor_group *group = csg_slot->group;
+
+ lockdep_assert_held(&sched->lock);
+
+ if (!group)
+ return;
+
+ /* No protected memory heap, a user space program tried to
+ * submit a protected mode jobs resulting in the GPU raising
+ * a CS_PROTM_PENDING request.
+ *
+ * This scenario is invalid and the protected mode jobs must
+ * not be allowed to progress.
+ */
+ if (!ptdev->protm.heap)
+ return;
+
+ group->protm_pending_queues |= BIT(cs_id);
+
+ sched_queue_delayed_work(sched, tick, 0);
+}
+
static void
cs_slot_process_fatal_event_locked(struct panthor_device *ptdev,
u32 csg_id, u32 cs_id)
@@ -1718,6 +1766,9 @@ static bool cs_slot_process_irq_locked(struct panthor_device *ptdev,
if (events & CS_TILER_OOM)
cs_slot_process_tiler_oom_event_locked(ptdev, csg_id, cs_id);
+ if (events & CS_PROTM_PENDING)
+ cs_slot_process_protm_pending_event_locked(ptdev, csg_id, cs_id);
+
/* We don't acknowledge the TILER_OOM event since its handling is
* deferred to a separate work.
*/
@@ -1848,6 +1899,17 @@ static void sched_process_idle_event_locked(struct panthor_device *ptdev)
sched_queue_delayed_work(ptdev->scheduler, tick, 0);
}
+static void sched_process_protm_exit_event_locked(struct panthor_device *ptdev)
+{
+ lockdep_assert_held(&ptdev->scheduler->lock);
+
+ /* Acknowledge the protm exit and schedule a tick. */
+ panthor_fw_protm_exit(ptdev);
+ sched_queue_delayed_work(ptdev->scheduler, tick, 0);
+ ptdev->scheduler->protm.protected_mode = false;
+ ptdev->scheduler->protm.active_group = NULL;
+}
+
/**
* sched_process_global_irq_locked() - Process the scheduling part of a global IRQ
* @ptdev: Device.
@@ -1863,6 +1925,9 @@ static void sched_process_global_irq_locked(struct panthor_device *ptdev)
ack = READ_ONCE(glb_iface->output->ack);
evts = (req ^ ack) & GLB_EVT_MASK;
+ if (evts & GLB_PROTM_EXIT)
+ sched_process_protm_exit_event_locked(ptdev);
+
if (evts & GLB_IDLE)
sched_process_idle_event_locked(ptdev);
}
@@ -1872,23 +1937,71 @@ static void process_fw_events_work(struct work_struct *work)
struct panthor_scheduler *sched = container_of(work, struct panthor_scheduler,
fw_events_work);
u32 events = atomic_xchg(&sched->fw_events, 0);
+ u32 csg_events = events & ~JOB_INT_GLOBAL_IF;
struct panthor_device *ptdev = sched->ptdev;
mutex_lock(&sched->lock);
+ while (csg_events) {
+ u32 csg_id = ffs(csg_events) - 1;
+
+ sched_process_csg_irq_locked(ptdev, csg_id);
+ csg_events &= ~BIT(csg_id);
+ }
+
if (events & JOB_INT_GLOBAL_IF) {
sched_process_global_irq_locked(ptdev);
events &= ~JOB_INT_GLOBAL_IF;
}
- while (events) {
- u32 csg_id = ffs(events) - 1;
+ mutex_unlock(&sched->lock);
+}
- sched_process_csg_irq_locked(ptdev, csg_id);
- events &= ~BIT(csg_id);
+static void handle_protm_fault(struct panthor_device *ptdev)
+{
+ struct panthor_scheduler *sched = ptdev->scheduler;
+ u32 csg_id;
+ struct panthor_group *protm_group;
+
+ guard(mutex)(&sched->lock);
+
+ if (!sched->protm.protected_mode)
+ return;
+
+ protm_group = sched->protm.active_group;
+
+ if (drm_WARN_ON(&ptdev->base, !protm_group))
+ return;
+
+ /* Group will be terminated by the device reset */
+ protm_group->fatal_queues |= GENMASK(protm_group->queue_count - 1, 0);
+
+ if (!panthor_fw_protm_exit_wait_event_timeout(ptdev))
+ goto cleanup_protm;
+
+ /**
+ * GPU failed to exit protected mode. Mark all non-protected mode CSGs
+ * as suspended so that they are unaffected by the GPU reset.
+ */
+
+ for (csg_id = 0; csg_id < sched->csg_slot_count; csg_id++) {
+ struct panthor_group *group = sched->csg_slots[csg_id].group;
+
+ if (!group || group == protm_group)
+ continue;
+
+ group->state = PANTHOR_CS_GROUP_SUSPENDED;
+
+ group_unbind_locked(group);
+
+ list_move(&group->run_node, group_is_idle(group) ?
+ &sched->groups.idle[group->priority] :
+ &sched->groups.runnable[group->priority]);
}
- mutex_unlock(&sched->lock);
+cleanup_protm:
+ sched->protm.protected_mode = false;
+ sched->protm.active_group = NULL;
}
/**
@@ -2029,6 +2142,7 @@ struct panthor_sched_tick_ctx {
bool immediate_tick;
bool stop_tick;
u32 csg_upd_failed_mask;
+ struct panthor_group *protm_group;
};
static bool
@@ -2299,6 +2413,7 @@ tick_ctx_evict_group(struct panthor_scheduler *sched,
static void
tick_ctx_reschedule_group(struct panthor_scheduler *sched,
+ struct panthor_sched_tick_ctx *ctx,
struct panthor_csg_slots_upd_ctx *upd_ctx,
struct panthor_group *group,
int new_csg_prio)
@@ -2321,6 +2436,30 @@ tick_ctx_reschedule_group(struct panthor_scheduler *sched,
csg_iface->output->ack ^ CSG_ENDPOINT_CONFIG,
CSG_ENDPOINT_CONFIG);
}
+
+ if (ctx->protm_group == group) {
+ for (u32 q = 0; q < group->queue_count; q++) {
+ struct panthor_fw_cs_iface *cs_iface;
+
+ if (!(group->protm_pending_queues & BIT(q)))
+ continue;
+
+ cs_iface = panthor_fw_get_cs_iface(ptdev, group->csg_id, q);
+ panthor_fw_update_reqs(cs_iface, req, cs_iface->output->ack,
+ CS_PROTM_PENDING);
+ }
+
+ panthor_fw_toggle_reqs(csg_iface, doorbell_req, doorbell_ack,
+ group->protm_pending_queues);
+ csgs_upd_ctx_ring_doorbell(upd_ctx, group->csg_id);
+ group->protm_pending_queues = 0;
+
+ /*
+ * We only allow one protected group to run at same time,
+ * as it makes it easier to handle faults in protected mode.
+ */
+ sched->protm.active_group = group;
+ }
}
static void
@@ -2336,6 +2475,17 @@ tick_ctx_schedule_group(struct panthor_scheduler *sched,
group_bind_locked(group, csg_id);
csg_slot_prog_locked(ptdev, csg_id, csg_prio);
+ /* If the group was waiting for protected mode before suspension,
+ * and the tick context enters this mode, it should be serviced
+ * immediately because the slot reset should have set the
+ * CS_PROTM_PENDING bit to zero, and cs_prog_slot_locked() sets it to
+ * zero too.
+ * It's not clear if we will get a new CS_PROTM_PENDING event in that
+ * case, but it should be safe either way.
+ */
+ if (group->protm_pending_queues && ctx->protm_group)
+ group->protm_pending_queues = 0;
+
csgs_upd_ctx_queue_reqs(ptdev, upd_ctx, csg_id,
group->state == PANTHOR_CS_GROUP_SUSPENDED ?
CSG_STATE_RESUME : CSG_STATE_START,
@@ -2365,7 +2515,7 @@ tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *c
/* Update priorities on already running groups. */
list_for_each_entry(group, &ctx->groups[prio], run_node) {
- tick_ctx_reschedule_group(sched, &upd_ctx, group, new_csg_prio--);
+ tick_ctx_reschedule_group(sched, ctx, &upd_ctx, group, new_csg_prio--);
}
}
@@ -2457,6 +2607,15 @@ tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *c
sched->used_csg_slot_count = ctx->group_count;
sched->might_have_idle_groups = ctx->idle_group_count > 0;
+
+ if (ctx->protm_group) {
+ ret = panthor_fw_protm_enter(ptdev);
+ if (ret) {
+ panthor_device_schedule_reset(ptdev);
+ ctx->csg_upd_failed_mask = U32_MAX;
+ }
+ sched->protm.protected_mode = true;
+ }
}
static u64
@@ -2490,7 +2649,7 @@ static void tick_work(struct work_struct *work)
u64 resched_target = sched->resched_target;
u64 remaining_jiffies = 0, resched_delay;
u64 now = get_jiffies_64();
- int prio, ret, cookie;
+ int prio, protm_prio, ret, cookie;
bool full_tick;
if (!drm_dev_enter(&ptdev->base, &cookie))
@@ -2564,14 +2723,49 @@ static void tick_work(struct work_struct *work)
}
}
+ /* Check if the highest priority group want to switch to protected mode */
+ for (protm_prio = PANTHOR_CSG_PRIORITY_COUNT - 1; protm_prio >= 0; protm_prio--) {
+ struct panthor_group *group;
+
+ group = list_first_entry_or_null(&ctx.groups[protm_prio],
+ struct panthor_group,
+ run_node);
+ if (group) {
+ ctx.protm_group = group;
+ break;
+ }
+ }
+
/* If we have free CSG slots left, pick idle groups */
- for (prio = PANTHOR_CSG_PRIORITY_COUNT - 1;
- prio >= 0 && !tick_ctx_is_full(sched, &ctx);
- prio--) {
- /* Check the old_group queue first to avoid reprogramming the slots */
- tick_ctx_pick_groups_from_list(sched, &ctx, &ctx.old_groups[prio], false, true);
- tick_ctx_pick_groups_from_list(sched, &ctx, &sched->groups.idle[prio],
- false, false);
+ if (ctx.protm_group) {
+ /* Pick only idle groups with equal or lower priority than the
+ * group triggering protected mode. Do not bother picking
+ * unscheduled idle groups.
+ */
+ for (prio = protm_prio;
+ prio >= 0 && !tick_ctx_is_full(sched, &ctx);
+ prio--)
+ tick_ctx_pick_groups_from_list(sched, &ctx,
+ &ctx.old_groups[prio],
+ false, true);
+ } else {
+ /* No switch to protected, just pick any idle group according
+ * to priority
+ */
+ for (prio = PANTHOR_CSG_PRIORITY_COUNT - 1;
+ prio >= 0 && !tick_ctx_is_full(sched, &ctx);
+ prio--) {
+ /* Check the old_group queue first to avoid
+ * reprogramming the slots
+ */
+ tick_ctx_pick_groups_from_list(sched, &ctx,
+ &ctx.old_groups[prio],
+ false, true);
+ tick_ctx_pick_groups_from_list(sched, &ctx,
+ &sched->groups.idle[prio],
+ false, false);
+ }
+
}
tick_ctx_apply(sched, &ctx);
@@ -2993,6 +3187,8 @@ void panthor_sched_pre_reset(struct panthor_device *ptdev)
cancel_work_sync(&sched->sync_upd_work);
cancel_delayed_work_sync(&sched->tick_work);
+ handle_protm_fault(ptdev);
+
panthor_sched_suspend(ptdev);
/* Stop all groups that might still accept jobs, so we don't get passed
--
2.43.0
^ permalink raw reply related
* [PATCH 8/8] drm/panthor: Expose protected rendering features
From: Ketil Johnsen @ 2026-05-05 14:05 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Ketil Johnsen
In-Reply-To: <20260505140516.1372388-1-ketil.johnsen@arm.com>
Add query for protected rendering capability.
Add flag to group creation to specify need for protected rendering.
Bump panthor version number.
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
---
drivers/gpu/drm/panthor/panthor_drv.c | 21 +++++++++++-
drivers/gpu/drm/panthor/panthor_sched.c | 21 +++++++-----
include/uapi/drm/panthor_drm.h | 45 +++++++++++++++++++++++--
3 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
index 73fc983dc9b44..817df17f31f15 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -177,6 +177,7 @@ panthor_get_uobj_array(const struct drm_panthor_obj_array *in, u32 min_stride,
PANTHOR_UOBJ_DECL(struct drm_panthor_csif_info, pad), \
PANTHOR_UOBJ_DECL(struct drm_panthor_timestamp_info, current_timestamp), \
PANTHOR_UOBJ_DECL(struct drm_panthor_group_priorities_info, pad), \
+ PANTHOR_UOBJ_DECL(struct drm_panthor_protected_info, features), \
PANTHOR_UOBJ_DECL(struct drm_panthor_sync_op, timeline_value), \
PANTHOR_UOBJ_DECL(struct drm_panthor_queue_submit, syncs), \
PANTHOR_UOBJ_DECL(struct drm_panthor_queue_create, ringbuf_size), \
@@ -928,12 +929,20 @@ static void panthor_query_group_priorities_info(struct drm_file *file,
}
}
+static void panthor_query_protected_info(struct panthor_device *ptdev,
+ struct drm_panthor_protected_info *arg)
+{
+ arg->features =
+ ptdev->protm.heap ? DRM_PANTHOR_PROTECTED_FEATURE_BASIC : 0;
+}
+
static int panthor_ioctl_dev_query(struct drm_device *ddev, void *data, struct drm_file *file)
{
struct panthor_device *ptdev = container_of(ddev, struct panthor_device, base);
struct drm_panthor_dev_query *args = data;
struct drm_panthor_timestamp_info timestamp_info;
struct drm_panthor_group_priorities_info priorities_info;
+ struct drm_panthor_protected_info protected_info;
int ret;
if (!args->pointer) {
@@ -954,6 +963,10 @@ static int panthor_ioctl_dev_query(struct drm_device *ddev, void *data, struct d
args->size = sizeof(priorities_info);
return 0;
+ case DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO:
+ args->size = sizeof(protected_info);
+ return 0;
+
default:
return -EINVAL;
}
@@ -984,6 +997,11 @@ static int panthor_ioctl_dev_query(struct drm_device *ddev, void *data, struct d
panthor_query_group_priorities_info(file, &priorities_info);
return PANTHOR_UOBJ_SET(args->pointer, args->size, priorities_info);
+ case DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO:
+ panthor_query_protected_info(ptdev, &protected_info);
+ return PANTHOR_UOBJ_SET(args->pointer, args->size,
+ protected_info);
+
default:
return -EINVAL;
}
@@ -1779,6 +1797,7 @@ static void panthor_debugfs_init(struct drm_minor *minor)
* - adds DRM_IOCTL_PANTHOR_BO_QUERY_INFO ioctl
* - adds drm_panthor_gpu_info::selected_coherency
* - 1.8 - extends DEV_QUERY_TIMESTAMP_INFO with flags
+ * - 1.9 - adds DEV_QUERY_PROTECTED_INFO query
*/
static const struct drm_driver panthor_drm_driver = {
.driver_features = DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ |
@@ -1792,7 +1811,7 @@ static const struct drm_driver panthor_drm_driver = {
.name = "panthor",
.desc = "Panthor DRM driver",
.major = 1,
- .minor = 8,
+ .minor = 9,
.gem_prime_import_sg_table = panthor_gem_prime_import_sg_table,
.gem_prime_import = panthor_gem_prime_import,
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index acb04250c7def..0e8a1059de589 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -3868,6 +3868,7 @@ static void add_group_kbo_sizes(struct panthor_device *ptdev,
}
#define MAX_GROUPS_PER_POOL 128
+#define GROUP_CREATE_FLAGS DRM_PANTHOR_GROUP_CREATE_PROTECTED
int panthor_group_create(struct panthor_file *pfile,
const struct drm_panthor_group_create *group_args,
@@ -3882,10 +3883,10 @@ int panthor_group_create(struct panthor_file *pfile,
u32 gid, i, suspend_size;
int ret;
- if (group_args->pad)
+ if (group_args->priority >= PANTHOR_CSG_PRIORITY_COUNT)
return -EINVAL;
- if (group_args->priority >= PANTHOR_CSG_PRIORITY_COUNT)
+ if (group_args->flags & ~GROUP_CREATE_FLAGS)
return -EINVAL;
if ((group_args->compute_core_mask & ~ptdev->gpu_info.shader_present) ||
@@ -3937,12 +3938,16 @@ int panthor_group_create(struct panthor_file *pfile,
goto err_put_group;
}
- suspend_size = csg_iface->control->protm_suspend_size;
- group->protm_suspend_buf = panthor_fw_alloc_protm_suspend_buf_mem(ptdev, suspend_size);
- if (IS_ERR(group->protm_suspend_buf)) {
- ret = PTR_ERR(group->protm_suspend_buf);
- group->protm_suspend_buf = NULL;
- goto err_put_group;
+ if (group_args->flags & DRM_PANTHOR_GROUP_CREATE_PROTECTED) {
+ suspend_size = csg_iface->control->protm_suspend_size;
+ group->protm_suspend_buf =
+ panthor_fw_alloc_protm_suspend_buf_mem(ptdev,
+ suspend_size);
+ if (IS_ERR(group->protm_suspend_buf)) {
+ ret = PTR_ERR(group->protm_suspend_buf);
+ group->protm_suspend_buf = NULL;
+ goto err_put_group;
+ }
}
group->syncobjs = panthor_kernel_bo_create(ptdev, group->vm,
diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
index 0e455d91e77d4..914110003bcd1 100644
--- a/include/uapi/drm/panthor_drm.h
+++ b/include/uapi/drm/panthor_drm.h
@@ -253,6 +253,11 @@ enum drm_panthor_dev_query_type {
* @DRM_PANTHOR_DEV_QUERY_GROUP_PRIORITIES_INFO: Query allowed group priorities information.
*/
DRM_PANTHOR_DEV_QUERY_GROUP_PRIORITIES_INFO,
+
+ /**
+ * @DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO: Query supported protected rendering information.
+ */
+ DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO,
};
/**
@@ -504,6 +509,28 @@ struct drm_panthor_group_priorities_info {
__u8 pad[3];
};
+/**
+ * enum drm_panthor_protected_feature_flags - Supported protected rendering features
+ *
+ * Place new types at the end, don't re-order, don't remove or replace.
+ */
+enum drm_panthor_protected_feature_flags {
+ /** @DRM_PANTHOR_PROTECTED_FEATURE_BASIC: Protected rendering available */
+ DRM_PANTHOR_PROTECTED_FEATURE_BASIC = 1 << 0,
+};
+
+/**
+ * struct drm_panthor_protected_info - protected support information
+ *
+ * Structure grouping all queryable information relating to the allowed group priorities.
+ */
+struct drm_panthor_protected_info {
+ /**
+ * @features: Combination of enum drm_panthor_protected_feature_flags flags.
+ */
+ __u32 features;
+};
+
/**
* struct drm_panthor_dev_query - Arguments passed to DRM_PANTHOR_IOCTL_DEV_QUERY
*/
@@ -843,6 +870,18 @@ enum drm_panthor_group_priority {
PANTHOR_GROUP_PRIORITY_REALTIME,
};
+/**
+ * enum drm_panthor_group_create_flags - Group create flags
+ */
+enum drm_panthor_group_create_flags {
+ /**
+ * @DRM_PANTHOR_GROUP_CREATE_PROTECTED: Support protected mode
+ *
+ * Enable protected rendering work to be executed on this group.
+ */
+ DRM_PANTHOR_GROUP_CREATE_PROTECTED = 1 << 0,
+};
+
/**
* struct drm_panthor_group_create - Arguments passed to DRM_IOCTL_PANTHOR_GROUP_CREATE
*/
@@ -877,8 +916,10 @@ struct drm_panthor_group_create {
/** @priority: Group priority (see enum drm_panthor_group_priority). */
__u8 priority;
- /** @pad: Padding field, MBZ. */
- __u32 pad;
+ /**
+ * @flags: Flags. Must be a combination of drm_panthor_group_create_flags flags.
+ */
+ __u32 flags;
/**
* @compute_core_mask: Mask encoding cores that can be used for compute jobs.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v9 3/6] iio: adc: ad4691: add triggered buffer support
From: Jonathan Cameron @ 2026-05-05 14:07 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-3-33e439e4fb87@analog.com>
On Thu, 30 Apr 2026 13:16:45 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add buffered capture support using the IIO triggered buffer framework.
>
> CNV Burst Mode: the GP pin identified by interrupt-names in the device
> tree is configured as DATA_READY output. The IRQ handler stops
> conversions and fires the IIO trigger; the trigger handler executes a
> pre-built SPI message that reads all active channels from the AVG_IN
> accumulator registers and then resets accumulator state and restarts
> conversions for the next cycle.
>
> Manual Mode: CNV is tied to SPI CS so each transfer simultaneously
> reads the previous result and starts the next conversion (pipelined
> N+1 scheme). At preenable time a pre-built, optimised SPI message of
> N+1 transfers is constructed (N channel reads plus one NOOP to drain
> the pipeline). The trigger handler executes the message in a single
> spi_sync() call and collects the results. An external trigger (e.g.
> iio-trig-hrtimer) is required to drive the trigger at the desired
> sample rate.
>
> Both modes share the same trigger handler and push a complete scan —
> one u16 slot per channel at its scan_index position, followed by a
> timestamp — to the IIO buffer via iio_push_to_buffers_with_ts().
>
> The CNV Burst Mode sampling frequency (PWM period) is exposed as a
> buffer-level attribute via IIO_DEVICE_ATTR.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
Another Sashiko found issue inline.
Also it calls out that you have no validate_trigger which might mean
another trigger is used. Moving the irq enable to the trigger_reenable
should solve that.
> +static ssize_t sampling_frequency_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ad4691_state *st = iio_priv(indio_dev);
> +
> + return sysfs_emit(buf, "%lu\n", NSEC_PER_SEC / st->cnv_period_ns);
> +}
> +
> +static ssize_t sampling_frequency_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ad4691_state *st = iio_priv(indio_dev);
> + int freq, ret;
> +
> + ret = kstrtoint(buf, 10, &freq);
I missed this but as Sashiko points out this could read in a negative
frequency. Given that's clearly silly kstrtouint()
> + if (ret)
> + return ret;
> +
> + IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> + if (IIO_DEV_ACQUIRE_FAILED(claim))
> + return -EBUSY;
> +
> +
> + ret = ad4691_set_pwm_freq(st, freq);
> + if (ret)
> + return ret;
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR_RW(sampling_frequency, 0);
> +
> +static const struct iio_dev_attr *ad4691_buffer_attrs[] = {
> + &iio_dev_attr_sampling_frequency,
> + NULL
> +};
^ permalink raw reply
* Re: [PATCH v2 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Leon Romanovsky @ 2026-05-05 14:09 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Greg KH
In-Reply-To: <20260503113506.5710-4-w@1wt.eu>
On Sun, May 03, 2026 at 01:35:06PM +0200, Willy Tarreau wrote:
> AI tools are increasingly used to assist in bug discovery. While these
> tools can identify valid issues, reports that are submitted without
> manual verification often lack context, contain speculative impact
> assessments, or include unnecessary formatting. Such reports increase
> triage effort, waste maintainers' time and may be ignored.
>
> Reports where the reporter has verified the issue and the proposed fix
> typically meet quality standards. This documentation outlines specific
> requirements for length, formatting, and impact evaluation to reduce
> the effort needed to deal with these reports.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 55 +++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
Thanks,
Reviewed-by: Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Leon Romanovsky @ 2026-05-05 14:10 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Greg KH
In-Reply-To: <20260503113506.5710-3-w@1wt.eu>
On Sun, May 03, 2026 at 01:35:05PM +0200, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/index.rst | 1 +
> Documentation/process/security-bugs.rst | 28 +++
> Documentation/process/threat-model.rst | 231 ++++++++++++++++++++++++
> 3 files changed, 260 insertions(+)
> create mode 100644 Documentation/process/threat-model.rst
Thanks,
Reviewed-by: Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] Documentation: security-bugs: do not systematically Cc the security team
From: Leon Romanovsky @ 2026-05-05 14:10 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Greg KH
In-Reply-To: <20260503113506.5710-2-w@1wt.eu>
On Sun, May 03, 2026 at 01:35:04PM +0200, Willy Tarreau wrote:
> With the increase of automated reports, the security team is dealing
> with way more messages than really needed. The reporting process works
> well with most teams so there is no need to systematically involve the
> security team in reports.
>
> Let's suggest to keep it for small lists of recipients and new reporters
> only. This should continue to cover the risk of lost messages while
> reducing the volume from prolific reporters.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
Thanks,
Reviewed-by: Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
From: Jonathan Cameron @ 2026-05-05 14:12 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-4-33e439e4fb87@analog.com>
On Thu, 30 Apr 2026 13:16:46 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add SPI offload support to enable DMA-based, CPU-independent data
> acquisition using the SPI Engine offload framework.
>
> When an SPI offload is available (devm_spi_offload_get() succeeds),
> the driver registers a DMA engine IIO buffer and uses dedicated buffer
> setup operations. If no offload is available the existing software
> triggered buffer path is used unchanged.
>
> Both CNV Burst Mode and Manual Mode support offload, but use different
> trigger mechanisms:
>
> CNV Burst Mode: the SPI Engine is triggered by the ADC's DATA_READY
> signal on the GP pin specified by the trigger-source consumer reference
> in the device tree (one cell = GP pin number 0-3). For this mode the
> driver acts as both an SPI offload consumer (DMA RX stream, message
> optimization) and a trigger source provider: it registers the
> GP/DATA_READY output via devm_spi_offload_trigger_register() so the
> offload framework can match the '#trigger-source-cells' phandle and
> automatically fire the SPI Engine DMA transfer at end-of-conversion.
>
> Manual Mode: the SPI Engine is triggered by a periodic trigger at
> the configured sampling frequency. The pre-built SPI message uses
> the pipelined CNV-on-CS protocol: N+1 16-bit transfers are issued
> for N active channels (the first result is discarded as garbage from
> the pipeline flush) and the remaining N results are captured by DMA.
>
> All offload transfers use 16-bit frames (bits_per_word=16, len=2).
> The channel scan_type (storagebits=16, shift=0, IIO_BE) is shared
> between the software triggered-buffer and offload paths; no separate
> scan_type or channel array is needed for the offload case. The
> ad4691_manual_channels[] array introduced in the triggered-buffer
> commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO
> attribute, which is not applicable in Manual Mode.
Probably good to call out that oversampling hasn't been introduced
to the driver yet. This confused Sashiko ;)
>
> Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
One minor thing inline.
> static int ad4691_reg_read(void *context, unsigned int reg, unsigned int *val)
> {
> struct spi_device *spi = context;
> @@ -712,6 +791,7 @@ static const struct iio_buffer_setup_ops ad4691_manual_buffer_setup_ops = {
> static int ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
> {
> struct ad4691_state *st = iio_priv(indio_dev);
> + unsigned int acc_mask;
> unsigned int k, i;
> int ret;
>
> @@ -758,9 +838,9 @@ static int ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
> if (ret)
> goto err_unoptimize;
>
> - ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG,
> - ~bitmap_read(indio_dev->active_scan_mask, 0,
> - iio_get_masklength(indio_dev)) & GENMASK(15, 0));
> + acc_mask = ~bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)) & GENMASK(15, 0);
Not obvious to me why this change is here. If you want it, push back to the
original patch that introduced this code.
> + ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG, acc_mask);
> if (ret)
> goto err_unoptimize;
>
> @@ -803,6 +883,209 @@ static const struct iio_buffer_setup_ops ad4691_cnv_burst_buffer_setup_ops = {
> .postdisable = &ad4691_cnv_burst_buffer_postdisable,
> };
^ permalink raw reply
* Re: [PATCH RFC] printk: remove BOOT_PRINTK_DELAY
From: Petr Mladek @ 2026-05-05 14:26 UTC (permalink / raw)
To: Andrew Murray
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Randy Dunlap, Clark Williams,
linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Linus Torvalds
In-Reply-To: <20260505-printk_delay-v1-1-5dba51d7f17c@thegoodpenguin.co.uk>
On Tue 2026-05-05 14:45:00, Andrew Murray wrote:
> The CONFIG_BOOT_PRINTK_DELAY option enables support for the boot_delay
> kernel parameter, this allows for a configurable delay to be added before
> each and every printk is emitted. This is DEBUG_KERNEL option that is
> helpful for debugging as kernel output can be slowed down during boot
> allowing messages to be seen before scrolling off the screen, or to
> correlate timing between some physical event and console output.
>
> However, since the introduction of nbcon and the legacy printer thread for
> PREEMPT_RT kernels, printk records are now emited to the console
> asynchronously to the caller of printk and its boot_delay. The delay added
> by boot_delay continues to slow down the calling process, but may not have
> any impact to the rate in which records are emited to the console. For
> example, if delay_use is set to 100ms, and the printer thread has a
> backlog of more than 100ms, perhaps due to a slow serial console, then the
> records will appear to be printed without any delay between them.
>
> It would be unhelpful to add a delay to the printer thread, and it would
> not be possible to disallow selection of CONFIG_BOOT_PRINTK_DELAY at build
> time as it's not possible to detect which consoles are nbcon enabled at
> build time. Therefore, let's remove this feature.
Heh, Randy proposed to remove "boot_delay" few days ago.
This RFC goes even further and remove both "boot_delay" and
"printk_delay".
Honestly, I do not feel comfortable by this. The delay seems to
be handy when there is only graphical console. I would suggest
to do:
1. Obsolete "boot_delay" with "printk_delay" as
proposed in Randy's thread, see
https://lore.kernel.org/all/afn2sYKKsqG4QBVX@pathway.suse.cz/
2. Move printk_delay() from vprintk_emit() to
console_emit_next_record() and nbcon_emit_next_record().
For nbcon console, even better would be to use a sleeping
wait in nbcon_kthread_func(). But it would need some
changes to call it only when a record was really emitted.
Also we would need to use the busy wait in
__nbcon_atomic_flush_pending_con().
IMHO, the only drawback might be that the delay might be multiplied
when more consoles are registered. But I would ignore it. People
would use this option only when the graphical console is the only
one. It does not make sense for serial or network consoles.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
From: Jonathan Cameron @ 2026-05-05 14:28 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-4-33e439e4fb87@analog.com>
On Thu, 30 Apr 2026 13:16:46 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add SPI offload support to enable DMA-based, CPU-independent data
> acquisition using the SPI Engine offload framework.
>
> When an SPI offload is available (devm_spi_offload_get() succeeds),
> the driver registers a DMA engine IIO buffer and uses dedicated buffer
> setup operations. If no offload is available the existing software
> triggered buffer path is used unchanged.
>
> Both CNV Burst Mode and Manual Mode support offload, but use different
> trigger mechanisms:
>
> CNV Burst Mode: the SPI Engine is triggered by the ADC's DATA_READY
> signal on the GP pin specified by the trigger-source consumer reference
> in the device tree (one cell = GP pin number 0-3). For this mode the
> driver acts as both an SPI offload consumer (DMA RX stream, message
> optimization) and a trigger source provider: it registers the
> GP/DATA_READY output via devm_spi_offload_trigger_register() so the
> offload framework can match the '#trigger-source-cells' phandle and
> automatically fire the SPI Engine DMA transfer at end-of-conversion.
>
> Manual Mode: the SPI Engine is triggered by a periodic trigger at
> the configured sampling frequency. The pre-built SPI message uses
> the pipelined CNV-on-CS protocol: N+1 16-bit transfers are issued
> for N active channels (the first result is discarded as garbage from
> the pipeline flush) and the remaining N results are captured by DMA.
>
> All offload transfers use 16-bit frames (bits_per_word=16, len=2).
> The channel scan_type (storagebits=16, shift=0, IIO_BE) is shared
> between the software triggered-buffer and offload paths; no separate
> scan_type or channel array is needed for the offload case. The
> ad4691_manual_channels[] array introduced in the triggered-buffer
> commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO
> attribute, which is not applicable in Manual Mode.
>
> Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
In general have a read through Sashiko reviews once they come in and
if you agree with them reply to your own patches to say what you are
changing.
https://sashiko.dev/#/patchset/20260430-ad4692-multichannel-sar-adc-driver-v9-0-33e439e4fb87%40analog.com
No perfect but another one in here is something I missed completely.
A few of them called out here but please make sure you've addressed them
all or established them to be false (which happens!)
> +
> +struct ad4691_offload_state {
> + struct spi_offload *offload;
> + struct spi_offload_trigger *trigger;
> + u64 trigger_hz;
> + u8 tx_cmd[17][2];
> + u8 tx_reset[4];
These two buffers share cachelines with trigger_hz. That can
be written via sysfs in the middle of a non coherent DMA transfer.
If it is you may loose the written value when a post transfer
flush copies back a stale cacheline (with the new data in tx_cmd
/ tx_reset). These need marking to force them to have their own cache lines.
> };
>
> +
> +static int ad4691_manual_offload_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + struct ad4691_offload_state *offload = st->offload;
> +
> + spi_offload_trigger_disable(offload->offload, offload->trigger);
> + spi_unoptimize_message(&st->scan_msg);
> +
> + return ad4691_exit_conversion_mode(st);
> +}
> +
> +static const struct iio_buffer_setup_ops ad4691_manual_offload_buffer_setup_ops = {
> + .postenable = &ad4691_manual_offload_buffer_postenable,
> + .predisable = &ad4691_manual_offload_buffer_predisable,
> +};
> +
> +static int ad4691_cnv_burst_offload_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + struct ad4691_offload_state *offload = st->offload;
> + struct device *dev = regmap_get_device(st->regmap);
> + struct spi_device *spi = to_spi_device(dev);
> + struct spi_offload_trigger_config config = {
> + .type = SPI_OFFLOAD_TRIGGER_DATA_READY,
> + };
> + unsigned int bpw = indio_dev->channels[0].scan_type.realbits;
> + unsigned int acc_mask;
> + unsigned int bit, k;
> + int ret;
> +
> + ret = regmap_write(st->regmap, AD4691_STD_SEQ_CONFIG,
> + bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)));
> + if (ret)
> + return ret;
> +
> + acc_mask = ~bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)) & GENMASK(15, 0);
> + ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG, acc_mask);
> + if (ret)
> + return ret;
> +
> + ret = ad4691_enter_conversion_mode(st);
> + if (ret)
> + return ret;
> +
> + memset(st->scan_xfers, 0, sizeof(st->scan_xfers));
> +
> + /*
> + * Each AVG_IN register read uses two 16-bit transfers:
> + * TX: [reg_hi | 0x80, reg_lo] (address, CS stays asserted)
> + * RX: [data_hi, data_lo] (data, storagebits=16, shift=0)
> + * The state reset is also split into two 16-bit transfers
> + * (address then value) to keep bits_per_word uniform throughout.
> + */
> + k = 0;
> + iio_for_each_active_channel(indio_dev, bit) {
> + put_unaligned_be16(0x8000 | AD4691_AVG_IN(bit), offload->tx_cmd[k]);
Sashiko makes the interesting point that you are setting bpw to 16 at least sometimes
and that means the SPI bus will be dealing in u16s. As such the endian swap seems
odd. Which also makes a mess if the word length isn't 16 bits. I'm assuming it
always is. If that's the case hard code it rather than giving impression this
will work otherwise. The endian swap probably wants to be unconditional rather
than only if little endian host.
There is a related question whether the larger words interact with the channel
endianness marking. I think that should be fine but please check.
> +
> + /* TX: address phase, CS stays asserted into data phase */
> + st->scan_xfers[2 * k].tx_buf = offload->tx_cmd[k];
> + st->scan_xfers[2 * k].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k].bits_per_word = bpw;
> +
> + /* RX: data phase, CS toggles after to delimit the next register op */
> + st->scan_xfers[2 * k + 1].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k + 1].bits_per_word = bpw;
> + st->scan_xfers[2 * k + 1].offload_flags = SPI_OFFLOAD_XFER_RX_STREAM;
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + k++;
> + }
> +
> + /* State reset to re-arm DATA_READY for the next scan. */
> + put_unaligned_be16(AD4691_STATE_RESET_REG, offload->tx_reset);
> + offload->tx_reset[2] = AD4691_STATE_RESET_ALL;
> +
> + st->scan_xfers[2 * k].tx_buf = offload->tx_reset;
> + st->scan_xfers[2 * k].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k].bits_per_word = bpw;
> +
> + st->scan_xfers[2 * k + 1].tx_buf = &offload->tx_reset[2];
> + st->scan_xfers[2 * k + 1].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k + 1].bits_per_word = bpw;
> + st->scan_xfers[2 * k + 1].cs_change = 1;
This is odd. Add a comment on why if you do want to leave CS active
after this sequence.
> +
> + spi_message_init_with_transfers(&st->scan_msg, st->scan_xfers, 2 * k + 2);
> + st->scan_msg.offload = offload->offload;
> +
> + ret = spi_optimize_message(spi, &st->scan_msg);
> + if (ret)
> + goto err_exit_conversion;
> +
> + ret = ad4691_sampling_enable(st, true);
There are some questions from Sashiko around whether the offload trigger should be enabled
first to avoid getting the device into an odd state. I haven't read the datasheet
in enough depth to check - so over to you to argue one way or the other!
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = spi_offload_trigger_enable(offload->offload, offload->trigger, &config);
> + if (ret)
> + goto err_sampling_disable;
> +
> + return 0;
> +
> +err_sampling_disable:
> + ad4691_sampling_enable(st, false);
> +err_unoptimize:
> + spi_unoptimize_message(&st->scan_msg);
> +err_exit_conversion:
> + ad4691_exit_conversion_mode(st);
> + return ret;
> +}
^ permalink raw reply
* Re: Regression due to /sys/kernel/dmabuf/buffers removal
From: T.J. Mercier @ 2026-05-05 14:32 UTC (permalink / raw)
To: Julian Orth
Cc: Christian König, corbet, dri-devel, linaro-mm-sig, linux-doc,
linux-kernel, linux-media, Sumit Semwal
In-Reply-To: <CAHijbEXQfm4QDDfo1yiVBV9mVvogGqt_BAu2ipnhqa-EDOKteg@mail.gmail.com>
On Tue, May 5, 2026 at 6:00 AM Julian Orth <ju.orth@gmail.com> wrote:
>
> On Tue, May 5, 2026 at 2:41 PM Christian König <christian.koenig@amd.com> wrote:
> >
> > Hi Julian,
> >
> > On 5/5/26 14:25, Julian Orth wrote:
> > > In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF
> > > sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
> > >
> > > I've been using this interface, specifically the exporter_name file,
> > > to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in
> > > exporter_name. I've been doing this for two reasons: 1) to detect that
> > > mmap on such buffers will be fast and 2) to detect that GPU access to
> > > such buffers will be slow.
> >
> > Crap, I really hoped that Android was the only user of that sysfs interface since that approach turned out to be quite broken.
> >
> > It's number one rule on Linux that we don't break userspace. So I hope that you don't insist on bringing that interface back, but if you do I will just revert the removal until we found a better solution.
>
> Bringing it back shouldn't be necessary.
>
> >
> > > With the removal of that file, that detection mechanism no longer works.
> > >
> > > I'm not particularly fond of that mechanism but it was the only one
> > > providing that functionality that I could find at the time. If there
> > > is another one, ideally an ioctl on the dmabuf, please let me know.
> >
> > The virtual fdinfo file you can find under /proc/$pid/fdinfo/$fd also contains the exporter name for the DMA-buf.
> >
> > You can find the full documentation here: https://docs.kernel.org/filesystems/proc.html#dma-buffer-files
> >
> > Is that sufficient?
>
> I think that is sufficient. I probably didn't use fdinfo initially
> because 1) it's a lot more work to parse and 2) I wasn't sure if it
> was intended to be machine-readable or if there could sometimes be
> newlines in the values and such.
>
> >
> > Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.
>
> My application runs as a regular user so it cannot access /sys/kernel/debug.
>
> Having an IOCTL would be ideal if it is not too much work. I'll fall
> back to fdinfo for now.
>
> Thanks, Julian
Phew, I'm glad fdinfo suits your needs.
Adding an ioctl would introduce new UAPI so I think we'd want to avoid
that unless absolutely necessary.
Thanks,
T.J.
> >
> > Regards,
> > Christian.
> >
> > >
> > > Shipping an entire BPF compiler in my application, which the original
> > > patch suggests as the replacement, is not an option when the removed
> > > alternative was simply reading a file.
> > >
> > > Thanks, Julian
> >
^ permalink raw reply
* Re: [PATCH v9 5/6] iio: adc: ad4691: add oversampling support
From: Jonathan Cameron @ 2026-05-05 14:32 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-5-33e439e4fb87@analog.com>
On Thu, 30 Apr 2026 13:16:47 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add per-channel oversampling ratio (OSR) support for CNV burst mode.
> The accumulator depth register (ACC_DEPTH_IN) is programmed with the
> selected OSR at buffer enable time and before each single-shot read.
>
> Supported OSR values: 1, 2, 4, 8, 16, 32.
>
> Introduce AD4691_MANUAL_CHANNEL() for manual mode channels, which do
> not expose the oversampling ratio attribute since OSR is not applicable
> in that mode. A separate manual_channels array is added to
> struct ad4691_channel_info and selected at probe time; offload paths
> reuse the same arrays with num_channels capping access before the soft
> timestamp entry.
>
> in_voltageN_sampling_frequency represents the effective output rate for
> channel N, defined as osc_freq / osr[N]. The chip has one internal
> oscillator shared by all channels; each channel independently
> accumulates osr[N] oscillator cycles before producing a result.
>
> Writing sampling_frequency computes needed_osc = freq * osr[N] and
> snaps down to the largest oscillator table entry that satisfies both
> osc <= needed_osc and osc % osr[N] == 0, guaranteeing an exact integer
> read-back. The result is stored in target_osc_freq_Hz and written to
> OSC_FREQ_REG at buffer enable and single-shot time, so sampling_frequency
> and oversampling_ratio can be set in any order.
>
> in_voltageN_sampling_frequency_available is computed dynamically from
> the channel's current OSR, listing only oscillator table entries that
> divide evenly by osr[N], expressed as effective rates. The list becomes
> sparser as OSR increases, capping at max_rate / osr[N].
>
> Writing oversampling_ratio stores the new OSR for that channel;
> target_osc_freq_Hz is left unchanged. The effective rate read back via
> in_voltageN_sampling_frequency becomes target_osc_freq_Hz / new_osr
> automatically. The two attributes are orthogonal: sampling_frequency
> controls the oscillator, oversampling_ratio controls the averaging depth.
>
> OSR defaults to 1 (no accumulation) for all channels.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
Just one thing - from Sashiko again.
J
>
> static int ad4691_read_avail(struct iio_dev *indio_dev,
> @@ -540,10 +655,30 @@ static int ad4691_read_avail(struct iio_dev *indio_dev,
> unsigned int start = ad4691_samp_freq_start(st->info);
>
> switch (mask) {
> - case IIO_CHAN_INFO_SAMP_FREQ:
> - *vals = &ad4691_osc_freqs_Hz[start];
> + case IIO_CHAN_INFO_SAMP_FREQ: {
> + unsigned int osr = st->osr[chan->channel];
> + int n = 0;
> +
Sashiko shouts about possibly getting a torn set in here if osr were to be changed
whilst you were computing the array. That's probably worth using locks to protect against.
> + /*
> + * Only oscillator frequencies evenly divisible by the channel's
> + * OSR yield an integer effective rate; expose those as effective
> + * rates (osc / osr) so the user works entirely in output-sample
> + * space.
> + */
> + for (unsigned int i = start; i < ARRAY_SIZE(ad4691_osc_freqs_Hz); i++) {
> + if (ad4691_osc_freqs_Hz[i] % osr != 0)
> + continue;
> + st->samp_freq_avail[n++] = ad4691_osc_freqs_Hz[i] / osr;
> + }
> + *vals = st->samp_freq_avail;
> *type = IIO_VAL_INT;
> - *length = ARRAY_SIZE(ad4691_osc_freqs_Hz) - start;
> + *length = n;
> + return IIO_AVAIL_LIST;
> + }
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> + *vals = ad4691_oversampling_ratios;
> + *type = IIO_VAL_INT;
> + *length = ARRAY_SIZE(ad4691_oversampling_ratios);
> return IIO_AVAIL_LIST;
> default:
> return -EINVAL;
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] dpll: zl3073x: report FFO as DPLL vs input reference offset
From: Petr Oros @ 2026-05-05 14:34 UTC (permalink / raw)
To: Ivan Vecera, netdev, Jiri Pirko
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jonathan Corbet, Leon Romanovsky,
Mark Bloch, Michal Schmidt, Paolo Abeni, Pasi Vaananen,
Prathosh Satish, Saeed Mahameed, Shuah Khan, Simon Horman,
Tariq Toukan, Vadim Fedorenko, linux-doc, linux-kernel,
linux-rdma
In-Reply-To: <20260504155340.411063-3-ivecera@redhat.com>
On 5/4/26 17:53, Ivan Vecera wrote:
> Replace the per-reference frequency offset measurement (which was
> redundant with measured-frequency) with a direct read of the DPLL's
> delta frequency offset vs its tracked input reference.
>
> The new implementation uses the dpll_df_offset_x register with
> ref_ofst=1 via the dpll_df_read_x semaphore mechanism. This
> provides 2^-48 resolution (~3.5 fE) and reports the actual
> frequency difference between the DPLL and its active input.
>
> FFO is now reported only for the active input pin in the nested
> (pin vs parent DPLL) context. Top-level FFO returns -ENODATA.
>
> Rewrite ffo_check to compare the cached df_offset converted to PPT
> instead of using the old per-reference measurement. Remove the
> ref_ffo_update periodic measurement and the ref ffo field since
> they are no longer needed.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/zl3073x/chan.c | 31 +++++++++++++++++++++++--
> drivers/dpll/zl3073x/chan.h | 14 ++++++++++++
> drivers/dpll/zl3073x/core.c | 45 -------------------------------------
> drivers/dpll/zl3073x/dpll.c | 34 ++++++++++++----------------
> drivers/dpll/zl3073x/ref.h | 14 ------------
> drivers/dpll/zl3073x/regs.h | 15 +++++++++++++
> 6 files changed, 72 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/dpll/zl3073x/chan.c b/drivers/dpll/zl3073x/chan.c
> index 2f48ca2391494..2fe3c3da84bb5 100644
> --- a/drivers/dpll/zl3073x/chan.c
> +++ b/drivers/dpll/zl3073x/chan.c
> @@ -18,6 +18,7 @@
> int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
> {
> struct zl3073x_chan *chan = &zldev->chan[index];
> + u64 val;
> int rc;
>
> rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_MON_STATUS(index),
> @@ -25,8 +26,34 @@ int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
> if (rc)
> return rc;
>
> - return zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
> - &chan->refsel_status);
> + rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
> + &chan->refsel_status);
> + if (rc)
> + return rc;
> +
> + /* Read df_offset vs tracked reference */
> + rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
> + ZL_DPLL_DF_READ_SEM);
> + if (rc)
> + return rc;
> +
> + rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_DF_READ(index),
> + ZL_DPLL_DF_READ_SEM | ZL_DPLL_DF_READ_REF_OFST);
> + if (rc)
> + return rc;
> +
> + rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
> + ZL_DPLL_DF_READ_SEM);
> + if (rc)
> + return rc;
> +
> + rc = zl3073x_read_u48(zldev, ZL_REG_DPLL_DF_OFFSET(index), &val);
> + if (rc)
> + return rc;
> +
> + chan->df_offset = sign_extend64(val, 47);
> +
> + return 0;
> }
>
> /**
> diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
> index 481da2133202b..4353809c69122 100644
> --- a/drivers/dpll/zl3073x/chan.h
> +++ b/drivers/dpll/zl3073x/chan.h
> @@ -17,6 +17,7 @@ struct zl3073x_dev;
> * @ref_prio: reference priority registers (4 bits per ref, P/N packed)
> * @mon_status: monitor status register value
> * @refsel_status: reference selection status register value
> + * @df_offset: frequency offset vs tracked reference in 2^-48 steps
> */
> struct zl3073x_chan {
> struct_group(cfg,
> @@ -26,6 +27,7 @@ struct zl3073x_chan {
> struct_group(stat,
> u8 mon_status;
> u8 refsel_status;
> + s64 df_offset;
> );
> };
>
> @@ -37,6 +39,18 @@ int zl3073x_chan_state_set(struct zl3073x_dev *zldev, u8 index,
>
> int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index);
>
> +/**
> + * zl3073x_chan_df_offset_get - get cached df_offset vs tracked reference
> + * @chan: pointer to channel state
> + *
> + * Return: frequency offset in 2^-48 steps
> + */
> +static inline s64
> +zl3073x_chan_df_offset_get(const struct zl3073x_chan *chan)
> +{
> + return chan->df_offset;
> +}
> +
> /**
> * zl3073x_chan_mode_get - get DPLL channel operating mode
> * @chan: pointer to channel state
> diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
> index 5f1e70f3e40a0..b3345060490db 100644
> --- a/drivers/dpll/zl3073x/core.c
> +++ b/drivers/dpll/zl3073x/core.c
> @@ -704,44 +704,6 @@ zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
> return 0;
> }
>
> -/**
> - * zl3073x_ref_ffo_update - update reference fractional frequency offsets
> - * @zldev: pointer to zl3073x_dev structure
> - *
> - * The function asks device to latch the latest measured fractional
> - * frequency offset values, reads and stores them into the ref state.
> - *
> - * Return: 0 on success, <0 on error
> - */
> -static int
> -zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
> -{
> - int i, rc;
> -
> - rc = zl3073x_ref_freq_meas_latch(zldev,
> - ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
> - if (rc)
> - return rc;
> -
> - /* Read DPLL-to-REFx frequency offset measurements */
> - for (i = 0; i < ZL3073X_NUM_REFS; i++) {
> - s32 value;
> -
> - /* Read value stored in units of 2^-32 signed */
> - rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
> - if (rc)
> - return rc;
> -
> - /* Convert to ppt
> - * ffo = (10^12 * value) / 2^32
> - * ffo = ( 5^12 * value) / 2^20
> - */
> - zldev->ref[i].ffo = mul_s64_u64_shr(value, 244140625, 20);
> - }
> -
> - return 0;
> -}
> -
> static void
> zl3073x_dev_periodic_work(struct kthread_work *work)
> {
> @@ -776,13 +738,6 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
> }
> }
>
> - /* Update references' fractional frequency offsets */
> - rc = zl3073x_ref_ffo_update(zldev);
> - if (rc)
> - dev_warn(zldev->dev,
> - "Failed to update fractional frequency offsets: %pe\n",
> - ERR_PTR(rc));
> -
> list_for_each_entry(zldpll, &zldev->dplls, list)
> zl3073x_dpll_changes_check(zldpll);
>
> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index f2d430d1a8e7b..af50cd6200001 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -299,8 +299,12 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
> {
> struct zl3073x_dpll_pin *pin = pin_priv;
>
> - /* Only rx vs tx symbol rate FFO is supported */
> - if (dpll)
> + /* Only nested FFO (pin vs parent DPLL) is supported */
> + if (!dpll)
> + return -ENODATA;
> +
> + /* Report FFO only for the active pin */
> + if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
> return -ENODATA;
>
> *ffo = pin->freq_offset;
> @@ -1733,37 +1737,27 @@ zl3073x_dpll_pin_phase_offset_check(struct zl3073x_dpll_pin *pin)
> }
>
> /**
> - * zl3073x_dpll_pin_ffo_check - check for pin fractional frequency offset change
> + * zl3073x_dpll_pin_ffo_check - check for FFO change on active pin
> * @pin: pin to check
> *
> - * Check for the given pin's fractional frequency change.
> - *
> - * Return: true on fractional frequency offset change, false otherwise
> + * Return: true on change, false otherwise
> */
> static bool
> zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
> {
> struct zl3073x_dpll *zldpll = pin->dpll;
> - struct zl3073x_dev *zldev = zldpll->dev;
> - const struct zl3073x_ref *ref;
> - u8 ref_id;
> + const struct zl3073x_chan *chan;
> s64 ffo;
>
> - /* Get reference monitor status */
> - ref_id = zl3073x_input_pin_ref_get(pin->id);
> - ref = zl3073x_ref_state_get(zldev, ref_id);
> -
> - /* Do not report ffo changes if the reference monitor report errors */
> - if (!zl3073x_ref_is_status_ok(ref))
> + if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
> return false;
>
> - /* Compare with previous value */
> - ffo = zl3073x_ref_ffo_get(ref);
> + chan = zl3073x_chan_state_get(zldpll->dev, zldpll->id);
> + ffo = mul_s64_u64_shr(zl3073x_chan_df_offset_get(chan),
> + 244140625, 36);
> +
> if (pin->freq_offset != ffo) {
> - dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
> - pin->label, pin->freq_offset, ffo);
> pin->freq_offset = ffo;
> -
> return true;
> }
>
> diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
> index 55e80e4f08734..e140ca3ea17dc 100644
> --- a/drivers/dpll/zl3073x/ref.h
> +++ b/drivers/dpll/zl3073x/ref.h
> @@ -22,7 +22,6 @@ struct zl3073x_dev;
> * @freq_ratio_n: FEC mode divisor
> * @sync_ctrl: reference sync control
> * @config: reference config
> - * @ffo: current fractional frequency offset
> * @meas_freq: measured input frequency in Hz
> * @mon_status: reference monitor status
> */
> @@ -40,7 +39,6 @@ struct zl3073x_ref {
> u8 config;
> );
> struct_group(stat, /* Status */
> - s64 ffo;
> u32 meas_freq;
> u8 mon_status;
> );
> @@ -58,18 +56,6 @@ int zl3073x_ref_state_update(struct zl3073x_dev *zldev, u8 index);
>
> int zl3073x_ref_freq_factorize(u32 freq, u16 *base, u16 *mult);
>
> -/**
> - * zl3073x_ref_ffo_get - get current fractional frequency offset
> - * @ref: pointer to ref state
> - *
> - * Return: the latest measured fractional frequency offset
> - */
> -static inline s64
> -zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
> -{
> - return ref->ffo;
> -}
> -
> /**
> * zl3073x_ref_meas_freq_get - get measured input frequency
> * @ref: pointer to ref state
> diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
> index 8015808bdf548..9578f00095282 100644
> --- a/drivers/dpll/zl3073x/regs.h
> +++ b/drivers/dpll/zl3073x/regs.h
> @@ -164,6 +164,11 @@
> #define ZL_DPLL_MODE_REFSEL_MODE_NCO 4
> #define ZL_DPLL_MODE_REFSEL_REF GENMASK(7, 4)
>
> +#define ZL_REG_DPLL_DF_READ(_idx) \
> + ZL_REG_IDX(_idx, 5, 0x28, 1, ZL3073X_MAX_CHANNELS, 1)
> +#define ZL_DPLL_DF_READ_SEM BIT(4)
> +#define ZL_DPLL_DF_READ_REF_OFST BIT(3)
> +
> #define ZL_REG_DPLL_MEAS_CTRL ZL_REG(5, 0x50, 1)
> #define ZL_DPLL_MEAS_CTRL_EN BIT(0)
> #define ZL_DPLL_MEAS_CTRL_AVG_FACTOR GENMASK(7, 4)
> @@ -176,6 +181,16 @@
> #define ZL_REG_DPLL_PHASE_ERR_DATA(_idx) \
> ZL_REG_IDX(_idx, 5, 0x55, 6, ZL3073X_MAX_CHANNELS, 6)
>
> +/*******************************
> + * Register Pages 6-7, DPLL Data
> + *******************************/
> +
> +#define ZL_REG_DPLL_DF_OFFSET_03(_idx) \
> + ZL_REG_IDX(_idx, 6, 0x00, 6, 4, 0x20)
> +#define ZL_REG_DPLL_DF_OFFSET_4 ZL_REG(7, 0x00, 6)
> +#define ZL_REG_DPLL_DF_OFFSET(_idx) \
> + ((_idx) < 4 ? ZL_REG_DPLL_DF_OFFSET_03(_idx) : ZL_REG_DPLL_DF_OFFSET_4)
> +
> /***********************************
> * Register Page 9, Synth and Output
> ***********************************/
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* Re: [PATCH v9 6/6] docs: iio: adc: ad4691: add driver documentation
From: Jonathan Cameron @ 2026-05-05 14:35 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-6-33e439e4fb87@analog.com>
On Thu, 30 Apr 2026 13:16:48 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add RST documentation for the AD4691 family ADC driver covering
> supported devices, IIO channels, operating modes, oversampling,
> reference voltage, LDO supply, reset, GP pins, SPI offload support,
> and buffer data format.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> diff --git a/Documentation/iio/ad4691.rst b/Documentation/iio/ad4691.rst
> new file mode 100644
> index 000000000000..38e2ad28a713
> --- /dev/null
> +++ b/Documentation/iio/ad4691.rst
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 24e4502b8292..819d8b6eb6bb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1491,6 +1491,7 @@ S: Supported
> W: https://ez.analog.com/linux-software-drivers
> F: Documentation/devicetree/bindings/iio/adc/adi,ad4691.yaml
> F: drivers/iio/adc/ad4691.c
> +F: drivers/iio/adc/ad4691.rst
Not there. (Sashiko got this one)
>
> ANALOG DEVICES INC AD4695 DRIVER
> M: Michael Hennerich <michael.hennerich@analog.com>
>
^ permalink raw reply
* Re: [PATCH 8/9] docs: maintainers_include: don't ignore invalid profile entries
From: Miguel Ojeda @ 2026-05-05 14:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, rust-for-linux, Björn Roy Baron, Alice Ryhl,
Andreas Hindborg, Benno Lossin, Boqun Feng, Danilo Krummrich,
Gary Guo, Miguel Ojeda, Shuah Khan, Trevor Gross
In-Reply-To: <20260505074534.5fefbed0@foz.lan>
On Tue, May 5, 2026 at 7:45 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> No, this won't work. See sphinx-build help:
That doesn't sound like a fundamental issue, i.e. we could work around
it. Anyway, it is not something we desperately need :)
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang @ 2026-05-05 14:41 UTC (permalink / raw)
To: Beleswar Prasad Padhi, Arnaud POULIQUEN, Mathieu Poirier
Cc: Andrew Lunn, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Frank Li, Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <268f8e00-91bc-43ea-ba95-077cf859e7f3@ti.com>
> -----Original Message-----
> From: Beleswar Prasad Padhi <b-padhi@ti.com>
> Sent: Monday, May 4, 2026 3:17 AM
> To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>; Mathieu Poirier
> <mathieu.poirier@linaro.org>
> Cc: Shenwei Wang <shenwei.wang@nxp.com>; Andrew Lunn
> <andrew@lunn.ch>; Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski
> <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Bjorn Andersson <andersson@kernel.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> Hi Arnaud,
>
> On 30/04/26 22:10, Arnaud POULIQUEN wrote:
> >
> >
> > On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >> Hello Arnaud,
> >>
> >> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>> Hello,
> >>>
> >>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
> >>>>>
> >>>>> Hi Mathieu,
> >>>>>
> >>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang
> <shenwei.wang@nxp.com> wrote:
> >>>>
>
> [...]
>
> >>>>> My mental model looks like this for the complete picture:
> >>>>>
> >>>>> 1. namespace/channel#1 = rpmsg-io
> >>>>> a. ept1 -> gpio-controller@1
> >>>>> b. ept2 -> gpio-controller@2
> >>>>>
> >>>>
> >>>> I've asked for one endpoint per GPIO controller since the very
> >>>> beginning. I don't yet have a strong opinion on whether to use one
> >>>> namespace request per GPIO controller or a single request that
> >>>> spins off multiple endpoints. I'll have to look at your link and
> >>>> reflect on that. Regardless of how we proceed on that front,
> >>>> multiplexing needs to happen at the endpoint level rather than the
> >>>> packet level. This is the only way this work can move forward.
> >>>>
> >>>
> >>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with
> every namespace request.”
> >>>
> >>> If the endpoint is created only on the Linux side, how do we match the Linux
> endpoint address with the local port field on the remote side?
> >>
> >>
> >> Simply by sending a message to the remote containing the newly
> >> created endpoint and the port idx. Note that is this done just one
> >> time, after this Linux need not have the port field in the message
> >> everytime its sending a message.
> >>
> >>>
> >>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr],
> where [addr] corresponds to the GPIO controller address in the DT. This would:
> >>
> >>
> >> You will face the same problem in this case also that you asked above:
> >> "how do we match the Linux endpoint address with the local port field
> >> on the remote side?"
> >
> > Sorry I probably introduced confusion here my sentence should be;
> > With a multi-namespace approach, the namespace could be
> > rpmsg-io-[port], where [port] corresponds to the GPIO controller port in the
> DT.
> >
> >
> > For instance:
> >
> > rpmsg {
> > rpmsg-io {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > gpio@25 {
> > compatible = "rpmsg-gpio";
> > reg = <25>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > #interrupt-cells = <2>;
> > interrupt-controller;
> > };
> >
> > gpio@32 {
> > compatible = "rpmsg-gpio";
> > reg = <32>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > #interrupt-cells = <2>;
> > interrupt-controller;
> > };
> > };
> > };
> >
> > rpmsg-io-25 would match with gpio@25
> > rpmsg-io-32 would match with gpio@32
> >
> >
> >>
> >> Because the endpoint that is created on a namespace request is also
> >> dynamic in nature. How will the remote know which endpoint addr Linux
> >> allocated for a namespace that it announced?
> >>
> >> As an example/PoC, I created a firmware example which announces
> >> 2 name services to Linux, one is the standard "rpmsg_chrdev" and the
> >> other is a TI specific name service "ti.ipc4.ping-pong". You can see
> >> it created 2 different addresses (0x400 and 0x401) for each of the
> >> name service request from the same firmware:
> >>
> >> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> >> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr
> 0xd
> >> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr
> 0xe
> >> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
> formed from src = 0x400 to dst = 0xe
> >> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new
> channel: 0x401 -> 0xd!
> >>
> >> So in this case, rpmsg-io-1 can have different ept addr than
> >> rpmsg-io-2 Back to same problem. Simple solution is to reply to
> >> remote with the created ept addr and the index.
> >
> > That why I would like to suggest to use the name service field to identify the
> port/controller, instead of the endpoint address.
> >>
> >>>
> >>> - match the RPMsg probe with the DT,
> >>
> >>
> >> We can probe from all controllers with a single name service
> >> announcement too.
> >>
> >>> - provide a simple mapping between the port and the endpoint on both
> >>> sides,
> >>
> >>
> >> We are trying to get rid of this mapping from Linux side to adapt the
> >> gpio-virtio design.
> >>
> >>> - allow multiple endpoints on the remote side,
> >>
> >>
> >> We can support this as well with single nameservice model.
> >> There is no limitation. Remote has to send a message with its newly
> >> created ept that's all.
> >>
> >>> - provide a simple discovery mechanism for remote capabilities.
> >>
> >>
> >> A single announcement: "rpmsg-io" is also discovery mechanism.
> >>
> >> Feel free to let me know if you have concerns with any of the
> >> suggestions!
> >
> > My only concern, whatever the solution, is that we find a smart
> > solution to associate the correct endpoint with the correct GPIO
> > port/controller defined in the DT.
>
>
> In my solution, there is no need to have this map of endpoint to GPIO port at
> Linux side. This aligns more with virtio-gpio design as well.
>
> >
> > I may have misunderstood your solution. Could you please help me
> > understand your proposal by explaining how you would handle three GPIO
> > ports defined in the DT, considering that the endpoint addresses on
> > the Linux side can be random?
> > If I assume there is a unique endpoint on the remote side, I do not
> > understand how you can match, on the firmware side, the Linux endpoint
> > address to the GPIO port.
>
>
> Sure, let me take an example:
> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
>
> rpmsg {
> rpmsg-io {
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio@25 {
> compatible = "rpmsg-gpio";
> reg = <25>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> gpio@32 {
> compatible = "rpmsg-gpio";
> reg = <32>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> gpio@35 {
> compatible = "rpmsg-gpio";
> reg = <35>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
> };
> };
>
> Code Flow:
> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
> ept = 0xd.
>
> 2. rpmsg_core.c creates the default dynamic local ept for the channel
> ept = 0x405.
>
> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
> rpdev->src = 0x405 and rpdev->dst = 0xd.
>
> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
> in DT, it will trigger rpmsg_gpiochip_register() which will now:
> a. Call port->ept = rpmsg_create_ept(rpdev,
> rpmsg_gpio_channel_callback,
> port,
> {rpdev.id.name,
> RPMSG_ADDR_ANY,
> RPMSG_ADDR_ANY});
> Ex- port->ept->addr = 0x408
>
> b. Prepare a 8-byte message having 2 fields:
> port->ept->addr (0x408) and port->idx (25)
>
> c. Send this message to remote firmware on default channel ept
> (0x405 -> 0xd) by:
> rpmsg_send(rpdev->ept, &message, sizeof(message));
>
> d. Remote side receives this message and creates a map of the
> linux_ept_addr to gpio_port. (0x408 <-> 25)
>
> 5. After this point, any gpio messages sent from Linux from gpio port
> endpoints (Ex- 0x408) can be decoded at remote side by looking up
> its map (Ex- map[0x408] = 25).
>
> 6. Any messages sent from remote to Linux for a particular gpio port can
> also be decoded at Linux by simply fetching the priv pointer to get
> the per-port device:
> struct rpmsg_gpio_port *port = priv;
>
> So Linux does not need to send the port idx everytime while sending a gpio
> message anymore.
>
I support the idea of encoding the port index directly into ept->addr.
To keep the design simple, we can rely on a predefined rule to derive ept->src, rather than
exchanging additional configuration. One approach is to use the default channel address as
the base address and encode the port index into the lower bits. For example:
ept->src = (baseaddr << 8) | port_index;
With this scheme, the endpoint-to-port mapping can be encoded implicitly, eliminating the need
for an extra message to exchange EPT and port mapping information.
Thanks,
Shenwei
> Thanks,
> Beleswar
>
> [...]
^ permalink raw reply
* Re: [PATCH v9 3/6] iio: adc: ad4691: add triggered buffer support
From: Andy Shevchenko @ 2026-05-05 14:58 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
David Lechner, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260505142640.49cde0ca@jic23-huawei>
On Tue, May 05, 2026 at 02:26:40PM +0100, Jonathan Cameron wrote:
...
> > > > + for (i = 0; i < ARRAY_SIZE(ad4691_gp_names); i++) {
> > > > + irq = fwnode_irq_get_byname(dev_fwnode(dev),
> > > > + ad4691_gp_names[i]);
> > > > + if (irq > 0)
> > > > + break;
> > >
> > > This is problematic in case the above returns EPROBE_DEFER. Can you confirm
> > > it
> > > may not ever happen? (Note, I don't know the answer.)
> >
> > You are right, thanks for this!
> I'm missing something. Why is that a problem? Driver will return
> the error and a dev_err_probe() is used so it won't print anything.
> So probe will fail which is exactly what we want.
If there are two IRQs and the first one is probe deferred and second returns
an error, we return that error instead of the deferral probe.
May be I missed something, but I have no idea how in this case it may return
the first error code in such a case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/8] dma-heap: Add proper kref handling on dma-buf heaps
From: Boris Brezillon @ 2026-05-05 15:20 UTC (permalink / raw)
To: Ketil Johnsen
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Liviu Dudau, Daniel Almeida,
Alice Ryhl, Matthias Brugger, AngeloGioacchino Del Regno,
dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Yong Wu, Yunfei Dong,
Florent Tomasin
In-Reply-To: <20260505140516.1372388-2-ketil.johnsen@arm.com>
Hi Ketil,
On Tue, 5 May 2026 16:05:07 +0200
Ketil Johnsen <ketil.johnsen@arm.com> wrote:
> From: John Stultz <jstultz@google.com>
>
> Add proper reference counting on the dma_heap structure. While
> existing heaps are built-in, we may eventually have heaps loaded
> from modules, and we'll need to be able to properly handle the
> references to the heaps
It's weird that this "heap as module" thing is mentioned here, but
actual robustness to make this safe is not added in the commit or any
of the following ones.
>
> Signed-off-by: John Stultz <jstultz@google.com>
> Signed-off-by: T.J. Mercier <tjmercier@google.com>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> [Yong: Just add comment for "minor" and "refcount"]
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> [Yunfei: Change reviewer's comments]
> Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
> [Florent: Rebase]
> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
> [Ketil: Rebase]
> ---
> drivers/dma-buf/dma-heap.c | 29 +++++++++++++++++++++++++++++
> include/linux/dma-heap.h | 2 ++
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index ac5f8685a6494..9fd365ddbd517 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -12,6 +12,7 @@
> #include <linux/dma-heap.h>
> #include <linux/err.h>
> #include <linux/export.h>
> +#include <linux/kref.h>
> #include <linux/list.h>
> #include <linux/nospec.h>
> #include <linux/syscalls.h>
> @@ -31,6 +32,7 @@
> * @heap_devt: heap device node
> * @list: list head connecting to list of heaps
> * @heap_cdev: heap char device
> + * @refcount: reference counter for this heap device
> *
> * Represents a heap of memory from which buffers can be made.
> */
> @@ -41,6 +43,7 @@ struct dma_heap {
> dev_t heap_devt;
> struct list_head list;
> struct cdev heap_cdev;
> + struct kref refcount;
> };
>
> static LIST_HEAD(heap_list);
> @@ -248,6 +251,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> if (!heap)
> return ERR_PTR(-ENOMEM);
>
> + kref_init(&heap->refcount);
> heap->name = exp_info->name;
> heap->ops = exp_info->ops;
> heap->priv = exp_info->priv;
> @@ -313,6 +317,31 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> }
> EXPORT_SYMBOL_NS_GPL(dma_heap_add, "DMA_BUF_HEAP");
>
> +static void dma_heap_release(struct kref *ref)
> +{
> + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
> + unsigned int minor = MINOR(heap->heap_devt);
> +
> + mutex_lock(&heap_list_lock);
> + list_del(&heap->list);
> + mutex_unlock(&heap_list_lock);
> +
> + device_destroy(dma_heap_class, heap->heap_devt);
> + cdev_del(&heap->heap_cdev);
> + xa_erase(&dma_heap_minors, minor);
> +
> + kfree(heap);
That's actually problematic, because cdev_del() doesn't guarantee that
all opened FDs have been closed [1], it just guarantees that no new ones
can materialize. In order to make that safe, we'd need a
1. kref_get_unless_zero() in dma_heap_open(), with proper locking around
the xa_load() to protect against the heap removal that's happening
here
2. a dma_heap_put() in a new dma_heap_close() implementation
3. a guarantee that heap implementations won't go away until the last
ref is dropped, which means ops and all the data needed for this heap
to satisfy ioctl()s (and more generally every passed at
dma_heap_add() time) have to stay valid until the last ref is
dropped. Alternatively, we could restrict this only to in-flight
ioctl()s, and have the ops replaced by some dummy ops using RCU or a
rwlock. But I guess live dmabufs allocated on this heap have to
retain the heap and its implementation anyway.
For record, #3 is already not satisfied by the current tee_heap
implementation (tee_dma_heap objects can vanish before the dma_heap
object is gone). The other implementations seem to be fine because they
are statically linked, and they either have exp_info.priv set to NULL,
or something that's never released.
TLDR; the whole assumption that adding refcounting to dma_heap is
enough to guarantee safety around device/module removal is not holding,
and adding in-kernel users acquiring dma_heap refs on top of this
design is just going to make it even more painful to fix.
I see two way forward from here, either we get the
dma_heap/dma_heap-producer lifetime right from the start the way I
suggested above (I might have missed corner cases there BTW), or we keep
assuming that heaps can only ever be created, never destroyed/removed
(which is basically what the current dma_heap.c logic does, except
tee_heap.c broke that), and just let dma_heap_find() return dma_heap
pointers whose lifetime is assumed to be static.
> +}
> +
> +/**
> + * dma_heap_put - drops a reference to a dmabuf heap, potentially freeing it
> + * @heap: DMA-Heap whose reference count to decrement
> + */
> +void dma_heap_put(struct dma_heap *heap)
> +{
> + kref_put(&heap->refcount, dma_heap_release);
nit: I'd go
if (heap)
kref_put(&heap->refcount, dma_heap_release);
so users can call dma_heap_put() on NULL heaps, which usually simplify
error paths and/or destruction of partially initialized objects.
Regards,
Boris
[1]https://elixir.bootlin.com/linux/v7.0.1/source/fs/char_dev.c#L594
^ permalink raw reply
* [PATCH] kbuild: deb-pkg: Allow setting package name at build
From: Mario Limonciello (AMD) @ 2026-05-05 15:29 UTC (permalink / raw)
To: mario.limonciello, nathan, nsc, corbet, skhan
Cc: Mario Limonciello (AMD), linux-kbuild, linux-doc
Users can change the source package by setting variable `KDEB_SOURCENAME`,
but the binary package name is hardcoded.
Add support for setting binary package name by using `KDEB_PACKAGENAME`
and let it affect both kernel image and debug image packages.
Update kbuild documentation to include defaults and mention both
`KDEB_PACKAGENAME` and `KDEB_SOURCENAME`.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
---
Documentation/kbuild/kbuild.rst | 10 ++++++++++
scripts/package/mkdebian | 6 ++++--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst
index 5a9013bacfb75..cbdd2224c3a55 100644
--- a/Documentation/kbuild/kbuild.rst
+++ b/Documentation/kbuild/kbuild.rst
@@ -177,6 +177,16 @@ the UTS_MACHINE variable, and on some architectures also the kernel config.
The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian
architecture.
+KDEB_SOURCENAME
+----------------
+For the deb-pkg target, allows overriding the default source package name.
+The default package name is "linux-upstream".
+
+KDEB_PACKAGENAME
+----------------
+For the deb-pkg target, allows overriding the default binary package name.
+The default package name is "linux-image".
+
KDOCFLAGS
---------
Specify extra (warning/error) flags for kernel-doc checks during the build,
diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
index d4b007b38a475..cbe4266fac732 100755
--- a/scripts/package/mkdebian
+++ b/scripts/package/mkdebian
@@ -166,7 +166,9 @@ else
fi
sourcename=${KDEB_SOURCENAME:-linux-upstream}
-if [ "$ARCH" = "um" ] ; then
+if [ "${KDEB_PACKAGENAME:+set}" ]; then
+ packagename=$KDEB_PACKAGENAME
+elif [ "$ARCH" = "um" ]; then
packagename=user-mode-linux
else
packagename=linux-image
@@ -252,7 +254,7 @@ fi
if is_enabled CONFIG_DEBUG_INFO; then
cat <<EOF >> debian/control
-Package: linux-image-${KERNELRELEASE}-dbg
+Package: $packagename-${KERNELRELEASE}-dbg
Section: debug
Architecture: $debarch
Build-Profiles: <!pkg.${sourcename}.nokerneldbg>
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-05 15:38 UTC (permalink / raw)
To: Beleswar Prasad Padhi, tanmay.shah, Arnaud POULIQUEN,
Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <4b622824-0073-4c6a-8525-248bd484c3f0@ti.com>
On 5/5/2026 6:16 AM, Beleswar Prasad Padhi wrote:
> Hi Tanmay,
>
> On 05/05/26 00:49, Shah, Tanmay wrote:
>> Hello all,
>>
>> I have started reviewing this work as well.
>> Thanks Shenwei for this work.
>>
>> I have gone through only the current revision, and would like to provide
>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>> Also, have some bindings related question.
>>
>> Please see below:
>>
>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>
>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>> Hello Arnaud,
>>>>
>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>> Hello,
>>>>>
>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>> Hi Mathieu,
>>>>>>>
>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>> Andersson
>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>> linux-imx <linux-
>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>
>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>> message format.
>>>>>>>>>>>>
>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>
>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>> requests and
>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>> channel, so a
>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>> of messages.
>>>>>>>>>>>
>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>> an additional
>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>> field is added to
>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>
>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>> multiplexing
>>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>>> field. One endpoint,
>>>>>>>>>> one GPIO controller.
>>>>>>>>>>
>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>> endpoint maps to, either
>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>> way), or by sending it
>>>>>>>>> separately.
>>>>>>>>>
>>>>>>>> An endpoint is created with every namespace request. There should be
>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>> unique
>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>> field to identify them.
>>>>>>>
>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>> request.
>>>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>
>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>> next week.
>>>>>>
>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>
>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>> a. ept1 -> gpio-controller@1
>>>>>>> b. ept2 -> gpio-controller@2
>>>>>>>
>> If my understanding of what gpio-controller is right, than this won't
>> work. We need one rpmsg channel per gpio-controller, and in most cases
>> there will be only one GPIO-controller on the remote side.
>
>
> Why so? In the current v13 version, the remote side already
> handles 2 GPIO controllers.
>
>> If there are
>> multiple or multiple instances of same controller, than we need separate
>> channel name for that controller just like we would have separate device
>> on the Linux.
>
>
> Why so? I think there is some confusion in the terminology:
>
> GPIO controller = GPIO port (gpio@xyz) defined in the
> Device tree = struct rpmsg_gpio_port in code
>
> GPIO line = Individual lines within each GPIO port (max =
> GPIOS_PER_PORT_DEFAULT) = struct rpmsg_gpio_line in code
>
Okay, I understand now. So, same gpio controller has multiple instances.
>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>> a. ept1 -> gpio-controller@1
>>>>>>> b. ept2 -> gpio-controller@2
So, In that case above mentioned approach doesn't work.
Because, this approach is mapping endpoint to the gpio-controller. From
linux's perspective, it needs to map rpmsg *channel* to the
gpio-controller not the endpoint.
To be more specific:
Linux: remote:
ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
- gpio-line ept1
- gpio-line ept2 -> They all map to same callback_ept_1024.
- gpio-line ept3
ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
- gpio-line ept1
- gpio-line ept2 -> They all map to same callback_ept_1025.
- gpio-line ept3
On the remote side, we have to hardcode Which rpmsg controller is mapped
to which endpoint.
>>
>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>> off multiple endpoints. I'll have to look at your link and reflect on
>>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>>> to happen at the endpoint level rather than the packet level. This is
>>>>>> the only way this work can move forward.
>>>>>>
>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>> created with every namespace request.”
>>>>>
>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>> the Linux endpoint address with the local port field on the remote side?
>>>>
>>>> Simply by sending a message to the remote containing the newly created
>>>> endpoint and the port idx. Note that is this done just one time, after
>>>> this
>>>> Linux need not have the port field in the message everytime its sending
>>>> a message.
>>>>
>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>> the DT. This would:
>>>>
>>>> You will face the same problem in this case also that you asked above:
>>>> "how do we match the Linux endpoint address with the local port field
>>>> on the remote side?"
>>> Sorry I probably introduced confusion here
>>> my sentence should be;
>>> With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>>> where [port] corresponds to the GPIO controller port in the DT.
>>>
>>>
>>> For instance:
>>>
>>> rpmsg {
>>> rpmsg-io {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> gpio@25 {
>>> compatible = "rpmsg-gpio";
>>> reg = <25>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>>
>>> gpio@32 {
>>> compatible = "rpmsg-gpio";
>>> reg = <32>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>> };
>>> };
>>>
>>> rpmsg-io-25 would match with gpio@25
>>> rpmsg-io-32 would match with gpio@32
>>>
>> The problem with this approach is, we will endup creating way too many
>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>> many GPIOs can be handled by remote from memory perspective. At
>> somepoint we might just run-out of number ept & channels created by the
>> remote. As of now, open-amp library supports 128 epts I think.
>
>
> Arnaud was suggesting one channel per gpio controller,
> not per line. We will not have 128 gpio controllers....
>
>>
>>>> Because the endpoint that is created on a namespace request is also
>>>> dynamic in nature. How will the remote know which endpoint addr
>>>> Linux allocated for a namespace that it announced?
>>>>
>>>> As an example/PoC, I created a firmware example which announces
>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>> the name service request from the same firmware:
>>>>
>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>> ti.ipc4.ping-pong addr 0xd
>>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>> addr 0xe
>>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>> formed from src = 0x400 to dst = 0xe
>>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>> new channel: 0x401 -> 0xd!
>>>>
>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>> Back to same problem. Simple solution is to reply to remote with the
>>>> created ept addr and the index.
>>> That why I would like to suggest to use the name service field to
>>> identify the port/controller, instead of the endpoint address.
>>>>
>>>>> - match the RPMsg probe with the DT,
>>>>
>>>> We can probe from all controllers with a single name service
>>>> announcement too.
>>>>
>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>> sides,
>>>>
>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>> the gpio-virtio design.
>>>>
>>>>> - allow multiple endpoints on the remote side,
>>>>
>>>> We can support this as well with single nameservice model.
>>>> There is no limitation. Remote has to send a message with
>>>> its newly created ept that's all.
>>>>
>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>
>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>
>>>> Feel free to let me know if you have concerns with any of the
>>>> suggestions!
>>> My only concern, whatever the solution, is that we find a smart
>>> solution to associate the correct endpoint with the correct GPIO
>>> port/controller defined in the DT.
>>>
>>> I may have misunderstood your solution. Could you please help me
>>> understand your proposal by explaining how you would handle three
>>> GPIO ports defined in the DT, considering that the endpoint
>>> addresses on the Linux side can be random?
>>> If I assume there is a unique endpoint on the remote side,
>>> I do not understand how you can match, on the firmware side,
>>> the Linux endpoint address to the GPIO port.
>>>
>>> Thanks and Regards,Arnaud
>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>>> Regards,
>>>>> Arnaud
>>>>>
>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>> a. ept1 -> i2c@1
>>>>>>> b. ept2 -> i2c@2
>>>>>>> c. ept3 -> i2c@3
>>>>>>>
>>>>>>> etc...
>>>>>>>
>> Just want to clear-up few terms before I jump to the solution:
>>
>> **RPMsg channel/device**:
>> - These are devices announced by the remote processor, and created by
>> linux. They are created at: /sys/bus/rpmsg/devices
>> - The channel format: <name>.<src ept>.<dst ept>
>>
>> **RPMsg endpoint**:
>> - Endpoint is differnt than channel. Single channel can have multiple
>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>
>> To create endpoint device, we have rpmsg_create_ept API, which takes
>> channel information as input, which has src-ept, dst-ept.
>>
>> Following is proposed solution:
>>
>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>> pin/port).
>
>
> One channel per pin was not suggested earlier...
>
>> - In our case that would be, single rpmsg-io node. (That makes me
>> question if bindings are correct or not).
>>
>> 2) Assign GPIO number as src ept.
>>
>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>> endpoint.
>>
>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>> add 1024 offset to the GPIO number:
>>
>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>
>> Now on the remote side, there is single channel and only single-endpoint
>> is needed that is mapped to the rpmsg-io channel callback.
>>
>> That callback will receive all the payloads from the Linux, which will
>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>
>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>> on platform specific logic.
>>
>> This doesn't need PORT information at all. Also it makes sure that
>> remote is using only single-endpoint so not much memory is used.
>>
>> *Example*:
>> If only rpmsg-gpio channel is created by the remote side, than following
>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>> the rpmsg-io controller:
>>
>> Linux Remote
>>
>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>
>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>> |
>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>> |
>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>>
>>
>> *On remote side*:
>>
>> ept_0x400_callback(..., int src_ept, ...,)
>> {
>> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>> // platform specific logic to convert gpio num to proper pin,
>> // just like you would convert gpio num to pin on a linux gpio controller.
>> }
>>
>> My question on the binding:
>>
>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>> can be represented just any other GPIO controller? Please let me know if
>> I am missing something.
>
>
> These are separate GPIO controllers, not separate pins within
> the same GPIO controller. Could you revisit your solution with
> this update.
>
> Thanks for your time,
> Beleswar
>
^ permalink raw reply
* [PATCH v6 00/22] Virtual Swap Space
From: Nhat Pham @ 2026-05-05 15:38 UTC (permalink / raw)
To: kasong
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
nphamcs, pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel, haowenchao22
This patch series is (still) based on 6.19 for now, for ease of
regression investigation and testing :) Kairui reported regressions
on fast swapfile backends (PMEM to be specific) in [19], so I have
focused on reproducing them and trying to figure out what happened.
For a more in-depth analysis, see [22].
I think I have got most of it, but since my setup cannot be 100%
similar to Kairui's, I figured I should not overindex on my setups
and send it out for his feedbacks. I will also try to work on
other benchmarks that he's interested in :)
Special thanks to Kairui, Johannes, and Gregory for their feedbacks,
ideas and testing! All mistakes are mine though :)
Changelog:
* v5 -> v6: focusing on reducing the CPU and memory overhead on fast
swap backends (zram, and hopefully PMEM).
* Combine multiple vswap operations to reduce roundtrips
to the vswap layer.
* Batch per-entry operations where possible (vswap_free for e.g).
* Eliminate redundant lookups.
* Per-CPU lookup cache for vswap cluster to reduce xarray
indirection overhead (patch 22).
* Augment the reverse map to avoid physical-to-virtual swap
indirection cost when checking swap-cache-only status.
* Decouple descriptor array from cluster header to eliminate
wasted space from slab rounding in cluster allocation.
* v4 -> v5:
* Fix a deadlock in memcg1_swapout (reported by syzbot [16]).
* Replace VM_WARN_ON(!spin_is_locked()) with lockdep_assert_held(),
and use guard(rcu) in vswap_cpu_dead
(reported by Peter Zijlstra [17]).
* v3 -> v4:
* Fix poor swap free batching behavior to alleviate a regression
(reported by Kairui Song).
* Fix assorted kernel build errors reported by kernel test robots
in the case of CONFIG_SWAP=n.
* RFC v2 -> v3:
* Implement a cluster-based allocation algorithm for virtual swap
slots, inspired by Kairui Song and Chris Li's implementation, as
well as Johannes Weiner's suggestions. This eliminates the lock
contention issues on the virtual swap layer.
* Re-use swap table for the reverse mapping.
* Remove CONFIG_VIRTUAL_SWAP.
* Reducing the size of the swap descriptor from 48 bytes to 24
bytes, i.e another 50% reduction in memory overhead from v2.
* Remove swap cache and zswap tree and use the swap descriptor
for this.
* Remove zeromap, and replace the swap_map bytemap with 2 bitmaps
(one for allocated slots, and one for bad slots).
* Rebase on top of 6.19 (7d0a66e4bb9081d75c82ec4957c50034cb0ea449)
* Update cover letter to include new benchmark results and discussion
on overhead in various cases.
* RFC v1 -> RFC v2:
* Use a single atomic type (swap_refs) for reference counting
purpose. This brings the size of the swap descriptor from 64 B
down to 48 B (25% reduction). Suggested by Yosry Ahmed.
* Zeromap bitmap is removed in the virtual swap implementation.
This saves one bit per physical swapfile slot.
* Rearrange the patches and the code change to make things more
reviewable. Suggested by Johannes Weiner.
* Update the cover letter a bit.
This patch series implements the virtual swap space idea, based on Yosry's
proposals at LSFMMBPF 2023 (see [1], [2], [3]), as well as valuable
inputs from Johannes Weiner. The same idea (with different
implementation details) has been floated by Rik van Riel since at least
2011 (see [8]).
I. Motivation
Currently, when an anon page is swapped out, a slot in a backing swap
device is allocated and stored in the page table entries that refer to
the original page. This slot is also used as the "key" to find the
swapped out content, as well as the index to swap data structures, such
as the swap cache, or the swap cgroup mapping. Tying a swap entry to its
backing slot in this way is performant and efficient when swap is purely
just disk space, and swapoff is rare.
However, the advent of many swap optimizations has exposed major
drawbacks of this design. The first problem is that we occupy a physical
slot in the swap space, even for pages that are NEVER expected to hit
the disk: pages compressed and stored in the zswap pool, zero-filled
pages, or pages rejected by both of these optimizations when zswap
writeback is disabled. This is the arguably central shortcoming of
zswap:
* In deployments when no disk space can be afforded for swap (such as
mobile and embedded devices), users cannot adopt zswap, and are forced
to use zram. This is confusing for users, and creates extra burdens
for developers, having to develop and maintain similar features for
two separate swap backends (writeback, cgroup charging, THP support,
etc.). For instance, see the discussion in [4].
* Resource-wise, it is hugely wasteful in terms of disk usage. At Meta,
we have swapfile in the order of tens to hundreds of GBs, which are
mostly unused and only exist to enable zswap usage and zero-filled
pages swap optimizations.
* Tying zswap (and more generally, other in-memory swap backends) to
the current physical swapfile infrastructure makes zswap implicitly
statically sized. This does not make sense, as unlike disk swap, in
which we consume a limited resource (disk space or swapfile space) to
save another resource (memory), zswap consume the same resource it is
saving (memory). The more we zswap, the more memory we have available,
not less. We are not rationing a limited resource when we limit
the size of the zswap pool, but rather we are capping the resource
(memory) saving potential of zswap. Under memory pressure, using
more zswap is almost always better than the alternative (disk IOs, or
even worse, OOMs), and dynamically sizing the zswap pool on demand
allows the system to flexibly respond to these precarious scenarios.
* Operationally, static provisioning the swapfile for zswap pose
significant challenges, because the sysadmin has to prescribe how
much swap is needed a priori, for each combination of
(memory size x disk space x workload usage). It is even more
complicated when we take into account the variance of memory
compression, which changes the reclaim dynamics (and as a result,
swap space size requirement). The problem is further exacerbated for
users who rely on swap utilization (and exhaustion) as an OOM signal.
All of these factors make it very difficult to configure the swapfile
for zswap: too small of a swapfile and we risk preventable OOMs and
limit the memory saving potentials of zswap; too big of a swapfile
and we waste disk space and memory due to swap metadata overhead.
This dilemma becomes more drastic in high memory systems, which can
have up to TBs worth of memory.
Past attempts to decouple disk and compressed swap backends, namely the
ghost swapfile approach (see [13]), as well as the alternative
compressed swap backend zram, have mainly focused on eliminating the
disk space usage of compressed backends. We want a solution that not
only tackles that same problem, but also achieve the dynamicization of
swap space to maximize the memory saving potentials while reducing
operational and static memory overhead.
Finally, any swap redesign should support efficient backend transfer,
i.e without having to perform the expensive page table walk to
update all the PTEs that refer to the swap entry:
* The main motivation for this requirement is zswap writeback. To quote
Johannes (from [14]): "Combining compression with disk swap is
extremely powerful, because it dramatically reduces the worst aspects
of both: it reduces the memory footprint of compression by shedding
the coldest data to disk; it reduces the IO latencies and flash wear
of disk swap through the writeback cache. In practice, this reduces
*average event rates of the entire reclaim/paging/IO stack*."
* Another motivation is to simplify swapoff, which is both complicated
and expensive in the current design, precisely because we are storing
an encoding of the backend positional information in the page table,
and thus requires a full page table walk to remove these references.
II. High Level Design Overview
To fix the aforementioned issues, we need an abstraction that separates
a swap entry from its physical backing storage. IOW, we need to
“virtualize” the swap space: swap clients will work with a dynamically
allocated virtual swap slot, storing it in page table entries, and
using it to index into various swap-related data structures. The
backing storage is decoupled from the virtual swap slot, and the newly
introduced layer will “resolve” the virtual swap slot to the actual
storage. This layer also manages other metadata of the swap entry, such
as its lifetime information (swap count), via a dynamically allocated,
per-swap-entry descriptor:
struct swp_desc {
union {
swp_slot_t slot; /* 0 8 */
struct zswap_entry * zswap_entry; /* 0 8 */
}; /* 0 8 */
union {
struct folio * swap_cache; /* 8 8 */
void * shadow; /* 8 8 */
}; /* 8 8 */
unsigned int swap_count; /* 16 4 */
unsigned short memcgid:16; /* 20: 0 2 */
bool in_swapcache:1; /* 22: 0 1 */
/* Bitfield combined with previous fields */
enum swap_type type:2; /* 20:17 4 */
/* size: 24, cachelines: 1, members: 6 */
/* bit_padding: 13 bits */
/* last cacheline: 24 bytes */
};
(output from pahole).
This design allows us to:
* Decouple zswap (and zeromapped swap entry) from backing swapfile:
simply associate the virtual swap slot with one of the supported
backends: a zswap entry, a zero-filled swap page, a slot on the
swapfile, or an in-memory page.
* Simplify and optimize swapoff: we only have to fault the page in and
have the virtual swap slot points to the page instead of the on-disk
physical swap slot. No need to perform any page table walking.
The size of the virtual swap descriptor is 24 bytes. Note that this is
not all "new" overhead, as the swap descriptor will replace:
* the swap_cgroup arrays (one per swap type) in the old design, which
is a massive source of static memory overhead. With the new design,
it is only allocated for used clusters.
* the swap tables, which holds the swap cache and workingset shadows.
* the zeromap bitmap, which is a bitmap of physical swap slots to
indicate whether the swapped out page is zero-filled or not.
* huge chunk of the swap_map. The swap_map is now replaced by 2 bitmaps,
one for allocated slots, and one for bad slots, representing 3 possible
states of a slot on the swapfile: allocated, free, and bad.
* the zswap tree.
So, in terms of additional memory overhead:
* For zswap entries, the added memory overhead is rather minimal. The
new indirection pointer neatly replaces the existing zswap tree.
We really only incur less than one word of overhead for swap count
blow up (since we no longer use swap continuation) and the swap type.
* For physical swap entries, the new design will impose fewer than 3 words
memory overhead. However, as noted above this overhead is only for
actively used swap entries, whereas in the current design the overhead is
static (including the swap cgroup array for example).
The primary victim of this overhead will be zram users. However, as
zswap now no longer takes up disk space, zram users can consider
switching to zswap (which, as a bonus, has a lot of useful features
out of the box, such as cgroup tracking, dynamic zswap pool sizing,
LRU-ordering writeback, etc.).
For a more concrete example, suppose we have a 32 GB swapfile (i.e.
8,388,608 swap entries), and we use zswap.
0% usage, or 0 entries: 0.00 MB
* Old design total overhead: 25.00 MB
* Vswap total overhead: 0.00 MB
25% usage, or 2,097,152 entries:
* Old design total overhead: 57.00 MB
* Vswap total overhead: 48.25 MB
50% usage, or 4,194,304 entries:
* Old design total overhead: 89.00 MB
* Vswap total overhead: 96.50 MB
75% usage, or 6,291,456 entries:
* Old design total overhead: 121.00 MB
* Vswap total overhead: 144.75 MB
100% usage, or 8,388,608 entries:
* Old design total overhead: 153.00 MB
* Vswap total overhead: 193.00 MB
So even in the worst case scenario for virtual swap, i.e when we
somehow have an oracle to correctly size the swapfile for zswap
pool to 32 GB, the added overhead is only 40 MB, which is a mere
0.12% of the total swapfile :)
In practice, the overhead will be closer to the 50-75% usage case, as
systems tend to leave swap headroom for pathological events or sudden
spikes in memory requirements. The added overhead in these cases are
practically negligible. And in deployments where swapfiles for zswap
are previously sparsely used, switching over to virtual swap will
actually reduce memory overhead.
Doing the same math for the disk swap, which is the worst case for
virtual swap in terms of swap backends:
0% usage, or 0 entries: 0.00 MB
* Old design total overhead: 25.00 MB
* Vswap total overhead: 2.00 MB
25% usage, or 2,097,152 entries:
* Old design total overhead: 41.00 MB
* Vswap total overhead: 66.25 MB
50% usage, or 4,194,304 entries:
* Old design total overhead: 57.00 MB
* Vswap total overhead: 130.50 MB
75% usage, or 6,291,456 entries:
* Old design total overhead: 73.00 MB
* Vswap total overhead: 194.75 MB
100% usage, or 8,388,608 entries:
* Old design total overhead: 89.00 MB
* Vswap total overhead: 259.00 MB
The added overhead is 170MB, which is 0.5% of the total swapfile size,
again in the worst case when we have a sizing oracle.
Please see the attached patches for more implementation details.
III. Usage and Benchmarking
This patch series introduce no new syscalls or userspace API. Existing
userspace setups will work as-is, except we no longer have to create a
swapfile or set memory.swap.max if we want to use zswap, as zswap is no
longer tied to physical swap. The zswap pool will be automatically and
dynamically sized based on memory usage and reclaim dynamics.
All benchmarks below use MGLRU and zram as the swap backend. zram,
being a fast swapfile, represents the worst case for vswap in terms of
overhead (both memory- and CPU-wise). This is also as close as I can
get to the setup in which Kairui reported his regressions (see [18]),
as I do not have access to a PMEM swap device. This also means I have
to modify the parameters of these benchmarks a bit, as zram eats up
memory of the system too - I hope this is acceptable.
All values are reported as mean +/- standard deviation across rounds.
Test system: x86_64, 52 cores for all these benchmarks, 64GB zram swap.
1. Memhog: single-threaded, 48GB allocation on a host with 16GB RAM,
8 rounds.
Baseline (6.19) VSS v5 VSS v6
real (s) 80.50 +/- 1.90 83.00 +/- 1.80 80.64 +/- 1.72
sys (s) 62.71 +/- 2.01 65.72 +/- 1.80 62.93 +/- 1.63
delta real - +3.1% +0.2%
delta sys - +4.8% +0.4%
2. Usemem single-threaded: anonymous memory allocation (56GB) on a host
with 32GB RAM, 16 rounds.
Baseline (6.19) VSS v5 VSS v6
real (s) 176.52 +/- 4.25 182.12 +/- 3.96 176.56 +/- 3.30
sys (s) 122.60 +/- 3.96 128.42 +/- 3.92 123.01 +/- 3.07
tput (KB/s) 390602 +/- 10179 380372 +/- 8802 390524 +/- 7752
free (ms) 7287 +/- 281 8354 +/- 217 7332 +/- 268
delta real - +3.2% +0.0%
delta sys - +4.7% +0.3%
delta tput - -2.6% -0.0%
delta free - +14.6% +0.6%
I do want to note that the free time is severely affected by system
compaction, due to a contention between zs_free() and
zs_page_migrate(). This actually affects both baseline and vswap, and
it's a bit of a luck-of-the-draw on a round-per-round basis whether you
will hit it, which is another reason that delays my submission of this
version. I also re-run it for 16 rounds instead of 8, in hope that the
variance will be averaged out somewhat.
Fortunately, when I raised this issues on the mailing list, Wenchao
came up up with a brilliant idea to get around this contention
(see [19]). I have actually hacked together a quick-and-dirty prototype
based on his idea, and it helps tremendously on the free path, but I
will leave it to him to push on this direction ;)
3. Usemem concurrency: 52 threads x 300MB, random access, on a host
with 16GB RAM, 20 rounds.
Baseline (6.19) VSS v5 VSS v6
real (s) 14.98 +/- 0.78 18.33 +/- 1.79 14.82 +/- 0.99
sys (s) 396.4 +/- 31.1 511.9 +/- 60.3 390.7 +/- 37.0
tput (KB/s) 28188 +/- 1810 23287 +/- 2464 28765 +/- 2264
free (ms) 101.1 +/- 3.5 91.4 +/- 4.0 98.7 +/- 6.2
delta real - +22.4% -1.1%
delta sys - +29.1% -1.4%
delta tput - -17.4% +2.0%
delta free - -9.6% -2.4%
Note: not sure why VSS does better than baseline on the free path here.
Could be some weird lock contention effect - I will dig deeper once I
have the free (pun intended) time ;) This could be an indendent
work to improve swap overall, similar to the aforementioned zmalloc
lock contention :)
4. Kernel build: 52 workers (one per processor), memory.max = 3GB,
64GB RAM, 5 rounds.
Baseline (6.19) VSS v5 VSS v6
real (s) 163.30 +/- 0.47 163.47 +/- 0.52 163.34 +/- 0.51
sys (s) 538.87 +/- 16.49 535.93 +/- 11.88 535.53 +/- 15.29
user (s) 5121.60 +/- 1.41 5126.80 +/- 1.55 5125.57 +/- 2.84
delta real - +0.1% +0.0%
delta sys - -0.5% -0.6%
With the optimizations done in V6, we have closed the gap between
virtual swap implementation and 6.19 vanilla to within noise :)
IV. Future Use Cases
While the patch series focus on two applications (decoupling swap
backends and swapoff optimization/simplification), this new,
future-proof design also allows us to implement new swap features more
easily and efficiently:
* Facilitating new backend implementations: Thanks to the flexibility
of the new design, we can easily add new swap backends, such as
compressed CXL as swap (see [20]). Vswap provides the much needed
dynamicity and ease-of-backend transfer for these new backends.
Another example is samefilled-swap-page (see [23]). I have actually
hacked together a small patch to do this, but I decided not to
include it, because it hides the problem in the memhog benchmark
of virtual swap - I will send it in the next version if folks believe
it is a worthwhile feature.
* Multi-tier swapping (as mentioned in [5]), with transparent
transferring (promotion/demotion) of pages across tiers (see [8] and
[9]). Similar to swapoff, with the old design we would need to
perform the expensive page table walk.
* Swapfile compaction to alleviate fragmentation (as proposed by Ying
Huang in [6]).
* Mixed backing THP swapin (see [7]): Once you have pinned down the
backing store of THPs, then you can dispatch each range of subpages
to appropriate backend swapin handler.
* Swapping a folio out with discontiguous physical swap slots
(see [10]).
* Zswap writeback optimization: The current architecture pre-reserves
physical swap space for pages when they enter the zswap pool, giving
the kernel no flexibility at writeback time. With the virtual swap
implementation, the backends are decoupled, and physical swap space
is allocated on-demand at writeback time, at which point we can make
much smarter decisions: we can batch multiple zswap writeback
operations into a single IO request, allocating contiguous physical
swap slots for that request. We can even perform compressed writeback
(i.e writing these pages without decompressing them) (see [12]).
* Deferred physical swap allocation to optimize IO patterns and fallback
to a different swap backend on error (see [24] and [25]).
V. References
[1]: https://lore.kernel.org/all/CAJD7tkbCnXJ95Qow_aOjNX6NOMU5ovMSHRC+95U4wtW6cM+puw@mail.gmail.com/
[2]: https://lwn.net/Articles/932077/
[3]: https://www.youtube.com/watch?v=Hwqw_TBGEhg
[4]: https://lore.kernel.org/all/Zqe_Nab-Df1CN7iW@infradead.org/
[5]: https://lore.kernel.org/lkml/CAF8kJuN-4UE0skVHvjUzpGefavkLULMonjgkXUZSBVJrcGFXCA@mail.gmail.com/
[6]: https://lore.kernel.org/linux-mm/87o78mzp24.fsf@yhuang6-desk2.ccr.corp.intel.com/
[7]: https://lore.kernel.org/all/CAGsJ_4ysCN6f7qt=6gvee1x3ttbOnifGneqcRm9Hoeun=uFQ2w@mail.gmail.com/
[8]: https://lore.kernel.org/linux-mm/4DA25039.3020700@redhat.com/
[9]: https://lore.kernel.org/all/CA+ZsKJ7DCE8PMOSaVmsmYZL9poxK6rn0gvVXbjpqxMwxS2C9TQ@mail.gmail.com/
[10]: https://lore.kernel.org/all/CACePvbUkMYMencuKfpDqtG1Ej7LiUS87VRAXb8sBn1yANikEmQ@mail.gmail.com/
[11]: https://lore.kernel.org/all/CAMgjq7BvQ0ZXvyLGp2YP96+i+6COCBBJCYmjXHGBnfisCAb8VA@mail.gmail.com/
[12]: https://lore.kernel.org/linux-mm/ZeZSDLWwDed0CgT3@casper.infradead.org/
[13]: https://lore.kernel.org/all/20251121-ghost-v1-1-cfc0efcf3855@kernel.org/
[14]: https://lore.kernel.org/linux-mm/20251202170222.GD430226@cmpxchg.org/
[15]: https://lore.kernel.org/linux-mm/CAMgjq7AQNGK-a=AOgvn4-V+zGO21QMbMTVbrYSW_R2oDSLoC+A@mail.gmail.com/
[16]: https://lore.kernel.org/all/69bc6c4f.050a0220.3bf4de.0001.GAE@google.com/
[17]: https://lore.kernel.org/all/20260319075621.GR3738010@noisy.programming.kicks-ass.net/
[18]: https://lore.kernel.org/all/CAMgjq7AiUr_Ntj51qoqvV+=XbEATjr7S4MH+rgD32T5pHfF7mg@mail.gmail.com/
[19]: https://lore.kernel.org/all/CAOptpSPs-1UrEa8AHg19e590=SiV6bpnex7gCbif8=aY7BtpuA@mail.gmail.com/
[20]: https://lore.kernel.org/all/aerrps94j70MkgdW@gourry-fedora-PF4VCD3F/
[21]: https://lore.kernel.org/all/afIKxG5mJZE6QgpR@gourry-fedora-PF4VCD3F/
[22]: https://lore.kernel.org/all/CAKEwX=NrUhUrAFx+8BYJEfaVKpCm-H9JhBzYSrqOQb-NW7QRug@mail.gmail.com/
[23]: https://lore.kernel.org/all/CAKEwX=PBjMVfMvKkNfqbgiw7o10NFyZBSB62ODzsqogv-WDYKQ@mail.gmail.com/
[24]: https://lore.kernel.org/all/CAKEwX=NR5dkKduTPwDHWiSMFwJ9ZmvindFvUNbPgQu690W_m+A@mail.gmail.com/
[25]: https://ieeexplore.ieee.org/document/8662047
Nhat Pham (22):
mm/swap: decouple swap cache from physical swap infrastructure
swap: rearrange the swap header file
mm: swap: add an abstract API for locking out swapoff
zswap: add new helpers for zswap entry operations
mm/swap: add a new function to check if a swap entry is in swap
cached.
mm: swap: add a separate type for physical swap slots
mm: create scaffolds for the new virtual swap implementation
zswap: prepare zswap for swap virtualization
mm: swap: allocate a virtual swap slot for each swapped out page
swap: move swap cache to virtual swap descriptor
zswap: move zswap entry management to the virtual swap descriptor
swap: implement the swap_cgroup API using virtual swap
swap: manage swap entry lifecycle at the virtual swap layer
mm: swap: decouple virtual swap slot from backing store
zswap: do not start zswap shrinker if there is no physical swap slots
swap: do not unnecessarily pin readahead swap entries
swapfile: remove zeromap bitmap
memcg: swap: only charge physical swap slots
swap: simplify swapoff using virtual swap
swapfile: replace the swap map with bitmaps
vswap: batch contiguous vswap free calls
vswap: cache cluster lookup
Documentation/mm/index.rst | 1 -
Documentation/mm/swap-table.rst | 69 -
MAINTAINERS | 4 +-
include/linux/cpuhotplug.h | 1 +
include/linux/memcontrol.h | 5 +
include/linux/mm_types.h | 16 +
include/linux/shmem_fs.h | 9 +-
include/linux/swap.h | 210 ++-
include/linux/swap_cgroup.h | 18 +-
include/linux/swapops.h | 25 +
include/linux/zswap.h | 17 +-
kernel/power/swap.c | 6 +-
mm/Makefile | 5 +-
mm/filemap.c | 14 +-
mm/huge_memory.c | 11 +-
mm/internal.h | 33 +-
mm/madvise.c | 2 +-
mm/memcontrol-v1.c | 17 +-
mm/memcontrol.c | 168 ++-
mm/memory.c | 109 +-
mm/migrate.c | 13 +-
mm/mincore.c | 15 +-
mm/page_io.c | 124 +-
mm/shmem.c | 227 +--
mm/swap.h | 268 ++--
mm/swap_cgroup.c | 172 ---
mm/swap_state.c | 308 +---
mm/swap_table.h | 132 +-
mm/swapfile.c | 1607 ++++----------------
mm/userfaultfd.c | 18 +-
mm/vmscan.c | 29 +-
mm/vswap.c | 2515 +++++++++++++++++++++++++++++++
mm/zswap.c | 178 +--
33 files changed, 3615 insertions(+), 2731 deletions(-)
delete mode 100644 Documentation/mm/swap-table.rst
delete mode 100644 mm/swap_cgroup.c
create mode 100644 mm/vswap.c
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
--
2.52.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox