From: "Danilo Krummrich" <dakr@kernel.org>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Steven Price" <steven.price@arm.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Janne Grunau" <j@jannau.net>,
kernel@collabora.com,
"Caterina Shablia" <caterina.shablia@collabora.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>
Subject: Re: [PATCH v5 04/11] drm/gpuvm: Add a helper to check if two VA can be merged
Date: Thu, 26 Mar 2026 23:44:38 +0100 [thread overview]
Message-ID: <DHD2TIKMD3E7.3L229ON925VS5@kernel.org> (raw)
In-Reply-To: <20260313150956.1618635-5-adrian.larumbe@collabora.com>
On Fri Mar 13, 2026 at 4:09 PM CET, Adrián Larumbe wrote:
> From: Boris Brezillon <boris.brezillon@collabora.com>
>
> We are going to add flags/properties that will impact the VA merging
> ability. Instead of sprinkling tests all over the place in
> __drm_gpuvm_sm_map(), let's add a helper aggregating all these checks
> can call it for every existing VA we walk through in the
> __drm_gpuvm_sm_map() loop.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> Signed-off-by: Caterina Shablia <caterina.shablia@collabora.com>
This needs your Signed-off-by: as well. Does it need Caterina's Co-developed-by:
tag as well?
> ---
> drivers/gpu/drm/drm_gpuvm.c | 46 +++++++++++++++++++++++++++----------
> 1 file changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> index 3c2b6102e818..4af7b71abcb4 100644
> --- a/drivers/gpu/drm/drm_gpuvm.c
> +++ b/drivers/gpu/drm/drm_gpuvm.c
> @@ -2378,16 +2378,47 @@ op_unmap_cb(const struct drm_gpuvm_ops *fn, void *priv,
> return fn->sm_step_unmap(&op, priv);
> }
>
> +static bool can_merge(struct drm_gpuvm *gpuvm, const struct drm_gpuva *va,
> + const struct drm_gpuva_op_map *new_map)
Not public, but please add some documentation regardless; it's not very obvious
what the function should achieve semantically from just looking at its
signature.
> +{
> + struct drm_gpuva_op_map existing_map = {
> + .va.addr = va->va.addr,
> + .va.range = va->va.range,
> + .gem.offset = va->gem.offset,
> + .gem.obj = va->gem.obj,
> + };
IIRC, previously this was a temporary struct drm_gpuva; this seems better (also
because its scope is limited to this function), but it still feels like an
abuse of this structure.
Anyways, I get that you want it for the swap() trick below, but I think it can
also easily be done without the swap() trick. What about this?
static bool can_merge(struct drm_gpuvm *gpuvm, const struct drm_gpuva *va,
const struct drm_gpuva_op_map *new_map)
{
/* Only GEM-based mappings can be merged, and they must point to
* the same GEM object.
*/
if (va->gem.obj != new_map->gem.obj || !new_map->gem.obj)
return false;
/* We assume the caller already checked that VAs overlap or are
* contiguous.
*/
if (drm_WARN_ON(gpuvm->drm,
new_map->va.addr > va->va.addr + va->va.range ||
va->va.addr > new_map->va.addr + new_map->va.range))
return false;
/* u64 underflow is fine: both sides negate equally, preserving
* the equality.
*/
return va->va.addr - new_map->va.addr ==
va->gem.offset - new_map->gem.offset;
}
> + const struct drm_gpuva_op_map *a = new_map, *b = &existing_map;
> +
> + /* Only GEM-based mappings can be merged, and they must point to
> + * the same GEM object.
> + */
> + if (a->gem.obj != b->gem.obj || !a->gem.obj)
> + return false;
> +
> + /* Order VAs for the rest of the checks. */
> + if (a->va.addr > b->va.addr)
> + swap(a, b);
> +
> + /* We assume the caller already checked that VAs overlap or are
> + * contiguous.
> + */
> + if (drm_WARN_ON(gpuvm->drm, b->va.addr > a->va.addr + a->va.range))
> + return false;
> +
> + /* We intentionally ignore u64 underflows because all we care about
> + * here is whether the VA diff matches the GEM offset diff.
> + */
> + return b->va.addr - a->va.addr == b->gem.offset - a->gem.offset;
> +}
next prev parent reply other threads:[~2026-03-26 22:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 15:09 [PATCH v5 00/11] Support repeated mappings in GPUVM and Panthor Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 01/11] drm/panthor: Expose GPU page sizes to UM Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 02/11] drm/gpuvm: Remove dead code Adrián Larumbe
2026-03-26 22:10 ` Danilo Krummrich
2026-05-29 17:54 ` Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 03/11] drm/gpuvm: Fix comment to reflect remap operation operand status Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 04/11] drm/gpuvm: Add a helper to check if two VA can be merged Adrián Larumbe
2026-03-26 22:44 ` Danilo Krummrich [this message]
2026-03-27 9:31 ` Alice Ryhl
2026-03-13 15:09 ` [PATCH v5 05/11] drm/gpuvm: Add a flags field to drm_gpuva_op_map Adrián Larumbe
2026-03-26 23:01 ` Danilo Krummrich
2026-03-13 15:09 ` [PATCH v5 06/11] drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic Adrián Larumbe
2026-03-26 23:18 ` Danilo Krummrich
2026-03-13 15:09 ` [PATCH v5 07/11] drm/gpuvm: Ensure correctness of unmap/remaps of repeated regions Adrián Larumbe
2026-03-26 23:39 ` Danilo Krummrich
2026-03-13 15:09 ` [PATCH v5 08/11] drm/panthor: Add support for repeated mappings Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 09/11] drm/panthor: Handle remap case " Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 10/11] drm/panthor: Pass vm_bind_op to vm_prepare_map_op_ctx Adrián Larumbe
2026-03-13 15:09 ` [PATCH v5 11/11] drm/panthor: Bump the driver version to 1.8 Adrián Larumbe
2026-03-24 20:51 ` [PATCH v5 00/11] Support repeated mappings in GPUVM and Panthor Dave Airlie
2026-03-25 18:11 ` Adrián Larumbe
2026-03-25 18:17 ` Rob Clark
2026-03-25 19:25 ` Janne Grunau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DHD2TIKMD3E7.3L229ON925VS5@kernel.org \
--to=dakr@kernel.org \
--cc=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=boris.brezillon@collabora.com \
--cc=caterina.shablia@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=j@jannau.net \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.