From: Eric Anholt
X/Y positioning of T-format buffers is quite tricky and the current
implementation was failing to position a plane using this format
correctly when the X, Y or both X and Y offsets were negative.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
Hi Eric,
I kept
from drm_plane_state.
Incidentally, it seems to fix a problem we had with negative X/Y
positioning of YUV planes.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_drv.h | 9 --
drivers/gpu/drm/vc4/vc4_plane.c | 210
On Tue, 24 Jul 2018 15:32:15 +0200
Boris Brezillon wrote:
> Async plane update is supposed to work only when updating the FB or FB
> position of an already enabled plane. That does not apply to requests
> where the plane was previously disabled or assigned to a different
> CTRC
On Tue, 24 Jul 2018 15:33:00 +0200
Boris Brezillon wrote:
> drm_atomic_helper_async_check() declares the plane, old_plane_state and
> new_plane_state variables to iterate over all planes of the atomic
> state and make sure only one plane is enabled.
>
> Unfortunately gcc is not
On Tue, 24 Jul 2018 15:36:01 +0200
Boris Brezillon wrote:
> This is needed to ensure ->is_unity is correct when the plane was
> previously configured to output a multi-planar format with scaling
> enabled, and is then being reconfigured to output a uniplanar format.
>
> F
On Fri, 27 Jul 2018 13:38:08 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > From: Eric Anholt
> >
> > drm_atomic_helper_check_plane_state() takes care of checking the
> > scaling capabilities and calculating the clipped X/Y offsets for us.
> >
On Wed, 25 Jul 2018 17:32:08 +0200
Boris Brezillon wrote:
> From: Eric Anholt
>
> The offset adjustment depends on the framebuffer modified, so let's
^ modifier
> just move this operation in the DRM_FORMAT_MOD_L
On Fri, 27 Jul 2018 13:46:31 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > From: Eric Anholt
> >
> > X/Y positioning of T-format buffers is quite tricky and the current
> > implementation was failing to position a plane using this format
> > cor
On Fri, 3 Aug 2018 09:23:05 +0200
Peter Rosin wrote:
> Hi!
>
> This is perhaps not a true resend in that these three patches were
> originally in a larger series [1], and the series have been rebased
> to v4.18-rc6. However, I did ask that these three patches should be
> considered separately.
On Fri, 27 Jul 2018 13:55:03 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > When there's no scaling requested ->is_unity should be true no matter
> > the format.
> >
> > Also, when no scaling is requested and we have a multi-planar YUV
> &g
On Fri, 27 Jul 2018 13:46:31 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > From: Eric Anholt
> >
> > X/Y positioning of T-format buffers is quite tricky and the current
> > implementation was failing to position a plane using this format
> > cor
From: Eric Anholt
Y_OFFSET field starts at bit 8 not 7.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
Changes in v2:
- None
---
drivers/gpu/drm/vc4/vc4_regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu
From: Eric Anholt
This is needed to support X/Y negative placement of planes using
T-format buffers.
Signed-off-by: Eric Anholt
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Fixed typo in commit subject line
---
drivers/gpu/drm/vc4/vc4_regs.h | 4
1 file changed, 4 insertions
X/Y positioning of T-format buffers is quite tricky and the current
implementation was failing to position a plane using this format
correctly when the CRTC X, Y or both X and Y offsets were negative.
It was also failing when the SRC X/Y offsets were != 0.
Signed-off-by: Boris Brezillon
Reviewed
: Boris Brezillon
---
Changes in v2:
- Grabbed authorship and dropped Eric's SoB
- Re-introduced vc4_state->crtc/src_x/y/w/h fields
---
drivers/gpu/drm/vc4/vc4_plane.c | 102
1 file changed, 52 insertions(+), 50 deletions(-)
diff --git a/drivers
ned-off-by: Boris Brezillon
---
Changes in v2:
- Fixed a typo in the commit message
---
drivers/gpu/drm/vc4/vc4_plane.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 26
On Mon, 06 Aug 2018 13:02:48 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > From: Eric Anholt
> >
> > Y_OFFSET field starts at bit 8 not 7.
> >
> > Signed-off-by: Eric Anholt
> > Signed-off-by: Boris Brezillon
>
> Your changes i
On Wed, 21 Aug 2024 11:37:27 -0300
Daniel Almeida wrote:
> This is of interest to userspace, and similar in nature to the GPU
> and CSIF information we already return in the query ioctl.
>
> Signed-off-by: Daniel Almeida
> ---
> drivers/gpu/drm/panthor/panthor_device.h | 3 +++
> drivers/gpu/
Hi Daniel
On Wed, 21 Aug 2024 11:37:28 -0300
Daniel Almeida wrote:
[...]
> +static void *alloc_bytes(struct dump_allocator *alloc, size_t size)
> +{
> + void *ret;
> +
> + if (alloc->pos + size > alloc->capacity)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = alloc->curr;
H
On Mon, 19 Aug 2024 13:25:08 +0200
Mary Guillemard wrote:
> +/**
> + * struct drm_panthor_timestamp_info - Timestamp information
> + *
> + * Structure grouping all queryable information relating to the GPU
> timestamp.
> + */
> +struct drm_panthor_timestamp_info {
> + /** @timestamp_frequenc
Hi Mihail,
On Thu, 8 Aug 2024 12:41:05 +0300
Mihail Atanassov wrote:
> >
> > +/** + * struct drm_panthor_timestamp_info - Timestamp information +
> > * + * Structure grouping all queryable information relating to the
> > GPU timestamp. + */ +struct drm_panthor_timestamp_info { + /**
> > @times
On Wed, 28 Aug 2024 14:22:51 +0100
Mihail Atanassov wrote:
> Hi Boris,
>
> On 28/08/2024 13:09, Boris Brezillon wrote:
> > Hi Mihail,
> >
> > On Thu, 8 Aug 2024 12:41:05 +0300
> > Mihail Atanassov wrote:
> >
> >>>
> >>> +/*
On Wed, 28 Aug 2024 18:07:03 +0200
Boris Brezillon wrote:
> On Wed, 28 Aug 2024 14:22:51 +0100
> Mihail Atanassov wrote:
>
> > Hi Boris,
> >
> > On 28/08/2024 13:09, Boris Brezillon wrote:
> > > Hi Mihail,
> > >
> > > On Thu, 8
On Wed, 28 Aug 2024 18:37:41 +0100
Mihail Atanassov wrote:
> On 28/08/2024 18:27, Boris Brezillon wrote:
> > On Wed, 28 Aug 2024 18:07:03 +0200
> > Boris Brezillon wrote:
> >
> >> On Wed, 28 Aug 2024 14:22:51 +0100
> >> Mihail Atanassov wrote:
>
e's nothing invalid there.
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: "Christian König"
Cc: Danilo Krummrich
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/scheduler/sched_fence.c | 8 +++-
drivers/gpu/drm/scheduler/sched_main.c | 18 -
include/drm/gpu_scheduler.h
Hi Christian,
On Fri, 30 Aug 2024 10:14:18 +0200
Christian König wrote:
> Am 29.08.24 um 19:12 schrieb Boris Brezillon:
> > dma_fence objects created by an entity might outlive the
> > drm_gpu_scheduler this entity was bound to if those fences are retained
> > by other
fence code is always
statically linked, just like dma-fence{-chain}.c does.
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: "Christian König"
Cc: Danilo Krummrich
Signed-off-by: Boris Brezillon
---
Just like for the other UAF fix, this is an RFC, as I'm not sure that's
how we want i
On Fri, 30 Aug 2024 11:37:21 +0200
Boris Brezillon wrote:
> > > With the introduction of a new model where each entity has its own
> > > drm_gpu_scheduler instance, this situation is likely to happen every time
> > > a GPU context is destroyed and some of it
On Fri, 30 Aug 2024 21:43:44 +
Matthew Brost wrote:
> On Fri, Aug 30, 2024 at 10:14:18AM +0200, Christian König wrote:
> > Am 29.08.24 um 19:12 schrieb Boris Brezillon:
> > > dma_fence objects created by an entity might outlive the
> > > drm_gpu_scheduler this e
Hi Matthew,
On Fri, 30 Aug 2024 22:28:19 +
Matthew Brost wrote:
> On Fri, Aug 30, 2024 at 12:40:57PM +0200, Boris Brezillon wrote:
> > dma_fence objects created by drm_sched might hit other subsystems, which
> > means the fence object might potentially outlive the d
> > Acked-by: Liviu Dudau
>
> Reviewed-by: Steven Price
Reviewed-by: Boris Brezillon
>
> > ---
> > drivers/gpu/drm/panthor/panthor_fw.c | 8 +++-
> > drivers/gpu/drm/panthor/panthor_mmu.c | 21 ++---
> > drivers/gpu/drm/panthor/panth
On Tue, 3 Sep 2024 21:43:48 +0200
Simona Vetter wrote:
> On Thu, Feb 29, 2024 at 05:22:24PM +0100, Boris Brezillon wrote:
> > - Add our job fence as DMA_RESV_USAGE_WRITE to all external objects
> > (was previously DMA_RESV_USAGE_BOOKKEEP). I don't get why, given
> &
; + sizeof(struct
> panthor_job_profiling_data),
> + DRM_PANTHOR_BO_NO_MMAP,
> + DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
> + DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
> + PANTHOR_VM_KERNEL_AUTO_VA);
> +
> + if (IS_ERR(queue->profiling_info.slots)) {
> + ret = PTR_ERR(queue->profiling_info.slots);
> + goto err_free_queue;
> + }
> +
> + ret = panthor_kernel_bo_vmap(queue->profiling_info.slots);
> + if (ret)
> + goto err_free_queue;
> +
> + memset(queue->profiling_info.slots->kmap, 0,
> +queue->profiling_info.slot_count * sizeof(struct
> panthor_job_profiling_data));
I don't think we need to memset() the profiling buffer.
> +
> + /*
> + * Credit limit argument tells us the total number of instructions
> + * across all CS slots in the ringbuffer, with some jobs requiring
> + * twice as many as others, depending on their profiling status.
> + */
> ret = drm_sched_init(&queue->scheduler, &panthor_queue_sched_ops,
>group->ptdev->scheduler->wq, 1,
> - args->ringbuf_size / (NUM_INSTRS_PER_SLOT *
> sizeof(u64)),
> + args->ringbuf_size / sizeof(u64),
>0, msecs_to_jiffies(JOB_TIMEOUT_MS),
>group->ptdev->reset.wq,
>NULL, "panthor-queue", group->ptdev->base.dev);
> @@ -3354,6 +3585,7 @@ panthor_job_create(struct panthor_file *pfile,
> {
> struct panthor_group_pool *gpool = pfile->groups;
> struct panthor_job *job;
> + u32 credits;
> int ret;
>
> if (qsubmit->pad)
> @@ -3407,9 +3639,16 @@ panthor_job_create(struct panthor_file *pfile,
> }
> }
>
> + job->profile_mask = pfile->ptdev->profile_mask;
> + credits = calc_job_credits(job->profile_mask);
> + if (credits == 0) {
> + ret = -EINVAL;
> + goto err_put_job;
> + }
> +
> ret = drm_sched_job_init(&job->base,
>&job->group->queues[job->queue_idx]->entity,
> - 1, job->group);
> + credits, job->group);
> if (ret)
> goto err_put_job;
>
Just add a bunch of minor comments (mostly cosmetic changes), but the
implementation looks good to me.
Reviewed-by: Boris Brezillon
On Tue, 3 Sep 2024 21:25:36 +0100
Adrián Larumbe wrote:
> Drawing from the FW-calculated values in the previous commit, we can
> increase the numbers for an open file by collecting them from finished jobs
> when updating their group synchronisation objects.
>
> Display of fdinfo key-value pairs
> Signed-off-by: Adrián Larumbe
> Reviewed-by: Liviu Dudau
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_gem.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c
> b/drivers/gpu
On Tue, 3 Sep 2024 21:25:38 +0100
Adrián Larumbe wrote:
> This commit introduces a DRM device sysfs attribute that lets UM control
> the job accounting status in the device. The knob variable had been brought
> in as part of a previous commit, but now we're able to fix it manually.
>
> As sysfs
hor_gpu_read_64bit_counter
>
> v4:
> - Fix multiple typos in uAPI documentation
> - Mention behavior when the timestamp frequency is unknown
> - Use u64 instead of unsigned long long
> for panthor_gpu_read_timestamp
> - Apply r-b from Mihail
>
> Signed-off-by: Mary Guil
On Wed, 4 Sep 2024 11:46:54 +0200
Simona Vetter wrote:
> On Wed, Sep 04, 2024 at 09:40:36AM +0200, Christian König wrote:
> > Am 03.09.24 um 10:13 schrieb Simona Vetter:
> > > [SNIP]
> > > > > So I think the issue is much, much bigger, and there's more. And the
> > > > > issue is I think a fu
On Wed, 4 Sep 2024 12:03:24 +0200
Simona Vetter wrote:
> On Wed, Sep 04, 2024 at 11:46:54AM +0200, Simona Vetter wrote:
> > On Wed, Sep 04, 2024 at 09:40:36AM +0200, Christian König wrote:
> > > Am 03.09.24 um 10:13 schrieb Simona Vetter:
> > > > [SNIP]
> > > > > > So I think the issue is m
r logical block")
> Cc: sta...@vger.kernel.org
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 23 +++
> drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
> include/uapi/drm/panthor_drm.h | 6 +-
> 3 files chan
On Wed, 4 Sep 2024 10:31:36 +0100
Steven Price wrote:
> On 04/09/2024 08:49, Christian König wrote:
> > Am 03.09.24 um 23:11 schrieb Simona Vetter:
> >> On Tue, Sep 03, 2024 at 03:46:43PM +0200, Christian König wrote:
> >>> Hi Steven,
> >>>
> >>> Am 29.08.24 um 15:37 schrieb Steven Price:
>
+ Adrian, who has been looking at the shrinker stuff for Panthor
On Wed, 4 Sep 2024 13:46:12 +0100
Steven Price wrote:
> On 04/09/2024 12:34, Christian König wrote:
> > Hi Boris,
> >
> > Am 04.09.24 um 13:23 schrieb Boris Brezillon:
> >>>>>> P
On Wed, 4 Sep 2024 14:35:12 +0100
Steven Price wrote:
> On 04/09/2024 14:20, Boris Brezillon wrote:
> > + Adrian, who has been looking at the shrinker stuff for Panthor
> >
> > On Wed, 4 Sep 2024 13:46:12 +0100
> > Steven Price wrote:
> >
> >>
out Xe was wrong, and we really want bookkeep on
all registered fences, so userspace can explicitly upgrade those to
read/write when needed.
Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block")
Cc: Matthew Brost
Cc: Simona Vetter
Cc:
Signed-off-by: Boris Brezillon
---
d
d out before the deferred SYNC_{SET,ADD}
is executed, we'll end up with a timeout, because no external
SYNC_{SET,ADD} will make the scheduler reconsider the group for
execution.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Cc:
Signed-off-by: Boris Brezillon
On Tue, 3 Sep 2024 16:49:55 +0200
Mary Guillemard wrote:
> We were allowing any users to create a high priority group without any
> permission checks. As a result, this was allowing possible denial of
> service.
>
> We now only allow the DRM master or users with the CAP_SYS_NICE
> capability to
On Wed, 4 Sep 2024 12:19:11 +0200
Boris Brezillon wrote:
> On Fri, 30 Aug 2024 10:03:50 +0200
> Mary Guillemard wrote:
>
> > Expose timestamp information supported by the GPU with a new device
> > query.
> >
> > Mali uses an external timer as GPU system time.
On Mon, 2 Sep 2024 16:11:51 +0100
Steven Price wrote:
> On 02/09/2024 14:02, Adrián Larumbe wrote:
> > In the off-chance that waiting for the firmware to signal its booted status
> > timed out in the fast reset path, one must flush the cache lines for the
> > entire FW VM address space before rel
gt; is being used.
>
> Signed-off-by: Steven Price
Just one formatting issue mentioned below, looks good otherwise.
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 55
> 1 file changed, 55 insertions(+)
>
> diff --git a/dri
struct
> drm_panthor_group_priorities_info *arg)
> +{
> + int prio;
> +
> + for (prio = PANTHOR_GROUP_PRIORITY_REALTIME; prio >= 0; prio--) {
> + if (!group_priority_permit(file, prio))
> + arg->allowed_mask |= 1 << prio;
nit: we have a BIT() macro for that ;-). Other than that, it looks good
to me.
Reviewed-by: Boris Brezillon
;
> Signed-off-by: Mary Guillemard
> Reviewed-by: Steven Price
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 2 +-
> drivers/gpu/drm/panthor/panthor_sched.c | 2 --
> include/uapi/drm/panthor_drm.h | 7 +++
> 3 files changed, 8 in
On Sat, 19 Aug 2023 05:13:06 +0300
Dmitry Osipenko wrote:
> On 8/11/23 16:08, Steven Price wrote:
> > On 09/08/2023 17:53, Boris Brezillon wrote:
> >> This way we can grab a pages ref without acquiring the resv lock when
> >> pages_use_count > 0. Need to implem
On Sun, 27 Aug 2023 20:54:36 +0300
Dmitry Osipenko wrote:
> Introduce kref_put_ww_mutex() helper that will handle the wait-wound
> mutex auto-locking on kref_put(). This helper is wanted by DRM drivers
> that extensively use dma-reservation locking which in turns uses ww-mutex.
>
> Signed-off-by
nned
> in memory, but whether pages exit and are soft-pinned (and could be swapped
^exist
> out). The pages_pin_count > 1 will hard-pin pages in memory.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gp
for this field until we have a real use case.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 37 ++
> include/drm/drm_gem_shmem_helper.h | 2 +-
> 2 files changed, 21 inserti
On Sun, 27 Aug 2023 20:54:43 +0300
Dmitry Osipenko wrote:
> In a preparation of adding drm-shmem memory shrinker, move all reservation
> locking lockdep checks to use new drm_gem_shmem_resv_assert_held() that
> will resolve spurious lockdep warning about wrong locking order vs
> fs_reclam code pa
On Sun, 27 Aug 2023 20:54:28 +0300
Dmitry Osipenko wrote:
> Use separate flag for tracking page count bumped by shmem->sgt to avoid
> imbalanced page counter during of drm_gem_shmem_free() time. It's fragile
> to assume that populated shmem->pages at a freeing time means that the
> count was bump
On Sun, 27 Aug 2023 20:54:27 +0300
Dmitry Osipenko wrote:
> Freeing drm-shmem GEM right after creating it using
> drm_gem_shmem_prime_import_sg_table() frees SGT of the imported dma-buf
> and then dma-buf frees this SGT second time.
>
> The v3d_prime_import_sg_table() is example of a error code
e them consistent with the rest of the API functions.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_client.c | 6 +++---
> drivers/gpu/drm/drm_gem.c| 20
On Sun, 27 Aug 2023 20:54:30 +0300
Dmitry Osipenko wrote:
> Add _locked postfix to drm_gem functions that have unlocked counterpart
> functions to make GEM functions naming more consistent and intuitive in
> regards to the locking requirements.
>
> Suggested-by: Boris Brezillon
On Sun, 27 Aug 2023 20:54:34 +0300
Dmitry Osipenko wrote:
> Add locked and remove unlocked postfixes from drm-shmem function names,
> making names consistent with the drm/gem core code.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by:
On Sun, 27 Aug 2023 20:54:35 +0300
Dmitry Osipenko wrote:
> Everything that uses the mapped buffer should by agnostic to is_iomem.
^be
> The only reason for the is_iomem test is that we're setting shmem->vaddr
> to the returned map->vaddr. Now tha
nned
> in memory, but whether pages exit and are soft-pinned (and could be swapped
> out). The pages_pin_count > 1 will hard-pin pages in memory.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 22
On Tue, 29 Aug 2023 05:34:23 +0300
Dmitry Osipenko wrote:
> On 8/28/23 13:12, Boris Brezillon wrote:
> > On Sun, 27 Aug 2023 20:54:43 +0300
> > Dmitry Osipenko wrote:
> >
> >> In a preparation of adding drm-shmem memory shrinker, move all reservation
> >
On Tue, 29 Aug 2023 10:52:03 +0200
Christian König wrote:
> Am 29.08.23 um 09:29 schrieb Boris Brezillon:
> > On Tue, 29 Aug 2023 05:34:23 +0300
> > Dmitry Osipenko wrote:
> >
> >> On 8/28/23 13:12, Boris Brezillon wrote:
> >>> On Sun, 27 Aug 2023 2
On Tue, 29 Aug 2023 11:44:13 +0200
Boris Brezillon wrote:
> On Tue, 29 Aug 2023 10:52:03 +0200
> Christian König wrote:
>
> > Am 29.08.23 um 09:29 schrieb Boris Brezillon:
> > > On Tue, 29 Aug 2023 05:34:23 +0300
> > > Dmitry Osipenko wrote:
> &g
On Mon, 21 Aug 2023 18:56:21 +0100
Robin Murphy wrote:
> > And, to be honest, for a fair bit of the common code in
> > panfrost/panthorm it's common to a few other drivers too. So the correct
> > answer might well be to try to add more generic helpers (devfreq,
> > clocks, power domains all sprin
On Fri, 11 Aug 2023 15:13:23 +0100
Steven Price wrote:
> > +#define AS_TRANSCFG_LO(as) (MMU_AS(as) + 0x30)
> > +#define AS_TRANSCFG_HI(as) (MMU_AS(as) + 0x34)
> > +#define AS_TRANSCFG_ADRMODE_LEGACY (0 << 0)
>
> I don't be
On Fri, 11 Aug 2023 16:47:56 +0100
Steven Price wrote:
> On 09/08/2023 17:53, Boris Brezillon wrote:
> > The panthor driver is designed in a modular way, where each logical
> > block is dealing with a specific HW-block or software feature. In order
> > for those blocks to
On Mon, 14 Aug 2023 11:54:27 +0100
Steven Price wrote:
> On 09/08/2023 17:53, Boris Brezillon wrote:
> > Handles everything that's not related to the FW, the MMU or the
> > scheduler. This is the block dealing with the GPU property retrieval,
> > the GPU block power on/
On Mon, 21 Aug 2023 17:09:49 +0100
Robin Murphy wrote:
> On 2023-08-14 11:54, Steven Price wrote:
> [...]
> >> +/**
> >> + * panthor_gpu_l2_power_on() - Power-on the L2-cache
> >> + * @ptdev: Device.
> >> + *
> >> + * Return: 0 on success, a negative error code otherwise.
> >> + */
> >> +int pant
On Mon, 14 Aug 2023 14:40:25 +0100
Steven Price wrote:
> > +/**
> > + * panthor_gem_create_with_handle() - Create a GEM object and attach it to
> > a handle.
> > + * @file: DRM file.
> > + * @ddev: DRM device.
> > + * @exclusive_vm: Exclusive VM. Not NULL if the GEM object can't be shared.
> > +
On Mon, 14 Aug 2023 16:53:09 +0100
Steven Price wrote:
> > +
> > +/**
> > + * struct panthor_vm_op_ctx - VM operation context
> > + *
> > + * With VM operations potentially taking place in a dma-signaling path, we
> > + * need to make sure everything that might require resource allocation is
> >
On Wed, 16 Aug 2023 17:01:56 +0100
Steven Price wrote:
> On 09/08/2023 17:53, Boris Brezillon wrote:
> > Contains everything that's FW related, that includes the code dealing
> > with the microcontroller unit (MCU) that's running the FW, and anything
> > rela
On Fri, 18 Aug 2023 15:39:03 +0100
Steven Price wrote:
> I'm not sure whether we should really be describing this structure in
> the kernel. Beyond the size the kernel has no reason to be looking at
> the internals and the spec does have a warning that the layout may change.
Yeah, I guess I just
On Fri, 18 Aug 2023 16:38:57 +0100
Steven Price wrote:
> > +/**
> > + * sched_queue_work() - Queue a scheduler work.
> > + * @sched: Scheduler object.
> > + * @wname: Work name.
> > + *
> > + * Conditionally queues a scheduler work if no reset is
> > pending/in-progress.
> > + */
> > +#define sc
On Mon, 21 Aug 2023 12:31:29 +0100
Steven Price wrote:
> On 09/08/2023 17:53, Boris Brezillon wrote:
> > This is the last piece missing to expose the driver to the outside
> > world.
> >
> > This is basically a wrapper between the ioctls and the other logi
On Fri, 11 Aug 2023 17:08:20 +0100
Steven Price wrote:
> On 09/08/2023 17:53, Boris Brezillon wrote:
> > Add an entry for the Panthor driver to the MAINTAINERS file.
> >
> > v2:
> > - New commit
> >
> > Signed-off-by: Boris Brezillon
> > ---
>
On Thu, 24 Aug 2023 02:34:45 +0100
Adrián Larumbe wrote:
> The drm-stats fdinfo tags made available to user space are drm-engine,
> drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
Pretty sure this has already been discussed, but it's probably worth
mentioning that drm-cycles is not a
On Thu, 24 Aug 2023 02:34:46 +0100
Adrián Larumbe wrote:
> A new DRM GEM object function is added so that drm_show_memory_stats can
> provider more accurate memory usage numbers.
s/provider/provide/
>
> Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
> after locking
eir BOs.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_file.c | 5 -
> include/drm/drm_gem.h | 9 +
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu
On Thu, 24 Aug 2023 02:34:44 +0100
Adrián Larumbe wrote:
> These GPU registers will be used when programming the cycle counter, which
> we need for providing accurate fdinfo drm-cycles values to user space.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
On Thu, 24 Aug 2023 02:34:48 +0100
Adrián Larumbe wrote:
> BO's RSS is updated every time new pages are allocated and mapped for the
> object, either in its entirety at creation time for non-heap buffers, or
> else on demand for heap buffers at GPU page fault's IRQ handler.
>
> Same calculations
On Wed, 30 Aug 2023 14:17:57 +0100
Steven Price wrote:
> >>> +static void panthor_device_reset_work(struct work_struct *work)
> >>> +{
> >>> + struct panthor_device *ptdev = container_of(work, struct
> >>> panthor_device, reset.work);
> >>> + int ret, cookie;
> >>> +
> >>> + if (!drm_dev_enter(&
On Wed, 30 Aug 2023 15:12:43 +0100
Steven Price wrote:
> On 29/08/2023 16:33, Boris Brezillon wrote:
> > On Mon, 14 Aug 2023 16:53:09 +0100
> > Steven Price wrote:
> >
> >>> +
> >>> +/**
> >>> + * struct panthor_vm_op_ctx - VM
On Thu, 31 Aug 2023 14:18:42 +0100
Liviu Dudau wrote:
> Hi Boris,
>
> On Wed, Aug 09, 2023 at 06:53:28PM +0200, Boris Brezillon wrote:
> > Add an entry for the Panthor driver to the MAINTAINERS file.
> >
> > v2:
> > - New commit
> >
> > Signed
On Fri, 1 Sep 2023 01:03:23 +0100
Adrián Larumbe wrote:
> >> @@ -274,13 +286,23 @@ panfrost_gem_prime_import_sg_table(struct drm_device
> >> *dev,
> >> {
> >>struct drm_gem_object *obj;
> >>struct panfrost_gem_object *bo;
> >> + struct scatterlist *sgl;
> >> + unsigned int count;
> >>
On Wed, 9 Aug 2023 18:53:15 +0200
Boris Brezillon wrote:
> +/**
> + * DOC: MMIO regions exposed to userspace.
> + *
> + * .. c:macro:: DRM_PANTHOR_USER_MMIO_OFFSET
> + *
> + * File offset for all MMIO regions being exposed to userspace. Don't use
> +
On Sat, 2 Sep 2023 21:28:21 +0300
Dmitry Osipenko wrote:
> On 8/28/23 13:55, Boris Brezillon wrote:
> > On Sun, 27 Aug 2023 20:54:28 +0300
> > Dmitry Osipenko wrote:
> >
> >> Use separate flag for tracking page count bumped by shmem->sgt to avoid
>
On Sat, 2 Sep 2023 21:15:39 +0300
Dmitry Osipenko wrote:
> On 8/28/23 14:16, Boris Brezillon wrote:
> > On Sun, 27 Aug 2023 20:54:27 +0300
> > Dmitry Osipenko wrote:
> >
> >> Freeing drm-shmem GEM right after creating it using
> >> drm_gem_shmem_p
On Mon, 4 Sep 2023 08:42:08 +0100
Steven Price wrote:
> On 01/09/2023 17:10, Boris Brezillon wrote:
> > On Wed, 9 Aug 2023 18:53:15 +0200
> > Boris Brezillon wrote:
> >
> >> +/**
> >> + * DOC: MMIO regions exposed to userspace.
> >> + *
&g
On Sat, 2 Sep 2023 22:43:02 +0300
Dmitry Osipenko wrote:
> On 8/29/23 10:29, Boris Brezillon wrote:
> > On Tue, 29 Aug 2023 05:34:23 +0300
> > Dmitry Osipenko wrote:
> >
> >> On 8/28/23 13:12, Boris Brezillon wrote:
> >>> On Sun, 27 Aug 2023 2
On Mon, 4 Sep 2023 08:42:08 +0100
Steven Price wrote:
> On 01/09/2023 17:10, Boris Brezillon wrote:
> > On Wed, 9 Aug 2023 18:53:15 +0200
> > Boris Brezillon wrote:
> >
> >> +/**
> >> + * DOC: MMIO regions exposed to userspace.
> >> + *
&g
On Mon, 4 Sep 2023 16:22:19 +0100
Steven Price wrote:
> On 04/09/2023 10:26, Boris Brezillon wrote:
> > On Mon, 4 Sep 2023 08:42:08 +0100
> > Steven Price wrote:
> >
> >> On 01/09/2023 17:10, Boris Brezillon wrote:
> >>> On Wed, 9 Aug 2023 1
nned
> in memory, but whether pages exist and are soft-pinned (and could be swapped
> out). The pages_pin_count > 1 will hard-pin pages in memory.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gp
On Sun, 3 Sep 2023 20:07:25 +0300
Dmitry Osipenko wrote:
> Everything that uses the mapped buffer should be agnostic to is_iomem.
> The only reason for the is_iomem test is that we're setting shmem->vaddr
> to the returned map->vaddr. Now that the shmem->vaddr code is gone, remove
> the obsolete
On Sun, 3 Sep 2023 20:07:27 +0300
Dmitry Osipenko wrote:
> Use atomic refcount_t helper for pages_use_count to optimize pin/unpin
> functions by skipping reservation locking while GEM's pin refcount > 1.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenk
t; Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_sh
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 19 ---
> include/drm/drm_gem_shmem_helper.h | 2 +-
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/driver
; refcnt > 1
nit: this optimization doesn't exist in practice, because the resv
lock is taken by the core, and ->v[un]map() are called with this lock
held.
> and also makes vmapping to benefit from the refcount_t's
> overflow checks.
>
> Suggested-by: Boris Brezillon
&g
1501 - 1600 of 2462 matches
Mail list logo
