date:20211122

This patch series deals with async migration and async vram management.
It still leaves an important part out, which is async unbinding which
will reduce latency further, at least when trying to migrate already active
objects.

Patches 1/6 deals with accessing and waiting for the TTM moving
fence from i915 GEM.
Patch 2 is pure code reorganization, no functional change.
Patch 3 breaks a refcounting loop involving the TTM moving fence.
Patch 4 makes the i915 TTM shinking code handle async moves.
Patch 5 uses TTM to implement the ttm move() callback async, it also
introduces a utility to collect dependencies and turn them into a
single dma_fence, which is needed for the intel_migrate code.
This also affects the gem object migrate code.
Patch 6 makes the object copy utility async as well, mainly for future
users since the only current user, suspend backup and restore, typically
will want to sync anyway.

v2:
- Fix a couple of SPARSE warnings.
v3:
- Fix a NULL pointer dereference.
v4:
- Squash what was previously patch 1 and 2 to patch1
- Ditch the moving fence waiting in i915_vma_pin_iomap()
- Rework how the refcounting loop is broken in patch 3. Drop region
  reference counting.
- Break what is now patch 4 out of patch 5. Add support for avoiding
  waiting for gpu when shrinking.
- A number of changes in patch 5. See the commit message for details.
v5:
- Some fixes to i915_vma_verify_bind_complete() (Matthew Auld)
- Update patches with R-B.
v6:
- Code comment update
- Re-check for fence signaled before returning -EBUSY (Matthew Auld)
- Use dma_resv_iter_is_exclusive() (Matthew Auld)
- Await all dma-resv fences before a migration blit (Matthew Auld)

Maarten Lankhorst (1):
  drm/i915: Add support for moving fence waiting

Thomas Hellström (5):
  drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function
  drm/i915/ttm: Drop region reference counting
  drm/i915/ttm: Correctly handle waiting for gpu when shrinking
  drm/i915/ttm: Implement asynchronous TTM moves
  drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronous

 drivers/gpu/drm/i915/gem/i915_gem_object.c|  52 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   6 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   6 +
 drivers/gpu/drm/i915/gem/i915_gem_region.c|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  89 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 409 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h  |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c|   3 +
 drivers/gpu/drm/i915/gem/i915_gem_wait.c  |   4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   |  10 +-
 drivers/gpu/drm/i915/i915_vma.c   |  39 +-
 drivers/gpu/drm/i915/intel_memory_region.c|  26 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   9 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   |  35 +-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   2 +-
 .../drm/i915/selftests/intel_memory_region.c  |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   7 +-
 23 files changed, 595 insertions(+), 143 deletions(-)

-- 
2.31.1

[PATCH v6 2/6] drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function

Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h.
This will help keep a number of functions static when introducing
async moves.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 47 ---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h  |  4 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 63 
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 10 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  1 +
 5 files changed, 56 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 68cfe6e9ceab..537a81445b90 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1063,50 +1063,3 @@ i915_gem_ttm_system_setup(struct drm_i915_private *i915,
intel_memory_region_set_name(mr, "system-ttm");
return mr;
 }
-
-/**
- * i915_gem_obj_copy_ttm - Copy the contents of one ttm-based gem object to
- * another
- * @dst: The destination object
- * @src: The source object
- * @allow_accel: Allow using the blitter. Otherwise TTM memcpy is used.
- * @intr: Whether to perform waits interruptible:
- *
- * Note: The caller is responsible for assuring that the underlying
- * TTM objects are populated if needed and locked.
- *
- * Return: Zero on success. Negative error code on error. If @intr == true,
- * then it may return -ERESTARTSYS or -EINTR.
- */
-int i915_gem_obj_copy_ttm(struct drm_i915_gem_object *dst,
- struct drm_i915_gem_object *src,
- bool allow_accel, bool intr)
-{
-   struct ttm_buffer_object *dst_bo = i915_gem_to_ttm(dst);
-   struct ttm_buffer_object *src_bo = i915_gem_to_ttm(src);
-   struct ttm_operation_ctx ctx = {
-   .interruptible = intr,
-   };
-   struct i915_refct_sgt *dst_rsgt;
-   int ret;
-
-   assert_object_held(dst);
-   assert_object_held(src);
-
-   /*
-* Sync for now. This will change with async moves.
-*/
-   ret = ttm_bo_wait_ctx(dst_bo, &ctx);
-   if (!ret)
-   ret = ttm_bo_wait_ctx(src_bo, &ctx);
-   if (ret)
-   return ret;
-
-   dst_rsgt = i915_ttm_resource_get_st(dst, dst_bo->resource);
-   __i915_ttm_move(src_bo, false, dst_bo->resource, dst_bo->ttm,
-   dst_rsgt, allow_accel);
-
-   i915_refct_sgt_put(dst_rsgt);
-
-   return 0;
-}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
index 074a7c08ff31..82cdabb542be 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h
@@ -49,10 +49,6 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
   resource_size_t page_size,
   unsigned int flags);
 
-int i915_gem_obj_copy_ttm(struct drm_i915_gem_object *dst,
- struct drm_i915_gem_object *src,
- bool allow_accel, bool intr);
-
 /* Internal I915 TTM declarations and definitions below. */
 
 #define I915_PL_LMEM0 TTM_PL_PRIV
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 ef22d4ed66ad..f35b386c56ca 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -378,18 +378,10 @@ i915_ttm_memcpy_work_arm(struct i915_ttm_memcpy_work 
*work,
return &work->fence;
 }
 
-/**
- * __i915_ttm_move - helper to perform TTM moves or clears.
- * @bo: The source buffer object.
- * @clear: Whether this is a clear operation.
- * @dst_mem: The destination ttm resource.
- * @dst_ttm: The destination ttm page vector.
- * @dst_rsgt: The destination refcounted sg-list.
- * @allow_accel: Whether to allow acceleration.
- */
-void __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
-struct ttm_resource *dst_mem, struct ttm_tt *dst_ttm,
-struct i915_refct_sgt *dst_rsgt, bool allow_accel)
+static void __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
+   struct ttm_resource *dst_mem,
+   struct ttm_tt *dst_ttm,
+   struct i915_refct_sgt *dst_rsgt, bool allow_accel)
 {
struct i915_ttm_memcpy_work *copy_work = NULL;
struct i915_ttm_memcpy_arg _arg, *arg = &_arg;
@@ -521,3 +513,50 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
i915_ttm_adjust_gem_after_move(obj);
return 0;
 }
+
+/**
+ * i915_gem_obj_copy_ttm - Copy the contents of one ttm-based gem object to
+ * another
+ * @dst: The destination object
+ * @src: The source object
+ * @allow_accel: Allow using the blitter. Otherwise TTM memcpy is used.
+ * @intr: Whether to perform waits interruptible:
+ *
+ * Note: The caller is responsible for assuring that the underl

[PATCH v6 1/6] drm/i915: Add support for moving fence waiting

From: Maarten Lankhorst 

For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.

The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a cpu map will only work after
the moving fence signals.

This should close all holes where userspace can read a buffer
before it's fully migrated.

v2:
- Fix a couple of SPARSE warnings
v3:
- Fix a NULL pointer dereference
v4:
- Ditch the moving fence waiting for i915_vma_pin_iomap() and
  replace with a verification that the vma is already bound.
  (Matthew Auld)
- Squash with a previous patch introducing moving fence waiting and
  accessing interfaces (Matthew Auld)
- Rename to indicated that we also add support for sync waiting.
v5:
- Fix check for NULL and unreferencing i915_vma_verify_bind_complete()
  (Matthew Auld)
- Fix compilation failure if !CONFIG_DRM_I915_DEBUG_GEM
- Fix include ordering. (Matthew Auld)

Co-developed-by: Thomas Hellström 
Signed-off-by: Thomas Hellström 
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 52 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  6 +++
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  |  6 +++
 drivers/gpu/drm/i915/i915_vma.c| 39 +++-
 4 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 591ee3cb7275..24f83c432350 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -31,6 +31,7 @@
 #include "i915_gem_context.h"
 #include "i915_gem_mman.h"
 #include "i915_gem_object.h"
+#include "i915_gem_ttm.h"
 #include "i915_memcpy.h"
 #include "i915_trace.h"
 
@@ -726,6 +727,57 @@ static const struct drm_gem_object_funcs 
i915_gem_object_funcs = {
.export = i915_gem_prime_export,
 };
 
+/**
+ * i915_gem_object_get_moving_fence - Get the object's moving fence if any
+ * @obj: The object whose moving fence to get.
+ *
+ * A non-signaled moving fence means that there is an async operation
+ * pending on the object that needs to be waited on before setting up
+ * any GPU- or CPU PTEs to the object's pages.
+ *
+ * Return: A refcounted pointer to the object's moving fence if any,
+ * NULL otherwise.
+ */
+struct dma_fence *
+i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj)
+{
+   return dma_fence_get(i915_gem_to_ttm(obj)->moving);
+}
+
+/**
+ * i915_gem_object_wait_moving_fence - Wait for the object's moving fence if 
any
+ * @obj: The object whose moving fence to wait for.
+ * @intr: Whether to wait interruptible.
+ *
+ * If the moving fence signaled without an error, it is detached from the
+ * object and put.
+ *
+ * Return: 0 if successful, -ERESTARTSYS if the wait was interrupted,
+ * negative error code if the async operation represented by the
+ * moving fence failed.
+ */
+int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
+ bool intr)
+{
+   struct dma_fence *fence = i915_gem_to_ttm(obj)->moving;
+   int ret;
+
+   assert_object_held(obj);
+   if (!fence)
+   return 0;
+
+   ret = dma_fence_wait(fence, intr);
+   if (ret)
+   return ret;
+
+   if (fence->error)
+   return fence->error;
+
+   i915_gem_to_ttm(obj)->moving = NULL;
+   dma_fence_put(fence);
+   return 0;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/huge_gem_object.c"
 #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 133963b46135..66f20b803b01 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -517,6 +517,12 @@ i915_gem_object_finish_access(struct drm_i915_gem_object 
*obj)
i915_gem_object_unpin_pages(obj);
 }
 
+struct dma_fence *
+i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj);
+
+int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj,
+ bool intr);
+
 void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
 unsigned int cache_level);
 bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index c4f684b7cc51..49c6e55c68ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -418,6 +418,12 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
}
 
if (!ptr) {
+   err = i915_gem_object_wait_moving_fence(obj, true);
+   if (err) {
+   ptr = ERR_PTR(err);
+

[PATCH v6 3/6] drm/i915/ttm: Drop region reference counting

There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a reference to drm_i915_gem_object,
drm_i915_gem_object may hold a reference to intel_memory_region.

Break this loop by dropping region reference counting.

In addition, Have regions with a manager moving fence make sure
that all region objects are released before freeing the region.

v6:
- Fix a code comment.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_region.c|  4 +--
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  6 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  3 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   | 10 --
 drivers/gpu/drm/i915/intel_memory_region.c| 26 --
 drivers/gpu/drm/i915/intel_memory_region.h|  9 ++---
 drivers/gpu/drm/i915/intel_region_ttm.c   | 35 +--
 drivers/gpu/drm/i915/intel_region_ttm.h   |  2 +-
 .../drm/i915/selftests/intel_memory_region.c  |  8 ++---
 drivers/gpu/drm/i915/selftests/mock_region.c  |  7 ++--
 12 files changed, 69 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index a016ccec36f3..a4350227e9ae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -11,7 +11,7 @@
 void i915_gem_object_init_memory_region(struct drm_i915_gem_object *obj,
struct intel_memory_region *mem)
 {
-   obj->mm.region = intel_memory_region_get(mem);
+   obj->mm.region = mem;
 
mutex_lock(&mem->objects.lock);
list_add(&obj->mm.region_link, &mem->objects.list);
@@ -25,8 +25,6 @@ void i915_gem_object_release_memory_region(struct 
drm_i915_gem_object *obj)
mutex_lock(&mem->objects.lock);
list_del(&obj->mm.region_link);
mutex_unlock(&mem->objects.lock);
-
-   intel_memory_region_put(mem);
 }
 
 struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 4a88c89b7a14..cc9fe258fba7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -664,9 +664,10 @@ static int init_shmem(struct intel_memory_region *mem)
return 0; /* Don't error, we can simply fallback to the kernel mnt */
 }
 
-static void release_shmem(struct intel_memory_region *mem)
+static int release_shmem(struct intel_memory_region *mem)
 {
i915_gemfs_fini(mem->i915);
+   return 0;
 }
 
 static const struct intel_memory_region_ops shmem_region_ops = {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index ddd37ccb1362..80680395bb3b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -720,9 +720,10 @@ static int init_stolen_smem(struct intel_memory_region 
*mem)
return i915_gem_init_stolen(mem);
 }
 
-static void release_stolen_smem(struct intel_memory_region *mem)
+static int release_stolen_smem(struct intel_memory_region *mem)
 {
i915_gem_cleanup_stolen(mem->i915);
+   return 0;
 }
 
 static const struct intel_memory_region_ops i915_region_stolen_smem_ops = {
@@ -759,10 +760,11 @@ static int init_stolen_lmem(struct intel_memory_region 
*mem)
return err;
 }
 
-static void release_stolen_lmem(struct intel_memory_region *mem)
+static int release_stolen_lmem(struct intel_memory_region *mem)
 {
io_mapping_fini(&mem->iomap);
i915_gem_cleanup_stolen(mem->i915);
+   return 0;
 }
 
 static const struct intel_memory_region_ops i915_region_stolen_lmem_ops = {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 537a81445b90..350bf1a23db5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -997,7 +997,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
 
/* Don't put on a region list until we're either locked or fully 
initialized. */
-   obj->mm.region = intel_memory_region_get(mem);
+   obj->mm.region = mem;
INIT_LIST_HEAD(&obj->mm.region_link);
 
INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | __GFP_NOWARN);
@@ -1044,6 +1044,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 
 static const struct intel_memory_region_ops ttm_system_region_ops = {
.init_object = __i915_gem_ttm_object_init,
+   .release = intel_region_ttm_fini,
 };
 
 struct intel_memory_region *
diff --git a/drivers/gpu/drm/i9

[PATCH v6 4/6] drm/i915/ttm: Correctly handle waiting for gpu when shrinking

With async migration, the shrinker may end up wanting to release the
pages of an object while the migration blit is still running, since
the GT migration code doesn't set up VMAs and the shrinker is thus
oblivious to the fact that the GPU is still using the pages.

Add waiting for gpu in the shrinker_release_pages() op and an
argument to that function indicating whether the shrinker expects it
to not wait for gpu. In the latter case the shrinker_release_pages()
op will return -EBUSY if the object is not idle.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 7 ++-
 3 files changed, 8 insertions(+), 1 deletion(-)

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 604ed5ad77f5..f9f7e44099fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -59,6 +59,7 @@ struct drm_i915_gem_object_ops {
int (*truncate)(struct drm_i915_gem_object *obj);
void (*writeback)(struct drm_i915_gem_object *obj);
int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
+ bool no_gpu_wait,
  bool should_writeback);
 
int (*pread)(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index dde0a5c232f8..8b4b5f3a432a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -60,6 +60,7 @@ static int try_to_writeback(struct drm_i915_gem_object *obj, 
unsigned int flags)
 {
if (obj->ops->shrinker_release_pages)
return obj->ops->shrinker_release_pages(obj,
+   !(flags & 
I915_SHRINK_ACTIVE),
flags & 
I915_SHRINK_WRITEBACK);
 
switch (obj->mm.madv) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 350bf1a23db5..e37157b080e4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -418,6 +418,7 @@ int i915_ttm_purge(struct drm_i915_gem_object *obj)
 }
 
 static int i915_ttm_shrinker_release_pages(struct drm_i915_gem_object *obj,
+  bool no_wait_gpu,
   bool should_writeback)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
@@ -425,7 +426,7 @@ static int i915_ttm_shrinker_release_pages(struct 
drm_i915_gem_object *obj,
container_of(bo->ttm, typeof(*i915_tt), ttm);
struct ttm_operation_ctx ctx = {
.interruptible = true,
-   .no_wait_gpu = false,
+   .no_wait_gpu = no_wait_gpu,
};
struct ttm_placement place = {};
int ret;
@@ -438,6 +439,10 @@ static int i915_ttm_shrinker_release_pages(struct 
drm_i915_gem_object *obj,
if (!i915_tt->filp)
return 0;
 
+   ret = ttm_bo_wait_ctx(bo, &ctx);
+   if (ret)
+   return ret;
+
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
return i915_ttm_purge(obj);
-- 
2.31.1

[PATCH v6 5/6] drm/i915/ttm: Implement asynchronous TTM moves

Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.

This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before freeing VRAM,
it is freed immediately and the fence is stored with the VRAM manager and
handed out to newly allocated objects to await before clears and swapins,
or for kernel objects before setting up gpu vmas or mapping.

To collect dependencies before migrating, add a set of utilities that
coalesce these to a single dma_fence.

What is still missing for fully asynchronous operation is asynchronous vma
unbinding, which is still to be implemented.

This commit substantially reduces execution time in the gem_lmem_swapping
test.

v2:
- Make a couple of functions static.
v4:
- Fix some style issues (Matthew Auld)
- Audit and add more checks for ghost objects (Matthew Auld)
- Add more documentation for the i915_deps utility (Mattew Auld)
- Simplify the i915_deps_sync() function
v6:
- Re-check for fence signaled before returning -EBUSY (Matthew Auld)
- Use dma_resv_iter_is_exclusive() (Matthew Auld)
- Await all dma-resv fences before a migration blit (Matthew Auld)

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  32 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 342 +--
 drivers/gpu/drm/i915/gem/i915_gem_wait.c |   4 +-
 4 files changed, 348 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e37157b080e4..81e84c1763de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -248,10 +248,13 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, bo->resource->mem_type);
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
-   enum ttm_caching caching = i915_ttm_select_tt_caching(obj);
+   enum ttm_caching caching;
struct i915_ttm_tt *i915_tt;
int ret;
 
+   if (!obj)
+   return NULL;
+
i915_tt = kzalloc(sizeof(*i915_tt), GFP_KERNEL);
if (!i915_tt)
return NULL;
@@ -260,6 +263,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
man->use_tt)
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
 
+   caching = i915_ttm_select_tt_caching(obj);
if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached) {
page_flags |= TTM_TT_FLAG_EXTERNAL |
  TTM_TT_FLAG_EXTERNAL_MAPPABLE;
@@ -326,6 +330,9 @@ static bool i915_ttm_eviction_valuable(struct 
ttm_buffer_object *bo,
 {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
 
+   if (!obj)
+   return false;
+
/*
 * EXTERNAL objects should never be swapped out by TTM, instead we need
 * to handle that ourselves. TTM will already skip such objects for us,
@@ -552,8 +559,12 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
 static void i915_ttm_swap_notify(struct ttm_buffer_object *bo)
 {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
-   int ret = i915_ttm_move_notify(bo);
+   int ret;
 
+   if (!obj)
+   return;
+
+   ret = i915_ttm_move_notify(bo);
GEM_WARN_ON(ret);
GEM_WARN_ON(obj->ttm.cached_io_rsgt);
if (!ret && obj->mm.madv != I915_MADV_WILLNEED)
@@ -575,17 +586,23 @@ static unsigned long i915_ttm_io_mem_pfn(struct 
ttm_buffer_object *bo,
 unsigned long page_offset)
 {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
-   unsigned long base = obj->mm.region->iomap.base - 
obj->mm.region->region.start;
struct scatterlist *sg;
+   unsigned long base;
unsigned int ofs;
 
+   GEM_BUG_ON(!obj);
GEM_WARN_ON(bo->ttm);
 
+   base = obj->mm.region->iomap.base - obj->mm.region->region.start;
sg = __i915_gem_object_get_sg(obj, &obj->ttm.get_io_page, page_offset, 
&ofs, true);
 
return ((base + sg_dma_address(sg)) >> PAGE_SHIFT) + ofs;
 }
 
+/*
+ * All callbacks need to take care not to downcast a struct ttm_buffer_object
+ * without checking its subclass, since it might be a TTM ghost object.
+ */
 static struct ttm_device_funcs i915_ttm_bo_driver = {
.ttm_tt_create = i915_ttm_tt_create,
.ttm_tt_populate = i915_ttm_tt_populate,
@@ -847,13 +864,16 @@ static void i915_ttm_delayed_free(struct 
drm_i915_gem_object *obj)
 static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
 {
struct vm_area_struct *area = vmf->vma;
-   struct drm_i915_gem_object *obj =
-   i915_ttm_to_gem(area->vm_private_data);
-   struct ttm_buffe

[PATCH v6 6/6] drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronous

Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for
future users and update the only current user to sync the objects
as needed after this function.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   |  2 +
 2 files changed, 30 insertions(+), 12 deletions(-)

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 43423d3976c3..80df9f592407 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -826,33 +826,49 @@ int i915_gem_obj_copy_ttm(struct drm_i915_gem_object *dst,
.interruptible = intr,
};
struct i915_refct_sgt *dst_rsgt;
-   struct dma_fence *copy_fence;
-   int ret;
+   struct dma_fence *copy_fence, *dep_fence;
+   struct i915_deps deps;
+   int ret, shared_err;
 
assert_object_held(dst);
assert_object_held(src);
+   i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
 
/*
-* Sync for now. This will change with async moves.
+* We plan to add a shared fence only for the source. If that
+* fails, we await all source fences before commencing
+* the copy instead of only the exclusive.
 */
-   ret = ttm_bo_wait_ctx(dst_bo, &ctx);
+   shared_err = dma_resv_reserve_shared(src_bo->base.resv, 1);
+   ret = i915_deps_add_resv(&deps, dst_bo->base.resv, true, false, &ctx);
if (!ret)
-   ret = ttm_bo_wait_ctx(src_bo, &ctx);
+   ret = i915_deps_add_resv(&deps, src_bo->base.resv,
+!!shared_err, false, &ctx);
if (ret)
return ret;
 
+   dep_fence = i915_deps_to_fence(&deps, &ctx);
+   if (IS_ERR(dep_fence))
+   return PTR_ERR(dep_fence);
+
dst_rsgt = i915_ttm_resource_get_st(dst, dst_bo->resource);
copy_fence = __i915_ttm_move(src_bo, false, dst_bo->resource,
-dst_bo->ttm, dst_rsgt, allow_accel, NULL);
+dst_bo->ttm, dst_rsgt, allow_accel,
+dep_fence);
 
i915_refct_sgt_put(dst_rsgt);
-   if (IS_ERR(copy_fence))
-   return PTR_ERR(copy_fence);
+   if (IS_ERR_OR_NULL(copy_fence))
+   return PTR_ERR_OR_ZERO(copy_fence);
 
-   if (copy_fence) {
-   dma_fence_wait(copy_fence, false);
-   dma_fence_put(copy_fence);
-   }
+   dma_resv_add_excl_fence(dst_bo->base.resv, copy_fence);
+
+   /* If we failed to reserve a shared slot, add an exclusive fence */
+   if (shared_err)
+   dma_resv_add_excl_fence(src_bo->base.resv, copy_fence);
+   else
+   dma_resv_add_shared_fence(src_bo->base.resv, copy_fence);
+
+   dma_fence_put(copy_fence);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 60d10ab55d1e..9aad84059d56 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -80,6 +80,7 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region 
*apply,
 
err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu, false);
GEM_WARN_ON(err);
+   ttm_bo_wait_ctx(backup_bo, &ctx);
 
obj->ttm.backup = backup;
return 0;
@@ -170,6 +171,7 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region 
*apply,
err = i915_gem_obj_copy_ttm(obj, backup, pm_apply->allow_gpu,
false);
GEM_WARN_ON(err);
+   ttm_bo_wait_ctx(backup_bo, &ctx);
 
obj->ttm.backup = NULL;
err = 0;
-- 
2.31.1

Re: [PATCH] drm/i915: Remove unused intel_gmbus_set_speed() function

On Sun, 21 Nov 2021, Hans de Goede  wrote:
> The intel_gmbus_set_speed() function is not used anywhere, remove it.
>
> Note drivers/gpu/drm/gma500 has its own copy called
> gma_intel_gmbus_set_speed() which is used, the intel_gmbus_set_speed()
> version in the i915 code is not used at all

Wow, the last user might have been removed by me. In 2012.

commit 6cb1612a7dc4c3d5ed86dba5dd21bb48a5c395af
Author: Jani Nikula 
Date:   Mon Oct 22 16:12:17 2012 +0300

drm/i915/sdvo: force GPIO bit-banging also on default pin

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/display/intel_gmbus.c | 7 ---
>  drivers/gpu/drm/i915/display/intel_gmbus.h | 1 -
>  2 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index ceb1bf8a8c3c..343f85543446 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -922,13 +922,6 @@ struct i2c_adapter *intel_gmbus_get_adapter(struct 
> drm_i915_private *dev_priv,
>   return &dev_priv->gmbus[pin].adapter;
>  }
>  
> -void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed)
> -{
> - struct intel_gmbus *bus = to_intel_gmbus(adapter);
> -
> - bus->reg0 = (bus->reg0 & ~(0x3 << 8)) | speed;
> -}
> -
>  void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
>  {
>   struct intel_gmbus *bus = to_intel_gmbus(adapter);
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.h 
> b/drivers/gpu/drm/i915/display/intel_gmbus.h
> index b96212b85425..8edc2e99cf53 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.h
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.h
> @@ -41,7 +41,6 @@ int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
>  
>  struct i2c_adapter *
>  intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
> -void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed);
>  void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit);
>  bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter);
>  void intel_gmbus_reset(struct drm_i915_private *dev_priv);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] drm/i915/ttm: Fix error code in i915_ttm_eviction_valuable()

2021-11-22 Thread Matthew Auld


On 22/11/2021 07:41, Dan Carpenter wrote:

This function returns a bool type so returning -EBUSY is equivalent to
returning true.  It should return false instead.

Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Dan Carpenter 

Reviewed-by: Matthew Auld

Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Fri, 19 Nov 2021 11:21:36 -0500
Jason Baron  wrote:

> On 11/18/21 10:24 AM, Pekka Paalanen wrote:
> > On Thu, 18 Nov 2021 09:29:27 -0500
> > Jason Baron  wrote:
> >   
> >> On 11/16/21 3:46 AM, Pekka Paalanen wrote:  
> >>> On Fri, 12 Nov 2021 10:08:41 -0500
> >>> Jason Baron  wrote:
> >>> 
>  On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
> > On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:  
> >> Sean Paul proposed, in:
> >> https://urldefense.com/v3/__https://patchwork.freedesktop.org/series/78133/__;!!GjvTz_vk!HcKnMRByYkIdyF1apqQjlN5aBIomzJR1an3YWXM6KXs0EftVMQdrewRA8Dki4A$
> >>  
> >> drm/trace: Mirror DRM debug logs to tracefs
> >>
> >> His patchset's objective is to be able to independently steer some of
> >> the drm.debug stream to an alternate tracing destination, by splitting
> >> drm_debug_enabled() into syslog & trace flavors, and enabling them
> >> separately.  2 advantages were identified:
> >>
> >> 1- syslog is heavyweight, tracefs is much lighter
> >> 2- separate selection of enabled categories means less traffic
> >>
> >> Dynamic-Debug can do 2nd exceedingly well:
> >>
> >> A- all work is behind jump-label's NOOP, zero off cost.
> >> B- exact site selectivity, precisely the useful traffic.
> >>can tailor enabled set interactively, at shell.
> >>
> >> Since the tracefs interface is effective for drm (the threads suggest
> >> so), adding that interface to dynamic-debug has real potential for
> >> everyone including drm.
> >>
> >> if CONFIG_TRACING:
> >>
> >> Grab Sean's trace_init/cleanup code, use it to provide tracefs
> >> available by default to all pr_debugs.  This will likely need some
> >> further per-module treatment; perhaps something reflecting hierarchy
> >> of module,file,function,line, maybe with a tuned flattening.
> >>
> >> endif CONFIG_TRACING
> >>
> >> Add a new +T flag to enable tracing, independent of +p, and add and
> >> use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
> >> the flag checks.  Existing code treats T like other flags.  
> >
> > I posted a patchset a while ago to do something very similar, but that
> > got stalled for some reason and I unfortunately didn't follow it up:
> >
> >  
> > https://urldefense.com/v3/__https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchu...@axis.com/__;!!GjvTz_vk!HcKnMRByYkIdyF1apqQjlN5aBIomzJR1an3YWXM6KXs0EftVMQdrewRGytKHPg$
> >  
> >
> > A key difference between that patchset and this patch (besides that
> > small fact that I used +x instead of +T) was that my patchset allowed
> > the dyndbg trace to be emitted to the main buffer and did not force them
> > to be in an instance-specific buffer.  
> 
>  Yes, I agree I'd prefer that we print here to the 'main' buffer - it
>  seems to keep things simpler and easier to combine the output from
>  different sources as you mentioned.
> >>>
> >>> Hi,
> >>>
> >>> I'm not quite sure I understand this discussion, but I would like to
> >>> remind you all of what Sean's original work is about:
> >>>
> >>> Userspace configures DRM tracing into a flight recorder buffer (I guess
> >>> this is what you refer to "instance-specific buffer").
> >>>
> >>> Userspace runs happily for months, and then hits a problem: a failure
> >>> in the DRM sub-system most likely, e.g. an ioctl that should never
> >>> fail, failed. Userspace handles that failure by dumping the flight
> >>> recorder buffer into a file and saving or sending a bug report. The
> >>> flight recorder contents give a log of all relevant DRM in-kernel
> >>> actions leading to the unexpected failure to help developers debug it.
> >>>
> >>> I don't mind if one can additionally send the flight recorder stream to
> >>> the main buffer, but I do want the separate flight recorder buffer to
> >>> be an option so that a) unrelated things cannot flood the interesting
> >>> bits out of it, and b) the scope of collected information is relevant.
> >>>
> >>> The very reason for this work is problems that are very difficult to
> >>> reproduce in practice, either because the problem itself is triggered
> >>> very rarely and randomly, or because the end users of the system have
> >>> either no knowledge or no access to reconfigure debug logging and then
> >>> reproduce the problem with good debug logs.
> >>>
> >>> Thank you very much for pushing this work forward!
> >>>
> >>> 
> >>
> >> So I think Vincent (earlier in the thread) was saying that he finds it
> >> very helpful have dynamic debug output go to the 'main' trace buffer,
> >> while you seem to be saying you'd prefer it just go to dynamic debug
> >> specific trace buffer.  
> > 
> > Seems like we have different use cases: traditional debugging, and
> > in-production flight recorder for problem reporting. I'm not s

Re: [PATCH linux-next] drm/i915/request: Remove unused variables

On Sun, 21 Nov 2021, Christophe JAILLET  wrote:
> Le 21/11/2021 à 11:13, cgel@gmail.com a écrit :
>> From: yong yiran 
>> 
>> The clang_analyzer complains as follows:
>> drivers/gpu/drm/i915/i915_request.c:2119:2 warning:
>> Value stored to 'x' is never read
>> 
>> Reported-by: Zeal Robot 
>> Signed-off-by: yong yiran 

The sender's Signed-off-by is missing.

>> ---
>>   drivers/gpu/drm/i915/i915_request.c | 3 ---
>>   1 file changed, 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_request.c 
>> b/drivers/gpu/drm/i915/i915_request.c
>> index 820a1f38b271..5e4420f461e9 100644
>> --- a/drivers/gpu/drm/i915/i915_request.c
>> +++ b/drivers/gpu/drm/i915/i915_request.c
>> @@ -2047,7 +2047,6 @@ void i915_request_show(struct drm_printer *m,
>>   {
>>  const char *name = rq->fence.ops->get_timeline_name((struct dma_fence 
>> *)&rq->fence);
>>  char buf[80] = "";
>> -int x = 0;
>>   
>>  /*
>>   * The prefix is used to show the queue status, for which we use
>> @@ -2079,8 +2078,6 @@ void i915_request_show(struct drm_printer *m,
>>   *  from the lists
>>   */
>>   
>> -x = print_sched_attr(&rq->sched.attr, buf, x, sizeof(buf));
>> -
>
> Seriously?

Basically I've started considering all of these patches as static
analyzer reports *only*. The "fixes" have often been completely wrong or
have missed the real issue and merely silenced the warning.

I really couldn't say anything about the "Zeal Robot" itself, but the
patches are giving it a bad reputation.


BR,
Jani.




>
> CJ
>
>
>>  drm_printf(m, "%s%.*s%c %llx:%lld%s%s %s @ %dms: %s\n",
>> prefix, indent, "",
>> queue_status(rq),
>> 
>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 1/2] drm/i915/backlight: Drop duplicate intel_panel_actually_set_backlight()

On Sun, 21 Nov 2021, Hans de Goede  wrote:
> After the recent refactoring of the backlight code the contents of
> intel_panel_actually_set_backlight() is exactly the same (minus a
> small wording difference in the drm_dbg_kms() as the contents if the
> more widely used intel_backlight_set_pwm_level() function.
>
> Drop the duplicate intel_panel_actually_set_backlight() function.
>
> Signed-off-by: Hans de Goede 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_backlight.c | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 9523411cddd8..03cd730c926a 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -268,18 +268,6 @@ static void ext_pwm_set_backlight(const struct 
> drm_connector_state *conn_state,
>   pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
>  }
>  
> -static void
> -intel_panel_actually_set_backlight(const struct drm_connector_state 
> *conn_state, u32 level)
> -{
> - struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
> - struct drm_i915_private *i915 = to_i915(connector->base.dev);
> - struct intel_panel *panel = &connector->panel;
> -
> - drm_dbg_kms(&i915->drm, "set backlight level = %d\n", level);
> -
> - panel->backlight.funcs->set(conn_state, level);
> -}
> -
>  /* set backlight brightness to level in range [0..max], assuming hw min is
>   * respected.
>   */
> @@ -314,7 +302,7 @@ void intel_backlight_set_acpi(const struct 
> drm_connector_state *conn_state,
>
> panel->backlight.device->props.max_brightness);
>  
>   if (panel->backlight.enabled)
> - intel_panel_actually_set_backlight(conn_state, hw_level);
> + intel_backlight_set_pwm_level(conn_state, hw_level);
>  
>   mutex_unlock(&dev_priv->backlight_lock);
>  }
> @@ -863,7 +851,7 @@ static void intel_panel_set_backlight(const struct 
> drm_connector_state *conn_sta
>   panel->backlight.level = hw_level;
>  
>   if (panel->backlight.enabled)
> - intel_panel_actually_set_backlight(conn_state, hw_level);
> + intel_backlight_set_pwm_level(conn_state, hw_level);
>  
>   mutex_unlock(&dev_priv->backlight_lock);
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 2/2] drm/i915/backlight: Make ext_pwm_disable_backlight() call intel_backlight_set_pwm_level()

On Sun, 21 Nov 2021, Hans de Goede  wrote:
> At least the Bay Trail LPSS PWM controller used with DSI panels on many
> Bay Trail tablets seems to leave the PWM pin in whatever state it was
> (high or low) ATM that the PWM gets disabled. Combined with some panels
> not having a separate backlight-enable pin this leads to the backlight
> sometimes staying on while it should not (when the pin was high during
> PWM-disabling).
>
> First calling intel_backlight_set_pwm_level() will ensure that the pin
> is always low (or high for inverted brightness panels) since the passed
> in duty-cycle is 0% (or 100%) when the PWM gets disabled fixing the
> backlight sometimes staying on.
>
> With the exception of ext_pwm_disable_backlight() all other
> foo_disable_backlight() functions call intel_backlight_set_pwm_level()
> already before disabling the backlight, so this change also aligns
> ext_pwm_disable_backlight() with all the other disable() functions.
>
> Signed-off-by: Hans de Goede 

I'll take your word for it.

Acked-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/display/intel_backlight.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 03cd730c926a..2758a2f6c093 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -421,6 +421,8 @@ static void ext_pwm_disable_backlight(const struct 
> drm_connector_state *old_conn
>   struct intel_connector *connector = 
> to_intel_connector(old_conn_state->connector);
>   struct intel_panel *panel = &connector->panel;
>  
> + intel_backlight_set_pwm_level(old_conn_state, level);
> +
>   panel->backlight.pwm_state.enabled = false;
>   pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v2 1/2] drm/input_helper: Add new input-handling helper

On Fri, 19 Nov 2021 16:56:01 +0100
Daniel Vetter  wrote:

> On Fri, Nov 19, 2021 at 12:38:41PM +0200, Pekka Paalanen wrote:
> > On Thu, 18 Nov 2021 17:46:10 -0800
> > Brian Norris  wrote:
> >   
> > > Hi Pekka,
> > > 
> > > Thanks for the thoughts and review. I've tried to respond below:
> > > 
> > > On Thu, Nov 18, 2021 at 12:39:28PM +0200, Pekka Paalanen wrote:  
> > > > On Wed, 17 Nov 2021 14:48:40 -0800
> > > > Brian Norris  wrote:
> > > > 
> > > > > A variety of applications have found it useful to listen to
> > > > > user-initiated input events to make decisions within a DRM driver, 
> > > > > given
> > > > > that input events are often the first sign that we're going to start
> > > > > doing latency-sensitive activities:
> > > > > 
> > > > >  * Panel self-refresh: software-directed self-refresh (e.g., with
> > > > >Rockchip eDP) is especially latency sensitive. In some cases, it 
> > > > > can
> > > > >take 10s of milliseconds for a panel to exit self-refresh, which 
> > > > > can
> > > > >be noticeable. Rockchip RK3399 Chrome OS systems have always 
> > > > > shipped
> > > > >with an input_handler boost, that preemptively exits self-refresh
> > > > >whenever there is input activity.
> > > > > 
> > > > >  * GPU drivers: on GPU-accelerated desktop systems, we may need to
> > > > >render new frames immediately after user activity. Powering up the
> > > > >GPU can take enough time that it is worthwhile to start this 
> > > > > process
> > > > >as soon as there is input activity. Many Chrome OS systems also 
> > > > > ship
> > > > >with an input_handler boost that powers up the GPU.
> > > > > 
> > > > > This patch provides a small helper library that abstracts some of the
> > > > > input-subsystem details around picking which devices to listen to, and
> > > > > some other boilerplate. This will be used in the next patch to 
> > > > > implement
> > > > > the first bullet: preemptive exit for panel self-refresh.
> > > > > 
> > > > > Bits of this are adapted from code the Android and/or Chrome OS 
> > > > > kernels
> > > > > have been carrying for a while.
> > > > > 
> > > > > Signed-off-by: Brian Norris 
> > > > > ---
> > > > 
> > > > Thanks Simon for the CC.
> > > > 
> > > > Hi Brian,
> > > > 
> > > > while this feature in general makes sense and sounds good, to start
> > > > warming up display hardware early when something might start to happen,
> > > > this particular proposal has many problems from UAPI perspective (as it
> > > > has none). Comments below.
> > > > 
> > > > Btw. if PSR is that slow to wake up from, how much do you actually gain
> > > > from this input event watching? I would imagine the improvement to not
> > > > be noticeable.
> > > 
> > > Patch 2 has details. It's not really about precisely how slow PSR is,
> > > but how much foresight we can gain: in patch 2, I note that with my
> > > particular user space and system, I can start PSR-exit 50ms earlier than
> > > I would otherweise. (FWIW, this measurement is exactly the same it was
> > > with the original version written 4 years ago.)
> > > 
> > > For how long PSR-exit takes: the measurements I'm able to do (via
> > > ftrace) show that drm_self_refresh_transition() takes between 35 and 55
> > > ms. That's noticeable at 60 fps. And quite conveniently, the input-boost
> > > manages to hide nearly 100% of that latency.
> > > 
> > > Typical use cases where one notices PSR latency (and where this 35-55ms
> > > matters) involve simply moving a cursor; it's very noticeable when you
> > > have more than a few frames of latency to "get started".  
> > 
> > Hi Brian,
> > 
> > that is very interesting, thanks.
> > 
> > I would never have expected to have userspace take *that* long to
> > react. But, that sounds like it could be just your userspace software
> > stack.  
> 
> In the other subthread we're talking about making this more explicit.
> Maybe we need to combine this with a "I expect to take this many
> milliseconds to get the first frame out" value.
> 
> That way compositors which take 50ms (which frankly is shocking slow) can
> set that, and kms can enable sr exit (since sr exit will actually help
> here). But other compositors which expect to get the first frame out in
> maybe 20 can spec that, and then the driver will not sr exit (because too
> high chances we'll just make shit slower), and instead will only boost
> render clocks.
> 
> Thoughts?

I wonder if the compositor or the userspace stack can know how long it
usually takes to prepare the first KMS submission after a pause. I
guess it would need to measure that at runtime. Hmm, doable I guess,
sure. Input to output latency in general is interesting.

However, that sounds like a pretty vague API with the delay value. I
think it has a high risk of regressing into a boolean toggle by
userspace choosing an arbitrary number and then assuming the threshold
in the driver is always the same.


Thanks,
pq


pgpO_4Ma15NN4.pgp
Description:

Re: [PATCH bpf] treewide: add missing includes masked by cgroup -> bpf dependency

On Fri, 19 Nov 2021, Jakub Kicinski  wrote:
> cgroup.h (therefore swap.h, therefore half of the universe)
> includes bpf.h which in turn includes module.h and slab.h.
> Since we're about to get rid of that dependency we need
> to clean things up.
>
> Signed-off-by: Jakub Kicinski 
> ---
> CC: ax...@kernel.dk
> CC: maarten.lankho...@linux.intel.com
> CC: mrip...@kernel.org
> CC: tzimmerm...@suse.de
> CC: airl...@linux.ie
> CC: dan...@ffwll.ch
> CC: jani.nik...@linux.intel.com
> CC: joonas.lahti...@linux.intel.com
> CC: rodrigo.v...@intel.com
> CC: yuq...@gmail.com
> CC: robdcl...@gmail.com
> CC: s...@poorly.run
> CC: christian.koe...@amd.com
> CC: ray.hu...@amd.com
> CC: sgout...@marvell.com
> CC: gak...@marvell.com
> CC: sbha...@marvell.com
> CC: hke...@marvell.com
> CC: jingooh...@gmail.com
> CC: lorenzo.pieral...@arm.com
> CC: r...@kernel.org
> CC: k...@linux.com
> CC: bhelg...@google.com
> CC: krzysztof.kozlow...@canonical.com
> CC: m...@kernel.org
> CC: paw...@cadence.com
> CC: peter.c...@kernel.org
> CC: rog...@kernel.org
> CC: a-govindr...@ti.com
> CC: gre...@linuxfoundation.org
> CC: a...@kernel.org
> CC: dan...@iogearbox.net
> CC: and...@kernel.org
> CC: ka...@fb.com
> CC: songliubrav...@fb.com
> CC: y...@fb.com
> CC: john.fastab...@gmail.com
> CC: kpsi...@kernel.org
> CC: s...@kernel.org
> CC: a...@linux-foundation.org
> CC: thomas.hellst...@linux.intel.com
> CC: matthew.a...@intel.com
> CC: colin.k...@intel.com
> CC: ge...@linux-m68k.org
> CC: linux-bl...@vger.kernel.org
> CC: dri-devel@lists.freedesktop.org
> CC: intel-...@lists.freedesktop.org
> CC: l...@lists.freedesktop.org
> CC: linux-arm-...@vger.kernel.org
> CC: freedr...@lists.freedesktop.org
> CC: linux-...@vger.kernel.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-samsung-...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: b...@vger.kernel.org
> CC: linux...@kvack.org
>
> Well, let's see if this makes it thru email servers...
> ---
>  block/fops.c  | 1 +
>  drivers/gpu/drm/drm_gem_shmem_helper.c| 1 +
>  drivers/gpu/drm/i915/gt/intel_gtt.c   | 1 +
>  drivers/gpu/drm/i915/i915_request.c   | 1 +

For the i915 parts,

Acked-by: Jani Nikula 


-- 
Jani Nikula, Intel Open Source Graphics Center

[RESEND PATCH v7 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver

2021-11-22 Thread Kevin Tang

Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.

v1:
  - Remove dphy and dsi graph binding, merge the dphy driver into the dsi.

v2:
  - Use drm_xxx to replace all DRM_XXX.
  - Use kzalloc to replace devm_kzalloc for sprd_dsi structure init.

v4:
  - Use drmm_helpers to allocate encoder.
  - Move allocate encoder and connector to bind function.

v5:
  - Drop the dsi ip file prefix.
  - Fix the checkpatch warnings.
  - Add Signed-off-by for dsi&dphy patch.
  - Use the mode_flags of mipi_dsi_device to setup crtc DPI and EDPI mode.

v6:
  - Redesign the way to access the dsi register.
  - Reduce the dsi_context member variables.

v7:
  - Fix codeing style issue by checkpatch.
  - Drop the pll registers structure define.
  - Use bridge API instead of drm panel API.
  - Register mipi_dsi_host on probe phase;
  - Remove some unused function.
---
 drivers/gpu/drm/sprd/Kconfig |1 +
 drivers/gpu/drm/sprd/Makefile|8 +-
 drivers/gpu/drm/sprd/megacores_pll.c |  305 
 drivers/gpu/drm/sprd/sprd_dpu.c  |   17 +
 drivers/gpu/drm/sprd/sprd_drm.c  |1 +
 drivers/gpu/drm/sprd/sprd_drm.h  |1 +
 drivers/gpu/drm/sprd/sprd_dsi.c  | 1075 ++
 drivers/gpu/drm/sprd/sprd_dsi.h  |  126 +++
 8 files changed, 1532 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
 create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
 create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h

diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
index 37762c333..3edeaeca0 100644
--- a/drivers/gpu/drm/sprd/Kconfig
+++ b/drivers/gpu/drm/sprd/Kconfig
@@ -5,6 +5,7 @@ config DRM_SPRD
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
help
  Choose this option if you have a Unisoc chipset.
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
index ab12b95e6..e82e6a6f8 100644
--- a/drivers/gpu/drm/sprd/Makefile
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -1,4 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-y := sprd_drm.o \
-   sprd_dpu.o
+sprd-drm-y := sprd_drm.o \
+   sprd_dpu.o \
+   sprd_dsi.o \
+   megacores_pll.o
+
+obj-$(CONFIG_DRM_SPRD) += sprd-drm.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sprd/megacores_pll.c 
b/drivers/gpu/drm/sprd/megacores_pll.c
new file mode 100644
index 0..3091dfdc1
--- /dev/null
+++ b/drivers/gpu/drm/sprd/megacores_pll.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sprd_dsi.h"
+
+#define L  0
+#define H  1
+#define CLK0
+#define DATA   1
+#define INFINITY   0x
+#define MIN_OUTPUT_FREQ(100)
+
+#define AVERAGE(a, b) (min(a, b) + abs((b) - (a)) / 2)
+
+/* sharkle */
+#define VCO_BAND_LOW   750
+#define VCO_BAND_MID   1100
+#define VCO_BAND_HIGH  1500
+#define PHY_REF_CLK26000
+
+static int dphy_calc_pll_param(struct dphy_pll *pll)
+{
+   const u32 khz = 1000;
+   const u32 mhz = 100;
+   const unsigned long long factor = 100;
+   unsigned long long tmp;
+   int i;
+
+   pll->potential_fvco = pll->freq / khz;
+   pll->ref_clk = PHY_REF_CLK / khz;
+
+   for (i = 0; i < 4; ++i) {
+   if (pll->potential_fvco >= VCO_BAND_LOW &&
+   pll->potential_fvco <= VCO_BAND_HIGH) {
+   pll->fvco = pll->potential_fvco;
+   pll->out_sel = BIT(i);
+   break;
+   }
+   pll->potential_fvco <<= 1;
+   }
+   if (pll->fvco == 0)
+   return -EINVAL;
+
+   if (pll->fvco >= VCO_BAND_LOW && pll->fvco <= VCO_BAND_MID) {
+   /* vco band control */
+   pll->vco_band = 0x0;
+   /* low pass filter control */
+   pll->lpf_sel = 1;
+   } else if (pll->fvco > VCO_BAND_MID && pll->fvco <= VCO_BAND_HIGH) {
+   pll->vco_band = 0x1;
+   pll->lpf_sel = 0;
+   } else {
+   return -EINVAL;
+   }
+
+   pll->nint = pll->fvco / pll->ref_clk;
+   tmp = pll->fvco * factor * mhz;
+   do_div(tmp, pll->ref_clk);
+   tmp = tmp - pll->nint * factor * mhz;
+   tmp *= BIT(20);
+   do_div(tmp, 1);
+   pll->kint = (u32)tmp;
+   pll->refin = 3; /* pre-divider bypass */
+   pll->sdm_en = true; /* use fraction N PLL */
+   pll->fdk_s = 0x1; /* fraction */
+   p

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gtt: stop caching the scratch page




On 28/10/2021 10:26, Matthew Auld wrote:

Normal users shouldn't be hitting this, likely this would indicate a
userspace bug. So don't bother caching, which should be safe now that we
manually flush the page.


Could this have a performance impact if "things" overfetch often enough 
in normal operation?


Regards,

Tvrtko


Suggested-by: Chris Wilson 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Chris Wilson 
Cc: Ramalingam C 
Reviewed-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 8af2f709571c..9966e9dc5218 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -651,7 +651,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
  
  	vm->scratch[0]->encode =

gen8_pte_encode(px_dma(vm->scratch[0]),
-   I915_CACHE_LLC, pte_flags);
+   I915_CACHE_NONE, pte_flags);
  
  	for (i = 1; i <= vm->top; i++) {

struct drm_i915_gem_object *obj;
@@ -667,7 +667,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
}
  
  		fill_px(obj, vm->scratch[i - 1]->encode);

-   obj->encode = gen8_pde_encode(px_dma(obj), I915_CACHE_LLC);
+   obj->encode = gen8_pde_encode(px_dma(obj), I915_CACHE_NONE);
  
  		vm->scratch[i] = obj;

}

Re: [PATCH v2 1/2] drm/input_helper: Add new input-handling helper

On Fri, 19 Nov 2021 17:11:07 +0100
Daniel Vetter  wrote:

> On Fri, Nov 19, 2021 at 04:04:28PM +, Simon Ser wrote:
> > On Friday, November 19th, 2021 at 16:53, Daniel Vetter  
> > wrote:
> >   
> > > Random idea ... should we perhaps let userspace connect the boosting? I.e.
> > > we do a bunch of standardized boost targets (render clocks, display sr
> > > exit), and userspace can then connect it to whichever input device it
> > > wants to?  
> > 
> > On IRC we discussed having user-space hand over a FD to the kernel. When 
> > the FD
> > becomes readable, the kernel triggers the boost.
> > 
> > This would let user-space use e.g. an input device, an eventfd, or an epoll 
> > FD
> > with any combination of these as the boost signal.  
> 
> Can userspace filter eventfd appropriately like we do here? And can they
> get at that maybe 2nd eventfd from logind or whatever there is on distros
> where /dev access is locked down for compositors/users.

(Mind, eventfd is a specific thing, see 'man eventfd', and evdev/input
device fd is different.)

I don't think any of that is any problem when userspace prepares an
epoll fd to be given to the boosting machinery. The boosting machinery
could have several different targets as well, PSR vs. GPU clocks and
whatnot.

I envision a compositor to maintain an epoll fd for boosting by
adding/removing the same device fds to it that it already uses in its
operations. I don't see any need to open new device fds just for
boosting. It's only the epoll fd given to the kernel and after that the
epoll set can still be changed, right?

The boosting machinery would never actually read or write the
registered fd(s), so it would not interfere with the normal operations.
But it also means the fd will remain readable until userspace services
it. Userspace may need to set up that epoll set very carefully to have
it work right (e.g. edge-triggered?).

If your input handling is in a different process than the DRM poking
for some reason, the epoll fd should still work if:
- it is possible to use SCM_RIGHTS to pass the epollfd from the
  input process to the DRM process, and
- you cannot extract the watched fds from an epoll fd.

Do we have those assumptions today?

Then the attack surface in the DRM process is limited to changing the
epoll set of which fds can trigger boosting, but the DRM process can do
that anyway. I also presume the input process can still add and remove
fds from the epoll set even afterwards.

> I do agree that if we can do this generically maybe we should, but also
> the use-case for input boosting is pretty well defined. I think it's just
> about making sure that compositors is in control, and that we don't make
> it worse (e.g. with the sr exit adding latency when the compositor can
> redraw quickly enough).

The epollfd design sounds very good to me. One can register an
arbitrary set of fds with it, and use even eventfds in the set to have
purely software triggers.

Thanks,
pq

pgpSIe2w2RHU0.pgp
Description: OpenPGP digital signature

Re: [PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

On Wed, 17 Nov 2021 23:58:28 +0900
Hector Martin  wrote:

> Add XRGB emulation support for devices that can only do XRGB2101010.
> 
> This is chiefly useful for simpledrm on Apple devices where the
> bootloader-provided framebuffer is 10-bit, which already works fine with
> simplefb. This is required to make simpledrm support this too.
> 
> Signed-off-by: Hector Martin 
> ---
>  drivers/gpu/drm/drm_format_helper.c | 64 +
>  include/drm/drm_format_helper.h |  4 ++
>  2 files changed, 68 insertions(+)

Hi Hector,

I'm curious, since the bootloader seems to always set up a 10-bit mode,
is there a reason for it that you can guess? Is the monitor in WCG or
even HDR mode?


Thanks,
pq


pgpfiAYNbZYeh.pgp
Description: OpenPGP digital signature

Re: [PATCH 03/15] iio: buffer-dma: Use round_down() instead of rounddown()

2021-11-22 Thread Paul Cercueil


Hi Jonathan,

Le dim., nov. 21 2021 at 14:08:23 +, Jonathan Cameron 
 a écrit :

On Mon, 15 Nov 2021 14:19:13 +
Paul Cercueil  wrote:


 We know that the buffer's alignment will always be a power of two;
 therefore, we can use the faster round_down() macro.

 Signed-off-by: Paul Cercueil 
*groan*.  I don't want to know where the naming of these two came 
from but that

is spectacular...

Anyhow, happy to pick up 1-3 now if you like as all are good cleanup 
of

existing code.


I think you can pick 2-3 now; I will do some changes to patch [01/15] 
in the V2.


Cheers,
-Paul

Re: [PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

2021-11-22 Thread Hector Martin


On 22/11/2021 18.52, Pekka Paalanen wrote:

On Wed, 17 Nov 2021 23:58:28 +0900
Hector Martin  wrote:


Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.

Signed-off-by: Hector Martin 
---
  drivers/gpu/drm/drm_format_helper.c | 64 +
  include/drm/drm_format_helper.h |  4 ++
  2 files changed, 68 insertions(+)


Hi Hector,

I'm curious, since the bootloader seems to always set up a 10-bit mode,
is there a reason for it that you can guess? Is the monitor in WCG or
even HDR mode?


My guess is that Apple prefer to use 10-bit framebuffers for seamless 
handover with their graphics stack, which presumably uses 10-bit 
framebuffers these days. It seems to be unconditional; I've never seen 
anything but 10 bits across all Apple devices, both with the internal 
panels on laptops and with bog standard external displays on the Mac 
Mini via HDMI. HDR is not necessary, even very dumb capture cards and 
old screens get a 10-bit framebufer in memory.


The only time I see an 8-bit framebuffer is with *no* monitor connected 
on the Mini, in which case you get an 8-bit 640x1136 dummy framebuffer 
(that's the iPhone 5 screen resolution... :-) )


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
> 
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge functionalities in order to DSI
> Host to Interface bridge.

In order to do this you would need to use the DRM bridge API...

> This patch convert the existing to a drm bridge driver with a
> built-in encoder support for compatibility with existing
> component drivers.

... but changing the encoder driver to a bridge is completely
unnecessary to do so. Why did you need to make that change?

> Signed-off-by: Jagan Teki 
>
> ---
> Changes for v5:
> - add atomic APIs
> - find host and device variant DSI devices.
> Changes for v4, v3:
> - none
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
>  2 files changed, 96 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 43d9c9e5198d..a6a272b55f77 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
>   return 0;
>  }
>  
> -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> +struct drm_bridge_state 
> *old_bridge_state)
>  {
> - struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> + struct drm_display_mode *mode = 
> &bridge->encoder->crtc->state->adjusted_mode;
>   struct mipi_dsi_device *device = dsi->device;
>   union phy_configure_opts opts = { };
>   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_prepare(dsi->panel);
>  
> + if (dsi->next_bridge)
> + dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> old_bridge_state);
> +

Please use the proper helpers.

>   /*
>* FIXME: This should be moved after the switch to HS mode.
>*
> @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_enable(dsi->panel);
>  
> + if (dsi->next_bridge)
> + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> old_bridge_state);
> +

Ditto

>   sun6i_dsi_start(dsi, DSI_START_HSC);
>  
>   udelay(1000);
> @@ -794,15 +802,19 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   sun6i_dsi_start(dsi, DSI_START_HSD);
>  }
>  
> -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state 
> *old_bridge_state)
>  {
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
>  
>   DRM_DEBUG_DRIVER("Disabling DSI output\n");
>  
>   if (dsi->panel) {
>   drm_panel_disable(dsi->panel);
>   drm_panel_unprepare(dsi->panel);
> + } else if (dsi->next_bridge) {
> + dsi->next_bridge->funcs->atomic_disable(dsi->next_bridge, 
> old_bridge_state);
> + dsi->next_bridge->funcs->atomic_post_disable(dsi->next_bridge, 
> old_bridge_state);

Ditto

>   }
>  
>   phy_power_off(dsi->dphy);
> @@ -842,9 +854,25 @@ static const struct drm_connector_funcs 
> sun6i_dsi_connector_funcs = {
>   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>  };
>  
> -static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
> - .disable= sun6i_dsi_encoder_disable,
> - .enable = sun6i_dsi_encoder_enable,
> +static int sun6i_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> +
> + if (dsi->next_bridge)
> + return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +  NULL, 0);
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs sun6i_dsi_bridge_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state   = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset   = drm_atomic_helper_bridge_reset,
> +

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> Get the display mode settings via mode_set bridge function
> instead of explicitly de-reference.

What's wrong with dereferencing the mode?

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] i2c: tegra: Add ACPI support

2021-11-22 Thread Dmitry Osipenko

19.11.2021 17:48, Andy Shevchenko пишет:
>> +   if (i2c_dev->nclocks == 0)
>> +   return;
> Why? Make clocks optional.

This check shouldn't be needed because both clk_disable() and
clk_bulk_unprepare() should handle NULL/zero clocks without problems.

Re: [PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

On Mon, 22 Nov 2021 19:05:16 +0900
Hector Martin  wrote:

> On 22/11/2021 18.52, Pekka Paalanen wrote:
> > On Wed, 17 Nov 2021 23:58:28 +0900
> > Hector Martin  wrote:
> >   
> >> Add XRGB emulation support for devices that can only do XRGB2101010.
> >>
> >> This is chiefly useful for simpledrm on Apple devices where the
> >> bootloader-provided framebuffer is 10-bit, which already works fine with
> >> simplefb. This is required to make simpledrm support this too.
> >>
> >> Signed-off-by: Hector Martin 
> >> ---
> >>   drivers/gpu/drm/drm_format_helper.c | 64 +
> >>   include/drm/drm_format_helper.h |  4 ++
> >>   2 files changed, 68 insertions(+)  
> > 
> > Hi Hector,
> > 
> > I'm curious, since the bootloader seems to always set up a 10-bit mode,
> > is there a reason for it that you can guess? Is the monitor in WCG or
> > even HDR mode?  
> 
> My guess is that Apple prefer to use 10-bit framebuffers for seamless 
> handover with their graphics stack, which presumably uses 10-bit 
> framebuffers these days. It seems to be unconditional; I've never seen 
> anything but 10 bits across all Apple devices, both with the internal 
> panels on laptops and with bog standard external displays on the Mac 
> Mini via HDMI. HDR is not necessary, even very dumb capture cards and 
> old screens get a 10-bit framebufer in memory.

That makes perfect sense, thanks!

Switching between sRGB and WCG or HDR mode is not a modeset, it's just
HDMI/DP/whatever metadata/infoframe.

> The only time I see an 8-bit framebuffer is with *no* monitor connected 
> on the Mini, in which case you get an 8-bit 640x1136 dummy framebuffer 
> (that's the iPhone 5 screen resolution... :-) )
> 

Thanks,
pq


pgpOvhSaDNnIx.pgp
Description: OpenPGP digital signature

Re: [PATCH] i2c: tegra: Add ACPI support

2021-11-22 Thread Dmitry Osipenko

19.11.2021 16:32, Akhil R пишет:
> - i2c_dev->rst = devm_reset_control_get_exclusive(i2c_dev->dev, "i2c");
> - if (IS_ERR(i2c_dev->rst)) {
> - dev_err_probe(i2c_dev->dev, PTR_ERR(i2c_dev->rst),
> -   "failed to get reset control\n");
> - return PTR_ERR(i2c_dev->rst);
> - }
> -
>   tegra_i2c_parse_dt(i2c_dev);
>  
> - err = tegra_i2c_init_clocks(i2c_dev);
> - if (err)
> - return err;
> + if (!has_acpi_companion(&pdev->dev)) {
> + i2c_dev->rst = devm_reset_control_get_exclusive(i2c_dev->dev, 
> "i2c");
> + if (IS_ERR(i2c_dev->rst)) {
> + dev_err_probe(i2c_dev->dev, PTR_ERR(i2c_dev->rst),
> +   "failed to get reset control\n");
> + return PTR_ERR(i2c_dev->rst);
> + }
> +
> + err = tegra_i2c_init_clocks(i2c_dev);
> + if (err)
> + return err;
> + }

What about to factor out the reset initialization into a separate function and 
write it like this:

static int tegra_i2c_init_reset(i2c_dev)
{
if (has_acpi_companion(i2c_dev->dev)
return 0;

i2c_dev->rst = devm_reset_control_get_exclusive(i2c_dev->dev, "i2c");
if (IS_ERR(i2c_dev->rst))
return dev_err_probe(i2c_dev->dev, PTR_ERR(i2c_dev->rst),
 "failed to get reset control\n");

return 0;
}

And then change tegra_i2c_init_clocks() to:

static int tegra_i2c_init_clocks(i2c_dev)
{
int err;

if (has_acpi_companion(i2c_dev->dev))
return 0;

...
}

This will make both reset/clocks initialization to look more consistent.

[PATCH] drm/ast: Create the driver for ASPEED proprietory Display-Port

2021-11-22 Thread KuoHsiang Chou

1. The MCU FW controling ASPEED DP is loaded by BMC boot loader.
2. Driver starts after CR[3:1] == 111b that indicates Tx is ASTDP,
   and CRD1[5] has been asserted by BMVC boot loader.
3. EDID is prioritized by DP monitor.
4. DP's EDID has high priority to decide resolution supporting.

Signed-off-by: KuoHsiang Chou 
---
 drivers/gpu/drm/ast/Makefile   |   2 +-
 drivers/gpu/drm/ast/ast_dp.c   | 286 +
 drivers/gpu/drm/ast/ast_drv.h  |  13 ++
 drivers/gpu/drm/ast/ast_main.c |   7 +-
 drivers/gpu/drm/ast/ast_mode.c |  50 +-
 drivers/gpu/drm/ast/ast_post.c |   4 +-
 6 files changed, 353 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/ast/ast_dp.c

diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
index 438a2d05b..9bd0756e0 100644
--- a/drivers/gpu/drm/ast/Makefile
+++ b/drivers/gpu/drm/ast/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ast-y := ast_drv.o ast_main.o ast_mm.o ast_mode.o ast_post.o ast_dp501.o
+ast-y := ast_drv.o ast_main.o ast_mm.o ast_mode.o ast_post.o ast_dp501.o 
ast_dp.o
 
 obj-$(CONFIG_DRM_AST) := ast.o
diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
new file mode 100644
index 0..537eaf4fa
--- /dev/null
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -0,0 +1,286 @@
+/*
+ * Copyright 2012 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ */
+/*
+ * Authors: KuoHsiang Chou 
+ */
+
+#include 
+#include 
+#include 
+#include "ast_drv.h"
+
+bool ast_dp_read_edid(struct drm_device *dev, u8 *ediddata)
+{
+   struct ast_private *ast = to_ast_private(dev);
+   u8 i = 0, j = 0;
+
+#ifdef DPControlPower
+   u8 bDPState_Change = false;
+
+   // Check DP power off or not.
+   if (ast->ASTDP_State & 0x10) {
+   // DP power on
+   ast_dp_PowerOnOff(dev, 1);
+   bDPState_Change = true;
+   }
+#endif
+
+   /*
+* CRD1[b5]: DP MCU FW is executing
+* CRDC[b0]: DP link success
+* CRDF[b0]: DP HPD
+* CRE5[b0]: Host reading EDID process is done
+*/
+   if (!(ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1, 0x20) &&
+   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDC, 0x01) &&
+   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDF, 0x01) &&
+   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5, 0x01))) {
+#ifdef DPControlPower
+   // Set back power off
+   if (bDPState_Change)
+   ast_dp_PowerOnOff(dev, 0);
+#endif
+   return false;
+   }
+
+   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5, 0x00, 0x00);
+
+   for (i = 0; i < 32; i++) {
+   /*
+* CRE4[7:0]: Read-Pointer for EDID (Unit: 4bytes); valid 
range: 0~64
+*/
+   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE4, 0x00, (u8) 
i);
+   j = 0;
+
+   /*
+* CRD7[b0]: valid flag for EDID
+* CRD6[b0]: mirror read pointer for EDID
+*/
+   while ((ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD7, 
0x01) != 0x01) ||
+   (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD6, 
0xFF) != i)) {
+   mdelay(j+1);
+
+   if (!(ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xD1, 0x20) &&
+   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xDC, 0x01) &&
+   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xDF, 0x01))) {
+   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xE5, 0x00, 0x01);
+   return false;
+

[RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support

2021-11-22 Thread Shunsuke Mie

This patch series add a dma-buf support for rxe driver.

A dma-buf based memory registering has beed introduced to use the memory
region that lack of associated page structures (e.g. device memory and CMA
managed memory) [1]. However, to use the dma-buf based memory, each rdma
device drivers require add some implementation. The rxe driver has not
support yet.

[1] https://www.spinics.net/lists/linux-rdma/msg98592.html

To enable to use the dma-buf memory in rxe rdma device, add some changes
and implementation in this patch series.

This series consists of two patches. The first patch changes the IB core
to support for rdma drivers that has not dma device. The secound patch adds
the dma-buf support to rxe driver.

Related user space RDMA library changes are provided as a separate patch.

v4:
* Fix warnings, unused variable and casting
v3: https://www.spinics.net/lists/linux-rdma/msg106776.html
* Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc6+)
* Fix to use dma-buf-map helpers
v2: https://www.spinics.net/lists/linux-rdma/msg105928.html
* Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc1+)
* Instead of using a dummy dma_device to attach dma-buf, just store
  dma-buf to use software RDMA driver
* Use dma-buf vmap() interface
* Check to pass tests of rdma-core
v1: https://www.spinics.net/lists/linux-rdma/msg105376.html
* The initial patch set
* Use ib_device as dma_device.
* Use dma-buf dynamic attach interface
* Add dma-buf support to rxe device

Shunsuke Mie (2):
  RDMA/umem: Change for rdma devices has not dma device
  RDMA/rxe: Add dma-buf support

 drivers/infiniband/core/umem_dmabuf.c |  20 -
 drivers/infiniband/sw/rxe/rxe_loc.h   |   2 +
 drivers/infiniband/sw/rxe/rxe_mr.c| 113 ++
 drivers/infiniband/sw/rxe/rxe_verbs.c |  34 
 include/rdma/ib_umem.h|   1 +
 5 files changed, 166 insertions(+), 4 deletions(-)

-- 
2.17.1

[RFC PATCH v4 1/2] RDMA/umem: Change for rdma devices has not dma device

2021-11-22 Thread Shunsuke Mie

Current implementation requires a dma device for RDMA driver to use
dma-buf memory space as RDMA buffer. However, software RDMA drivers has
not dma device and copy RDMA data using CPU instead of hardware.

This patch changes to be hold a dma-buf on struct ib_umem_dmabuf. This
allows the software RDMA driver to map dma-buf memory for CPU memory
accessing.

Signed-off-by: Shunsuke Mie 
---
 drivers/infiniband/core/umem_dmabuf.c | 20 
 include/rdma/ib_umem.h|  1 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/core/umem_dmabuf.c 
b/drivers/infiniband/core/umem_dmabuf.c
index e824baf4640d..ebbb0a259fd4 100644
--- a/drivers/infiniband/core/umem_dmabuf.c
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -117,9 +117,6 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device 
*device,
if (check_add_overflow(offset, (unsigned long)size, &end))
return ret;
 
-   if (unlikely(!ops || !ops->move_notify))
-   return ret;
-
dmabuf = dma_buf_get(fd);
if (IS_ERR(dmabuf))
return ERR_CAST(dmabuf);
@@ -133,6 +130,8 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device 
*device,
goto out_release_dmabuf;
}
 
+   umem_dmabuf->dmabuf = dmabuf;
+
umem = &umem_dmabuf->umem;
umem->ibdev = device;
umem->length = size;
@@ -143,6 +142,13 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device 
*device,
if (!ib_umem_num_pages(umem))
goto out_free_umem;
 
+   /* Software RDMA drivers has not dma device. Just get dmabuf from fd */
+   if (!device->dma_device)
+   goto done;
+
+   if (unlikely(!ops || !ops->move_notify))
+   goto out_free_umem;
+
umem_dmabuf->attach = dma_buf_dynamic_attach(
dmabuf,
device->dma_device,
@@ -152,6 +158,7 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device 
*device,
ret = ERR_CAST(umem_dmabuf->attach);
goto out_free_umem;
}
+done:
return umem_dmabuf;
 
 out_free_umem:
@@ -165,13 +172,18 @@ EXPORT_SYMBOL(ib_umem_dmabuf_get);
 
 void ib_umem_dmabuf_release(struct ib_umem_dmabuf *umem_dmabuf)
 {
-   struct dma_buf *dmabuf = umem_dmabuf->attach->dmabuf;
+   struct dma_buf *dmabuf = umem_dmabuf->dmabuf;
+
+   if (!umem_dmabuf->attach)
+   goto free_dmabuf;
 
dma_resv_lock(dmabuf->resv, NULL);
ib_umem_dmabuf_unmap_pages(umem_dmabuf);
dma_resv_unlock(dmabuf->resv);
 
dma_buf_detach(dmabuf, umem_dmabuf->attach);
+
+free_dmabuf:
dma_buf_put(dmabuf);
kfree(umem_dmabuf);
 }
diff --git a/include/rdma/ib_umem.h b/include/rdma/ib_umem.h
index 5ae9dff74dac..11c0cf7e0dd8 100644
--- a/include/rdma/ib_umem.h
+++ b/include/rdma/ib_umem.h
@@ -32,6 +32,7 @@ struct ib_umem {
 struct ib_umem_dmabuf {
struct ib_umem umem;
struct dma_buf_attachment *attach;
+   struct dma_buf *dmabuf;
struct sg_table *sgt;
struct scatterlist *first_sg;
struct scatterlist *last_sg;
-- 
2.17.1

[RFC PATCH v4 2/2] RDMA/rxe: Add dma-buf support

2021-11-22 Thread Shunsuke Mie

Implement a ib device operation ‘reg_user_mr_dmabuf’. Generate a
rxe_map from the memory space linked the passed dma-buf.

Signed-off-by: Shunsuke Mie 
---
 drivers/infiniband/sw/rxe/rxe_loc.h   |   2 +
 drivers/infiniband/sw/rxe/rxe_mr.c| 113 ++
 drivers/infiniband/sw/rxe/rxe_verbs.c |  34 
 3 files changed, 149 insertions(+)

diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h 
b/drivers/infiniband/sw/rxe/rxe_loc.h
index 1ca43b859d80..8bc19ea1a376 100644
--- a/drivers/infiniband/sw/rxe/rxe_loc.h
+++ b/drivers/infiniband/sw/rxe/rxe_loc.h
@@ -75,6 +75,8 @@ u8 rxe_get_next_key(u32 last_key);
 void rxe_mr_init_dma(struct rxe_pd *pd, int access, struct rxe_mr *mr);
 int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 length, u64 iova,
 int access, struct rxe_mr *mr);
+int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64 length,
+   u64 iova, int access, struct rxe_mr *mr);
 int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr *mr);
 int rxe_mr_copy(struct rxe_mr *mr, u64 iova, void *addr, int length,
enum rxe_mr_copy_dir dir);
diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c 
b/drivers/infiniband/sw/rxe/rxe_mr.c
index 53271df10e47..b954e5647f82 100644
--- a/drivers/infiniband/sw/rxe/rxe_mr.c
+++ b/drivers/infiniband/sw/rxe/rxe_mr.c
@@ -4,6 +4,8 @@
  * Copyright (c) 2015 System Fabric Works, Inc. All rights reserved.
  */
 
+#include 
+#include 
 #include "rxe.h"
 #include "rxe_loc.h"
 
@@ -245,6 +247,114 @@ int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 
length, u64 iova,
return err;
 }
 
+static int rxe_map_dmabuf_mr(struct rxe_mr *mr,
+struct ib_umem_dmabuf *umem_dmabuf)
+{
+   struct rxe_map_set *set;
+   struct rxe_phys_buf *buf = NULL;
+   struct rxe_map **map;
+   void *vaddr;
+   int num_buf = 0;
+   int err;
+   size_t remain;
+   struct dma_buf_map dmabuf_map;
+
+   err = dma_buf_vmap(umem_dmabuf->dmabuf, &dmabuf_map);
+   if (err || dmabuf_map.is_iomem)
+   goto err_out;
+
+   set = mr->cur_map_set;
+   set->page_shift = PAGE_SHIFT;
+   set->page_mask = PAGE_SIZE - 1;
+
+   map = set->map;
+   buf = map[0]->buf;
+
+   vaddr = dmabuf_map.vaddr;
+   remain = umem_dmabuf->dmabuf->size;
+
+   for (; remain; vaddr += PAGE_SIZE) {
+   if (num_buf >= RXE_BUF_PER_MAP) {
+   map++;
+   buf = map[0]->buf;
+   num_buf = 0;
+   }
+
+   buf->addr = (uintptr_t)vaddr;
+   if (remain >= PAGE_SIZE)
+   buf->size = PAGE_SIZE;
+   else
+   buf->size = remain;
+   remain -= buf->size;
+
+   num_buf++;
+   buf++;
+   }
+
+   return 0;
+
+err_out:
+   return err;
+}
+
+static void rxe_unmap_dmabuf_mr(struct rxe_mr *mr)
+{
+   struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(mr->umem);
+   struct rxe_map *map = mr->cur_map_set->map[0];
+   struct dma_buf_map dma_buf_map =
+   DMA_BUF_MAP_INIT_VADDR((void *)(uintptr_t)map->buf->addr);
+
+   dma_buf_vunmap(umem_dmabuf->dmabuf, &dma_buf_map);
+}
+
+int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64 length,
+   u64 iova, int access, struct rxe_mr *mr)
+{
+   struct ib_umem_dmabuf *umem_dmabuf;
+   struct rxe_map_set *set;
+   int err;
+
+   umem_dmabuf = ib_umem_dmabuf_get(pd->ibpd.device, start, length, fd,
+access, NULL);
+   if (IS_ERR(umem_dmabuf)) {
+   err = PTR_ERR(umem_dmabuf);
+   goto err_out;
+   }
+
+   rxe_mr_init(access, mr);
+
+   err = rxe_mr_alloc(mr, ib_umem_num_pages(&umem_dmabuf->umem), 0);
+   if (err) {
+   pr_warn("%s: Unable to allocate memory for map\n", __func__);
+   goto err_release_umem;
+   }
+
+   mr->ibmr.pd = &pd->ibpd;
+   mr->umem = &umem_dmabuf->umem;
+   mr->access = access;
+   mr->state = RXE_MR_STATE_VALID;
+   mr->type = IB_MR_TYPE_USER;
+
+   set = mr->cur_map_set;
+   set->length = length;
+   set->iova = iova;
+   set->va = start;
+   set->offset = ib_umem_offset(mr->umem);
+
+   err = rxe_map_dmabuf_mr(mr, umem_dmabuf);
+   if (err)
+   goto err_free_map_set;
+
+   return 0;
+
+err_free_map_set:
+   rxe_mr_free_map_set(mr->num_map, mr->cur_map_set);
+err_release_umem:
+   ib_umem_release(&umem_dmabuf->umem);
+err_out:
+   return err;
+}
+
 int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr *mr)
 {
int err;
@@ -703,6 +813,9 @@ void rxe_mr_cleanup(struct rxe_pool_entry *arg)
 {
struct rxe_mr *mr = container_of(arg, typeof(*mr), pelem);
 
+   if (mr->umem && mr->umem

[PATCH v4 1/4] arm64: dts: qcom: sc7280: add display dt nodes

From: Krishna Manikandan 

Add mdss and mdp DT nodes for sc7280.

Signed-off-by: Krishna Manikandan 
Reported-by: kernel test robot 
Reviewed-by: Stephen Boyd 
Reported-by: kernel test robot 
Signed-off-by: Sankeerth Billakanti 
---

Changes in v4:
None

Changes in v3:
None

Changes in v2:
- Rename display dt nodes (Stephen Boyd)
- Add clock names one per line for readability (Stephen Boyd)


 arch/arm64/boot/dts/qcom/sc7280.dtsi | 90 
 1 file changed, 90 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 365a2e0..a4536b6 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2704,6 +2704,96 @@
#power-domain-cells = <1>;
};
 
+   mdss: display-subsystem@ae0 {
+   compatible = "qcom,sc7280-mdss";
+   reg = <0 0x0ae0 0 0x1000>;
+   reg-names = "mdss";
+
+   power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
+
+   clocks = <&gcc GCC_DISP_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+   <&dispcc DISP_CC_MDSS_MDP_CLK>;
+   clock-names = "iface",
+ "ahb",
+ "core";
+
+   assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
+   assigned-clock-rates = <3>;
+
+   interrupts = ;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt 
SLAVE_EBI1 0>;
+   interconnect-names = "mdp0-mem";
+
+   iommus = <&apps_smmu 0x900 0x402>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   status = "disabled";
+
+   mdp: display-controller@ae01000 {
+   compatible = "qcom,sc7280-dpu";
+   reg = <0 0x0ae01000 0 0x8f030>,
+   <0 0x0aeb 0 0x2008>;
+   reg-names = "mdp", "vbif";
+
+   clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+   <&gcc GCC_DISP_SF_AXI_CLK>,
+   <&dispcc DISP_CC_MDSS_AHB_CLK>,
+   <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+   <&dispcc DISP_CC_MDSS_MDP_CLK>,
+   <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+   clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_MDP_CLK>,
+   <&dispcc 
DISP_CC_MDSS_VSYNC_CLK>,
+   <&dispcc DISP_CC_MDSS_AHB_CLK>;
+   assigned-clock-rates = <3>,
+   <1920>,
+   <1920>;
+   operating-points-v2 = <&mdp_opp_table>;
+   power-domains = <&rpmhpd SC7280_CX>;
+
+   interrupt-parent = <&mdss>;
+   interrupts = <0>;
+
+   status = "disabled";
+
+   mdp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-38000 {
+   opp-hz = /bits/ 64 <38000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-50667 {
+   opp-hz = /bits/ 64 <50667>;
+

[PATCH v4 2/4] arm64: dts: qcom: sc7280: Add DSI display nodes

From: Krishna Manikandan 

Add DSI controller and PHY nodes for sc7280.

Signed-off-by: Rajeev Nandan 
Signed-off-by: Krishna Manikandan 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Stephen Boyd 
Signed-off-by: Sankeerth Billakanti 
---

Changes in v4:
None

Changes in v3:
- Add the dsi_phy clocks (Kuogee Hsieh)
- One clock cell per line (Stephen Boyd)

Changes in v2:
- Drop flags from interrupts (Stephen Boyd)
- Rename dsi-opp-table (Stephen Boyd)
- Rename dsi phy  node (Stephen Boyd)


 arch/arm64/boot/dts/qcom/sc7280.dtsi | 111 ++-
 1 file changed, 109 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index a4536b6..12c4d32 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2691,8 +2691,14 @@
reg = <0 0xaf0 0 0x2>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
 <&gcc GCC_DISP_GPLL0_CLK_SRC>,
-<0>, <0>, <0>, <0>, <0>, <0>;
-   clock-names = "bi_tcxo", "gcc_disp_gpll0_clk",
+<&dsi_phy 0>,
+<&dsi_phy 1>,
+<0>,
+<0>,
+<0>,
+<0>;
+   clock-names = "bi_tcxo",
+ "gcc_disp_gpll0_clk",
  "dsi0_phy_pll_out_byteclk",
  "dsi0_phy_pll_out_dsiclk",
  "dp_phy_pll_link_clk",
@@ -2768,6 +2774,18 @@
 
status = "disabled";
 
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dpu_intf1_out: endpoint {
+   remote-endpoint = 
<&dsi0_in>;
+   };
+   };
+   };
+
mdp_opp_table: opp-table {
compatible = "operating-points-v2";
 
@@ -2792,6 +2810,95 @@
};
};
};
+
+   dsi0: dsi@ae94000 {
+   compatible = "qcom,mdss-dsi-ctrl";
+   reg = <0 0x0ae94000 0 0x400>;
+   reg-names = "dsi_ctrl";
+
+   interrupt-parent = <&mdss>;
+   interrupts = <4>;
+
+   clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+<&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+<&dispcc DISP_CC_MDSS_ESC0_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&gcc GCC_DISP_HF_AXI_CLK>;
+   clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+   operating-points-v2 = <&dsi_opp_table>;
+   power-domains = <&rpmhpd SC7280_CX>;
+
+   phys = <&dsi_phy>;
+   phy-names = "dsi";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_in: endpoint {
+   remote-endpoint = 
<&dpu_intf1_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi0_out: endpoint {
+   };
+   };
+

[PATCH v4 3/4] arm64: dts: qcom: sc7280: add edp display dt nodes

Add edp controller and phy DT nodes for sc7280.

Signed-off-by: Krishna Manikandan 
Reviewed-by: Stephen Boyd 
Signed-off-by: Sankeerth Billakanti 
---

Changes in v4:
None

Changes in v3:
- Add one clock cell per line (Stephen Boyd)
- Unit address should match first reg property (Stephen Boyd)
- Remove new line (Stephen Boyd)
- Add the dsi_phy clocks in dispcc (Kuogee Hsieh)

Changes in v2:
- Move regulator definitions to board file (Matthias Kaehlcke)
- Move the gpio definitions to board file (Matthias Kaehlcke)
- Move the pinconf to board file (Matthias Kaehlcke)
- Move status property (Stephen Boyd)
- Drop flags from interrupts (Stephen Boyd)
- Add clock names one per line for readability (Stephen Boyd)
- Rename edp-opp-table (Stephen Boyd)

 arch/arm64/boot/dts/qcom/sc7280.dtsi | 107 ++-
 1 file changed, 105 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 12c4d32..5ad500e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2695,8 +2695,8 @@
 <&dsi_phy 1>,
 <0>,
 <0>,
-<0>,
-<0>;
+<&edp_phy 0>,
+<&edp_phy 1>;
clock-names = "bi_tcxo",
  "gcc_disp_gpll0_clk",
  "dsi0_phy_pll_out_byteclk",
@@ -2784,6 +2784,13 @@
remote-endpoint = 
<&dsi0_in>;
};
};
+
+   port@1 {
+   reg = <1>;
+   dpu_intf5_out: endpoint {
+   remote-endpoint = 
<&edp_in>;
+   };
+   };
};
 
mdp_opp_table: opp-table {
@@ -2899,6 +2906,102 @@
 
status = "disabled";
};
+
+   msm_edp: edp@aea {
+   compatible = "qcom,sc7280-edp";
+
+   reg = <0 0xaea 0 0x200>,
+ <0 0xaea0200 0 0x200>,
+ <0 0xaea0400 0 0xc00>,
+ <0 0xaea1000 0 0x400>;
+
+   interrupt-parent = <&mdss>;
+   interrupts = <14>;
+
+   clocks = <&rpmhcc RPMH_CXO_CLK>,
+<&gcc GCC_EDP_CLKREF_EN>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_EDP_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_EDP_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_EDP_LINK_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_EDP_PIXEL_CLK>;
+   clock-names = "core_xo",
+ "core_ref",
+ "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+   #clock-cells = <1>;
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_EDP_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_EDP_PIXEL_CLK_SRC>;
+   assigned-clock-parents = <&edp_phy 0>, 
<&edp_phy 1>;
+
+   phys = <&edp_phy>;
+   phy-names = "dp";
+
+   operating-points-v2 = <&edp_opp_table>;
+   power-domains = <&rpmhpd SC7280_CX>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   edp_in: endpoint {
+   remote-endpoint = 
<&dpu_intf5_out>;
+

[PATCH v4 4/4] arm64: dts: qcom: sc7280: Add Display Port node

From: Kuogee Hsieh 

Signed-off-by: Kuogee Hsieh 
Reviewed-by: Stephen Boyd 
Signed-off-by: Sankeerth Billakanti 
---

Changes in v4:
- Add the patch to display DT change series (Bjorn Andersson)
- Remove the trailing whitespaces

 arch/arm64/boot/dts/qcom/sc7280.dtsi | 90 +++-
 1 file changed, 88 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 5ad500e..0b2ffd5 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2693,8 +2693,8 @@
 <&gcc GCC_DISP_GPLL0_CLK_SRC>,
 <&dsi_phy 0>,
 <&dsi_phy 1>,
-<0>,
-<0>,
+<&dp_phy 0>,
+<&dp_phy 1>,
 <&edp_phy 0>,
 <&edp_phy 1>;
clock-names = "bi_tcxo",
@@ -2791,6 +2791,13 @@
remote-endpoint = 
<&edp_in>;
};
};
+
+   port@2 {
+reg = <2>;
+dpu_intf0_out: endpoint {
+remote-endpoint = 
<&dp_in>;
+};
+};
};
 
mdp_opp_table: opp-table {
@@ -3002,6 +3009,79 @@
 
status = "disabled";
};
+
+   msm_dp: displayport-controller@ae9 {
+   compatible = "qcom,sc7280-dp";
+
+   reg = <0 0x0ae9 0 0x1400>;
+
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+   clock-names =   "core_iface",
+   "core_aux",
+   "ctrl_link",
+   "ctrl_link_iface",
+   "stream_pixel";
+   #clock-cells = <1>;
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+   assigned-clock-parents = <&dp_phy 0>, <&dp_phy 
1>;
+   phys = <&dp_phy>;
+   phy-names = "dp";
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SC7280_CX>;
+
+   #sound-dai-cells = <0>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   dp_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dp_out: endpoint { };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+

[PATCH v1 1/4] ARM: dts: imx6dl-prtvt7: Add display and panel nodes

Add Innolux G070Y2-T02 panel to the Protonic VT7 board.

Signed-off-by: Robin van der Gracht 
Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/imx6dl-prtvt7.dts | 47 +
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts 
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index 190d26642bc8..be7c4cb339e7 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -28,6 +28,30 @@ backlight_lcd: backlight-lcd {
power-supply = <®_bl_12v0>;
};
 
+   display {
+   compatible = "fsl,imx-parallel-display";
+   pinctrl-0 = <&pinctrl_ipu1_disp>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   display_in: endpoint {
+   remote-endpoint = <&ipu1_di0_disp0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   display_out: endpoint {
+   remote-endpoint = <&panel_in>;
+   };
+   };
+   };
+
keys {
compatible = "gpio-keys";
autorepeat;
@@ -135,6 +159,18 @@ led-debug0 {
};
};
 
+   panel {
+   compatible = "innolux,g070y2-t02";
+   backlight = <&backlight_lcd>;
+   power-supply = <®_3v3>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <&display_out>;
+   };
+   };
+   };
+
reg_bl_12v0: regulator-bl-12v0 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -146,6 +182,13 @@ reg_bl_12v0: regulator-bl-12v0 {
enable-active-high;
};
 
+   reg_3v3: regulator-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
reg_1v8: regulator-1v8 {
compatible = "regulator-fixed";
regulator-name = "1v8";
@@ -275,6 +318,10 @@ &ipu1 {
status = "okay";
 };
 
+&ipu1_di0_disp0 {
+   remote-endpoint = <&display_in>;
+};
+
 &pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
-- 
2.30.2

[PATCH v1 2/4] ARM: dts: imx6dl-prtvt7: Add missing tvp5150 video decoder node

From: Robin van der Gracht 

Signed-off-by: Robin van der Gracht 
---
 arch/arm/boot/dts/imx6dl-prtvt7.dts | 40 +
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts 
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index be7c4cb339e7..02b53df03e6f 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 #include "imx6dl.dtsi"
 #include "imx6qdl-prti6q.dtsi"
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,18 @@ panel_in: endpoint {
};
};
 
+   connector {
+   compatible = "composite-video-connector";
+   label = "Composite0";
+   sdtv-standards = ;
+
+   port {
+   comp0_out: endpoint {
+   remote-endpoint = <&tvp5150_comp0_in>;
+   };
+   };
+   };
+
reg_bl_12v0: regulator-bl-12v0 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -295,6 +308,29 @@ sgtl5000: audio-codec@a {
VDDIO-supply = <®_3v3>;
VDDD-supply = <®_1v8>;
};
+
+   video@5c {
+   compatible = "ti,tvp5150";
+   reg = <0x5c>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   tvp5150_comp0_in: endpoint {
+   remote-endpoint = <&comp0_out>;
+   };
+   };
+
+   /* Output port 2 is video output pad */
+   port@2 {
+   reg = <2>;
+   tvp5151_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<&ipu1_csi0_mux_from_parallel_sensor>;
+   };
+   };
+   };
 };
 
 &i2c3 {
@@ -322,6 +358,10 @@ &ipu1_di0_disp0 {
remote-endpoint = <&display_in>;
 };
 
+&ipu1_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <&tvp5151_to_ipu1_csi0_mux>;
+};
+
 &pwm1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
-- 
2.30.2

[PATCH v1 3/4] ARM: dts: imx6qdl-vicut1: add CAN termination support

The gpio1 0 pin is controlling CAN termination, not USB H1 VBUS. So,
remove wrong regulator and assign this GPIO to the new DT CAN termination
property.

Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi 
b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
index b9e305774fed..1ac7e13249d2 100644
--- a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
@@ -126,15 +126,6 @@ reg_3v3: regulator-3v3 {
regulator-max-microvolt = <330>;
};
 
