On 6/23/26 15:14, Adrián Larumbe wrote:
On 2026-06-23 13:41:12+01:00, Akash Goel wrote:
On 6/23/26 13:09, Boris Brezillon wrote:

On Tue, 23 Jun 2026 12:17:51 +0100
Akash Goel <[email protected]> wrote:


Nah, you're correct, the patching of the drm_gpuva is independent of the
adjusted unmap range, so we should be good even if we don't adjust this
range for evicted sparse mappings. Sorry for the noise.

No worries. Thanks for confirming.

Since I had a closer look at the code, sorry I have another doubt.

Do we really need the call to 'panthor_fix_sparse_map_offset()' in the
following code block ?. The 'op->remap.next->gem.offset' would already
have been patched before.

You're right, it's completely unnecessary.

Thanks Adrian for confirming.


> Maybe replace it with a comment that says the right offset had already > been adjusted earlier in the function?

Sure, I can prepare a patch for this.


Other than that:

Reviewed-by: Adrián Larumbe <[email protected]>


Thanks for the review.

Best regards
Akash



        if (op->remap.next) {
                u64 addr = op->remap.next->va.addr;
                u64 size = unmap_start + unmap_range - op->remap.next->va.addr;

                if (!unmap_vma->evicted && size > 0) {
                        struct drm_gpuva_op_map map_op = {
                                .va.addr = addr,
                                .va.range = size,
                                .gem.obj = op->remap.next->gem.obj,
                                .gem.offset = op->remap.next->gem.offset,
                        };
                        panthor_fix_sparse_map_offset(&map_op, 
unmap_vma->flags);

                        ret = panthor_vm_exec_map_op(vm, unmap_vma->flags, 
&map_op);

Reviewed-by: Boris Brezillon <[email protected]>

Sorry I realized that indentation needs to be fixed in my patch.

Will send a v2 and ad your r-b tag.

Best regards
Akash


Reply via email to