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 06/11] drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic
Date: Fri, 27 Mar 2026 00:18:06 +0100	[thread overview]
Message-ID: <DHD3J5BKEG5P.U0R7DT73MJ0Q@kernel.org> (raw)
In-Reply-To: <20260313150956.1618635-7-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>
>
> To be able to support "fake sparse" mappings without relying on GPU page
> fault handling, drivers may need to create large (e.g. 4GiB) mappings of
> the same page repeatedly (or same range of pages). Doing this through
> individual mappings would be very wasteful. This can be handled better
> by using a flag on map creation, but to do it safely, drm_gpuvm needs to
> be aware of this special case.
>
> Add a flag that signals that a given mapping is a page mapping, which is
> repeated all over the entire requested VA range. This tweaks the
> sm_map() logic to treat the GEM offsets differently when mappings are
> a repeated ones so they are not incremented as they would be with regular
> mappings.
>
> The size of the GEM portion to repeat is passed through
> drm_gpuva::gem::range. Most of the time it will be a page size, but
> it can be bigger as long as it's less than drm_gpuva::va::range, and
> drm_gpuva::va::range is a multiple of drm_gpuva::gem::range.
>
> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
> Signed-off-by: Caterina Shablia <caterina.shablia@collabora.com>

In v4 I also mentioned:

	I also think this feature deserves its own section in the global GPUVM
	documentation -- please add a corresponding paragraph.

	Also it seems that we need to update the documentation which shows all potential
	cases when calling __drm_gpuvm_sm_map() [1].

	[1] https://docs.kernel.org/gpu/drm-mm.html#split-and-merge

Why did this not happen?

> +static int validate_map_request(struct drm_gpuvm *gpuvm,
> +				const struct drm_gpuva_op_map *op)
> +{
> +	if (unlikely(!drm_gpuvm_range_valid(gpuvm, op->va.addr, op->va.range)))
> +		return -EINVAL;
> +
> +	if (op->flags & DRM_GPUVA_REPEAT) {
> +		u64 va_range = op->va.range;
> +
> +		/* For a repeated mapping, GEM range must be > 0
> +		 * and a multiple of the VA range.
> +		 */
> +		if (unlikely(!op->gem.repeat_range ||
> +			     va_range < op->gem.repeat_range ||
> +			     do_div(va_range, op->gem.repeat_range)))
> +			return -EINVAL;
> +	}
> +
> +	if (op->flags & DRM_GPUVA_INVALIDATED)
> +		return -EINVAL;

This seems unrelated to this patch.

> +
> +	return 0;
> +}
> +
>  static int
>  __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  		   const struct drm_gpuvm_ops *ops, void *priv,
> @@ -2429,7 +2475,8 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  	u64 req_end = req_addr + req_range;
>  	int ret;
>  
> -	if (unlikely(!drm_gpuvm_range_valid(gpuvm, req_addr, req_range)))
> +	ret = validate_map_request(gpuvm, &req->map);
> +	if (unlikely(ret))
>  		return -EINVAL;
>  
>  	drm_gpuvm_for_each_va_range_safe(va, next, gpuvm, req_addr, req_end) {
> @@ -2463,7 +2510,9 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm,
>  					.va.addr = req_end,
>  					.va.range = range - req_range,
>  					.gem.obj = obj,
> -					.gem.offset = offset + req_range,
> +					.gem.repeat_range = va->gem.repeat_range,
> +					.gem.offset = offset +
> +						(va->flags & DRM_GPUVA_REPEAT ? 0 : req_range),

This seems to be a repeating pattern, can we factor this into a helper?

  reply	other threads:[~2026-03-26 23:18 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
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 [this message]
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=DHD3J5BKEG5P.U0R7DT73MJ0Q@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.