-   reg_h1_vbus: regulator-h1-vbus {
-   compatible = "regulator-fixed";
-   regulator-name = "h1-vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
reg_otg_vbus: regulator-otg-vbus {
compatible = "regulator-fixed";
regulator-name = "otg-vbus";
@@ -212,6 +203,8 @@ IMX_AUDMUX_V2_PTCR_SYN  
IMX_AUDMUX_V2_PDCR_RXDSEL(0)
 &can1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_can1>;
+   termination-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+   termination-ohms = <150>;
status = "okay";
 };
 
@@ -492,7 +485,6 @@ &uart5 {
 };
 
 &usbh1 {
-   vbus-supply = <®_h1_vbus>;
pinctrl-names = "default";
phy_type = "utmi";
dr_mode = "host";
-- 
2.30.2

[PATCH v1 4/4] ARM: dts: imx6dl: plym2m, prtvt7, victgo: make use of new resistive-adc-touch driver

The tsc2046 is an ADC used as touchscreen controller. To share as mach
code as possible, we should use it as actual ADC + virtual tochscreen
controller.
With this patch we make use of the new kernel IIO and HID infrastructure.

Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/imx6dl-plym2m.dts | 55 -
 arch/arm/boot/dts/imx6dl-prtvt7.dts | 53 ---
 arch/arm/boot/dts/imx6dl-victgo.dts | 55 +
 3 files changed, 120 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts 
b/arch/arm/boot/dts/imx6dl-plym2m.dts
index 60fe5f14666e..e2afedae85cb 100644
--- a/arch/arm/boot/dts/imx6dl-plym2m.dts
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -101,6 +101,17 @@ reg_12v0: regulator-12v0 {
regulator-min-microvolt = <1200>;
regulator-max-microvolt = <1200>;
};
+
+   touchscreen {
+   compatible = "resistive-adc-touch";
+   io-channels = <&adc 1>, <&adc 3>, <&adc 4>, <&adc 5>;
+   io-channel-names = "y", "z1", "z2", "x";
+   touchscreen-min-pressure = <64687>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+   touchscreen-x-plate-ohms = <300>;
+   touchscreen-y-plate-ohms = <800>;
+   };
 };
 
 &can1 {
@@ -129,26 +140,38 @@ &ecspi2 {
pinctrl-0 = <&pinctrl_ecspi2>;
status = "okay";
 
-   touchscreen@0 {
-   compatible = "ti,tsc2046";
+   adc: adc@0 {
+   compatible = "ti,tsc2046e-adc";
reg = <0>;
pinctrl-0 = <&pinctrl_tsc2046>;
pinctrl-names ="default";
-   spi-max-frequency = <10>;
-   interrupts-extended = <&gpio3 20 IRQ_TYPE_EDGE_FALLING>;
-   pendown-gpio = <&gpio3 20 GPIO_ACTIVE_LOW>;
+   spi-max-frequency = <100>;
+   interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>;
+   #io-channel-cells = <1>;
 
-   touchscreen-inverted-x;
-   touchscreen-inverted-y;
-   touchscreen-max-pressure = <4095>;
-
-   ti,vref-delay-usecs = /bits/ 16 <100>;
-   ti,x-plate-ohms = /bits/ 16 <800>;
-   ti,y-plate-ohms = /bits/ 16 <300>;
-   ti,debounce-max = /bits/ 16 <3>;
-   ti,debounce-tol = /bits/ 16 <70>;
-   ti,debounce-rep = /bits/ 16 <3>;
-   wakeup-source;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   channel@1 {
+   reg = <1>;
+   settling-time-us = <700>;
+   oversampling-ratio = <5>;
+   };
+   channel@3 {
+   reg = <3>;
+   settling-time-us = <700>;
+   oversampling-ratio = <5>;
+   };
+   channel@4 {
+   reg = <4>;
+   settling-time-us = <700>;
+   oversampling-ratio = <5>;
+   };
+   channel@5 {
+   reg = <5>;
+   settling-time-us = <700>;
+   oversampling-ratio = <5>;
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts 
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
index 02b53df03e6f..c361e0683973 100644
--- a/arch/arm/boot/dts/imx6dl-prtvt7.dts
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -235,6 +235,17 @@ simple-audio-card,codec {
frame-master;
};
};
+
+   touchscreen {
+   compatible = "resistive-adc-touch";
+   io-channels = <&adc 1>, <&adc 3>, <&adc 4>, <&adc 5>;
+   io-channel-names = "y", "z1", "z2", "x";
+   touchscreen-min-pressure = <64687>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+   touchscreen-x-plate-ohms = <300>;
+   touchscreen-y-plate-ohms = <800>;
+   };
 };
 
 &audmux {
@@ -277,22 +288,38 @@ &ecspi2 {
pinctrl-0 = <&pinctrl_ecspi2>;
status = "okay";
 
-   touchscreen@0 {
-   compatible = "ti,tsc2046";
+   adc: adc@0 {
+   compatible = "ti,tsc2046e-adc";
reg = <0>;
pinctrl-0 = <&pinctrl_tsc>;
pinctrl-names ="default";
-   spi-max-frequency = <10>;
-   interrupts-extended = <&gpio3 20 IRQ_TYPE_EDGE_FALLING>;
-   pendown-gpio = <&gpio3 20 GPIO_ACTIVE_LOW>;
-   touchscreen-max-pressure = <4095>;
-   ti,vref-delay-usecs = /bits/ 16 <100>;
-   ti,x-plate-ohms = /bits/ 16 <800>;
-   ti,y-plate-ohms = /bits/ 16 <300>;
-   ti,debounce-max = /bits/ 16 <3>;
-   ti,debounce-tol = /bits/ 16 <70>;
-   ti,debounc

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Laurent Pinchart

Hi Maxime,

On Mon, Nov 22, 2021 at 11:07:12AM +0100, Maxime Ripard wrote:
> On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output, those
> > can have an option to connect the DSI host by means of interface
> > bridge converter.
> > 
> > This DSI to non-DSI interface bridge converter would requires
> > DSI Host to handle drm bridge functionalities in order to DSI
> > Host to Interface bridge.
> 
> In order to do this you would need to use the DRM bridge API...
> 
> > This patch convert the existing to a drm bridge driver with a
> > built-in encoder support for compatibility with existing
> > component drivers.
> 
> ... but changing the encoder driver to a bridge is completely
> unnecessary to do so. Why did you need to make that change?
> 
> > Signed-off-by: Jagan Teki 
> >
> > ---
> > Changes for v5:
> > - add atomic APIs
> > - find host and device variant DSI devices.
> > Changes for v4, v3:
> > - none
> > 
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> >  2 files changed, 96 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 43d9c9e5198d..a6a272b55f77 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -21,6 +21,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> > return 0;
> >  }
> >  
> > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > +  struct drm_bridge_state 
> > *old_bridge_state)
> >  {
> > -   struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> > -   struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > +   struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > +   struct drm_display_mode *mode = 
> > &bridge->encoder->crtc->state->adjusted_mode;
> > struct mipi_dsi_device *device = dsi->device;
> > union phy_configure_opts opts = { };
> > struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> > *encoder)
> > if (dsi->panel)
> > drm_panel_prepare(dsi->panel);
> >  
> > +   if (dsi->next_bridge)
> > +   dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > old_bridge_state);
> > +
> 
> Please use the proper helpers.

I don't know about this series in particular, but overall we try to move
encoders to bridge drivers in order to standardize on a single API. The
drm_encoder can't be removed as it's exposed to userspace, so it then
becomes a dumb encoder, without any operation implemented.

> > /*
> >  * FIXME: This should be moved after the switch to HS mode.
> >  *
> > @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> > *encoder)
> > if (dsi->panel)
> > drm_panel_enable(dsi->panel);
> >  
> > +   if (dsi->next_bridge)
> > +   dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> > old_bridge_state);
> > +
> 
> Ditto
> 
> > sun6i_dsi_start(dsi, DSI_START_HSC);
> >  
> > udelay(1000);
> > @@ -794,15 +802,19 @@ static void sun6i_dsi_encoder_enable(struct 
> > drm_encoder *encoder)
> > sun6i_dsi_start(dsi, DSI_START_HSD);
> >  }
> >  
> > -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> > +static void sun6i_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> > +   struct drm_bridge_state 
> > *old_bridge_state)
> >  {
> > -   struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > +   struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> >  
> > DRM_DEBUG_DRIVER("Disabling DSI output\n");
> >  
> > if (dsi->panel) {
> > drm_panel_disable(dsi->panel);
> > drm_panel_unprepare(dsi->panel);
> > +   } else if (dsi->next_bridge) {
> > +   dsi->next_bridge->funcs->atomic_disable(dsi->next_bridge, 
> > old_bridge_state);
> > +   dsi->next_bridge->funcs->atomic_post_disable(dsi->next_bridge, 
> > old_bridge_state);
> 
> Ditto
> 
> > }
> >  
> > phy_power_off(dsi->dphy);
> > @@ -842,9 +854,25 @@ static const struct drm_connector_funcs 
> > sun6i_dsi_connector_funcs = {
> > .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
> >  };
> >  
> > -static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
> > -   .disable= sun6i_dsi_encoder_disable,
> > -   .enable = sun6i_dsi_encoder_enable,
> > +static int sun6i_dsi_bridge_attach(struct drm_bridge *bridge,
> > +  enum drm_bridge_attach_flags flags)
> > +{
> > +

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Neil Armstrong

On 22/11/2021 07:52, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
> 
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge functionalities in order to DSI
> Host to Interface bridge.
> 
> This patch convert the existing to a drm bridge driver with a
> built-in encoder support for compatibility with existing
> component drivers.
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v5:
> - add atomic APIs
> - find host and device variant DSI devices.
> Changes for v4, v3:
> - none
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
>  2 files changed, 96 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 43d9c9e5198d..a6a272b55f77 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
>   return 0;
>  }
>  
> -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> +struct drm_bridge_state 
> *old_bridge_state)
>  {
> - struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> + struct drm_display_mode *mode = 
> &bridge->encoder->crtc->state->adjusted_mode;
>   struct mipi_dsi_device *device = dsi->device;
>   union phy_configure_opts opts = { };
>   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_prepare(dsi->panel);
>  
> + if (dsi->next_bridge)
> + dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> old_bridge_state);
> +
>   /*
>* FIXME: This should be moved after the switch to HS mode.
>*
> @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_enable(dsi->panel);
>  
> + if (dsi->next_bridge)
> + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> old_bridge_state);
> +


No need to call the next bridge atomic pre_enable/enable/disable/post_disable 
since they will
be called automatically on the bridge chain.

>   sun6i_dsi_start(dsi, DSI_START_HSC);
>  
>   udelay(1000);
> @@ -794,15 +802,19 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   sun6i_dsi_start(dsi, DSI_START_HSD);
>  }
>  
> -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state 
> *old_bridge_state)
>  {
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
>  
>   DRM_DEBUG_DRIVER("Disabling DSI output\n");
>  
>   if (dsi->panel) {
>   drm_panel_disable(dsi->panel);
>   drm_panel_unprepare(dsi->panel);
> + } else if (dsi->next_bridge) {
> + dsi->next_bridge->funcs->atomic_disable(dsi->next_bridge, 
> old_bridge_state);
> + dsi->next_bridge->funcs->atomic_post_disable(dsi->next_bridge, 
> old_bridge_state);

Ditto

>   }
>  
>   phy_power_off(dsi->dphy);
> @@ -842,9 +854,25 @@ static const struct drm_connector_funcs 
> sun6i_dsi_connector_funcs = {
>   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>  };
>  
> -static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
> - .disable= sun6i_dsi_encoder_disable,
> - .enable = sun6i_dsi_encoder_enable,
> +static int sun6i_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> +
> + if (dsi->next_bridge)
> + return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +  NULL, 0);
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs sun6i_dsi_bridge_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state   = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset   = drm_atomic_helper_bridge_reset,
> + .atomic_enable  = sun6i_dsi_bridge_atomic_enable,
> + .atomic_disable = sun6i_ds

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 3:38 PM Maxime Ripard  wrote:
>
> On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> > Get the display mode settings via mode_set bridge function
> > instead of explicitly de-reference.
>
> What's wrong with dereferencing the mode?

Nothing wrong with dereferencing, however we have built-in API to that job.

Jagan.

Patch "drm/cma-helper: Release non-coherent memory with dma_free_noncoherent()" has been added to the 5.15-stable tree

2021-11-22 Thread gregkh



This is a note to let you know that I've just added the patch titled

drm/cma-helper: Release non-coherent memory with dma_free_noncoherent()

to the 5.15-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-cma-helper-release-non-coherent-memory-with-dma_free_noncoherent.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 995f54ea962e03ec08b8bc6a4fe11a32b420edd3 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann 
Date: Thu, 8 Jul 2021 19:51:46 +0200
Subject: drm/cma-helper: Release non-coherent memory with dma_free_noncoherent()

From: Thomas Zimmermann 

commit 995f54ea962e03ec08b8bc6a4fe11a32b420edd3 upstream.

The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage
with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this
with a call to dma_free_noncoherent(). Writecombining storage is still
released with dma_free_wc().

Signed-off-by: Thomas Zimmermann 
Fixes: cf8ccbc72d61 ("drm: Add support for GEM buffers backed by non-coherent 
memory")
Acked-by: Paul Cercueil 
Cc: Thomas Zimmermann 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20210708175146.10618-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/drm_gem_cma_helper.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -210,8 +210,13 @@ void drm_gem_cma_free_object(struct drm_
dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map);
drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
} else if (cma_obj->vaddr) {
-   dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
-   cma_obj->vaddr, cma_obj->paddr);
+   if (cma_obj->map_noncoherent)
+   dma_free_noncoherent(gem_obj->dev->dev, 
cma_obj->base.size,
+cma_obj->vaddr, cma_obj->paddr,
+DMA_TO_DEVICE);
+   else
+   dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
+   cma_obj->vaddr, cma_obj->paddr);
}
 
drm_gem_object_release(gem_obj);


Patches currently in stable-queue which might be from tzimmerm...@suse.de are

queue-5.15/drm-cma-helper-release-non-coherent-memory-with-dma_free_noncoherent.patch

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

Hi Neil,

On Mon, Nov 22, 2021 at 6:22 PM Neil Armstrong  wrote:
>
> On 22/11/2021 07:52, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output, those
> > can have an option to connect the DSI host by means of interface
> > bridge converter.
> >
> > This DSI to non-DSI interface bridge converter would requires
> > DSI Host to handle drm bridge functionalities in order to DSI
> > Host to Interface bridge.
> >
> > This patch convert the existing to a drm bridge driver with a
> > built-in encoder support for compatibility with existing
> > component drivers.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> > Changes for v5:
> > - add atomic APIs
> > - find host and device variant DSI devices.
> > Changes for v4, v3:
> > - none
> >
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> >  2 files changed, 96 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 43d9c9e5198d..a6a272b55f77 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -21,6 +21,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> >   return 0;
> >  }
> >
> > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > +struct drm_bridge_state 
> > *old_bridge_state)
> >  {
> > - struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > + struct drm_display_mode *mode = 
> > &bridge->encoder->crtc->state->adjusted_mode;
> >   struct mipi_dsi_device *device = dsi->device;
> >   union phy_configure_opts opts = { };
> >   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> > *encoder)
> >   if (dsi->panel)
> >   drm_panel_prepare(dsi->panel);
> >
> > + if (dsi->next_bridge)
> > + dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > old_bridge_state);
> > +
> >   /*
> >* FIXME: This should be moved after the switch to HS mode.
> >*
> > @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> > *encoder)
> >   if (dsi->panel)
> >   drm_panel_enable(dsi->panel);
> >
> > + if (dsi->next_bridge)
> > + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> > old_bridge_state);
> > +
>
>
> No need to call the next bridge atomic pre_enable/enable/disable/post_disable 
> since they will
> be called automatically on the bridge chain.

Correct, but the existing bridge chain (stack) is not compatible with
sun6i DSI start sequence. We cannot send any DCS once we start HS
mode.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#n775

This specific problem can be fixed only if we change the bridge chain
from stack to queue. Please check this series
https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-6-ja...@amarulasolutions.com/

Jagan.

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 06:35:58PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 3:38 PM Maxime Ripard  wrote:
> >
> > On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> > > Get the display mode settings via mode_set bridge function
> > > instead of explicitly de-reference.
> >
> > What's wrong with dereferencing the mode?
> 
> Nothing wrong with dereferencing, however we have built-in API to that job.

That's not an API though?

It's perfectly valid to dereference the pointer in atomic_enable, and
that patch would consume memory for no particular reason.

Maxime

Re: [PATCH 1/2] drm/i915/dmabuf: fix broken build




On 28/10/2021 09:48, Matthew Auld wrote:

On 28/10/2021 02:43, Vivi, Rodrigo wrote:

On Wed, 2021-10-27 at 10:48 +0100, Matthew Auld wrote:

On Wed, 27 Oct 2021 at 10:44, Jani Nikula
 wrote:


On Wed, 27 Oct 2021, Matthew Auld 
wrote:

On Wed, 27 Oct 2021 at 09:58, Jani Nikula
 wrote:


On Wed, 27 Oct 2021, Matthew Auld
 wrote:

On Thu, 21 Oct 2021 at 13:54, Matthew Auld
 wrote:


wbinvd_on_all_cpus() is only defined on x86 it seems, plus
we need to
include asm/smp.h here.

Reported-by: kernel test robot 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 


Jani, would it make sense to cherry-pick this to -fixes? The
offending
commit is in drm-next, and there have been a few reports
around this.

Fixes: a035154da45d ("drm/i915/dmabuf: add paranoid flush-on-
acquire")


If the Fixes: tag is in place, our tooling will cherry-pick it
where it
belongs. (In this case, drm-intel-next-fixes, not drm-intel-
fixes.)


Yeah, I forgot to add the fixes tag here unfortunately.


Already merged? What's the commit id to be cherry-picked? Rodrigo
can do
it manually.


Yeah, it was merged to gt-next:

777226dac058 ("drm/i915/dmabuf: fix broken build")


picked up to drm-intel-next-fixes


Thanks.


Hmm it looks like we have this in -fixes (and in -gt) while Linus has 
explicitly thrown it out (see 
https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html). 



End result is that now we have a different Kernel Test Robot warning 
("asm/smp.h is included more than once.").


So we need to fish out "drm/i915/dmabuf: fix broken build" out from 
fixes with a revert or what?


Regards,

Tvrtko





thanks,
Rodrigo.





Note to self, we should set up some way to check which maintainer
is
responsible for which branches and when.

BR,
Jani.





Cc: Rodrigo who covers drm-intel-next-fixes atm.

BR,
Jani.







---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 1adcd8e02d29..a45d0ec2c5b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,13 @@
  #include "i915_gem_object.h"
  #include "i915_scatterlist.h"

+#if defined(CONFIG_X86)
+#include 
+#else
+#define wbinvd_on_all_cpus() \
+   pr_warn(DRIVER_NAME ": Missing cache flush in
%s\n", __func__)
+#endif
+
  I915_SELFTEST_DECLARE(static bool
force_different_devices;)

  static struct drm_i915_gem_object *dma_buf_to_obj(struct
dma_buf *buf)
--
2.26.3



--
Jani Nikula, Intel Open Source Graphics Center


--
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v3] drm/i915/rpm: Enable runtime pm autosuspend by default

2021-11-22 Thread Anshuman Gupta

On 2021-11-16 at 21:22:38 +0530, Tilak Tangudu wrote:
> v1: Enable runtime pm autosuspend by default for Gen12
> and later versions.
> 
> v2: Enable runtime pm autosuspend by default for all
> platforms(Syrjala Ville)
> 
> v3: Change commit message(Nikula Jani)
It would require to reorder the commit log, version log
need to move after commit message.
Thanks,
Anshuman.
> Let's enable runtime pm autosuspend by default everywhere.
> So, we can allow D3hot and bigger power savings on idle scenarios.
> 
> But at this time let's not touch the autosuspend_delay time,
> what caused some regression on our previous attempt.
> 
> Also, the latest identified issue on GuC PM has been fixed by
> commit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregistering
> context")
> 
> Signed-off-by: Tilak Tangudu 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 0d85f3c5c526..22dab36afcb6 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -590,6 +590,9 @@ void intel_runtime_pm_enable(struct intel_runtime_pm *rpm)
>   pm_runtime_use_autosuspend(kdev);
>   }
>  
> + /* Enable by default */
> + pm_runtime_allow(kdev);
> +
>   /*
>* The core calls the driver load handler with an RPM reference held.
>* We drop that here and will reacquire it during unloading in
> -- 
> 2.25.1
>

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

Hi Maxime,

On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard  wrote:
>
> On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output, those
> > can have an option to connect the DSI host by means of interface
> > bridge converter.
> >
> > This DSI to non-DSI interface bridge converter would requires
> > DSI Host to handle drm bridge functionalities in order to DSI
> > Host to Interface bridge.
>
> In order to do this you would need to use the DRM bridge API...

Sorry, which bridge API do you mean?

>
> > This patch convert the existing to a drm bridge driver with a
> > built-in encoder support for compatibility with existing
> > component drivers.
>
> ... but changing the encoder driver to a bridge is completely
> unnecessary to do so. Why did you need to make that change?

Idea of this series is to convert the driver to bridge and use the
latest bridge function from the v1 series.

>
> > Signed-off-by: Jagan Teki 
> >
> > ---
> > Changes for v5:
> > - add atomic APIs
> > - find host and device variant DSI devices.
> > Changes for v4, v3:
> > - none
> >
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> >  2 files changed, 96 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 43d9c9e5198d..a6a272b55f77 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -21,6 +21,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> >   return 0;
> >  }
> >
> > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > +struct drm_bridge_state 
> > *old_bridge_state)
> >  {
> > - struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > + struct drm_display_mode *mode = 
> > &bridge->encoder->crtc->state->adjusted_mode;
> >   struct mipi_dsi_device *device = dsi->device;
> >   union phy_configure_opts opts = { };
> >   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> > *encoder)
> >   if (dsi->panel)
> >   drm_panel_prepare(dsi->panel);
> >
> > + if (dsi->next_bridge)
> > + dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > old_bridge_state);
> > +
>
> Please use the proper helpers.

If we use bridge_functions we need to take atomic functions as
precedence as the next bridge functions might convert atomic calls.

>
> >   /*
> >* FIXME: This should be moved after the switch to HS mode.
> >*
> > @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> > *encoder)
> >   if (dsi->panel)
> >   drm_panel_enable(dsi->panel);
> >
> > + if (dsi->next_bridge)
> > + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> > old_bridge_state);
> > +
>
> Ditto
>
> >   sun6i_dsi_start(dsi, DSI_START_HSC);
> >
> >   udelay(1000);
> > @@ -794,15 +802,19 @@ static void sun6i_dsi_encoder_enable(struct 
> > drm_encoder *encoder)
> >   sun6i_dsi_start(dsi, DSI_START_HSD);
> >  }
> >
> > -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> > +static void sun6i_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> > + struct drm_bridge_state 
> > *old_bridge_state)
> >  {
> > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> >
> >   DRM_DEBUG_DRIVER("Disabling DSI output\n");
> >
> >   if (dsi->panel) {
> >   drm_panel_disable(dsi->panel);
> >   drm_panel_unprepare(dsi->panel);
> > + } else if (dsi->next_bridge) {
> > + dsi->next_bridge->funcs->atomic_disable(dsi->next_bridge, 
> > old_bridge_state);
> > + 
> > dsi->next_bridge->funcs->atomic_post_disable(dsi->next_bridge, 
> > old_bridge_state);
>
> Ditto
>
> >   }
> >
> >   phy_power_off(dsi->dphy);
> > @@ -842,9 +854,25 @@ static const struct drm_connector_funcs 
> > sun6i_dsi_connector_funcs = {
> >   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
> >  };
> >
> > -static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
> > - .disable= sun6i_dsi_encoder_disable,
> > - .enable = sun6i_dsi_encoder_enable,
> > +static int sun6i_dsi_bridge_attach(struct drm_bridge *bridge,
> > +

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

Hi Maxime,

On Mon, Nov 22, 2021 at 6:58 PM Maxime Ripard  wrote:
>
> On Mon, Nov 22, 2021 at 06:35:58PM +0530, Jagan Teki wrote:
> > On Mon, Nov 22, 2021 at 3:38 PM Maxime Ripard  wrote:
> > >
> > > On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> > > > Get the display mode settings via mode_set bridge function
> > > > instead of explicitly de-reference.
> > >
> > > What's wrong with dereferencing the mode?
> >
> > Nothing wrong with dereferencing, however we have built-in API to that job.
>
> That's not an API though?

May be we can call it bridge or encoding function, I usually call
these ops are API's.

>
> It's perfectly valid to dereference the pointer in atomic_enable, and
> that patch would consume memory for no particular reason.

Again, I'm not pointing any mistake in dereference and certainly not
understand about what memory consumption issue here. I'm doing it here
since I'm doing it via mode_set in other drivers. No problem for me
either way.

Thanks,
Jagan.

[PATCH] Revert "drm/i915/dmabuf: fix broken build"

From: Tvrtko Ursulin 

This reverts commit 777226dac058d119286b4081953cb5aa2cb7394b.

Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive via 304ac8032d3f
("Merge tag 'drm-next-2021-11-12' of git://anongit.freedesktop.org/drm/drm").

Signed-off-by: Tvrtko Ursulin 
Fixes: 777226dac058 ("drm/i915/dmabuf: fix broken build")
Cc: Matthew Auld 
Cc: Thomas Hellström 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f291cf4c3886..1b526039a60d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -17,13 +17,6 @@
 
 MODULE_IMPORT_NS(DMA_BUF);
 
-#if defined(CONFIG_X86)
-#include 
-#else
-#define wbinvd_on_all_cpus() \
-   pr_warn(DRIVER_NAME ": Missing cache flush in %s\n", __func__)
-#endif
-
 I915_SELFTEST_DECLARE(static bool force_different_devices;)
 
 static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
-- 
2.32.0

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

Hi Marek.

On Mon, Nov 22, 2021 at 12:36 PM Jagan Teki  wrote:
>
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
>
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge functionalities in order to DSI
> Host to Interface bridge.
>
> This patch convert the existing to a drm bridge driver with a
> built-in encoder support for compatibility with existing
> component drivers.
>
> Signed-off-by: Jagan Teki 
> ---
> Note:
> Hi Marek Szyprowski,
>
> Please test this on Panel and Bridge hardware.
>
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 73 +
>  1 file changed, 51 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8d137857818c..174590f543c3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -257,6 +257,7 @@ struct exynos_dsi {
> struct drm_connector connector;
> struct drm_panel *panel;
> struct list_head bridge_chain;
> +   struct drm_bridge bridge;
> struct drm_bridge *out_bridge;
> struct device *dev;
>
> @@ -287,9 +288,9 @@ struct exynos_dsi {
>  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>  #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>
> -static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
> +static inline struct exynos_dsi *bridge_to_dsi(struct drm_bridge *b)
>  {
> -   return container_of(e, struct exynos_dsi, encoder);
> +   return container_of(b, struct exynos_dsi, bridge);
>  }
>
>  enum reg_idx {
> @@ -1374,9 +1375,10 @@ static void exynos_dsi_unregister_te_irq(struct 
> exynos_dsi *dsi)
> }
>  }
>
> -static void exynos_dsi_enable(struct drm_encoder *encoder)
> +static void exynos_dsi_atomic_enable(struct drm_bridge *bridge,
> +struct drm_bridge_state 
> *old_bridge_state)
>  {
> -   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> +   struct exynos_dsi *dsi = bridge_to_dsi(bridge);
> struct drm_bridge *iter;
> int ret;
>
> @@ -1399,7 +1401,8 @@ static void exynos_dsi_enable(struct drm_encoder 
> *encoder)
> list_for_each_entry_reverse(iter, &dsi->bridge_chain,
> chain_node) {
> if (iter->funcs->pre_enable)
> -   iter->funcs->pre_enable(iter);
> +   iter->funcs->atomic_pre_enable(iter,
> +  
> old_bridge_state);
> }
> }
>
> @@ -1413,7 +1416,7 @@ static void exynos_dsi_enable(struct drm_encoder 
> *encoder)
> } else {
> list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
> if (iter->funcs->enable)
> -   iter->funcs->enable(iter);
> +   iter->funcs->atomic_enable(iter, 
> old_bridge_state);
> }
> }
>
> @@ -1429,9 +1432,10 @@ static void exynos_dsi_enable(struct drm_encoder 
> *encoder)
> pm_runtime_put(dsi->dev);
>  }
>
> -static void exynos_dsi_disable(struct drm_encoder *encoder)
> +static void exynos_dsi_atomic_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state 
> *old_bridge_state)
>  {
> -   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> +   struct exynos_dsi *dsi = bridge_to_dsi(bridge);
> struct drm_bridge *iter;
>
> if (!(dsi->state & DSIM_STATE_ENABLED))
> @@ -1443,7 +1447,7 @@ static void exynos_dsi_disable(struct drm_encoder 
> *encoder)
>
> list_for_each_entry_reverse(iter, &dsi->bridge_chain, chain_node) {
> if (iter->funcs->disable)
> -   iter->funcs->disable(iter);
> +   iter->funcs->atomic_disable(iter, old_bridge_state);
> }
>
> exynos_dsi_set_display_enable(dsi, false);
> @@ -1451,7 +1455,7 @@ static void exynos_dsi_disable(struct drm_encoder 
> *encoder)
>
> list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
> if (iter->funcs->post_disable)
> -   iter->funcs->post_disable(iter);
> +   iter->funcs->atomic_post_disable(iter, 
> old_bridge_state);
> }
>
> dsi->state &= ~DSIM_STATE_ENABLED;
> @@ -1494,9 +1498,9 @@ static const struct drm_connector_helper_funcs 
> exynos_dsi_connector_helper_funcs
> .get_modes = exynos_dsi_get_modes,
>  };
>
> -static int exynos_dsi_create_connector(struct drm_encoder *encoder)
> +static int exynos_dsi_create_connector(struct exynos_dsi *dsi)
>  {
> -   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> +   struct drm_encode

Re: [PATCH] Revert "drm/i915/dmabuf: fix broken build"

2021-11-22 Thread Matthew Auld


On 22/11/2021 13:57, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

This reverts commit 777226dac058d119286b4081953cb5aa2cb7394b.

Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive via 304ac8032d3f
("Merge tag 'drm-next-2021-11-12' of git://anongit.freedesktop.org/drm/drm").

Signed-off-by: Tvrtko Ursulin 
Fixes: 777226dac058 ("drm/i915/dmabuf: fix broken build")
Cc: Matthew Auld 
Cc: Thomas Hellström 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 


Acked-by: Matthew Auld 

This was copy-paste from gem/i915_gem_pm.c, does that need a similar patch?


---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f291cf4c3886..1b526039a60d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -17,13 +17,6 @@
  
  MODULE_IMPORT_NS(DMA_BUF);
  
-#if defined(CONFIG_X86)

-#include 
-#else
-#define wbinvd_on_all_cpus() \
-   pr_warn(DRIVER_NAME ": Missing cache flush in %s\n", __func__)
-#endif
-
  I915_SELFTEST_DECLARE(static bool force_different_devices;)
  
  static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> Hi Maxime,
> 
> On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard  wrote:
> >
> > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > Some display panels would come up with a non-DSI output, those
> > > can have an option to connect the DSI host by means of interface
> > > bridge converter.
> > >
> > > This DSI to non-DSI interface bridge converter would requires
> > > DSI Host to handle drm bridge functionalities in order to DSI
> > > Host to Interface bridge.
> >
> > In order to do this you would need to use the DRM bridge API...
> 
> Sorry, which bridge API do you mean?

Any variant of of_drm_find_bridge, and drm_bridge_attach. Just like
we're doing in sun4i_rgb.c

> > > This patch convert the existing to a drm bridge driver with a
> > > built-in encoder support for compatibility with existing
> > > component drivers.
> >
> > ... but changing the encoder driver to a bridge is completely
> > unnecessary to do so. Why did you need to make that change?
> 
> Idea of this series is to convert the driver to bridge and use the
> latest bridge function from the v1 series.

Ok, but it's not at all what you mention in your commit log? You don't
need any of that in order to support a bridge downstream.

> >
> > > Signed-off-by: Jagan Teki 
> > >
> > > ---
> > > Changes for v5:
> > > - add atomic APIs
> > > - find host and device variant DSI devices.
> > > Changes for v4, v3:
> > > - none
> > >
> > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> > >  2 files changed, 96 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > index 43d9c9e5198d..a6a272b55f77 100644
> > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > @@ -21,6 +21,7 @@
> > >
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> > >   return 0;
> > >  }
> > >
> > > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > > +struct drm_bridge_state 
> > > *old_bridge_state)
> > >  {
> > > - struct drm_display_mode *mode = 
> > > &encoder->crtc->state->adjusted_mode;
> > > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > > + struct drm_display_mode *mode = 
> > > &bridge->encoder->crtc->state->adjusted_mode;
> > >   struct mipi_dsi_device *device = dsi->device;
> > >   union phy_configure_opts opts = { };
> > >   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > drm_encoder *encoder)
> > >   if (dsi->panel)
> > >   drm_panel_prepare(dsi->panel);
> > >
> > > + if (dsi->next_bridge)
> > > + 
> > > dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > > old_bridge_state);
> > > +
> >
> > Please use the proper helpers.
> 
> If we use bridge_functions we need to take atomic functions as
> precedence as the next bridge functions might convert atomic calls.

We've had this discussion over and over again, but this is something
that needs to be documented and / or in your commit log.

You must not deviate from the standard (and expected) behavior without
any kind of justification.

> >
> > >   /*
> > >* FIXME: This should be moved after the switch to HS mode.
> > >*
> > > @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > drm_encoder *encoder)
> > >   if (dsi->panel)
> > >   drm_panel_enable(dsi->panel);
> > >
> > > + if (dsi->next_bridge)
> > > + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> > > old_bridge_state);
> > > +
> >
> > Ditto
> >
> > >   sun6i_dsi_start(dsi, DSI_START_HSC);
> > >
> > >   udelay(1000);
> > > @@ -794,15 +802,19 @@ static void sun6i_dsi_encoder_enable(struct 
> > > drm_encoder *encoder)
> > >   sun6i_dsi_start(dsi, DSI_START_HSD);
> > >  }
> > >
> > > -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> > > +static void sun6i_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> > > + struct drm_bridge_state 
> > > *old_bridge_state)
> > >  {
> > > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > >
> > >   DRM_DEBUG_DRIVER("Disabling DSI output\n");
> > >
> > >   if (dsi->panel) {
> > >   drm_panel_disable(dsi->panel);
> > >   drm_panel_unprepare(dsi->panel);
> > > + } else if (dsi->next

Re: [PATCH v3] drm/i915/rpm: Enable runtime pm autosuspend by default

2021-11-22 Thread Rodrigo Vivi

On Mon, Nov 22, 2021 at 07:18:17PM +0530, Anshuman Gupta wrote:
> On 2021-11-16 at 21:22:38 +0530, Tilak Tangudu wrote:
> > v1: Enable runtime pm autosuspend by default for Gen12
> > and later versions.
> > 
> > v2: Enable runtime pm autosuspend by default for all
> > platforms(Syrjala Ville)
> > 
> > v3: Change commit message(Nikula Jani)
> It would require to reorder the commit log, version log
> need to move after commit message.

Well noticed. I changed while pushing.

So, for the record:

Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi 

> Thanks,
> Anshuman.
> > Let's enable runtime pm autosuspend by default everywhere.
> > So, we can allow D3hot and bigger power savings on idle scenarios.
> > 
> > But at this time let's not touch the autosuspend_delay time,
> > what caused some regression on our previous attempt.
> > 
> > Also, the latest identified issue on GuC PM has been fixed by
> > commit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregistering
> > context")
> > 
> > Signed-off-by: Tilak Tangudu 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 0d85f3c5c526..22dab36afcb6 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -590,6 +590,9 @@ void intel_runtime_pm_enable(struct intel_runtime_pm 
> > *rpm)
> > pm_runtime_use_autosuspend(kdev);
> > }
> >  
> > +   /* Enable by default */
> > +   pm_runtime_allow(kdev);
> > +
> > /*
> >  * The core calls the driver load handler with an RPM reference held.
> >  * We drop that here and will reacquire it during unloading in
> > -- 
> > 2.25.1
> >

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > It's perfectly valid to dereference the pointer in atomic_enable, and
> > that patch would consume memory for no particular reason.
> 
> Again, I'm not pointing any mistake in dereference and certainly not
> understand about what memory consumption issue here.

You add a struct drm_display_mode field to struct sun6i_dsi. It
increases the size of struct sun6i_dsi of sizeof(struct
drm_display_mode).

> I'm doing it here since I'm doing it via mode_set in other drivers. No
> problem for me either way.

But *why* are you doing so?

There might be a valid reason in other drivers, but there's none here
(that you mentioned at least).

Maxime

Re: [PATCH v4] drm/ttm: Clarify that the TTM_PL_SYSTEM is under TTMs control

2021-11-22 Thread Christian König

Am 16.11.21 um 16:53 schrieb Zack Rusin:

On Nov 16, 2021, at 03:20, Christian König wrote:

Am 16.11.21 um 08:43 schrieb Thomas Hellström:

On 11/16/21 08:19, Christian König wrote:

Am 13.11.21 um 12:26 schrieb Thomas Hellström:

Hi, Zack,

On 11/11/21 17:44, Zack Rusin wrote:

On Wed, 2021-11-10 at 09:50 -0500, Zack Rusin wrote:

TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes
driver internal usage of TTM_PL_SYSTEM prone to errors because it
requires the drivers to manually handle all interactions between TTM
which can swap out those buffers whenever it thinks it's the right
thing to do and driver.

CPU buffers which need to be fenced and shared with accelerators
should
be placed in driver specific placements that can explicitly handle
CPU/accelerator buffer fencing.
Currently, apart, from things silently failing nothing is enforcing
that requirement which means that it's easy for drivers and new
developers to get this wrong. To avoid the confusion we can document
this requirement and clarify the solution.

This came up during a discussion on dri-devel:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F232f45e9-8748-1243-09bf-56763e6668b3%40amd.com&data=04%7C01%7Cchristian.koenig%40amd.com%7C57658f299a72436627e608d9a9194209%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637726748229186505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UbE43u8a0MPNgXtzcqkJJfSe0I%2BA5Yojz7yoh7e6Oyo%3D&reserved=0

I took a slightly deeper look into this. I think we need to formalize this a bit more to understand
pros and cons and what the restrictions are really all about. Anybody looking at the prevous
discussion will mostly see arguments similar to "this is stupid and difficult" and
"it has always been this way" which are not really constructive.

First disregarding all accounting stuff, I think this all boils down to
TTM_PL_SYSTEM having three distinct states:
1) POPULATED
2) LIMBO (Or whatever we want to call it. No pages present)
3) SWAPPED.

The ttm_bo_move_memcpy() helper understands these, and any standalone driver
implementation of the move() callback _currently_ needs to understand these as
well, unless using the ttm_bo_move_memcpy() helper.

Now using a bounce domain to proxy SYSTEM means that the driver can forget
about the SWAPPED state, it's automatically handled by the move setup code.
However, another pitfall is LIMBO, in that if when you move from SYSTEM/LIMBO
to your bounce domain, the BO will be populated. So any naive accelerated
move() implementation creating a 1GB BO in fixed memory, like VRAM, will
needlessly allocate and free 1GB of system memory in the process instead of
just performing a clear operation. Looks like amdgpu suffers from this?

I think what is really needed is either

a) A TTM helper that helps move callback implementations resolve the issues
populating system from LIMBO or SWAP, and then also formalize driver
notification for swapping. At a minimum, I think the swap_notify() callback
needs to be able to return a late error.

b) Make LIMBO and SWAPPED distinct memory regions. (I think I'd vote for this
without looking into it in detail).

In both these cases, we should really make SYSTEM bindable by GPU, otherwise
we'd just be trading one pitfall for another related without really resolving
the root problem.

As for fencing not being supported by SYSTEM, I'm not sure why we don't want
this, because it would for example prohibit async ttm_move_memcpy(), and also,
async unbinding of ttm_tt memory like MOB on vmgfx. (I think it's still sync).

There might be an accounting issue related to this as well, but I guess
Christian would need to chime in on this. If so, I think it needs to be well
understood and documented (in TTM, not in AMD drivers).

I think the problem goes deeper than what has been mentioned here so far.

Having fences attached to BOs in the system domain is probably ok, but the key
point is that the BOs in the system domain are under TTMs control and should
not be touched by the driver.

What we have now is that TTMs internals like the allocation state of BOs in
system memory (the populated, limbo, swapped you mentioned above) is leaking
into the drivers and I think exactly that is the part which doesn't work
reliable here. You can of course can get that working, but that requires
knowledge of the internal state which in my eyes was always illegal.

Well, I tend to agree to some extent, but then, like said above even disregarding
swap will cause trouble with the limbo state, because the driver's move callback
would need knowledge of that to implement moves limbo -> vram efficiently.

Well my long term plan is to audit the code base once more and remove the limbo
state from the SYSTEM domain.

E.g. instead of a SYSTEM BO without pages you allocate a BO without a resource in
general which is now possible since bo->resou

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

On 22.11.2021 08:06, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
>
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge functionalities in order to DSI
> Host to Interface bridge.
>
> This patch convert the existing to a drm bridge driver with a
> built-in encoder support for compatibility with existing
> component drivers.
>
> Signed-off-by: Jagan Teki 
> ---
> Note:
> Hi Marek Szyprowski,
>
> Please test this on Panel and Bridge hardware.

I don't have good news, t crashes:

[drm] Exynos DRM: using 1380.decon device for DMA mapping operations
exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
[drm:drm_bridge_attach] *ERROR* failed to attach bridge 
/soc@0/dsi@1390 to encoder TMDS-67: -22
exynos-drm exynos-drm: failed to bind 1390.dsi (ops 
exynos_dsi_component_ops): -22
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
Hardware name: Samsung TM2E board (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : decon_atomic_disable+0x58/0xd4
lr : decon_atomic_disable+0x28/0xd4
sp : 80001390b940
x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
input: stmfts as 
/devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
x26: ffea x25: 25a40280 x24: 0001
x23: 800011b55f98 x22: 315dc000 x21: 2695d100
x20: 27e7a080 x19: 315e6000 x18: 
x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
x14: 0028 x13: 0001 x12: 0040
x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
x8 : 23c00270 x7 :  x6 : 23c00268
x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
Call trace:
  decon_atomic_disable+0x58/0xd4
  decon_unbind+0x1c/0x3c
  component_unbind+0x38/0x60
  component_bind_all+0x16c/0x25c
  exynos_drm_bind+0x104/0x1bc
  try_to_bring_up_master+0x164/0x1d0
  __component_add+0xa8/0x174
  component_add+0x14/0x20
  hdmi_probe+0x438/0x710
  platform_probe+0x68/0xe0
  really_probe.part.0+0x9c/0x31c
  __driver_probe_device+0x98/0x144
  driver_probe_device+0xc8/0x160
  __device_attach_driver+0xb8/0x120
  bus_for_each_drv+0x78/0xd0
  __device_attach+0xd8/0x180
  device_initial_probe+0x14/0x20
  bus_probe_device+0x9c/0xa4
  deferred_probe_work_func+0x88/0xc4
  process_one_work+0x288/0x6f0
  worker_thread+0x74/0x470
  kthread+0x188/0x194
  ret_from_fork+0x10/0x20
Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
---[ end trace d73aff585b108954 ]---
Kernel panic - not syncing: synchronous external abort: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x2,300071c2,0846
Memory Limit: none
---[ end Kernel panic - not syncing: synchronous external abort: Fatal 
exception ]---

I will try to debug it a bit more once I find some spare time. I've 
applied only the first patch.

>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 73 +
>   1 file changed, 51 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8d137857818c..174590f543c3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -257,6 +257,7 @@ struct exynos_dsi {
>   struct drm_connector connector;
>   struct drm_panel *panel;
>   struct list_head bridge_chain;
> + struct drm_bridge bridge;
>   struct drm_bridge *out_bridge;
>   struct device *dev;
>   
> @@ -287,9 +288,9 @@ struct exynos_dsi {
>   #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
>   #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
>   
> -static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
> +static inline struct exynos_dsi *bridge_to_dsi(struct drm_bridge *b)
>   {
> - return container_of(e, struct exynos_dsi, encoder);
> + return container_of(b, struct exynos_dsi, bridge);
>   }
>   
>   enum reg_idx {
> @@ -1374,9 +1375,10 @@ static void exynos_dsi_unregister_te_irq(struct 
> exynos_dsi *dsi)
>   }
>   }
>   
> -static void exynos_dsi_enable(struct drm_encoder *encoder)
> +static void exynos_dsi_atomic_enable(struct drm_bridge *bridge,
> +  struct drm_bridge_state *old_bridge_state)
>   {
> - struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> + struct exynos_dsi *dsi = bridge_to_d

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

Hi Maxime,

On Mon, Nov 22, 2021 at 7:35 PM Maxime Ripard  wrote:
>
> On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard  wrote:
> > >
> > > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > > Some display panels would come up with a non-DSI output, those
> > > > can have an option to connect the DSI host by means of interface
> > > > bridge converter.
> > > >
> > > > This DSI to non-DSI interface bridge converter would requires
> > > > DSI Host to handle drm bridge functionalities in order to DSI
> > > > Host to Interface bridge.
> > >
> > > In order to do this you would need to use the DRM bridge API...
> >
> > Sorry, which bridge API do you mean?
>
> Any variant of of_drm_find_bridge, and drm_bridge_attach. Just like
> we're doing in sun4i_rgb.c

Yes, we have drm_bridge_attach in bind and bridge_function.attach
calls in this patch and of_drm_find_bridge in sun6i_mipi_dsi_attach.
Not sure which API's I've missed.

>
> > > > This patch convert the existing to a drm bridge driver with a
> > > > built-in encoder support for compatibility with existing
> > > > component drivers.
> > >
> > > ... but changing the encoder driver to a bridge is completely
> > > unnecessary to do so. Why did you need to make that change?
> >
> > Idea of this series is to convert the driver to bridge and use the
> > latest bridge function from the v1 series.
>
> Ok, but it's not at all what you mention in your commit log? You don't
> need any of that in order to support a bridge downstream.

I've mentioned "Converting to bridge driver" and thought it has
meaning of converting encoder related function to bridge functions as
well. Not think about specific description to describe on commit
message. Will update this.

>
> > >
> > > > Signed-off-by: Jagan Teki 
> > > >
> > > > ---
> > > > Changes for v5:
> > > > - add atomic APIs
> > > > - find host and device variant DSI devices.
> > > > Changes for v4, v3:
> > > > - none
> > > >
> > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> > > >  2 files changed, 96 insertions(+), 23 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > index 43d9c9e5198d..a6a272b55f77 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > @@ -21,6 +21,7 @@
> > > >
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> > > >   return 0;
> > > >  }
> > > >
> > > > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > > > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > > > +struct drm_bridge_state 
> > > > *old_bridge_state)
> > > >  {
> > > > - struct drm_display_mode *mode = 
> > > > &encoder->crtc->state->adjusted_mode;
> > > > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > > > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > > > + struct drm_display_mode *mode = 
> > > > &bridge->encoder->crtc->state->adjusted_mode;
> > > >   struct mipi_dsi_device *device = dsi->device;
> > > >   union phy_configure_opts opts = { };
> > > >   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > > > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > > drm_encoder *encoder)
> > > >   if (dsi->panel)
> > > >   drm_panel_prepare(dsi->panel);
> > > >
> > > > + if (dsi->next_bridge)
> > > > + 
> > > > dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > > > old_bridge_state);
> > > > +
> > >
> > > Please use the proper helpers.
> >
> > If we use bridge_functions we need to take atomic functions as
> > precedence as the next bridge functions might convert atomic calls.
>
> We've had this discussion over and over again, but this is something
> that needs to be documented and / or in your commit log.
>
> You must not deviate from the standard (and expected) behavior without
> any kind of justification.

Not exactly sure about what you mean, sorry. All these atomic bridge
functions are already documented if I'm not wrong and Laurent have
patches to switch the normal functions to atomic. Not sure what else
need to document here and need justification for it if the driver is
converting to bridge.

>
> > >
> > > >   /*
> > > >* FIXME: This should be moved after the switch to HS mode.
> > > >*
> > > > @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > > drm_encoder *encoder)
> > > >   if (dsi->panel)
> > > >   drm_panel_enable(dsi->panel);
> > > >
> > > > + if (dsi->next_bridge)
> > > > + ds

[drm-exynos:exynos-drm-next 1/3] drivers/gpu/drm/exynos/exynos_drm_dsi.c:1338:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is true

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next
head:   ef1a179ae8eba0aeaac239a28ecdd0700412052a
commit: 84d977a69917c18c9e0a65ed16b43dc889fdd97c [1/3] drm/exynos: Replace 
legacy gpio interface for gpiod interface
config: riscv-randconfig-r006-20211122 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 
c133fb321f7ca6083ce15b6aa5bf89de6600e649)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/commit/?id=84d977a69917c18c9e0a65ed16b43dc889fdd97c
git remote add drm-exynos 
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
git fetch --no-tags drm-exynos exynos-drm-next
git checkout 84d977a69917c18c9e0a65ed16b43dc889fdd97c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/exynos/exynos_drm_dsi.c:1338:6: warning: variable 'ret' is 
>> used uninitialized whenever 'if' condition is true 
>> [-Wsometimes-uninitialized]
   if (IS_ERR(dsi->te_gpio)) {
   ^~~~
   drivers/gpu/drm/exynos/exynos_drm_dsi.c:1355:9: note: uninitialized use 
occurs here
   return ret;
  ^~~
   drivers/gpu/drm/exynos/exynos_drm_dsi.c:1338:2: note: remove the 'if' if its 
condition is always false
   if (IS_ERR(dsi->te_gpio)) {
   ^~~
   drivers/gpu/drm/exynos/exynos_drm_dsi.c:1334:9: note: initialize the 
variable 'ret' to silence this warning
   int ret;
  ^
   = 0
   1 warning generated.


vim +1338 drivers/gpu/drm/exynos/exynos_drm_dsi.c

  1330  
  1331  static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
  1332struct device *panel)
  1333  {
  1334  int ret;
  1335  int te_gpio_irq;
  1336  
  1337  dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", 
GPIOD_IN);
> 1338  if (IS_ERR(dsi->te_gpio)) {
  1339  dev_err(dsi->dev, "gpio request failed with %ld\n",
  1340  PTR_ERR(dsi->te_gpio));
  1341  goto out;
  1342  }
  1343  
  1344  te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
  1345  
  1346  ret = request_threaded_irq(te_gpio_irq, 
exynos_dsi_te_irq_handler, NULL,
  1347 IRQF_TRIGGER_RISING | 
IRQF_NO_AUTOEN, "TE", dsi);
  1348  if (ret) {
  1349  dev_err(dsi->dev, "request interrupt failed with %d\n", 
ret);
  1350  gpiod_put(dsi->te_gpio);
  1351  goto out;
  1352  }
  1353  
  1354  out:
  1355  return ret;
  1356  }
  1357  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

Hi Marek,

On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
 wrote:
>
> On 22.11.2021 08:06, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output, those
> > can have an option to connect the DSI host by means of interface
> > bridge converter.
> >
> > This DSI to non-DSI interface bridge converter would requires
> > DSI Host to handle drm bridge functionalities in order to DSI
> > Host to Interface bridge.
> >
> > This patch convert the existing to a drm bridge driver with a
> > built-in encoder support for compatibility with existing
> > component drivers.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> > Note:
> > Hi Marek Szyprowski,
> >
> > Please test this on Panel and Bridge hardware.
>
> I don't have good news, t crashes:
>
> [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
> exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
> exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
> exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
> [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /soc@0/dsi@1390 to encoder TMDS-67: -22
> exynos-drm exynos-drm: failed to bind 1390.dsi (ops
> exynos_dsi_component_ops): -22
> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
> Hardware name: Samsung TM2E board (DT)
> Workqueue: events_unbound deferred_probe_work_func
> pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : decon_atomic_disable+0x58/0xd4
> lr : decon_atomic_disable+0x28/0xd4
> sp : 80001390b940
> x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
> input: stmfts as
> /devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
> x26: ffea x25: 25a40280 x24: 0001
> x23: 800011b55f98 x22: 315dc000 x21: 2695d100
> x20: 27e7a080 x19: 315e6000 x18: 
> x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
> x14: 0028 x13: 0001 x12: 0040
> x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
> x8 : 23c00270 x7 :  x6 : 23c00268
> x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
> x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
> Call trace:
>   decon_atomic_disable+0x58/0xd4
>   decon_unbind+0x1c/0x3c
>   component_unbind+0x38/0x60
>   component_bind_all+0x16c/0x25c
>   exynos_drm_bind+0x104/0x1bc
>   try_to_bring_up_master+0x164/0x1d0
>   __component_add+0xa8/0x174
>   component_add+0x14/0x20
>   hdmi_probe+0x438/0x710
>   platform_probe+0x68/0xe0
>   really_probe.part.0+0x9c/0x31c
>   __driver_probe_device+0x98/0x144
>   driver_probe_device+0xc8/0x160
>   __device_attach_driver+0xb8/0x120
>   bus_for_each_drv+0x78/0xd0
>   __device_attach+0xd8/0x180
>   device_initial_probe+0x14/0x20
>   bus_probe_device+0x9c/0xa4
>   deferred_probe_work_func+0x88/0xc4
>   process_one_work+0x288/0x6f0
>   worker_thread+0x74/0x470
>   kthread+0x188/0x194
>   ret_from_fork+0x10/0x20
> Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
> ---[ end trace d73aff585b108954 ]---
> Kernel panic - not syncing: synchronous external abort: Fatal exception
> SMP: stopping secondary CPUs
> Kernel Offset: disabled
> CPU features: 0x2,300071c2,0846
> Memory Limit: none
> ---[ end Kernel panic - not syncing: synchronous external abort: Fatal
> exception ]---

Is this with Bridge or normal DSI panel?

Jagan.

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

Hi Marek,

On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki  wrote:
>
> Hi Marek,
>
> On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
>  wrote:
> >
> > On 22.11.2021 08:06, Jagan Teki wrote:
> > > Some display panels would come up with a non-DSI output, those
> > > can have an option to connect the DSI host by means of interface
> > > bridge converter.
> > >
> > > This DSI to non-DSI interface bridge converter would requires
> > > DSI Host to handle drm bridge functionalities in order to DSI
> > > Host to Interface bridge.
> > >
> > > This patch convert the existing to a drm bridge driver with a
> > > built-in encoder support for compatibility with existing
> > > component drivers.
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > > Note:
> > > Hi Marek Szyprowski,
> > >
> > > Please test this on Panel and Bridge hardware.
> >
> > I don't have good news, t crashes:
> >
> > [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
> > exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
> > exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
> > exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
> > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc@0/dsi@1390 to encoder TMDS-67: -22
> > exynos-drm exynos-drm: failed to bind 1390.dsi (ops
> > exynos_dsi_component_ops): -22
> > Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
> > Hardware name: Samsung TM2E board (DT)
> > Workqueue: events_unbound deferred_probe_work_func
> > pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : decon_atomic_disable+0x58/0xd4
> > lr : decon_atomic_disable+0x28/0xd4
> > sp : 80001390b940
> > x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
> > input: stmfts as
> > /devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
> > x26: ffea x25: 25a40280 x24: 0001
> > x23: 800011b55f98 x22: 315dc000 x21: 2695d100
> > x20: 27e7a080 x19: 315e6000 x18: 
> > x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
> > x14: 0028 x13: 0001 x12: 0040
> > x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
> > x8 : 23c00270 x7 :  x6 : 23c00268
> > x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
> > x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
> > Call trace:
> >   decon_atomic_disable+0x58/0xd4
> >   decon_unbind+0x1c/0x3c
> >   component_unbind+0x38/0x60
> >   component_bind_all+0x16c/0x25c
> >   exynos_drm_bind+0x104/0x1bc
> >   try_to_bring_up_master+0x164/0x1d0
> >   __component_add+0xa8/0x174
> >   component_add+0x14/0x20
> >   hdmi_probe+0x438/0x710
> >   platform_probe+0x68/0xe0
> >   really_probe.part.0+0x9c/0x31c
> >   __driver_probe_device+0x98/0x144
> >   driver_probe_device+0xc8/0x160
> >   __device_attach_driver+0xb8/0x120
> >   bus_for_each_drv+0x78/0xd0
> >   __device_attach+0xd8/0x180
> >   device_initial_probe+0x14/0x20
> >   bus_probe_device+0x9c/0xa4
> >   deferred_probe_work_func+0x88/0xc4
> >   process_one_work+0x288/0x6f0
> >   worker_thread+0x74/0x470
> >   kthread+0x188/0x194
> >   ret_from_fork+0x10/0x20
> > Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
> > ---[ end trace d73aff585b108954 ]---
> > Kernel panic - not syncing: synchronous external abort: Fatal exception
> > SMP: stopping secondary CPUs
> > Kernel Offset: disabled
> > CPU features: 0x2,300071c2,0846
> > Memory Limit: none
> > ---[ end Kernel panic - not syncing: synchronous external abort: Fatal
> > exception ]---
>
> Is this with Bridge or normal DSI panel?

Can you apply this patch and check?
https://github.com/openedev/linux/commit/412f226acd774356e8188c9e62b653672926ee0d

Jagan.

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard  wrote:
>
> On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > It's perfectly valid to dereference the pointer in atomic_enable, and
> > > that patch would consume memory for no particular reason.
> >
> > Again, I'm not pointing any mistake in dereference and certainly not
> > understand about what memory consumption issue here.
>
> You add a struct drm_display_mode field to struct sun6i_dsi. It
> increases the size of struct sun6i_dsi of sizeof(struct
> drm_display_mode).
>
> > I'm doing it here since I'm doing it via mode_set in other drivers. No
> > problem for me either way.
>
> But *why* are you doing so?
>
> There might be a valid reason in other drivers, but there's none here
> (that you mentioned at least).

The reason is to use existing bridge function instead of dereference
ie what I've mentioned. I don't have any other reasons.

Jagan.

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

2021-11-22 Thread Fabio Estevam

Hi Jagan,

On Mon, Nov 22, 2021 at 11:21 AM Jagan Teki  wrote:

> Is this with Bridge or normal DSI panel?

According to the log shared by Marek, the dts being used is:
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
which includes arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi.

In this dtsi there is a "sil,sii8620" bridge.

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

Hi Jagan,

On 22.11.2021 15:21, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
>  wrote:
>> On 22.11.2021 08:06, Jagan Teki wrote:
>>> Some display panels would come up with a non-DSI output, those
>>> can have an option to connect the DSI host by means of interface
>>> bridge converter.
>>>
>>> This DSI to non-DSI interface bridge converter would requires
>>> DSI Host to handle drm bridge functionalities in order to DSI
>>> Host to Interface bridge.
>>>
>>> This patch convert the existing to a drm bridge driver with a
>>> built-in encoder support for compatibility with existing
>>> component drivers.
>>>
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Note:
>>> Hi Marek Szyprowski,
>>>
>>> Please test this on Panel and Bridge hardware.
>> I don't have good news, t crashes:
>>
>> [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
>> exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
>> exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
>> exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
>> [drm:drm_bridge_attach] *ERROR* failed to attach bridge
>> /soc@0/dsi@1390 to encoder TMDS-67: -22
>> exynos-drm exynos-drm: failed to bind 1390.dsi (ops
>> exynos_dsi_component_ops): -22
>> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
>> Hardware name: Samsung TM2E board (DT)
>> Workqueue: events_unbound deferred_probe_work_func
>> pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : decon_atomic_disable+0x58/0xd4
>> lr : decon_atomic_disable+0x28/0xd4
>> sp : 80001390b940
>> x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
>> input: stmfts as
>> /devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
>> x26: ffea x25: 25a40280 x24: 0001
>> x23: 800011b55f98 x22: 315dc000 x21: 2695d100
>> x20: 27e7a080 x19: 315e6000 x18: 
>> x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
>> x14: 0028 x13: 0001 x12: 0040
>> x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
>> x8 : 23c00270 x7 :  x6 : 23c00268
>> x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
>> x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
>> Call trace:
>>decon_atomic_disable+0x58/0xd4
>>decon_unbind+0x1c/0x3c
>>component_unbind+0x38/0x60
>>component_bind_all+0x16c/0x25c
>>exynos_drm_bind+0x104/0x1bc
>>try_to_bring_up_master+0x164/0x1d0
>>__component_add+0xa8/0x174
>>component_add+0x14/0x20
>>hdmi_probe+0x438/0x710
>>platform_probe+0x68/0xe0
>>really_probe.part.0+0x9c/0x31c
>>__driver_probe_device+0x98/0x144
>>driver_probe_device+0xc8/0x160
>>__device_attach_driver+0xb8/0x120
>>bus_for_each_drv+0x78/0xd0
>>__device_attach+0xd8/0x180
>>device_initial_probe+0x14/0x20
>>bus_probe_device+0x9c/0xa4
>>deferred_probe_work_func+0x88/0xc4
>>process_one_work+0x288/0x6f0
>>worker_thread+0x74/0x470
>>kthread+0x188/0x194
>>ret_from_fork+0x10/0x20
>> Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
>> ---[ end trace d73aff585b108954 ]---
>> Kernel panic - not syncing: synchronous external abort: Fatal exception
>> SMP: stopping secondary CPUs
>> Kernel Offset: disabled
>> CPU features: 0x2,300071c2,0846
>> Memory Limit: none
>> ---[ end Kernel panic - not syncing: synchronous external abort: Fatal
>> exception ]---
> Is this with Bridge or normal DSI panel?

This log is from the TM2e board 
(arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts) with a normal DSI panel 
and Exynos MIC bridge between Exynos Decon and Exynos DSI.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

On 22.11.2021 15:40, Fabio Estevam wrote:
> Hi Jagan,
>
> On Mon, Nov 22, 2021 at 11:21 AM Jagan Teki  
> wrote:
>
>> Is this with Bridge or normal DSI panel?
> According to the log shared by Marek, the dts being used is:
>   arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> which includes arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi.
>
> In this dtsi there is a "sil,sii8620" bridge.

Sii8620 bridge is attached to the HDMI display path. That's completely 
different from the DSI display path modified by this patchset.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 2/2] drm/i915: Use to_root_gt() to refer to the root tile

Hi Andi,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-2028]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.16-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/More-preparation-for-multi-gt-patches/20211121-213526
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-c007-20211121 (attached as .config)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/068a75571292e317e35752c1b078605dda122741
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Andi-Shyti/More-preparation-for-multi-gt-patches/20211121-213526
git checkout 068a75571292e317e35752c1b078605dda122741
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from :4:
   In file included from drivers/gpu/drm/i915/display/intel_de.h:9:
>> drivers/gpu/drm/i915/i915_drv.h:1756:1: error: all paths through this 
>> function will call itself [-Werror,-Winfinite-recursion]
   {
   ^
   1 error generated.
--
   In file included from drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:12:
>> drivers/gpu/drm/i915/i915_drv.h:1756:1: error: all paths through this 
>> function will call itself [-Werror,-Winfinite-recursion]
   {
   ^
   drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:59:6: error: no previous 
prototype for function 'intel_pxp_debugfs_register' 
[-Werror,-Wmissing-prototypes]
   void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry 
*gt_root)
^
   drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:59:1: note: declare 'static' if 
the function is not intended to be used outside of this translation unit
   void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct dentry 
*gt_root)
   ^
   static 
   2 errors generated.
--
   In file included from drivers/gpu/drm/i915/pxp/intel_pxp_tee.c:11:
>> drivers/gpu/drm/i915/i915_drv.h:1756:1: error: all paths through this 
>> function will call itself [-Werror,-Winfinite-recursion]
   {
   ^
>> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c:19:35: error: no member named 'gt' 
>> in 'struct drm_i915_private'
   return &kdev_to_i915(i915_kdev)->gt.pxp;
   ~~~  ^
   2 errors generated.
--
   In file included from drivers/gpu/drm/i915/selftests/igt_reset.c:12:
>> drivers/gpu/drm/i915/selftests/../i915_drv.h:1756:1: error: all paths 
>> through this function will call itself [-Werror,-Winfinite-recursion]
   {
   ^
   1 error generated.


vim +1756 drivers/gpu/drm/i915/i915_drv.h

  1750  
  1751  /* Only valid when HAS_DISPLAY() is true */
  1752  #define INTEL_DISPLAY_ENABLED(dev_priv) \
  1753  (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)), 
!(dev_priv)->params.disable_display)
  1754  
  1755  static inline struct intel_gt *to_root_gt(struct drm_i915_private *i915)
> 1756  {
  1757  return to_root_gt(i915);
  1758  }
  1759  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125

2021-11-22 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=205089

--- Comment #26 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Hristos from comment #25)
> Kernel: 5.15.3
> Mesa: 21.2.5
> Xorg: 7.6
> 
> I see this when running OpenMW and a lot of mods
> (https://modding-openmw.com/lists/total-overhaul/). OpenMW with no mods or a
> smaller mod list seems to run fine.
> 
> When the program starts rendering the actual game scene (after loading data
> files and etc) it will hang, and then crash with "Failed to initialize
> parser -125" messages in the console. 
> 
> It only happens with Mesa 21.2.X, though. When I downgraded to Mesa 21.1.7
> everything ran as expected.

This sounds like a mesa issue.  You might want to open a mesa issue:
https://gitlab.freedesktop.org/groups/mesa/-/issues

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH 1/2] dt-bindings: display: Turn lvds.yaml into a generic schema

Hi,

On Sat, Nov 20, 2021 at 12:46:33AM +0200, Laurent Pinchart wrote:
> On Tue, Nov 16, 2021 at 03:35:02PM +0100, Maxime Ripard wrote:
> > The lvds.yaml file so far was both defining the generic LVDS properties
> > (such as data-mapping) that could be used for any LVDS sink, but also
> > the panel-lvds binding.
> > 
> > That last binding was to describe LVDS panels simple enough, and had a
> > number of other bindings using it as a base to specialise it further.
> > 
> > However, this situation makes it fairly hard to extend and reuse both
> > the generic parts, and the panel-lvds itself.
> > 
> > Let's remove the panel-lvds parts and leave only the generic LVDS
> > properties.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../display/panel/advantech,idk-1110wr.yaml   | 17 ++-
> >  .../display/panel/innolux,ee101ia-01d.yaml| 21 +-
> >  .../bindings/display/panel/lvds.yaml  | 29 +--
> >  .../display/panel/mitsubishi,aa104xd12.yaml   | 17 ++-
> >  .../display/panel/mitsubishi,aa121td01.yaml   | 17 ++-
> >  .../display/panel/sgd,gktw70sdae4se.yaml  | 17 ++-
> >  6 files changed, 85 insertions(+), 33 deletions(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml 
> > b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> > index 93878c2cd370..f27cd2038636 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> > @@ -11,13 +11,23 @@ maintainers:
> >- Thierry Reding 
> >  
> >  allOf:
> > +  - $ref: panel-common.yaml#
> >- $ref: lvds.yaml#
> >  
> > +select:
> > +  properties:
> > +compatible:
> > +  contains:
> > +const: advantech,idk-1110wr
> > +
> > +  required:
> > +- compatible
> 
> I've never encountered this before, what does it do ?

select dictates if the schema is applied to a node or not.

It takes a schema, and if this schema is valid, the rest of the schema
will be applied to the current node.

It's mostly unused in the kernel because the dt-validate tool will add a
select clause from the compatible list in most case that would expand in
this case to:

select:
  properties:
contains:
  enum:
- advantech,idk-1110wr
- panel-lvds

  required:
- compatible

ie, it tries to validate with this schema any node that has either the
panel compatible or the generic compatible.

That means we would have that schema applied to all the nodes that have
panel-lvds, including the ones with a different compatible than the
advantech one.

With this clause, we make sure that we ignore the other panels, while
ensuring that the compatible list for the advantech compatible is
correct.

> > +
> >  properties:
> >compatible:
> >  items:
> >- const: advantech,idk-1110wr
> > -  - {} # panel-lvds, but not listed here to avoid false select
> > +  - const: panel-lvds
> >  
> >data-mapping:
> >  const: jeida-24
> > @@ -35,6 +45,11 @@ additionalProperties: false
> >  
> >  required:
> >- compatible
> > +  - data-mapping
> > +  - width-mm
> > +  - height-mm
> > +  - panel-timing
> > +  - port
> >  
> >  examples:
> >- |+
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml 
> > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
> > index a69681e724cb..6e06eecac14e 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
> > @@ -11,15 +11,26 @@ maintainers:
> >- Thierry Reding 
> >  
> >  allOf:
> > +  - $ref: panel-common.yaml#
> >- $ref: lvds.yaml#
> >  
> > +select:
> > +  properties:
> > +compatible:
> > +  contains:
> > +const: innolux,ee101ia-01d
> > +
> > +  required:
> > +- compatible
> > +
> >  properties:
> >compatible:
> >  items:
> >- const: innolux,ee101ia-01d
> > -  - {} # panel-lvds, but not listed here to avoid false select
> > +  - const: panel-lvds
> >  
> >backlight: true
> > +  data-mapping: true
> >enable-gpios: true
> >power-supply: true
> >width-mm: true
> > @@ -27,5 +38,13 @@ properties:
> >panel-timing: true
> >port: true
> >  
> > +required:
> > +  - compatible
> > +  - data-mapping
> > +  - width-mm
> > +  - height-mm
> > +  - panel-timing
> > +  - port
> > +
> >  additionalProperties: false
> >  ...
> > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
> > b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > index 49460c9dceea..5281a75c8bb5 100644
> > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > @@ -4,7 +4,7 @@
> >  $id: http://devicetree.org/s

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

Hi Marek,

On Mon, Nov 22, 2021 at 7:59 PM Jagan Teki  wrote:
>
> Hi Marek,
>
> On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki  wrote:
> >
> > Hi Marek,
> >
> > On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
> >  wrote:
> > >
> > > On 22.11.2021 08:06, Jagan Teki wrote:
> > > > Some display panels would come up with a non-DSI output, those
> > > > can have an option to connect the DSI host by means of interface
> > > > bridge converter.
> > > >
> > > > This DSI to non-DSI interface bridge converter would requires
> > > > DSI Host to handle drm bridge functionalities in order to DSI
> > > > Host to Interface bridge.
> > > >
> > > > This patch convert the existing to a drm bridge driver with a
> > > > built-in encoder support for compatibility with existing
> > > > component drivers.
> > > >
> > > > Signed-off-by: Jagan Teki 
> > > > ---
> > > > Note:
> > > > Hi Marek Szyprowski,
> > > >
> > > > Please test this on Panel and Bridge hardware.
> > >
> > > I don't have good news, t crashes:
> > >
> > > [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
> > > exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
> > > exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
> > > exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
> > > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > > /soc@0/dsi@1390 to encoder TMDS-67: -22
> > > exynos-drm exynos-drm: failed to bind 1390.dsi (ops
> > > exynos_dsi_component_ops): -22
> > > Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> > > Modules linked in:
> > > CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
> > > Hardware name: Samsung TM2E board (DT)
> > > Workqueue: events_unbound deferred_probe_work_func
> > > pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > pc : decon_atomic_disable+0x58/0xd4
> > > lr : decon_atomic_disable+0x28/0xd4
> > > sp : 80001390b940
> > > x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
> > > input: stmfts as
> > > /devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
> > > x26: ffea x25: 25a40280 x24: 0001
> > > x23: 800011b55f98 x22: 315dc000 x21: 2695d100
> > > x20: 27e7a080 x19: 315e6000 x18: 
> > > x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
> > > x14: 0028 x13: 0001 x12: 0040
> > > x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
> > > x8 : 23c00270 x7 :  x6 : 23c00268
> > > x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
> > > x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
> > > Call trace:
> > >   decon_atomic_disable+0x58/0xd4
> > >   decon_unbind+0x1c/0x3c
> > >   component_unbind+0x38/0x60
> > >   component_bind_all+0x16c/0x25c
> > >   exynos_drm_bind+0x104/0x1bc
> > >   try_to_bring_up_master+0x164/0x1d0
> > >   __component_add+0xa8/0x174
> > >   component_add+0x14/0x20
> > >   hdmi_probe+0x438/0x710
> > >   platform_probe+0x68/0xe0
> > >   really_probe.part.0+0x9c/0x31c
> > >   __driver_probe_device+0x98/0x144
> > >   driver_probe_device+0xc8/0x160
> > >   __device_attach_driver+0xb8/0x120
> > >   bus_for_each_drv+0x78/0xd0
> > >   __device_attach+0xd8/0x180
> > >   device_initial_probe+0x14/0x20
> > >   bus_probe_device+0x9c/0xa4
> > >   deferred_probe_work_func+0x88/0xc4
> > >   process_one_work+0x288/0x6f0
> > >   worker_thread+0x74/0x470
> > >   kthread+0x188/0x194
> > >   ret_from_fork+0x10/0x20
> > > Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
> > > ---[ end trace d73aff585b108954 ]---
> > > Kernel panic - not syncing: synchronous external abort: Fatal exception
> > > SMP: stopping secondary CPUs
> > > Kernel Offset: disabled
> > > CPU features: 0x2,300071c2,0846
> > > Memory Limit: none
> > > ---[ end Kernel panic - not syncing: synchronous external abort: Fatal
> > > exception ]---
> >
> > Is this with Bridge or normal DSI panel?
>
> Can you apply this patch and check?
> https://github.com/openedev/linux/commit/412f226acd774356e8188c9e62b653672926ee0d

Any news on this? just asking in case if you missed it.

Jagan.

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

On Mon, Nov 22, 2021 at 07:49:26PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:35 PM Maxime Ripard  wrote:
> > On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> > > On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard  wrote:
> > > >
> > > > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > > > Some display panels would come up with a non-DSI output, those
> > > > > can have an option to connect the DSI host by means of interface
> > > > > bridge converter.
> > > > >
> > > > > This DSI to non-DSI interface bridge converter would requires
> > > > > DSI Host to handle drm bridge functionalities in order to DSI
> > > > > Host to Interface bridge.
> > > >
> > > > In order to do this you would need to use the DRM bridge API...
> > >
> > > Sorry, which bridge API do you mean?
> >
> > Any variant of of_drm_find_bridge, and drm_bridge_attach. Just like
> > we're doing in sun4i_rgb.c
> 
> Yes, we have drm_bridge_attach in bind and bridge_function.attach
> calls in this patch and of_drm_find_bridge in sun6i_mipi_dsi_attach.
> Not sure which API's I've missed.

None, that's my point, you don't need anything else in order to do what
you wanted to achieve.

> >
> > > > > This patch convert the existing to a drm bridge driver with a
> > > > > built-in encoder support for compatibility with existing
> > > > > component drivers.
> > > >
> > > > ... but changing the encoder driver to a bridge is completely
> > > > unnecessary to do so. Why did you need to make that change?
> > >
> > > Idea of this series is to convert the driver to bridge and use the
> > > latest bridge function from the v1 series.
> >
> > Ok, but it's not at all what you mention in your commit log? You don't
> > need any of that in order to support a bridge downstream.
> 
> I've mentioned "Converting to bridge driver" and thought it has
> meaning of converting encoder related function to bridge functions as
> well. Not think about specific description to describe on commit
> message. Will update this.

But you provided no reason to do so. The only one you did mention was
that you wanted to support downstream bridges, but you don't need to
convert the DSI driver to a bridge in order to do that.

> > > > > Signed-off-by: Jagan Teki 
> > > > >
> > > > > ---
> > > > > Changes for v5:
> > > > > - add atomic APIs
> > > > > - find host and device variant DSI devices.
> > > > > Changes for v4, v3:
> > > > > - none
> > > > >
> > > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 
> > > > > -
> > > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> > > > >  2 files changed, 96 insertions(+), 23 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > index 43d9c9e5198d..a6a272b55f77 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > @@ -21,6 +21,7 @@
> > > > >
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi 
> > > > > *dsi,
> > > > >   return 0;
> > > > >  }
> > > > >
> > > > > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > > > > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > > > > +struct drm_bridge_state 
> > > > > *old_bridge_state)
> > > > >  {
> > > > > - struct drm_display_mode *mode = 
> > > > > &encoder->crtc->state->adjusted_mode;
> > > > > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > > > > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > > > > + struct drm_display_mode *mode = 
> > > > > &bridge->encoder->crtc->state->adjusted_mode;
> > > > >   struct mipi_dsi_device *device = dsi->device;
> > > > >   union phy_configure_opts opts = { };
> > > > >   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > > > > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > > > drm_encoder *encoder)
> > > > >   if (dsi->panel)
> > > > >   drm_panel_prepare(dsi->panel);
> > > > >
> > > > > + if (dsi->next_bridge)
> > > > > + 
> > > > > dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > > > > old_bridge_state);
> > > > > +
> > > >
> > > > Please use the proper helpers.
> > >
> > > If we use bridge_functions we need to take atomic functions as
> > > precedence as the next bridge functions might convert atomic calls.
> >
> > We've had this discussion over and over again, but this is something
> > that needs to be documented and / or in your commit log.
> >
> > You must not deviate from the standard (and expected) behavior without
> > any kind of justification.
> 
> Not exactly sure about what you mean, sorry. All these atomic bridge
> functions are already documented if I'm not wr

Re: [PATCH v4] drm/ttm: Clarify that the TTM_PL_SYSTEM is under TTMs control

2021-11-22 Thread Zack Rusin

On Mon, 2021-11-22 at 15:15 +0100, Christian König wrote:
> Am 16.11.21 um 16:53 schrieb Zack Rusin:
> > > On Nov 16, 2021, at 03:20, Christian König
> > >  wrote:
> > > 
> > > Am 16.11.21 um 08:43 schrieb Thomas Hellström:
> > > > On 11/16/21 08:19, Christian König wrote:
> > > > > Am 13.11.21 um 12:26 schrieb Thomas Hellström:
> > > > > > Hi, Zack,
> > > > > > 
> > > > > > On 11/11/21 17:44, Zack Rusin wrote:
> > > > > > > On Wed, 2021-11-10 at 09:50 -0500, Zack Rusin wrote:
> > > > > > > > TTM takes full control over TTM_PL_SYSTEM placed
> > > > > > > > buffers. This makes
> > > > > > > > driver internal usage of TTM_PL_SYSTEM prone to errors
> > > > > > > > because it
> > > > > > > > requires the drivers to manually handle all
> > > > > > > > interactions between TTM
> > > > > > > > which can swap out those buffers whenever it thinks
> > > > > > > > it's the right
> > > > > > > > thing to do and driver.
> > > > > > > > 
> > > > > > > > CPU buffers which need to be fenced and shared with
> > > > > > > > accelerators
> > > > > > > > should
> > > > > > > > be placed in driver specific placements that can
> > > > > > > > explicitly handle
> > > > > > > > CPU/accelerator buffer fencing.
> > > > > > > > Currently, apart, from things silently failing nothing
> > > > > > > > is enforcing
> > > > > > > > that requirement which means that it's easy for drivers
> > > > > > > > and new
> > > > > > > > developers to get this wrong. To avoid the confusion we
> > > > > > > > can document
> > > > > > > > this requirement and clarify the solution.
> > > > > > > > 
> > > > > > > > This came up during a discussion on dri-devel:
> > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F232f45e9-8748-1243-09bf-56763e6668b3%40amd.com&data=04%7C01%7Czackr%40vmware.com%7C084389d8acc04ffdbbb808d9adc28cfe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637731873379429725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ahHm7HV9VPAhfBKsk9xOBcnObsJXHvVAbCdEhJ%2BjJYU%3D&reserved=0
> > > > > > I took a slightly deeper look into this. I think we need to
> > > > > > formalize this a bit more to understand pros and cons and
> > > > > > what the restrictions are really all about. Anybody looking
> > > > > > at the prevous discussion will mostly see arguments similar
> > > > > > to "this is stupid and difficult" and "it has always been
> > > > > > this way" which are not really constructive.
> > > > > > 
> > > > > > First disregarding all accounting stuff, I think this all
> > > > > > boils down to TTM_PL_SYSTEM having three distinct states:
> > > > > > 1) POPULATED
> > > > > > 2) LIMBO (Or whatever we want to call it. No pages present)
> > > > > > 3) SWAPPED.
> > > > > > 
> > > > > > The ttm_bo_move_memcpy() helper understands these, and any
> > > > > > standalone driver implementation of the move() callback
> > > > > > _currently_ needs to understand these as well, unless using
> > > > > > the ttm_bo_move_memcpy() helper.
> > > > > > 
> > > > > > Now using a bounce domain to proxy SYSTEM means that the
> > > > > > driver can forget about the SWAPPED state, it's
> > > > > > automatically handled by the move setup code. However,
> > > > > > another pitfall is LIMBO, in that if when you move from
> > > > > > SYSTEM/LIMBO to your bounce domain, the BO will be
> > > > > > populated. So any naive accelerated move() implementation
> > > > > > creating a 1GB BO in fixed memory, like VRAM, will
> > > > > > needlessly allocate and free 1GB of system memory in the
> > > > > > process instead of just performing a clear operation. Looks
> > > > > > like amdgpu suffers from this?
> > > > > > 
> > > > > > I think what is really needed is either
> > > > > > 
> > > > > > a) A TTM helper that helps move callback implementations
> > > > > > resolve the issues populating system from LIMBO or SWAP,
> > > > > > and then also formalize driver notification for swapping.
> > > > > > At a minimum, I think the swap_notify() callback needs to
> > > > > > be able to return a late error.
> > > > > > 
> > > > > > b) Make LIMBO and SWAPPED distinct memory regions. (I think
> > > > > > I'd vote for this without looking into it in detail).
> > > > > > 
> > > > > > In both these cases, we should really make SYSTEM bindable
> > > > > > by GPU, otherwise we'd just be trading one pitfall for
> > > > > > another related without really resolving the root problem.
> > > > > > 
> > > > > > As for fencing not being supported by SYSTEM, I'm not sure
> > > > > > why we don't want this, because it would for example
> > > > > > prohibit async ttm_move_memcpy(), and also, async unbinding
> > > > > > of ttm_tt memory like MOB on vmgfx. (I think it's still
> > > > > > sync).
> > > > > > 
> > > > > > There might be an accounting issue related to this as well,
> > > > > > but I guess Christian would need to chime in on this. If
> > > > > > so, I think it needs to be well understood

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 08:01:47PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard  wrote:
> >
> > On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > > It's perfectly valid to dereference the pointer in atomic_enable, and
> > > > that patch would consume memory for no particular reason.
> > >
> > > Again, I'm not pointing any mistake in dereference and certainly not
> > > understand about what memory consumption issue here.
> >
> > You add a struct drm_display_mode field to struct sun6i_dsi. It
> > increases the size of struct sun6i_dsi of sizeof(struct
> > drm_display_mode).
> >
> > > I'm doing it here since I'm doing it via mode_set in other drivers. No
> > > problem for me either way.
> >
> > But *why* are you doing so?
> >
> > There might be a valid reason in other drivers, but there's none here
> > (that you mentioned at least).
> 
> The reason is to use existing bridge function instead of dereference
> ie what I've mentioned. I don't have any other reasons.

This discussion is going in circles. Unless you have a reason other than
"because we can", NAK for the reasons already stated above.

Maxime

Re: [PATCH v6 1/4] drm/i915: Avoid allocating a page array for the gpu coredump

2021-11-22 Thread Ramalingam C

On 2021-11-08 at 18:45:44 +0100, Thomas Hellström wrote:
> The gpu coredump typically takes place in a dma_fence signalling
> critical path, and hence can't use GFP_KERNEL allocations, as that
> means we might hit deadlocks under memory pressure. However
> changing to __GFP_KSWAPD_RECLAIM which will be done in an upcoming
> patch will instead mean a lower chance of the allocation succeeding.
> In particular large contigous allocations like the coredump page
> vector.
> Remove the page vector in favor of a linked list of single pages.
> Use the page lru list head as the list link, as the page owner is
> allowed to do that.
> 
> Signed-off-by: Thomas Hellström 

Looks good to me

Reviewed-by: Ramalingam C 

> ---
>  drivers/gpu/drm/i915/i915_gpu_error.c | 50 +++
>  drivers/gpu/drm/i915/i915_gpu_error.h |  4 +--
>  2 files changed, 28 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 2a2d7643b551..14de64282697 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -275,16 +275,16 @@ static bool compress_start(struct i915_vma_compress *c)
>  static void *compress_next_page(struct i915_vma_compress *c,
>   struct i915_vma_coredump *dst)
>  {
> - void *page;
> + void *page_addr;
> + struct page *page;
>  
> - if (dst->page_count >= dst->num_pages)
> - return ERR_PTR(-ENOSPC);
> -
> - page = pool_alloc(&c->pool, ALLOW_FAIL);
> - if (!page)
> + page_addr = pool_alloc(&c->pool, ALLOW_FAIL);
> + if (!page_addr)
>   return ERR_PTR(-ENOMEM);
>  
> - return dst->pages[dst->page_count++] = page;
> + page = virt_to_page(page_addr);
> + list_add_tail(&page->lru, &dst->page_list);
> + return page_addr;
>  }
>  
>  static int compress_page(struct i915_vma_compress *c,
> @@ -397,7 +397,7 @@ static int compress_page(struct i915_vma_compress *c,
>  
>   if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
>   memcpy(ptr, src, PAGE_SIZE);
> - dst->pages[dst->page_count++] = ptr;
> + list_add_tail(&virt_to_page(ptr)->lru, &dst->page_list);
>   cond_resched();
>  
>   return 0;
> @@ -614,7 +614,7 @@ static void print_error_vma(struct 
> drm_i915_error_state_buf *m,
>   const struct i915_vma_coredump *vma)
>  {
>   char out[ASCII85_BUFSZ];
> - int page;
> + struct page *page;
>  
>   if (!vma)
>   return;
> @@ -628,16 +628,17 @@ static void print_error_vma(struct 
> drm_i915_error_state_buf *m,
>   err_printf(m, "gtt_page_sizes = 0x%08x\n", vma->gtt_page_sizes);
>  
>   err_compression_marker(m);
> - for (page = 0; page < vma->page_count; page++) {
> + list_for_each_entry(page, &vma->page_list, lru) {
>   int i, len;
> + const u32 *addr = page_address(page);
>  
>   len = PAGE_SIZE;
> - if (page == vma->page_count - 1)
> + if (page == list_last_entry(&vma->page_list, typeof(*page), 
> lru))
>   len -= vma->unused;
>   len = ascii85_encode_len(len);
>  
>   for (i = 0; i < len; i++)
> - err_puts(m, ascii85_encode(vma->pages[page][i], out));
> + err_puts(m, ascii85_encode(addr[i], out));
>   }
>   err_puts(m, "\n");
>  }
> @@ -946,10 +947,12 @@ static void i915_vma_coredump_free(struct 
> i915_vma_coredump *vma)
>  {
>   while (vma) {
>   struct i915_vma_coredump *next = vma->next;
> - int page;
> + struct page *page, *n;
>  
> - for (page = 0; page < vma->page_count; page++)
> - free_page((unsigned long)vma->pages[page]);
> + list_for_each_entry_safe(page, n, &vma->page_list, lru) {
> + list_del_init(&page->lru);
> + __free_page(page);
> + }
>  
>   kfree(vma);
>   vma = next;
> @@ -1016,7 +1019,6 @@ i915_vma_coredump_create(const struct intel_gt *gt,
>   struct i915_ggtt *ggtt = gt->ggtt;
>   const u64 slot = ggtt->error_capture.start;
>   struct i915_vma_coredump *dst;
> - unsigned long num_pages;
>   struct sgt_iter iter;
>   int ret;
>  
> @@ -1025,9 +1027,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
>   if (!vma || !vma->pages || !compress)
>   return NULL;
>  
> - num_pages = min_t(u64, vma->size, vma->obj->base.size) >> PAGE_SHIFT;
> - num_pages = DIV_ROUND_UP(10 * num_pages, 8); /* worstcase zlib growth */
> - dst = kmalloc(sizeof(*dst) + num_pages * sizeof(u32 *), ALLOW_FAIL);
> + dst = kmalloc(sizeof(*dst), ALLOW_FAIL);
>   if (!dst)
>   return NULL;
>  
> @@ -1036,14 +1036,13 @@ i915_vma_coredump_create(const struct intel_gt *gt,
>   return NULL;
>   }

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

On 22.11.2021 15:55, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:59 PM Jagan Teki  wrote:
>> On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki  
>> wrote:
>>> On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
>>>  wrote:
 On 22.11.2021 08:06, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
>
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge functionalities in order to DSI
> Host to Interface bridge.
>
> This patch convert the existing to a drm bridge driver with a
> built-in encoder support for compatibility with existing
> component drivers.
>
> Signed-off-by: Jagan Teki 
> ---
> Note:
> Hi Marek Szyprowski,
>
> Please test this on Panel and Bridge hardware.
 I don't have good news, t crashes:

 [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
 exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
 exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
 exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
 [drm:drm_bridge_attach] *ERROR* failed to attach bridge
 /soc@0/dsi@1390 to encoder TMDS-67: -22
 exynos-drm exynos-drm: failed to bind 1390.dsi (ops
 exynos_dsi_component_ops): -22
 Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
 Modules linked in:
 CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
 Hardware name: Samsung TM2E board (DT)
 Workqueue: events_unbound deferred_probe_work_func
 pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : decon_atomic_disable+0x58/0xd4
 lr : decon_atomic_disable+0x28/0xd4
 sp : 80001390b940
 x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
 input: stmfts as
 /devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
 x26: ffea x25: 25a40280 x24: 0001
 x23: 800011b55f98 x22: 315dc000 x21: 2695d100
 x20: 27e7a080 x19: 315e6000 x18: 
 x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
 x14: 0028 x13: 0001 x12: 0040
 x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
 x8 : 23c00270 x7 :  x6 : 23c00268
 x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
 x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
 Call trace:
decon_atomic_disable+0x58/0xd4
decon_unbind+0x1c/0x3c
component_unbind+0x38/0x60
component_bind_all+0x16c/0x25c
exynos_drm_bind+0x104/0x1bc
try_to_bring_up_master+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x14/0x20
hdmi_probe+0x438/0x710
platform_probe+0x68/0xe0
really_probe.part.0+0x9c/0x31c
__driver_probe_device+0x98/0x144
driver_probe_device+0xc8/0x160
__device_attach_driver+0xb8/0x120
bus_for_each_drv+0x78/0xd0
__device_attach+0xd8/0x180
device_initial_probe+0x14/0x20
bus_probe_device+0x9c/0xa4
deferred_probe_work_func+0x88/0xc4
process_one_work+0x288/0x6f0
worker_thread+0x74/0x470
kthread+0x188/0x194
ret_from_fork+0x10/0x20
 Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
 ---[ end trace d73aff585b108954 ]---
 Kernel panic - not syncing: synchronous external abort: Fatal exception
 SMP: stopping secondary CPUs
 Kernel Offset: disabled
 CPU features: 0x2,300071c2,0846
 Memory Limit: none
 ---[ end Kernel panic - not syncing: synchronous external abort: Fatal
 exception ]---
>>> Is this with Bridge or normal DSI panel?
>> Can you apply this patch and check?
>> https://protect2.fireeye.com/v1/url?k=aad62f08-f54d1627-aad7a447-0cc47a31cdf8-ea5858ddb7f0ecfe&q=1&e=2d730862-2c56-4988-a252-8febd02da578&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Flinux%2Fcommit%2F412f226acd774356e8188c9e62b653672926ee0d
> Any news on this? just asking in case if you missed it.

It is somehow better. System doesn't crash, but the DRM is not bound:

# cat /sys/kernel/debug/device_component/exynos-drm
master name    status
-
exynos-drm  not bound

device name    status
-
1380.decon  not bound
1388.decon  not bound
1393.mic    not bound
(unknown)

Re: [PATCH 01/15] iio: buffer-dma: Get rid of incoming/outgoing queues

2021-11-22 Thread Lars-Peter Clausen


On 11/21/21 9:08 PM, Paul Cercueil wrote:



Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 6:52 PM, Paul Cercueil wrote:

Hi Lars,

Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen 
 a écrit :

On 11/15/21 3:19 PM, Paul Cercueil wrote:

The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much easier to
just check each block's state manually, and keep a counter for the 
next

block to dequeue.

Since the new DMABUF based API wouldn't use these incoming and 
outgoing

queues anyway, getting rid of them now makes the upcoming changes
simpler.

Signed-off-by: Paul Cercueil 
The outgoing queue is going to be replaced by fences, but I think 
we need to keep the incoming queue.


Blocks are always accessed in sequential order, so we now have a 
"queue->next_dequeue" that cycles between the buffers allocated for 
fileio.



[...]
@@ -442,28 +435,33 @@ EXPORT_SYMBOL_GPL(iio_dma_buffer_disable);
  static void iio_dma_buffer_enqueue(struct iio_dma_buffer_queue 
*queue,

  struct iio_dma_buffer_block *block)
  {
-    if (block->state == IIO_BLOCK_STATE_DEAD) {
+    if (block->state == IIO_BLOCK_STATE_DEAD)
  iio_buffer_block_put(block);
-    } else if (queue->active) {
+    else if (queue->active)
  iio_dma_buffer_submit_block(queue, block);
-    } else {
+    else
  block->state = IIO_BLOCK_STATE_QUEUED;
-    list_add_tail(&block->head, &queue->incoming);
If iio_dma_buffer_enqueue() is called with a dmabuf and the buffer 
is not active, it will be marked as queued, but we don't actually 
keep a reference to it anywhere. It will never be submitted to 
the DMA, and it will never be signaled as completed.


We do keep a reference to the buffers, in the queue->fileio.blocks 
array. When the buffer is enabled, all the blocks in that array 
that are in the "queued" state will be submitted to the DMA.


But not when used in combination with the DMA buf changes later in 
this series.




That's still the case after the DMABUF changes of the series. Or can 
you point me exactly what you think is broken?


When you allocate a DMABUF with the allocate IOCTL and then submit it 
with the enqueue IOCTL before the buffer is enabled it will end up 
marked as queued, but not actually be queued anywhere.

Re: [PATCH 01/15] iio: buffer-dma: Get rid of incoming/outgoing queues

2021-11-22 Thread Paul Cercueil


Hi Lars,

Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 9:08 PM, Paul Cercueil wrote:



Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 6:52 PM, Paul Cercueil wrote:

Hi Lars,

Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen 
 a écrit :

On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and outgoing, 
to

manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much 
easier to
just check each block's state manually, and keep a counter for 
the next

block to dequeue.

Since the new DMABUF based API wouldn't use these incoming and 
outgoing

queues anyway, getting rid of them now makes the upcoming changes
simpler.

Signed-off-by: Paul Cercueil 
The outgoing queue is going to be replaced by fences, but I think 
we need to keep the incoming queue.


Blocks are always accessed in sequential order, so we now have a 
"queue->next_dequeue" that cycles between the buffers 
allocated for fileio.



[...]
@@ -442,28 +435,33 @@ EXPORT_SYMBOL_GPL(iio_dma_buffer_disable);
  static void iio_dma_buffer_enqueue(struct iio_dma_buffer_queue 
*queue,

  struct iio_dma_buffer_block *block)
  {
-if (block->state == IIO_BLOCK_STATE_DEAD) {
+if (block->state == IIO_BLOCK_STATE_DEAD)
  iio_buffer_block_put(block);
-} else if (queue->active) {
+else if (queue->active)
  iio_dma_buffer_submit_block(queue, block);
-} else {
+else
  block->state = IIO_BLOCK_STATE_QUEUED;
-list_add_tail(&block->head, &queue->incoming);
If iio_dma_buffer_enqueue() is called with a dmabuf and the 
buffer is not active, it will be marked as queued, but we 
don't actually keep a reference to it anywhere. It will 
never be submitted to the DMA, and it will never be 
signaled as completed.


We do keep a reference to the buffers, in the queue->fileio.blocks 
array. When the buffer is enabled, all the blocks in that 
array that are in the "queued" state will be submitted to the 
DMA.


But not when used in combination with the DMA buf changes later in 
this series.




That's still the case after the DMABUF changes of the series. Or can 
you point me exactly what you think is broken?


When you allocate a DMABUF with the allocate IOCTL and then submit it 
with the enqueue IOCTL before the buffer is enabled it will end up 
marked as queued, but not actually be queued anywhere.




Ok, it works for me because I never enqueue blocks before enabling the 
buffer. I can add a requirement that blocks must be enqueued only after 
the buffer is enabled.


Cheers,
-Paul

Re: [PATCH 01/15] iio: buffer-dma: Get rid of incoming/outgoing queues

2021-11-22 Thread Lars-Peter Clausen


On 11/22/21 4:16 PM, Paul Cercueil wrote:

Hi Lars,

Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 9:08 PM, Paul Cercueil wrote:



Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 6:52 PM, Paul Cercueil wrote:

Hi Lars,

Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen 
 a écrit :

On 11/15/21 3:19 PM, Paul Cercueil wrote:

The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much 
easier to
just check each block's state manually, and keep a counter for 
the next

block to dequeue.

Since the new DMABUF based API wouldn't use these incoming and 
outgoing

queues anyway, getting rid of them now makes the upcoming changes
simpler.

Signed-off-by: Paul Cercueil 
The outgoing queue is going to be replaced by fences, but I think 
we need to keep the incoming queue.


Blocks are always accessed in sequential order, so we now have a 
"queue->next_dequeue" that cycles between the buffers 
allocated for fileio.



[...]
@@ -442,28 +435,33 @@ EXPORT_SYMBOL_GPL(iio_dma_buffer_disable);
  static void iio_dma_buffer_enqueue(struct iio_dma_buffer_queue 
*queue,

  struct iio_dma_buffer_block *block)
  {
-    if (block->state == IIO_BLOCK_STATE_DEAD) {
+    if (block->state == IIO_BLOCK_STATE_DEAD)
  iio_buffer_block_put(block);
-    } else if (queue->active) {
+    else if (queue->active)
  iio_dma_buffer_submit_block(queue, block);
-    } else {
+    else
  block->state = IIO_BLOCK_STATE_QUEUED;
-    list_add_tail(&block->head, &queue->incoming);
If iio_dma_buffer_enqueue() is called with a dmabuf and the 
buffer is not active, it will be marked as queued, but we 
don't actually keep a reference to it anywhere. It will 
never be submitted to the DMA, and it will never be 
signaled as completed.


We do keep a reference to the buffers, in the queue->fileio.blocks 
array. When the buffer is enabled, all the blocks in that 
array that are in the "queued" state will be submitted to the 
DMA.


But not when used in combination with the DMA buf changes later in 
this series.




That's still the case after the DMABUF changes of the series. Or can 
you point me exactly what you think is broken?


When you allocate a DMABUF with the allocate IOCTL and then submit it 
with the enqueue IOCTL before the buffer is enabled it will end up 
marked as queued, but not actually be queued anywhere.




Ok, it works for me because I never enqueue blocks before enabling the 
buffer. I can add a requirement that blocks must be enqueued only 
after the buffer is enabled.


I don't think that is a good idea. This way you are going to potentially 
drop data at the begining of your stream when the DMA isn't ready yet.

Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

On Mon, Nov 22, 2021 at 8:36 PM Maxime Ripard  wrote:
>
> On Mon, Nov 22, 2021 at 08:01:47PM +0530, Jagan Teki wrote:
> > On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard  wrote:
> > >
> > > On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > > > It's perfectly valid to dereference the pointer in atomic_enable, and
> > > > > that patch would consume memory for no particular reason.
> > > >
> > > > Again, I'm not pointing any mistake in dereference and certainly not
> > > > understand about what memory consumption issue here.
> > >
> > > You add a struct drm_display_mode field to struct sun6i_dsi. It
> > > increases the size of struct sun6i_dsi of sizeof(struct
> > > drm_display_mode).
> > >
> > > > I'm doing it here since I'm doing it via mode_set in other drivers. No
> > > > problem for me either way.
> > >
> > > But *why* are you doing so?
> > >
> > > There might be a valid reason in other drivers, but there's none here
> > > (that you mentioned at least).
> >
> > The reason is to use existing bridge function instead of dereference
> > ie what I've mentioned. I don't have any other reasons.
>
> This discussion is going in circles. Unless you have a reason other than
> "because we can", NAK for the reasons already stated above.

Agreed your point.

Thanks,
Jagan.

Re: [PATCH 01/15] iio: buffer-dma: Get rid of incoming/outgoing queues

2021-11-22 Thread Paul Cercueil





Le lun., nov. 22 2021 at 16:17:59 +0100, Lars-Peter Clausen 
 a écrit :

On 11/22/21 4:16 PM, Paul Cercueil wrote:

Hi Lars,

Le lun., nov. 22 2021 at 16:08:51 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 9:08 PM, Paul Cercueil wrote:



Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen 
 a écrit :

On 11/21/21 6:52 PM, Paul Cercueil wrote:

Hi Lars,

Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen 
 a écrit :

On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and 
outgoing, to

manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much 
easier to
just check each block's state manually, and keep a counter for 
the next

block to dequeue.

Since the new DMABUF based API wouldn't use these incoming and 
outgoing
queues anyway, getting rid of them now makes the upcoming 
changes

simpler.

Signed-off-by: Paul Cercueil 
The outgoing queue is going to be replaced by fences, but I 
think we need to keep the incoming queue.


Blocks are always accessed in sequential order, so we now have a 
"queue->next_dequeue" that cycles between the buffers 
allocated for fileio.



[...]
@@ -442,28 +435,33 @@ 
EXPORT_SYMBOL_GPL(iio_dma_buffer_disable);
  static void iio_dma_buffer_enqueue(struct 
iio_dma_buffer_queue *queue,

  struct iio_dma_buffer_block *block)
  {
-if (block->state == IIO_BLOCK_STATE_DEAD) {
+if (block->state == IIO_BLOCK_STATE_DEAD)
  iio_buffer_block_put(block);
-} else if (queue->active) {
+else if (queue->active)
  iio_dma_buffer_submit_block(queue, block);
-} else {
+else
  block->state = IIO_BLOCK_STATE_QUEUED;
-list_add_tail(&block->head, &queue->incoming);
If iio_dma_buffer_enqueue() is called with a dmabuf and the 
buffer is not active, it will be marked as queued, 
but we don't actually keep a reference to it 
anywhere. It will never be submitted to the DMA, and 
it will never be signaled as completed.


We do keep a reference to the buffers, in the 
queue->fileio.blocks array. When the buffer is enabled, 
all the blocks in that array that are in the "queued" 
state will be submitted to the DMA.


But not when used in combination with the DMA buf changes later 
in this series.




That's still the case after the DMABUF changes of the series. Or 
can you point me exactly what you think is broken?


When you allocate a DMABUF with the allocate IOCTL and then submit 
it with the enqueue IOCTL before the buffer is enabled it will 
end up marked as queued, but not actually be queued anywhere.




Ok, it works for me because I never enqueue blocks before enabling 
the buffer. I can add a requirement that blocks must be enqueued 
only after the buffer is enabled.


I don't think that is a good idea. This way you are going to 
potentially drop data at the begining of your stream when the DMA 
isn't ready yet.




You wouldn't drop data, but it could cause an underrun, yes. Is it such 
a big deal, knowing that the buffer was just enabled? I don't think you 
can disable then enable the buffer without causing a discontinuity in 
the stream.


-Paul

Re: [PATCH] drm: check drm_format_info hsub and vsub to avoid divide by zero

2021-11-22 Thread George Kennedy





On 11/19/2021 9:25 AM, Jani Nikula wrote:

On Fri, 19 Nov 2021, Daniel Vetter  wrote:

On Fri, Nov 19, 2021 at 12:03:00PM +0200, Ville Syrjälä wrote:

On Fri, Nov 19, 2021 at 10:40:38AM +0100, Daniel Vetter wrote:

On Thu, Oct 28, 2021 at 05:04:19PM +0300, Ville Syrjälä wrote:

On Thu, Oct 28, 2021 at 08:57:17AM -0500, George Kennedy wrote:

Do a sanity check on struct drm_format_info hsub and vsub values to
avoid divide by zero.

Syzkaller reported a divide error in framebuffer_check() when the
DRM_FORMAT_Q410 or DRM_FORMAT_Q401 pixel_format is passed in via
the DRM_IOCTL_MODE_ADDFB2 ioctl. The drm_format_info struct for
the DRM_FORMAT_Q410 pixel_pattern has ".hsub = 0" and ".vsub = 0".
fb_plane_width() uses hsub as a divisor and fb_plane_height() uses
vsub as a divisor. These divisors need to be sanity checked for
zero before use.

divide error:  [#1] SMP KASAN NOPTI
CPU: 0 PID: 14995 Comm: syz-executor709 Not tainted 5.15.0-rc6-syzk #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2
RIP: 0010:framebuffer_check drivers/gpu/drm/drm_framebuffer.c:199 [inline]
RIP: 0010:drm_internal_framebuffer_create+0x604/0xf90
drivers/gpu/drm/drm_framebuffer.c:317

Call Trace:
  drm_mode_addfb2+0xdc/0x320 drivers/gpu/drm/drm_framebuffer.c:355
  drm_mode_addfb2_ioctl+0x2a/0x40 drivers/gpu/drm/drm_framebuffer.c:391
  drm_ioctl_kernel+0x23a/0x2e0 drivers/gpu/drm/drm_ioctl.c:795
  drm_ioctl+0x589/0xac0 drivers/gpu/drm/drm_ioctl.c:898
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:874 [inline]
  __se_sys_ioctl fs/ioctl.c:860 [inline]
  __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
  do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

Signed-off-by: George Kennedy 
---
  drivers/gpu/drm/drm_framebuffer.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 07f5abc..a146e4b 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -195,6 +195,16 @@ static int framebuffer_check(struct drm_device *dev,
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
  
+	if (info->hsub == 0) {

+   DRM_DEBUG_KMS("bad horizontal chroma subsampling factor %u\n", 
info->hsub);
+   return -EINVAL;
+   }
+
+   if (info->vsub == 0) {
+   DRM_DEBUG_KMS("bad vertical chroma subsampling factor %u\n", 
info->vsub);
+   return -EINVAL;
+   }

Looks like duct tape to me. I think we need to either fix those formats
to have valid format info, or just revert the whole patch that added such
broken things.

Yeah maybe even a compile-time check of the format table(s) to validate
them properly and scream ... Or at least a selftest.

I really wish C had (even very limited) compile time evaluation
so one could actually loop over arrays like at compile time to
check each element. As it stands you either have to check each
array element by hand, or you do some cpp macro horrors to
pretend you're iterating the array.

Python preprocess or so seems to be the usual answer, and that then just
generates the C table after it's all checked.

Or a post-processor which fishes the table out from the .o (or just links
against it).

But yeah doing this in cpp isn't going to work, aside from it'd be really
ugly.

Kbuild does have support for hostprogs which are typically used in the
build. The obvious idea is to use that for code generation, but it would
also be interesting to see how that could be used for compile-time
evaluation of sorts. Kind of like compile-time selftests? And, of
course, how badly that would be frowned upon.

git grep says there are only four hostprogs users in drivers/, so it
certainly isn't a popularity contest winner. (One of them is
"mkregtable" in radeon.)


So, can someone suggest a fix? A cpp type of approach does not seem 
feasible.


Adding the sanity checks that are in the patch, which are similar to the 
sanity checks preceding them in framebuffer_check(), along with a 
self-test that ran through all the table entries, might address all the 
concerns brought up in this thread.


Thank you,
George



BR,
Jani.

Re: [PATCH] Revert "drm/i915/dmabuf: fix broken build"




On 22/11/2021 14:04, Matthew Auld wrote:

On 22/11/2021 13:57, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

This reverts commit 777226dac058d119286b4081953cb5aa2cb7394b.

Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive via 304ac8032d3f
("Merge tag 'drm-next-2021-11-12' of 
git://anongit.freedesktop.org/drm/drm").


Signed-off-by: Tvrtko Ursulin 
Fixes: 777226dac058 ("drm/i915/dmabuf: fix broken build")
Cc: Matthew Auld 
Cc: Thomas Hellström 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 


Acked-by: Matthew Auld 

This was copy-paste from gem/i915_gem_pm.c, does that need a similar patch?


Personally I don't think we need to act immediately and can wait until 
the !x86 build efforts crystalize things for us a bit.


At least the commentary and commit in i915_gem_pm.c give rationale on 
pros and cons of clflush vs wbinvd. And commentary in i915_gem_dmabuf.c 
makes it sound we cannot simply go to clflush there in all cases.


Regards,

Tvrtko




---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c

index f291cf4c3886..1b526039a60d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -17,13 +17,6 @@
  MODULE_IMPORT_NS(DMA_BUF);
-#if defined(CONFIG_X86)
-#include 
-#else
-#define wbinvd_on_all_cpus() \
-    pr_warn(DRIVER_NAME ": Missing cache flush in %s\n", __func__)
-#endif
-
  I915_SELFTEST_DECLARE(static bool force_different_devices;)
  static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Neil Armstrong

Hi,

On 22/11/2021 14:16, Jagan Teki wrote:
> Hi Neil,
> 
> On Mon, Nov 22, 2021 at 6:22 PM Neil Armstrong  
> wrote:
>>
>> On 22/11/2021 07:52, Jagan Teki wrote:
>>> Some display panels would come up with a non-DSI output, those
>>> can have an option to connect the DSI host by means of interface
>>> bridge converter.
>>>
>>> This DSI to non-DSI interface bridge converter would requires
>>> DSI Host to handle drm bridge functionalities in order to DSI
>>> Host to Interface bridge.
>>>
>>> This patch convert the existing to a drm bridge driver with a
>>> built-in encoder support for compatibility with existing
>>> component drivers.
>>>
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Changes for v5:
>>> - add atomic APIs
>>> - find host and device variant DSI devices.
>>> Changes for v4, v3:
>>> - none
>>>
>>>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
>>>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
>>>  2 files changed, 96 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
>>> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>>> index 43d9c9e5198d..a6a272b55f77 100644
>>> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>>> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>>> @@ -21,6 +21,7 @@
>>>
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
>>>   return 0;
>>>  }
>>>
>>> -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
>>> +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
>>> +struct drm_bridge_state 
>>> *old_bridge_state)
>>>  {
>>> - struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
>>> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
>>> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
>>> + struct drm_display_mode *mode = 
>>> &bridge->encoder->crtc->state->adjusted_mode;
>>>   struct mipi_dsi_device *device = dsi->device;
>>>   union phy_configure_opts opts = { };
>>>   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
>>> @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
>>> *encoder)
>>>   if (dsi->panel)
>>>   drm_panel_prepare(dsi->panel);
>>>
>>> + if (dsi->next_bridge)
>>> + dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
>>> old_bridge_state);
>>> +
>>>   /*
>>>* FIXME: This should be moved after the switch to HS mode.
>>>*
>>> @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
>>> *encoder)
>>>   if (dsi->panel)
>>>   drm_panel_enable(dsi->panel);
>>>
>>> + if (dsi->next_bridge)
>>> + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
>>> old_bridge_state);
>>> +
>>
>>
>> No need to call the next bridge atomic 
>> pre_enable/enable/disable/post_disable since they will
>> be called automatically on the bridge chain.
> 
> Correct, but the existing bridge chain (stack) is not compatible with
> sun6i DSI start sequence. We cannot send any DCS once we start HS
> mode.
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#n775

It's a classical DSI sequence init issue, look at dw-mipi-dsi:
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c

We setup the "command-mode" (low-speed) withing mode_set so when the next 
bridge dsi_pre_enable is called,
low-speed DCS can be sent, then the bridge enable() sets video mode 
(high-speed).
The disable still needs to call the next_bridge post_disable :
https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L893

You can send any low-speed DCS once HS mode is started if the HW supports it 
and the driver handles it, look
at the 
https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L397
The MIPI_DSI_MODE_LPM and MIPI_DSI_MSG_USE_LPM is used for that.

Neil

> 
> This specific problem can be fixed only if we change the bridge chain
> from stack to queue. Please check this series
> https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-6-ja...@amarulasolutions.com/
> 
> Jagan.
>

Re: [Intel-gfx] [PATCH v6 1/6] drm/i915: Add support for moving fence waiting

Hi "Thomas,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next drm/drm-next v5.16-rc2 
next-2028]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next 
airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-ttm-Async-migration/20211122-162430
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a004-20211122 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 
c133fb321f7ca6083ce15b6aa5bf89de6600e649)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/387d80b6342f138213ce6e79e84459597b4a0394
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Thomas-Hellstr-m/drm-i915-ttm-Async-migration/20211122-162430
git checkout 387d80b6342f138213ce6e79e84459597b4a0394
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/i915_vma.c:356:12: warning: function 
>> 'i915_vma_verify_bind_complete' is not needed and will not be emitted 
>> [-Wunneeded-internal-declaration]
   static int i915_vma_verify_bind_complete(struct i915_vma *vma)
  ^
   1 warning generated.


vim +/i915_vma_verify_bind_complete +356 drivers/gpu/drm/i915/i915_vma.c

   355  
 > 356  static int i915_vma_verify_bind_complete(struct i915_vma *vma)
   357  {
   358  int err = 0;
   359  
   360  if (i915_active_has_exclusive(&vma->active)) {
   361  struct dma_fence *fence =
   362  i915_active_fence_get(&vma->active.excl);
   363  
   364  if (!fence)
   365  return 0;
   366  
   367  if (dma_fence_is_signaled(fence))
   368  err = fence->error;
   369  else
   370  err = -EBUSY;
   371  
   372  dma_fence_put(fence);
   373  }
   374  
   375  return err;
   376  }
   377  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 1/2] drm: exynos: dsi: Convert to bridge driver

On 22.11.2021 16:07, Marek Szyprowski wrote:
> On 22.11.2021 15:55, Jagan Teki wrote:
>> On Mon, Nov 22, 2021 at 7:59 PM Jagan Teki 
>>  wrote:
>>> On Mon, Nov 22, 2021 at 7:51 PM Jagan Teki 
>>>  wrote:
 On Mon, Nov 22, 2021 at 7:45 PM Marek Szyprowski
  wrote:
> On 22.11.2021 08:06, Jagan Teki wrote:
>> Some display panels would come up with a non-DSI output, those
>> can have an option to connect the DSI host by means of interface
>> bridge converter.
>>
>> This DSI to non-DSI interface bridge converter would requires
>> DSI Host to handle drm bridge functionalities in order to DSI
>> Host to Interface bridge.
>>
>> This patch convert the existing to a drm bridge driver with a
>> built-in encoder support for compatibility with existing
>> component drivers.
>>
>> Signed-off-by: Jagan Teki 
>> ---
>> Note:
>> Hi Marek Szyprowski,
>>
>> Please test this on Panel and Bridge hardware.
> I don't have good news, t crashes:
>
> [drm] Exynos DRM: using 1380.decon device for DMA mapping 
> operations
> exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
> exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
> exynos-drm exynos-drm: bound 1393.mic (ops 
> exynos_mic_component_ops)
> [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /soc@0/dsi@1390 to encoder TMDS-67: -22
> exynos-drm exynos-drm: failed to bind 1390.dsi (ops
> exynos_dsi_component_ops): -22
> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 2 PID: 74 Comm: kworker/u16:1 Not tainted 5.16.0-rc1+ #4141
> Hardware name: Samsung TM2E board (DT)
> Workqueue: events_unbound deferred_probe_work_func
> pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : decon_atomic_disable+0x58/0xd4
> lr : decon_atomic_disable+0x28/0xd4
> sp : 80001390b940
> x29: 80001390b940 x28: 80001259a000 x27: 27f39e80
> input: stmfts as
> /devices/platform/soc@0/14ed.hsi2c/i2c-3/3-0049/input/input0
> x26: ffea x25: 25a40280 x24: 0001
> x23: 800011b55f98 x22: 315dc000 x21: 2695d100
> x20: 27e7a080 x19: 315e6000 x18: 
> x17: 645f736f6e797865 x16: 2073706f28206973 x15: 00028ee0
> x14: 0028 x13: 0001 x12: 0040
> x11: 23c18920 x10: 23c18922 x9 : 8000126352f0
> x8 : 23c00270 x7 :  x6 : 23c00268
> x5 : 27e7a3a0 x4 : 0001 x3 : 27e7a080
> x2 : 0024 x1 : 800013bc8024 x0 : 246117c0
> Call trace:
>    decon_atomic_disable+0x58/0xd4
>    decon_unbind+0x1c/0x3c
>    component_unbind+0x38/0x60
>    component_bind_all+0x16c/0x25c
>    exynos_drm_bind+0x104/0x1bc
>    try_to_bring_up_master+0x164/0x1d0
>    __component_add+0xa8/0x174
>    component_add+0x14/0x20
>    hdmi_probe+0x438/0x710
>    platform_probe+0x68/0xe0
>    really_probe.part.0+0x9c/0x31c
>    __driver_probe_device+0x98/0x144
>    driver_probe_device+0xc8/0x160
>    __device_attach_driver+0xb8/0x120
>    bus_for_each_drv+0x78/0xd0
>    __device_attach+0xd8/0x180
>    device_initial_probe+0x14/0x20
>    bus_probe_device+0x9c/0xa4
>    deferred_probe_work_func+0x88/0xc4
>    process_one_work+0x288/0x6f0
>    worker_thread+0x74/0x470
>    kthread+0x188/0x194
>    ret_from_fork+0x10/0x20
> Code: 11002042 f9481c61 531e7442 8b020021 (88dffc21)
> ---[ end trace d73aff585b108954 ]---
> Kernel panic - not syncing: synchronous external abort: Fatal 
> exception
> SMP: stopping secondary CPUs
> Kernel Offset: disabled
> CPU features: 0x2,300071c2,0846
> Memory Limit: none
> ---[ end Kernel panic - not syncing: synchronous external abort: 
> Fatal
> exception ]---
 Is this with Bridge or normal DSI panel?
>>> Can you apply this patch and check?
>>> https://protect2.fireeye.com/v1/url?k=aad62f08-f54d1627-aad7a447-0cc47a31cdf8-ea5858ddb7f0ecfe&q=1&e=2d730862-2c56-4988-a252-8febd02da578&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Flinux%2Fcommit%2F412f226acd774356e8188c9e62b653672926ee0d
>>>  
>>>
>> Any news on this? just asking in case if you missed it.
>
> It is somehow better. System doesn't crash, but the DRM is not bound:
>
> # cat /sys/kernel/debug/device_component/exynos-drm
> master name    status
> -
> exynos-drm  not bound
>
> device name    status
> -
> 1380.decon

Re: [Intel-gfx] [PATCH v6 2/4] drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code

2021-11-22 Thread Ramalingam C

On 2021-11-08 at 18:45:45 +0100, Thomas Hellström wrote:
> The capture code is typically run entirely in the fence signalling
> critical path. We're about to add lockdep annotation in an upcoming patch
> which reveals a lockdep splat similar to the below one.
> 
> Fix the associated potential deadlocks using __GFP_KSWAPD_RECLAIM
> (which is the same as GFP_WAIT, but open-coded for clarity) rather than
> GFP_KERNEL for memory allocation in the capture path. This has the
> potential drawback that capture might fail in situations with memory
> pressure.
> 
> [  234.842048] WARNING: possible circular locking dependency detected
> [  234.842050] 5.15.0-rc7+ #20 Tainted: G U  W
> [  234.842052] --
> [  234.842054] gem_exec_captur/1180 is trying to acquire lock:
> [  234.842056] a3e51c00 (fs_reclaim){+.+.}-{0:0}, at: 
> __kmalloc+0x4d/0x330
> [  234.842063]
>but task is already holding lock:
> [  234.842064] a3f57620 (dma_fence_map){}-{0:0}, at: 
> i915_vma_snapshot_resource_pin+0x27/0x30 [i915]
> [  234.842138]
>which lock already depends on the new lock.
> 
> [  234.842140]
>the existing dependency chain (in reverse order) is:
> [  234.842142]
>-> #2 (dma_fence_map){}-{0:0}:
> [  234.842145]__dma_fence_might_wait+0x41/0xa0
> [  234.842149]dma_resv_lockdep+0x1dc/0x28f
> [  234.842151]do_one_initcall+0x58/0x2d0
> [  234.842154]kernel_init_freeable+0x273/0x2bf
> [  234.842157]kernel_init+0x16/0x120
> [  234.842160]ret_from_fork+0x1f/0x30
> [  234.842163]
>-> #1 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> [  234.842166]fs_reclaim_acquire+0x6d/0xd0
> [  234.842168]__kmalloc_node+0x51/0x3a0
> [  234.842171]alloc_cpumask_var_node+0x1b/0x30
> [  234.842174]native_smp_prepare_cpus+0xc7/0x292
> [  234.842177]kernel_init_freeable+0x160/0x2bf
> [  234.842179]kernel_init+0x16/0x120
> [  234.842181]ret_from_fork+0x1f/0x30
> [  234.842184]
>-> #0 (fs_reclaim){+.+.}-{0:0}:
> [  234.842186]__lock_acquire+0x1161/0x1dc0
> [  234.842189]lock_acquire+0xb5/0x2b0
> [  234.842192]fs_reclaim_acquire+0xa1/0xd0
> [  234.842193]__kmalloc+0x4d/0x330
> [  234.842196]i915_vma_coredump_create+0x78/0x5b0 [i915]
> [  234.842253]intel_engine_coredump_add_vma+0x36/0xe0 [i915]
> [  234.842307]__i915_gpu_coredump+0x290/0x5e0 [i915]
> [  234.842365]i915_capture_error_state+0x57/0xa0 [i915]
> [  234.842415]intel_gt_handle_error+0x348/0x3e0 [i915]
> [  234.842462]intel_gt_debugfs_reset_store+0x3c/0x90 [i915]
> [  234.842504]simple_attr_write+0xc1/0xe0
> [  234.842507]full_proxy_write+0x53/0x80
> [  234.842509]vfs_write+0xbc/0x350
> [  234.842513]ksys_write+0x58/0xd0
> [  234.842514]do_syscall_64+0x38/0x90
> [  234.842516]entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  234.842519]
>other info that might help us debug this:
> 
> [  234.842521] Chain exists of:
>  fs_reclaim --> mmu_notifier_invalidate_range_start --> 
> dma_fence_map
> 
> [  234.842526]  Possible unsafe locking scenario:
> 
> [  234.842528]CPU0CPU1
> [  234.842529]
> [  234.842531]   lock(dma_fence_map);
> [  234.842532]
> lock(mmu_notifier_invalidate_range_start);
> [  234.842535]lock(dma_fence_map);
> [  234.842537]   lock(fs_reclaim);
> [  234.842539]
> *** DEADLOCK ***
> 
> [  234.842540] 4 locks held by gem_exec_captur/1180:
> [  234.842543]  #0: 9007812d9460 (sb_writers#17){.+.+}-{0:0}, at: 
> ksys_write+0x58/0xd0
> [  234.842547]  #1: 900781d9ecb8 (&attr->mutex){+.+.}-{3:3}, at: 
> simple_attr_write+0x3a/0xe0
> [  234.842552]  #2: c11913a8 (capture_mutex){+.+.}-{3:3}, at: 
> i915_capture_error_state+0x1a/0xa0 [i915]
> [  234.842602]  #3: a3f57620 (dma_fence_map){}-{0:0}, at: 
> i915_vma_snapshot_resource_pin+0x27/0x30 [i915]
> [  234.842656]
>stack backtrace:
> [  234.842658] CPU: 0 PID: 1180 Comm: gem_exec_captur Tainted: G U  W 
> 5.15.0-rc7+ #20
> [  234.842661] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 
> 0403 01/26/2021
> [  234.842664] Call Trace:
> [  234.842666]  dump_stack_lvl+0x57/0x72
> [  234.842669]  check_noncircular+0xde/0x100
> [  234.842672]  ? __lock_acquire+0x3bf/0x1dc0
> [  234.842675]  __lock_acquire+0x1161/0x1dc0
> [  234.842678]  lock_acquire+0xb5/0x2b0
> [  234.842680]  ? __kmalloc+0x4d/0x330
> [  234.842683]  ? finish_task_switch.isra.0+0xf2/0x360
> [  234.842686]  ? i915_vma_coredump_create+0x78/0x5b0 [i915]
> [  234.842734]  fs_reclaim_acquire+0xa1/0xd0
> [  234.842737]  ? __kmalloc+0x4d/0x330
> [

RPM raw-wakeref not held in intel_pxp_fini_hw

2021-11-22 Thread Jason A. Donenfeld

Hey Intel PXPers,

I hit this splat on 5.16-rc1 during system suspend:

Nov 22 13:54:09 thinkpad systemd-logind[934]: Lid closed.
Nov 22 13:54:09 thinkpad systemd[1]: Reached target Sleep.
Nov 22 13:54:09 thinkpad systemd[1]: Starting System Suspend...
Nov 22 13:54:09 thinkpad systemd-sleep[519259]: Entering sleep state
'suspend'...
Nov 22 13:54:09 thinkpad kernel: PM: suspend entry (s2idle)
Nov 22 15:22:05 thinkpad kernel: Filesystems sync: 0.124 seconds
Nov 22 15:22:05 thinkpad kernel: Freezing user space processes ...
(elapsed 0.001 seconds) done.
Nov 22 15:22:05 thinkpad kernel: OOM killer disabled.
Nov 22 15:22:05 thinkpad kernel: Freezing remaining freezable tasks
... (elapsed 0.001 seconds) done.
Nov 22 15:22:05 thinkpad kernel: printk: Suspending console(s) (use
no_console_suspend to debug)
Nov 22 15:22:05 thinkpad kernel: [ cut here ]
Nov 22 15:22:05 thinkpad kernel: RPM wakelock ref not held during HW access
Nov 22 15:22:05 thinkpad kernel: WARNING: CPU: 10 PID: 519259 at
drivers/gpu/drm/i915/intel_runtime_pm.h:112
fwtable_write32+0x1cb/0x200 [i915]
Nov 22 15:22:05 thinkpad kernel: Modules linked in: cdc_mbim cdc_wdm
cdc_ncm cdc_ether usbnet mii snd_seq_dummy snd_hrtimer snd_seq
snd_seq_device rfcomm cmac algif_skcipher bnep uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 btusb
videobuf2_common btintel blue>
Nov 22 15:22:05 thinkpad kernel:  i2c_designware_platform
i2c_designware_core mei_pxp mei_hdcp ac97_bus kvm_intel snd_hda_intel
snd_intel_dspcfg intel_rapl_msr think_lmi snd_intel_sdw_acpi i915
firmware_attributes_class wmi_bmof snd_hda_codec kvm i2c_algo_bit
snd_hwdep int>
Nov 22 15:22:05 thinkpad kernel: CPU: 10 PID: 519259 Comm:
systemd-sleep Tainted: G S   U5.16.0-rc1+ #192
Nov 22 15:22:05 thinkpad kernel: Hardware name: LENOVO
20Y5CTO1WW/20Y5CTO1WW, BIOS N40ET28W (1.10 ) 09/09/2021
Nov 22 15:22:05 thinkpad kernel: RIP: 0010:fwtable_write32+0x1cb/0x200 [i915]
Nov 22 15:22:05 thinkpad kernel: Code: 21 cb df 0f 0b e9 85 fe ff ff
80 3d 36 68 1f 00 00 0f 85 82 fe ff ff 48 c7 c7 70 cf c4 a1 c6 05 22
68 1f 00 01 e8 1c 21 cb df <0f> 0b e9 68 fe ff ff 48 8b bb 40 01 00 00
e8 a2 cf ce df b9 01 00
Nov 22 15:22:05 thinkpad kernel: RSP: 0018:88821d283c80 EFLAGS: 00010282
Nov 22 15:22:05 thinkpad kernel: RAX: 002a RBX:
88813df707d0 RCX: 0027
Nov 22 15:22:05 thinkpad kernel: RDX: 88901f69b448 RSI:
0001 RDI: 88901f69b440
Nov 22 15:22:05 thinkpad kernel: RBP: 000320f0 R08:
0d17 R09: 88821d283c20
Nov 22 15:22:05 thinkpad kernel: R10: 3fff R11:
fff93a78 R12: 4000
Nov 22 15:22:05 thinkpad kernel: R13:  R14:
888101311150 R15: 81491b20
Nov 22 15:22:05 thinkpad kernel: FS:  7efcfaa87800()
GS:88901f68() knlGS:
Nov 22 15:22:05 thinkpad kernel: CS:  0010 DS:  ES:  CR0:
80050033
Nov 22 15:22:05 thinkpad kernel: CR2: 7efcfb41e6f0 CR3:
0005ed937004 CR4: 00770ee0
Nov 22 15:22:05 thinkpad kernel: PKRU: 5554
Nov 22 15:22:05 thinkpad kernel: Call Trace:
Nov 22 15:22:05 thinkpad kernel:  
Nov 22 15:22:05 thinkpad kernel:  intel_pxp_fini_hw+0x23/0x30 [i915]
Nov 22 15:22:05 thinkpad kernel:  intel_pxp_suspend+0x2f/0x40 [i915]
Nov 22 15:22:05 thinkpad kernel:  i915_gem_backup_suspend+0x6e/0x150 [i915]
Nov 22 15:22:05 thinkpad kernel:  ? pci_target_state+0xc/0xc0
Nov 22 15:22:05 thinkpad kernel:  pci_pm_prepare+0x28/0x60
Nov 22 15:22:05 thinkpad kernel:  dpm_prepare+0xbd/0x370
Nov 22 15:22:05 thinkpad kernel:  dpm_suspend_start+0x16/0x80
Nov 22 15:22:05 thinkpad kernel:  suspend_devices_and_enter+0x104/0x6d0
Nov 22 15:22:05 thinkpad kernel:  pm_suspend.cold+0x2f6/0x33d
Nov 22 15:22:05 thinkpad kernel:  state_store+0x6b/0xe0
Nov 22 15:22:05 thinkpad kernel:  kernfs_fop_write_iter+0x107/0x190
Nov 22 15:22:05 thinkpad kernel:  new_sync_write+0x100/0x170
Nov 22 15:22:05 thinkpad kernel:  vfs_write+0x1c5/0x260
Nov 22 15:22:05 thinkpad kernel:  ksys_write+0x4a/0xc0
Nov 22 15:22:05 thinkpad kernel:  do_syscall_64+0x35/0x80
Nov 22 15:22:05 thinkpad kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
Nov 22 15:22:05 thinkpad kernel: RIP: 0033:0x7efcfb27ccb3
Nov 22 15:22:05 thinkpad kernel: Code: 8b 15 81 11 0f 00 f7 d8 64 89
02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0
75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48
83 ec 28 48 89 54 24 18
Nov 22 15:22:05 thinkpad kernel: RSP: 002b:7fff279a5308 EFLAGS:
0246 ORIG_RAX: 0001
Nov 22 15:22:05 thinkpad kernel: RAX: ffda RBX:
0004 RCX: 7efcfb27ccb3
Nov 22 15:22:05 thinkpad kernel: RDX: 0004 RSI:
7fff279a5400 RDI: 0004
Nov 22 15:22:05 thinkpad kernel: RBP: 5571997e72d0 R08:
0007 R09: 5571997eb4a0
Nov 22 15:22:05 thinkpad kernel: R10: 11500bc5676901a3 R11:
0246 R12: 0004
Nov 22 15

Re: RPM raw-wakeref not held in intel_pxp_fini_hw

2021-11-22 Thread Daniele Ceraolo Spurio


Hi,

The fix for this is in flight:

https://patchwork.freedesktop.org/series/96658/

It just needs a last round of testing before we merge it.

Thanks,
Daniele

On 11/22/2021 8:47 AM, Jason A. Donenfeld wrote:

Hey Intel PXPers,

I hit this splat on 5.16-rc1 during system suspend:

Nov 22 13:54:09 thinkpad systemd-logind[934]: Lid closed.
Nov 22 13:54:09 thinkpad systemd[1]: Reached target Sleep.
Nov 22 13:54:09 thinkpad systemd[1]: Starting System Suspend...
Nov 22 13:54:09 thinkpad systemd-sleep[519259]: Entering sleep state
'suspend'...
Nov 22 13:54:09 thinkpad kernel: PM: suspend entry (s2idle)
Nov 22 15:22:05 thinkpad kernel: Filesystems sync: 0.124 seconds
Nov 22 15:22:05 thinkpad kernel: Freezing user space processes ...
(elapsed 0.001 seconds) done.
Nov 22 15:22:05 thinkpad kernel: OOM killer disabled.
Nov 22 15:22:05 thinkpad kernel: Freezing remaining freezable tasks
... (elapsed 0.001 seconds) done.
Nov 22 15:22:05 thinkpad kernel: printk: Suspending console(s) (use
no_console_suspend to debug)
Nov 22 15:22:05 thinkpad kernel: [ cut here ]
Nov 22 15:22:05 thinkpad kernel: RPM wakelock ref not held during HW access
Nov 22 15:22:05 thinkpad kernel: WARNING: CPU: 10 PID: 519259 at
drivers/gpu/drm/i915/intel_runtime_pm.h:112
fwtable_write32+0x1cb/0x200 [i915]
Nov 22 15:22:05 thinkpad kernel: Modules linked in: cdc_mbim cdc_wdm
cdc_ncm cdc_ether usbnet mii snd_seq_dummy snd_hrtimer snd_seq
snd_seq_device rfcomm cmac algif_skcipher bnep uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 btusb
videobuf2_common btintel blue>
Nov 22 15:22:05 thinkpad kernel:  i2c_designware_platform
i2c_designware_core mei_pxp mei_hdcp ac97_bus kvm_intel snd_hda_intel
snd_intel_dspcfg intel_rapl_msr think_lmi snd_intel_sdw_acpi i915
firmware_attributes_class wmi_bmof snd_hda_codec kvm i2c_algo_bit
snd_hwdep int>
Nov 22 15:22:05 thinkpad kernel: CPU: 10 PID: 519259 Comm:
systemd-sleep Tainted: G S   U5.16.0-rc1+ #192
Nov 22 15:22:05 thinkpad kernel: Hardware name: LENOVO
20Y5CTO1WW/20Y5CTO1WW, BIOS N40ET28W (1.10 ) 09/09/2021
Nov 22 15:22:05 thinkpad kernel: RIP: 0010:fwtable_write32+0x1cb/0x200 [i915]
Nov 22 15:22:05 thinkpad kernel: Code: 21 cb df 0f 0b e9 85 fe ff ff
80 3d 36 68 1f 00 00 0f 85 82 fe ff ff 48 c7 c7 70 cf c4 a1 c6 05 22
68 1f 00 01 e8 1c 21 cb df <0f> 0b e9 68 fe ff ff 48 8b bb 40 01 00 00
e8 a2 cf ce df b9 01 00
Nov 22 15:22:05 thinkpad kernel: RSP: 0018:88821d283c80 EFLAGS: 00010282
Nov 22 15:22:05 thinkpad kernel: RAX: 002a RBX:
88813df707d0 RCX: 0027
Nov 22 15:22:05 thinkpad kernel: RDX: 88901f69b448 RSI:
0001 RDI: 88901f69b440
Nov 22 15:22:05 thinkpad kernel: RBP: 000320f0 R08:
0d17 R09: 88821d283c20
Nov 22 15:22:05 thinkpad kernel: R10: 3fff R11:
fff93a78 R12: 4000
Nov 22 15:22:05 thinkpad kernel: R13:  R14:
888101311150 R15: 81491b20
Nov 22 15:22:05 thinkpad kernel: FS:  7efcfaa87800()
GS:88901f68() knlGS:
Nov 22 15:22:05 thinkpad kernel: CS:  0010 DS:  ES:  CR0:
80050033
Nov 22 15:22:05 thinkpad kernel: CR2: 7efcfb41e6f0 CR3:
0005ed937004 CR4: 00770ee0
Nov 22 15:22:05 thinkpad kernel: PKRU: 5554
Nov 22 15:22:05 thinkpad kernel: Call Trace:
Nov 22 15:22:05 thinkpad kernel:  
Nov 22 15:22:05 thinkpad kernel:  intel_pxp_fini_hw+0x23/0x30 [i915]
Nov 22 15:22:05 thinkpad kernel:  intel_pxp_suspend+0x2f/0x40 [i915]
Nov 22 15:22:05 thinkpad kernel:  i915_gem_backup_suspend+0x6e/0x150 [i915]
Nov 22 15:22:05 thinkpad kernel:  ? pci_target_state+0xc/0xc0
Nov 22 15:22:05 thinkpad kernel:  pci_pm_prepare+0x28/0x60
Nov 22 15:22:05 thinkpad kernel:  dpm_prepare+0xbd/0x370
Nov 22 15:22:05 thinkpad kernel:  dpm_suspend_start+0x16/0x80
Nov 22 15:22:05 thinkpad kernel:  suspend_devices_and_enter+0x104/0x6d0
Nov 22 15:22:05 thinkpad kernel:  pm_suspend.cold+0x2f6/0x33d
Nov 22 15:22:05 thinkpad kernel:  state_store+0x6b/0xe0
Nov 22 15:22:05 thinkpad kernel:  kernfs_fop_write_iter+0x107/0x190
Nov 22 15:22:05 thinkpad kernel:  new_sync_write+0x100/0x170
Nov 22 15:22:05 thinkpad kernel:  vfs_write+0x1c5/0x260
Nov 22 15:22:05 thinkpad kernel:  ksys_write+0x4a/0xc0
Nov 22 15:22:05 thinkpad kernel:  do_syscall_64+0x35/0x80
Nov 22 15:22:05 thinkpad kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
Nov 22 15:22:05 thinkpad kernel: RIP: 0033:0x7efcfb27ccb3
Nov 22 15:22:05 thinkpad kernel: Code: 8b 15 81 11 0f 00 f7 d8 64 89
02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0
75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48
83 ec 28 48 89 54 24 18
Nov 22 15:22:05 thinkpad kernel: RSP: 002b:7fff279a5308 EFLAGS:
0246 ORIG_RAX: 0001
Nov 22 15:22:05 thinkpad kernel: RAX: ffda RBX:
0004 RCX: 7efcfb27ccb3
Nov 22 15:22:05 thinkpad kernel: RDX: 0004 RSI:
7fff279a5400 RDI: 000

Re: RPM raw-wakeref not held in intel_pxp_fini_hw

2021-11-22 Thread Jason A. Donenfeld

Hi Daniele,

I'll give it a whirl on my laptop. Thanks.

Jason

Re: [PATCH v1 1/9] mm: add zone device coherent type memory support

2021-11-22 Thread Felix Kuehling

Am 2021-11-21 um 9:40 p.m. schrieb Alistair Popple:
 diff --git a/mm/migrate.c b/mm/migrate.c
 index 1852d787e6ab..f74422a42192 100644
 --- a/mm/migrate.c
 +++ b/mm/migrate.c
 @@ -362,7 +362,7 @@ static int expected_page_refs(struct address_space 
 *mapping, struct page *page)
 * Device private pages have an extra refcount as they are
 * ZONE_DEVICE pages.
 */
 -  expected_count += is_device_private_page(page);
 +  expected_count += is_device_page(page);
if (mapping)
expected_count += thp_nr_pages(page) + page_has_private(page);
  
 @@ -2503,7 +2503,7 @@ static bool migrate_vma_check_page(struct page *page)
 * FIXME proper solution is to rework migration_entry_wait() so
 * it does not need to take a reference on page.
 */
>>> Note that I have posted a patch to fix this - see
>>> https://lore.kernel.org/all/2028020754.954425-1-apop...@nvidia.com/ This
>>> looks ok for now assuming coherent pages can never be pinned.
>>>
>>> However that raises a question - what happens when something calls
>>> get_user_pages() on a pfn pointing to a coherent device page? I can't see
>>> anything in this series that prevents pinning of coherent device pages, so 
>>> we
>>> can't just assume they aren't pinned.
>> I agree. I think we need to depend on your patch to go in first.
>>
>> I'm also wondering if we need to do something to prevent get_user_pages
>> from pinning device pages. And by "pin", I think migrate_vma_check_page
>> is not talking about FOLL_PIN, but any get_user_pages call. As far as I
>> can tell, there should be nothing fundamentally wrong with pinning
>> device pages for a short time. But I think we'll want to avoid
>> FOLL_LONGTERM because that would affect our memory manager's ability to
>> evict device memory.
> Right, so long as my fix goes in I don't think there is anything wrong with
> pinning device public pages. Agree that we should avoid FOLL_LONGTERM pins for
> device memory though. I think the way to do that is update is_pinnable_page()
> so we treat device pages the same as other unpinnable pages ie. long-term pins
> will migrate the page.

I'm trying to understand check_and_migrate_movable_pages in gup.c. It
doesn't look like the right way to migrate device pages. We may have to
do something different there as well. So instead of changing
is_pinnable_page, it maybe better to explicitly check for is_device_page
or is_device_coherent_page in check_and_migrate_movable_pages to migrate
it correctly, or just fail outright.

Thanks,
  Felix


>
>>> In the case of device-private pages this is enforced by the fact they never
>>> have present pte's, so any attempt to GUP them results in a fault. But if 
>>> I'm
>>> understanding this series correctly that won't be the case for coherent 
>>> device
>>> pages right?
>> Right.
>>
>> Regards,
>>   Felix
>>
>>
 -  return is_device_private_page(page);
 +  return is_device_page(page);
}
  
/* For file back page */
 @@ -2791,7 +2791,7 @@ EXPORT_SYMBOL(migrate_vma_setup);
   * handle_pte_fault()
   *   do_anonymous_page()
   * to map in an anonymous zero page but the struct page will be a 
 ZONE_DEVICE
 - * private page.
 + * private or coherent page.
   */
  static void migrate_vma_insert_page(struct migrate_vma *migrate,
unsigned long addr,
 @@ -2867,10 +2867,15 @@ static void migrate_vma_insert_page(struct 
 migrate_vma *migrate,
swp_entry = make_readable_device_private_entry(
page_to_pfn(page));
entry = swp_entry_to_pte(swp_entry);
 +  } else if (is_device_page(page)) {
>>> How about adding an explicit `is_device_coherent_page()` helper? It would 
>>> make
>>> the test more explicit that this is expected to handle just coherent pages 
>>> and
>>> I bet there will be future changes that need to differentiate between 
>>> private
>>> and coherent pages anyway.
>>>
 +  entry = pte_mkold(mk_pte(page,
 +   READ_ONCE(vma->vm_page_prot)));
 +  if (vma->vm_flags & VM_WRITE)
 +  entry = pte_mkwrite(pte_mkdirty(entry));
} else {
/*
 -   * For now we only support migrating to un-addressable
 -   * device memory.
 +   * We support migrating to private and coherent types
 +   * for device zone memory.
 */
pr_warn_once("Unsupported ZONE_DEVICE page type.\n");
goto abort;
 @@ -2976,10 +2981,10 @@ void migrate_vma_pages(struct migrate_vma *migrate)
mapping = page_mapp

Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Dave Stevenson

Hi

On Mon, 22 Nov 2021 at 15:35, Neil Armstrong  wrote:
>
> Hi,
>
> On 22/11/2021 14:16, Jagan Teki wrote:
> > Hi Neil,
> >
> > On Mon, Nov 22, 2021 at 6:22 PM Neil Armstrong  
> > wrote:
> >>
> >> On 22/11/2021 07:52, Jagan Teki wrote:
> >>> Some display panels would come up with a non-DSI output, those
> >>> can have an option to connect the DSI host by means of interface
> >>> bridge converter.
> >>>
> >>> This DSI to non-DSI interface bridge converter would requires
> >>> DSI Host to handle drm bridge functionalities in order to DSI
> >>> Host to Interface bridge.
> >>>
> >>> This patch convert the existing to a drm bridge driver with a
> >>> built-in encoder support for compatibility with existing
> >>> component drivers.
> >>>
> >>> Signed-off-by: Jagan Teki 
> >>> ---
> >>> Changes for v5:
> >>> - add atomic APIs
> >>> - find host and device variant DSI devices.
> >>> Changes for v4, v3:
> >>> - none
> >>>
> >>>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> >>>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> >>>  2 files changed, 96 insertions(+), 23 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> >>> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> >>> index 43d9c9e5198d..a6a272b55f77 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> >>> @@ -21,6 +21,7 @@
> >>>
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> >>>   return 0;
> >>>  }
> >>>
> >>> -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> >>> +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> >>> +struct drm_bridge_state 
> >>> *old_bridge_state)
> >>>  {
> >>> - struct drm_display_mode *mode = 
> >>> &encoder->crtc->state->adjusted_mode;
> >>> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> >>> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> >>> + struct drm_display_mode *mode = 
> >>> &bridge->encoder->crtc->state->adjusted_mode;
> >>>   struct mipi_dsi_device *device = dsi->device;
> >>>   union phy_configure_opts opts = { };
> >>>   struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> >>> @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct 
> >>> drm_encoder *encoder)
> >>>   if (dsi->panel)
> >>>   drm_panel_prepare(dsi->panel);
> >>>
> >>> + if (dsi->next_bridge)
> >>> + 
> >>> dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> >>> old_bridge_state);
> >>> +
> >>>   /*
> >>>* FIXME: This should be moved after the switch to HS mode.
> >>>*
> >>> @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct 
> >>> drm_encoder *encoder)
> >>>   if (dsi->panel)
> >>>   drm_panel_enable(dsi->panel);
> >>>
> >>> + if (dsi->next_bridge)
> >>> + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> >>> old_bridge_state);
> >>> +
> >>
> >>
> >> No need to call the next bridge atomic 
> >> pre_enable/enable/disable/post_disable since they will
> >> be called automatically on the bridge chain.
> >
> > Correct, but the existing bridge chain (stack) is not compatible with
> > sun6i DSI start sequence. We cannot send any DCS once we start HS
> > mode.
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#n775
>
> It's a classical DSI sequence init issue, look at dw-mipi-dsi:
> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>
> We setup the "command-mode" (low-speed) withing mode_set so when the next 
> bridge dsi_pre_enable is called,
> low-speed DCS can be sent, then the bridge enable() sets video mode 
> (high-speed).
> The disable still needs to call the next_bridge post_disable :
> https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L893

Doesn't that mean the post_disable gets called twice? Once by the
dw-mipi-dsi driver and once by the framework.

> You can send any low-speed DCS once HS mode is started if the HW supports it 
> and the driver handles it, look
> at the 
> https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L397
> The MIPI_DSI_MODE_LPM and MIPI_DSI_MSG_USE_LPM is used for that.

This seems to be the same question as I was asking back in [1] and
continued in [2].

vc4 and Exynos break the chain apart so that they can initialise the
DSI host before the panel.
That doesn't work if the DSI host is an encoder, as the encoder
mode_valid call is missing the struct drm_display_info needed for
calling the bridge mode_valid function.
It also fails with the atomic operations as the framework can't see
the bridges/panels beyond the DSI host, and the

RE: RPM raw-wakeref not held in intel_pxp_fini_hw

2021-11-22 Thread Lubart, Vitaly

CC Tomas and Sasha

> -Original Message-
> From: Ceraolo Spurio, Daniele 
> Sent: Monday, November 22, 2021 18:54
> To: Jason A. Donenfeld ; Lubart, Vitaly
> ; Gupta, Anshuman ;
> Surendrakumar Upadhyay, TejaskumarX
> 
> Cc: LKML ; intel-...@lists.freedesktop.org; dri-
> devel 
> Subject: Re: RPM raw-wakeref not held in intel_pxp_fini_hw
> 
> Hi,
> 
> The fix for this is in flight:
> 
> https://patchwork.freedesktop.org/series/96658/
> 
> It just needs a last round of testing before we merge it.
> 
> Thanks,
> Daniele
> 
> On 11/22/2021 8:47 AM, Jason A. Donenfeld wrote:
> > Hey Intel PXPers,
> >
> > I hit this splat on 5.16-rc1 during system suspend:
> >
> > Nov 22 13:54:09 thinkpad systemd-logind[934]: Lid closed.
> > Nov 22 13:54:09 thinkpad systemd[1]: Reached target Sleep.
> > Nov 22 13:54:09 thinkpad systemd[1]: Starting System Suspend...
> > Nov 22 13:54:09 thinkpad systemd-sleep[519259]: Entering sleep state
> > 'suspend'...
> > Nov 22 13:54:09 thinkpad kernel: PM: suspend entry (s2idle) Nov 22
> > 15:22:05 thinkpad kernel: Filesystems sync: 0.124 seconds Nov 22
> > 15:22:05 thinkpad kernel: Freezing user space processes ...
> > (elapsed 0.001 seconds) done.
> > Nov 22 15:22:05 thinkpad kernel: OOM killer disabled.
> > Nov 22 15:22:05 thinkpad kernel: Freezing remaining freezable tasks
> > ... (elapsed 0.001 seconds) done.
> > Nov 22 15:22:05 thinkpad kernel: printk: Suspending console(s) (use
> > no_console_suspend to debug) Nov 22 15:22:05 thinkpad kernel:
> > [ cut here ] Nov 22 15:22:05 thinkpad kernel:
> > RPM wakelock ref not held during HW access Nov 22 15:22:05 thinkpad
> > kernel: WARNING: CPU: 10 PID: 519259 at
> > drivers/gpu/drm/i915/intel_runtime_pm.h:112
> > fwtable_write32+0x1cb/0x200 [i915]
> > Nov 22 15:22:05 thinkpad kernel: Modules linked in: cdc_mbim cdc_wdm
> > cdc_ncm cdc_ether usbnet mii snd_seq_dummy snd_hrtimer snd_seq
> > snd_seq_device rfcomm cmac algif_skcipher bnep uvcvideo
> > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 btusb
> > videobuf2_common btintel blue> Nov 22 15:22:05 thinkpad kernel:
> > i2c_designware_platform i2c_designware_core mei_pxp mei_hdcp ac97_bus
> > kvm_intel snd_hda_intel snd_intel_dspcfg intel_rapl_msr think_lmi
> > snd_intel_sdw_acpi i915 firmware_attributes_class wmi_bmof
> > snd_hda_codec kvm i2c_algo_bit snd_hwdep int> Nov 22 15:22:05 thinkpad
> > kernel: CPU: 10 PID: 519259 Comm:
> > systemd-sleep Tainted: G S   U5.16.0-rc1+ #192
> > Nov 22 15:22:05 thinkpad kernel: Hardware name: LENOVO
> > 20Y5CTO1WW/20Y5CTO1WW, BIOS N40ET28W (1.10 ) 09/09/2021 Nov 22
> > 15:22:05 thinkpad kernel: RIP: 0010:fwtable_write32+0x1cb/0x200 [i915]
> > Nov 22 15:22:05 thinkpad kernel: Code: 21 cb df 0f 0b e9 85 fe ff ff
> > 80 3d 36 68 1f 00 00 0f 85 82 fe ff ff 48 c7 c7 70 cf c4 a1 c6 05 22
> > 68 1f 00 01 e8 1c 21 cb df <0f> 0b e9 68 fe ff ff 48 8b bb 40 01 00 00
> > e8 a2 cf ce df b9 01 00
> > Nov 22 15:22:05 thinkpad kernel: RSP: 0018:88821d283c80 EFLAGS:
> > 00010282 Nov 22 15:22:05 thinkpad kernel: RAX: 002a RBX:
> > 88813df707d0 RCX: 0027 Nov 22 15:22:05 thinkpad
> > kernel: RDX: 88901f69b448 RSI:
> > 0001 RDI: 88901f69b440 Nov 22 15:22:05 thinkpad
> > kernel: RBP: 000320f0 R08:
> > 0d17 R09: 88821d283c20 Nov 22 15:22:05 thinkpad
> > kernel: R10: 3fff R11:
> > fff93a78 R12: 4000 Nov 22 15:22:05 thinkpad
> > kernel: R13:  R14:
> > 888101311150 R15: 81491b20 Nov 22 15:22:05 thinkpad
> > kernel: FS:  7efcfaa87800()
> > GS:88901f68() knlGS: Nov 22 15:22:05
> > thinkpad kernel: CS:  0010 DS:  ES:  CR0:
> > 80050033
> > Nov 22 15:22:05 thinkpad kernel: CR2: 7efcfb41e6f0 CR3:
> > 0005ed937004 CR4: 00770ee0 Nov 22 15:22:05 thinkpad
> > kernel: PKRU: 5554 Nov 22 15:22:05 thinkpad kernel: Call Trace:
> > Nov 22 15:22:05 thinkpad kernel:   Nov 22 15:22:05 thinkpad
> > kernel:  intel_pxp_fini_hw+0x23/0x30 [i915] Nov 22 15:22:05 thinkpad
> > kernel:  intel_pxp_suspend+0x2f/0x40 [i915] Nov 22 15:22:05 thinkpad
> > kernel:  i915_gem_backup_suspend+0x6e/0x150 [i915] Nov 22 15:22:05
> > thinkpad kernel:  ? pci_target_state+0xc/0xc0 Nov 22 15:22:05 thinkpad
> > kernel:  pci_pm_prepare+0x28/0x60 Nov 22 15:22:05 thinkpad kernel:
> > dpm_prepare+0xbd/0x370 Nov 22 15:22:05 thinkpad kernel:
> > dpm_suspend_start+0x16/0x80 Nov 22 15:22:05 thinkpad kernel:
> > suspend_devices_and_enter+0x104/0x6d0
> > Nov 22 15:22:05 thinkpad kernel:  pm_suspend.cold+0x2f6/0x33d Nov 22
> > 15:22:05 thinkpad kernel:  state_store+0x6b/0xe0 Nov 22 15:22:05
> > thinkpad kernel:  kernfs_fop_write_iter+0x107/0x190 Nov 22 15:22:05
> > thinkpad kernel:  new_sync_write+0x100/0x170 Nov 22 15:22:05 thinkpad
> > kernel:  vfs_write+0x1c5/0x260 Nov 22 15:22:05 thinkpad kernel:
> > ksys_write+0x4a/0xc0 Nov 22 15:22:05 thinkpad kernel:
> > do_syscall_64+0x35/0x

Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support

2021-11-22 Thread Alex Bee

Am 22.11.21 um 09:10 schrieb Sascha Hauer:
> Hi Alex,
>
> On Mon, Nov 22, 2021 at 12:18:47AM +0100, Alex Bee wrote:
>> Hi Sascha,
>>
>> Am 17.11.21 um 15:33 schrieb Sascha Hauer:
>>> This series adds initial graphics support for the Rockchip RK356[68]
>>> SoCs.  Graphics support is based around the VOP2 controller which
>>> replaces the VOP controller found on earlier Rockchip SoCs. The driver
>>> has been tested with HDMI support included in this series and MIPI-DSI
>>> which is not included because it needs some more work. The driver is
>>> taken from the downstream Rockchip kernel and heavily polished, most non
>>> standard features have been removed for now. I tested the driver with
>>> the libdrm modetest utility and also with weston with both pixman and
>>> panfrost driver support. Michael Riesch reported the driver to work on
>>> the RK3566 as well, but device tree support for this SoC is not yet
>>> included in this series.
>>>
>>> The HDMI changes are based on patches from Benjamin Gaignard, but
>>> modified a bit as I found out that the HDMI port on the RK3568 only
>>> needs one additional clock, not two. Also I added regulator support
>>> which is needed to get the HDMI up on the rk3568-EVB board.
>>>
>>> All review and testing feedback welcome
>>
>> thanks for working on that - it's very (very,very) much appreciated.
>>
>> It took me some time to figure it out: It seems rk3568-iommu driver s
>> broken - I did only get "white noise" when using it alongside vop
>> (similar like it was reported here before). However: removing the
>> iommu-property from vop makes it working for me with HDMI output on
>> quartz64 as well. Could you check if you have the iommu driver in kernel
>> enabled if it works for you, if the property is present in DT? (I used
>> 5.16-rc1 + this series + [0]).
> I have the iommu driver enabled and it works for me. I get this during
> boot:
>
> [0.263287] rockchip-vop2 fe04.vop: Adding to iommu group 0
>
> So I expect it is indeed used.
>
>> Also vop mmu seems to have the
>> power-domain missing in your series (same as downstream) - however
>> adding that doesn't help much currently.
> Probably the power domain gets enabled anyway when the VOP is activated,
> so adding it to the iommu won't help anything. Nevertheless it seems
> correct to add the property, I'll do so in the next round.
>
>> As a sidenote: I verfied this with using Ezequiel's vpu addtion for
>> RK356x: It did only work when removing the iommu there as well (getting
>> tons of page faults otherwise) - so iommu driver really seems to broken,
>> at least for RK3566. (Or I'm a missing a option in kernel config, which
>> wasn't required for the older iommu version?)
> I don't think so. I started from defconfig and disabled other
> architectures and unneeded drivers, but I did not enable anything
> specific to iommu.

I've found out now that I can make it work with iommu, by limiting the
available memory to something below 4G (I have a 8G board). So there is
something wrong in the driver or somewhere in memory mapping, iommu api
(since it works when using CMA), ... however: it does clearly not relate
to your patch.

>>  
>> But as reported before: For HDMI this does currently only work for pixel
>> clock rates, which are integer-divisable with hpll clock rate (which is
>> the hardcoded parent of vop0's dclk)
>> As discussed in Benjamin's initial submission of the addition of
>> RK3568's hdmi controller [1] same as with RK3288's and RK3399's hdmi phy
>> needs a reference clock (it's called vpll there) which needs to get
>> switched before the vop switches the mode (since phy rate switching is
>> done before) - it's HPLL in case of RK356x. For whatever reason it's
>> called "ref" for RK356x only downstream [2] - so you should add another
>> clock "vpll" (renaming it to "ref" for _ALL_ SoCs which have it would be
>> a _GREAT_ idea) which is <&pmucru PLL_HPLL>.
> Yeah, a consumer clock should be named after the usage in the consumer,
> not after the provider name. I also stumbled over this and naming it
> "ref" makes much more sense. We'll likely have to keep supporting "vpll"
> as well for compatibility to old device trees.
>
>> What brings us to the "real" clock problem and the reason, why
>> non-integer divisable pixel clock rates are not possible ATM: This is a
>> long standing issue for RK3288 and RK3399 as well (and one of the main
>> reasons why 4k modes are not possible for those older SoCs currently):
>> Upstream all PLL rates are controlled with those PLL rate tables in the
>> clock driver and they have to be _exactly_ defined as they are used
>> (HDMI sinks are very picky).
>> You will not see any additional rates downstream for RK3568: they have a
>> mechanism there to automatically calculate the PLL settings if the rate
>> doesn't exist in these tables (IIRC this was submitted upstream also:
>> but it was rejected/ignored by maintainers).
> Looks like we have to try harder to get it upstream. Do you have

Re: [PATCH 4/4] drm/msm/a6xx: Capture gmu log in devcoredump

2021-11-22 Thread Rob Clark

On Thu, Nov 18, 2021 at 2:21 AM Akhil P Oommen  wrote:
>
> Capture gmu log in coredump to enhance debugging.
>
> Signed-off-by: Akhil P Oommen 
> ---
>
>  drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41 
> +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c |  2 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h |  2 ++
>  3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> index 7501849..9fa3fa6 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> @@ -42,6 +42,8 @@ struct a6xx_gpu_state {
> struct a6xx_gpu_state_obj *cx_debugbus;
> int nr_cx_debugbus;
>
> +   struct msm_gpu_state_bo *gmu_log;
> +
> struct list_head objs;
>  };
>
> @@ -800,6 +802,30 @@ static void a6xx_get_gmu_registers(struct msm_gpu *gpu,
> &a6xx_state->gmu_registers[2], false);
>  }
>
> +static void a6xx_get_gmu_log(struct msm_gpu *gpu,
> +   struct a6xx_gpu_state *a6xx_state)
> +{
> +   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> +   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> +   struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> +   struct msm_gpu_state_bo *gmu_log;
> +
> +   gmu_log = state_kcalloc(a6xx_state,
> +   1, sizeof(*a6xx_state->gmu_log));
> +   if (!gmu_log)
> +   return;
> +
> +   gmu_log->iova = gmu->log.iova;
> +   gmu_log->size = gmu->log.size;
> +   gmu_log->data = kvzalloc(gmu_log->size, GFP_KERNEL);
> +   if (!gmu_log->data)
> +   return;
> +
> +   memcpy(gmu_log->data, gmu->log.virt, gmu->log.size);
> +
> +   a6xx_state->gmu_log = gmu_log;
> +}
> +
>  #define A6XX_GBIF_REGLIST_SIZE   1
>  static void a6xx_get_registers(struct msm_gpu *gpu,
> struct a6xx_gpu_state *a6xx_state,
> @@ -937,6 +963,8 @@ struct msm_gpu_state *a6xx_gpu_state_get(struct msm_gpu 
> *gpu)
>
> a6xx_get_gmu_registers(gpu, a6xx_state);
>
> +   a6xx_get_gmu_log(gpu, a6xx_state);
> +
> /* If GX isn't on the rest of the data isn't going to be accessible */
> if (!a6xx_gmu_gx_is_on(&a6xx_gpu->gmu))
> return &a6xx_state->base;
> @@ -978,6 +1006,9 @@ static void a6xx_gpu_state_destroy(struct kref *kref)
> struct a6xx_gpu_state *a6xx_state = container_of(state,
> struct a6xx_gpu_state, base);
>
> +   if (a6xx_state->gmu_log && a6xx_state->gmu_log->data)
> +   kvfree(a6xx_state->gmu_log->data);
> +
> list_for_each_entry_safe(obj, tmp, &a6xx_state->objs, node)
> kfree(obj);
>
> @@ -1191,6 +1222,16 @@ void a6xx_show(struct msm_gpu *gpu, struct 
> msm_gpu_state *state,
>
> adreno_show(gpu, state, p);
>
> +   drm_puts(p, "gmu-log:\n");
> +   if (a6xx_state->gmu_log) {
> +   struct msm_gpu_state_bo *gmu_log = a6xx_state->gmu_log;
> +
> +   drm_printf(p, "iova: 0x%016llx\n", gmu_log->iova);
> +   drm_printf(p, "size: %d\n", gmu_log->size);

fwiw, that wants to be:

 +   drm_printf(p, "size: %zu\n", gmu_log->size);

with that fixed, r-b

BR,
-R

> +   adreno_show_object(p, &gmu_log->data, gmu_log->size,
> +   &gmu_log->encoded);
> +   }
> +
> drm_puts(p, "registers:\n");
> for (i = 0; i < a6xx_state->nr_registers; i++) {
> struct a6xx_gpu_state_obj *obj = &a6xx_state->registers[i];
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 7486652..7d1ff20 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -630,7 +630,7 @@ static char *adreno_gpu_ascii85_encode(u32 *src, size_t 
> len)
>  }
>
>  /* len is expected to be in bytes */
> -static void adreno_show_object(struct drm_printer *p, void **ptr, int len,
> +void adreno_show_object(struct drm_printer *p, void **ptr, int len,
> bool *encoded)
>  {
> if (!*ptr || !len)
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 225c277..6762308 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -306,6 +306,8 @@ void adreno_gpu_state_destroy(struct msm_gpu_state 
> *state);
>
>  int adreno_gpu_state_get(struct msm_gpu *gpu, struct msm_gpu_state *state);
>  int adreno_gpu_state_put(struct msm_gpu_state *state);
> +void adreno_show_object(struct drm_printer *p, void **ptr, int len,
> +   bool *encoded);
>
>  /*
>   * Common helper function to initialize the default address space for 
> arm-smmu
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation.
>

Re: [PATCH 3/3] drm/i915/gt: Improve "race-to-idle" at low frequencies

2021-11-22 Thread Rodrigo Vivi

On Wed, Nov 17, 2021 at 02:49:55PM -0800, Vinay Belgaumkar wrote:
> From: Chris Wilson 
> 
> While the power consumption is proportional to the frequency, there is
> also a static draw for active gates. The longer we are able to powergate
> (rc6), the lower the static draw. Thus there is a sweetspot in the
> frequency/power curve where we run at higher frequency in order to sleep
> longer, aka race-to-idle. This is more evident at lower frequencies, so
> let's look to bump the frequency if we think we will benefit by sleeping
> longer at the higher frequency and so conserving power.
> 
> Signed-off-by: Chris Wilson 
> Cc: Vinay Belgaumkar 
> Cc: Tvrtko Ursulin 

Please let's not increase the complexity here, unless we have a very good
and documented reason.

Before trying to implement anything smart like this in the driver I'd like
to see data, power and performance results in different platforms and with
different workloads.

Thanks,
Rodrigo.

> ---
>  drivers/gpu/drm/i915/gt/intel_rps.c | 31 -
>  1 file changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 3675ac93ded0..6af3231982af 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -63,6 +63,22 @@ static void set(struct intel_uncore *uncore, i915_reg_t 
> reg, u32 val)
>   intel_uncore_write_fw(uncore, reg, val);
>  }
>  
> +static bool race_to_idle(struct intel_rps *rps, u64 busy, u64 dt)
> +{
> + unsigned int this = rps->cur_freq;
> + unsigned int next = rps->cur_freq + 1;
> + u64 next_dt = next * max(busy, dt);
> +
> + /*
> +  * Compare estimated time spent in rc6 at the next power bin. If
> +  * we expect to sleep longer than the estimated increased power
> +  * cost of running at a higher frequency, it will be reduced power
> +  * consumption overall.
> +  */
> + return (((next_dt - this * busy) >> 10) * this * this >
> + ((next_dt - next * busy) >> 10) * next * next);
> +}
> +
>  static void rps_timer(struct timer_list *t)
>  {
>   struct intel_rps *rps = from_timer(rps, t, timer);
> @@ -133,7 +149,7 @@ static void rps_timer(struct timer_list *t)
>   if (!max_busy[i])
>   break;
>  
> - busy += div_u64(max_busy[i], 1 << i);
> + busy += max_busy[i] >> i;
>   }
>   GT_TRACE(rps_to_gt(rps),
>"busy:%lld [%d%%], max:[%lld, %lld, %lld], 
> interval:%d\n",
> @@ -141,13 +157,18 @@ static void rps_timer(struct timer_list *t)
>max_busy[0], max_busy[1], max_busy[2],
>rps->pm_interval);
>  
> - if (100 * busy > rps->power.up_threshold * dt &&
> - rps->cur_freq < rps->max_freq_softlimit) {
> + if (rps->cur_freq < rps->max_freq_softlimit &&
> + race_to_idle(rps, max_busy[0], dt)) {
> + rps->pm_iir |= GEN6_PM_RP_UP_THRESHOLD;
> + rps->pm_interval = 1;
> + schedule_work(&rps->work);
> + } else if (rps->cur_freq < rps->max_freq_softlimit &&
> +100 * busy > rps->power.up_threshold * dt) {
>   rps->pm_iir |= GEN6_PM_RP_UP_THRESHOLD;
>   rps->pm_interval = 1;
>   schedule_work(&rps->work);
> - } else if (100 * busy < rps->power.down_threshold * dt &&
> -rps->cur_freq > rps->min_freq_softlimit) {
> + } else if (rps->cur_freq > rps->min_freq_softlimit &&
> +100 * busy < rps->power.down_threshold * dt) {
>   rps->pm_iir |= GEN6_PM_RP_DOWN_THRESHOLD;
>   rps->pm_interval = 1;
>   schedule_work(&rps->work);
> -- 
> 2.34.0
>

Re: [PATCH 4/4] drm/msm/a6xx: Capture gmu log in devcoredump

2021-11-22 Thread Rob Clark

On Mon, Nov 22, 2021 at 10:26 AM Rob Clark  wrote:
>
> On Thu, Nov 18, 2021 at 2:21 AM Akhil P Oommen  wrote:
> >
> > Capture gmu log in coredump to enhance debugging.
> >
> > Signed-off-by: Akhil P Oommen 
> > ---
> >
> >  drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41 
> > +
> >  drivers/gpu/drm/msm/adreno/adreno_gpu.c |  2 +-
> >  drivers/gpu/drm/msm/adreno/adreno_gpu.h |  2 ++
> >  3 files changed, 44 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c 
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > index 7501849..9fa3fa6 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > @@ -42,6 +42,8 @@ struct a6xx_gpu_state {
> > struct a6xx_gpu_state_obj *cx_debugbus;
> > int nr_cx_debugbus;
> >
> > +   struct msm_gpu_state_bo *gmu_log;
> > +
> > struct list_head objs;
> >  };
> >
> > @@ -800,6 +802,30 @@ static void a6xx_get_gmu_registers(struct msm_gpu *gpu,
> > &a6xx_state->gmu_registers[2], false);
> >  }
> >
> > +static void a6xx_get_gmu_log(struct msm_gpu *gpu,
> > +   struct a6xx_gpu_state *a6xx_state)
> > +{
> > +   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> > +   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> > +   struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
> > +   struct msm_gpu_state_bo *gmu_log;
> > +
> > +   gmu_log = state_kcalloc(a6xx_state,
> > +   1, sizeof(*a6xx_state->gmu_log));
> > +   if (!gmu_log)
> > +   return;
> > +
> > +   gmu_log->iova = gmu->log.iova;
> > +   gmu_log->size = gmu->log.size;
> > +   gmu_log->data = kvzalloc(gmu_log->size, GFP_KERNEL);
> > +   if (!gmu_log->data)
> > +   return;
> > +
> > +   memcpy(gmu_log->data, gmu->log.virt, gmu->log.size);
> > +
> > +   a6xx_state->gmu_log = gmu_log;
> > +}
> > +
> >  #define A6XX_GBIF_REGLIST_SIZE   1
> >  static void a6xx_get_registers(struct msm_gpu *gpu,
> > struct a6xx_gpu_state *a6xx_state,
> > @@ -937,6 +963,8 @@ struct msm_gpu_state *a6xx_gpu_state_get(struct msm_gpu 
> > *gpu)
> >
> > a6xx_get_gmu_registers(gpu, a6xx_state);
> >
> > +   a6xx_get_gmu_log(gpu, a6xx_state);
> > +
> > /* If GX isn't on the rest of the data isn't going to be accessible 
> > */
> > if (!a6xx_gmu_gx_is_on(&a6xx_gpu->gmu))
> > return &a6xx_state->base;
> > @@ -978,6 +1006,9 @@ static void a6xx_gpu_state_destroy(struct kref *kref)
> > struct a6xx_gpu_state *a6xx_state = container_of(state,
> > struct a6xx_gpu_state, base);
> >
> > +   if (a6xx_state->gmu_log && a6xx_state->gmu_log->data)
> > +   kvfree(a6xx_state->gmu_log->data);
> > +
> > list_for_each_entry_safe(obj, tmp, &a6xx_state->objs, node)
> > kfree(obj);
> >
> > @@ -1191,6 +1222,16 @@ void a6xx_show(struct msm_gpu *gpu, struct 
> > msm_gpu_state *state,
> >
> > adreno_show(gpu, state, p);
> >
> > +   drm_puts(p, "gmu-log:\n");
> > +   if (a6xx_state->gmu_log) {
> > +   struct msm_gpu_state_bo *gmu_log = a6xx_state->gmu_log;
> > +
> > +   drm_printf(p, "iova: 0x%016llx\n", gmu_log->iova);
> > +   drm_printf(p, "size: %d\n", gmu_log->size);
>
> fwiw, that wants to be:
>
>  +   drm_printf(p, "size: %zu\n", gmu_log->size);
>
> with that fixed, r-b

Hmm, actually, I seem to be getting an empty log.. is special gmu fw,
or non-fused device needed for this to work?

BR,
-R

> BR,
> -R
>
> > +   adreno_show_object(p, &gmu_log->data, gmu_log->size,
> > +   &gmu_log->encoded);
> > +   }
> > +
> > drm_puts(p, "registers:\n");
> > for (i = 0; i < a6xx_state->nr_registers; i++) {
> > struct a6xx_gpu_state_obj *obj = &a6xx_state->registers[i];
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 7486652..7d1ff20 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -630,7 +630,7 @@ static char *adreno_gpu_ascii85_encode(u32 *src, size_t 
> > len)
> >  }
> >
> >  /* len is expected to be in bytes */
> > -static void adreno_show_object(struct drm_printer *p, void **ptr, int len,
> > +void adreno_show_object(struct drm_printer *p, void **ptr, int len,
> > bool *encoded)
> >  {
> > if (!*ptr || !len)
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > index 225c277..6762308 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > @@ -306,6 +306,8 @@ void adreno_gpu_state_destroy(struct msm_gpu_state 
> > *state);
> >
> >  int adreno_gpu_state_get(struct msm_gpu *gpu, struct msm

Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support

2021-11-22 Thread Robin Murphy


On 2021-11-22 17:47, Alex Bee wrote:

Am 22.11.21 um 09:10 schrieb Sascha Hauer:

Hi Alex,

On Mon, Nov 22, 2021 at 12:18:47AM +0100, Alex Bee wrote:

Hi Sascha,

Am 17.11.21 um 15:33 schrieb Sascha Hauer:

This series adds initial graphics support for the Rockchip RK356[68]
SoCs.  Graphics support is based around the VOP2 controller which
replaces the VOP controller found on earlier Rockchip SoCs. The driver
has been tested with HDMI support included in this series and MIPI-DSI
which is not included because it needs some more work. The driver is
taken from the downstream Rockchip kernel and heavily polished, most non
standard features have been removed for now. I tested the driver with
the libdrm modetest utility and also with weston with both pixman and
panfrost driver support. Michael Riesch reported the driver to work on
the RK3566 as well, but device tree support for this SoC is not yet
included in this series.

The HDMI changes are based on patches from Benjamin Gaignard, but
modified a bit as I found out that the HDMI port on the RK3568 only
needs one additional clock, not two. Also I added regulator support
which is needed to get the HDMI up on the rk3568-EVB board.

All review and testing feedback welcome


thanks for working on that - it's very (very,very) much appreciated.

It took me some time to figure it out: It seems rk3568-iommu driver s
broken - I did only get "white noise" when using it alongside vop
(similar like it was reported here before). However: removing the
iommu-property from vop makes it working for me with HDMI output on
quartz64 as well. Could you check if you have the iommu driver in kernel
enabled if it works for you, if the property is present in DT? (I used
5.16-rc1 + this series + [0]).

I have the iommu driver enabled and it works for me. I get this during
boot:

[0.263287] rockchip-vop2 fe04.vop: Adding to iommu group 0

So I expect it is indeed used.


Also vop mmu seems to have the
power-domain missing in your series (same as downstream) - however
adding that doesn't help much currently.

Probably the power domain gets enabled anyway when the VOP is activated,
so adding it to the iommu won't help anything. Nevertheless it seems
correct to add the property, I'll do so in the next round.


As a sidenote: I verfied this with using Ezequiel's vpu addtion for
RK356x: It did only work when removing the iommu there as well (getting
tons of page faults otherwise) - so iommu driver really seems to broken,
at least for RK3566. (Or I'm a missing a option in kernel config, which
wasn't required for the older iommu version?)

I don't think so. I started from defconfig and disabled other
architectures and unneeded drivers, but I did not enable anything
specific to iommu.


I've found out now that I can make it work with iommu, by limiting the
available memory to something below 4G (I have a 8G board). So there is
something wrong in the driver or somewhere in memory mapping, iommu api
(since it works when using CMA), ... however: it does clearly not relate
to your patch.


FWIW it doesn't surprise me that there might still be bugs lurking in 
the IOMMU driver's relatively recent changes for packing 40-bit physical 
addresses into 32-bit pagetable entries and registers - that sort of 
thing is always tricky to get right. You're correct that that's 
something that wants debugging in its own right, though.


Robin.

Re: [Intel-gfx] [PATCH v6 1/6] drm/i915: Add support for moving fence waiting