* [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.