All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-04 14:30 ` Nirmoy Das
  0 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx
  Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Andi Shyti,
	Nirmoy Das

Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++++++++++----
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c     |  5 +++--
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5dcbbef31d44..830c11431ee8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -328,6 +328,12 @@ struct drm_i915_gem_object {
  */
 #define I915_BO_ALLOC_GPU_ONLY	  BIT(6)
 #define I915_BO_ALLOC_CCS_AUX	  BIT(7)
+/*
+ * Object is allowed to retain its initial data and will not be cleared on first
+ * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
+ * preallocated framebuffer data intact while transitioning it to i915drmfb.
+ */
+#define I915_BO_PREALLOC	  BIT(8)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 			     I915_BO_ALLOC_VOLATILE | \
 			     I915_BO_ALLOC_CPU_CLEAR | \
@@ -335,10 +341,11 @@ struct drm_i915_gem_object {
 			     I915_BO_ALLOC_PM_VOLATILE | \
 			     I915_BO_ALLOC_PM_EARLY | \
 			     I915_BO_ALLOC_GPU_ONLY | \
-			     I915_BO_ALLOC_CCS_AUX)
-#define I915_BO_READONLY          BIT(8)
-#define I915_TILING_QUIRK_BIT     9 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED         BIT(10)
+			     I915_BO_ALLOC_CCS_AUX | \
+			     I915_BO_PREALLOC)
+#define I915_BO_READONLY          BIT(9)
+#define I915_TILING_QUIRK_BIT     10 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED         BIT(11)
 	/**
 	 * @mem_flags - Mutable placement-related flags
 	 *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index dd188dfcc423..69eb20ed4d47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
 	struct dma_fence *migration_fence = NULL;
 	struct ttm_tt *ttm = bo->ttm;
 	struct i915_refct_sgt *dst_rsgt;
-	bool clear;
+	bool clear, prealloc_bo;
 	int ret;
 
 	if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
@@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
 		return PTR_ERR(dst_rsgt);
 
 	clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || !ttm_tt_is_populated(ttm));
-	if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+	prealloc_bo = obj->flags & I915_BO_PREALLOC;
+	if (!(clear && ttm && !((ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC) && !prealloc_bo))) {
 		struct i915_deps deps;
 
 		i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-04 14:30 ` Nirmoy Das
  0 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx; +Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Nirmoy Das

Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++++++++++----
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c     |  5 +++--
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5dcbbef31d44..830c11431ee8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -328,6 +328,12 @@ struct drm_i915_gem_object {
  */
 #define I915_BO_ALLOC_GPU_ONLY	  BIT(6)
 #define I915_BO_ALLOC_CCS_AUX	  BIT(7)
+/*
+ * Object is allowed to retain its initial data and will not be cleared on first
+ * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
+ * preallocated framebuffer data intact while transitioning it to i915drmfb.
+ */
+#define I915_BO_PREALLOC	  BIT(8)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 			     I915_BO_ALLOC_VOLATILE | \
 			     I915_BO_ALLOC_CPU_CLEAR | \
@@ -335,10 +341,11 @@ struct drm_i915_gem_object {
 			     I915_BO_ALLOC_PM_VOLATILE | \
 			     I915_BO_ALLOC_PM_EARLY | \
 			     I915_BO_ALLOC_GPU_ONLY | \
-			     I915_BO_ALLOC_CCS_AUX)
-#define I915_BO_READONLY          BIT(8)
-#define I915_TILING_QUIRK_BIT     9 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED         BIT(10)
+			     I915_BO_ALLOC_CCS_AUX | \
+			     I915_BO_PREALLOC)
+#define I915_BO_READONLY          BIT(9)
+#define I915_TILING_QUIRK_BIT     10 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED         BIT(11)
 	/**
 	 * @mem_flags - Mutable placement-related flags
 	 *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index dd188dfcc423..69eb20ed4d47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
 	struct dma_fence *migration_fence = NULL;
 	struct ttm_tt *ttm = bo->ttm;
 	struct i915_refct_sgt *dst_rsgt;
-	bool clear;
+	bool clear, prealloc_bo;
 	int ret;
 
 	if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
@@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
 		return PTR_ERR(dst_rsgt);
 
 	clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || !ttm_tt_is_populated(ttm));
-	if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+	prealloc_bo = obj->flags & I915_BO_PREALLOC;
+	if (!(clear && ttm && !((ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC) && !prealloc_bo))) {
 		struct i915_deps deps;
 
 		i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 14:30   ` Nirmoy Das
  -1 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx
  Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Andi Shyti,
	Nirmoy Das

Framebuffer is exposed to userspace so make sure we set
proper flags for it. Set I915_BO_PREALLOC for prealloced
fb so that ttm won't clear existing data.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev.c         | 3 ++-
 drivers/gpu/drm/i915/display/intel_plane_initial.c | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 673bcdfb7ff6..f7d48d00ae4b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -163,7 +163,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 	obj = ERR_PTR(-ENODEV);
 	if (HAS_LMEM(dev_priv)) {
 		obj = i915_gem_object_create_lmem(dev_priv, size,
-						  I915_BO_ALLOC_CONTIGUOUS);
+						  I915_BO_ALLOC_CONTIGUOUS |
+						  I915_BO_ALLOC_USER);
 	} else {
 		/*
 		 * If the FB is too big, just don't use it since fbdev is not very
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index bb6ea7de5c61..736072a8b2b0 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -110,7 +110,9 @@ initial_plane_vma(struct drm_i915_private *i915,
 	    size * 2 > i915->dsm.usable_size)
 		return NULL;
 
-	obj = i915_gem_object_create_region_at(mem, phys_base, size, 0);
+	obj = i915_gem_object_create_region_at(mem, phys_base, size,
+					       I915_BO_ALLOC_USER |
+					       I915_BO_PREALLOC);
 	if (IS_ERR(obj))
 		return NULL;
 
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [Intel-gfx] [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
@ 2023-04-04 14:30   ` Nirmoy Das
  0 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx; +Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Nirmoy Das

Framebuffer is exposed to userspace so make sure we set
proper flags for it. Set I915_BO_PREALLOC for prealloced
fb so that ttm won't clear existing data.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev.c         | 3 ++-
 drivers/gpu/drm/i915/display/intel_plane_initial.c | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 673bcdfb7ff6..f7d48d00ae4b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -163,7 +163,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 	obj = ERR_PTR(-ENODEV);
 	if (HAS_LMEM(dev_priv)) {
 		obj = i915_gem_object_create_lmem(dev_priv, size,
-						  I915_BO_ALLOC_CONTIGUOUS);
+						  I915_BO_ALLOC_CONTIGUOUS |
+						  I915_BO_ALLOC_USER);
 	} else {
 		/*
 		 * If the FB is too big, just don't use it since fbdev is not very
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index bb6ea7de5c61..736072a8b2b0 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -110,7 +110,9 @@ initial_plane_vma(struct drm_i915_private *i915,
 	    size * 2 > i915->dsm.usable_size)
 		return NULL;
 
-	obj = i915_gem_object_create_region_at(mem, phys_base, size, 0);
+	obj = i915_gem_object_create_region_at(mem, phys_base, size,
+					       I915_BO_ALLOC_USER |
+					       I915_BO_PREALLOC);
 	if (IS_ERR(obj))
 		return NULL;
 
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 14:30   ` Nirmoy Das
  -1 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld, Andi Shyti, Nirmoy Das

Implement i915_gem_fb_mmap() to enable fb_ops.fb_mmap()
callback for i915's framebuffer objects.

v2: add a comment why i915_gem_object_get() needed(Andi).
v3: mmap also ttm objects.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 137 +++++++++++++++--------
 drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +-
 2 files changed, 93 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d3c1dee16af2..3dbacdf0911a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -927,53 +927,15 @@ static struct file *mmap_singleton(struct drm_i915_private *i915)
 	return file;
 }
 
-/*
- * This overcomes the limitation in drm_gem_mmap's assignment of a
- * drm_gem_object as the vma->vm_private_data. Since we need to
- * be able to resolve multiple mmap offsets which could be tied
- * to a single gem object.
- */
-int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+static int
+i915_gem_object_mmap(struct drm_i915_gem_object *obj,
+		     struct i915_mmap_offset *mmo,
+		     struct vm_area_struct *vma)
 {
-	struct drm_vma_offset_node *node;
-	struct drm_file *priv = filp->private_data;
-	struct drm_device *dev = priv->minor->dev;
-	struct drm_i915_gem_object *obj = NULL;
-	struct i915_mmap_offset *mmo = NULL;
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
+	struct drm_device *dev = &i915->drm;
 	struct file *anon;
 
-	if (drm_dev_is_unplugged(dev))
-		return -ENODEV;
-
-	rcu_read_lock();
-	drm_vma_offset_lock_lookup(dev->vma_offset_manager);
-	node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
-						  vma->vm_pgoff,
-						  vma_pages(vma));
-	if (node && drm_vma_node_is_allowed(node, priv)) {
-		/*
-		 * Skip 0-refcnted objects as it is in the process of being
-		 * destroyed and will be invalid when the vma manager lock
-		 * is released.
-		 */
-		if (!node->driver_private) {
-			mmo = container_of(node, struct i915_mmap_offset, vma_node);
-			obj = i915_gem_object_get_rcu(mmo->obj);
-
-			GEM_BUG_ON(obj && obj->ops->mmap_ops);
-		} else {
-			obj = i915_gem_object_get_rcu
-				(container_of(node, struct drm_i915_gem_object,
-					      base.vma_node));
-
-			GEM_BUG_ON(obj && !obj->ops->mmap_ops);
-		}
-	}
-	drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
-	rcu_read_unlock();
-	if (!obj)
-		return node ? -EACCES : -EINVAL;
-
 	if (i915_gem_object_is_readonly(obj)) {
 		if (vma->vm_flags & VM_WRITE) {
 			i915_gem_object_put(obj);
@@ -1005,7 +967,7 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 	if (obj->ops->mmap_ops) {
 		vma->vm_page_prot = pgprot_decrypted(vm_get_page_prot(vma->vm_flags));
 		vma->vm_ops = obj->ops->mmap_ops;
-		vma->vm_private_data = node->driver_private;
+		vma->vm_private_data = obj->base.vma_node.driver_private;
 		return 0;
 	}
 
@@ -1043,6 +1005,91 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 	return 0;
 }
 
+/*
+ * This overcomes the limitation in drm_gem_mmap's assignment of a
+ * drm_gem_object as the vma->vm_private_data. Since we need to
+ * be able to resolve multiple mmap offsets which could be tied
+ * to a single gem object.
+ */
+int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+	struct drm_vma_offset_node *node;
+	struct drm_file *priv = filp->private_data;
+	struct drm_device *dev = priv->minor->dev;
+	struct drm_i915_gem_object *obj = NULL;
+	struct i915_mmap_offset *mmo = NULL;
+
+	if (drm_dev_is_unplugged(dev))
+		return -ENODEV;
+
+	rcu_read_lock();
+	drm_vma_offset_lock_lookup(dev->vma_offset_manager);
+	node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
+						  vma->vm_pgoff,
+						  vma_pages(vma));
+	if (node && drm_vma_node_is_allowed(node, priv)) {
+		/*
+		 * Skip 0-refcnted objects as it is in the process of being
+		 * destroyed and will be invalid when the vma manager lock
+		 * is released.
+		 */
+		if (!node->driver_private) {
+			mmo = container_of(node, struct i915_mmap_offset, vma_node);
+			obj = i915_gem_object_get_rcu(mmo->obj);
+
+			GEM_BUG_ON(obj && obj->ops->mmap_ops);
+		} else {
+			obj = i915_gem_object_get_rcu
+				(container_of(node, struct drm_i915_gem_object,
+					      base.vma_node));
+
+			GEM_BUG_ON(obj && !obj->ops->mmap_ops);
+		}
+	}
+	drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
+	rcu_read_unlock();
+	if (!obj)
+		return node ? -EACCES : -EINVAL;
+
+	return i915_gem_object_mmap(obj, mmo, vma);
+}
+
+int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma)
+{
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
+	struct drm_device *dev = &i915->drm;
+	struct i915_mmap_offset *mmo = NULL;
+	enum i915_mmap_type mmap_type;
+	struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+
+	if (drm_dev_is_unplugged(dev))
+		return -ENODEV;
+
+	/* handle ttm object */
+	if (obj->ops->mmap_ops) {
+		/*
+		 * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake offset
+		 * to calculate page offset so set that up.
+		 */
+		vma->vm_pgoff += drm_vma_node_start(&obj->base.vma_node);
+	} else {
+		/* handle stolen and smem objects */
+		mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
+		mmo = mmap_offset_attach(obj, mmap_type, NULL);
+		if (!mmo)
+			return -ENODEV;
+	}
+
+	/*
+	 * When we install vm_ops for mmap we are too late for
+	 * the vm_ops->open() which increases the ref_count of
+	 * this obj and then it gets decreased by the vm_ops->close().
+	 * To balance this increase the obj ref_count here.
+	 */
+	obj = i915_gem_object_get(obj);
+	return i915_gem_object_mmap(obj, mmo, vma);
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/i915_gem_mman.c"
 #endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 1fa91b3033b3..196417fd0f5c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -29,5 +29,5 @@ void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
 
 void i915_gem_object_runtime_pm_release_mmap_offset(struct drm_i915_gem_object *obj);
 void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
-
+int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma);
 #endif
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [Intel-gfx] [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
@ 2023-04-04 14:30   ` Nirmoy Das
  0 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld, Nirmoy Das

Implement i915_gem_fb_mmap() to enable fb_ops.fb_mmap()
callback for i915's framebuffer objects.

v2: add a comment why i915_gem_object_get() needed(Andi).
v3: mmap also ttm objects.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 137 +++++++++++++++--------
 drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +-
 2 files changed, 93 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d3c1dee16af2..3dbacdf0911a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -927,53 +927,15 @@ static struct file *mmap_singleton(struct drm_i915_private *i915)
 	return file;
 }
 
-/*
- * This overcomes the limitation in drm_gem_mmap's assignment of a
- * drm_gem_object as the vma->vm_private_data. Since we need to
- * be able to resolve multiple mmap offsets which could be tied
- * to a single gem object.
- */
-int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+static int
+i915_gem_object_mmap(struct drm_i915_gem_object *obj,
+		     struct i915_mmap_offset *mmo,
+		     struct vm_area_struct *vma)
 {
-	struct drm_vma_offset_node *node;
-	struct drm_file *priv = filp->private_data;
-	struct drm_device *dev = priv->minor->dev;
-	struct drm_i915_gem_object *obj = NULL;
-	struct i915_mmap_offset *mmo = NULL;
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
+	struct drm_device *dev = &i915->drm;
 	struct file *anon;
 
-	if (drm_dev_is_unplugged(dev))
-		return -ENODEV;
-
-	rcu_read_lock();
-	drm_vma_offset_lock_lookup(dev->vma_offset_manager);
-	node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
-						  vma->vm_pgoff,
-						  vma_pages(vma));
-	if (node && drm_vma_node_is_allowed(node, priv)) {
-		/*
-		 * Skip 0-refcnted objects as it is in the process of being
-		 * destroyed and will be invalid when the vma manager lock
-		 * is released.
-		 */
-		if (!node->driver_private) {
-			mmo = container_of(node, struct i915_mmap_offset, vma_node);
-			obj = i915_gem_object_get_rcu(mmo->obj);
-
-			GEM_BUG_ON(obj && obj->ops->mmap_ops);
-		} else {
-			obj = i915_gem_object_get_rcu
-				(container_of(node, struct drm_i915_gem_object,
-					      base.vma_node));
-
-			GEM_BUG_ON(obj && !obj->ops->mmap_ops);
-		}
-	}
-	drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
-	rcu_read_unlock();
-	if (!obj)
-		return node ? -EACCES : -EINVAL;
-
 	if (i915_gem_object_is_readonly(obj)) {
 		if (vma->vm_flags & VM_WRITE) {
 			i915_gem_object_put(obj);
@@ -1005,7 +967,7 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 	if (obj->ops->mmap_ops) {
 		vma->vm_page_prot = pgprot_decrypted(vm_get_page_prot(vma->vm_flags));
 		vma->vm_ops = obj->ops->mmap_ops;
-		vma->vm_private_data = node->driver_private;
+		vma->vm_private_data = obj->base.vma_node.driver_private;
 		return 0;
 	}
 
@@ -1043,6 +1005,91 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 	return 0;
 }
 
+/*
+ * This overcomes the limitation in drm_gem_mmap's assignment of a
+ * drm_gem_object as the vma->vm_private_data. Since we need to
+ * be able to resolve multiple mmap offsets which could be tied
+ * to a single gem object.
+ */
+int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+	struct drm_vma_offset_node *node;
+	struct drm_file *priv = filp->private_data;
+	struct drm_device *dev = priv->minor->dev;
+	struct drm_i915_gem_object *obj = NULL;
+	struct i915_mmap_offset *mmo = NULL;
+
+	if (drm_dev_is_unplugged(dev))
+		return -ENODEV;
+
+	rcu_read_lock();
+	drm_vma_offset_lock_lookup(dev->vma_offset_manager);
+	node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
+						  vma->vm_pgoff,
+						  vma_pages(vma));
+	if (node && drm_vma_node_is_allowed(node, priv)) {
+		/*
+		 * Skip 0-refcnted objects as it is in the process of being
+		 * destroyed and will be invalid when the vma manager lock
+		 * is released.
+		 */
+		if (!node->driver_private) {
+			mmo = container_of(node, struct i915_mmap_offset, vma_node);
+			obj = i915_gem_object_get_rcu(mmo->obj);
+
+			GEM_BUG_ON(obj && obj->ops->mmap_ops);
+		} else {
+			obj = i915_gem_object_get_rcu
+				(container_of(node, struct drm_i915_gem_object,
+					      base.vma_node));
+
+			GEM_BUG_ON(obj && !obj->ops->mmap_ops);
+		}
+	}
+	drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
+	rcu_read_unlock();
+	if (!obj)
+		return node ? -EACCES : -EINVAL;
+
+	return i915_gem_object_mmap(obj, mmo, vma);
+}
+
+int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma)
+{
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
+	struct drm_device *dev = &i915->drm;
+	struct i915_mmap_offset *mmo = NULL;
+	enum i915_mmap_type mmap_type;
+	struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+
+	if (drm_dev_is_unplugged(dev))
+		return -ENODEV;
+
+	/* handle ttm object */
+	if (obj->ops->mmap_ops) {
+		/*
+		 * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake offset
+		 * to calculate page offset so set that up.
+		 */
+		vma->vm_pgoff += drm_vma_node_start(&obj->base.vma_node);
+	} else {
+		/* handle stolen and smem objects */
+		mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
+		mmo = mmap_offset_attach(obj, mmap_type, NULL);
+		if (!mmo)
+			return -ENODEV;
+	}
+
+	/*
+	 * When we install vm_ops for mmap we are too late for
+	 * the vm_ops->open() which increases the ref_count of
+	 * this obj and then it gets decreased by the vm_ops->close().
+	 * To balance this increase the obj ref_count here.
+	 */
+	obj = i915_gem_object_get(obj);
+	return i915_gem_object_mmap(obj, mmo, vma);
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/i915_gem_mman.c"
 #endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index 1fa91b3033b3..196417fd0f5c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -29,5 +29,5 @@ void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
 
 void i915_gem_object_runtime_pm_release_mmap_offset(struct drm_i915_gem_object *obj);
 void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
-
+int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma);
 #endif
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 14:30   ` Nirmoy Das
  -1 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx
  Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Andi Shyti,
	Nirmoy Das

Add a helper function to retrieve struct intel_fbdev from
struct drm_fb_helper.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 23 ++++++++++------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
index f7d48d00ae4b..2ac9e9f8a128 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -67,6 +67,11 @@ struct intel_fbdev {
 	struct mutex hpd_lock;
 };
 
+static struct intel_fbdev *to_intel_fbdev(struct drm_fb_helper *fb_helper)
+{
+	return container_of(fb_helper, struct intel_fbdev, helper);
+}
+
 static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev *ifbdev)
 {
 	return ifbdev->fb->frontbuffer;
@@ -79,9 +84,7 @@ static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
 
 static int intel_fbdev_set_par(struct fb_info *info)
 {
-	struct drm_fb_helper *fb_helper = info->par;
-	struct intel_fbdev *ifbdev =
-		container_of(fb_helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
 	int ret;
 
 	ret = drm_fb_helper_set_par(info);
@@ -93,9 +96,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
 
 static int intel_fbdev_blank(int blank, struct fb_info *info)
 {
-	struct drm_fb_helper *fb_helper = info->par;
-	struct intel_fbdev *ifbdev =
-		container_of(fb_helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
 	int ret;
 
 	ret = drm_fb_helper_blank(blank, info);
@@ -108,9 +109,7 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
 static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
 				   struct fb_info *info)
 {
-	struct drm_fb_helper *fb_helper = info->par;
-	struct intel_fbdev *ifbdev =
-		container_of(fb_helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
 	int ret;
 
 	ret = drm_fb_helper_pan_display(var, info);
@@ -136,8 +135,7 @@ static const struct fb_ops intelfb_ops = {
 static int intelfb_alloc(struct drm_fb_helper *helper,
 			 struct drm_fb_helper_surface_size *sizes)
 {
-	struct intel_fbdev *ifbdev =
-		container_of(helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
 	struct drm_framebuffer *fb;
 	struct drm_device *dev = helper->dev;
 	struct drm_i915_private *dev_priv = to_i915(dev);
@@ -194,8 +192,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 static int intelfb_create(struct drm_fb_helper *helper,
 			  struct drm_fb_helper_surface_size *sizes)
 {
-	struct intel_fbdev *ifbdev =
-		container_of(helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
 	struct intel_framebuffer *intel_fb = ifbdev->fb;
 	struct drm_device *dev = helper->dev;
 	struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [Intel-gfx] [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
@ 2023-04-04 14:30   ` Nirmoy Das
  0 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:30 UTC (permalink / raw)
  To: intel-gfx; +Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Nirmoy Das

Add a helper function to retrieve struct intel_fbdev from
struct drm_fb_helper.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 23 ++++++++++------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
index f7d48d00ae4b..2ac9e9f8a128 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -67,6 +67,11 @@ struct intel_fbdev {
 	struct mutex hpd_lock;
 };
 
+static struct intel_fbdev *to_intel_fbdev(struct drm_fb_helper *fb_helper)
+{
+	return container_of(fb_helper, struct intel_fbdev, helper);
+}
+
 static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev *ifbdev)
 {
 	return ifbdev->fb->frontbuffer;
@@ -79,9 +84,7 @@ static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
 
 static int intel_fbdev_set_par(struct fb_info *info)
 {
-	struct drm_fb_helper *fb_helper = info->par;
-	struct intel_fbdev *ifbdev =
-		container_of(fb_helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
 	int ret;
 
 	ret = drm_fb_helper_set_par(info);
@@ -93,9 +96,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
 
 static int intel_fbdev_blank(int blank, struct fb_info *info)
 {
-	struct drm_fb_helper *fb_helper = info->par;
-	struct intel_fbdev *ifbdev =
-		container_of(fb_helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
 	int ret;
 
 	ret = drm_fb_helper_blank(blank, info);
@@ -108,9 +109,7 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
 static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
 				   struct fb_info *info)
 {
-	struct drm_fb_helper *fb_helper = info->par;
-	struct intel_fbdev *ifbdev =
-		container_of(fb_helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
 	int ret;
 
 	ret = drm_fb_helper_pan_display(var, info);
@@ -136,8 +135,7 @@ static const struct fb_ops intelfb_ops = {
 static int intelfb_alloc(struct drm_fb_helper *helper,
 			 struct drm_fb_helper_surface_size *sizes)
 {
-	struct intel_fbdev *ifbdev =
-		container_of(helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
 	struct drm_framebuffer *fb;
 	struct drm_device *dev = helper->dev;
 	struct drm_i915_private *dev_priv = to_i915(dev);
@@ -194,8 +192,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 static int intelfb_create(struct drm_fb_helper *helper,
 			  struct drm_fb_helper_surface_size *sizes)
 {
-	struct intel_fbdev *ifbdev =
-		container_of(helper, struct intel_fbdev, helper);
+	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
 	struct intel_framebuffer *intel_fb = ifbdev->fb;
 	struct drm_device *dev = helper->dev;
 	struct drm_i915_private *dev_priv = to_i915(dev);
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [PATCH 5/5] drm/i915/display: Implement fb_mmap callback function
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 14:31   ` Nirmoy Das
  -1 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:31 UTC (permalink / raw)
  To: intel-gfx
  Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Andi Shyti,
	Nirmoy Das

If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will use cpu to access
the framebuffer.

v2: Use to_intel_fbdev() function(Jani)

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 2ac9e9f8a128..aab1ae74a8f7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -40,8 +40,10 @@
 #include <drm/drm_crtc.h>
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_fourcc.h>
+#include <drm/drm_gem_framebuffer_helper.h>
 
 #include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_mman.h"
 
 #include "i915_drv.h"
 #include "intel_display_types.h"
@@ -119,6 +121,15 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
 	return ret;
 }
 
+static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+	struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
+	struct drm_gem_object *bo = drm_gem_fb_get_obj(&fbdev->fb->base, 0);
+	struct drm_i915_gem_object *obj = to_intel_bo(bo);
+
+	return i915_gem_fb_mmap(obj, vma);
+}
+
 static const struct fb_ops intelfb_ops = {
 	.owner = THIS_MODULE,
 	DRM_FB_HELPER_DEFAULT_OPS,
@@ -130,6 +141,7 @@ static const struct fb_ops intelfb_ops = {
 	.fb_imageblit = drm_fb_helper_cfb_imageblit,
 	.fb_pan_display = intel_fbdev_pan_display,
 	.fb_blank = intel_fbdev_blank,
+	.fb_mmap = intel_fbdev_mmap,
 };
 
 static int intelfb_alloc(struct drm_fb_helper *helper,
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [Intel-gfx] [PATCH 5/5] drm/i915/display: Implement fb_mmap callback function
@ 2023-04-04 14:31   ` Nirmoy Das
  0 siblings, 0 replies; 40+ messages in thread
From: Nirmoy Das @ 2023-04-04 14:31 UTC (permalink / raw)
  To: intel-gfx; +Cc: Andrzej Hajda, Jani Nikula, dri-devel, Matthew Auld, Nirmoy Das

If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will use cpu to access
the framebuffer.

v2: Use to_intel_fbdev() function(Jani)

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 2ac9e9f8a128..aab1ae74a8f7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -40,8 +40,10 @@
 #include <drm/drm_crtc.h>
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_fourcc.h>
+#include <drm/drm_gem_framebuffer_helper.h>
 
 #include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_mman.h"
 
 #include "i915_drv.h"
 #include "intel_display_types.h"
@@ -119,6 +121,15 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
 	return ret;
 }
 
+static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+	struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
+	struct drm_gem_object *bo = drm_gem_fb_get_obj(&fbdev->fb->base, 0);
+	struct drm_i915_gem_object *obj = to_intel_bo(bo);
+
+	return i915_gem_fb_mmap(obj, vma);
+}
+
 static const struct fb_ops intelfb_ops = {
 	.owner = THIS_MODULE,
 	DRM_FB_HELPER_DEFAULT_OPS,
@@ -130,6 +141,7 @@ static const struct fb_ops intelfb_ops = {
 	.fb_imageblit = drm_fb_helper_cfb_imageblit,
 	.fb_pan_display = intel_fbdev_pan_display,
 	.fb_blank = intel_fbdev_blank,
+	.fb_mmap = intel_fbdev_mmap,
 };
 
 static int intelfb_alloc(struct drm_fb_helper *helper,
-- 
2.39.0


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 15:30   ` Andrzej Hajda
  -1 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-04 15:30 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld, Andi Shyti



On 04.04.2023 16:30, Nirmoy Das wrote:
> Add a mechanism to keep existing data when creating
> a ttm object with I915_BO_ALLOC_USER flag.
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++++++++++----
>   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c     |  5 +++--
>   2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 5dcbbef31d44..830c11431ee8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -328,6 +328,12 @@ struct drm_i915_gem_object {
>    */
>   #define I915_BO_ALLOC_GPU_ONLY	  BIT(6)
>   #define I915_BO_ALLOC_CCS_AUX	  BIT(7)
> +/*
> + * Object is allowed to retain its initial data and will not be cleared on first
> + * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
> + * preallocated framebuffer data intact while transitioning it to i915drmfb.
> + */
> +#define I915_BO_PREALLOC	  BIT(8)
>   #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
>   			     I915_BO_ALLOC_VOLATILE | \
>   			     I915_BO_ALLOC_CPU_CLEAR | \
> @@ -335,10 +341,11 @@ struct drm_i915_gem_object {
>   			     I915_BO_ALLOC_PM_VOLATILE | \
>   			     I915_BO_ALLOC_PM_EARLY | \
>   			     I915_BO_ALLOC_GPU_ONLY | \
> -			     I915_BO_ALLOC_CCS_AUX)
> -#define I915_BO_READONLY          BIT(8)
> -#define I915_TILING_QUIRK_BIT     9 /* unknown swizzling; do not release! */
> -#define I915_BO_PROTECTED         BIT(10)
> +			     I915_BO_ALLOC_CCS_AUX | \
> +			     I915_BO_PREALLOC)
> +#define I915_BO_READONLY          BIT(9)
> +#define I915_TILING_QUIRK_BIT     10 /* unknown swizzling; do not release! */
> +#define I915_BO_PROTECTED         BIT(11)
>   	/**
>   	 * @mem_flags - Mutable placement-related flags
>   	 *
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index dd188dfcc423..69eb20ed4d47 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
>   	struct dma_fence *migration_fence = NULL;
>   	struct ttm_tt *ttm = bo->ttm;
>   	struct i915_refct_sgt *dst_rsgt;
> -	bool clear;
> +	bool clear, prealloc_bo;
>   	int ret;
>   
>   	if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
> @@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
>   		return PTR_ERR(dst_rsgt);
>   
>   	clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || !ttm_tt_is_populated(ttm));
> -	if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
> +	prealloc_bo = obj->flags & I915_BO_PREALLOC;
> +	if (!(clear && ttm && !((ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC) && !prealloc_bo))) {

This looks like school exercise for complicated usage of logical 
operators, and I have problem with understanding this :)
Couldn't this be somehow simplified?

Anyway as the patch just reuses existing code:
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Regards
Andrzej


>   		struct i915_deps deps;
>   
>   		i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-04 15:30   ` Andrzej Hajda
  0 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-04 15:30 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld



On 04.04.2023 16:30, Nirmoy Das wrote:
> Add a mechanism to keep existing data when creating
> a ttm object with I915_BO_ALLOC_USER flag.
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++++++++++----
>   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c     |  5 +++--
>   2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 5dcbbef31d44..830c11431ee8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -328,6 +328,12 @@ struct drm_i915_gem_object {
>    */
>   #define I915_BO_ALLOC_GPU_ONLY	  BIT(6)
>   #define I915_BO_ALLOC_CCS_AUX	  BIT(7)
> +/*
> + * Object is allowed to retain its initial data and will not be cleared on first
> + * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
> + * preallocated framebuffer data intact while transitioning it to i915drmfb.
> + */
> +#define I915_BO_PREALLOC	  BIT(8)
>   #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
>   			     I915_BO_ALLOC_VOLATILE | \
>   			     I915_BO_ALLOC_CPU_CLEAR | \
> @@ -335,10 +341,11 @@ struct drm_i915_gem_object {
>   			     I915_BO_ALLOC_PM_VOLATILE | \
>   			     I915_BO_ALLOC_PM_EARLY | \
>   			     I915_BO_ALLOC_GPU_ONLY | \
> -			     I915_BO_ALLOC_CCS_AUX)
> -#define I915_BO_READONLY          BIT(8)
> -#define I915_TILING_QUIRK_BIT     9 /* unknown swizzling; do not release! */
> -#define I915_BO_PROTECTED         BIT(10)
> +			     I915_BO_ALLOC_CCS_AUX | \
> +			     I915_BO_PREALLOC)
> +#define I915_BO_READONLY          BIT(9)
> +#define I915_TILING_QUIRK_BIT     10 /* unknown swizzling; do not release! */
> +#define I915_BO_PROTECTED         BIT(11)
>   	/**
>   	 * @mem_flags - Mutable placement-related flags
>   	 *
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index dd188dfcc423..69eb20ed4d47 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
>   	struct dma_fence *migration_fence = NULL;
>   	struct ttm_tt *ttm = bo->ttm;
>   	struct i915_refct_sgt *dst_rsgt;
> -	bool clear;
> +	bool clear, prealloc_bo;
>   	int ret;
>   
>   	if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
> @@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
>   		return PTR_ERR(dst_rsgt);
>   
>   	clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || !ttm_tt_is_populated(ttm));
> -	if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
> +	prealloc_bo = obj->flags & I915_BO_PREALLOC;
> +	if (!(clear && ttm && !((ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC) && !prealloc_bo))) {

This looks like school exercise for complicated usage of logical 
operators, and I have problem with understanding this :)
Couldn't this be somehow simplified?

Anyway as the patch just reuses existing code:
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Regards
Andrzej


>   		struct i915_deps deps;
>   
>   		i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
                   ` (5 preceding siblings ...)
  (?)
@ 2023-04-04 15:47 ` Patchwork
  -1 siblings, 0 replies; 40+ messages in thread
From: Patchwork @ 2023-04-04 15:47 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
URL   : https://patchwork.freedesktop.org/series/116093/
State : warning

== Summary ==

Error: dim checkpatch failed
6d227bf78d21 drm/i915/ttm: Add I915_BO_PREALLOC
0afb53513af0 drm/i915/display: Set I915_BO_ALLOC_USER for fb
238ea32be324 drm/i915: Add a function to mmap framebuffer obj
-:131: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants
#131: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1040:
+			GEM_BUG_ON(obj && obj->ops->mmap_ops);

-:137: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants
#137: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1046:
+			GEM_BUG_ON(obj && !obj->ops->mmap_ops);

total: 0 errors, 2 warnings, 0 checks, 164 lines checked
ee0620d0ce67 drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
062c04b1867c drm/i915/display: Implement fb_mmap callback function



^ permalink raw reply	[flat|nested] 40+ messages in thread

* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
                   ` (6 preceding siblings ...)
  (?)
@ 2023-04-04 15:47 ` Patchwork
  -1 siblings, 0 replies; 40+ messages in thread
From: Patchwork @ 2023-04-04 15:47 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
URL   : https://patchwork.freedesktop.org/series/116093/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.



^ permalink raw reply	[flat|nested] 40+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
                   ` (7 preceding siblings ...)
  (?)
@ 2023-04-04 16:00 ` Patchwork
  -1 siblings, 0 replies; 40+ messages in thread
From: Patchwork @ 2023-04-04 16:00 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: intel-gfx

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

== Series Details ==

Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
URL   : https://patchwork.freedesktop.org/series/116093/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12965 -> Patchwork_116093v1
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/index.html

Participating hosts (38 -> 36)
------------------------------

  Missing    (2): bat-rpls-2 fi-snb-2520m 

Known issues
------------

  Here are the changes found in Patchwork_116093v1 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live@execlists:
    - fi-kbl-soraka:      [PASS][1] -> [INCOMPLETE][2] ([i915#7156] / [i915#7913])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-kbl-soraka/igt@i915_selftest@live@execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/fi-kbl-soraka/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@live@slpc:
    - bat-rpls-1:         NOTRUN -> [DMESG-FAIL][3] ([i915#6367] / [i915#7996])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@i915_selftest@live@slpc.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
    - bat-dg2-11:         NOTRUN -> [SKIP][4] ([i915#7828])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-dg2-11/igt@kms_chamelium_hpd@common-hpd-after-suspend.html
    - bat-rpls-1:         NOTRUN -> [SKIP][5] ([i915#7828])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@kms_chamelium_hpd@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
    - bat-rpls-1:         NOTRUN -> [SKIP][6] ([i915#1845])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@kms_pipe_crc_basic@suspend-read-crc.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@gt_heartbeat:
    - fi-apl-guc:         [DMESG-FAIL][7] ([i915#5334]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
    - bat-dg2-11:         [INCOMPLETE][9] ([i915#7609] / [i915#7913]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
    - bat-rpls-1:         [ABORT][11] ([i915#4983] / [i915#7911]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-rpls-1/igt@i915_selftest@live@requests.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-rpls-1/igt@i915_selftest@live@requests.html

  * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
    - bat-dg2-8:          [FAIL][13] ([i915#7932]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1.html

  
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996


Build changes
-------------

  * Linux: CI_DRM_12965 -> Patchwork_116093v1

  CI-20190529: 20190529
  CI_DRM_12965: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116093v1: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

7d5216c49733 drm/i915/display: Implement fb_mmap callback function
a3e84ec57029 drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
df67f701575d drm/i915: Add a function to mmap framebuffer obj
5629582ffdd6 drm/i915/display: Set I915_BO_ALLOC_USER for fb
eb10111d59e3 drm/i915/ttm: Add I915_BO_PREALLOC

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/index.html

[-- Attachment #2: Type: text/html, Size: 5986 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 16:23   ` Andi Shyti
  -1 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-04 16:23 UTC (permalink / raw)
  To: Nirmoy Das
  Cc: Andi Shyti, Jani Nikula, intel-gfx, dri-devel, Matthew Auld,
	Andrzej Hajda

Hi Nirmoy,

On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
> Add a mechanism to keep existing data when creating
> a ttm object with I915_BO_ALLOC_USER flag.

why do we need this mechanism? What was the logic behind? These
are all questions people might have when checking this commit.
Please be a bit more explicative.

> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Thanks,
Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-04 16:23   ` Andi Shyti
  0 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-04 16:23 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld, Andrzej Hajda

Hi Nirmoy,

On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
> Add a mechanism to keep existing data when creating
> a ttm object with I915_BO_ALLOC_USER flag.

why do we need this mechanism? What was the logic behind? These
are all questions people might have when checking this commit.
Please be a bit more explicative.

> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Thanks,
Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
  2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 16:36     ` Andi Shyti
  -1 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-04 16:36 UTC (permalink / raw)
  To: Nirmoy Das
  Cc: Andi Shyti, Jani Nikula, intel-gfx, dri-devel, Matthew Auld,
	Andrzej Hajda

Hi Nirmoy,

On Tue, Apr 04, 2023 at 04:30:57PM +0200, Nirmoy Das wrote:
> Framebuffer is exposed to userspace so make sure we set
> proper flags for it. Set I915_BO_PREALLOC for prealloced
> fb so that ttm won't clear existing data.
> 
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Thanks,
Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
@ 2023-04-04 16:36     ` Andi Shyti
  0 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-04 16:36 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld, Andrzej Hajda

Hi Nirmoy,

On Tue, Apr 04, 2023 at 04:30:57PM +0200, Nirmoy Das wrote:
> Framebuffer is exposed to userspace so make sure we set
> proper flags for it. Set I915_BO_PREALLOC for prealloced
> fb so that ttm won't clear existing data.
> 
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Thanks,
Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
  2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
@ 2023-04-04 16:57     ` Andi Shyti
  -1 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-04 16:57 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld, Andi Shyti

Hi Nirmoy,

[...]

> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma)
> +{
> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +	struct drm_device *dev = &i915->drm;
> +	struct i915_mmap_offset *mmo = NULL;
> +	enum i915_mmap_type mmap_type;
> +	struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> +
> +	if (drm_dev_is_unplugged(dev))
> +		return -ENODEV;
> +
> +	/* handle ttm object */
> +	if (obj->ops->mmap_ops) {
> +		/*
> +		 * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake offset
> +		 * to calculate page offset so set that up.
> +		 */
> +		vma->vm_pgoff += drm_vma_node_start(&obj->base.vma_node);

you could have kept my r-b. Good work here!

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> 

Thanks,
Andi

> +	} else {
> +		/* handle stolen and smem objects */
> +		mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
> +		mmo = mmap_offset_attach(obj, mmap_type, NULL);
> +		if (!mmo)
> +			return -ENODEV;
> +	}
> +
> +	/*
> +	 * When we install vm_ops for mmap we are too late for
> +	 * the vm_ops->open() which increases the ref_count of
> +	 * this obj and then it gets decreased by the vm_ops->close().
> +	 * To balance this increase the obj ref_count here.
> +	 */
> +	obj = i915_gem_object_get(obj);
> +	return i915_gem_object_mmap(obj, mmo, vma);
> +}

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
@ 2023-04-04 16:57     ` Andi Shyti
  0 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-04 16:57 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld

Hi Nirmoy,

[...]

> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma)
> +{
> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +	struct drm_device *dev = &i915->drm;
> +	struct i915_mmap_offset *mmo = NULL;
> +	enum i915_mmap_type mmap_type;
> +	struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
> +
> +	if (drm_dev_is_unplugged(dev))
> +		return -ENODEV;
> +
> +	/* handle ttm object */
> +	if (obj->ops->mmap_ops) {
> +		/*
> +		 * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake offset
> +		 * to calculate page offset so set that up.
> +		 */
> +		vma->vm_pgoff += drm_vma_node_start(&obj->base.vma_node);

you could have kept my r-b. Good work here!

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> 

Thanks,
Andi

> +	} else {
> +		/* handle stolen and smem objects */
> +		mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
> +		mmo = mmap_offset_attach(obj, mmap_type, NULL);
> +		if (!mmo)
> +			return -ENODEV;
> +	}
> +
> +	/*
> +	 * When we install vm_ops for mmap we are too late for
> +	 * the vm_ops->open() which increases the ref_count of
> +	 * this obj and then it gets decreased by the vm_ops->close().
> +	 * To balance this increase the obj ref_count here.
> +	 */
> +	obj = i915_gem_object_get(obj);
> +	return i915_gem_object_mmap(obj, mmo, vma);
> +}

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
  2023-04-04 16:57     ` [Intel-gfx] " Andi Shyti
@ 2023-04-04 17:59       ` Das, Nirmoy
  -1 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-04 17:59 UTC (permalink / raw)
  To: Andi Shyti; +Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld

Hi Andi,

On 4/4/2023 6:57 PM, Andi Shyti wrote:
> Hi Nirmoy,
>
> [...]
>
>> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma)
>> +{
>> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> +	struct drm_device *dev = &i915->drm;
>> +	struct i915_mmap_offset *mmo = NULL;
>> +	enum i915_mmap_type mmap_type;
>> +	struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>> +
>> +	if (drm_dev_is_unplugged(dev))
>> +		return -ENODEV;
>> +
>> +	/* handle ttm object */
>> +	if (obj->ops->mmap_ops) {
>> +		/*
>> +		 * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake offset
>> +		 * to calculate page offset so set that up.
>> +		 */
>> +		vma->vm_pgoff += drm_vma_node_start(&obj->base.vma_node);
> you could have kept my r-b.


I wasn't sure, so I removed it :)


>   Good work here!
>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>


Thanks,

Nirmoy

>
> Thanks,
> Andi
>
>> +	} else {
>> +		/* handle stolen and smem objects */
>> +		mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
>> +		mmo = mmap_offset_attach(obj, mmap_type, NULL);
>> +		if (!mmo)
>> +			return -ENODEV;
>> +	}
>> +
>> +	/*
>> +	 * When we install vm_ops for mmap we are too late for
>> +	 * the vm_ops->open() which increases the ref_count of
>> +	 * this obj and then it gets decreased by the vm_ops->close().
>> +	 * To balance this increase the obj ref_count here.
>> +	 */
>> +	obj = i915_gem_object_get(obj);
>> +	return i915_gem_object_mmap(obj, mmo, vma);
>> +}

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj
@ 2023-04-04 17:59       ` Das, Nirmoy
  0 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-04 17:59 UTC (permalink / raw)
  To: Andi Shyti; +Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld

Hi Andi,

On 4/4/2023 6:57 PM, Andi Shyti wrote:
> Hi Nirmoy,
>
> [...]
>
>> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct *vma)
>> +{
>> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> +	struct drm_device *dev = &i915->drm;
>> +	struct i915_mmap_offset *mmo = NULL;
>> +	enum i915_mmap_type mmap_type;
>> +	struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
>> +
>> +	if (drm_dev_is_unplugged(dev))
>> +		return -ENODEV;
>> +
>> +	/* handle ttm object */
>> +	if (obj->ops->mmap_ops) {
>> +		/*
>> +		 * ttm fault handler, ttm_bo_vm_fault_reserved() uses fake offset
>> +		 * to calculate page offset so set that up.
>> +		 */
>> +		vma->vm_pgoff += drm_vma_node_start(&obj->base.vma_node);
> you could have kept my r-b.


I wasn't sure, so I removed it :)


>   Good work here!
>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>


Thanks,

Nirmoy

>
> Thanks,
> Andi
>
>> +	} else {
>> +		/* handle stolen and smem objects */
>> +		mmap_type = i915_ggtt_has_aperture(ggtt) ? I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
>> +		mmo = mmap_offset_attach(obj, mmap_type, NULL);
>> +		if (!mmo)
>> +			return -ENODEV;
>> +	}
>> +
>> +	/*
>> +	 * When we install vm_ops for mmap we are too late for
>> +	 * the vm_ops->open() which increases the ref_count of
>> +	 * this obj and then it gets decreased by the vm_ops->close().
>> +	 * To balance this increase the obj ref_count here.
>> +	 */
>> +	obj = i915_gem_object_get(obj);
>> +	return i915_gem_object_mmap(obj, mmo, vma);
>> +}

^ permalink raw reply	[flat|nested] 40+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
                   ` (9 preceding siblings ...)
  (?)
@ 2023-04-05  0:30 ` Patchwork
  -1 siblings, 0 replies; 40+ messages in thread
From: Patchwork @ 2023-04-05  0:30 UTC (permalink / raw)
  To: Nirmoy Das; +Cc: intel-gfx

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

== Series Details ==

Series: series starting with [1/5] drm/i915/ttm: Add I915_BO_PREALLOC
URL   : https://patchwork.freedesktop.org/series/116093/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12965_full -> Patchwork_116093v1_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
------------------------------

  No changes in participating hosts

Known issues
------------

  Here are the changes found in Patchwork_116093v1_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_eio@in-flight-contexts-1us:
    - shard-snb:          [PASS][1] -> [FAIL][2] ([i915#7942])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-snb4/igt@gem_eio@in-flight-contexts-1us.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-snb4/igt@gem_eio@in-flight-contexts-1us.html

  * igt@gem_huc_copy@huc-copy:
    - shard-apl:          NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@gem_huc_copy@huc-copy.html
    - shard-glk:          NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@heavy-multi:
    - shard-glk:          NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk9/igt@gem_lmem_swapping@heavy-multi.html

  * igt@gem_lmem_swapping@verify-random-ccs:
    - shard-apl:          NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +1 similar issue
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl1/igt@gem_lmem_swapping@verify-random-ccs.html

  * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
    - shard-glk:          NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk9/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
    - shard-apl:          NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs:
    - shard-apl:          NOTRUN -> [SKIP][9] ([fdo#109271]) +58 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@kms_ccs@pipe-b-random-ccs-data-4_tiled_dg2_rc_ccs.html

  * igt@kms_cursor_crc@cursor-random-max-size:
    - shard-glk:          NOTRUN -> [SKIP][10] ([fdo#109271]) +64 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@kms_cursor_crc@cursor-random-max-size.html

  * igt@kms_plane_alpha_blend@alpha-basic@pipe-a-dp-1:
    - shard-apl:          NOTRUN -> [FAIL][11] ([i915#7862]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@kms_plane_alpha_blend@alpha-basic@pipe-a-dp-1.html

  * igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1:
    - shard-glk:          NOTRUN -> [FAIL][12] ([i915#7862]) +1 similar issue
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1.html

  * igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-a-hdmi-a-1:
    - shard-glk:          NOTRUN -> [FAIL][13] ([i915#4573]) +1 similar issue
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk9/igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-a-hdmi-a-1.html

  * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
    - shard-apl:          NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html
    - shard-glk:          NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658]) +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk3/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
    - shard-apl:          [ABORT][16] ([i915#180]) -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl2/igt@gem_ctx_isolation@preservation-s3@rcs0.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl1/igt@gem_ctx_isolation@preservation-s3@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
    - shard-apl:          [FAIL][18] ([i915#2842]) -> [PASS][19]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl7/igt@gem_exec_fair@basic-pace-solo@rcs0.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl2/igt@gem_exec_fair@basic-pace-solo@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
    - {shard-rkl}:        [FAIL][20] ([i915#2842]) -> [PASS][21]
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-rkl-7/igt@gem_exec_fair@basic-pace@rcs0.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-rkl-2/igt@gem_exec_fair@basic-pace@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-apl:          [ABORT][22] ([i915#5566]) -> [PASS][23]
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-apl4/igt@gen9_exec_parse@allowed-single.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-apl3/igt@gen9_exec_parse@allowed-single.html

  * igt@i915_pm_dc@dc6-dpms:
    - {shard-tglu}:       [FAIL][24] ([i915#3989] / [i915#454]) -> [PASS][25]
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-tglu-8/igt@i915_pm_dc@dc6-dpms.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-tglu-9/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_cursor_legacy@single-move@pipe-b:
    - shard-glk:          [DMESG-WARN][26] ([i915#118]) -> [PASS][27]
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-glk9/igt@kms_cursor_legacy@single-move@pipe-b.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-glk5/igt@kms_cursor_legacy@single-move@pipe-b.html

  * igt@kms_plane_scaling@i915-max-src-size@pipe-a-hdmi-a-2:
    - {shard-rkl}:        [FAIL][28] -> [PASS][29]
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12965/shard-rkl-4/igt@kms_plane_scaling@i915-max-src-size@pipe-a-hdmi-a-2.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/shard-rkl-2/igt@kms_plane_scaling@i915-max-src-size@pipe-a-hdmi-a-2.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302
  [fdo#109303]: https://bugs.freedesktop.org/show_bug.cgi?id=109303
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1257]: https://gitlab.freedesktop.org/drm/intel/issues/1257
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2434]: https://gitlab.freedesktop.org/drm/intel/issues/2434
  [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
  [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#315]: https://gitlab.freedesktop.org/drm/intel/issues/315
  [i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
  [i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
  [i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
  [i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
  [i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
  [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#3938]: https://gitlab.freedesktop.org/drm/intel/issues/3938
  [i915#3952]: https://gitlab.freedesktop.org/drm/intel/issues/3952
  [i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989
  [i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
  [i915#4349]: https://gitlab.freedesktop.org/drm/intel/issues/4349
  [i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#4573]: https://gitlab.freedesktop.org/drm/intel/issues/4573
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4771]: https://gitlab.freedesktop.org/drm/intel/issues/4771
  [i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
  [i915#4816]: https://gitlab.freedesktop.org/drm/intel/issues/4816
  [i915#4833]: https://gitlab.freedesktop.org/drm/intel/issues/4833
  [i915#4852]: https://gitlab.freedesktop.org/drm/intel/issues/4852
  [i915#4860]: https://gitlab.freedesktop.org/drm/intel/issues/4860
  [i915#4879]: https://gitlab.freedesktop.org/drm/intel/issues/4879
  [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
  [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
  [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
  [i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
  [i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439
  [i915#5563]: https://gitlab.freedesktop.org/drm/intel/issues/5563
  [i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
  [i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
  [i915#6301]: https://gitlab.freedesktop.org/drm/intel/issues/6301
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#7116]: https://gitlab.freedesktop.org/drm/intel/issues/7116
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7711]: https://gitlab.freedesktop.org/drm/intel/issues/7711
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7862]: https://gitlab.freedesktop.org/drm/intel/issues/7862
  [i915#7942]: https://gitlab.freedesktop.org/drm/intel/issues/7942
  [i915#8150]: https://gitlab.freedesktop.org/drm/intel/issues/8150
  [i915#8211]: https://gitlab.freedesktop.org/drm/intel/issues/8211
  [i915#8253]: https://gitlab.freedesktop.org/drm/intel/issues/8253
  [i915#8292]: https://gitlab.freedesktop.org/drm/intel/issues/8292


Build changes
-------------

  * Linux: CI_DRM_12965 -> Patchwork_116093v1

  CI-20190529: 20190529
  CI_DRM_12965: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116093v1: 53e37ca502cfe620396e498fae8430c293fb2c83 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116093v1/index.html

[-- Attachment #2: Type: text/html, Size: 10668 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 15:30   ` [Intel-gfx] " Andrzej Hajda
@ 2023-04-05 10:42     ` Das, Nirmoy
  -1 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-05 10:42 UTC (permalink / raw)
  To: Andrzej Hajda, Nirmoy Das, intel-gfx; +Cc: Jani Nikula, Matthew Auld, dri-devel


On 4/4/2023 5:30 PM, Andrzej Hajda wrote:
>
>
> On 04.04.2023 16:30, Nirmoy Das wrote:
>> Add a mechanism to keep existing data when creating
>> a ttm object with I915_BO_ALLOC_USER flag.
>>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++++++++++----
>>   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c     |  5 +++--
>>   2 files changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
>> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>> index 5dcbbef31d44..830c11431ee8 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>> @@ -328,6 +328,12 @@ struct drm_i915_gem_object {
>>    */
>>   #define I915_BO_ALLOC_GPU_ONLY      BIT(6)
>>   #define I915_BO_ALLOC_CCS_AUX      BIT(7)
>> +/*
>> + * Object is allowed to retain its initial data and will not be 
>> cleared on first
>> + * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
>> + * preallocated framebuffer data intact while transitioning it to 
>> i915drmfb.
>> + */
>> +#define I915_BO_PREALLOC      BIT(8)
>>   #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
>>                    I915_BO_ALLOC_VOLATILE | \
>>                    I915_BO_ALLOC_CPU_CLEAR | \
>> @@ -335,10 +341,11 @@ struct drm_i915_gem_object {
>>                    I915_BO_ALLOC_PM_VOLATILE | \
>>                    I915_BO_ALLOC_PM_EARLY | \
>>                    I915_BO_ALLOC_GPU_ONLY | \
>> -                 I915_BO_ALLOC_CCS_AUX)
>> -#define I915_BO_READONLY          BIT(8)
>> -#define I915_TILING_QUIRK_BIT     9 /* unknown swizzling; do not 
>> release! */
>> -#define I915_BO_PROTECTED         BIT(10)
>> +                 I915_BO_ALLOC_CCS_AUX | \
>> +                 I915_BO_PREALLOC)
>> +#define I915_BO_READONLY          BIT(9)
>> +#define I915_TILING_QUIRK_BIT     10 /* unknown swizzling; do not 
>> release! */
>> +#define I915_BO_PROTECTED         BIT(11)
>>       /**
>>        * @mem_flags - Mutable placement-related flags
>>        *
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>> index dd188dfcc423..69eb20ed4d47 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>> @@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, 
>> bool evict,
>>       struct dma_fence *migration_fence = NULL;
>>       struct ttm_tt *ttm = bo->ttm;
>>       struct i915_refct_sgt *dst_rsgt;
>> -    bool clear;
>> +    bool clear, prealloc_bo;
>>       int ret;
>>         if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
>> @@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, 
>> bool evict,
>>           return PTR_ERR(dst_rsgt);
>>         clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || 
>> !ttm_tt_is_populated(ttm));
>> -    if (!(clear && ttm && !(ttm->page_flags & 
>> TTM_TT_FLAG_ZERO_ALLOC))) {
>> +    prealloc_bo = obj->flags & I915_BO_PREALLOC;
>> +    if (!(clear && ttm && !((ttm->page_flags & 
>> TTM_TT_FLAG_ZERO_ALLOC) && !prealloc_bo))) {
>
> This looks like school exercise for complicated usage of logical 
> operators, and I have problem with understanding this :)
> Couldn't this be somehow simplified?

(I thought I sent this email yesterday but was stuck in oAuth pop up 
sign-in)

Yes, this can be improved I think, took me while too.

>
> Anyway as the patch just reuses existing code:
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>


Thanks Andrzej,

Nirmoy

>
> Regards
> Andrzej
>
>
>>           struct i915_deps deps;
>>             i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | 
>> __GFP_NOWARN);
>

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-05 10:42     ` Das, Nirmoy
  0 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-05 10:42 UTC (permalink / raw)
  To: Andrzej Hajda, Nirmoy Das, intel-gfx; +Cc: Jani Nikula, Matthew Auld, dri-devel


On 4/4/2023 5:30 PM, Andrzej Hajda wrote:
>
>
> On 04.04.2023 16:30, Nirmoy Das wrote:
>> Add a mechanism to keep existing data when creating
>> a ttm object with I915_BO_ALLOC_USER flag.
>>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++++++++++----
>>   drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c     |  5 +++--
>>   2 files changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
>> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>> index 5dcbbef31d44..830c11431ee8 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>> @@ -328,6 +328,12 @@ struct drm_i915_gem_object {
>>    */
>>   #define I915_BO_ALLOC_GPU_ONLY      BIT(6)
>>   #define I915_BO_ALLOC_CCS_AUX      BIT(7)
>> +/*
>> + * Object is allowed to retain its initial data and will not be 
>> cleared on first
>> + * access if used along with I915_BO_ALLOC_USER. This is mainly to keep
>> + * preallocated framebuffer data intact while transitioning it to 
>> i915drmfb.
>> + */
>> +#define I915_BO_PREALLOC      BIT(8)
>>   #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
>>                    I915_BO_ALLOC_VOLATILE | \
>>                    I915_BO_ALLOC_CPU_CLEAR | \
>> @@ -335,10 +341,11 @@ struct drm_i915_gem_object {
>>                    I915_BO_ALLOC_PM_VOLATILE | \
>>                    I915_BO_ALLOC_PM_EARLY | \
>>                    I915_BO_ALLOC_GPU_ONLY | \
>> -                 I915_BO_ALLOC_CCS_AUX)
>> -#define I915_BO_READONLY          BIT(8)
>> -#define I915_TILING_QUIRK_BIT     9 /* unknown swizzling; do not 
>> release! */
>> -#define I915_BO_PROTECTED         BIT(10)
>> +                 I915_BO_ALLOC_CCS_AUX | \
>> +                 I915_BO_PREALLOC)
>> +#define I915_BO_READONLY          BIT(9)
>> +#define I915_TILING_QUIRK_BIT     10 /* unknown swizzling; do not 
>> release! */
>> +#define I915_BO_PROTECTED         BIT(11)
>>       /**
>>        * @mem_flags - Mutable placement-related flags
>>        *
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>> index dd188dfcc423..69eb20ed4d47 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>> @@ -576,7 +576,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, 
>> bool evict,
>>       struct dma_fence *migration_fence = NULL;
>>       struct ttm_tt *ttm = bo->ttm;
>>       struct i915_refct_sgt *dst_rsgt;
>> -    bool clear;
>> +    bool clear, prealloc_bo;
>>       int ret;
>>         if (GEM_WARN_ON(i915_ttm_is_ghost_object(bo))) {
>> @@ -632,7 +632,8 @@ int i915_ttm_move(struct ttm_buffer_object *bo, 
>> bool evict,
>>           return PTR_ERR(dst_rsgt);
>>         clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || 
>> !ttm_tt_is_populated(ttm));
>> -    if (!(clear && ttm && !(ttm->page_flags & 
>> TTM_TT_FLAG_ZERO_ALLOC))) {
>> +    prealloc_bo = obj->flags & I915_BO_PREALLOC;
>> +    if (!(clear && ttm && !((ttm->page_flags & 
>> TTM_TT_FLAG_ZERO_ALLOC) && !prealloc_bo))) {
>
> This looks like school exercise for complicated usage of logical 
> operators, and I have problem with understanding this :)
> Couldn't this be somehow simplified?

(I thought I sent this email yesterday but was stuck in oAuth pop up 
sign-in)

Yes, this can be improved I think, took me while too.

>
> Anyway as the patch just reuses existing code:
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>


Thanks Andrzej,

Nirmoy

>
> Regards
> Andrzej
>
>
>>           struct i915_deps deps;
>>             i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | 
>> __GFP_NOWARN);
>

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-04 16:23   ` [Intel-gfx] " Andi Shyti
@ 2023-04-05 10:52     ` Das, Nirmoy
  -1 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-05 10:52 UTC (permalink / raw)
  To: Andi Shyti, Nirmoy Das
  Cc: Jani Nikula, intel-gfx, Matthew Auld, dri-devel, Andrzej Hajda


On 4/4/2023 6:23 PM, Andi Shyti wrote:
> Hi Nirmoy,
>
> On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
>> Add a mechanism to keep existing data when creating
>> a ttm object with I915_BO_ALLOC_USER flag.
> why do we need this mechanism? What was the logic behind? These
> are all questions people might have when checking this commit.
> Please be a bit more explicative.


Agree, the commit message is bit short. I will add more content in next 
revision.

>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>


Thanks,

Nirmoy

>
> Thanks,
> Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-05 10:52     ` Das, Nirmoy
  0 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-05 10:52 UTC (permalink / raw)
  To: Andi Shyti, Nirmoy Das
  Cc: Jani Nikula, intel-gfx, Matthew Auld, dri-devel, Andrzej Hajda


On 4/4/2023 6:23 PM, Andi Shyti wrote:
> Hi Nirmoy,
>
> On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
>> Add a mechanism to keep existing data when creating
>> a ttm object with I915_BO_ALLOC_USER flag.
> why do we need this mechanism? What was the logic behind? These
> are all questions people might have when checking this commit.
> Please be a bit more explicative.


Agree, the commit message is bit short. I will add more content in next 
revision.

>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>


Thanks,

Nirmoy

>
> Thanks,
> Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-05 10:52     ` [Intel-gfx] " Das, Nirmoy
@ 2023-04-05 11:53       ` Andi Shyti
  -1 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-05 11:53 UTC (permalink / raw)
  To: Das, Nirmoy
  Cc: Andrzej Hajda, Jani Nikula, intel-gfx, dri-devel, Matthew Auld,
	Andi Shyti, Nirmoy Das

Hi Nirmoy,

> > > Add a mechanism to keep existing data when creating
> > > a ttm object with I915_BO_ALLOC_USER flag.
> > why do we need this mechanism? What was the logic behind? These
> > are all questions people might have when checking this commit.
> > Please be a bit more explicative.
> 
> 
> Agree, the commit message is bit short. I will add more content in next
> revision.

you don't need to send a new version just for this commit log.

You could just propose a new commit log in the reply and if it's
OK, add it before pushing it.

As you wish.

Andi

> > 
> > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Cc: Imre Deak <imre.deak@intel.com>
> > > Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> > Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> 
> 
> Thanks,
> 
> Nirmoy
> 
> > 
> > Thanks,
> > Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-05 11:53       ` Andi Shyti
  0 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-05 11:53 UTC (permalink / raw)
  To: Das, Nirmoy
  Cc: Andrzej Hajda, Jani Nikula, intel-gfx, dri-devel, Matthew Auld,
	Nirmoy Das

Hi Nirmoy,

> > > Add a mechanism to keep existing data when creating
> > > a ttm object with I915_BO_ALLOC_USER flag.
> > why do we need this mechanism? What was the logic behind? These
> > are all questions people might have when checking this commit.
> > Please be a bit more explicative.
> 
> 
> Agree, the commit message is bit short. I will add more content in next
> revision.

you don't need to send a new version just for this commit log.

You could just propose a new commit log in the reply and if it's
OK, add it before pushing it.

As you wish.

Andi

> > 
> > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > > Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Cc: Imre Deak <imre.deak@intel.com>
> > > Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> > Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> 
> 
> Thanks,
> 
> Nirmoy
> 
> > 
> > Thanks,
> > Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-05 11:53       ` [Intel-gfx] " Andi Shyti
@ 2023-04-05 12:36         ` Das, Nirmoy
  -1 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-05 12:36 UTC (permalink / raw)
  To: Andi Shyti
  Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld, Andrzej Hajda,
	Nirmoy Das

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

Hi Andi,

On 4/5/2023 1:53 PM, Andi Shyti wrote:
> Hi Nirmoy,
>
>>>> Add a mechanism to keep existing data when creating
>>>> a ttm object with I915_BO_ALLOC_USER flag.
>>> why do we need this mechanism? What was the logic behind? These
>>> are all questions people might have when checking this commit.
>>> Please be a bit more explicative.
>>
>> Agree, the commit message is bit short. I will add more content in next
>> revision.
> you don't need to send a new version just for this commit log.
>
> You could just propose a new commit log in the reply and if it's
> OK, add it before pushing it.

Let me know what do you think about:

Add a mechanism to preserve existing data when creating a TTM

object with the I915_BO_ALLOC_USER flag. This will be used in the subsequent

patch where the I915_BO_ALLOC_USER flag will be applied to the framebuffer

object. For a pre-allocated framebuffer without the I915_BO_PREALLOC flag,

TTM would clear the content, which is not desirable.

Thanks,

Nirmoy

>
> As you wish.
>
> Andi
>
>>>> Cc: Matthew Auld<matthew.auld@intel.com>
>>>> Cc: Andi Shyti<andi.shyti@linux.intel.com>
>>>> Cc: Andrzej Hajda<andrzej.hajda@intel.com>
>>>> Cc: Ville Syrjälä<ville.syrjala@linux.intel.com>
>>>> Cc: Jani Nikula<jani.nikula@intel.com>
>>>> Cc: Imre Deak<imre.deak@intel.com>
>>>> Signed-off-by: Nirmoy Das<nirmoy.das@intel.com>
>>> Reviewed-by: Andi Shyti<andi.shyti@linux.intel.com>
>>
>> Thanks,
>>
>> Nirmoy
>>
>>> Thanks,
>>> Andi

[-- Attachment #2: Type: text/html, Size: 3751 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-05 12:36         ` Das, Nirmoy
  0 siblings, 0 replies; 40+ messages in thread
From: Das, Nirmoy @ 2023-04-05 12:36 UTC (permalink / raw)
  To: Andi Shyti
  Cc: Jani Nikula, intel-gfx, dri-devel, Matthew Auld, Andrzej Hajda,
	Nirmoy Das

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

Hi Andi,

On 4/5/2023 1:53 PM, Andi Shyti wrote:
> Hi Nirmoy,
>
>>>> Add a mechanism to keep existing data when creating
>>>> a ttm object with I915_BO_ALLOC_USER flag.
>>> why do we need this mechanism? What was the logic behind? These
>>> are all questions people might have when checking this commit.
>>> Please be a bit more explicative.
>>
>> Agree, the commit message is bit short. I will add more content in next
>> revision.
> you don't need to send a new version just for this commit log.
>
> You could just propose a new commit log in the reply and if it's
> OK, add it before pushing it.

Let me know what do you think about:

Add a mechanism to preserve existing data when creating a TTM

object with the I915_BO_ALLOC_USER flag. This will be used in the subsequent

patch where the I915_BO_ALLOC_USER flag will be applied to the framebuffer

object. For a pre-allocated framebuffer without the I915_BO_PREALLOC flag,

TTM would clear the content, which is not desirable.

Thanks,

Nirmoy

>
> As you wish.
>
> Andi
>
>>>> Cc: Matthew Auld<matthew.auld@intel.com>
>>>> Cc: Andi Shyti<andi.shyti@linux.intel.com>
>>>> Cc: Andrzej Hajda<andrzej.hajda@intel.com>
>>>> Cc: Ville Syrjälä<ville.syrjala@linux.intel.com>
>>>> Cc: Jani Nikula<jani.nikula@intel.com>
>>>> Cc: Imre Deak<imre.deak@intel.com>
>>>> Signed-off-by: Nirmoy Das<nirmoy.das@intel.com>
>>> Reviewed-by: Andi Shyti<andi.shyti@linux.intel.com>
>>
>> Thanks,
>>
>> Nirmoy
>>
>>> Thanks,
>>> Andi

[-- Attachment #2: Type: text/html, Size: 3751 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
  2023-04-05 12:36         ` [Intel-gfx] " Das, Nirmoy
@ 2023-04-05 13:52           ` Andi Shyti
  -1 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-05 13:52 UTC (permalink / raw)
  To: Das, Nirmoy
  Cc: Andrzej Hajda, Jani Nikula, intel-gfx, dri-devel, Matthew Auld,
	Andi Shyti, Nirmoy Das

> Add a mechanism to preserve existing data when creating a TTM
> object with the I915_BO_ALLOC_USER flag. This will be used in the subsequent
> patch where the I915_BO_ALLOC_USER flag will be applied to the framebuffer
> object. For a pre-allocated framebuffer without the I915_BO_PREALLOC flag,
> TTM would clear the content, which is not desirable.

ack!

Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC
@ 2023-04-05 13:52           ` Andi Shyti
  0 siblings, 0 replies; 40+ messages in thread
From: Andi Shyti @ 2023-04-05 13:52 UTC (permalink / raw)
  To: Das, Nirmoy
  Cc: Andrzej Hajda, Jani Nikula, intel-gfx, dri-devel, Matthew Auld,
	Nirmoy Das

> Add a mechanism to preserve existing data when creating a TTM
> object with the I915_BO_ALLOC_USER flag. This will be used in the subsequent
> patch where the I915_BO_ALLOC_USER flag will be applied to the framebuffer
> object. For a pre-allocated framebuffer without the I915_BO_PREALLOC flag,
> TTM would clear the content, which is not desirable.

ack!

Andi

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
  2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
@ 2023-04-05 14:11     ` Andrzej Hajda
  -1 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-05 14:11 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld, Andi Shyti



On 04.04.2023 16:30, Nirmoy Das wrote:
> Framebuffer is exposed to userspace so make sure we set
> proper flags for it. Set I915_BO_PREALLOC for prealloced
> fb so that ttm won't clear existing data.
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Regards
Andrzej
> ---
>   drivers/gpu/drm/i915/display/intel_fbdev.c         | 3 ++-
>   drivers/gpu/drm/i915/display/intel_plane_initial.c | 4 +++-
>   2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 673bcdfb7ff6..f7d48d00ae4b 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -163,7 +163,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>   	obj = ERR_PTR(-ENODEV);
>   	if (HAS_LMEM(dev_priv)) {
>   		obj = i915_gem_object_create_lmem(dev_priv, size,
> -						  I915_BO_ALLOC_CONTIGUOUS);
> +						  I915_BO_ALLOC_CONTIGUOUS |
> +						  I915_BO_ALLOC_USER);
>   	} else {
>   		/*
>   		 * If the FB is too big, just don't use it since fbdev is not very
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index bb6ea7de5c61..736072a8b2b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -110,7 +110,9 @@ initial_plane_vma(struct drm_i915_private *i915,
>   	    size * 2 > i915->dsm.usable_size)
>   		return NULL;
>   
> -	obj = i915_gem_object_create_region_at(mem, phys_base, size, 0);
> +	obj = i915_gem_object_create_region_at(mem, phys_base, size,
> +					       I915_BO_ALLOC_USER |
> +					       I915_BO_PREALLOC);
>   	if (IS_ERR(obj))
>   		return NULL;
>   


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb
@ 2023-04-05 14:11     ` Andrzej Hajda
  0 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-05 14:11 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld



On 04.04.2023 16:30, Nirmoy Das wrote:
> Framebuffer is exposed to userspace so make sure we set
> proper flags for it. Set I915_BO_PREALLOC for prealloced
> fb so that ttm won't clear existing data.
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Regards
Andrzej
> ---
>   drivers/gpu/drm/i915/display/intel_fbdev.c         | 3 ++-
>   drivers/gpu/drm/i915/display/intel_plane_initial.c | 4 +++-
>   2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 673bcdfb7ff6..f7d48d00ae4b 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -163,7 +163,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>   	obj = ERR_PTR(-ENODEV);
>   	if (HAS_LMEM(dev_priv)) {
>   		obj = i915_gem_object_create_lmem(dev_priv, size,
> -						  I915_BO_ALLOC_CONTIGUOUS);
> +						  I915_BO_ALLOC_CONTIGUOUS |
> +						  I915_BO_ALLOC_USER);
>   	} else {
>   		/*
>   		 * If the FB is too big, just don't use it since fbdev is not very
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index bb6ea7de5c61..736072a8b2b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -110,7 +110,9 @@ initial_plane_vma(struct drm_i915_private *i915,
>   	    size * 2 > i915->dsm.usable_size)
>   		return NULL;
>   
> -	obj = i915_gem_object_create_region_at(mem, phys_base, size, 0);
> +	obj = i915_gem_object_create_region_at(mem, phys_base, size,
> +					       I915_BO_ALLOC_USER |
> +					       I915_BO_PREALLOC);
>   	if (IS_ERR(obj))
>   		return NULL;
>   


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
  2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
@ 2023-04-05 14:13     ` Andrzej Hajda
  -1 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-05 14:13 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld, Andi Shyti



On 04.04.2023 16:30, Nirmoy Das wrote:
> Add a helper function to retrieve struct intel_fbdev from
> struct drm_fb_helper.
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Regards
Andrzej

> ---
>   drivers/gpu/drm/i915/display/intel_fbdev.c | 23 ++++++++++------------
>   1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index f7d48d00ae4b..2ac9e9f8a128 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -67,6 +67,11 @@ struct intel_fbdev {
>   	struct mutex hpd_lock;
>   };
>   
> +static struct intel_fbdev *to_intel_fbdev(struct drm_fb_helper *fb_helper)
> +{
> +	return container_of(fb_helper, struct intel_fbdev, helper);
> +}
> +
>   static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev *ifbdev)
>   {
>   	return ifbdev->fb->frontbuffer;
> @@ -79,9 +84,7 @@ static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
>   
>   static int intel_fbdev_set_par(struct fb_info *info)
>   {
> -	struct drm_fb_helper *fb_helper = info->par;
> -	struct intel_fbdev *ifbdev =
> -		container_of(fb_helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>   	int ret;
>   
>   	ret = drm_fb_helper_set_par(info);
> @@ -93,9 +96,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
>   
>   static int intel_fbdev_blank(int blank, struct fb_info *info)
>   {
> -	struct drm_fb_helper *fb_helper = info->par;
> -	struct intel_fbdev *ifbdev =
> -		container_of(fb_helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>   	int ret;
>   
>   	ret = drm_fb_helper_blank(blank, info);
> @@ -108,9 +109,7 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
>   static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
>   				   struct fb_info *info)
>   {
> -	struct drm_fb_helper *fb_helper = info->par;
> -	struct intel_fbdev *ifbdev =
> -		container_of(fb_helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>   	int ret;
>   
>   	ret = drm_fb_helper_pan_display(var, info);
> @@ -136,8 +135,7 @@ static const struct fb_ops intelfb_ops = {
>   static int intelfb_alloc(struct drm_fb_helper *helper,
>   			 struct drm_fb_helper_surface_size *sizes)
>   {
> -	struct intel_fbdev *ifbdev =
> -		container_of(helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>   	struct drm_framebuffer *fb;
>   	struct drm_device *dev = helper->dev;
>   	struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -194,8 +192,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>   static int intelfb_create(struct drm_fb_helper *helper,
>   			  struct drm_fb_helper_surface_size *sizes)
>   {
> -	struct intel_fbdev *ifbdev =
> -		container_of(helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>   	struct intel_framebuffer *intel_fb = ifbdev->fb;
>   	struct drm_device *dev = helper->dev;
>   	struct drm_i915_private *dev_priv = to_i915(dev);


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
@ 2023-04-05 14:13     ` Andrzej Hajda
  0 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-05 14:13 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld



On 04.04.2023 16:30, Nirmoy Das wrote:
> Add a helper function to retrieve struct intel_fbdev from
> struct drm_fb_helper.
>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

Regards
Andrzej

> ---
>   drivers/gpu/drm/i915/display/intel_fbdev.c | 23 ++++++++++------------
>   1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index f7d48d00ae4b..2ac9e9f8a128 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -67,6 +67,11 @@ struct intel_fbdev {
>   	struct mutex hpd_lock;
>   };
>   
> +static struct intel_fbdev *to_intel_fbdev(struct drm_fb_helper *fb_helper)
> +{
> +	return container_of(fb_helper, struct intel_fbdev, helper);
> +}
> +
>   static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev *ifbdev)
>   {
>   	return ifbdev->fb->frontbuffer;
> @@ -79,9 +84,7 @@ static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
>   
>   static int intel_fbdev_set_par(struct fb_info *info)
>   {
> -	struct drm_fb_helper *fb_helper = info->par;
> -	struct intel_fbdev *ifbdev =
> -		container_of(fb_helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>   	int ret;
>   
>   	ret = drm_fb_helper_set_par(info);
> @@ -93,9 +96,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
>   
>   static int intel_fbdev_blank(int blank, struct fb_info *info)
>   {
> -	struct drm_fb_helper *fb_helper = info->par;
> -	struct intel_fbdev *ifbdev =
> -		container_of(fb_helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>   	int ret;
>   
>   	ret = drm_fb_helper_blank(blank, info);
> @@ -108,9 +109,7 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
>   static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
>   				   struct fb_info *info)
>   {
> -	struct drm_fb_helper *fb_helper = info->par;
> -	struct intel_fbdev *ifbdev =
> -		container_of(fb_helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>   	int ret;
>   
>   	ret = drm_fb_helper_pan_display(var, info);
> @@ -136,8 +135,7 @@ static const struct fb_ops intelfb_ops = {
>   static int intelfb_alloc(struct drm_fb_helper *helper,
>   			 struct drm_fb_helper_surface_size *sizes)
>   {
> -	struct intel_fbdev *ifbdev =
> -		container_of(helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>   	struct drm_framebuffer *fb;
>   	struct drm_device *dev = helper->dev;
>   	struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -194,8 +192,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>   static int intelfb_create(struct drm_fb_helper *helper,
>   			  struct drm_fb_helper_surface_size *sizes)
>   {
> -	struct intel_fbdev *ifbdev =
> -		container_of(helper, struct intel_fbdev, helper);
> +	struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>   	struct intel_framebuffer *intel_fb = ifbdev->fb;
>   	struct drm_device *dev = helper->dev;
>   	struct drm_i915_private *dev_priv = to_i915(dev);


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
  2023-04-05 14:13     ` [Intel-gfx] " Andrzej Hajda
@ 2023-04-05 14:14       ` Andrzej Hajda
  -1 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-05 14:14 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld, Andi Shyti



On 05.04.2023 16:13, Andrzej Hajda wrote:
>
>
> On 04.04.2023 16:30, Nirmoy Das wrote:
>> Add a helper function to retrieve struct intel_fbdev from
>> struct drm_fb_helper.
>>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
>
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>


Ups, please ignore :)

>
> Regards
> Andrzej
>
>> ---
>>   drivers/gpu/drm/i915/display/intel_fbdev.c | 23 ++++++++++------------
>>   1 file changed, 10 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
>> b/drivers/gpu/drm/i915/display/intel_fbdev.c
>> index f7d48d00ae4b..2ac9e9f8a128 100644
>> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
>> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
>> @@ -67,6 +67,11 @@ struct intel_fbdev {
>>       struct mutex hpd_lock;
>>   };
>>   +static struct intel_fbdev *to_intel_fbdev(struct drm_fb_helper 
>> *fb_helper)
>> +{
>> +    return container_of(fb_helper, struct intel_fbdev, helper);
>> +}
>> +
>>   static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev 
>> *ifbdev)
>>   {
>>       return ifbdev->fb->frontbuffer;
>> @@ -79,9 +84,7 @@ static void intel_fbdev_invalidate(struct 
>> intel_fbdev *ifbdev)
>>     static int intel_fbdev_set_par(struct fb_info *info)
>>   {
>> -    struct drm_fb_helper *fb_helper = info->par;
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(fb_helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>>       int ret;
>>         ret = drm_fb_helper_set_par(info);
>> @@ -93,9 +96,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
>>     static int intel_fbdev_blank(int blank, struct fb_info *info)
>>   {
>> -    struct drm_fb_helper *fb_helper = info->par;
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(fb_helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>>       int ret;
>>         ret = drm_fb_helper_blank(blank, info);
>> @@ -108,9 +109,7 @@ static int intel_fbdev_blank(int blank, struct 
>> fb_info *info)
>>   static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
>>                      struct fb_info *info)
>>   {
>> -    struct drm_fb_helper *fb_helper = info->par;
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(fb_helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>>       int ret;
>>         ret = drm_fb_helper_pan_display(var, info);
>> @@ -136,8 +135,7 @@ static const struct fb_ops intelfb_ops = {
>>   static int intelfb_alloc(struct drm_fb_helper *helper,
>>                struct drm_fb_helper_surface_size *sizes)
>>   {
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>>       struct drm_framebuffer *fb;
>>       struct drm_device *dev = helper->dev;
>>       struct drm_i915_private *dev_priv = to_i915(dev);
>> @@ -194,8 +192,7 @@ static int intelfb_alloc(struct drm_fb_helper 
>> *helper,
>>   static int intelfb_create(struct drm_fb_helper *helper,
>>                 struct drm_fb_helper_surface_size *sizes)
>>   {
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>>       struct intel_framebuffer *intel_fb = ifbdev->fb;
>>       struct drm_device *dev = helper->dev;
>>       struct drm_i915_private *dev_priv = to_i915(dev);
>


^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [Intel-gfx] [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper
@ 2023-04-05 14:14       ` Andrzej Hajda
  0 siblings, 0 replies; 40+ messages in thread
From: Andrzej Hajda @ 2023-04-05 14:14 UTC (permalink / raw)
  To: Nirmoy Das, intel-gfx; +Cc: Jani Nikula, dri-devel, Matthew Auld



On 05.04.2023 16:13, Andrzej Hajda wrote:
>
>
> On 04.04.2023 16:30, Nirmoy Das wrote:
>> Add a helper function to retrieve struct intel_fbdev from
>> struct drm_fb_helper.
>>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
>
> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>


Ups, please ignore :)

>
> Regards
> Andrzej
>
>> ---
>>   drivers/gpu/drm/i915/display/intel_fbdev.c | 23 ++++++++++------------
>>   1 file changed, 10 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
>> b/drivers/gpu/drm/i915/display/intel_fbdev.c
>> index f7d48d00ae4b..2ac9e9f8a128 100644
>> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
>> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
>> @@ -67,6 +67,11 @@ struct intel_fbdev {
>>       struct mutex hpd_lock;
>>   };
>>   +static struct intel_fbdev *to_intel_fbdev(struct drm_fb_helper 
>> *fb_helper)
>> +{
>> +    return container_of(fb_helper, struct intel_fbdev, helper);
>> +}
>> +
>>   static struct intel_frontbuffer *to_frontbuffer(struct intel_fbdev 
>> *ifbdev)
>>   {
>>       return ifbdev->fb->frontbuffer;
>> @@ -79,9 +84,7 @@ static void intel_fbdev_invalidate(struct 
>> intel_fbdev *ifbdev)
>>     static int intel_fbdev_set_par(struct fb_info *info)
>>   {
>> -    struct drm_fb_helper *fb_helper = info->par;
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(fb_helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>>       int ret;
>>         ret = drm_fb_helper_set_par(info);
>> @@ -93,9 +96,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
>>     static int intel_fbdev_blank(int blank, struct fb_info *info)
>>   {
>> -    struct drm_fb_helper *fb_helper = info->par;
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(fb_helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>>       int ret;
>>         ret = drm_fb_helper_blank(blank, info);
>> @@ -108,9 +109,7 @@ static int intel_fbdev_blank(int blank, struct 
>> fb_info *info)
>>   static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
>>                      struct fb_info *info)
>>   {
>> -    struct drm_fb_helper *fb_helper = info->par;
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(fb_helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(info->par);
>>       int ret;
>>         ret = drm_fb_helper_pan_display(var, info);
>> @@ -136,8 +135,7 @@ static const struct fb_ops intelfb_ops = {
>>   static int intelfb_alloc(struct drm_fb_helper *helper,
>>                struct drm_fb_helper_surface_size *sizes)
>>   {
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>>       struct drm_framebuffer *fb;
>>       struct drm_device *dev = helper->dev;
>>       struct drm_i915_private *dev_priv = to_i915(dev);
>> @@ -194,8 +192,7 @@ static int intelfb_alloc(struct drm_fb_helper 
>> *helper,
>>   static int intelfb_create(struct drm_fb_helper *helper,
>>                 struct drm_fb_helper_surface_size *sizes)
>>   {
>> -    struct intel_fbdev *ifbdev =
>> -        container_of(helper, struct intel_fbdev, helper);
>> +    struct intel_fbdev *ifbdev = to_intel_fbdev(helper);
>>       struct intel_framebuffer *intel_fb = ifbdev->fb;
>>       struct drm_device *dev = helper->dev;
>>       struct drm_i915_private *dev_priv = to_i915(dev);
>


^ permalink raw reply	[flat|nested] 40+ messages in thread

end of thread, other threads:[~2023-04-05 14:14 UTC | newest]

Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-04 14:30 [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC Nirmoy Das
2023-04-04 14:30 ` [Intel-gfx] " Nirmoy Das
2023-04-04 14:30 ` [PATCH 2/5] drm/i915/display: Set I915_BO_ALLOC_USER for fb Nirmoy Das
2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
2023-04-04 16:36   ` Andi Shyti
2023-04-04 16:36     ` [Intel-gfx] " Andi Shyti
2023-04-05 14:11   ` Andrzej Hajda
2023-04-05 14:11     ` [Intel-gfx] " Andrzej Hajda
2023-04-04 14:30 ` [PATCH 3/5] drm/i915: Add a function to mmap framebuffer obj Nirmoy Das
2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
2023-04-04 16:57   ` Andi Shyti
2023-04-04 16:57     ` [Intel-gfx] " Andi Shyti
2023-04-04 17:59     ` Das, Nirmoy
2023-04-04 17:59       ` [Intel-gfx] " Das, Nirmoy
2023-04-04 14:30 ` [PATCH 4/5] drm/i915/display: Add helper func to get intel_fbdev from drm_fb_helper Nirmoy Das
2023-04-04 14:30   ` [Intel-gfx] " Nirmoy Das
2023-04-05 14:13   ` Andrzej Hajda
2023-04-05 14:13     ` [Intel-gfx] " Andrzej Hajda
2023-04-05 14:14     ` Andrzej Hajda
2023-04-05 14:14       ` [Intel-gfx] " Andrzej Hajda
2023-04-04 14:31 ` [PATCH 5/5] drm/i915/display: Implement fb_mmap callback function Nirmoy Das
2023-04-04 14:31   ` [Intel-gfx] " Nirmoy Das
2023-04-04 15:30 ` [PATCH 1/5] drm/i915/ttm: Add I915_BO_PREALLOC Andrzej Hajda
2023-04-04 15:30   ` [Intel-gfx] " Andrzej Hajda
2023-04-05 10:42   ` Das, Nirmoy
2023-04-05 10:42     ` [Intel-gfx] " Das, Nirmoy
2023-04-04 15:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] " Patchwork
2023-04-04 15:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-04 16:00 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-04 16:23 ` [PATCH 1/5] " Andi Shyti
2023-04-04 16:23   ` [Intel-gfx] " Andi Shyti
2023-04-05 10:52   ` Das, Nirmoy
2023-04-05 10:52     ` [Intel-gfx] " Das, Nirmoy
2023-04-05 11:53     ` Andi Shyti
2023-04-05 11:53       ` [Intel-gfx] " Andi Shyti
2023-04-05 12:36       ` Das, Nirmoy
2023-04-05 12:36         ` [Intel-gfx] " Das, Nirmoy
2023-04-05 13:52         ` Andi Shyti
2023-04-05 13:52           ` [Intel-gfx] " Andi Shyti
2023-04-05  0:30 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] " Patchwork

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.