public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Dave Airlie <airlied@redhat.com>, DRI <dri-devel@lists.freedesktop.org>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linux Next Mailing List" <linux-next@vger.kernel.org>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: linux-next: manual merge of the drm tree with the drm-fixes tree
Date: Fri, 23 Jan 2026 17:45:36 +0000	[thread overview]
Message-ID: <aXOzwL50DYVm570X@sirena.org.uk> (raw)

[-- Attachment #1: Type: text/plain, Size: 4640 bytes --]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  include/drm/drm_pagemap.h

between commits:

  754c232384386 ("drm/pagemap, drm/xe: Ensure that the devmem allocation is idle before use")
  bdcdf968be314 ("drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATE")

from the drm-fixes tree and commits:

  a599b98607dec ("drm/pagemap, drm/xe: Add refcounting to struct drm_pagemap")
  75af93b3f5d0a ("drm/pagemap, drm/xe: Support destination migration over interconnect")
  77f14f2f2d73f ("drm/pagemap: Add a drm_pagemap cache and shrinker")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc include/drm/drm_pagemap.h
index eb29e5309f0ab,46e9c58f09e01..0000000000000
--- a/include/drm/drm_pagemap.h
+++ b/include/drm/drm_pagemap.h
@@@ -209,19 -243,56 +243,69 @@@ struct drm_pagemap_devmem_ops 
  			   struct dma_fence *pre_migrate_fence);
  };
  
 +#if IS_ENABLED(CONFIG_ZONE_DEVICE)
 +
 +struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page);
 +
 +#else
 +
 +static inline struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page)
 +{
 +	return NULL;
 +}
 +
 +#endif /* IS_ENABLED(CONFIG_ZONE_DEVICE) */
 +
+ int drm_pagemap_init(struct drm_pagemap *dpagemap,
+ 		     struct dev_pagemap *pagemap,
+ 		     struct drm_device *drm,
+ 		     const struct drm_pagemap_ops *ops);
+ 
+ struct drm_pagemap *drm_pagemap_create(struct drm_device *drm,
+ 				       struct dev_pagemap *pagemap,
+ 				       const struct drm_pagemap_ops *ops);
+ 
+ #if IS_ENABLED(CONFIG_DRM_GPUSVM)
+ 
+ void drm_pagemap_put(struct drm_pagemap *dpagemap);
+ 
+ #else
+ 
+ static inline void drm_pagemap_put(struct drm_pagemap *dpagemap)
+ {
+ }
+ 
+ #endif /* IS_ENABLED(CONFIG_DRM_GPUSVM) */
+ 
+ /**
+  * drm_pagemap_get() - Obtain a reference on a struct drm_pagemap
+  * @dpagemap: Pointer to the struct drm_pagemap, or NULL.
+  *
+  * Return: Pointer to the struct drm_pagemap, or NULL.
+  */
+ static inline struct drm_pagemap *
+ drm_pagemap_get(struct drm_pagemap *dpagemap)
+ {
+ 	if (likely(dpagemap))
+ 		kref_get(&dpagemap->ref);
+ 
+ 	return dpagemap;
+ }
+ 
+ /**
+  * drm_pagemap_get_unless_zero() - Obtain a reference on a struct drm_pagemap
+  * unless the current reference count is zero.
+  * @dpagemap: Pointer to the drm_pagemap or NULL.
+  *
+  * Return: A pointer to @dpagemap if the reference count was successfully
+  * incremented. NULL if @dpagemap was NULL, or its refcount was 0.
+  */
+ static inline struct drm_pagemap * __must_check
+ drm_pagemap_get_unless_zero(struct drm_pagemap *dpagemap)
+ {
+ 	return (dpagemap && kref_get_unless_zero(&dpagemap->ref)) ? dpagemap : NULL;
+ }
+ 
  /**
   * struct drm_pagemap_devmem - Structure representing a GPU SVM device memory allocation
   *
@@@ -246,8 -317,23 +330,25 @@@ struct drm_pagemap_devmem 
  	struct dma_fence *pre_migrate_fence;
  };
  
+ /**
+  * struct drm_pagemap_migrate_details - Details to govern migration.
+  * @timeslice_ms: The time requested for the migrated pagemap pages to
+  * be present in @mm before being allowed to be migrated back.
+  * @can_migrate_same_pagemap: Whether the copy function as indicated by
+  * the @source_peer_migrates flag, can migrate device pages within a
+  * single drm_pagemap.
+  * @source_peer_migrates: Whether on p2p migration, The source drm_pagemap
+  * should use the copy_to_ram() callback rather than the destination
+  * drm_pagemap should use the copy_to_devmem() callback.
+  */
+ struct drm_pagemap_migrate_details {
+ 	unsigned long timeslice_ms;
+ 	u32 can_migrate_same_pagemap : 1;
+ 	u32 source_peer_migrates : 1;
+ };
+ 
 +#if IS_ENABLED(CONFIG_ZONE_DEVICE)
 +
  int drm_pagemap_migrate_to_devmem(struct drm_pagemap_devmem *devmem_allocation,
  				  struct mm_struct *mm,
  				  unsigned long start, unsigned long end,
@@@ -269,6 -356,7 +369,10 @@@ int drm_pagemap_populate_mm(struct drm_
  			    struct mm_struct *mm,
  			    unsigned long timeslice_ms);
  
 +#endif /* IS_ENABLED(CONFIG_ZONE_DEVICE) */
 +
+ void drm_pagemap_destroy(struct drm_pagemap *dpagemap, bool is_atomic_or_reclaim);
+ 
+ int drm_pagemap_reinit(struct drm_pagemap *dpagemap);
++
  #endif

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2026-01-23 17:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 17:45 Mark Brown [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-03-27 20:52 linux-next: manual merge of the drm tree with the drm-fixes tree Mark Brown
2026-03-27 20:46 Mark Brown
2026-03-09 14:35 Mark Brown
2026-03-06 13:47 Mark Brown
2026-03-06 13:47 Mark Brown
2026-01-30 15:37 Mark Brown
2026-01-30 15:28 Mark Brown
2025-06-27  2:58 Stephen Rothwell
2024-10-18  1:56 Stephen Rothwell
2024-06-27 15:08 Mark Brown
2024-06-27 15:00 Mark Brown
2024-06-21 13:21 Mark Brown
2023-08-18  1:53 Stephen Rothwell
2023-02-13  0:23 Stephen Rothwell
2022-09-26 17:49 broonie
2022-02-25 16:37 broonie
2022-02-24 16:33 broonie
2021-08-06 12:04 Mark Brown
2021-08-10 11:56 ` Geert Uytterhoeven
2021-08-10 12:53   ` Stephen Rothwell
2020-07-10  2:28 Stephen Rothwell
2019-08-23  3:20 Stephen Rothwell
2019-07-05  2:50 Stephen Rothwell
2019-03-01  2:23 Stephen Rothwell
2019-03-01 23:29 ` Alex Deucher
2019-03-04  0:54   ` Stephen Rothwell
2019-03-11 12:36     ` Daniel Vetter
2018-12-14  1:51 Stephen Rothwell
2018-12-07  2:38 Stephen Rothwell
2018-12-07  2:31 Stephen Rothwell

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=aXOzwL50DYVm570X@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=airlied@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox