From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3868D157487 for ; Thu, 16 Apr 2026 06:55:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776322545; cv=none; b=hrxpGfjvK98CGx6+eq5T04PWiK2u0HhLJSlb9zIznUTGCthV8VaLiJaKYvxLsScdaufau7sULrQJXHZYH12MdjgRVk9s8/4aa2tl5/ON0Ecs2iRL5+YIVUQG+uk5w+EwDJw8B+B1uFDelFZbLvz/Q8Dfo3WYUn77bBF0YNHT29w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776322545; c=relaxed/simple; bh=iVXocKTZmYJGC0WoAS800VksTIgZCs1qZSpnUGiK1qk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YGtTptzj4MRaVEG9Ujr2n31VxWtppN3EtL0FnpDXLGrvn+7nRJJ7tuo6X6PM+Hd4sc3CGDR68VWHluZeaQdwbSJsITe6XuaGqQCnKvKoC1+CoUDRe9dX0vaY8Th3/ewOhNhVIkkqw2UNff8rnjapJO7m9NgPqyHdSXA9IKYnyR8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=WkQgc3/A; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="WkQgc3/A" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1776322542; bh=iVXocKTZmYJGC0WoAS800VksTIgZCs1qZSpnUGiK1qk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WkQgc3/AsBYe2F5Zc4Ha1DJOxsuoT/z3IIuecVxLrvjB8GvDA/RzIAlgu6IAvti7e 2NrnTAEJ8ewhS8f/yzuc2ySWYukShS1I56gOaRVS/C2yrKg08U1fT8EDYeLebS2gKb vEEMDrdfbbz0cY13LrF08UcS2noAs9O/3UW3U7Pfrr7y+vqbhnecMeNOVSWjvKL7gq UJnVHBTPycqHLuvL3+zkyN7zxElHiXhjVct4qbOhSdzJ97cHo/Z0m07XzsoDC0wu8W BRqu8OOs6IwF4CoPJztpTqHHdQDozSkjH/MZuGtccXALP+ndbu/f9rT2SEPxF26wW0 tBwkZ+A0o3x7A== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 9119F17E11F5; Thu, 16 Apr 2026 08:55:41 +0200 (CEST) Date: Thu, 16 Apr 2026 08:55:37 +0200 From: Boris Brezillon To: =?UTF-8?B?QWRyacOhbg==?= Larumbe Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Steven Price , kernel@collabora.com, Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Daniel Almeida , Alice Ryhl Subject: Re: [PATCH v7 5/6] drm/panthor: Support sparse mappings Message-ID: <20260416085537.6af9e2c8@fedora> In-Reply-To: References: <20260415112900.681834-1-adrian.larumbe@collabora.com> <20260415112900.681834-6-adrian.larumbe@collabora.com> <20260415171247.3701e116@fedora> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 15 Apr 2026 23:09:17 +0100 Adri=C3=A1n Larumbe wrote: > > > @@ -2251,14 +2383,17 @@ static int panthor_gpuva_sm_step_remap(struct= drm_gpuva_op *op, > > > } > > > > > > if (op->remap.prev) { > > > - struct panthor_gem_object *bo =3D to_panthor_bo(op->remap.prev->ge= m.obj); > > > - u64 offset =3D op->remap.prev->gem.offset + unmap_start - op->rema= p.prev->va.addr; > > > - u64 size =3D op->remap.prev->va.addr + op->remap.prev->va.range - = unmap_start; > > > + const struct drm_gpuva_op_map map_op =3D { > > > + .va.addr =3D unmap_start, > > > + .va.range =3D > > > + op->remap.prev->va.addr + op->remap.prev->va.range - unmap_start, > > > + .gem.obj =3D op->remap.prev->gem.obj, > > > + .gem.offset =3D > > > + op->remap.prev->gem.offset + unmap_start - op->remap.prev->va.add= r, =20 > > > > I believe it should be forced to zero if this is a sparse > > mapping, no? This makes me think we probably want this to be > > NULL, in the case of a sparse mapping. It shouldn't prevent > > reclaim from happening on the dummy BO, because the drm_gpuva > > has a separate vm_bo field. Yes it forces us to add bunch of > > is_sparse checks in a few other places, but I find it cleaner > > than pretending this is a regular BO. =20 >=20 > The .gem.offset field is assigned here unconditionally, but discarded in = cases it's a sparse mapping > when calling panthor_vm_map_sparse() (which takes no offset argument). I = assume what you mean is that > in panthor_vm_exec_op(), I should abstain from assining .map.gem.obj and = .map.gem.offset. However, > if I do that, the 'va->vm_bo =3D drm_gpuvm_bo_get(vm_bo);' will never hap= pen inside drm_gpuva_link(). Ah, crap! I thought drm_gpuva_link() was only considering vm_bo. Okay, let's keep it the way you did it then, and just add a comment explaining unmap_op.keep can't be trusted when the mapping is sparse.