On Tue, 7 Oct 2025 13:40:11 -0300
Daniel Almeida wrote:
> > On 7 Oct 2025, at 10:39, Daniel Almeida
> > wrote:
> >
> > Hi Dan, thanks for the review!
> >
> > […]
> >
> >>
> >>> +static void
> >>> +issue_store_multiple(u8 *command_stream, uint64_t kernel_va, uint32_t
> >>> constant)
> >
; Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 49 ++---
> 1 file changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/dr
scheduler tracepoints.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 6 --
> drivers/gpu/drm/panfrost/panfrost_job.c | 6 +-
> drivers/gpu/drm/panfrost/panfrost_job.h | 2 ++
> 3 files changed, 7 inse
On Tue, 7 Oct 2025 16:44:59 +0200
Danilo Krummrich wrote:
> On 9/30/25 1:57 PM, Boris Brezillon wrote:
> > Can you remind me what the problem is? I thought the lifetime issue was
> > coming from the fact the drm_sched ownership model was lax enough that
> > the job c
On Tue, 30 Sep 2025 12:30:03 +0200
Boris Brezillon wrote:
> > +unsigned long drm_gem_get_unmapped_area(struct file *filp, unsigned long
> > uaddr,
> > + unsigned long len, unsigned long pgoff,
> > +
in Yang
Reviewed-by: Boris Brezillon
> ---
> .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> b/Documentation/devicetree
On Sun, 28 Sep 2025 17:03:34 +0800
Rain Yang wrote:
> From: Rain Yang
>
> The regulator is optional, skip the setup instead of returning an
> error if it is not present
>
> Signed-off-by: Rain Yang
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panth
o get and put a vm_bo
> refcount on the vm_bo. This simplifies the code a lot. I preserved the
> behavior where panthor_gpuva_sm_step_map() drops the refcount right away
> rather than letting panthor_vm_cleanup_op_ctx() do it later.
>
> Signed-off-by: Alice Ryhl
Reviewed-by: Boris Br
ogram the JM to panfrosot_jm_* instead.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 14 +++
> drivers/gpu/drm/panfrost/panfrost_drv.c| 4 +-
> drivers/gpu/drm/panfrost/panfrost_job.c| 48
hat
> clears the interrupts and another one which unmasks them conditionally.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 9 ++---
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 +-
> driver
On Tue, 30 Sep 2025 12:58:29 +0200
"Danilo Krummrich" wrote:
> On Tue Sep 30, 2025 at 12:12 PM CEST, Boris Brezillon wrote:
> > So, my take on that is that what we want ultimately is to have the
> > functionality provided by drm_sched split into different
> >
ress and the total size to the debugging logs in order to
> help understand which batch an op is part of.
>
> Signed-off-by: Loïc Molinari
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_mmu.c | 19 ++-
> 1 file changed, 14 insertions(+), 5
On Mon, 29 Sep 2025 22:03:14 +0200
Loïc Molinari wrote:
> Introduce the 'panthor.transparent_hugepage' boolean module parameter
> (false by default). When the parameter is set to true, a new tmpfs
> mount point is created and mounted using the 'huge=within_size'
> option. It's then used at GEM ob
On Fri, 26 Sep 2025 17:07:22 +0800
Rain Yang wrote:
> From: Rain Yang
>
> The regulator is optional, skip the setup instead of returning an
> error if it is not present
AFAICT, it's not flagged optional in the DT bindings yet, so I'd prefer
to have this change and the DT bindings update in the
mf->address, page_to_pfn(page));
> + default:
Not sure about the error, but we should have something like
ret = VM_FAULT_FALLBACK;
break;
because otherwise ret is uninitialized. We probably want a WARN_ON()
too, because this function is not supposed
On Tue, 9 Sep 2025 13:39:39 +
Alice Ryhl wrote:
> On Tue, Sep 09, 2025 at 01:36:22PM +, Alice Ryhl wrote:
> > When using GPUVM in immediate mode, it is necessary to call
> > drm_gpuvm_unlink() from the fence signalling critical path. However,
> > unlink may call drm_gpuvm_bo_put(), which
On Wed, 10 Sep 2025 16:56:43 +0100
Steven Price wrote:
> On 10/09/2025 16:52, Boris Brezillon wrote:
> > On Wed, 10 Sep 2025 16:42:32 +0100
> > Steven Price wrote:
> >
> >>> +int panfrost_jm_ctx_create(struct drm_file *file,
> >>> +
On Thu, 11 Sep 2025 11:08:43 +
Alice Ryhl wrote:
> On Thu, Sep 11, 2025 at 12:15:37PM +0200, Boris Brezillon wrote:
> > On Tue, 09 Sep 2025 13:36:23 +
> > Alice Ryhl wrote:
> >
> > > static void panthor_vma_init(struct panthor_vma *vma, u32 fla
t
have been acquired after drm_gpuvm_bo_create()/::vm_bo_alloc() has
returned), this looks reasonable to me.
So here's my
Reviewed-by: Boris Brezillon
(stands even after the llist changes Thomas suggested).
> ---
> drivers/gpu/drm/drm_gpuvm.c | 174
> ++
On Mon, 8 Sep 2025 08:26:13 +
Alice Ryhl wrote:
> On Mon, Sep 08, 2025 at 09:11:40AM +0200, Boris Brezillon wrote:
> > Hi Alice,
> >
> > On Sun, 7 Sep 2025 11:39:41 +
> > Alice Ryhl wrote:
> >
> > > Yeah I guess we could have unlink remo
On Tue, 16 Sep 2025 10:58:40 +0200
Nicolas Frattaroli wrote:
> On Tuesday, 16 September 2025 06:21:10 Central European Summer Time Chia-I Wu
> wrote:
> > On Mon, Sep 15, 2025 at 10:52 AM Conor Dooley wrote:
> > >
> > > On Mon, Sep 15, 2025 at 06:51:16PM +0100, Conor Dooley wrote:
> > > > Ac
eamed yet.
> They might as well take a different form when upstreamed.
>
> Signed-off-by: Chia-I Wu
Reviewed-by: Boris Brezillon
>
> ---
> v2:
> - remove CONFIG_DRM_PANTHOR_SOC_MT8196 and panthor_soc*.[ch]
> - update commit message
> ---
> drivers/gpu/drm/pantho
On Tue, 09 Sep 2025 13:36:23 +
Alice Ryhl wrote:
> Instead of manually deferring cleanup of vm_bos, use the new GPUVM
> infrastructure for doing so.
>
> To avoid manual management of vm_bo refcounts, the panthor_vma_link()
> and panthor_vma_unlink() methods are changed to get and put a vm_bo
On Tue, 09 Sep 2025 13:36:23 +
Alice Ryhl wrote:
> Instead of manually deferring cleanup of vm_bos, use the new GPUVM
> infrastructure for doing so.
>
> To avoid manual management of vm_bo refcounts, the panthor_vma_link()
> and panthor_vma_unlink() methods are changed to get and put a vm_bo
On Tue, 9 Sep 2025 13:39:39 +
Alice Ryhl wrote:
> On Tue, Sep 09, 2025 at 01:36:22PM +, Alice Ryhl wrote:
> > When using GPUVM in immediate mode, it is necessary to call
> > drm_gpuvm_unlink() from the fence signalling critical path. However,
> > unlink may call drm_gpuvm_bo_put(), which
On Tue, 09 Sep 2025 13:36:23 +
Alice Ryhl wrote:
> static void panthor_vma_init(struct panthor_vma *vma, u32 flags)
> @@ -2084,12 +2010,12 @@ static int panthor_gpuva_sm_step_map(struct
> drm_gpuva_op *op, void *priv)
> if (ret)
> return ret;
>
> - /* Ref owned by
eloped-by: Beata Michalska
> Signed-off-by: Beata Michalska
> Co-developed-by: Carsten Haitzler
> Signed-off-by: Carsten Haitzler
> Co-developed-by: Rob Herring
> Signed-off-by: Rob Herring
>
> Link:
> https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html
> Signed-off-by: Daniel Almeida
Not that is really matters, but this is
Acked-by: Boris Brezillon
On Wed, 10 Sep 2025 16:42:32 +0100
Steven Price wrote:
> > +int panfrost_jm_ctx_create(struct drm_file *file,
> > + struct drm_panfrost_jm_ctx_create *args)
> > +{
> > + struct panfrost_file_priv *priv = file->driver_priv;
> > + struct panfrost_device *pfdev = priv->pfdev
On Mon, 08 Sep 2025 13:11:32 +0200
"Danilo Krummrich" wrote:
> On Mon Sep 8, 2025 at 12:20 PM CEST, Boris Brezillon wrote:
> > I'm not following. Yes there's going to be a
> > drm_gpuva_unlink_defer_put() that skips the
> >
> > va-&g
On Mon, 08 Sep 2025 10:47:25 +0200
"Danilo Krummrich" wrote:
> On Mon Sep 8, 2025 at 10:26 AM CEST, Alice Ryhl wrote:
> > On Mon, Sep 08, 2025 at 09:11:40AM +0200, Boris Brezillon wrote:
> >> Hi Alice,
> >>
> >> On Sun, 7 Sep 2025 11:39:41 +
t;> On Fri Sep 5, 2025 at 8:18 PM CEST, Alice Ryhl wrote:
> > >> > On Fri, Sep 5, 2025 at 3:25 PM Boris Brezillon
> > >> > wrote:
> > >> >> On Fri, 05 Sep 2025 12:11:28 +
> > >> >> Alice Ryhl
On Sun, 7 Sep 2025 11:15:20 +
Alice Ryhl wrote:
> On Sat, Sep 06, 2025 at 12:47:36AM +0200, Danilo Krummrich wrote:
> > On Fri Sep 5, 2025 at 8:18 PM CEST, Alice Ryhl wrote:
> > > On Fri, Sep 5, 2025 at 3:25 PM Boris Brezillon
> > > wrote:
> > >
On Wed, 3 Sep 2025 15:55:04 -0700
Chia-I Wu wrote:
> diff --git a/drivers/gpu/drm/panthor/Makefile
> b/drivers/gpu/drm/panthor/Makefile
> index 02db21748c125..75e92c461304b 100644
> --- a/drivers/gpu/drm/panthor/Makefile
> +++ b/drivers/gpu/drm/panthor/Makefile
> @@ -12,4 +12,6 @@ panthor-y :=
On Fri, 05 Sep 2025 12:11:29 +
Alice Ryhl wrote:
> static void panthor_vm_cleanup_op_ctx(struct panthor_vm_op_ctx *op_ctx,
> struct panthor_vm *vm)
> {
> - struct panthor_vma *vma, *tmp_vma;
> -
> u32 remaining_pt_count = op_ctx->rsvd_page_table
On Fri, 05 Sep 2025 12:11:28 +
Alice Ryhl wrote:
> When using GPUVM in immediate mode, it is necessary to call
> drm_gpuvm_unlink() from the fence signalling critical path. However,
> unlink may call drm_gpuvm_bo_put(), which causes some challenges:
>
> 1. drm_gpuvm_bo_put() often requires y
On Thu, 4 Sep 2025 16:54:38 +0200
Marek Vasut wrote:
> On 9/4/25 4:04 PM, Boris Brezillon wrote:
>
> Hello Boris,
>
> >>>> I suspect the extra soft reset I did before "un-halted" the GPU and
> >>>> allowed it to proceed.
> >>>
On Thu, 4 Sep 2025 15:49:31 +0200
Marek Vasut wrote:
> >> I suspect the extra soft reset I did before "un-halted" the GPU and
> >> allowed it to proceed.
> >
> > Hm, not quite. I mean, you still need to explicitly boot the MCU after
> > a reset, which is what the write to MCU_CONTROL [1] does.
Hello Marek,
On Wed, 3 Sep 2025 23:44:59 +0200
Marek Vasut wrote:
> On 3/25/25 3:52 PM, Boris Brezillon wrote:
>
> Hello Boris,
>
> sorry for the late reply.
>
> >>>>>>> Hm, that might be the cause of the fast reset issue (which is a fast
> >&
On Thu, 28 Aug 2025 13:01:16 -0700
Chia-I Wu wrote:
> Fail early from panthor_vm_bind_prepare_op_ctx instead of late from
> ops->map_pages.
>
> Signed-off-by: Chia-I Wu
> Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_mmu.c | 4 ++--
> 1 file
On Sat, 30 Aug 2025 10:12:32 +0200
Daniel Stone wrote:
> Hi Adrian,
>
> On Thu, 28 Aug 2025 at 04:35, Adrián Larumbe
> wrote:
> > -void panfrost_job_close(struct panfrost_file_priv *panfrost_priv)
> > +int panfrost_jm_ctx_destroy(struct drm_file *file, u32 handle)
> > {
> > - struct panf
parallel in
> each process, assign unique names to schedulers such that userspace can
> distinguish them.
>
> Signed-off-by: Chia-I Wu
Reviewed-by: Boris Brezillon
>
> ---
>
> v2:
> - include drm_client_id in the name to be truly unique
> - remove unnece
On Tue, 2 Sep 2025 12:20:01 -0700
Chia-I Wu wrote:
> A panthor group can have at most MAX_CS_PER_CSG panthor queues.
>
> Signed-off-by: Chia-I Wu
With a proper Fixes tag, this is
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 3 +++
>
Hi Steve,
On Mon, 1 Sep 2025 11:52:02 +0100
Steven Price wrote:
> On 28/08/2025 03:34, Adrián Larumbe wrote:
> > From: Boris Brezillon
> >
> > The new uAPI lets user space query the KM driver for the available
> > priorities a job can be given at submit time. These
Hi Adrian,
On Mon, 1 Sep 2025 09:18:49 +0100
Adrian Larumbe wrote:
> Hi Faith,
>
> On 22.08.2025 10:29, Faith Ekstrand wrote:
> > This enables syncing mapped GEM objects between the CPU and GPU via calls
> > to dma_sync_*(). It's a bit annoying as it requires walking the sg_table
> > so it's b
On Fri, 29 Aug 2025 16:02:50 -0700
Chia-I Wu wrote:
> Userspace relies on the ring field of gpu_scheduler tracepoints to
> identify a drm_gpu_scheduler. The value of the ring field is taken from
> sched->name.
>
> Because we typically have multiple schedulers running in parallel in
> each proce
On Thu, 28 Aug 2025 13:18:05 -0700
Chia-I Wu wrote:
> The values are written to ASN_HASH[0..2] registers. The property is
> called "l2-hash-values" in the downstream driver.
>
> Signed-off-by: Chia-I Wu
> ---
> .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 8
> 1 file ch
parallel in
> each process, assign unique names to schedulers such that userspace can
> distinguish them.
>
> Signed-off-by: Chia-I Wu
Reviewed-by: Boris Brezillon
Two minor comments below.
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 32 ++---
&g
tial panthor infrastructure
> tests/panthor: add panthor tests
Can't really comment on the patches themselves, as I have not been
working on IGT tests myself in while, but I'm really happy to see that
happening at last, so thanks a lot for doing that, and here's my
Acked-by
m_unpin() to unpin
> the backing pages for a shmem GEM.
With the subject prefixed with "drm/gem-shmem: " this is
Reviewed-by: Boris Brezillon
>
> WARNING: CPU: 2 PID: 1106 at drivers/gpu/drm/drm_gem_shmem_helper.c:180
> drm_gem_shmem_free+0x4d0/0x6f0
> Call trace:
On Sat, 23 Aug 2025 03:12:00 +0300
Dmitry Baryshkov wrote:
> Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM
> driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not
> allocate memptrs: -22" errors. The mentioned commit reworked the
> function, but didn't take
On Fri, 22 Aug 2025 10:29:12 -0400
Faith Ekstrand wrote:
It probably deserve a quick description of why this is needed (same for
the previous commit BTW).
> Signed-off-by: Faith Ekstrand
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 47 ++-
> drivers/gpu/drm/panthor/panth
On Fri, 22 Aug 2025 10:29:11 -0400
Faith Ekstrand wrote:
> From: Loïc Molinari
>
> Signed-off-by: Loïc Molinari
> Signed-off-by: Faith Ekstrand
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 7 ++-
> drivers/gpu/drm/panthor/panthor_gem.c | 3 +++
> include/uapi/drm/panthor_drm.h
On Fri, 22 Aug 2025 10:29:10 -0400
Faith Ekstrand wrote:
> This enables syncing mapped GEM objects between the CPU and GPU via calls
> to dma_sync_*(). It's a bit annoying as it requires walking the sg_table
> so it's best if every driver doesn't hand-roll it.
>
> Signed-off-by: Faith Ekstrand
+panthor/panfrost maintainers/devs
On Fri, 22 Aug 2025 10:29:09 -0400
Faith Ekstrand wrote:
> This series implements cached maps and explicit flushing for both panfrost
> and panthor. To avoid code/bug duplication, the tricky guts of the cache
> flusing ioctl which walk the sg list are broken i
On Fri, 22 Aug 2025 10:57:26 +
Alice Ryhl wrote:
> On Fri, Aug 22, 2025 at 11:52:21AM +0200, Boris Brezillon wrote:
> > On Fri, 22 Aug 2025 09:28:24 +
> >
> > Maybe it's time we start moving some bits of the gpuva field docs next
>
t should be safe to take this mutex during the fence
> + * signalling path, so do not allocate memory while holding
> + * this lock.
> + */
To follow-up on my comment on patch 1: this makes
drm_gem_object::gpuva::list the only field to not have a proper doc.
This patch is
Reviewed-by: Boris Brezillon
regardless.
Thanks,
Boris
nup is fence signalling safe is
> dubious and likely to be violated in practice.
>
> Panthor already has its own custom implementation of postponing vm_bo
> cleanup.
>
> Signed-off-by: Alice Ryhl
Reviewed-by: Boris Brezillon
One minor thing below.
> ---
> drivers/gpu/
On Thu, 21 Aug 2025 22:25:06 +0530
"Ghimiray, Himal Prasad" wrote:
> On 21-08-2025 19:05, Danilo Krummrich wrote:
> > On Thu Aug 21, 2025 at 3:01 PM CEST, Boris Brezillon wrote:
> >> On Thu, 21 Aug 2025 14:55:06 +0200
> >> "Danilo Krummrich" wro
On Thu, 21 Aug 2025 16:02:09 +0100
Steven Price wrote:
> On 21/08/2025 12:51, Boris Brezillon wrote:
> > On Wed, 16 Jul 2025 16:43:24 +0100
> > Steven Price wrote:
> [...]
> >> Although in general I'm a bit wary of relying on the whole lock region
> >&g
drm_gem_gpuva_set_lock(&obj->base.base, &obj->gpuva_list_lock);
> + drm_gem_gpuva_set_lock(&obj->base.base, &obj->base.base.gpuva.lock);
I guess this will go away in the previous patch in you follow Danilo's
advice to get rid of drm_gem_gpuva_set_lock(). The r
On Thu, 21 Aug 2025 14:55:06 +0200
"Danilo Krummrich" wrote:
> On Thu Aug 21, 2025 at 1:25 PM CEST, Boris Brezillon wrote:
> > On Thu, 21 Aug 2025 13:01:46 +0200
> > Boris Brezillon wrote:
> >> On a second thought, I'm now wondering why we need drm_gp
On Mon, 07 Jul 2025 21:33:13 +0200
"Danilo Krummrich" wrote:
> On Mon Jul 7, 2025 at 7:04 PM CEST, Caterina Shablia wrote:
> > From: Asahi Lina
> >
> > To be able to support "fake sparse" mappings without relying on GPU page
> > fault handling, drivers may need to create large (e.g. 4GiB) mappin
On Tue, 22 Jul 2025 20:21:25 +0100
Adrian Larumbe wrote:
> > /**
> > @@ -1074,6 +1079,9 @@ struct drm_gpuvm_map_req {
> > /** @offset: offset in the GEM */
> > u64 offset;
> > } gem;
> > +
> > + /** @flags: combination of DRM_GPUVA_ flags describing the mapping
> >
On Mon, 07 Jul 2025 21:06:50 +0200
"Danilo Krummrich" wrote:
> On Mon Jul 7, 2025 at 9:00 PM CEST, Danilo Krummrich wrote:
> > On Mon Jul 7, 2025 at 7:04 PM CEST, Caterina Shablia wrote:
> >> diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> >> index 05978c5c38b1..dc3c2f9
On Mon, 07 Jul 2025 21:00:54 +0200
"Danilo Krummrich" wrote:
> On Mon Jul 7, 2025 at 7:04 PM CEST, Caterina Shablia wrote:
> > diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> > index 05978c5c38b1..dc3c2f906400 100644
> > --- a/drivers/gpu/drm/drm_gpuvm.c
> > +++ b/drivers
On Tue, 22 Jul 2025 20:17:14 +0100
Adrian Larumbe wrote:
> On 07.07.2025 17:04, Caterina Shablia wrote:
> > From: Boris Brezillon
> >
> > We are going to add flags/properties that will impact the VA merging
> > ability. Instead of sprinkling tests all over the plac
On Mon, 07 Jul 2025 20:44:49 +0200
"Danilo Krummrich" wrote:
> On Mon Jul 7, 2025 at 7:04 PM CEST, Caterina Shablia wrote:
> > +/**
> > + * struct drm_gpuvm_map_req - arguments passed to
> > drm_gpuvm_sm_map[_ops_create]()
> > + */
> > +struct drm_gpuvm_map_req {
> > + /** @va: virtual address
On Wed, 16 Jul 2025 16:43:24 +0100
Steven Price wrote:
> >>> I think we need to briefly take vm->op_lock to ensure synchronisation
> >>> but that doesn't seem a big issue. Or perhaps there's a good reason that
> >>> I'm missing?
> >>
> >> I think you're right, all other accesses to locked_regio
On Fri, 11 Jul 2025 14:30:21 +0100
Steven Price wrote:
> On 07/07/2025 18:04, Caterina Shablia wrote:
> > From: Boris Brezillon
> >
> > Move the lock/flush_mem operations around the gpuvm_sm_map() calls so
> > we can implement true atomic page updates, where any acc
On Thu, 21 Aug 2025 13:01:46 +0200
Boris Brezillon wrote:
> On Wed, 20 Aug 2025 18:07:42 +0200
> Boris Brezillon wrote:
>
> > On Wed, 20 Aug 2025 20:53:35 +0530
> > Himal Prasad Ghimiray wrote:
> >
> > > Renamed 'map' to 'op' in drm
On Wed, 20 Aug 2025 18:07:42 +0200
Boris Brezillon wrote:
> On Wed, 20 Aug 2025 20:53:35 +0530
> Himal Prasad Ghimiray wrote:
>
> > Renamed 'map' to 'op' in drm_gpuvm_map_req for clarity and added
> > corresponding documentation. No functional changes
On Mon, 28 Jul 2025 12:24:02 +0100
Steven Price wrote:
> On 20/07/2025 01:01, Chia-I Wu wrote:
> > Create a devcoredump on any faulty or fatal event. The coredump data is
> > in YAML format for readability and flexibility.
> >
> > Only panthor_group state is captured for now.
> >
> > Signed-off
On Sat, 19 Jul 2025 17:01:46 -0700
Chia-I Wu wrote:
> When the flag is set, bo data is captured for devcoredump.
>
> Signed-off-by: Chia-I Wu
> ---
> drivers/gpu/drm/panthor/panthor_coredump.c | 36 ++
> drivers/gpu/drm/panthor/panthor_drv.c | 3 +-
> drivers/gpu/drm/
On Sat, 19 Jul 2025 17:01:45 -0700
Chia-I Wu wrote:
> Fail early from panthor_vm_bind_prepare_op_ctx instead of late from
> ops->map_pages.
>
> Signed-off-by: Chia-I Wu
Reviewed-by: Boris Brezillon
We can probably merge this one ahead of the coredump stuff.
> ---
> dr
se_ops_create")
> Fixes: 000a45dce7ad ("drm/gpuvm: Pass map arguments through a struct")
> Suggested-by: Boris Brezillon
> Suggested-by: Danilo Krummrich
> Cc: Danilo Krummrich
> Cc: Matt Coster
> Cc: Boris Brezillon
> Cc: Rob Clark
> Cc: Matthew Bros
On Tue, 19 Aug 2025 03:27:30 +0530
Himal Prasad Ghimiray wrote:
> From: Boris Brezillon
>
> We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
> so, before we do that, let's pass arguments through a struct instead
> of changing each call site every
On Tue, 8 Jul 2025 14:40:06 -0700
Chia-I Wu wrote:
> On Sun, Jun 22, 2025 at 11:32 PM Boris Brezillon
> wrote:
> >
> > On Wed, 18 Jun 2025 07:55:49 -0700
> > Chia-I Wu wrote:
> >
> > > It is unclear why fence errors were set only for CS_INHERIT_FAULT
On Mon, 30 Jun 2025 18:12:02 +0200
Danilo Krummrich wrote:
> On 6/30/25 6:06 PM, Boris Brezillon wrote:
> > On Sat, 28 Jun 2025 01:12:34 +0200
> > Danilo Krummrich wrote:
> >
> >>> +pub(crate) fn log(&self, pdev: &platform::Device) {
> >>
On Sat, 28 Jun 2025 01:12:34 +0200
Danilo Krummrich wrote:
> > +pub(crate) fn log(&self, pdev: &platform::Device) {
> > +let major = (self.gpu_id >> 16) & 0xff;
> > +let minor = (self.gpu_id >> 8) & 0xff;
> > +let status = self.gpu_id & 0xff;
> > +
> > +let mod
to using the pwrtrans_reg register instead. Fix the function
> to use the correct register.
>
> Fixes: 4d230aa209ed ("drm/panthor: Add 64-bit and poll register accessors")
> Signed-off-by: Steven Price
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/pant
On Wed, 18 Jun 2025 07:55:49 -0700
Chia-I Wu wrote:
> It is unclear why fence errors were set only for CS_INHERIT_FAULT.
> Downstream driver also does not treat CS_INHERIT_FAULT specially.
> Remove the check.
>
> Signed-off-by: Chia-I Wu
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
>
On Fri, 20 Jun 2025 16:50:51 -0700
Chia-I Wu wrote:
> We would like to access panthor_file from panthor_group on gpu errors.
> Because panthour_group can outlive drm_file, add refcount to
> panthor_file to ensure its lifetime.
I'm not a huge fan of refcounting panthor_file because people tend to
On Fri, 20 Jun 2025 16:50:50 -0700
Chia-I Wu wrote:
> It allows us to get rid of manual try_module_get / module_put.
>
> Signed-off-by: Chia-I Wu
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 14 +++---
> 1 file changed, 3 insertion
Hi,
On Fri, 13 Jun 2025 13:42:59 -0300
Daniel Almeida wrote:
> Danilo,
>
>
> >
> >
> +// SAFETY: DRM GpuVmBo objects are always reference counted and the
> get/put functions
> +// satisfy the requirements.
> +unsafe impl AlwaysRefCounted for GpuVmBo {
> +fn in
On Tue, 3 Jun 2025 10:49:31 +0100
Ashley Smith wrote:
> This fixes a bug where if we timeout after a suspend and the termination
> fails, due to waiting on a fence that will never be signalled for
> example, we do not resume the group correctly. The fix forces a reset
> for groups that are not t
On Fri, 6 Jun 2025 10:09:30 +0200
Boris Brezillon wrote:
> Hello,
>
> This is an attempt a couple bugs exposed by FEX-Emu. The first one
> is pretty trivial and should be uncontroversial, since it's just
> a missing padding field in one of our uAPI structs. We are getti
On Fri, 6 Jun 2025 12:18:33 +0200
Boris Brezillon wrote:
> Hi all,
>
> This patch series adds support for 64-bit and poll register accessors in
> the Panthor DRM driver and performs a cleanup of the 64-bit register
> definitions.
>
> The first patch introduces new
Price
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Karunika Choo
---
drivers/gpu/drm/panthor/panthor_drv.c | 4 +-
drivers/gpu/drm/panthor/panthor_gpu.c | 8 +--
drivers/gpu/drm/panthor/panthor_gpu.h | 10 +--
drivers/gpu/drm/panthor/panthor_mmu.c | 16
Hi all,
This patch series adds support for 64-bit and poll register accessors in
the Panthor DRM driver and performs a cleanup of the 64-bit register
definitions.
The first patch introduces new accessor functions to simplify and
standardize 64-bit and polling register operations. The second patch
Price
Reviewed-by: Boris Brezillon
Signed-off-by: Karunika Choo
---
drivers/gpu/drm/panthor/panthor_device.h | 71 ++
drivers/gpu/drm/panthor/panthor_drv.c| 4 +-
drivers/gpu/drm/panthor/panthor_fw.c | 9 +-
drivers/gpu/drm/panthor/panthor_gpu.c| 159
SET_USER_MMIO_OFFSET
requests to race with mmap() requests
- Don't do the is_user_mmio_offset test twice in panthor_mmap()
- Improve the uAPI docs
Changes in v3:
- Bump to version 1.5 instead of 1.4 after rebasing
- Add R-bs
- Fix/rephrase comment as suggested by Liviu
Signed-off-by: Boris Brezi
we need
Changes in v3:
- Fix a comment
[1]https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34573
Boris Brezillon (2):
drm/panthor: Add missing explicit padding in drm_panthor_gpu_info
drm/panthor: Fix the user MMIO offset logic for emulators
drivers/gpu/drm/panthor/p
hor
which are either arm32 or arm64 where the 64-bit alignment of
u64 fields is already enforced a the compiler level.
Changes in v2:
- Rename the garbage field into pad0 and adjust the comment accordingly
- Add Liviu's A-b
Changes in v3:
- Add R-bs
Fixes: 0f25e493a246 ("drm/panthor: A
On Wed, 04 Jun 2025 11:01:27 +0100
Ashley Smith wrote:
> On Tue, 03 Jun 2025 12:09:44 +0100 Liviu Dudau
> wrote:
> > On Tue, Jun 03, 2025 at 10:49:31AM +0100, Ashley Smith wrote:
> > > This fixes a bug where if we timeout after a suspend and the
> > > termination fails, due to waiting on a
On Mon, 19 May 2025 15:50:19 +0100
Ashley Smith wrote:
> This fixes a bug where if we timeout after a suspend and the termination
> fails, due to waiting on a fence that will never be signalled for
> example, we do not resume the group correctly. The fix forces a reset
> for groups that are not t
aces due to
> > drm_sched_suspend_timeout() not having a lock. Another issue seems to
> > be in queue_run_job() if the group is not scheduled, we suspend the
> > timeout again which undoes what drm_sched_job_begin() did when calling
> > drm_sched_start_timeout(). So the timeout
llowed in their creation, they might remain
> unlabelled for their entire lifetime, so a generic tag was deemed
> preferable. The tag is assigned before a UM handle is created so it
> doesn't contradict the logic about labelling internal BOs.
>
> Signed-off-by: Adrián Lar
jects as reclaimable.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 5 +
> drivers/gpu/drm/panfrost/panfrost_device.h | 15 +++
> drivers/gpu/drm/panfrost/panfrost_drv.c| 35 ++
> drivers/gp
abels through a new ioctl().
>
> Signed-off-by: Adrián Larumbe
> Reviewed-by: Steven Price
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.c | 42 +
> drivers/gpu/drm/panfrost/panfrost_gem.h | 17 ++
> 2 files chang
lows
> Panfrost naming conventions.
>
> Signed-off-by: Adrián Larumbe
> Fixes: 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device
> frequency")
I don't we want to backport this patch, so would drop the Fixes tag.
Reviewed-by: Boris Brezillon
>
1 - 100 of 1774 matches
Mail list logo
