All of lore.kernel.org
 help / color / mirror / Atom feed
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, "Asahi Lina" <lina+kernel@asahilina.net>,
	"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 05/11] drm/gpuvm: Add a flags field to drm_gpuva_op_map
Date: Fri, 27 Mar 2026 00:01:50 +0100	[thread overview]
Message-ID: <DHD36ONR7KSE.1NFF01QTXNHR6@kernel.org> (raw)
In-Reply-To: <20260313150956.1618635-6-adrian.larumbe@collabora.com>

On Fri Mar 13, 2026 at 4:09 PM CET, Adrián Larumbe wrote:
> From: Asahi Lina <lina+kernel@asahilina.net>
>
> drm_gpuva objects have a flags field. Currently, this can be managed by
> drivers out-of-band, without any special handling in drm_gpuvm.
>
> To be able to introduce flags that do affect the logic in the drm_gpuvm
> core, we need to plumb it through the map calls. This will allow the
> core to check the flags on map and alter the merge/split logic depending
> on the requested flags and the flags of the existing drm_gpuva ranges
> that are being split.
>
> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
> Signed-off-by: Caterina Shablia <caterina.shablia@collabora.com>

Missing Signed-off-by.

> ---
>  drivers/gpu/drm/drm_gpuvm.c | 14 ++++++++++++--
>  include/drm/drm_gpuvm.h     | 18 ++++++++++++++++++
>  2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> index 4af7b71abcb4..0d9c821d1b34 100644
> --- a/drivers/gpu/drm/drm_gpuvm.c
> +++ b/drivers/gpu/drm/drm_gpuvm.c
> @@ -2386,6 +2386,7 @@ static bool can_merge(struct drm_gpuvm *gpuvm, const struct drm_gpuva *va,
>  		.va.range = va->va.range,
>  		.gem.offset = va->gem.offset,
>  		.gem.obj = va->gem.obj,
> +		.flags = va->flags,
>  	};
>  	const struct drm_gpuva_op_map *a = new_map, *b = &existing_map;
>  
> @@ -2395,6 +2396,10 @@ static bool can_merge(struct drm_gpuvm *gpuvm, const struct drm_gpuva *va,
>  	if (a->gem.obj != b->gem.obj || !a->gem.obj)
>  		return false;
>  
> +	/* For two VAs to be merged, their flags must be compatible */
> +	if ((a->flags & VA_MERGE_MUST_MATCH_FLAGS) != (b->flags & VA_MERGE_MUST_MATCH_FLAGS))
> +		return false;

This has nothing to do with this patch, the commit message only talks about
adding flags to struct drm_gpuva_op_map.

Please create a new patch for further changes, v4 of this was fine as is.

> +
>  	/* Order VAs for the rest of the checks. */
>  	if (a->va.addr > b->va.addr)
>  		swap(a, b);
> @@ -2459,6 +2464,7 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  					.va.range = range - req_range,
>  					.gem.obj = obj,
>  					.gem.offset = offset + req_range,
> +					.flags = va->flags,
>  				};
>  				struct drm_gpuva_op_unmap u = {
>  					.va = va,
> @@ -2480,6 +2486,7 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  				.va.range = ls_range,
>  				.gem.obj = obj,
>  				.gem.offset = offset,
> +				.flags = va->flags,
>  			};
>  			struct drm_gpuva_op_unmap u = { .va = va };
>  
> @@ -2519,8 +2526,8 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  					.va.addr = req_end,
>  					.va.range = end - req_end,
>  					.gem.obj = obj,
> -					.gem.offset = offset + ls_range +
> -						      req_range,
> +					.gem.offset = offset + ls_range + req_range,

Spurious change.

> +					.flags = va->flags,
>  				};
>  
>  				ret = op_remap_cb(ops, priv, &p, &n, &u);
> @@ -2554,6 +2561,7 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  					.va.range = end - req_end,
>  					.gem.obj = obj,
>  					.gem.offset = offset + req_end - addr,
> +					.flags = va->flags,
>  				};
>  				struct drm_gpuva_op_unmap u = {
>  					.va = va,
> @@ -2605,6 +2613,7 @@ __drm_gpuvm_sm_unmap(struct drm_gpuvm *gpuvm,
>  			prev.va.range = req_addr - addr;
>  			prev.gem.obj = obj;
>  			prev.gem.offset = offset;
> +			prev.flags = va->flags;
>  
>  			prev_split = true;
>  		}
> @@ -2614,6 +2623,7 @@ __drm_gpuvm_sm_unmap(struct drm_gpuvm *gpuvm,
>  			next.va.range = end - req_end;
>  			next.gem.obj = obj;
>  			next.gem.offset = offset + (req_end - addr);
> +			next.flags = va->flags;
>  
>  			next_split = true;
>  		}
> diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
> index 6a6e64cd2cce..5bf37deb282d 100644
> --- a/include/drm/drm_gpuvm.h
> +++ b/include/drm/drm_gpuvm.h
> @@ -63,6 +63,8 @@ enum drm_gpuva_flags {
>  	DRM_GPUVA_USERBITS = (1 << 2),
>  };
>  
> +#define VA_MERGE_MUST_MATCH_FLAGS (DRM_GPUVA_SPARSE)

Please drop this indirection if the only criteria is that both must be sparse.

> +
>  /**
>   * struct drm_gpuva - structure to track a GPU VA mapping
>   *
> @@ -886,6 +888,11 @@ struct drm_gpuva_op_map {
>  		 */
>  		struct drm_gem_object *obj;
>  	} gem;
> +
> +	/**
> +	 * @flags: requested flags for the &drm_gpuva for this mapping
> +	 */
> +	enum drm_gpuva_flags flags;
>  };
>  
>  /**
> @@ -1124,6 +1131,7 @@ void drm_gpuva_ops_free(struct drm_gpuvm *gpuvm,
>  static inline void drm_gpuva_init_from_op(struct drm_gpuva *va,
>  					  const struct drm_gpuva_op_map *op)
>  {
> +	va->flags = op->flags;
>  	va->va.addr = op->va.addr;
>  	va->va.range = op->va.range;
>  	va->gem.obj = op->gem.obj;
> @@ -1249,6 +1257,16 @@ struct drm_gpuvm_ops {
>  	 * used.
>  	 */
>  	int (*sm_step_unmap)(struct drm_gpuva_op *op, void *priv);
> +
> +	/**
> +	 * @sm_can_merge_flags: called during &drm_gpuvm_sm_map
> +	 *
> +	 * This callback is called to determine whether two va ranges can be merged,
> +	 * based on their flags.
> +	 *
> +	 * If NULL, va ranges can only be merged if their flags are equal.
> +	 */
> +	bool (*sm_can_merge_flags)(enum drm_gpuva_flags a, enum drm_gpuva_flags b);

Again, this has nothing to do with this commit, please add a separate patch for
this with a proper commit message explaining the motivation.

Also, this callback appears to be unused and seems to contradict the static
check for compatible merge flags in the hunk above.

  reply	other threads:[~2026-03-26 23:01 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
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 [this message]
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=DHD36ONR7KSE.1NFF01QTXNHR6@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=lina+kernel@asahilina.net \
    --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.