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
>
that are not terminated correctly.
>
> Signed-off-by: Ashley Smith
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_sch
On Wed, 7 May 2025 14:01:04 +0100
Adrián Larumbe wrote:
> On 06.05.2025 08:54, Boris Brezillon wrote:
> > On Thu, 24 Apr 2025 03:21:30 +0100
> > Adrián Larumbe wrote:
> >
> > > Unlike in Panthor, from where this change is based on, there is no need
> > >
On Thu, 24 Apr 2025 03:21:30 +0100
Adrián Larumbe wrote:
> Unlike in Panthor, from where this change is based on, there is no need
> to support tagging of BO's other than UM-exposed ones, so all strings
> can be freed with kfree().
>
> This commit is done in preparation of a following one that w
On Thu, 24 Apr 2025 03:21:32 +0100
Adrián Larumbe wrote:
> This change is essentially a Panfrost port of commit a3707f53eb3f
> ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS").
>
> The DebugFS file is almost the same as in Panthor, minus the GEM object
> usage flags, since
On Thu, 24 Apr 2025 03:21:31 +0100
Adrián Larumbe wrote:
> Allow UM to label a BO for which it possesses a DRM handle.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 44 -
> driver
On Wed, 30 Apr 2025 11:07:17 +0200
Simona Vetter wrote:
> On Wed, Apr 16, 2025 at 11:38:03AM +0200, Simona Vetter wrote:
> > On Wed, Apr 16, 2025 at 08:57:45AM +0200, Thomas Zimmermann wrote:
> > > Test struct drm_gem_object.import_attach to detect imported objects.
> > >
> > > During object c
On Thu, 24 Apr 2025 19:40:34 +0100
Adrián Larumbe wrote:
> Commit a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM
> objects over DebugFS") causes a build warning and linking error when
> built without support for DebugFS, because of a non-inline non-static
> function declaration in a
Hi Iago,
On Mon, 28 Apr 2025 08:55:07 +0200
Iago Toral wrote:
> Hi,
>
> Pitching in to describe the situation for v3d:
Thanks for chiming in.
>
> El vie, 18-04-2025 a las 14:25 +0200, Boris Brezillon escribió:
>
> (...)
> > +For all these reasons, the til
Hi Steve,
On Wed, 23 Apr 2025 10:41:53 +0100
Steven Price wrote:
> On 18/04/2025 13:25, Boris Brezillon wrote:
> > Tile-based GPUs come with a set of constraints that are not present
> > when immediate rendering is used. This new document tries to explain
> > the dif
Hi Alyssa,
On Wed, 23 Apr 2025 10:47:21 -0400
Alyssa Rosenzweig wrote:
> Steven wanted non-Mali eyes, so with my Imaginapple hat on...
>
> > +All lot of embedded GPUs are using tile-based rendering instead of
> > immediate
>
> s/All lot of/Many/
Will change that.
>
> > +- Complex geometr
h is just an artifact of the import. Prepares
> > to make import_attach optional.
> >
> > Signed-off-by: Thomas Zimmermann
> > Cc: Boris Brezillon
> > Cc: Steven Price
> > Cc: Liviu Dudau
> > ---
> > drivers/gpu/drm/panthor/panthor_gem.c | 2 +-
&g
On Thu, 24 Apr 2025 14:10:16 +0200
"Arnd Bergmann" wrote:
> On Thu, Apr 24, 2025, at 13:41, Boris Brezillon wrote:
> > On Thu, 24 Apr 2025 13:25:47 +0200
> >> +#ifdef CONFIG_DEBUG_FS
> >>bo->debugfs.flags = usage_flags |
> &g
On Thu, 24 Apr 2025 13:25:47 +0200
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When debugfs is disabled, including panthor_gem.h causes warnings
> about a non-static global function defined in a header:
>
> In file included from drivers/gpu/drm/panthor/panthor_drv.c:30:
> drivers/gpu/drm/pa
On Wed, 23 Apr 2025 03:12:30 +0100
Adrián Larumbe wrote:
> This patch series is aimed at providing UM with detailed memory profiling
> information in debug builds. It is achieved through a device-wide list of
> DRM GEM objects, and also implementing the ability to label BO's from UM
> through a n
On Wed, 23 Apr 2025 09:01:49 +0200
Boris Brezillon wrote:
> > +
> > +enum panthor_debugfs_gem_usage_flags {
> > + PANTHOR_DEBUGFS_GEM_USAGE_KERNEL_BIT = 0,
> > + PANTHOR_DEBUGFS_GEM_USAGE_FW_MAPPED_BIT = 1,
>
> Now that you print the flags as raw hex value
1 - 100 of 1759 matches
Mail list logo
