* [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos
2026-05-06 10:45 [PATCH 0/4] Let userspace explicitly trigger memory reclaims Nicolas Frattaroli
@ 2026-05-06 10:45 ` Nicolas Frattaroli
2026-05-06 15:06 ` Steven Price
2026-05-06 10:45 ` [PATCH 2/4] MAINTAINERS: Add sysfs ABI docs to list of panthor files Nicolas Frattaroli
` (3 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Nicolas Frattaroli @ 2026-05-06 10:45 UTC (permalink / raw)
To: Boris Brezillon, Steven Price, Liviu Dudau, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig,
Nicolas Frattaroli
panthor_mmu_reclaim_priv_bos returns the number of freed pages. However,
how many bytes of freed memory this translates to can't generally be
deduced from the number of pages, as the page size is a per-VM property.
It may be useful to know the exact number of bytes that have been freed
for observability and debugging purposes. To that end, add a new
parameter "freed_sz", which is a pointer to a size_t where this
information will be stored. It may be NULL, in which case the
information isn't stored at all.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/panthor/panthor_gem.c | 3 ++-
drivers/gpu/drm/panthor/panthor_mmu.c | 12 ++++++++++--
drivers/gpu/drm/panthor/panthor_mmu.h | 1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
index 13295d7a593d..80e82238f3c5 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.c
+++ b/drivers/gpu/drm/panthor/panthor_gem.c
@@ -1511,7 +1511,8 @@ panthor_gem_shrinker_scan(struct shrinker *shrinker, struct shrink_control *sc)
goto out;
freed += panthor_mmu_reclaim_priv_bos(ptdev, sc->nr_to_scan - freed,
- &remaining, panthor_gem_try_evict);
+ &remaining, NULL,
+ panthor_gem_try_evict);
if (freed >= sc->nr_to_scan)
goto out;
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index a7ee14986849..b81388b35a58 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -3127,13 +3127,18 @@ int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec, struct panthor_vm
unsigned long
panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
unsigned int nr_to_scan, unsigned long *remaining,
+ size_t *freed_sz,
bool (*shrink)(struct drm_gem_object *,
struct ww_acquire_ctx *))
{
+ unsigned long newly_freed;
unsigned long freed = 0;
LIST_HEAD(remaining_vms);
LIST_HEAD(vms);
+ if (freed_sz)
+ *freed_sz = 0;
+
mutex_lock(&ptdev->reclaim.lock);
list_splice_init(&ptdev->reclaim.vms, &vms);
@@ -3152,8 +3157,11 @@ panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
mutex_unlock(&ptdev->reclaim.lock);
- freed += drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed,
- remaining, shrink, NULL);
+ newly_freed = drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed,
+ remaining, shrink, NULL);
+ if (freed_sz)
+ *freed_sz += panthor_vm_page_size(vm) * newly_freed;
+ freed += newly_freed;
mutex_lock(&ptdev->reclaim.lock);
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.h b/drivers/gpu/drm/panthor/panthor_mmu.h
index 3522fbbce369..12b18b5f90e1 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.h
+++ b/drivers/gpu/drm/panthor/panthor_mmu.h
@@ -52,6 +52,7 @@ int panthor_vm_evict_bo_mappings_locked(struct panthor_gem_object *bo);
unsigned long
panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
unsigned int nr_to_scan, unsigned long *remaining,
+ size_t *freed_sz,
bool (*shrink)(struct drm_gem_object *,
struct ww_acquire_ctx *));
int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec,
--
2.54.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos
2026-05-06 10:45 ` [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos Nicolas Frattaroli
@ 2026-05-06 15:06 ` Steven Price
2026-05-06 15:19 ` Nicolas Frattaroli
0 siblings, 1 reply; 10+ messages in thread
From: Steven Price @ 2026-05-06 15:06 UTC (permalink / raw)
To: Nicolas Frattaroli, Boris Brezillon, Liviu Dudau,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig
On 06/05/2026 11:45, Nicolas Frattaroli wrote:
> panthor_mmu_reclaim_priv_bos returns the number of freed pages. However,
> how many bytes of freed memory this translates to can't generally be
> deduced from the number of pages, as the page size is a per-VM property.
>
> It may be useful to know the exact number of bytes that have been freed
The "useful" aspect seems to just be a drm_dbg() message from what I can
see with this series? Am I missing something or is it not actually that
useful?
Thanks,
Steve
> for observability and debugging purposes. To that end, add a new
> parameter "freed_sz", which is a pointer to a size_t where this
> information will be stored. It may be NULL, in which case the
> information isn't stored at all.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/panthor/panthor_gem.c | 3 ++-
> drivers/gpu/drm/panthor/panthor_mmu.c | 12 ++++++++++--
> drivers/gpu/drm/panthor/panthor_mmu.h | 1 +
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> index 13295d7a593d..80e82238f3c5 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -1511,7 +1511,8 @@ panthor_gem_shrinker_scan(struct shrinker *shrinker, struct shrink_control *sc)
> goto out;
>
> freed += panthor_mmu_reclaim_priv_bos(ptdev, sc->nr_to_scan - freed,
> - &remaining, panthor_gem_try_evict);
> + &remaining, NULL,
> + panthor_gem_try_evict);
> if (freed >= sc->nr_to_scan)
> goto out;
>
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index a7ee14986849..b81388b35a58 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -3127,13 +3127,18 @@ int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec, struct panthor_vm
> unsigned long
> panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
> unsigned int nr_to_scan, unsigned long *remaining,
> + size_t *freed_sz,
> bool (*shrink)(struct drm_gem_object *,
> struct ww_acquire_ctx *))
> {
> + unsigned long newly_freed;
> unsigned long freed = 0;
> LIST_HEAD(remaining_vms);
> LIST_HEAD(vms);
>
> + if (freed_sz)
> + *freed_sz = 0;
> +
> mutex_lock(&ptdev->reclaim.lock);
> list_splice_init(&ptdev->reclaim.vms, &vms);
>
> @@ -3152,8 +3157,11 @@ panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
>
> mutex_unlock(&ptdev->reclaim.lock);
>
> - freed += drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed,
> - remaining, shrink, NULL);
> + newly_freed = drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed,
> + remaining, shrink, NULL);
> + if (freed_sz)
> + *freed_sz += panthor_vm_page_size(vm) * newly_freed;
> + freed += newly_freed;
>
> mutex_lock(&ptdev->reclaim.lock);
>
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.h b/drivers/gpu/drm/panthor/panthor_mmu.h
> index 3522fbbce369..12b18b5f90e1 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.h
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.h
> @@ -52,6 +52,7 @@ int panthor_vm_evict_bo_mappings_locked(struct panthor_gem_object *bo);
> unsigned long
> panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
> unsigned int nr_to_scan, unsigned long *remaining,
> + size_t *freed_sz,
> bool (*shrink)(struct drm_gem_object *,
> struct ww_acquire_ctx *));
> int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec,
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos
2026-05-06 15:06 ` Steven Price
@ 2026-05-06 15:19 ` Nicolas Frattaroli
0 siblings, 0 replies; 10+ messages in thread
From: Nicolas Frattaroli @ 2026-05-06 15:19 UTC (permalink / raw)
To: Boris Brezillon, Liviu Dudau, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Steven Price
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig
On Wednesday, 6 May 2026 17:06:57 Central European Summer Time Steven Price wrote:
> On 06/05/2026 11:45, Nicolas Frattaroli wrote:
> > panthor_mmu_reclaim_priv_bos returns the number of freed pages. However,
> > how many bytes of freed memory this translates to can't generally be
> > deduced from the number of pages, as the page size is a per-VM property.
> >
> > It may be useful to know the exact number of bytes that have been freed
>
> The "useful" aspect seems to just be a drm_dbg() message from what I can
> see with this series?
Correct.
> Am I missing something or is it not actually that useful?
I wanted to know how much memory I'm actually reclaiming without
making any assumptions about page sizes, and figured the change is
innocent enough. If it's deemed too pointless, then I'll just drop
the size in bytes from the debug message.
Kind regards,
Nicolas Frattaroli
>
> Thanks,
> Steve
>
> > for observability and debugging purposes. To that end, add a new
> > parameter "freed_sz", which is a pointer to a size_t where this
> > information will be stored. It may be NULL, in which case the
> > information isn't stored at all.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/gpu/drm/panthor/panthor_gem.c | 3 ++-
> > drivers/gpu/drm/panthor/panthor_mmu.c | 12 ++++++++++--
> > drivers/gpu/drm/panthor/panthor_mmu.h | 1 +
> > 3 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> > index 13295d7a593d..80e82238f3c5 100644
> > --- a/drivers/gpu/drm/panthor/panthor_gem.c
> > +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> > @@ -1511,7 +1511,8 @@ panthor_gem_shrinker_scan(struct shrinker *shrinker, struct shrink_control *sc)
> > goto out;
> >
> > freed += panthor_mmu_reclaim_priv_bos(ptdev, sc->nr_to_scan - freed,
> > - &remaining, panthor_gem_try_evict);
> > + &remaining, NULL,
> > + panthor_gem_try_evict);
> > if (freed >= sc->nr_to_scan)
> > goto out;
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> > index a7ee14986849..b81388b35a58 100644
> > --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> > +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> > @@ -3127,13 +3127,18 @@ int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec, struct panthor_vm
> > unsigned long
> > panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
> > unsigned int nr_to_scan, unsigned long *remaining,
> > + size_t *freed_sz,
> > bool (*shrink)(struct drm_gem_object *,
> > struct ww_acquire_ctx *))
> > {
> > + unsigned long newly_freed;
> > unsigned long freed = 0;
> > LIST_HEAD(remaining_vms);
> > LIST_HEAD(vms);
> >
> > + if (freed_sz)
> > + *freed_sz = 0;
> > +
> > mutex_lock(&ptdev->reclaim.lock);
> > list_splice_init(&ptdev->reclaim.vms, &vms);
> >
> > @@ -3152,8 +3157,11 @@ panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
> >
> > mutex_unlock(&ptdev->reclaim.lock);
> >
> > - freed += drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed,
> > - remaining, shrink, NULL);
> > + newly_freed = drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed,
> > + remaining, shrink, NULL);
> > + if (freed_sz)
> > + *freed_sz += panthor_vm_page_size(vm) * newly_freed;
> > + freed += newly_freed;
> >
> > mutex_lock(&ptdev->reclaim.lock);
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.h b/drivers/gpu/drm/panthor/panthor_mmu.h
> > index 3522fbbce369..12b18b5f90e1 100644
> > --- a/drivers/gpu/drm/panthor/panthor_mmu.h
> > +++ b/drivers/gpu/drm/panthor/panthor_mmu.h
> > @@ -52,6 +52,7 @@ int panthor_vm_evict_bo_mappings_locked(struct panthor_gem_object *bo);
> > unsigned long
> > panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
> > unsigned int nr_to_scan, unsigned long *remaining,
> > + size_t *freed_sz,
> > bool (*shrink)(struct drm_gem_object *,
> > struct ww_acquire_ctx *));
> > int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec,
> >
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/4] MAINTAINERS: Add sysfs ABI docs to list of panthor files
2026-05-06 10:45 [PATCH 0/4] Let userspace explicitly trigger memory reclaims Nicolas Frattaroli
2026-05-06 10:45 ` [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos Nicolas Frattaroli
@ 2026-05-06 10:45 ` Nicolas Frattaroli
2026-05-06 10:45 ` [PATCH 3/4] drm/panthor: Add explicit memory reclaim sysfs knob Nicolas Frattaroli
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Nicolas Frattaroli @ 2026-05-06 10:45 UTC (permalink / raw)
To: Boris Brezillon, Steven Price, Liviu Dudau, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig,
Nicolas Frattaroli
While the ABI documentation in Documentation/ABI/ does include a contact
person for each bit of ABI, this contact is not necessarily the same as
the maintainers for the driver it touches.
Add panthor-specific sysfs ABI as tracked files to MAINTAINERS for
panthor, to ensure that any changes to these files also go through the
panthor maintainers.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b897e9f4c73..f006ea21d99c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2205,6 +2205,7 @@ M: Liviu Dudau <liviu.dudau@arm.com>
L: dri-devel@lists.freedesktop.org
S: Supported
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
+F: Documentation/ABI/*/sysfs-driver-panthor-*
F: Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
F: drivers/gpu/drm/ci/xfails/panthor*
F: drivers/gpu/drm/panthor/
--
2.54.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 3/4] drm/panthor: Add explicit memory reclaim sysfs knob
2026-05-06 10:45 [PATCH 0/4] Let userspace explicitly trigger memory reclaims Nicolas Frattaroli
2026-05-06 10:45 ` [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos Nicolas Frattaroli
2026-05-06 10:45 ` [PATCH 2/4] MAINTAINERS: Add sysfs ABI docs to list of panthor files Nicolas Frattaroli
@ 2026-05-06 10:45 ` Nicolas Frattaroli
2026-05-06 10:45 ` [PATCH 4/4] drm/panthor: Add explicit memory claim " Nicolas Frattaroli
2026-05-06 15:06 ` [PATCH 0/4] Let userspace explicitly trigger memory reclaims Steven Price
4 siblings, 0 replies; 10+ messages in thread
From: Nicolas Frattaroli @ 2026-05-06 10:45 UTC (permalink / raw)
To: Boris Brezillon, Steven Price, Liviu Dudau, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig,
Nicolas Frattaroli
For deployments of systems with very tight memory and a system resource
manager process that can make well-founded decisions on trade-offs, a
way to tell panthor's GEM shrinker to run a reclaim on a specific
process immediately is of interest.
Make it possible to do this by adding a new sysfs file, called
"mem_reclaim", which kicks off a reclaim for private BOs owned by the
process whose TGID is written to the file.
Processes may trigger an explicit reclaim on themselves, but triggering
it on other processes requires the CAP_SYS_RESOURCE capability.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/ABI/testing/sysfs-driver-panthor-mem | 17 ++++++
drivers/gpu/drm/panthor/panthor_drv.c | 67 ++++++++++++++++++++++
drivers/gpu/drm/panthor/panthor_gem.c | 4 +-
drivers/gpu/drm/panthor/panthor_gem.h | 1 +
drivers/gpu/drm/panthor/panthor_mmu.c | 33 +++++++++++
drivers/gpu/drm/panthor/panthor_mmu.h | 2 +
6 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-panthor-mem b/Documentation/ABI/testing/sysfs-driver-panthor-mem
new file mode 100644
index 000000000000..6639394abed2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-panthor-mem
@@ -0,0 +1,17 @@
+What: /sys/bus/platform/drivers/panthor/.../mem_reclaim
+Date: May 2026
+Contact: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+Description:
+ (WO) Writing to this file will trigger a GPU memory reclaim run for all
+ panthor GPU contexts associated with the TGID written to it. The write
+ completes when the reclaim operation has finished.
+
+ To run a reclaim on a TGID other than its own, a process requires the
+ CAP_SYS_RESOURCE capability.
+
+ Possible error codes:
+ * -ERANGE: given TGID is too large/small for the TGID type.
+ * -EINVAL: given TGID could not be parsed.
+ * -EPERM: insufficient permissions to run a reclaim on given TGID
+ * -EINTR: interrupted by signal
+ * -ESRCH: given TGID is not using panthor, and might not exist at all
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
index 66996c9147c2..7d19b8785ea3 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1858,8 +1858,75 @@ static ssize_t profiling_store(struct device *dev,
static DEVICE_ATTR_RW(profiling);
+/**
+ * panthor_run_on_pfiles_of_tgid - Run function on each panthor_file of process
+ * @ptdev: pointer to the &struct panthor_device
+ * @tgid: The TGID of the process to look for
+ * @func: function pointer to run on every &struct panthor_file opened by @tgid
+ *
+ * Searches through the list of all panthor DRM files for ones that are opened
+ * by a process with TGID @tgid. For every match found, runs @func with the
+ * associated &struct panthor_file.
+ *
+ * Returns: negative errno on error, number of files matching @tgid otherwise.
+ */
+static int panthor_run_on_pfiles_of_tgid(struct panthor_device *ptdev, pid_t tgid,
+ void (*func)(struct panthor_file *pf))
+{
+ struct drm_file *file;
+ int found = 0;
+
+ scoped_cond_guard(mutex_intr, return -EINTR, &ptdev->base.filelist_mutex) {
+ list_for_each_entry(file, &ptdev->base.filelist, lhead) {
+ struct task_struct *task;
+ struct pid *file_pid;
+
+ rcu_read_lock();
+ file_pid = rcu_dereference(file->pid);
+ task = pid_task(file_pid, PIDTYPE_TGID);
+ if (!task || task->tgid != tgid) {
+ rcu_read_unlock();
+ continue;
+ }
+ rcu_read_unlock();
+ found++;
+ /* func needs to run outside RCU lock */
+ func(file->driver_priv);
+ }
+ }
+
+ return found;
+}
+
+static ssize_t mem_reclaim_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct panthor_device *ptdev = dev_get_drvdata(dev);
+ pid_t tgid;
+ int ret;
+
+ ret = kstrtoint(buf, 0, &tgid);
+ if (ret)
+ return ret;
+
+ if (tgid != current->tgid && !capable(CAP_SYS_RESOURCE))
+ return -EPERM;
+
+ ret = panthor_run_on_pfiles_of_tgid(ptdev, tgid, panthor_mmu_force_reclaim);
+ if (ret < 0)
+ return ret;
+ else if (!ret)
+ return -ESRCH;
+
+ return len;
+}
+
+static DEVICE_ATTR_WO(mem_reclaim);
+
static struct attribute *panthor_attrs[] = {
&dev_attr_profiling.attr,
+ &dev_attr_mem_reclaim.attr,
NULL,
};
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
index 80e82238f3c5..5780fd51170c 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.c
+++ b/drivers/gpu/drm/panthor/panthor_gem.c
@@ -1473,8 +1473,8 @@ static bool panthor_gem_try_evict_no_resv_wait(struct drm_gem_object *obj,
return ret == 0;
}
-static bool panthor_gem_try_evict(struct drm_gem_object *obj,
- struct ww_acquire_ctx *ticket)
+bool panthor_gem_try_evict(struct drm_gem_object *obj,
+ struct ww_acquire_ctx *ticket)
{
struct panthor_gem_object *bo = to_panthor_bo(obj);
diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h
index ae0491d0b121..593d8e7b7aaf 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.h
+++ b/drivers/gpu/drm/panthor/panthor_gem.h
@@ -254,6 +254,7 @@ panthor_gem_get_dev_sgt(struct panthor_gem_object *bo);
int panthor_gem_pin(struct panthor_gem_object *bo);
void panthor_gem_unpin(struct panthor_gem_object *bo);
int panthor_gem_swapin_locked(struct panthor_gem_object *bo);
+bool panthor_gem_try_evict(struct drm_gem_object *obj, struct ww_acquire_ctx *ticket);
void panthor_gem_update_reclaim_state_locked(struct panthor_gem_object *bo,
enum panthor_gem_reclaim_state *old_state);
int panthor_gem_shrinker_init(struct panthor_device *ptdev);
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index b81388b35a58..e185787f5657 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -3199,6 +3199,39 @@ panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
return freed;
}
+/**
+ * panthor_mmu_force_reclaim - Run a reclaim on all VMs associated with a file
+ * @pfile: pointer to the &struct panthor_file to reclaim memory on
+ *
+ * Attempt to evict all private BOs of VMs associated with @pfile. In other
+ * words, attempt to swap out as much GPU memory of the context associated with
+ * @pfile as possible.
+ */
+void panthor_mmu_force_reclaim(struct panthor_file *pfile)
+{
+ struct panthor_device *ptdev = pfile->ptdev;
+ unsigned long i, remaining, freed;
+ unsigned int nr_to_scan = 0;
+ struct panthor_vm *vm;
+ size_t freed_sz;
+
+ scoped_guard(mutex, &ptdev->reclaim.lock) {
+ xa_for_each(&pfile->vms->xa, i, vm) {
+ /* Skip VMs that already aren't backed by any pages */
+ if (!vm->reclaim.lru.count)
+ continue;
+
+ nr_to_scan += vm->reclaim.lru.count;
+ list_move(&vm->reclaim.lru_node, &ptdev->reclaim.vms);
+ }
+ }
+ freed = panthor_mmu_reclaim_priv_bos(ptdev, nr_to_scan, &remaining,
+ &freed_sz, panthor_gem_try_evict);
+ drm_dbg(&ptdev->base,
+ "Reclaimed %lu pages (%zu bytes) out of %u scanned, with %lu remaining\n",
+ freed, freed_sz, nr_to_scan, remaining);
+}
+
/**
* panthor_mmu_unplug() - Unplug the MMU logic
* @ptdev: Device.
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.h b/drivers/gpu/drm/panthor/panthor_mmu.h
index 12b18b5f90e1..34adca4b4e95 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.h
+++ b/drivers/gpu/drm/panthor/panthor_mmu.h
@@ -11,6 +11,7 @@
struct drm_exec;
struct drm_sched_job;
struct drm_memory_stats;
+struct panthor_file;
struct panthor_gem_object;
struct panthor_heap_pool;
struct panthor_vm;
@@ -23,6 +24,7 @@ void panthor_mmu_pre_reset(struct panthor_device *ptdev);
void panthor_mmu_post_reset(struct panthor_device *ptdev);
void panthor_mmu_suspend(struct panthor_device *ptdev);
void panthor_mmu_resume(struct panthor_device *ptdev);
+void panthor_mmu_force_reclaim(struct panthor_file *pfile);
int panthor_vm_map_bo_range(struct panthor_vm *vm, struct panthor_gem_object *bo,
u64 offset, u64 size, u64 va, u32 flags);
--
2.54.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 4/4] drm/panthor: Add explicit memory claim sysfs knob
2026-05-06 10:45 [PATCH 0/4] Let userspace explicitly trigger memory reclaims Nicolas Frattaroli
` (2 preceding siblings ...)
2026-05-06 10:45 ` [PATCH 3/4] drm/panthor: Add explicit memory reclaim sysfs knob Nicolas Frattaroli
@ 2026-05-06 10:45 ` Nicolas Frattaroli
2026-05-06 15:06 ` [PATCH 0/4] Let userspace explicitly trigger memory reclaims Steven Price
4 siblings, 0 replies; 10+ messages in thread
From: Nicolas Frattaroli @ 2026-05-06 10:45 UTC (permalink / raw)
To: Boris Brezillon, Steven Price, Liviu Dudau, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig,
Nicolas Frattaroli
For deployments of systems with very tight memory and a system resource
manager process that can make well-founded decisions on trade-offs, a
way to tell panthor that all of a process' swapped-out GPU memory should
be swapped back in without touching every page manually is of interest.
Make it possible to do this by adding a new sysfs file, called
"mem_claim". Writing a TGID to it will cause panthor to search through
all panthor_files associated with that process, and bring all its
buffers back from swap.
Doing this requires the writer to have the CAP_SYS_RESOURCE capability,
even when operating on themselves.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/ABI/testing/sysfs-driver-panthor-mem | 17 ++++++++++++++
drivers/gpu/drm/panthor/panthor_drv.c | 26 ++++++++++++++++++++++
drivers/gpu/drm/panthor/panthor_mmu.c | 25 +++++++++++++++++++++
drivers/gpu/drm/panthor/panthor_mmu.h | 1 +
4 files changed, 69 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-panthor-mem b/Documentation/ABI/testing/sysfs-driver-panthor-mem
index 6639394abed2..41e2c18f641d 100644
--- a/Documentation/ABI/testing/sysfs-driver-panthor-mem
+++ b/Documentation/ABI/testing/sysfs-driver-panthor-mem
@@ -15,3 +15,20 @@ Description:
* -EPERM: insufficient permissions to run a reclaim on given TGID
* -EINTR: interrupted by signal
* -ESRCH: given TGID is not using panthor, and might not exist at all
+
+What: /sys/bus/platform/drivers/panthor/.../mem_claim
+Date: May 2026
+Contact: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+Description:
+ (WO) Writing to this file will cause GPU memory for all panthor GPU
+ contexts associated with the TGID that's written to it to be brought
+ back from swap. The write completes when the operation has finished.
+
+ The writing process requires the CAP_SYS_RESOURCE capability.
+
+ Possible error codes:
+ * -ERANGE: given TGID is too large/small for the TGID type.
+ * -EINVAL: given TGID could not be parsed.
+ * -EPERM: insufficient permissions
+ * -EINTR: interrupted by signal
+ * -ESRCH: given TGID is not using panthor, and might not exist at all
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
index 7d19b8785ea3..fb2172b0439c 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1924,9 +1924,35 @@ static ssize_t mem_reclaim_store(struct device *dev,
static DEVICE_ATTR_WO(mem_reclaim);
+static ssize_t mem_claim_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct panthor_device *ptdev = dev_get_drvdata(dev);
+ pid_t tgid;
+ int ret;
+
+ ret = kstrtoint(buf, 0, &tgid);
+ if (ret)
+ return ret;
+
+ if (!capable(CAP_SYS_RESOURCE))
+ return -EPERM;
+
+ ret = panthor_run_on_pfiles_of_tgid(ptdev, tgid, panthor_mmu_force_claim);
+ if (ret < 0)
+ return ret;
+ else if (!ret)
+ return -ESRCH;
+
+ return len;
+}
+
+static DEVICE_ATTR_WO(mem_claim);
+
static struct attribute *panthor_attrs[] = {
&dev_attr_profiling.attr,
&dev_attr_mem_reclaim.attr,
+ &dev_attr_mem_claim.attr,
NULL,
};
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
index e185787f5657..7130ba4a24da 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.c
+++ b/drivers/gpu/drm/panthor/panthor_mmu.c
@@ -3232,6 +3232,31 @@ void panthor_mmu_force_reclaim(struct panthor_file *pfile)
freed, freed_sz, nr_to_scan, remaining);
}
+/**
+ * panthor_mmu_force_claim - Swap in all VMs associated with a file
+ * @pfile: pointer to the &struct panthor_file whose memory to swap in
+ *
+ * Attempt to get all GPU memory of @pfile swapped back in.
+ */
+void panthor_mmu_force_claim(struct panthor_file *pfile)
+{
+ struct panthor_vm *vm;
+ unsigned long i;
+ int ret;
+
+ xa_for_each(&pfile->vms->xa, i, vm) {
+ struct dma_resv *resv = drm_gpuvm_resv(&vm->base);
+
+ dma_resv_lock(resv, NULL);
+ ret = drm_gpuvm_validate(&vm->base, NULL);
+ if (ret)
+ drm_dbg(&vm->ptdev->base, "drm_gpuvm_validate failed: %pe\n",
+ ERR_PTR(ret));
+
+ dma_resv_unlock(resv);
+ }
+}
+
/**
* panthor_mmu_unplug() - Unplug the MMU logic
* @ptdev: Device.
diff --git a/drivers/gpu/drm/panthor/panthor_mmu.h b/drivers/gpu/drm/panthor/panthor_mmu.h
index 34adca4b4e95..460f83eb22a9 100644
--- a/drivers/gpu/drm/panthor/panthor_mmu.h
+++ b/drivers/gpu/drm/panthor/panthor_mmu.h
@@ -25,6 +25,7 @@ void panthor_mmu_post_reset(struct panthor_device *ptdev);
void panthor_mmu_suspend(struct panthor_device *ptdev);
void panthor_mmu_resume(struct panthor_device *ptdev);
void panthor_mmu_force_reclaim(struct panthor_file *pfile);
+void panthor_mmu_force_claim(struct panthor_file *pfile);
int panthor_vm_map_bo_range(struct panthor_vm *vm, struct panthor_gem_object *bo,
u64 offset, u64 size, u64 va, u32 flags);
--
2.54.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH 0/4] Let userspace explicitly trigger memory reclaims
2026-05-06 10:45 [PATCH 0/4] Let userspace explicitly trigger memory reclaims Nicolas Frattaroli
` (3 preceding siblings ...)
2026-05-06 10:45 ` [PATCH 4/4] drm/panthor: Add explicit memory claim " Nicolas Frattaroli
@ 2026-05-06 15:06 ` Steven Price
2026-05-06 15:43 ` Nicolas Frattaroli
4 siblings, 1 reply; 10+ messages in thread
From: Steven Price @ 2026-05-06 15:06 UTC (permalink / raw)
To: Nicolas Frattaroli, Boris Brezillon, Liviu Dudau,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig
On 06/05/2026 11:45, Nicolas Frattaroli wrote:
> RAM is not, in fact, cheap. Especially on embedded systems with a low
> amount of memory, but known and well-defined userspace, more explicit
> resource management can lead to better utilisation patterns. As an
> example, a resource manager process on a purpose-built device may wish
> to launch, and then explicitly swap out, memory of processes that are
> kept "warm", to improve perceived startup latency of individual
> full-screen applications without making the kernel figure out the usage
> pattern from observation alone in order to swap out the right pages.
Have you considered memory control groups (memcg) for this purpose?
Imposing a lower limit than currently allocated should trigger reclaim,
so 'background' applications could have the limit lowered and then
restored when moved to the foreground.
> To allow for this explicit control in the context of panthor's GPU
> memory, add two new sysfs knobs. The first, mem_reclaim, runs an
> explicit priv BO reclaim cycle on the TGID written to it.
>
> The second, mem_claim, does the opposite: it swaps BOs back into active
> memory.
How necessary is this mem_claim for performance? Have you done any
benchmarking of explicitly claiming vs just allowing it to happen
naturally? My gut feeling is that mem_claim should be unnecessary in
most situations, but I'm prepared to be proved wrong.
I'm not saying this series is necessarily the wrong approach - but I
think we need a bit more justification for adding a new API for this.
Thanks,
Steve
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> Nicolas Frattaroli (4):
> drm/panthor: Add freed_sz parameter to reclaim_priv_bos
> MAINTAINERS: Add sysfs ABI docs to list of panthor files
> drm/panthor: Add explicit memory reclaim sysfs knob
> drm/panthor: Add explicit memory claim sysfs knob
>
> Documentation/ABI/testing/sysfs-driver-panthor-mem | 34 ++++++++
> MAINTAINERS | 1 +
> drivers/gpu/drm/panthor/panthor_drv.c | 93 ++++++++++++++++++++++
> drivers/gpu/drm/panthor/panthor_gem.c | 7 +-
> drivers/gpu/drm/panthor/panthor_gem.h | 1 +
> drivers/gpu/drm/panthor/panthor_mmu.c | 70 +++++++++++++++-
> drivers/gpu/drm/panthor/panthor_mmu.h | 4 +
> 7 files changed, 205 insertions(+), 5 deletions(-)
> ---
> base-commit: 2c4b906cd135bbb44855287d0d0eff0ee0b47afe
> change-id: 20260506-panthor-explicit-reclaim-3dffed028d8c
>
> Best regards,
> --
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH 0/4] Let userspace explicitly trigger memory reclaims
2026-05-06 15:06 ` [PATCH 0/4] Let userspace explicitly trigger memory reclaims Steven Price
@ 2026-05-06 15:43 ` Nicolas Frattaroli
2026-05-06 15:55 ` Steven Price
0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Frattaroli @ 2026-05-06 15:43 UTC (permalink / raw)
To: Boris Brezillon, Liviu Dudau, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Steven Price
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig
On Wednesday, 6 May 2026 17:06:56 Central European Summer Time Steven Price wrote:
> On 06/05/2026 11:45, Nicolas Frattaroli wrote:
> > RAM is not, in fact, cheap. Especially on embedded systems with a low
> > amount of memory, but known and well-defined userspace, more explicit
> > resource management can lead to better utilisation patterns. As an
> > example, a resource manager process on a purpose-built device may wish
> > to launch, and then explicitly swap out, memory of processes that are
> > kept "warm", to improve perceived startup latency of individual
> > full-screen applications without making the kernel figure out the usage
> > pattern from observation alone in order to swap out the right pages.
>
> Have you considered memory control groups (memcg) for this purpose?
> Imposing a lower limit than currently allocated should trigger reclaim,
> so 'background' applications could have the limit lowered and then
> restored when moved to the foreground.
This is a suggestion in line with what I've made to the entity for
whom I am adding this, but was told that for them they really do want
tight control without having to use cgroups into technically doing it
by dynamically adjusting the limits of them.
I do think that writing 0 to `memory.high` to swap it out and `"max"`
to allow it to swap back in might work, though that'll then apply to
all of the process' memory, not just the GPU resources.
I will ask for clarification internally.
>
> > To allow for this explicit control in the context of panthor's GPU
> > memory, add two new sysfs knobs. The first, mem_reclaim, runs an
> > explicit priv BO reclaim cycle on the TGID written to it.
> >
> > The second, mem_claim, does the opposite: it swaps BOs back into active
> > memory.
>
> How necessary is this mem_claim for performance? Have you done any
> benchmarking of explicitly claiming vs just allowing it to happen
> naturally? My gut feeling is that mem_claim should be unnecessary in
> most situations, but I'm prepared to be proved wrong.
I've done no benchmarking, but can do so if you have any preferred
workloads for this. Since we have to keep entire groups either in
memory or out of memory right now AFAIK, I don't expect this to be
very beneficial at all. At most we avoid a single fault I think.
I can drop the mem_claim part, though it may become relevant if we
ever have more fine-grained memory eviction where a single job or
group can run into multiple faults before everything it needs to
render a new frame is back in memory. In that case, it will be
beneficial, because it avoids doing the swap-in dance several
times while the user wonders why the UI is rendering at powerpoint
speeds as it touches memory pages that are still swapped out during
subsequent frames.
>
> I'm not saying this series is necessarily the wrong approach - but I
> think we need a bit more justification for adding a new API for this.
>
> Thanks,
> Steve
Kind regards,
Nicolas Frattaroli
>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > Nicolas Frattaroli (4):
> > drm/panthor: Add freed_sz parameter to reclaim_priv_bos
> > MAINTAINERS: Add sysfs ABI docs to list of panthor files
> > drm/panthor: Add explicit memory reclaim sysfs knob
> > drm/panthor: Add explicit memory claim sysfs knob
> >
> > Documentation/ABI/testing/sysfs-driver-panthor-mem | 34 ++++++++
> > MAINTAINERS | 1 +
> > drivers/gpu/drm/panthor/panthor_drv.c | 93 ++++++++++++++++++++++
> > drivers/gpu/drm/panthor/panthor_gem.c | 7 +-
> > drivers/gpu/drm/panthor/panthor_gem.h | 1 +
> > drivers/gpu/drm/panthor/panthor_mmu.c | 70 +++++++++++++++-
> > drivers/gpu/drm/panthor/panthor_mmu.h | 4 +
> > 7 files changed, 205 insertions(+), 5 deletions(-)
> > ---
> > base-commit: 2c4b906cd135bbb44855287d0d0eff0ee0b47afe
> > change-id: 20260506-panthor-explicit-reclaim-3dffed028d8c
> >
> > Best regards,
> > --
> > Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> >
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 0/4] Let userspace explicitly trigger memory reclaims
2026-05-06 15:43 ` Nicolas Frattaroli
@ 2026-05-06 15:55 ` Steven Price
0 siblings, 0 replies; 10+ messages in thread
From: Steven Price @ 2026-05-06 15:55 UTC (permalink / raw)
To: Nicolas Frattaroli, Boris Brezillon, Liviu Dudau,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sumit Semwal, Christian König
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig
On 06/05/2026 16:43, Nicolas Frattaroli wrote:
> On Wednesday, 6 May 2026 17:06:56 Central European Summer Time Steven Price wrote:
>> On 06/05/2026 11:45, Nicolas Frattaroli wrote:
>>> RAM is not, in fact, cheap. Especially on embedded systems with a low
>>> amount of memory, but known and well-defined userspace, more explicit
>>> resource management can lead to better utilisation patterns. As an
>>> example, a resource manager process on a purpose-built device may wish
>>> to launch, and then explicitly swap out, memory of processes that are
>>> kept "warm", to improve perceived startup latency of individual
>>> full-screen applications without making the kernel figure out the usage
>>> pattern from observation alone in order to swap out the right pages.
>>
>> Have you considered memory control groups (memcg) for this purpose?
>> Imposing a lower limit than currently allocated should trigger reclaim,
>> so 'background' applications could have the limit lowered and then
>> restored when moved to the foreground.
>
> This is a suggestion in line with what I've made to the entity for
> whom I am adding this, but was told that for them they really do want
> tight control without having to use cgroups into technically doing it
> by dynamically adjusting the limits of them.
>
> I do think that writing 0 to `memory.high` to swap it out and `"max"`
> to allow it to swap back in might work, though that'll then apply to
> all of the process' memory, not just the GPU resources.
>
> I will ask for clarification internally.
Thanks, it would be good to have a better understanding of why GPU
memory is special (and needs to be paged out) and the process' other
memory can be kept.
>>
>>> To allow for this explicit control in the context of panthor's GPU
>>> memory, add two new sysfs knobs. The first, mem_reclaim, runs an
>>> explicit priv BO reclaim cycle on the TGID written to it.
>>>
>>> The second, mem_claim, does the opposite: it swaps BOs back into active
>>> memory.
>>
>> How necessary is this mem_claim for performance? Have you done any
>> benchmarking of explicitly claiming vs just allowing it to happen
>> naturally? My gut feeling is that mem_claim should be unnecessary in
>> most situations, but I'm prepared to be proved wrong.
>
> I've done no benchmarking, but can do so if you have any preferred
> workloads for this. Since we have to keep entire groups either in
> memory or out of memory right now AFAIK, I don't expect this to be
> very beneficial at all. At most we avoid a single fault I think.
Yes the memory should be brought back in as soon as a job is submitted.
I've no particular workloads in mind - but it would be nice to be able
to point to something that actually improves by adding this feature.
> I can drop the mem_claim part, though it may become relevant if we
> ever have more fine-grained memory eviction where a single job or
> group can run into multiple faults before everything it needs to
> render a new frame is back in memory. In that case, it will be
> beneficial, because it avoids doing the swap-in dance several
> times while the user wonders why the UI is rendering at powerpoint
> speeds as it touches memory pages that are still swapped out during
> subsequent frames.
We don't want to be faulting memory in a page at a time for exactly the
reasons you state. So even if we do make things more fine-grained we're
going to have to implement some form of read-ahead. Otherwise it's
"powerpoint time" after any even that causes memory pressure.
A possible justification is if the system can tell an application is
about to be used and can "pre-fault" things before rendering starts. But
it's a rare system design where it has this form of precognition.
Thanks,
Steve
>>
>> I'm not saying this series is necessarily the wrong approach - but I
>> think we need a bit more justification for adding a new API for this.
>>
>> Thanks,
>> Steve
>
> Kind regards,
> Nicolas Frattaroli
>
>>
>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>> ---
>>> Nicolas Frattaroli (4):
>>> drm/panthor: Add freed_sz parameter to reclaim_priv_bos
>>> MAINTAINERS: Add sysfs ABI docs to list of panthor files
>>> drm/panthor: Add explicit memory reclaim sysfs knob
>>> drm/panthor: Add explicit memory claim sysfs knob
>>>
>>> Documentation/ABI/testing/sysfs-driver-panthor-mem | 34 ++++++++
>>> MAINTAINERS | 1 +
>>> drivers/gpu/drm/panthor/panthor_drv.c | 93 ++++++++++++++++++++++
>>> drivers/gpu/drm/panthor/panthor_gem.c | 7 +-
>>> drivers/gpu/drm/panthor/panthor_gem.h | 1 +
>>> drivers/gpu/drm/panthor/panthor_mmu.c | 70 +++++++++++++++-
>>> drivers/gpu/drm/panthor/panthor_mmu.h | 4 +
>>> 7 files changed, 205 insertions(+), 5 deletions(-)
>>> ---
>>> base-commit: 2c4b906cd135bbb44855287d0d0eff0ee0b47afe
>>> change-id: 20260506-panthor-explicit-reclaim-3dffed028d8c
>>>
>>> Best regards,
>>> --
>>> Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>>
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread