Re: [PATCH] tty: vt: selection: Add check for valid tiocl_selection values

[Helge Deller]

Hello Jiri,

Thanks for looking into this patch!

On 8/4/22 07:47, Jiri Slaby wrote:
> On 30. 07. 22, 20:49, Helge Deller wrote:
>> The line and column numbers for the selection need to start at 1.
>> Add the checks to prevent invalid input.
>>
>> Signed-off-by: Helge Deller 
>> Reported-by: syzbot+14b0e8f3fd1612e35...@syzkaller.appspotmail.com
>>
>> diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
>> index f7755e73696e..58692a9b4097 100644
>> --- a/drivers/tty/vt/selection.c
>> +++ b/drivers/tty/vt/selection.c
>> @@ -326,6 +326,9 @@ static int vc_selection(struct vc_data *vc, struct 
>> tiocl_selection *v,
>>   return 0;
>>   }
>>
>> +    if (!v->xs || !v->ys || !v->xe || !v->ye)
>> +    return -EINVAL;
>
> Hmm, I'm not sure about this. It potentially breaks userspace (by
> returning EINVAL now).

Right.
According to the code below, my interpretation is that all xs/ys/xe/ye values
should be > 0. But of course I might be wrong on this, as I didn't find any
documentation for TIOCL_SETSEL.

And if userspace tries to set an invalid selection (e.g. by selecting row 0),
my patch now returns -EINVAL, while it returned success before.

> And the code below should handle this just fine, right:
>>   v->xs = min_t(u16, v->xs - 1, vc->vc_cols - 1);
>>   v->ys = min_t(u16, v->ys - 1, vc->vc_rows - 1);
>>   v->xe = min_t(u16, v->xe - 1, vc->vc_cols - 1);

It "handles it fine" in the sense that it can cope with the
input and will not crash.
But it returns (maybe?) unexpected results...

For example, if a user selects row 0 (where I assume he wanted to set
the first line), he instead selects the last row.
I'm not sure if this is the expected behaviour.

Do you know of any userspace program which breaks because of this?

Helge

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gt: document TLB cache invalidation functions

[Mauro Carvalho Chehab]

On Tue, 2 Aug 2022 15:30:44 -0700
Niranjana Vishwanathapura  wrote:

> On Fri, Jul 29, 2022 at 09:03:55AM +0200, Mauro Carvalho Chehab wrote:
> >Add a description for the TLB cache invalidation algorithm and for
> >the related kAPI functions.
> >
> >Signed-off-by: Mauro Carvalho Chehab 
> >---
> >
> >To avoid mailbombing on a large number of people, only mailing lists were 
> >C/C on the cover.
> >See [PATCH v2 0/2] at: 
> >https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/
> >
> > Documentation/gpu/i915.rst  |   7 ++
> > drivers/gpu/drm/i915/gt/intel_tlb.c |  25 +++
> > drivers/gpu/drm/i915/gt/intel_tlb.h | 101 
> > 3 files changed, 133 insertions(+)
> >
> >diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> >index 4e59db1cfb00..46911fdd79e8 100644
> >--- a/Documentation/gpu/i915.rst
> >+++ b/Documentation/gpu/i915.rst
> >@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
> > .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
> >:internal:
> >
> >+TLB cache invalidation
> >+--
> >+
> >+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
> >+
> >+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
> >+
> > Workarounds
> > ---
> >
> >diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
> >b/drivers/gpu/drm/i915/gt/intel_tlb.c
> >index af8cae979489..4873b7ecc015 100644
> >--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
> >+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
> >@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> > intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
> > }
> >
> >+/**
> >+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> >+ * @gt: GT structure
> >+ * @seqno: sequence number
> >+ *
> >+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
> >+ * full TLB cache invalidation.
> >+ *
> >+ * Note:
> >+ * The TLB cache invalidation logic depends on GEN-specific registers.
> >+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
> >+ */
> > void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
> > {
> > intel_wakeref_t wakeref;
> >@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
> >u32 seqno)
> > }
> > }
> >
> >+/**
> >+ * intel_gt_init_tlb - initialize TLB-specific vars
> >+ * @gt: GT structure
> >+ *
> >+ * TLB cache invalidation logic internally uses some resources that require
> >+ * initialization. Should be called before doing any TLB cache invalidation.
> >+ */
> > void intel_gt_init_tlb(struct intel_gt *gt)
> > {
> > mutex_init(>->tlb.invalidate_lock);
> > seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
> > }
> >
> >+/**
> >+ * intel_gt_fini_tlb - initialize TLB-specific vars  
> 
> Free TLB-specific vars

OK.

> 
> >+ * @gt: GT structure
> >+ *
> >+ * Frees any resources needed by TLB cache invalidation logic.
> >+ */
> > void intel_gt_fini_tlb(struct intel_gt *gt)
> > {
> > mutex_destroy(>->tlb.invalidate_lock);
> >diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h 
> >b/drivers/gpu/drm/i915/gt/intel_tlb.h
> >index 46ce25bf5afe..dca70c33bd61 100644
> >--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
> >+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
> >@@ -11,16 +11,117 @@
> >
> > #include "intel_gt_types.h"
> >
> >+/**
> >+ * DOC: TLB cache invalidation logic
> >+ *
> >+ * The way the current algorithm works is that a struct drm_i915_gem_object 
> >can
> >+ * be created on any order. At unbind/evict time, the object is warranted 
> >that
> >+ * it won't be used anymore. So, a sequence number provided by
> >+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen 
> >either
> >+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() - 
> >for
> >+ * VMA async VMA bind.
> >+ *
> >+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is 
> >called,
> >+ * where it checks if the sequence number of the object was already 
> >invalidated
> >+ * or not. If not, it flushes the TLB and increments the sequence number::
> >+ *
> >+ *   void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
> >+ *   {
> >+ *   ...
> >+ *  with_intel_gt_pm_if_awake(gt, wakeref) {
> >+ *  mutex_lock(>->tlb.invalidate_lock);
> >+ *  if (tlb_seqno_passed(gt, seqno))
> >+ *  goto unlock;
> >+ *
> >+ *  // Some code to do TLB invalidation
> >+ *   ...
> >+ *
> >+ *  write_seqcount_invalidate(>->tlb.seqno); // increment seqno
> >+ *  mutex_lock(>->tlb.invalidate_lock);
> >+ *  }
> >+ *
> >+ * So, let's say the current seqno is 2 and 3 new objects were created,
> >+ * on this order::
> >+ *
> >+ *  obj1
> >+ *  obj2
> >+ *  obj3
> >+ *
> >+ * They can be unbind/evict on a different order. At unbind/evict time,
> >+ * the mm.tlb will be stamped with the sequence number, using the number
> >+ * from the last TLB flush, plus 1.  
> 
> I am trying to g

mainline build failure due to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training support for PSP_V13")

[Sudip Mukherjee (Codethink)]

Hi All,

The latest mainline kernel branch fails to build for alpha and mips
allmodconfig with the error:

drivers/gpu/drm/amd/amdgpu/psp_v13_0.c: In function 'psp_v13_0_memory_training':
drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:23: error: implicit declaration of 
function 'vmalloc'; did you mean 'kvmalloc'? 
[-Werror=implicit-function-declaration]
  534 | buf = vmalloc(sz);
  |   ^~~
  |   kvmalloc
drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:21: error: assignment to 'void *' 
from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
  534 | buf = vmalloc(sz);
  | ^
drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:545:33: error: implicit declaration of 
function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
  545 | vfree(buf);
  | ^
  | kvfree

git bisect pointed to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training 
support for PSP_V13").

And, reverting that commit has fixed the build failure.

I will be happy to test any patch or provide any extra log if needed.

--
Regards
Sudip

[PATCH v3 2/3] drm/i915/gt: Move TLB invalidation to its own file

[Mauro Carvalho Chehab]

From: Chris Wilson 

Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.

It also:

- Renames intel_gt_invalidate_tlb() to intel_gt_invalidate_tlb_full()
- Add intel_gt_init_tlb() and intel_gt_fini_tlb() abstracts.

Signed-off-by: Chris Wilson 
Reviewed-by: Niranjana Vishwanathapura 
Reviewed-by: Andi Shyti 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v3 0/3] at: 
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 168 +---
 drivers/gpu/drm/i915/gt/intel_gt.h|  12 --
 drivers/gpu/drm/i915/gt/intel_tlb.c   | 183 ++
 drivers/gpu/drm/i915/gt/intel_tlb.h   |  29 
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 7 files changed, 219 insertions(+), 179 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..d3df9832d1f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,7 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+   gt/intel_tlb.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8357dbdcab5c..1cd76cc5d9f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,7 +7,7 @@
 #include 
 
 #include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
+#include "gt/intel_tlb.h"
 
 #include "i915_drv.h"
 #include "i915_gem_object.h"
@@ -199,7 +199,7 @@ static void flush_tlb_invalidate(struct drm_i915_gem_object 
*obj)
if (!obj->mm.tlb)
return;
 
-   intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+   intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
obj->mm.tlb = 0;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f435e06125aa..18d82cd620bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -11,9 +11,7 @@
 #include "pxp/intel_pxp.h"
 
 #include "i915_drv.h"
-#include "i915_perf_oa_regs.h"
 #include "intel_context.h"
-#include "intel_engine_pm.h"
 #include "intel_engine_regs.h"
 #include "intel_ggtt_gmch.h"
 #include "intel_gt.h"
@@ -31,6 +29,7 @@
 #include "intel_renderstate.h"
 #include "intel_rps.h"
 #include "intel_gt_sysfs.h"
+#include "intel_tlb.h"
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
@@ -48,8 +47,7 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
-   mutex_init(>->tlb.invalidate_lock);
-   seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
+   intel_gt_init_tlb(gt);
intel_gt_pm_init_early(gt);
 
intel_uc_init_early(>->uc);
@@ -770,7 +768,7 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
-   mutex_destroy(>->tlb.invalidate_lock);
+   intel_gt_fini_tlb(gt);
intel_engines_free(gt);
}
 }
@@ -881,163 +879,3 @@ void intel_gt_info_print(const struct intel_gt_info *info,
 
intel_sseu_dump(&info->sseu, p);
 }
-
-struct reg_and_bit {
-   i915_reg_t reg;
-   u32 bit;
-};
-
-static struct reg_and_bit
-get_reg_and_bit(const struct intel_engine_cs *engine, const bool gen8,
-   const i915_reg_t *regs, const unsigned int num)
-{
-   const unsigned int class = engine->class;
-   struct reg_and_bit rb = { };
-
-   if (drm_WARN_ON_ONCE(&engine->i915->drm,
-class >= num || !regs[class].reg))
-   return rb;
-
-   rb.reg = regs[class];
-   if (gen8 && class == VIDEO_DECODE_CLASS)
-   rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
-   else
-   rb.bit = engine->instance;
-
-   rb.bit = BIT(rb.bit);
-
-   return rb;
-}
-
-static void mmio_invalidate_full(struct intel_gt *gt)
-{
-   static const i915_reg_t gen8_regs[] = {
-   [RENDER_CLASS]  = GEN8_RTCR,
-   [VIDEO_DECODE_CLASS]= GEN8_M1TCR, /* , GEN8_M2TCR */
-   [VIDEO_ENHANCEMENT_CLASS]   = GEN8_VTCR,
-   [COPY_ENGINE_CLASS] = GEN8_BTCR,
-   };
-   static const i915_reg_t gen12_regs[] = {
-   [RENDER_CLASS]  

[PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

[Mauro Carvalho Chehab]

WRITE_ONCE() should happen at the original var, not on a local
copy of it.

Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")
Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v3 0/3] at: 
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
 drivers/gpu/drm/i915/i915_vma.c   | 6 +++---
 drivers/gpu/drm/i915/i915_vma.h   | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c 
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 2da6c82a8bd2..6ee8d1127016 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -211,7 +211,7 @@ void ppgtt_unbind_vma(struct i915_address_space *vm,
 
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
if (vma_res->tlb)
-   vma_invalidate_tlb(vm, *vma_res->tlb);
+   vma_invalidate_tlb(vm, vma_res->tlb);
 }
 
 static unsigned long pd_count(u64 size, int shift)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 84a9ccbc5fc5..260371716490 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1308,7 +1308,7 @@ I915_SELFTEST_EXPORT int i915_vma_get_pages(struct 
i915_vma *vma)
return err;
 }
 
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb)
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb)
 {
/*
 * Before we release the pages that were bound by this vma, we
@@ -1318,7 +1318,7 @@ void vma_invalidate_tlb(struct i915_address_space *vm, 
u32 tlb)
 * the most recent TLB invalidation seqno, and if we have not yet
 * flushed the TLBs upon release, perform a full invalidation.
 */
-   WRITE_ONCE(tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
+   WRITE_ONCE(*tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
 }
 
 static void __vma_put_pages(struct i915_vma *vma, unsigned int count)
@@ -1971,7 +1971,7 @@ struct dma_fence *__i915_vma_evict(struct i915_vma *vma, 
bool async)
dma_fence_put(unbind_fence);
unbind_fence = NULL;
}
-   vma_invalidate_tlb(vma->vm, vma->obj->mm.tlb);
+   vma_invalidate_tlb(vma->vm, &vma->obj->mm.tlb);
}
 
/*
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 5048eed536da..33a58f605d75 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -213,7 +213,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flags);
 void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
 void i915_vma_revoke_mmap(struct i915_vma *vma);
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb);
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb);
 struct dma_fence *__i915_vma_evict(struct i915_vma *vma, bool async);
 int __i915_vma_unbind(struct i915_vma *vma);
 int __must_check i915_vma_unbind(struct i915_vma *vma);
-- 
2.37.1

[PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions

[Mauro Carvalho Chehab]

Add a description for the TLB cache invalidation algorithm and for
the related kAPI functions.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v3 0/3] at: 
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/

 Documentation/gpu/i915.rst  |  7 ++
 drivers/gpu/drm/i915/gt/intel_tlb.c | 25 
 drivers/gpu/drm/i915/gt/intel_tlb.h | 99 +
 3 files changed, 131 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..46911fdd79e8 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
 .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
 
+TLB cache invalidation
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
+
 Workarounds
 ---
 
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index af8cae979489..16b918ffe824 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
 }
 
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
+ * @seqno: sequence number
+ *
+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
+ * full TLB cache invalidation.
+ *
+ * Note:
+ * The TLB cache invalidation logic depends on GEN-specific registers.
+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
+ */
 void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
 {
intel_wakeref_t wakeref;
@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
u32 seqno)
}
 }
 
+/**
+ * intel_gt_init_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * TLB cache invalidation logic internally uses some resources that require
+ * initialization. Should be called before doing any TLB cache invalidation.
+ */
 void intel_gt_init_tlb(struct intel_gt *gt)
 {
mutex_init(>->tlb.invalidate_lock);
seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
 }
 
+/**
+ * intel_gt_fini_tlb - free TLB-specific vars
+ * @gt: GT structure
+ *
+ * Frees any resources needed by TLB cache invalidation logic.
+ */
 void intel_gt_fini_tlb(struct intel_gt *gt)
 {
mutex_destroy(>->tlb.invalidate_lock);
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h 
b/drivers/gpu/drm/i915/gt/intel_tlb.h
index 46ce25bf5afe..2838c051f872 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
@@ -11,16 +11,115 @@
 
 #include "intel_gt_types.h"
 
+/**
+ * DOC: TLB cache invalidation logic
+ *
+ * The way the current algorithm works is that a struct drm_i915_gem_object can
+ * be created on any order. At unbind/evict time, the object is warranted that
+ * it won't be used anymore. So, a sequence number provided by
+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen either
+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() - for
+ * VMA async VMA bind.
+ *
+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is 
called,
+ * where it checks if the sequence number of the object was already invalidated
+ * or not. If not, it flushes the TLB and increments the sequence number::
+ *
+ *   void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
+ *   {
+ *   ...
+ * with_intel_gt_pm_if_awake(gt, wakeref) {
+ * mutex_lock(>->tlb.invalidate_lock);
+ * if (tlb_seqno_passed(gt, seqno))
+ * goto unlock;
+ *
+ * // Some code to do TLB invalidation
+ *   ...
+ *
+ * write_seqcount_invalidate(>->tlb.seqno); // increment seqno
+ * mutex_lock(>->tlb.invalidate_lock);
+ *  }
+ *
+ * So, let's say the current seqno is 2 and 3 new objects were created,
+ * on this order::
+ *
+ * obj1
+ * obj2
+ * obj3
+ *
+ * They can be unbind/evict on a different order. At unbind/evict time,
+ * the mm.tlb will be stamped with the sequence number, using the number
+ * from the last TLB flush, plus 1.
+ *
+ * Different threads may be used on unbind/evict and/or unset pages.
+ * As the logic at intel_gt_invalidate_tlb_full() is protected by a mutex,
+ * for simplicity, let's consider just two threads:
+ *
+ * 
+---+-+-+
+ * | sequence number   | Thread 0| Thread 1
+
+ * 
+===+=+=+
+ * | seqno=2   | | 
|
+ * |  

Re: New subsystem for acceleration devices

[Oded Gabbay]

On Thu, Aug 4, 2022 at 2:54 AM Dave Airlie  wrote:
>
> On Thu, 4 Aug 2022 at 06:21, Oded Gabbay  wrote:
> >
> > On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie  wrote:
> > >
> > > On Sun, 31 Jul 2022 at 22:04, Oded Gabbay  wrote:
> > > >
> > > > Hi,
> > > > Greg and I talked a couple of months ago about preparing a new accel
> > > > subsystem for compute/acceleration devices that are not GPUs and I
> > > > think your drivers that you are now trying to upstream fit it as well.
> > >
> > > We've had some submissions for not-GPUs to the drm subsystem recently.
> > >
> > > Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit.
> > >
> > > why is creating a new subsystem at this time necessary?
> > >
> > > Are we just creating a subsystem to avoid the open source userspace
> > > consumer rules? Or do we have some concrete reasoning behind it?
> > >
> > > Dave.
> >
> > Hi Dave.
> > The reason it happened now is because I saw two drivers, which are
> > doing h/w acceleration for AI, trying to be accepted to the misc
> > subsystem.
> > Add to that the fact I talked with Greg a couple of months ago about
> > doing a subsystem for any compute accelerators, which he was positive
> > about, I thought it is a good opportunity to finally do it.
> >
> > I also honestly think that I can contribute much to these drivers from
> > my experience with the habana driver (which is now deployed in mass at
> > AWS) and contribute code from the habana driver to a common framework
> > for AI drivers.
>
> Why not port the habana driver to drm now instead? I don't get why it
> wouldn't make sense?

imho, no, I don't see the upside. This is not a trivial change, and
will require a large effort. What will it give me that I need and I
don't have now ?

>
> Stepping up to create a new subsystem is great, but we need rules
> around what belongs where, we can't just spawn new subsystems when we
> have no clear guidelines on where drivers should land.
>
> What are the rules for a new accel subsystem? Do we have to now
> retarget the 3 drivers that are queued up to use drm for accelerators,
> because 2 drivers don't?
>
> There's a lot more to figure out here than merge some structures and
> it will be fine.
I totally agree. We need to set some rules and make sure everyone in
the kernel community is familiar with them, because now you get
different answers based on who you consult with.

My rules of thumb that I thought of was that if you don't have any
display (you don't need to support X/wayland) and you don't need to
support opengl/vulkan/opencl/directx or any other gpu-related software
stack, then you don't have to go through drm.
In other words, if you don't have gpu-specific h/w and/or you don't
need gpu uAPI, you don't belong in drm.

After all, memory management services, or common device chars handling
I can get from other subsystems (e.g. rdma) as well. I'm sure I could
model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI
there as well), but this doesn't mean I belong there, right ?

>
> I think the one area I can see a divide where a new subsystem is for
> accelerators that are single-user, one shot type things like media
> drivers (though maybe they could be just media drivers).
>
> I think anything that does command offloading to firmware or queues
> belongs in drm, because that is pretty much what the framework does. I
I think this is a very broad statement which doesn't reflect reality
in the kernel.

> think it might make sense to enhance some parts of drm to fit things
> in better, but that shouldn't block things getting started.
>
> I'm considering if, we should add an accelerator staging area to drm
> and land the 2-3 submissions we have and try and steer things towards
> commonality that way instead of holding them out of tree.
Sounds like a good idea regardless of this discussion.

>
> I'd like to offload things from Greg by just not having people submit
> misc drivers at all for things that should go elsewhere.
Great, at least we can agree on that.

Thanks,
Oded

>
> Dave.
>
>
> >
> > Regarding the open source userspace rules in drm - yes, I think your
> > rules are too limiting for the relatively young AI scene, and I saw at
> > the 2021 kernel summit that other people from the kernel community
> > think that as well.
> > But that's not the main reason, or even a reason at all for doing
> > this. After all, at least for habana, we open-sourced our compiler and
> > a runtime library. And Greg also asked those two drivers if they have
> > matching open-sourced user-space code.
> >
> > And a final reason is that I thought this can also help in somewhat
> > reducing the workload on Greg. I saw in the last kernel summit there
> > was a concern about bringing more people to be kernel maintainers so I
> > thought this is a step in the right direction.
> >
> > Oded

[PATCH v3 0/3] Move TLB invalidation code for its own file and document it

[Mauro Carvalho Chehab]

There are more things to be added to TLB invalidation. Before doing that,
move the code to its own file, and add the relevant documentation.

Patch 1 fixes vma_invalidate_tlb() logic to make it update the right var;

Patch 2 only moves the code and do some function renames. No functional
change;

Patch 3 adds documentation for the TLB invalidation algorithm and functions.

---

v3: 
  - Added a fix for an issue from the last TLB patch series;
  - included a better description about the changes on patch 2;
  - did some minor fixes at kernel-doc markups;

v2: only patch 2 (kernel-doc) was modified:

  - The kernel-doc markups for TLB were added to i915.rst doc;
  - Some minor fixes at the texts;
  - Use a table instead of a literal block while explaining how the algorithm 
works.
That should make easier to understand the logic, both in text form and after
its conversion to HTML/PDF;
  - Remove mention for GuC, as this depends on a series that will be sent later.



Chris Wilson (1):
  drm/i915/gt: Move TLB invalidation to its own file

Mauro Carvalho Chehab (2):
  drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()
  drm/i915/gt: document TLB cache invalidation functions

 Documentation/gpu/i915.rst|   7 +
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 168 +
 drivers/gpu/drm/i915/gt/intel_gt.h|  12 --
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   2 +-
 drivers/gpu/drm/i915/gt/intel_tlb.c   | 208 ++
 drivers/gpu/drm/i915/gt/intel_tlb.h   | 128 +
 drivers/gpu/drm/i915/i915_vma.c   |   7 +-
 drivers/gpu/drm/i915/i915_vma.h   |   2 +-
 10 files changed, 355 insertions(+), 184 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

-- 
2.37.1

[PATCH] drm/amd/display: restore plane with no modifiers code.

[Dave Airlie]

When this file was split in

5d945cbcd4b16a29d6470a80dfb19738f9a4319f
Author: Rodrigo Siqueira 
Date:   Wed Jul 20 15:31:42 2022 -0400

drm/amd/display: Create a file dedicated to planes

This chunk seemed to get dropped. Linus noticed on this
rx580 and I've reproduced on FIJI which makes sense as these
are pre-modifier GPUs.

With this applied, I get gdm back.

Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 8cd25b2ea0dc..b841b8b0a9d8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1591,6 +1591,9 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager 
*dm,
if (res)
return res;
 
+   if (modifiers == NULL)
+   adev_to_drm(dm->adev)->mode_config.fb_modifiers_not_supported = 
true;
+
res = drm_universal_plane_init(adev_to_drm(dm->adev), plane, 
possible_crtcs,
   &dm_plane_funcs, formats, num_formats,
   modifiers, plane->type, NULL);
-- 
2.37.1



--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH 1/2] drm/msm: Move hangcheck timer restart

[Akhil P Oommen]

On 8/4/2022 1:59 AM, Rob Clark wrote:

On Wed, Aug 3, 2022 at 12:52 PM Akhil P Oommen  wrote:

On 8/3/2022 10:53 PM, Rob Clark wrote:

From: Rob Clark 

Don't directly restart the hangcheck timer from the timer handler, but
instead start it after the recover_worker replays remaining jobs.

If the kthread is blocked for other reasons, there is no point to
immediately restart the timer.  Fixes a random symptom of the problem
fixed in the next patch.

Signed-off-by: Rob Clark 
---
   drivers/gpu/drm/msm/msm_gpu.c | 14 +-
   1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index fba85f894314..8f9c48eabf7d 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -328,6 +328,7 @@ find_submit(struct msm_ringbuffer *ring, uint32_t fence)
   }

   static void retire_submits(struct msm_gpu *gpu);
+static void hangcheck_timer_reset(struct msm_gpu *gpu);

   static void get_comm_cmdline(struct msm_gem_submit *submit, char **comm, 
char **cmd)
   {
@@ -420,6 +421,8 @@ static void recover_worker(struct kthread_work *work)
   }

   if (msm_gpu_active(gpu)) {
+ bool restart_hangcheck = false;
+
   /* retire completed submits, plus the one that hung: */
   retire_submits(gpu);

@@ -436,10 +439,15 @@ static void recover_worker(struct kthread_work *work)
   unsigned long flags;

   spin_lock_irqsave(&ring->submit_lock, flags);
- list_for_each_entry(submit, &ring->submits, node)
+ list_for_each_entry(submit, &ring->submits, node) {
   gpu->funcs->submit(gpu, submit);
+ restart_hangcheck = true;
+ }
   spin_unlock_irqrestore(&ring->submit_lock, flags);
   }
+
+ if (restart_hangcheck)
+ hangcheck_timer_reset(gpu);
   }

   mutex_unlock(&gpu->lock);
@@ -515,10 +523,6 @@ static void hangcheck_handler(struct timer_list *t)
   kthread_queue_work(gpu->worker, &gpu->recover_work);
   }

- /* if still more pending work, reset the hangcheck timer: */

In the scenario mentioned here, shouldn't we restart the timer?

yeah, actually the case where we don't want to restart the timer is
*only* when we schedule recover_work..

BR,
-R
Not sure if your codebase is different but based on msm-next branch, 
when "if (fence != ring->hangcheck_fence)" is true, we now skip 
rescheduling the timer. I don't think that is what we want. There should 
be a hangcheck timer running as long as there is an active submit, 
unless we have scheduled a recover_work here.


-Akhil.



-Akhil.

- if (fence_after(ring->fctx->last_fence, ring->hangcheck_fence))
- hangcheck_timer_reset(gpu);
-
   /* workaround for missing irq: */
   msm_gpu_retire(gpu);
   }

[PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect

[Takashi Iwai]

At both suspend and disconnect, we should rather cancel the pending
URBs immediately.  For the suspend case, the display will be turned
off, so it makes no sense to process the rendering.  And for the
disconnect case, the device may be no longer accessible, hence we
shouldn't do any submission.

Tested-by: Thomas Zimmermann 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/udl/udl_drv.h |  2 ++
 drivers/gpu/drm/udl/udl_main.c| 25 ++---
 drivers/gpu/drm/udl/udl_modeset.c |  2 ++
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index f01e50c5b7b7..28aaf75d71cf 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -39,6 +39,7 @@ struct urb_node {
 
 struct urb_list {
struct list_head list;
+   struct list_head in_flight;
spinlock_t lock;
wait_queue_head_t sleep;
int available;
@@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev)
 
 int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
 int udl_sync_pending_urbs(struct drm_device *dev);
+void udl_kill_pending_urbs(struct drm_device *dev);
 void udl_urb_completion(struct urb *urb);
 
 int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 93615648414b..47204b7eb10e 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */
 
spin_lock_irqsave(&udl->urbs.lock, flags);
-   list_add_tail(&unode->entry, &udl->urbs.list);
+   list_move(&unode->entry, &udl->urbs.list);
udl->urbs.available++;
spin_unlock_irqrestore(&udl->urbs.lock, flags);
 
@@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct drm_device *dev, int 
count, size_t size)
 retry:
udl->urbs.size = size;
INIT_LIST_HEAD(&udl->urbs.list);
+   INIT_LIST_HEAD(&udl->urbs.in_flight);
 
init_waitqueue_head(&udl->urbs.sleep);
udl->urbs.count = 0;
@@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev, 
long timeout)
}
 
unode = list_first_entry(&udl->urbs.list, struct urb_node, entry);
-   list_del_init(&unode->entry);
+   list_move(&unode->entry, &udl->urbs.in_flight);
udl->urbs.available--;
 
 unlock:
@@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
spin_lock_irq(&udl->urbs.lock);
/* 2 seconds as a sane timeout */
if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
-udl->urbs.available == udl->urbs.count,
+list_empty(&udl->urbs.in_flight),
 udl->urbs.lock,
 msecs_to_jiffies(2000)))
ret = -ETIMEDOUT;
@@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
return ret;
 }
 
+/* kill pending URBs */
+void udl_kill_pending_urbs(struct drm_device *dev)
+{
+   struct udl_device *udl = to_udl(dev);
+   struct urb_node *unode;
+
+   spin_lock_irq(&udl->urbs.lock);
+   while (!list_empty(&udl->urbs.in_flight)) {
+   unode = list_first_entry(&udl->urbs.in_flight,
+struct urb_node, entry);
+   spin_unlock_irq(&udl->urbs.lock);
+   usb_kill_urb(unode->urb);
+   spin_lock_irq(&udl->urbs.lock);
+   }
+   spin_unlock_irq(&udl->urbs.lock);
+}
+
 int udl_init(struct udl_device *udl)
 {
struct drm_device *dev = &udl->drm;
@@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
 {
struct udl_device *udl = to_udl(dev);
 
+   udl_kill_pending_urbs(dev);
udl_free_urb_list(dev);
put_device(udl->dmadev);
udl->dmadev = NULL;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 50025606b6ad..169110d8fc2e 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct 
drm_simple_display_pipe *pipe)
struct urb *urb;
char *buf;
 
+   udl_kill_pending_urbs(dev);
+
urb = udl_get_urb(dev);
if (!urb)
return;
-- 
2.35.3

[PATCH 0/4] drm/udl: Fix stray URBs and cleanup

[Takashi Iwai]

Hi,

this is a series of fixes for UDL driver to address the leftover URBs
at suspend/resume.  It begins with the simplification of FIFO control
code with the standard wait queue, followed by the handling of pending
URBs, and replace BUG_ON() with WARN_ON() as a cleanup.


Takashi

===

Takashi Iwai (4):
  drm/udl: Replace semaphore with a simple wait queue
  drm/udl: Sync pending URBs at suspend / disconnect
  drm/udl: Kill pending URBs at suspend and disconnect
  drm/udl: Replace BUG_ON() with WARN_ON()

 drivers/gpu/drm/udl/udl_drv.h  |  14 +++-
 drivers/gpu/drm/udl/udl_main.c | 125 ++---
 drivers/gpu/drm/udl/udl_modeset.c  |   4 +
 drivers/gpu/drm/udl/udl_transfer.c |   3 +-
 4 files changed, 79 insertions(+), 67 deletions(-)

-- 
2.35.3

[PATCH 1/4] drm/udl: Replace semaphore with a simple wait queue

[Takashi Iwai]

UDL driver uses a semaphore for controlling the emptiness of FIFO in a
slightly funky way.  This patch replaces it with a wait queue and
controls the emptiness with the standard wait_event*() macro instead,
which is a more straightforward implementation.

While we are at it, drop the dead code for delayed semaphore down,
too.

Tested-by: Thomas Zimmermann 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/udl/udl_drv.h  | 11 +++--
 drivers/gpu/drm/udl/udl_main.c | 84 ++
 2 files changed, 31 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index cc16a13316e4..e008686ec738 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -34,14 +34,13 @@ struct udl_device;
 struct urb_node {
struct list_head entry;
struct udl_device *dev;
-   struct delayed_work release_urb_work;
struct urb *urb;
 };
 
 struct urb_list {
struct list_head list;
spinlock_t lock;
-   struct semaphore limit_sem;
+   wait_queue_head_t sleep;
int available;
int count;
size_t size;
@@ -75,7 +74,13 @@ static inline struct usb_device *udl_to_usb_device(struct 
udl_device *udl)
 int udl_modeset_init(struct drm_device *dev);
 struct drm_connector *udl_connector_init(struct drm_device *dev);
 
-struct urb *udl_get_urb(struct drm_device *dev);
+struct urb *udl_get_urb_timeout(struct drm_device *dev, long timeout);
+
+#define GET_URB_TIMEOUTHZ
+static inline struct urb *udl_get_urb(struct drm_device *dev)
+{
+   return udl_get_urb_timeout(dev, GET_URB_TIMEOUT);
+}
 
 int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
 void udl_urb_completion(struct urb *urb);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 853f147036f6..67fd41e59b80 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -23,9 +23,6 @@
 #define WRITES_IN_FLIGHT (4)
 #define MAX_VENDOR_DESCRIPTOR_SIZE 256
 
-#define GET_URB_TIMEOUTHZ
-#define FREE_URB_TIMEOUT (HZ*2)
-
 static int udl_parse_vendor_descriptor(struct udl_device *udl)
 {
struct usb_device *udev = udl_to_usb_device(udl);
@@ -119,14 +116,6 @@ static int udl_select_std_channel(struct udl_device *udl)
return ret < 0 ? ret : 0;
 }
 
-static void udl_release_urb_work(struct work_struct *work)
-{
-   struct urb_node *unode = container_of(work, struct urb_node,
- release_urb_work.work);
-
-   up(&unode->dev->urbs.limit_sem);
-}
-
 void udl_urb_completion(struct urb *urb)
 {
struct urb_node *unode = urb->context;
@@ -150,23 +139,13 @@ void udl_urb_completion(struct urb *urb)
udl->urbs.available++;
spin_unlock_irqrestore(&udl->urbs.lock, flags);
 
-#if 0
-   /*
-* When using fb_defio, we deadlock if up() is called
-* while another is waiting. So queue to another process.
-*/
-   if (fb_defio)
-   schedule_delayed_work(&unode->release_urb_work, 0);
-   else
-#endif
-   up(&udl->urbs.limit_sem);
+   wake_up(&udl->urbs.sleep);
 }
 
 static void udl_free_urb_list(struct drm_device *dev)
 {
struct udl_device *udl = to_udl(dev);
int count = udl->urbs.count;
-   struct list_head *node;
struct urb_node *unode;
struct urb *urb;
 
@@ -174,23 +153,15 @@ static void udl_free_urb_list(struct drm_device *dev)
 
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
-   down(&udl->urbs.limit_sem);
-
-   spin_lock_irq(&udl->urbs.lock);
-
-   node = udl->urbs.list.next; /* have reserved one with sem */
-   list_del_init(node);
-
-   spin_unlock_irq(&udl->urbs.lock);
-
-   unode = list_entry(node, struct urb_node, entry);
-   urb = unode->urb;
-
+   urb = udl_get_urb_timeout(dev, MAX_SCHEDULE_TIMEOUT);
+   if (WARN_ON(!urb))
+   break;
+   unode = urb->context;
/* Free each separately allocated piece */
usb_free_coherent(urb->dev, udl->urbs.size,
  urb->transfer_buffer, urb->transfer_dma);
usb_free_urb(urb);
-   kfree(node);
+   kfree(unode);
}
udl->urbs.count = 0;
 }
@@ -210,7 +181,7 @@ static int udl_alloc_urb_list(struct drm_device *dev, int 
count, size_t size)
udl->urbs.size = size;
INIT_LIST_HEAD(&udl->urbs.list);
 
-   sema_init(&udl->urbs.limit_sem, 0);
+   init_waitqueue_head(&udl->urbs.sleep);
udl->urbs.count = 0;
udl->urbs.available = 0;
 
@@ -220,9 +191,6 @@ static int udl_alloc_urb_list(struct drm_device *dev, int 
count, size_t size)
break;
unode->dev = udl;
 
-   INIT_DELAY

[PATCH 2/4] drm/udl: Sync pending URBs at suspend / disconnect

[Takashi Iwai]

We need to wait for finishing to process the all URBs after disabling
the pipe; otherwise pending URBs may stray at suspend/resume, leading
to a possible memory corruption in a worst case.

Tested-by: Thomas Zimmermann 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/udl/udl_drv.h |  1 +
 drivers/gpu/drm/udl/udl_main.c| 17 +
 drivers/gpu/drm/udl/udl_modeset.c |  2 ++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index e008686ec738..f01e50c5b7b7 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -83,6 +83,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev)
 }
 
 int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
+int udl_sync_pending_urbs(struct drm_device *dev);
 void udl_urb_completion(struct urb *urb);
 
 int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 67fd41e59b80..93615648414b 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -270,6 +270,23 @@ int udl_submit_urb(struct drm_device *dev, struct urb 
*urb, size_t len)
return ret;
 }
 
+/* wait until all pending URBs have been processed */
+int udl_sync_pending_urbs(struct drm_device *dev)
+{
+   struct udl_device *udl = to_udl(dev);
+   int ret = 0;
+
+   spin_lock_irq(&udl->urbs.lock);
+   /* 2 seconds as a sane timeout */
+   if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
+udl->urbs.available == udl->urbs.count,
+udl->urbs.lock,
+msecs_to_jiffies(2000)))
+   ret = -ETIMEDOUT;
+   spin_unlock_irq(&udl->urbs.lock);
+   return ret;
+}
+
 int udl_init(struct udl_device *udl)
 {
struct drm_device *dev = &udl->drm;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index e67c40a48fb4..50025606b6ad 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -408,6 +408,8 @@ udl_simple_display_pipe_disable(struct 
drm_simple_display_pipe *pipe)
buf = udl_dummy_render(buf);
 
udl_submit_urb(dev, urb, buf - (char *)urb->transfer_buffer);
+
+   udl_sync_pending_urbs(dev);
 }
 
 static void
-- 
2.35.3

[PATCH 4/4] drm/udl: Replace BUG_ON() with WARN_ON()

[Takashi Iwai]

BUG_ON() is a tasteless choice as a sanity check for a driver like UDL
that isn't really a core code.  Replace with WARN_ON() and proper
error handling instead.

Tested-by: Thomas Zimmermann 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/udl/udl_main.c | 3 ++-
 drivers/gpu/drm/udl/udl_transfer.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 47204b7eb10e..fdafbf8f3c3c 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -260,7 +260,8 @@ int udl_submit_urb(struct drm_device *dev, struct urb *urb, 
size_t len)
struct udl_device *udl = to_udl(dev);
int ret;
 
-   BUG_ON(len > udl->urbs.size);
+   if (WARN_ON(len > udl->urbs.size))
+   return -EINVAL;
 
urb->transfer_buffer_length = len; /* set to actual payload len */
ret = usb_submit_urb(urb, GFP_ATOMIC);
diff --git a/drivers/gpu/drm/udl/udl_transfer.c 
b/drivers/gpu/drm/udl/udl_transfer.c
index 971927669d6b..176ef2a6a731 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -220,7 +220,8 @@ int udl_render_hline(struct drm_device *dev, int log_bpp, 
struct urb **urb_ptr,
u8 *cmd = *urb_buf_ptr;
u8 *cmd_end = (u8 *) urb->transfer_buffer + urb->transfer_buffer_length;
 
-   BUG_ON(!(log_bpp == 1 || log_bpp == 2));
+   if (WARN_ON(!(log_bpp == 1 || log_bpp == 2)))
+   return -EINVAL;
 
line_start = (u8 *) (front + byte_offset);
next_pixel = line_start;
-- 
2.35.3

Re: [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()

[Tvrtko Ursulin]

On 04/08/2022 08:37, Mauro Carvalho Chehab wrote:

WRITE_ONCE() should happen at the original var, not on a local
copy of it.

Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")


Cc: stable I think, since the above one was. So both hit 5.21 (or 6.1) 
together.


Regards,

Tvrtko


Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH v3 0/3] at: 
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/

  drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
  drivers/gpu/drm/i915/i915_vma.c   | 6 +++---
  drivers/gpu/drm/i915/i915_vma.h   | 2 +-
  3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c 
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 2da6c82a8bd2..6ee8d1127016 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -211,7 +211,7 @@ void ppgtt_unbind_vma(struct i915_address_space *vm,
  
  	vm->clear_range(vm, vma_res->start, vma_res->vma_size);

if (vma_res->tlb)
-   vma_invalidate_tlb(vm, *vma_res->tlb);
+   vma_invalidate_tlb(vm, vma_res->tlb);
  }
  
  static unsigned long pd_count(u64 size, int shift)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 84a9ccbc5fc5..260371716490 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1308,7 +1308,7 @@ I915_SELFTEST_EXPORT int i915_vma_get_pages(struct 
i915_vma *vma)
return err;
  }
  
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb)

+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb)
  {
/*
 * Before we release the pages that were bound by this vma, we
@@ -1318,7 +1318,7 @@ void vma_invalidate_tlb(struct i915_address_space *vm, 
u32 tlb)
 * the most recent TLB invalidation seqno, and if we have not yet
 * flushed the TLBs upon release, perform a full invalidation.
 */
-   WRITE_ONCE(tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
+   WRITE_ONCE(*tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
  }
  
  static void __vma_put_pages(struct i915_vma *vma, unsigned int count)

@@ -1971,7 +1971,7 @@ struct dma_fence *__i915_vma_evict(struct i915_vma *vma, 
bool async)
dma_fence_put(unbind_fence);
unbind_fence = NULL;
}
-   vma_invalidate_tlb(vma->vm, vma->obj->mm.tlb);
+   vma_invalidate_tlb(vma->vm, &vma->obj->mm.tlb);
}
  
  	/*

diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 5048eed536da..33a58f605d75 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -213,7 +213,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flags);
  void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
  void i915_vma_revoke_mmap(struct i915_vma *vma);
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb);
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb);
  struct dma_fence *__i915_vma_evict(struct i915_vma *vma, bool async);
  int __i915_vma_unbind(struct i915_vma *vma);
  int __must_check i915_vma_unbind(struct i915_vma *vma);

Re: [PATCH] drm: panel-orientation-quirks: Add quirk for Anbernic Win600

[Hans de Goede]

Hi,

On 8/3/22 20:24, Maccraft123 wrote:
> From: Maya Matuszczyk 
> 
> This device is another x86 gaming handheld, and as (hopefully) there is
> only one set of DMI IDs it's using DMI_EXACT_MATCH
> 
> Signed-off-by: Maya Matuszczyk 

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede 

Since we are currently in the middle of the merge window
and this patch needs to go to a -fixes branch I'm not quite
sure how to handle this.

Hopefully one of the drm-misc maintainers can pick this
up (once rc1 is out?) .

Regards,

Hans



> ---
>  drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index d4e0f2e85548..a8681610ede7 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -128,6 +128,12 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"),
>   },
>   .driver_data = (void *)&lcd800x1280_rightside_up,
> + }, {/* Anbernic Win600 */
> + .matches = {
> +   DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Anbernic"),
> +   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Win600"),
> + },
> + .driver_data = (void *)&lcd720x1280_rightside_up,
>   }, {/* Asus T100HA */
>   .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-03, Adam Ford wrote:
> On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch  wrote:
> >
> > On 22-08-02, Adam Ford wrote:
> >
> > ...
> >
> > > > I did some reading about the internal timing generator.  It appears
> > > > that it's required when video formats use fractional bytes, and it's
> > > > preconfigured to run at 720p by default, but registers 28h through 37h
> > > > configure it for other video modes.
> > >
> > > I think there may still be some issues with the DSIM since some of the
> > > clock frequencies are set in the device tree.
> > >
> > > From what I can tell, the pixel rate is calculated based on the
> >
> > By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes.
> > The ADV has an divider which is already configured by the driver but
> > meaningless since the driver is lacking of setting the "manual-divider"
> > bit within the same register.
> 
> I was thinking about the pixel clock from the DSI to the ADV.  I did
> see the manual-divider bit was missing.  I tried enabling that bit,
> but it didn't appear to make much difference.

This depends, e.g. I saw that the HDMI pixel clock is correct if I had
set this bit, set the divider manually to 6 and configured the dsi-host
burst clock to 891MHz:
  -> 891MHz / 2 = 445.5 (DSI-Clock) -> 445.5 / 6 = 74.25 (HDMI pixel
  clock for 720P)

Of course this doesn't happen automatically yet :( I also find it a bit
of too reduce the lane line, I had removed this logic too. But as I
said, I got no frames shown on my HDMI monitor.

...

> > > samsung,burst-clock-frequency = <15>;
> >
> > This is not correct since the burst-clock-freq. specifies the hs-clock
> > for the data lanes (see above).
> 
> But I don't think the clock should be fixed. I think it should vary as
> the resolution changes. 

You're right and this is something we have on our TODO list as well. But
this needs a bit more work within the DRM framework. So the client and
the host can negotiate the frequency.

Remember our main problem: with a correct burst-clock-frequency set and
lane number set for 720P, the ADV don't display anything.

> From what I can tell, NXP's DSI code doesn't
> hard code this value, but it does appear to cap it at 1.5G.  I did
> soom looking into the NXP frequency calculation

Can you provide me a link? There are a lot frequencies involved in this
discussion ^^ Just that I look at the same location.

> and it is capable of adjusting resolutions to some extent and from
> what I can see the 891MHz clock is only set when 1080p.  At 720p,
> thier kernel shows the output frequency at  445.5 MHz. 

Yes, we need the dynamic handling but hardcoding it isn't the way we
should go either. We have the dynamic PLL calculation, so we can
configure it to all possible values not just a few VESA standards.

> The way the DSIM is currently configured, it's fixed at 891MHz, so I
> don't expect the output feeding the adv7535 to be correct for the
> different resolutions.

Why not? The ADV can work with that hs-clock and for 720P@60 we need a
bandwidth of roughly (only pixels no package header/footer overhead):

  1280x720x24x60 = 1327104000 Bit/s = 1327.104 MBit/s

With 891MHz and 2 lanes we have

  891MBps * 2 = 178200 Bit/s = 1782 MBit/s

So this should be fine. With 445.5 MHz and 2 lanes we have not enough
bandwidth and with 445.5 MHz and 4 lanes we have exactly the same
bandwidth.

Therefore I still think that there is problem within the ADV.

...

> > > With these settings and the above mentioned code changes, 1080p still
> > > appears, however when attempting other modes, the display still fails
> > > to load.  I also noticed that the phy ref clock is set to 27MHz
> > > instead of NXP's 12MHz.
> >
> > That's interesting, I didn't noticed that NXP uses 12 MHz as refclock
> > but I don't think that this is the problem. Since we have other
> > converter chips using the bridge driver and they work fine. I still
> > think that the main problem is within the ADV driver.
> 
> Do the other converter chips work fine at different resolutions?

Yes.

> 
> >
> > > I attempted to play with that setting, but I couldn't get 1080p to
> > > work again, so I backed it out.
> > >
> > > Maybe I am headed in the wrong direction, but I'm going to examine the
> > > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in
> > > this code compares.
> >
> > I think the pms values are fine.
> 
> I compared the P/M/S values between this driver and NXP's and they
> calculate different values of PMS when running at 1080P.

NXP don't calculate anything if I remember correctly, they just provide
PLL values so they reach the frequency. On the other hand with the
patches from Jagan we can configure the PLL to what-ever value :)

> NXP @ 1080p:
> fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0
> 
> This kernel @ 1080p:
> 
> PLL freq 89100, (p 3, m 99, s 0)

As you said, we use a differnet fin value 27MHz instead of the 12MHz so
those values must be d

Re: [PATCH] tty: vt: selection: Add check for valid tiocl_selection values

[Helge Deller]

On 8/4/22 09:15, Helge Deller wrote:
> Hello Jiri,
>
> Thanks for looking into this patch!
>
> On 8/4/22 07:47, Jiri Slaby wrote:
>> On 30. 07. 22, 20:49, Helge Deller wrote:
>>> The line and column numbers for the selection need to start at 1.
>>> Add the checks to prevent invalid input.
>>>
>>> Signed-off-by: Helge Deller 
>>> Reported-by: syzbot+14b0e8f3fd1612e35...@syzkaller.appspotmail.com
>>>
>>> diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
>>> index f7755e73696e..58692a9b4097 100644
>>> --- a/drivers/tty/vt/selection.c
>>> +++ b/drivers/tty/vt/selection.c
>>> @@ -326,6 +326,9 @@ static int vc_selection(struct vc_data *vc, struct 
>>> tiocl_selection *v,
>>>   return 0;
>>>   }
>>>
>>> +    if (!v->xs || !v->ys || !v->xe || !v->ye)
>>> +    return -EINVAL;
>>
>> Hmm, I'm not sure about this. It potentially breaks userspace (by
>> returning EINVAL now).
>
> Right.
> According to the code below, my interpretation is that all xs/ys/xe/ye values
> should be > 0. But of course I might be wrong on this, as I didn't find any
> documentation for TIOCL_SETSEL.
>
> And if userspace tries to set an invalid selection (e.g. by selecting row 0),
> my patch now returns -EINVAL, while it returned success before.
>
>> And the code below should handle this just fine, right:
>>>   v->xs = min_t(u16, v->xs - 1, vc->vc_cols - 1);
>>>   v->ys = min_t(u16, v->ys - 1, vc->vc_rows - 1);
>>>   v->xe = min_t(u16, v->xe - 1, vc->vc_cols - 1);
>
> It "handles it fine" in the sense that it can cope with the
> input and will not crash.
> But it returns (maybe?) unexpected results...

After some more thinking maybe you are right.
In case a user provided invalid values in the past, simply an unexpected
selection was set, but nothing broke.
Since the patch doesn't fix any critical issue, we could just drop this patch
and leave it as is.

Helge

[PATCH v4 1/6] drm/ttm: Add new callbacks to ttm res mgr

[Arunpravin Paneer Selvam]

We are adding two new callbacks to ttm resource manager
function to handle intersection and compatibility of
placement and resources.

v2: move the amdgpu and ttm_range_manager changes to
separate patches (Christian)
v3: rename "intersect" to "intersects" (Matthew)

Signed-off-by: Christian König 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/ttm/ttm_resource.c | 59 ++
 include/drm/ttm/ttm_resource.h | 39 
 2 files changed, 98 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index 20f9adcc3235..357249630c37 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -253,6 +253,65 @@ void ttm_resource_free(struct ttm_buffer_object *bo, 
struct ttm_resource **res)
 }
 EXPORT_SYMBOL(ttm_resource_free);
 
+/**
+ * ttm_resource_intersects - test for intersection
+ *
+ * @bdev: TTM device structure
+ * @res: The resource to test
+ * @place: The placement to test
+ * @size: How many bytes the new allocation needs.
+ *
+ * Test if @res intersects with @place and @size. Used for testing if evictions
+ * are valueable or not.
+ *
+ * Returns true if the res placement intersects with @place and @size.
+ */
+bool ttm_resource_intersects(struct ttm_device *bdev,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+   struct ttm_resource_manager *man;
+
+   if (!res)
+   return false;
+
+   man = ttm_manager_type(bdev, res->mem_type);
+   if (!place || !man->func->intersects)
+   return true;
+
+   return man->func->intersects(man, res, place, size);
+}
+
+/**
+ * ttm_resource_compatible - test for compatibility
+ *
+ * @bdev: TTM device structure
+ * @res: The resource to test
+ * @place: The placement to test
+ * @size: How many bytes the new allocation needs.
+ *
+ * Test if @res compatible with @place and @size.
+ *
+ * Returns true if the res placement compatible with @place and @size.
+ */
+bool ttm_resource_compatible(struct ttm_device *bdev,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+   struct ttm_resource_manager *man;
+
+   if (!res)
+   return false;
+
+   man = ttm_manager_type(bdev, res->mem_type);
+   if (!place || !man->func->compatible)
+   return true;
+
+   return man->func->compatible(man, res, place, size);
+}
+
 static bool ttm_resource_places_compat(struct ttm_resource *res,
   const struct ttm_place *places,
   unsigned num_placement)
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index ca89a48c2460..b4914ca75230 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -88,6 +88,37 @@ struct ttm_resource_manager_func {
void (*free)(struct ttm_resource_manager *man,
 struct ttm_resource *res);
 
+   /**
+* struct ttm_resource_manager_func member intersects
+*
+* @man: Pointer to a memory type manager.
+* @res: Pointer to a struct ttm_resource to be checked.
+* @place: Placement to check against.
+* @size: Size of the check.
+*
+* Test if @res intersects with @place + @size. Used to judge if
+* evictions are valueable or not.
+*/
+   bool (*intersects)(struct ttm_resource_manager *man,
+  struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size);
+
+   /**
+* struct ttm_resource_manager_func member compatible
+*
+* @man: Pointer to a memory type manager.
+* @res: Pointer to a struct ttm_resource to be checked.
+* @place: Placement to check against.
+* @size: Size of the check.
+*
+* Test if @res compatible with @place + @size.
+*/
+   bool (*compatible)(struct ttm_resource_manager *man,
+  struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size);
+
/**
 * struct ttm_resource_manager_func member debug
 *
@@ -329,6 +360,14 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
   const struct ttm_place *place,
   struct ttm_resource **res);
 void ttm_resource_free(struct ttm_buffer_object *bo, struct ttm_resource 
**res);
+bool ttm_resource_intersects(struct ttm_device *bdev,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size);
+bool ttm_resource_compatible(struct ttm_device *

[PATCH v4 2/6] drm/ttm: Implement intersect/compatible functions

[Arunpravin Paneer Selvam]

Implemented a new intersect and compatible callback functions
to ttm range manager fetching start offset from drm mm range
allocator.

Signed-off-by: Christian König 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/ttm/ttm_range_manager.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index d91666721dc6..4cfef2b3514d 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -113,6 +113,37 @@ static void ttm_range_man_free(struct ttm_resource_manager 
*man,
kfree(node);
 }
 
+static bool ttm_range_man_intersects(struct ttm_resource_manager *man,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+   struct drm_mm_node *node = &to_ttm_range_mgr_node(res)->mm_nodes[0];
+   u32 num_pages = PFN_UP(size);
+
+   /* Don't evict BOs outside of the requested placement range */
+   if (place->fpfn >= (node->start + num_pages) ||
+   (place->lpfn && place->lpfn <= node->start))
+   return false;
+
+   return true;
+}
+
+static bool ttm_range_man_compatible(struct ttm_resource_manager *man,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+   struct drm_mm_node *node = &to_ttm_range_mgr_node(res)->mm_nodes[0];
+   u32 num_pages = PFN_UP(size);
+
+   if (node->start < place->fpfn ||
+   (place->lpfn && (node->start + num_pages) > place->lpfn))
+   return false;
+
+   return true;
+}
+
 static void ttm_range_man_debug(struct ttm_resource_manager *man,
struct drm_printer *printer)
 {
@@ -126,6 +157,8 @@ static void ttm_range_man_debug(struct ttm_resource_manager 
*man,
 static const struct ttm_resource_manager_func ttm_range_manager_func = {
.alloc = ttm_range_man_alloc,
.free = ttm_range_man_free,
+   .intersects = ttm_range_man_intersects,
+   .compatible = ttm_range_man_compatible,
.debug = ttm_range_man_debug
 };
 
-- 
2.25.1

[PATCH v4 3/6] drm/amdgpu: Implement intersect/compatible functions

[Arunpravin Paneer Selvam]

Implemented a new intersect and compatible callback function
fetching start offset from backend drm buddy allocator.

Signed-off-by: Christian König 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 38 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 68 
 2 files changed, 106 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 8c6b2284cf56..1f3302aebeff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -204,6 +204,42 @@ void amdgpu_gtt_mgr_recover(struct amdgpu_gtt_mgr *mgr)
amdgpu_gart_invalidate_tlb(adev);
 }
 
+/**
+ * amdgpu_gtt_mgr_intersects - test for intersection
+ *
+ * @man: Our manager object
+ * @res: The resource to test
+ * @place: The place for the new allocation
+ * @size: The size of the new allocation
+ *
+ * Simplified intersection test, only interesting if we need GART or not.
+ */
+static bool amdgpu_gtt_mgr_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+   return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+}
+
+/**
+ * amdgpu_gtt_mgr_compatible - test for compatibility
+ *
+ * @man: Our manager object
+ * @res: The resource to test
+ * @place: The place for the new allocation
+ * @size: The size of the new allocation
+ *
+ * Simplified compatibility test.
+ */
+static bool amdgpu_gtt_mgr_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+   return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+}
+
 /**
  * amdgpu_gtt_mgr_debug - dump VRAM table
  *
@@ -225,6 +261,8 @@ static void amdgpu_gtt_mgr_debug(struct 
ttm_resource_manager *man,
 static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func = {
.alloc = amdgpu_gtt_mgr_new,
.free = amdgpu_gtt_mgr_del,
+   .intersects = amdgpu_gtt_mgr_intersects,
+   .compatible = amdgpu_gtt_mgr_compatible,
.debug = amdgpu_gtt_mgr_debug
 };
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 7a5e8a7b4a1b..dcf2a6400e8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -720,6 +720,72 @@ uint64_t amdgpu_vram_mgr_vis_usage(struct amdgpu_vram_mgr 
*mgr)
return atomic64_read(&mgr->vis_usage);
 }
 
+/**
+ * amdgpu_vram_mgr_intersects - test each drm buddy block for intersection
+ *
+ * @man: TTM memory type manager
+ * @res: The resource to test
+ * @place: The place to test against
+ * @size: Size of the new allocation
+ *
+ * Test each drm buddy block for intersection for eviction decision.
+ */
+static bool amdgpu_vram_mgr_intersects(struct ttm_resource_manager *man,
+  struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size)
+{
+   struct amdgpu_vram_mgr_resource *mgr = to_amdgpu_vram_mgr_resource(res);
+   struct drm_buddy_block *block;
+
+   /* Check each drm buddy block individually */
+   list_for_each_entry(block, &mgr->blocks, link) {
+   unsigned long fpfn =
+   amdgpu_vram_mgr_block_start(block) >> PAGE_SHIFT;
+   unsigned long lpfn = fpfn +
+   (amdgpu_vram_mgr_block_size(block) >> PAGE_SHIFT);
+
+   if (place->fpfn < lpfn &&
+   (place->lpfn && place->lpfn > fpfn))
+   return true;
+   }
+
+   return false;
+}
+
+/**
+ * amdgpu_vram_mgr_compatible - test each drm buddy block for compatibility
+ *
+ * @man: TTM memory type manager
+ * @res: The resource to test
+ * @place: The place to test against
+ * @size: Size of the new allocation
+ *
+ * Test each drm buddy block for placement compatibility.
+ */
+static bool amdgpu_vram_mgr_compatible(struct ttm_resource_manager *man,
+  struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size)
+{
+   struct amdgpu_vram_mgr_resource *mgr = to_amdgpu_vram_mgr_resource(res);
+   struct drm_buddy_block *block;
+
+   /* Check each drm buddy block individually */
+   list_for_each_entry(block, &mgr->blocks, link) {
+   unsigned long fpfn =
+   amdgpu_vram_mgr_block_start(block) >> PAGE_SHIFT;
+   unsigned long lpfn = fpfn +
+   (amdgpu_vram_mgr_block_size(block) >> PAGE_SHIFT);
+
+   

[PATCH v4 5/6] drm/nouveau: Implement intersect/compatible functions

[Arunpravin Paneer Selvam]

Implemented a new intersect and compatible callback function
fetching the start offset from struct ttm_resource.

Signed-off-by: Christian König 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/nouveau/nouveau_mem.c | 29 +++
 drivers/gpu/drm/nouveau/nouveau_mem.h |  6 ++
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 24 ++
 3 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 2e517cdc24c9..76f8edefa637 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -187,3 +187,32 @@ nouveau_mem_new(struct nouveau_cli *cli, u8 kind, u8 comp,
*res = &mem->base;
return 0;
 }
+
+bool
+nouveau_mem_intersects(struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size)
+{
+   u32 num_pages = PFN_UP(size);
+
+   /* Don't evict BOs outside of the requested placement range */
+   if (place->fpfn >= (res->start + num_pages) ||
+   (place->lpfn && place->lpfn <= res->start))
+   return false;
+
+   return true;
+}
+
+bool
+nouveau_mem_compatible(struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size)
+{
+   u32 num_pages = PFN_UP(size);
+
+   if (res->start < place->fpfn ||
+   (place->lpfn && (res->start + num_pages) > place->lpfn))
+   return false;
+
+   return true;
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.h 
b/drivers/gpu/drm/nouveau/nouveau_mem.h
index 325551eba5cd..1ee6cdb9ad9b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.h
@@ -25,6 +25,12 @@ int nouveau_mem_new(struct nouveau_cli *, u8 kind, u8 comp,
struct ttm_resource **);
 void nouveau_mem_del(struct ttm_resource_manager *man,
 struct ttm_resource *);
+bool nouveau_mem_intersects(struct ttm_resource *res,
+   const struct ttm_place *place,
+   size_t size);
+bool nouveau_mem_compatible(struct ttm_resource *res,
+   const struct ttm_place *place,
+   size_t size);
 int nouveau_mem_vram(struct ttm_resource *, bool contig, u8 page);
 int nouveau_mem_host(struct ttm_resource *, struct ttm_tt *);
 void nouveau_mem_fini(struct nouveau_mem *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 85f1f5a0fe5d..9602c30928f2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -42,6 +42,24 @@ nouveau_manager_del(struct ttm_resource_manager *man,
nouveau_mem_del(man, reg);
 }
 
+static bool
+nouveau_manager_intersects(struct ttm_resource_manager *man,
+  struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size)
+{
+   return nouveau_mem_intersects(res, place, size);
+}
+
+static bool
+nouveau_manager_compatible(struct ttm_resource_manager *man,
+  struct ttm_resource *res,
+  const struct ttm_place *place,
+  size_t size)
+{
+   return nouveau_mem_compatible(res, place, size);
+}
+
 static int
 nouveau_vram_manager_new(struct ttm_resource_manager *man,
 struct ttm_buffer_object *bo,
@@ -73,6 +91,8 @@ nouveau_vram_manager_new(struct ttm_resource_manager *man,
 const struct ttm_resource_manager_func nouveau_vram_manager = {
.alloc = nouveau_vram_manager_new,
.free = nouveau_manager_del,
+   .intersects = nouveau_manager_intersects,
+   .compatible = nouveau_manager_compatible,
 };
 
 static int
@@ -97,6 +117,8 @@ nouveau_gart_manager_new(struct ttm_resource_manager *man,
 const struct ttm_resource_manager_func nouveau_gart_manager = {
.alloc = nouveau_gart_manager_new,
.free = nouveau_manager_del,
+   .intersects = nouveau_manager_intersects,
+   .compatible = nouveau_manager_compatible,
 };
 
 static int
@@ -130,6 +152,8 @@ nv04_gart_manager_new(struct ttm_resource_manager *man,
 const struct ttm_resource_manager_func nv04_gart_manager = {
.alloc = nv04_gart_manager_new,
.free = nouveau_manager_del,
+   .intersects = nouveau_manager_intersects,
+   .compatible = nouveau_manager_compatible,
 };
 
 static int
-- 
2.25.1

[PATCH v4 4/6] drm/i915: Implement intersect/compatible functions

[Arunpravin Paneer Selvam]

Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.

v3: move the bits that are specific to buddy_man (Matthew)
v4: consider the block size /range (Matthew)

Signed-off-by: Christian König 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 41 +--
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 73 +++
 2 files changed, 74 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 70e2ed4e99df..bf5fd6886ca0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -379,7 +379,6 @@ static bool i915_ttm_eviction_valuable(struct 
ttm_buffer_object *bo,
   const struct ttm_place *place)
 {
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
-   struct ttm_resource *res = bo->resource;
 
if (!obj)
return false;
@@ -396,45 +395,7 @@ static bool i915_ttm_eviction_valuable(struct 
ttm_buffer_object *bo,
if (!i915_gem_object_evictable(obj))
return false;
 
-   switch (res->mem_type) {
-   case I915_PL_LMEM0: {
-   struct ttm_resource_manager *man =
-   ttm_manager_type(bo->bdev, res->mem_type);
-   struct i915_ttm_buddy_resource *bman_res =
-   to_ttm_buddy_resource(res);
-   struct drm_buddy *mm = bman_res->mm;
-   struct drm_buddy_block *block;
-
-   if (!place->fpfn && !place->lpfn)
-   return true;
-
-   GEM_BUG_ON(!place->lpfn);
-
-   /*
-* If we just want something mappable then we can quickly check
-* if the current victim resource is using any of the CPU
-* visible portion.
-*/
-   if (!place->fpfn &&
-   place->lpfn == i915_ttm_buddy_man_visible_size(man))
-   return bman_res->used_visible_size > 0;
-
-   /* Real range allocation */
-   list_for_each_entry(block, &bman_res->blocks, link) {
-   unsigned long fpfn =
-   drm_buddy_block_offset(block) >> PAGE_SHIFT;
-   unsigned long lpfn = fpfn +
-   (drm_buddy_block_size(mm, block) >> PAGE_SHIFT);
-
-   if (place->fpfn < lpfn && place->lpfn > fpfn)
-   return true;
-   }
-   return false;
-   } default:
-   break;
-   }
-
-   return true;
+   return ttm_bo_eviction_valuable(bo, place);
 }
 
 static void i915_ttm_evict_flags(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c 
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index a5109548abc0..9def01d5f368 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -178,6 +178,77 @@ static void i915_ttm_buddy_man_free(struct 
ttm_resource_manager *man,
kfree(bman_res);
 }
 
+static bool i915_ttm_buddy_man_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+   struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+   struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+   struct drm_buddy *mm = &bman->mm;
+   struct drm_buddy_block *block;
+
+   if (!place->fpfn && !place->lpfn)
+   return true;
+
+   GEM_BUG_ON(!place->lpfn);
+
+   /*
+* If we just want something mappable then we can quickly check
+* if the current victim resource is using any of the CP
+* visible portion.
+*/
+   if (!place->fpfn &&
+   place->lpfn == i915_ttm_buddy_man_visible_size(man))
+   return bman_res->used_visible_size > 0;
+
+   /* Check each drm buddy block individually */
+   list_for_each_entry(block, &bman_res->blocks, link) {
+   unsigned long fpfn =
+   drm_buddy_block_offset(block) >> PAGE_SHIFT;
+   unsigned long lpfn = fpfn +
+   (drm_buddy_block_size(mm, block) >> PAGE_SHIFT);
+
+   if (place->fpfn < lpfn && place->lpfn > fpfn)
+   return true;
+   }
+
+   return false;
+}
+
+static bool i915_ttm_buddy_man_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+   struct i915_ttm_buddy_resource *bman_res = t

[PATCH v4 6/6] drm/ttm: Switch to using the new res callback

[Arunpravin Paneer Selvam]

Apply new intersect and compatible callback instead
of having a generic placement range verfications.

v2: Added a separate callback for compatiblilty
checks (Christian)

Signed-off-by: Christian König 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 45 +++--
 drivers/gpu/drm/ttm/ttm_bo.c|  9 +++--
 drivers/gpu/drm/ttm/ttm_resource.c  |  5 +--
 3 files changed, 20 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 170935c294f5..7d25a10395c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1328,11 +1328,12 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
*adev, struct ttm_tt *ttm,
 static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
 {
-   unsigned long num_pages = bo->resource->num_pages;
struct dma_resv_iter resv_cursor;
-   struct amdgpu_res_cursor cursor;
struct dma_fence *f;
 
+   if (!amdgpu_bo_is_amdgpu_bo(bo))
+   return ttm_bo_eviction_valuable(bo, place);
+
/* Swapout? */
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -1351,40 +1352,20 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct 
ttm_buffer_object *bo,
return false;
}
 
-   switch (bo->resource->mem_type) {
-   case AMDGPU_PL_PREEMPT:
-   /* Preemptible BOs don't own system resources managed by the
-* driver (pages, VRAM, GART space). They point to resources
-* owned by someone else (e.g. pageable memory in user mode
-* or a DMABuf). They are used in a preemptible context so we
-* can guarantee no deadlocks and good QoS in case of MMU
-* notifiers or DMABuf move notifiers from the resource owner.
-*/
+   /* Preemptible BOs don't own system resources managed by the
+* driver (pages, VRAM, GART space). They point to resources
+* owned by someone else (e.g. pageable memory in user mode
+* or a DMABuf). They are used in a preemptible context so we
+* can guarantee no deadlocks and good QoS in case of MMU
+* notifiers or DMABuf move notifiers from the resource owner.
+*/
+   if (bo->resource->mem_type == AMDGPU_PL_PREEMPT)
return false;
-   case TTM_PL_TT:
-   if (amdgpu_bo_is_amdgpu_bo(bo) &&
-   amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
-   return false;
-   return true;
 
-   case TTM_PL_VRAM:
-   /* Check each drm MM node individually */
-   amdgpu_res_first(bo->resource, 0, (u64)num_pages << PAGE_SHIFT,
-&cursor);
-   while (cursor.remaining) {
-   if (place->fpfn < PFN_DOWN(cursor.start + cursor.size)
-   && !(place->lpfn &&
-place->lpfn <= PFN_DOWN(cursor.start)))
-   return true;
-
-   amdgpu_res_next(&cursor, cursor.size);
-   }
+   if (bo->resource->mem_type == TTM_PL_TT &&
+   amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
return false;
 
-   default:
-   break;
-   }
-
return ttm_bo_eviction_valuable(bo, place);
 }
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c1bd006a5525..f066e8124c50 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
 bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
  const struct ttm_place *place)
 {
+   struct ttm_resource *res = bo->resource;
+   struct ttm_device *bdev = bo->bdev;
+
dma_resv_assert_held(bo->base.resv);
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -525,11 +528,7 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
/* Don't evict this BO if it's outside of the
 * requested placement range
 */
-   if (place->fpfn >= (bo->resource->start + bo->resource->num_pages) ||
-   (place->lpfn && place->lpfn <= bo->resource->start))
-   return false;
-
-   return true;
+   return ttm_resource_intersects(bdev, res, place, bo->base.size);
 }
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index 357249630c37..3d70e0f50a88 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -316,6 +316,8 @@ static bool ttm_resource_places_compat(struct ttm_resource 
*res,
   

Re: [Intel-gfx] [PATCH v5 1/7] drm: Move and add a few utility macros into drm util header

[Andi Shyti]

Hi Jani,

> >> It moves overflows_type utility macro into drm util header from i915_utils
> >> header. The overflows_type can be used to catch the truncation between data
> >> types. And it adds safe_conversion() macro which performs a type conversion
> >> (cast) of an source value into a new variable, checking that the
> >> destination is large enough to hold the source value.
> >> And it adds exact_type and exactly_pgoff_t macro to catch type mis-match
> >> while compiling.
> >> 
> >> v3: Add is_type_unsigned() macro (Mauro)
> >> Modify overflows_type() macro to consider signed data types (Mauro)
> >> Fix the problem that safe_conversion() macro always returns true
> >> v4: Fix kernel-doc markups
> >> 
> >> Signed-off-by: Gwan-gyeong Mun 
> >> Cc: Thomas Hellström 
> >> Cc: Matthew Auld 
> >> Cc: Nirmoy Das 
> >> Cc: Jani Nikula 
> >> Reviewed-by: Mauro Carvalho Chehab 
> >> ---
> >>  drivers/gpu/drm/i915/i915_utils.h |  5 +-
> >>  include/drm/drm_util.h| 77 +++
> >>  2 files changed, 78 insertions(+), 4 deletions(-)
> >
> > Jani and Mauro suggested to have this macro in
> > include/drm/drm_util.h.
> 
> I can't recall suggesting such a thing. The macros in question have
> nothing specifically to do with i915 *or* drm. They are generic, and
> should be in generic kernel headers.
> 
> We must stop piling up generic and generally useful stuff in our own
> headers.

Yes, I agree with you and I think there was already such
discussion whether to move this into generic kernel headers or in
drm header.

Gwan-gyeong, any thoughts or further plans to move this to a
different place? It's been already three people (and I'm
including myself here) recommending to have this in a different
place.

Andi

> I thought I've been clear about this all along.

Thanks, Jani!

Andi

Re: [PATCH] tty: vt: selection: Add check for valid tiocl_selection values

[Jiri Slaby]

On 04. 08. 22, 10:44, Helge Deller wrote:

On 8/4/22 09:15, Helge Deller wrote:

Hello Jiri,

Thanks for looking into this patch!

On 8/4/22 07:47, Jiri Slaby wrote:

On 30. 07. 22, 20:49, Helge Deller wrote:

The line and column numbers for the selection need to start at 1.
Add the checks to prevent invalid input.

Signed-off-by: Helge Deller 
Reported-by: syzbot+14b0e8f3fd1612e35...@syzkaller.appspotmail.com

diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index f7755e73696e..58692a9b4097 100644
--- a/drivers/tty/vt/selection.c
+++ b/drivers/tty/vt/selection.c
@@ -326,6 +326,9 @@ static int vc_selection(struct vc_data *vc, struct 
tiocl_selection *v,
   return 0;
   }

+    if (!v->xs || !v->ys || !v->xe || !v->ye)
+    return -EINVAL;


Hmm, I'm not sure about this. It potentially breaks userspace (by
returning EINVAL now).


Right.
According to the code below, my interpretation is that all xs/ys/xe/ye values
should be > 0. But of course I might be wrong on this, as I didn't find any
documentation for TIOCL_SETSEL.

And if userspace tries to set an invalid selection (e.g. by selecting row 0),
my patch now returns -EINVAL, while it returned success before.


And the code below should handle this just fine, right:

   v->xs = min_t(u16, v->xs - 1, vc->vc_cols - 1);
   v->ys = min_t(u16, v->ys - 1, vc->vc_rows - 1);
   v->xe = min_t(u16, v->xe - 1, vc->vc_cols - 1);


It "handles it fine" in the sense that it can cope with the
input and will not crash.
But it returns (maybe?) unexpected results...


After some more thinking maybe you are right.
In case a user provided invalid values in the past, simply an unexpected
selection was set, but nothing broke.
Since the patch doesn't fix any critical issue, we could just drop this patch
and leave it as is.


We can still do a trial and revert it if something breaks... It's just 
that _noone_ knows with all this undocumented stuff ;).


But in fact, 0 currently means full row/column. Isn't it on purpose?

Today, we are out of luck, codesearch.debian.net gives no clue about users:
https://codesearch.debian.net/search?q=%5CbTIOCL_SETSEL%5Cb&literal=0

thanks,
--
js
suse labs

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Dave, Adam,

On 22-08-03, Dave Stevenson wrote:
> Hi Adam
> 
> On Wed, 3 Aug 2022 at 12:03, Adam Ford  wrote:

...

> > > Did managed to get access to the ADV7535 programming guide? This is the
> > > black box here. Let me check if I can provide you a link with our repo
> > > so you can test our current DSIM state if you want.
> >
> > I do have access to the programming guide, but it's under NDA, but
> > I'll try to answer questions if I can.
> 
> Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> from previously looking at these chips.

Thanks for stepping into :)

> Mine fairly plainly states:
> "The DSI receiver input supports DSI video mode operation only, and
> specifically, only supports nonburst mode with sync pulses".

I've read this also, and we are working in nonburst mode with sync
pulses. I have no access to an MIPI-DSI analyzer therefore I can't
verify it.

> Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> HDMI pixel rate.

On DSI side you don't have a pixel-clock instead there is bit-clock.

> Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> even more explicit about the requirement of DSI timing matching

Is it possible to share the key points of the requirements?

> The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> be correct for 720p operation.

It should be absolute no difference if you work on 891MHz with 2 lanes
or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
GBps.

> If you do program the manual DSI divider register to allow a DSI pixel
> rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on

There is no such DSI pixel rate to be precise, we only have a DSI bit
clock/rate.

> the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> tx to compensate for the differing data rates. I see no reference to
> such, and I'd be surprised if it was more than a half dozen pixels to
> compensate for the jitter in the cases where the internal timing
> generator is mandatory due to fractional bytes.

This is interesting and would proofs our assumption that the device
don't have a FIFO :)

Our assumptions (we don't have the datasheet/programming manual):
  - HDMI part is fetching 3 bytes per HDMI pixclk
  - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
HDMI are in sync. So from bandwidth pov there are no differences
between:
  - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
  - DSI:891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
  - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)

But the ratio is different and therefore the faster clocking option
let something 'overflow'.

Anyway, but all this means that Adam should configure the
burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
either and now we are back on my initial statement -> the driver needs
some attention.

Regards,
  Marco

Re: [PATCH] drm: fix whitespace in drm_plane_create_color_properties()

[Jani Nikula]

On Wed, 03 Aug 2022, Simon Ser  wrote:
> The drm_property_create_enum() call for "COLOR_RANGE" contains a tab
> character in the middle of the argument list.
>
> Signed-off-by: Simon Ser 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/drm_color_mgmt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 17c6c3eefcd6..d021497841b8 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -575,7 +575,7 @@ int drm_plane_create_color_properties(struct drm_plane 
> *plane,
>   len++;
>   }
>  
> - prop = drm_property_create_enum(dev, 0, "COLOR_RANGE",
> + prop = drm_property_create_enum(dev, 0, "COLOR_RANGE",
>   enum_list, len);
>   if (!prop)
>   return -ENOMEM;

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support

[Alice Chen]

Pavel Machek  於 2022年7月31日 週日 清晨5:42寫道：

> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2022 Richtek Technology Corp.
> > + *
> > + * Author: Alice Chen 
> Add ">" at end of line.
>
> The series is quite big, would it be possible to submit LED changes
> in separate series?
>
Hi Pavel,

Our mfd dt-bindings depends on flash and LED dt-bindings,
but our flash and LED config depend on mfd config.
For the dependency consideration,
we think submitting them in a patch series is better.

Best Regards,
Alice

Re: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance calculation function

[Jani Nikula]

On Tue, 19 Jul 2022, Jouni Högander  wrote:
> Luminance range calculation was split out into drm_edid.c and is now
> part of edid parsing. Rely on values calculated during edid parsing and
> use these for caps->aux_max_input_signal and caps->aux_min_input_signal.

Harry, I'll merge patches 1 & 3 in this series through drm-misc-next,
because I think they're good to go, and fix stuff in i915.

Can I get your rb/ack to merge this patch as well, or do you want to
take this later via your tree?

BR,
Jani.


>
> v2: Use values calculated during edid parsing
>
> Cc: Roman Li 
> Cc: Rodrigo Siqueira 
> Cc: Harry Wentland 
> Cc: Lyude Paul 
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Jouni Högander 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 +++
>  1 file changed, 4 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3e83fed540e8..eb7abdeb8653 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2903,15 +2903,12 @@ static struct drm_mode_config_helper_funcs 
> amdgpu_dm_mode_config_helperfuncs = {
>  
>  static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
>  {
> - u32 max_avg, min_cll, max, min, q, r;
>   struct amdgpu_dm_backlight_caps *caps;
>   struct amdgpu_display_manager *dm;
>   struct drm_connector *conn_base;
>   struct amdgpu_device *adev;
>   struct dc_link *link = NULL;
> - static const u8 pre_computed_values[] = {
> - 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> - 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> + struct drm_luminance_range_info *luminance_range;
>   int i;
>  
>   if (!aconnector || !aconnector->dc_link)
> @@ -2933,8 +2930,6 @@ static void update_connector_ext_caps(struct 
> amdgpu_dm_connector *aconnector)
>   caps = &dm->backlight_caps[i];
>   caps->ext_caps = &aconnector->dc_link->dpcd_sink_ext_caps;
>   caps->aux_support = false;
> - max_avg = conn_base->hdr_sink_metadata.hdmi_type1.max_fall;
> - min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll;
>  
>   if (caps->ext_caps->bits.oled == 1 /*||
>   caps->ext_caps->bits.sdr_aux_backlight_control == 1 ||
> @@ -2946,31 +2941,9 @@ static void update_connector_ext_caps(struct 
> amdgpu_dm_connector *aconnector)
>   else if (amdgpu_backlight == 1)
>   caps->aux_support = true;
>  
> - /* From the specification (CTA-861-G), for calculating the maximum
> -  * luminance we need to use:
> -  *  Luminance = 50*2**(CV/32)
> -  * Where CV is a one-byte value.
> -  * For calculating this expression we may need float point precision;
> -  * to avoid this complexity level, we take advantage that CV is divided
> -  * by a constant. From the Euclids division algorithm, we know that CV
> -  * can be written as: CV = 32*q + r. Next, we replace CV in the
> -  * Luminance expression and get 50*(2**q)*(2**(r/32)), hence we just
> -  * need to pre-compute the value of r/32. For pre-computing the values
> -  * We just used the following Ruby line:
> -  *  (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> -  * The results of the above expressions can be verified at
> -  * pre_computed_values.
> -  */
> - q = max_avg >> 5;
> - r = max_avg % 32;
> - max = (1 << q) * pre_computed_values[r];
> -
> - // min luminance: maxLum * (CV/255)^2 / 100
> - q = DIV_ROUND_CLOSEST(min_cll, 255);
> - min = max * DIV_ROUND_CLOSEST((q * q), 100);
> -
> - caps->aux_max_input_signal = max;
> - caps->aux_min_input_signal = min;
> + luminance_range = &conn_base->display_info.luminance_range;
> + caps->aux_min_input_signal = luminance_range->min_luminance;
> + caps->aux_max_input_signal = luminance_range->max_luminance;
>  }
>  
>  void amdgpu_dm_update_connector_after_detect(

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-03, Adam Ford wrote:
> On Wed, Aug 3, 2022 at 7:17 AM Dave Stevenson

...

> > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > from previously looking at these chips.
> 
> Thanks for the feedback.
> 
> > Mine fairly plainly states:
> > "The DSI receiver input supports DSI video mode operation only, and
> > specifically, only supports nonburst mode with sync pulses".
> > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > HDMI pixel rate.
> 
> Mine also states the DSI source needs to provide correct video timing
> with start and stop sync packets.
> 
> If I remember correctly, it seemed like Marek V wanted the hard coded
> samsung,burst-clock-frequency to go away so the clock frequency could
> be set dynamically.

As previously said, this is something on our TODO list too :) but needs
a bit more infrastructure work.

> I have attempted to do some of this work based on what I am seeing in
> the NXP kernel, and I get get my monitor to sync at some resolutions,
> but the screen is usually all green or all blue, so it's not really a
> success. The clock part appears to be good enough to make the monitor
> see some sort of signal, so I am going to investigate the calculation
> of the rest of the video timings to see if I can fix the color issue.

Please don't pay to much attention to the NXP kernel. No one have a glue
where those porches came from. If I specify the burst-clock-freq. to
445.5 and set the lane number to 4 and hack in the porches values from
NXP, than I get a 720P output too. But this isn't the way to go instead
we should calc the porches settings and the burst-clock-frequency
dynamiclly to provide more than just a few resolutions. But for that we
need a clear understanding of how the ADV is working.

I will prepare a repo to day and will send you a link with the hack
patches in it, so you can test it :)

Regards,
  Marco

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

On 22-08-03, Dave Stevenson wrote:
> On Wed, 3 Aug 2022 at 13:31, Adam Ford  wrote:

...

> > Mine also states the DSI source needs to provide correct video timing
> > with start and stop sync packets.
> >
> > If I remember correctly, it seemed like Marek V wanted the hard coded
> > samsung,burst-clock-frequency to go away so the clock frequency could
> > be set dynamically.
> 
> I've never worked with Exynos or imx8, but my view would be that
> samsung,burst-clock-frequency should only be used if
> MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
> adv7533/5).

Some notes on that. The samsung,burst-clock-frequency is the
hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to
do with the MIPI_DSI_MODE_VIDEO_BURST.

> Without that flag the DSI link frequency should be running at the rate
> defined by the mode clock, number of lanes, bpp, etc.

IMHO the DSI link have only to guarantee the bandwidth is sufficient for
the mode.

> From the DSI spec (v 1.1 section 8.11.1):
> "Non-Burst Mode with Sync Pulses – enables the peripheral to
> accurately reconstruct original video timing, including sync pulse
> widths."
> "RGB pixel packets are time-compressed, leaving more time during a
> scan line for LP mode (saving power) or for multiplexing other
> transmissions onto the DSI link."
> How can the peripheral reconstruct the video timing off a quirky link 
> frequency?

If the ADV couldn't reconstruct the sync signals, then we should not get
any mode working but we get the 1080P mode working.

> Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
> reconfigures the clock setup of the DSI block, then I don't see how
> the Exynos driver can follow the DSI spec in that regard.

Why do you think that the Exynos driver isn't following the spec? We
configure the host into video mode with sync signals which is working
for the 1080P mode.

Regards,
  Marco

[v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280

[Kalyan Thota]

Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.

representation: master_flush && (PCC_flush | IGC_flush .. etc )

This change adds necessary support for the above design.

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  4 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  5 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 40 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  3 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|  7 +
 6 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7763558..4eca317 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -703,6 +703,10 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc 
*crtc)
mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
mixer[i].hw_dspp->idx);
 
+   if(ctl->ops.set_dspp_hierarchical_flush)
+   ctl->ops.set_dspp_hierarchical_flush(ctl,
+   mixer[i].hw_dspp->idx, 
DSPP_SUB_PCC);
+
/* stage config flush mask */
ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 021eb2f..3b27a87 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -58,7 +58,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
 
 #define CTL_SC7280_MASK \
-   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) | 
BIT(DPU_CTL_VM_CFG))
+   (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_HIERARCHICAL_FLUSH))
 
 #define MERGE_3D_SM8150_MASK (0)
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index b85b24b..7922f6c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -185,6 +185,7 @@ enum {
  * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
  * @DPU_CTL_FETCH_ACTIVE:  Active CTL for fetch HW (SSPPs)
  * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_HIERARCHICAL_FLUSH: CTL config to support hierarchical flush
  * @DPU_CTL_MAX
  */
 enum {
@@ -192,6 +193,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+   DPU_CTL_HIERARCHICAL_FLUSH,
DPU_CTL_MAX
 };
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 3584f5e..b34fc30 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -28,6 +28,8 @@
 #define   CTL_INTF_FLUSH0x110
 #define   CTL_INTF_MASTER   0x134
 #define   CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define   CTL_DSPP_0_FLUSH 0x13C
+
 
 #define CTL_MIXER_BORDER_OUTBIT(24)
 #define CTL_FLUSH_MASK_CTL  BIT(17)
@@ -292,6 +294,36 @@ static uint32_t dpu_hw_ctl_get_bitmask_dspp(struct 
dpu_hw_ctl *ctx,
return flushbits;
 }
 
+static uint32_t dpu_hw_ctl_get_bitmask_dspp_v1(struct dpu_hw_ctl *ctx,
+   enum dpu_dspp dspp)
+{
+   return BIT(29);
+}
+
+static void dpu_hw_ctl_set_dspp_hierarchical_flush(struct dpu_hw_ctl *ctx,
+   enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
+{
+   uint32_t flushbits = 0, active = 0;
+
+   switch (dspp_sub_blk) {
+   case DSPP_SUB_IGC:
+   flushbits = BIT(2);
+   break;
+   case DSPP_SUB_PCC:
+   flushbits = BIT(4);
+   break;
+   case DSPP_SUB_GC:
+   flushbits = BIT(5);
+   break;
+   default:
+   return;
+   }
+
+   active = DPU_REG_READ(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4));
+
+   DPU_REG_WRITE(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4), active | 
flushbits);
+}
+
 static u32 dpu_hw_ctl_poll_reset_status(struct dpu_hw_ctl *ctx, u32 timeout_us)
 {
struct dpu_hw_blk_reg_map *c = &ctx->hw;
@@ -600,7 +632,13 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->setup_blendstage = dpu_hw_ctl_setup_blendstage;
ops->get_bitmask_sspp = dpu_hw_ctl_get_bitmask_sspp;
ops->get_bitmask_mixer = dpu_hw_ctl_get_bitmask_mixer;
-   ops->get_bitmask_dspp = dpu_hw_ctl_get_bitmask_dspp;
+   if (cap & BIT(DPU_CTL_HIERARCHICAL_FLUSH)) {
+   ops->get_bitmask_dspp = dpu_hw_ctl_get_bitmask_dspp_v1;
+   ops->set_dspp_hierarchical_flush = 
dpu_hw_ctl_set

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

Hi Marco

On Thu, 4 Aug 2022 at 10:38, Marco Felsch  wrote:
>
> Hi Dave, Adam,
>
> On 22-08-03, Dave Stevenson wrote:
> > Hi Adam
> >
> > On Wed, 3 Aug 2022 at 12:03, Adam Ford  wrote:
>
> ...
>
> > > > Did managed to get access to the ADV7535 programming guide? This is the
> > > > black box here. Let me check if I can provide you a link with our repo
> > > > so you can test our current DSIM state if you want.
> > >
> > > I do have access to the programming guide, but it's under NDA, but
> > > I'll try to answer questions if I can.
> >
> > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > from previously looking at these chips.
>
> Thanks for stepping into :)
>
> > Mine fairly plainly states:
> > "The DSI receiver input supports DSI video mode operation only, and
> > specifically, only supports nonburst mode with sync pulses".
>
> I've read this also, and we are working in nonburst mode with sync
> pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> verify it.
>
> > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > HDMI pixel rate.
>
> On DSI side you don't have a pixel-clock instead there is bit-clock.

You have an effective pixel clock, with a fixed conversion for the
configuration.

DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s

As noted elsewhere, the DSI is DDR, so the clock lane itself is only
running at 891 / 2 = 445.5MHz.

> > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > even more explicit about the requirement of DSI timing matching
>
> Is it possible to share the key points of the requirements?

"Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
mode requires real time data generation as a pulse packet received
becomes a pulse generated. Therefore this mode requires a continuous
stream of data with correct video timing to avoid any visual
artifacts."

LP mode is supported on data lanes. Clock lane must remain in HS mode.

"... the goal is to accurately convey DPI-type timing over DSI. This
includes matching DPI pixel-transmission rates, and widths of timing
events."

> > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > be correct for 720p operation.
>
> It should be absolute no difference if you work on 891MHz with 2 lanes
> or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> GBps.

Has someone changed the number of lanes in use? I'd missed that if so,
but I'll agree that 891MHz over 2 lanes should work for 720p60.

I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
of the modes that is mandatory to use the timing generator (reg 0x27
bit 7 = 1). On 2 lanes it is not required.
I don't know why it's referencing the 1000/1001 pixel clock rates and
not the base one, as it's only a base clock change with the same
timing (74.176MHz clock instead of 74.25MHz).

> > If you do program the manual DSI divider register to allow a DSI pixel
> > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
>
> There is no such DSI pixel rate to be precise, we only have a DSI bit
> clock/rate.
>
> > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > tx to compensate for the differing data rates. I see no reference to
> > such, and I'd be surprised if it was more than a half dozen pixels to
> > compensate for the jitter in the cases where the internal timing
> > generator is mandatory due to fractional bytes.
>
> This is interesting and would proofs our assumption that the device
> don't have a FIFO :)
>
> Our assumptions (we don't have the datasheet/programming manual):
>   - HDMI part is fetching 3 bytes per HDMI pixclk
>   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> HDMI are in sync. So from bandwidth pov there are no differences
> between:
>   - HDMI: 74.25 MHz * 24 Bit  = 1782.0 MBit/s
>   - DSI:891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: 445.5 )
>   - DSI:  445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: 222.75)
>
> But the ratio is different and therefore the faster clocking option
> let something 'overflow'.

I'll agree that all looks consistent.

> Anyway, but all this means that Adam should configure the
> burst-clock-rate to 445.5 and set the lanes to 4. But this doesn't work
> either and now we are back on my initial statement -> the driver needs
> some attention.

Things always need attention :-)
I suspect that it's the use of the timing generator that is the issue.
The programming guide does recommend using it for all modes, so that
would be a sensible first step.

I will say that we had a number of issues getting this chip to do
anything, and it generally seemed happier on 2 or 3 lanes instead of
4. Suffice to say that we abandoned trying to use it, despite some
assistance from ADI.

  Dave

Re: [RFC PATCH 1/2] drm/panel-edp: Allow overriding the eDP EDID

[Jani Nikula]

On Fri, 29 Jul 2022, Doug Anderson  wrote:
> Hi,
>
> On Thu, Jul 21, 2022 at 4:36 AM Dmitry Baryshkov
>  wrote:
>>
>> On Thu, 21 Jul 2022 at 01:55, Douglas Anderson  wrote:
>> >
>> > I found that writing to `/sys/kernel/debug/dri/*/eDP*/edid_override`
>> > wasn't working for me. I could see the new EDID take effect in
>> > `/sys/class/drm/card*-eDP*/edid` but userspace wasn't seeing it..
>> >
>> > The problem was that panel-edp was caching the EDID that it read and
>> > using that over and over again.
>> >
>> > Let's change panel-edp to look at the EDID that's stored in the
>> > connector. This is still a cache, which is important since this
>> > function is called multiple times and readin the EDID is slow, but
>> > this property is automatically updated by drm_get_edid() (which reads
>> > the EDID) and also updated when writing the edid_override in debugfs.
>> >
>> > Fixes: 63358e24ee79 ("drm/panel: panel-simple: Cache the EDID as long as 
>> > we retain power")
>> > Signed-off-by: Douglas Anderson 
>>
>> A different proposal for you to consider:
>> Change drm_get_edid/drm_do_get_edid to return int rather than struct
>> edid, while caching the EDID in the connector. Or maybe add a new API
>> drm_read_edid() and make drm_get_edid() deprecated in favour of it.
>> The goal should be to let all drivers use connector-cached EDID rather
>> than getting  the EDID, parsing it and kfree()ing it immediately
>> afterwards.
>
> I think the majority of drivers don't actually want the cached EDID
> behavior so the edp-panel case is actually pretty rare. For everyone
> else I think DRM is handling things in a pretty reasonable way.
> Looking closely, it looks like there have been a bunch of patches
> landed in this area recently and so I assume people are happy enough
> with the current design for the majority of cases.
>
> I guess your point though, is that the way I'm using the API right now
> in ${SUBJECT} patch is a bit gross and maybe the DRM core needs a
> helper of some sort for this case? Essentially what we're saying is
> that we have inside knowledge this is a built-in panel and thus the
> EDID will never change and it's a waste of time to read it again and
> again. We could somehow tell the DRM core that.
>
> I guess I could add a function like drm_edid_read_if_needed(). That
> would essentially use the existing blob if it was there and read it
> otherwise. Does that work? Basically:
>
> def drm_edid_read_if_needed(...):
>   if (connector->edid_blob_ptr)
> return dupe_edid(connector->edid_blob_ptr);
>   return drm_edid_read(...);
>
> I guess maybe we'd want a _ddc variant too.
>
> Adding Jani since the recent patches I see touching this were his and
> there are even comments there about what to do about drivers that want
> to cache the EDID.
>
>
>> Most probably we should be able to move
>> drm_connector_update_edid_property() into drm_do_get_edid() and drop
>> it from the rest of the code. This might require additional thought
>> about locking, to ensure that nobody pulls the cached edid out from
>> under our feet.
>
> This all looks like it's moving now, actually. Looking around at
> recent changes, I see that now the property gets updated in a
> different call.
>
> Old (deprecated)
> 1. drm_get_edid() <-- Updates the EDID property
> 2. drm_add_edid_modes()
>
> New:
> 1. drm_edid_read()
> 2. drm_edid_connector_update() <-- Updates the EDID property
>
>
>  > Extra "bonus" points to consider:
>> - Maybe it's time to add get_edid() to the drm_panel interface, teach
>> panel_bridge about it and let drm_bridge_connector handle all the
>> details?
>>
>> So, while this looks like a longer path, I think it's worth checking
>> that we can refactor this piece of code.
>
> It's certainly interesting to consider. At the moment, though, it
> doesn't look super easy to do. Points to note:
>
> 1. We don't necessarily want to cache the EDID for all display types.
> For builtin panels it makes sense to do so, but it's less obvious for
> external displays. _In theory_ we could try to cache the EDID for
> external devices if we're really certain that we'll notice when
> they're unplugged / re-plugged again but I'm not convinced that all
> drivers always handle this. In any case, I tend to assume that when
> we're dealing with external displays we're a little less interested in
> trying to optimize all of the milliseconds away. If nothing else there
> are hundreds of milliseconds of hotplug detect debounce happening for
> external displays. Yes, we could have a rule about only caching the
> EDID only for eDP displays but then the motivation of moving it out of
> edp-panel and to drm_bridge_connector is a lot less.
>
> 2. At the moment, drm_bridge_connector only calls get_modes() if it
> doesn't have get_edid() implemented. At the moment the panel-edp code
> actually _combines_ the EDID and any hardcoded modes that were
> specified. I think we'd have to resolve this difference if we do what
> you suggest. The panel-edp beh

Re: New subsystem for acceleration devices

[Tvrtko Ursulin]

On 04/08/2022 00:54, Dave Airlie wrote:

On Thu, 4 Aug 2022 at 06:21, Oded Gabbay  wrote:


On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie  wrote:


On Sun, 31 Jul 2022 at 22:04, Oded Gabbay  wrote:


Hi,
Greg and I talked a couple of months ago about preparing a new accel
subsystem for compute/acceleration devices that are not GPUs and I
think your drivers that you are now trying to upstream fit it as well.


We've had some submissions for not-GPUs to the drm subsystem recently.

Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit.

why is creating a new subsystem at this time necessary?

Are we just creating a subsystem to avoid the open source userspace
consumer rules? Or do we have some concrete reasoning behind it?

Dave.


Hi Dave.
The reason it happened now is because I saw two drivers, which are
doing h/w acceleration for AI, trying to be accepted to the misc
subsystem.
Add to that the fact I talked with Greg a couple of months ago about
doing a subsystem for any compute accelerators, which he was positive
about, I thought it is a good opportunity to finally do it.

I also honestly think that I can contribute much to these drivers from
my experience with the habana driver (which is now deployed in mass at
AWS) and contribute code from the habana driver to a common framework
for AI drivers.


Why not port the habana driver to drm now instead? I don't get why it
wouldn't make sense?

Stepping up to create a new subsystem is great, but we need rules
around what belongs where, we can't just spawn new subsystems when we
have no clear guidelines on where drivers should land.

What are the rules for a new accel subsystem? Do we have to now
retarget the 3 drivers that are queued up to use drm for accelerators,
because 2 drivers don't?


Isn't there three on the "don't prefer drm" side as well? Habana, 
Toshiba and Samsung? Just so the numbers argument is not misrepresented. 
Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't 
care in principle; is in order?


More to the point, code sharing is a very compelling argument if it can 
be demonstrated to be significant, aka not needing to reinvent the same 
wheel.


Perhaps one route forward could be a) to consider is to rename DRM to 
something more appropriate, removing rendering from the name and 
replacing with accelerators, co-processors, I don't know... Although I 
am not sure renaming the codebase, character device node names and 
userspace headers is all that feasible. Thought to mention it 
nevertheless, maybe it gives an idea to someone how it could be done.


And b) allow the userspace rules to be considered per driver, or per 
class (is it a gpu or not should be a question that can be answered). 
Shouldn't be a blocker if it still matches the rules present elsewhere 
in the kernel.


Those two would remove the two most contentions points as far as I 
understood the thread.


Regards,

Tvrtko


There's a lot more to figure out here than merge some structures and
it will be fine.

I think the one area I can see a divide where a new subsystem is for
accelerators that are single-user, one shot type things like media
drivers (though maybe they could be just media drivers).

I think anything that does command offloading to firmware or queues
belongs in drm, because that is pretty much what the framework does. I
think it might make sense to enhance some parts of drm to fit things
in better, but that shouldn't block things getting started.

I'm considering if, we should add an accelerator staging area to drm
and land the 2-3 submissions we have and try and steer things towards
commonality that way instead of holding them out of tree.

I'd like to offload things from Greg by just not having people submit
misc drivers at all for things that should go elsewhere.

Dave.




Regarding the open source userspace rules in drm - yes, I think your
rules are too limiting for the relatively young AI scene, and I saw at
the 2021 kernel summit that other people from the kernel community
think that as well.
But that's not the main reason, or even a reason at all for doing
this. After all, at least for habana, we open-sourced our compiler and
a runtime library. And Greg also asked those two drivers if they have
matching open-sourced user-space code.

And a final reason is that I thought this can also help in somewhat
reducing the workload on Greg. I saw in the last kernel summit there
was a concern about bringing more people to be kernel maintainers so I
thought this is a step in the right direction.

Oded

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

Hi Marco

On Thu, 4 Aug 2022 at 11:28, Marco Felsch  wrote:
>
> On 22-08-03, Dave Stevenson wrote:
> > On Wed, 3 Aug 2022 at 13:31, Adam Ford  wrote:
>
> ...
>
> > > Mine also states the DSI source needs to provide correct video timing
> > > with start and stop sync packets.
> > >
> > > If I remember correctly, it seemed like Marek V wanted the hard coded
> > > samsung,burst-clock-frequency to go away so the clock frequency could
> > > be set dynamically.
> >
> > I've never worked with Exynos or imx8, but my view would be that
> > samsung,burst-clock-frequency should only be used if
> > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
> > adv7533/5).
>
> Some notes on that. The samsung,burst-clock-frequency is the
> hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to
> do with the MIPI_DSI_MODE_VIDEO_BURST.
>
> > Without that flag the DSI link frequency should be running at the rate
> > defined by the mode clock, number of lanes, bpp, etc.
>
> IMHO the DSI link have only to guarantee the bandwidth is sufficient for
> the mode.

DSI spec 8.11.3 Non-Burst Mode with Sync Events
"This mode is a simplification of the format described in Section
8.11.2 (Non-Burst Mode with Sync Pulses)
...
Pixels are transmitted at the same rate as they would in a
corresponding parallel display interface such as DPI-2."

If you are running the DSI clock at anything other than that rate,
then AIUI you are in a burst mode (although you may choose not to drop
into LP mode).

(One of my pet peeves that there is no documentation as to exactly
what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI
spec all modes of 8.11 say that the host can drop to LP during
blanking if time allows, it surely has to be the time compression
element of 8.11.4 Burst Mode).

> > From the DSI spec (v 1.1 section 8.11.1):
> > "Non-Burst Mode with Sync Pulses – enables the peripheral to
> > accurately reconstruct original video timing, including sync pulse
> > widths."
> > "RGB pixel packets are time-compressed, leaving more time during a
> > scan line for LP mode (saving power) or for multiplexing other
> > transmissions onto the DSI link."
> > How can the peripheral reconstruct the video timing off a quirky link 
> > frequency?
>
> If the ADV couldn't reconstruct the sync signals, then we should not get
> any mode working but we get the 1080P mode working.
>
> > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
> > reconfigures the clock setup of the DSI block, then I don't see how
> > the Exynos driver can follow the DSI spec in that regard.
>
> Why do you think that the Exynos driver isn't following the spec? We
> configure the host into video mode with sync signals which is working
> for the 1080P mode.

1080p is working with samsung,burst-clock-frequency setting?
As I say, I've not worked with this IP, I'm only looking at it from
the outside having spent far too much time recently on the Pi DSI
interface.
exynos_drm_dsi.c seems to be doing a lot of PLL computation around
burst-clock-frequency, and nothing with the pixel clock rate. Without
knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG actually
does in the hardware, I can only make guesses. Perhaps it does ditch
the burst clock and switch the bit clock to be derived from the pixel
clock of the upstream block, but that seems unlikely.

  Dave

[PATCH RFC] dma-buf: To check DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT status on debug

[Arvind Yadav]

If core DMA-buf framework forgets to call dma_fence_enable_signaling()
before calling the dma_fence_is_signaled(). To handle this scenario on
debug kernel the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT needs to be checked
before checking the actual signaling status.

Signed-off-by: Arvind Yadav 
---
 include/linux/dma-fence.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 775cdc0b4f24..7c95c8d5e5f5 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -428,6 +428,10 @@ dma_fence_is_signaled_locked(struct dma_fence *fence)
 static inline bool
 dma_fence_is_signaled(struct dma_fence *fence)
 {
+#ifdef CONFIG_DEBUG_FS
+   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags))
+   return true;
+#endif
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return true;
 
-- 
2.25.1

Re: [PATCH v3 26/32] drm/via: Add via_drm.h

[Thomas Zimmermann]

Hi

Am 03.08.22 um 03:49 schrieb Kevin Brace:

Hi Thomas,

I am honestly surprised of the e-mail back and forth regarding the mainlining 
of OpenChrome DRM, but let me state my position.


That's because your expectations are unrealistic. We don't know you, you 
apparently have little prior kernel experience and want to merge code 
that is essentially your pet project. It's also not a good start to 
insist on merging new uapi calls.


Upstream kernel is not a place to dump code that you declare ready. 
You're becoming part of a community. Your first priority should be to 
earn the trust of the other developers on this mailing list.



Considering the age of the hardware I am dealing with (i.e., pre-OpenGL 2.x 
generation 3D engine), I do not anticipate being able to run OpenChrome on 
Wayland with acceleration.


Acceleration and wayland are independent from each other.


As a first step after mainlining, I am looking to add uAPI to pass 2D / 3D 
acceleration commands to the graphics engine, but frankly, I am going to focus 
on the 2D acceleration side first.


Did you read

  https://blog.ffwll.ch/2018/08/no-2d-in-drm.html

?


Considering the age of the hardware, I do not think limiting the use to X.Org X 
Server is a bad choice.


If you're not interested in running modern userspace, then why are you 
doing this anyway? Everyone with an X server can already use the 
existing DRI1 code.


You also don't seem to understand the state of the Linux graphics stack. 
First of all, you're not building a driver for one particular program, 
but for all of them. There's the X server, a number of Wayland 
compositors, and a few more outlandish things like kmscon.


And secondly, did you read

  https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html

?

Xorg-on-hardware is pretty much dead. There hasn't been a release for 
years. What will remain is Xorg-on-Wayland, which is provided by xwayland.



I do OpenChrome development on Gentoo Linux where 32-bit x86 ISA and X.Org X 
Server are still fully supported.
Adding 3D acceleration will likely be done after 2D and video accelerations are 
mostly working.


Video acceleration seems realistic. 2d and 3d not so much. 2d for 
reasons given in Daniel's blog. 3d because the hardware might be too old 
already. If VIA really only supports OpenGL-1.x-era features, you'd have 
to revive the old mesa branches to use it. But I can't say for sure.



The proposed OpenChrome uAPI is essentially a cutdown version of the mostly 2D 
acceleration focused implementation (my opinion) being worked on and off since 
2011.
The limited addition of uAPI calls is merely a preparatory step for adding 2D 
acceleration in the near future (I have not started the work yet.).
I assume you are aware that OpenChrome DDX is a user of DRM_VIA_GEM_CREATE, 
DRM_VIA_GEM_MAP, and DRM_VIA_GEM_UNMAP uAPIs.


To my understanding, the DDX code only exists in a repository in a git 
tree of yours. That's not "userspace".



For those who still choose to use older generation hardware, I think X.Org X Server still 
has a lot of life left in it, and I plan to continue modernizing the graphics stack for 
what I call "underserved" (i.e., neglected) graphics hardware.


As I said we welcome drivers for old hardware. But your current proposal 
is not feasible and will cause friction with upstream.


Here's a suggestion that is more promising.

 1) Get an un-accelerated driver merged without new uapi, ioctls, etc. 
All you need is there already. We already agreed to take the code mostly 
as-is and do the cleanups later on.


 2a) Stay around on dri-devel, send improvements and fixes for the 
merged code.


 2b) In parallel, you can work on video, 3d, etc in both kernel and 
userspace.


 3) When you have a feature ready, send a patchset to dri-devel with 
the kernel changes and another patchset to the respective userspace 
project (e.g., Mesa). They should refer to each other, so that reviewers 
can see both sides of the interface at the same time.



Best regards
Thomas



Regards,

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com



Sent: Tuesday, August 02, 2022 at 4:38 AM
From: "Thomas Zimmermann" 
To: "Kevin Brace" 
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h

Hi

Am 02.08.22 um 05:45 schrieb Kevin Brace:

Hi Thomas,

I hope I am comprehending this right.
Yes, I am adding 3 new uAPI calls, not 6 of them.
Correspondingly, there are 3 new structs added.


That's understood.


While I may drop one (unmap uAPI), I personally do not wish to drop the other 
two at this point.
Instead, I may need to add setparam and / or getparam uAPI to pass PCI Device 
ID back to the userspace.
This is mainly needed by Mesa, although there is no code for Mesa at this point.


Exactly my point! There's no userspace for it. That's why Sam and me are
asking you to remove all kinds if uapi changes or ioctls from the
patchset until Mesa (or some other component)

[PATCH 1/3] video: fbdev: vt8623fb: Check the size of screen before memset_io()

[Zheyu Ma]

In the function vt8623fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:

[  583.339036] BUG: unable to handle page fault for address: c9000500
[  583.339049] #PF: supervisor write access in kernel mode
[  583.339052] #PF: error_code(0x0002) - not-present page
[  583.339074] RIP: 0010:memset_orig+0x33/0xb0
[  583.339110] Call Trace:
[  583.339118]  vt8623fb_set_par+0x11cd/0x21e0
[  583.339146]  fb_set_var+0x604/0xeb0
[  583.339181]  do_fb_ioctl+0x234/0x670
[  583.339209]  fb_ioctl+0xdd/0x130

Fix the this by checking the value of 'screen_size' before memset_io().

Fixes: 558b7bd86c32 ("vt8623fb: new framebuffer driver for VIA VT8623")
Signed-off-by: Zheyu Ma 
---
 drivers/video/fbdev/vt8623fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index a92a8c670cf0..4274c6efb249 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -507,6 +507,8 @@ static int vt8623fb_set_par(struct fb_info *info)
 (info->var.vmode & FB_VMODE_DOUBLE) ? 2 : 1, 1,
 1, info->node);
 
+   if (screen_size > info->screen_size)
+   screen_size = info->screen_size;
memset_io(info->screen_base, 0x00, screen_size);
 
/* Device and screen back on */
-- 
2.25.1

[PATCH 2/3] video: fbdev: arkfb: Check the size of screen before memset_io()

[Zheyu Ma]

In the function arkfb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:

[  659.399066] BUG: unable to handle page fault for address: c9000300
[  659.399077] #PF: supervisor write access in kernel mode
[  659.399079] #PF: error_code(0x0002) - not-present page
[  659.399094] RIP: 0010:memset_orig+0x33/0xb0
[  659.399116] Call Trace:
[  659.399122]  arkfb_set_par+0x143f/0x24c0
[  659.399130]  fb_set_var+0x604/0xeb0
[  659.399161]  do_fb_ioctl+0x234/0x670
[  659.399189]  fb_ioctl+0xdd/0x130

Fix the this by checking the value of 'screen_size' before memset_io().

Fixes: 681e14730c73 ("arkfb: new framebuffer driver for ARK Logic cards")
Signed-off-by: Zheyu Ma 
---
 drivers/video/fbdev/arkfb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index eb3e47c58c5f..de4002914f9e 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -792,6 +792,8 @@ static int arkfb_set_par(struct fb_info *info)
value = ((value * hmul / hdiv) / 8) - 5;
vga_wcrt(par->state.vgabase, 0x42, (value + 1) / 2);
 
+   if (screen_size > info->screen_size)
+   screen_size = info->screen_size;
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
svga_wcrt_mask(par->state.vgabase, 0x17, 0x80, 0x80);
-- 
2.25.1

[PATCH 3/3] video: fbdev: s3fb: Check the size of screen before memset_io()

[Zheyu Ma]

In the function s3fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:

[   54.083733] BUG: unable to handle page fault for address: c9000300
[   54.083742] #PF: supervisor write access in kernel mode
[   54.083744] #PF: error_code(0x0002) - not-present page
[   54.083760] RIP: 0010:memset_orig+0x33/0xb0
[   54.083782] Call Trace:
[   54.083788]  s3fb_set_par+0x1ec6/0x4040
[   54.083806]  fb_set_var+0x604/0xeb0
[   54.083836]  do_fb_ioctl+0x234/0x670

Fix the this by checking the value of 'screen_size' before memset_io().

Fixes: a268422de8bf ("[PATCH] fbdev driver for S3 Trio/Virge")
Signed-off-by: Zheyu Ma 
---
 drivers/video/fbdev/s3fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index b93c8eb02336..5069f6f67923 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -905,6 +905,8 @@ static int s3fb_set_par(struct fb_info *info)
value = clamp((htotal + hsstart + 1) / 2 + 2, hsstart + 4, htotal + 1);
svga_wcrt_multi(par->state.vgabase, s3_dtpc_regs, value);
 
+   if (screen_size > info->screen_size)
+   screen_size = info->screen_size;
memset_io(info->screen_base, 0x00, screen_size);
/* Device and screen back on */
svga_wcrt_mask(par->state.vgabase, 0x17, 0x80, 0x80);
-- 
2.25.1

Re: [PATCH] drm/imx/dcss: get rid of HPD warning message

[Laurentiu Palcu]

On Thu, Jul 21, 2022 at 03:25:02PM +0300, Laurent Pinchart wrote:
> Hi Laurentiu,
> 
> Thank you for the patch.
> 
> On Thu, Jul 21, 2022 at 03:09:12PM +0300, Laurentiu Palcu wrote:
> > When DCSS + MIPI_DSI is used, and the last bridge in the chain supports
> > HPD, we can see a "Hot plug detection already enabled" warning stack
> > trace dump that's thrown when DCSS is initialized.
> > 
> > The problem appeared when HPD was enabled by default in the
> > bridge_connector initialization, which made the
> > drm_bridge_connector_enable_hpd() call, in DCSS init path, redundant.
> > So, let's remove that call.
> > 
> > Fixes: 09077bc311658 ("drm/bridge_connector: enable HPD by default if 
> > supported")
> > Signed-off-by: Laurentiu Palcu 
> 
> Reviewed-by: Laurent Pinchart 

Applied to drm-misc/drm-misc-fixes.

Thanks,
laurentiu

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Dave,

On 22-08-04, Dave Stevenson wrote:
> Hi Marco
> 
> On Thu, 4 Aug 2022 at 10:38, Marco Felsch  wrote:
> >
> > Hi Dave, Adam,
> >
> > On 22-08-03, Dave Stevenson wrote:
> > > Hi Adam
> > >
> > > On Wed, 3 Aug 2022 at 12:03, Adam Ford  wrote:
> >
> > ...
> >
> > > > > Did managed to get access to the ADV7535 programming guide? This is 
> > > > > the
> > > > > black box here. Let me check if I can provide you a link with our repo
> > > > > so you can test our current DSIM state if you want.
> > > >
> > > > I do have access to the programming guide, but it's under NDA, but
> > > > I'll try to answer questions if I can.
> > >
> > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > from previously looking at these chips.
> >
> > Thanks for stepping into :)
> >
> > > Mine fairly plainly states:
> > > "The DSI receiver input supports DSI video mode operation only, and
> > > specifically, only supports nonburst mode with sync pulses".
> >
> > I've read this also, and we are working in nonburst mode with sync
> > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > verify it.
> >
> > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > HDMI pixel rate.
> >
> > On DSI side you don't have a pixel-clock instead there is bit-clock.
> 
> You have an effective pixel clock, with a fixed conversion for the
> configuration.
> 
> DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s

Okay, I just checked the bandwidth which must equal.

> As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> running at 891 / 2 = 445.5MHz.
> 
> > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > even more explicit about the requirement of DSI timing matching
> >
> > Is it possible to share the key points of the requirements?
> 
> "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> mode requires real time data generation as a pulse packet received
> becomes a pulse generated. Therefore this mode requires a continuous
> stream of data with correct video timing to avoid any visual
> artifacts."
> 
> LP mode is supported on data lanes. Clock lane must remain in HS mode.
> 
> "... the goal is to accurately convey DPI-type timing over DSI. This
> includes matching DPI pixel-transmission rates, and widths of timing
> events."

Thanks for sharing.

> > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > be correct for 720p operation.
> >
> > It should be absolute no difference if you work on 891MHz with 2 lanes
> > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > GBps.
> 
> Has someone changed the number of lanes in use? I'd missed that if so,
> but I'll agree that 891MHz over 2 lanes should work for 720p60.

The ADV driver is changing it autom. but this logic is somehow odd and
there was already a approach to stop the driver doing this.

To sync up: we have two problems:
  1) The 720P mode with static DSI host configuration isn't working
 without hacks.
  2) The DSI link frequency should changed as soon as required
 automatically. So we can provide all modes.

I would concentrate on problem 1 first before moving on to the 2nd.

> I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> of the modes that is mandatory to use the timing generator (reg 0x27
> bit 7 = 1). On 2 lanes it is not required.
> I don't know why it's referencing the 1000/1001 pixel clock rates and
> not the base one, as it's only a base clock change with the same
> timing (74.176MHz clock instead of 74.25MHz).

Interesting! I would like to know how the HDMI block gets fetched by the
DSI block and how the timing-generator can influence this in good/bad
way. So that we know what DSI settings (freq, lanes) are sufficient.

> > > If you do program the manual DSI divider register to allow a DSI pixel
> > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> >
> > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > clock/rate.
> >
> > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > tx to compensate for the differing data rates. I see no reference to
> > > such, and I'd be surprised if it was more than a half dozen pixels to
> > > compensate for the jitter in the cases where the internal timing
> > > generator is mandatory due to fractional bytes.
> >
> > This is interesting and would proofs our assumption that the device
> > don't have a FIFO :)
> >
> > Our assumptions (we don't have the datasheet/programming manual):
> >   - HDMI part is fetching 3 bytes per HDMI pixclk
> >   - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI and
> > HDMI are in sync. So from bandwidth pov there are no differences
> > between:
> >   - HDMI: 74.25 MHz * 24 Bit  = 1782.0 

[PATCH 0/3] Fix bugs in *_set_par() caused by user input

[Zheyu Ma]

In the function *_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause a bug in the memset_io().

Zheyu Ma (3):
  video: fbdev: vt8623fb: Check the size of screen before memset_io()
  video: fbdev: arkfb: Check the size of screen before memset_io()
  video: fbdev: s3fb: Check the size of screen before memset_io()

 drivers/video/fbdev/arkfb.c| 2 ++
 drivers/video/fbdev/s3fb.c | 2 ++
 drivers/video/fbdev/vt8623fb.c | 2 ++
 3 files changed, 6 insertions(+)

-- 
2.25.1

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch  wrote:
>
> Hi Dave,
>
> On 22-08-04, Dave Stevenson wrote:
> > Hi Marco
> >
> > On Thu, 4 Aug 2022 at 10:38, Marco Felsch  wrote:
> > >
> > > Hi Dave, Adam,
> > >
> > > On 22-08-03, Dave Stevenson wrote:
> > > > Hi Adam
> > > >
> > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford  wrote:
> > >
> > > ...
> > >
> > > > > > Did managed to get access to the ADV7535 programming guide? This is 
> > > > > > the
> > > > > > black box here. Let me check if I can provide you a link with our 
> > > > > > repo
> > > > > > so you can test our current DSIM state if you want.
> > > > >
> > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > I'll try to answer questions if I can.
> > > >
> > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > from previously looking at these chips.
> > >
> > > Thanks for stepping into :)
> > >
> > > > Mine fairly plainly states:
> > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > specifically, only supports nonburst mode with sync pulses".
> > >
> > > I've read this also, and we are working in nonburst mode with sync
> > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > verify it.
> > >
> > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > HDMI pixel rate.
> > >
> > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> >
> > You have an effective pixel clock, with a fixed conversion for the
> > configuration.
> >
> > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
>
> Okay, I just checked the bandwidth which must equal.
>
> > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > running at 891 / 2 = 445.5MHz.
> >
> > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > even more explicit about the requirement of DSI timing matching
> > >
> > > Is it possible to share the key points of the requirements?
> >
> > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > mode requires real time data generation as a pulse packet received
> > becomes a pulse generated. Therefore this mode requires a continuous
> > stream of data with correct video timing to avoid any visual
> > artifacts."
> >
> > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> >
> > "... the goal is to accurately convey DPI-type timing over DSI. This
> > includes matching DPI pixel-transmission rates, and widths of timing
> > events."
>
> Thanks for sharing.
>
> > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > be correct for 720p operation.
> > >
> > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > GBps.
> >
> > Has someone changed the number of lanes in use? I'd missed that if so,
> > but I'll agree that 891MHz over 2 lanes should work for 720p60.
>
> The ADV driver is changing it autom. but this logic is somehow odd and
> there was already a approach to stop the driver doing this.
>
> To sync up: we have two problems:
>   1) The 720P mode with static DSI host configuration isn't working
>  without hacks.

can you share your hacks with me about getting 720p to work?  I've
been struggling to get 720 to work.

>   2) The DSI link frequency should changed as soon as required
>  automatically. So we can provide all modes.
>
> I would concentrate on problem 1 first before moving on to the 2nd.

I do have some code that does #2 already.  I can clean it up and share
if you want.  I've been bouncing back and forth between the NXP kernel
and the Jagan/Fabio kernel to compare and with my clock change, it
appears to be generating similar clocks to the NXP, yet it still won't
sync at 720P.

>
> > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > of the modes that is mandatory to use the timing generator (reg 0x27
> > bit 7 = 1). On 2 lanes it is not required.
> > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > not the base one, as it's only a base clock change with the same
> > timing (74.176MHz clock instead of 74.25MHz).
>
> Interesting! I would like to know how the HDMI block gets fetched by the
> DSI block and how the timing-generator can influence this in good/bad
> way. So that we know what DSI settings (freq, lanes) are sufficient.
>
> > > > If you do program the manual DSI divider register to allow a DSI pixel
> > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > >
> > > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > > clock/rate.
> > >
> > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > > tx to compensate for the differing

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Dave,

On 22-08-04, Dave Stevenson wrote:
> Hi Marco
> 
> On Thu, 4 Aug 2022 at 11:28, Marco Felsch  wrote:
> >
> > On 22-08-03, Dave Stevenson wrote:
> > > On Wed, 3 Aug 2022 at 13:31, Adam Ford  wrote:
> >
> > ...
> >
> > > > Mine also states the DSI source needs to provide correct video timing
> > > > with start and stop sync packets.
> > > >
> > > > If I remember correctly, it seemed like Marek V wanted the hard coded
> > > > samsung,burst-clock-frequency to go away so the clock frequency could
> > > > be set dynamically.
> > >
> > > I've never worked with Exynos or imx8, but my view would be that
> > > samsung,burst-clock-frequency should only be used if
> > > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for
> > > adv7533/5).
> >
> > Some notes on that. The samsung,burst-clock-frequency is the
> > hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to
> > do with the MIPI_DSI_MODE_VIDEO_BURST.
> >
> > > Without that flag the DSI link frequency should be running at the rate
> > > defined by the mode clock, number of lanes, bpp, etc.
> >
> > IMHO the DSI link have only to guarantee the bandwidth is sufficient for
> > the mode.
> 
> DSI spec 8.11.3 Non-Burst Mode with Sync Events
> "This mode is a simplification of the format described in Section
> 8.11.2 (Non-Burst Mode with Sync Pulses)
> ...
> Pixels are transmitted at the same rate as they would in a
> corresponding parallel display interface such as DPI-2."
> 
> If you are running the DSI clock at anything other than that rate,
> then AIUI you are in a burst mode (although you may choose not to drop
> into LP mode).

Yes, that makes sense to me. The bandwidth on the DSI side should match
the one required on the other side (HDMI). Apart the fact that the ADV
is working in mode 8.11.2 (Non-Burst Mode with Sync Pulses).

> (One of my pet peeves that there is no documentation as to exactly
> what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI
> spec all modes of 8.11 say that the host can drop to LP during
> blanking if time allows, it surely has to be the time compression
> element of 8.11.4 Burst Mode).

Hm.. I don't have the DSI spec either but I thought that BURST mode
allows the host to send the data as fast as possible and enter LP
afterwards.

> > > From the DSI spec (v 1.1 section 8.11.1):
> > > "Non-Burst Mode with Sync Pulses – enables the peripheral to
> > > accurately reconstruct original video timing, including sync pulse
> > > widths."
> > > "RGB pixel packets are time-compressed, leaving more time during a
> > > scan line for LP mode (saving power) or for multiplexing other
> > > transmissions onto the DSI link."
> > > How can the peripheral reconstruct the video timing off a quirky link 
> > > frequency?
> >
> > If the ADV couldn't reconstruct the sync signals, then we should not get
> > any mode working but we get the 1080P mode working.
> >
> > > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1]
> > > reconfigures the clock setup of the DSI block, then I don't see how
> > > the Exynos driver can follow the DSI spec in that regard.
> >
> > Why do you think that the Exynos driver isn't following the spec? We
> > configure the host into video mode with sync signals which is working
> > for the 1080P mode.
> 
> 1080p is working with samsung,burst-clock-frequency setting?

Yes.

> As I say, I've not worked with this IP, I'm only looking at it from
> the outside having spent far too much time recently on the Pi DSI
> interface.

Good to know :)

> exynos_drm_dsi.c seems to be doing a lot of PLL computation around
> burst-clock-frequency, and nothing with the pixel clock rate.

Yes currently there is just this setting for setting the PLL freq. but
as you said for the "Non-Burst Mode with Sync Pulses" we need to
reconfigure it according the required bandwidth or the dsi-device tells
us about which dsi-link settings should be applied.

> Without knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG
> actually does in the hardware, I can only make guesses.

8<--
   Selects Burst mode in Video mode

   In Non-burst mode, RGB data area is filled with RGB data and Null
   packets, according to input bandwidth of RGB interface.
   
   In Burst mode, RGB data area is filled with RGB data only.

   0 = Non-burst mode
   1 = Burst mode
8<--

According the current implementation we are in Non-burst mode.

Regards,
  Marco

> Perhaps it does ditch the burst clock and switch the bit clock to be
> derived from the pixel clock of the upstream block, but that seems
> unlikely.
> 
>   Dave
> 

[PATCH 1/2] drm/cmdline-parser: Merge negative tests

[Michał Winiarski]

Negative tests can be expressed as a single parameterized test case,
which highlights that we're following the same test logic (passing
negative cmdline and expecting drm_mode_parse_command_line_for_connector
to fail), which improves readability.

Signed-off-by: Michał Winiarski 
---
 .../gpu/drm/tests/drm_cmdline_parser_test.c   | 293 ++
 1 file changed, 103 insertions(+), 190 deletions(-)

diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c 
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 59b29cdfdd35..058808faaf4a 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -109,24 +109,6 @@ static void drm_cmdline_test_force_d_only(struct kunit 
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
 }
 
-static void drm_cmdline_test_margin_only(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "m";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_interlace_only(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "i";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
 static void drm_cmdline_test_res(struct kunit *test)
 {
struct drm_cmdline_mode mode = { };
@@ -149,42 +131,6 @@ static void drm_cmdline_test_res(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
 }
 
-static void drm_cmdline_test_res_missing_x(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "x480";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_missing_y(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "1024x";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_bad_y(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "1024xtest";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_missing_y_bpp(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "1024x-24";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
 static void drm_cmdline_test_res_vesa(struct kunit *test)
 {
struct drm_cmdline_mode mode = { };
@@ -274,15 +220,6 @@ static void drm_cmdline_test_res_bpp(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
 }
 
-static void drm_cmdline_test_res_bad_bpp(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "720x480-test";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
 static void drm_cmdline_test_res_refresh(struct kunit *test)
 {
struct drm_cmdline_mode mode = { };
@@ -306,15 +243,6 @@ static void drm_cmdline_test_res_refresh(struct kunit 
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
 }
 
-static void drm_cmdline_test_res_bad_refresh(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline = "720x480@refresh";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
 static void drm_cmdline_test_res_bpp_refresh(struct kunit *test)
 {
struct drm_cmdline_mode mode = { };
@@ -411,15 +339,6 @@ static void 
drm_cmdline_test_res_bpp_refresh_force_off(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
 }
 
-static void drm_cmdline_test_res_bpp_refresh_force_on_off(struct kunit *test)
-{
-   struct drm_cmdline_mode mode = { };
-   const char *cmdline =  "720x480-24@60de";
-
-   KUNIT_EXPECT_FALSE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
-  
&no_connector, &mode));
-}
-
 static void drm_cmdline_t

[PATCH 2/2] drm/cmdline-parser: Use assert when needed

[Michał Winiarski]

Expecting to observe a specific value, when the function responsible for
setting the value has failed will lead to extra noise in test output.
Use assert when the situation calls for it.
Also - very small tidying up around the changed areas (whitespace /
variable locality).

Signed-off-by: Michał Winiarski 
---
 .../gpu/drm/tests/drm_cmdline_parser_test.c   | 93 +--
 1 file changed, 46 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c 
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 058808faaf4a..7a313e2fd52a 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -16,7 +16,7 @@ static void drm_cmdline_test_force_e_only(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "e";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
  
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -34,7 +34,7 @@ static void drm_cmdline_test_force_D_only_not_digital(struct 
kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "D";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
  
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -47,16 +47,16 @@ static void 
drm_cmdline_test_force_D_only_not_digital(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_ON);
 }
 
-static const struct drm_connector connector_hdmi = {
-   .connector_type = DRM_MODE_CONNECTOR_HDMIB,
-};
 
 static void drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
 {
struct drm_cmdline_mode mode = { };
+   const struct drm_connector connector_hdmi = {
+   .connector_type = DRM_MODE_CONNECTOR_HDMIB,
+   };
const char *cmdline = "D";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
  
&connector_hdmi, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -69,16 +69,15 @@ static void drm_cmdline_test_force_D_only_hdmi(struct kunit 
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_ON_DIGITAL);
 }
 
-static const struct drm_connector connector_dvi = {
-   .connector_type = DRM_MODE_CONNECTOR_DVII,
-};
-
 static void drm_cmdline_test_force_D_only_dvi(struct kunit *test)
 {
struct drm_cmdline_mode mode = { };
+   const struct drm_connector connector_dvi = {
+   .connector_type = DRM_MODE_CONNECTOR_DVII,
+   };
const char *cmdline = "D";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
  
&connector_dvi, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -96,7 +95,7 @@ static void drm_cmdline_test_force_d_only(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "d";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
  
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -114,7 +113,7 @@ static void drm_cmdline_test_res(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
  
&no_connector, &mode));
KUNIT_EXPECT_TRUE(test, mode.specified);
KUNIT_EXPECT_EQ(test, mode.xres, 720);
@@ -136,7 +135,7 @@ static void drm_cmdline_test_res_vesa(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480M";
 
-   KUNIT_EXPECT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
+   KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_co

[PATCH] drm/display: Fix comment typo

[Jason Wang]

The double `the' is duplicated in the comment, remove one.

Signed-off-by: Jason Wang 
---
 drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index e5bab236b3ae..32b295003f49 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const struct 
drm_dp_aux_msg *msg)
 
 /*
  * Calculate the length of the i2c transfer in usec, assuming
- * the i2c bus speed is as specified. Gives the the "worst"
+ * the i2c bus speed is as specified. Gives the "worst"
  * case estimate, ie. successful while as long as possible.
  * Doesn't account the "MOT" bit, and instead assumes each
  * message includes a START, ADDRESS and STOP. Neither does it
-- 
2.35.1

[PATCH] drm/mipi-dsi: Fix comment typo

[Jason Wang]

The double `the' is duplicated in the comment, remove one.

Signed-off-by: Jason Wang 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index c40bde96cfdf..fd2790a5664d 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -606,7 +606,7 @@ EXPORT_SYMBOL(mipi_dsi_turn_on_peripheral);
 
 /*
  * mipi_dsi_set_maximum_return_packet_size() - specify the maximum size of the
- *the payload in a long packet transmitted from the peripheral back to the
+ *payload in a long packet transmitted from the peripheral back to the
  *host processor
  * @dsi: DSI peripheral device
  * @value: the maximum size of the payload
-- 
2.35.1

[PATCH] drm/panel: nt35510: Fix comment typo

[Jason Wang]

The double `the' is duplicated in the comment, remove one.

Signed-off-by: Jason Wang 
---
 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c 
b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index 40ea41b0a5dd..4085822f619a 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -231,7 +231,7 @@ struct nt35510_config {
 * bits 0..2 in the lower nibble controls HCK, the booster clock
 * frequency, the values are the same as for PCK in @bt1ctr.
 * bits 4..5 in the upper nibble controls BTH, the boosting
-* amplification for the the step-up circuit.
+* amplification for the step-up circuit.
 * 0 = AVDD + VDDB
 * 1 = AVDD - AVEE
 * 2 = AVDD - AVEE + VDDB
-- 
2.35.1

[PATCH] drm/gma500: Fix comment typo

[Jason Wang]

The double `the' is duplicated in the comment, remove one.

Signed-off-by: Jason Wang 
---
 drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index bb2e9d64018a..53b967282d6a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -115,7 +115,7 @@ i2c_algo_dp_aux_stop(struct i2c_adapter *adapter, bool 
reading)
 
 /*
  * Write a single byte to the current I2C address, the
- * the I2C link must be running or this returns -EIO
+ * I2C link must be running or this returns -EIO
  */
 static int
 i2c_algo_dp_aux_put_byte(struct i2c_adapter *adapter, u8 byte)
-- 
2.35.1

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Marco Felsch]

Hi Adam,

On 22-08-04, Adam Ford wrote:
> On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch  wrote:
> >
> > Hi Dave,
> >
> > On 22-08-04, Dave Stevenson wrote:
> > > Hi Marco
> > >
> > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch  wrote:
> > > >
> > > > Hi Dave, Adam,
> > > >
> > > > On 22-08-03, Dave Stevenson wrote:
> > > > > Hi Adam
> > > > >
> > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford  wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Did managed to get access to the ADV7535 programming guide? This 
> > > > > > > is the
> > > > > > > black box here. Let me check if I can provide you a link with our 
> > > > > > > repo
> > > > > > > so you can test our current DSIM state if you want.
> > > > > >
> > > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > > I'll try to answer questions if I can.
> > > > >
> > > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > > from previously looking at these chips.
> > > >
> > > > Thanks for stepping into :)
> > > >
> > > > > Mine fairly plainly states:
> > > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > > specifically, only supports nonburst mode with sync pulses".
> > > >
> > > > I've read this also, and we are working in nonburst mode with sync
> > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > > verify it.
> > > >
> > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > > HDMI pixel rate.
> > > >
> > > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> > >
> > > You have an effective pixel clock, with a fixed conversion for the
> > > configuration.
> > >
> > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> >
> > Okay, I just checked the bandwidth which must equal.
> >
> > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > > running at 891 / 2 = 445.5MHz.
> > >
> > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > > even more explicit about the requirement of DSI timing matching
> > > >
> > > > Is it possible to share the key points of the requirements?
> > >
> > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > > mode requires real time data generation as a pulse packet received
> > > becomes a pulse generated. Therefore this mode requires a continuous
> > > stream of data with correct video timing to avoid any visual
> > > artifacts."
> > >
> > > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> > >
> > > "... the goal is to accurately convey DPI-type timing over DSI. This
> > > includes matching DPI pixel-transmission rates, and widths of timing
> > > events."
> >
> > Thanks for sharing.
> >
> > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > > be correct for 720p operation.
> > > >
> > > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > > GBps.
> > >
> > > Has someone changed the number of lanes in use? I'd missed that if so,
> > > but I'll agree that 891MHz over 2 lanes should work for 720p60.
> >
> > The ADV driver is changing it autom. but this logic is somehow odd and
> > there was already a approach to stop the driver doing this.
> >
> > To sync up: we have two problems:
> >   1) The 720P mode with static DSI host configuration isn't working
> >  without hacks.
> 
> can you share your hacks with me about getting 720p to work?  I've
> been struggling to get 720 to work.

Here you go: https://git.pengutronix.de/cgit/mfe/linux

It has just one branch, so very easy. If you use a 8MMini-EVK with the
NXP-Adapter than you only need a proper defconfig.

> >   2) The DSI link frequency should changed as soon as required
> >  automatically. So we can provide all modes.
> >
> > I would concentrate on problem 1 first before moving on to the 2nd.
> 
> I do have some code that does #2 already. 

Unfortunately no, since we want to fix problem 1 first.

> I can clean it up and share if you want.  I've been bouncing back and
> forth between the NXP kernel and the Jagan/Fabio kernel to compare and
> with my clock change, it appears to be generating similar clocks to
> the NXP, yet it still won't sync at 720P.
> 
> >
> > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > > of the modes that is mandatory to use the timing generator (reg 0x27
> > > bit 7 = 1). On 2 lanes it is not required.
> > > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > > not the base one, as it's only a base clock change with the same
> > > timing (74.176MHz clock instead of 74.25MHz).
> >
> > Interesting! I would like to know how the HDMI block gets fetched by the
> > DSI block and h

Re: [PATCH] drm/amd/display: restore plane with no modifiers code.

[Harry Wentland]

On 2022-08-04 01:50, Dave Airlie wrote:
> When this file was split in
> 
> 5d945cbcd4b16a29d6470a80dfb19738f9a4319f
> Author: Rodrigo Siqueira 
> Date:   Wed Jul 20 15:31:42 2022 -0400
> 
> drm/amd/display: Create a file dedicated to planes
> 
> This chunk seemed to get dropped. Linus noticed on this
> rx580 and I've reproduced on FIJI which makes sense as these
> are pre-modifier GPUs.
> 
> With this applied, I get gdm back.
> 
> Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
> Signed-off-by: Dave Airlie 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 8cd25b2ea0dc..b841b8b0a9d8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -1591,6 +1591,9 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager 
> *dm,
>   if (res)
>   return res;
>  
> + if (modifiers == NULL)
> + adev_to_drm(dm->adev)->mode_config.fb_modifiers_not_supported = 
> true;
> +
>   res = drm_universal_plane_init(adev_to_drm(dm->adev), plane, 
> possible_crtcs,
>  &dm_plane_funcs, formats, num_formats,
>  modifiers, plane->type, NULL);

Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280

[Doug Anderson]

On Thu, Aug 4, 2022 at 3:29 AM Kalyan Thota  wrote:
>
> +static void dpu_hw_ctl_set_dspp_hierarchical_flush(struct dpu_hw_ctl *ctx,
> +   enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
> +{
> +   uint32_t flushbits = 0, active = 0;

nit: don't init to 0 since you just override below.


> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> index ac15444..8ecab91 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> @@ -160,6 +160,9 @@ struct dpu_hw_ctl_ops {
> uint32_t (*get_bitmask_dspp)(struct dpu_hw_ctl *ctx,
> enum dpu_dspp blk);
>
> +   void (*set_dspp_hierarchical_flush)(struct dpu_hw_ctl *ctx,
> +   enum dpu_dspp blk, enum dpu_dspp_sub_blk dspp_sub_blk);
> +

Given that most of the items in this list have kernel-doc comments
explaining them, probably you should have one for your new one too.

-Doug

[PATCH v4 0/6] drm/msm/dsi regulator improvements

[Douglas Anderson]

The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads for DSI drivers.

As of v3 of this series, the regulator API improvements needed for the
later patches in the series are merged into mainline. Thus this series
only contains the DSI changes now.

I'd expect:
* The first two patches are bugfixes found while converting the DSI
  driver over. Those could land any time.
* The third patch ("drm/msm/dsi: Don't set a load before disabling a
  regulator") is a patch a sent the other day verbatim, included in
  this series because it's highly related. It could land any
  time.
* The next two patches use the new APIs. Since those APIs are now in
  mainline those could also land any time.
* The last patch is just cleanup I noticed as I was touching the
  function. It's not really related to regulators but it applies atop
  these. In theory it could be rebased to land separately.

Changes in v4:
- Correct the commit that this Fixes.
- Mention error code change in commit message.
- Use more gooder English in the commit description.

Changes in v3:
- ("Improve dsi_phy_driver_probe() probe error handling") new for v3.
- Do all the PHYs too.
- Fix typo in commit message.
- Get rid of error print after devm_regulator_bulk_get_const().
- Just directly call the bulk commands; get rid of the wrapper.
- Update commit message to point at the git hash of the regulator change.

Changes in v2:
- ("Fix number of regulators for SDM660") new for v2.
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
- ("Take advantage of devm_regulator_bulk_get_const") new for v2.
- ("Use the new regulator bulk feature to specify the load") new for v2.

Douglas Anderson (6):
  drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg
  drm/msm/dsi: Fix number of regulators for SDM660
  drm/msm/dsi: Don't set a load before disabling a regulator
  drm/msm/dsi: Use the new regulator bulk feature to specify the load
  drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const()
  drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling

 drivers/gpu/drm/msm/dsi/dsi.h |  13 --
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |   3 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c|  96 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 160 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |   5 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c|  20 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c|  32 ++--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c|  14 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c|  28 +--
 .../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c   |  12 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c |  32 ++--
 12 files changed, 197 insertions(+), 390 deletions(-)

-- 
2.37.1.455.g008518b4e5-goog

[PATCH v4 4/6] drm/msm/dsi: Use the new regulator bulk feature to specify the load

[Douglas Anderson]

As of commit 6eabfc018e8d ("regulator: core: Allow specifying an
initial load w/ the bulk API") we can now specify the initial load in
the bulk data rather than having to manually call regulator_set_load()
on each regulator. Let's use it.

Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---

(no changes since v3)

Changes in v3:
- Update commit message to point at the git hash of the regulator change.

Changes in v2:
- ("Use the new regulator bulk feature to specify the load") new for v2.

 drivers/gpu/drm/msm/dsi/dsi_host.c| 13 +++--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 13 +++--
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 9df278d39559..a0a1b6d61d05 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -260,8 +260,10 @@ static int dsi_regulator_init(struct msm_dsi_host 
*msm_host)
int num = msm_host->cfg_hnd->cfg->reg_cfg.num;
int i, ret;
 
-   for (i = 0; i < num; i++)
+   for (i = 0; i < num; i++) {
s[i].supply = regs[i].name;
+   s[i].init_load_uA = regs[i].enable_load;
+   }
 
ret = devm_regulator_bulk_get(&msm_host->pdev->dev, num, s);
if (ret < 0) {
@@ -270,15 +272,6 @@ static int dsi_regulator_init(struct msm_dsi_host 
*msm_host)
return ret;
}
 
-   for (i = 0; i < num; i++) {
-   if (regs[i].enable_load >= 0) {
-   ret = regulator_set_load(s[i].consumer,
-regs[i].enable_load);
-   if (ret < 0)
-   return ret;
-   }
-   }
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 7c105120d73e..efb6b1726cdb 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -515,8 +515,10 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
int num = phy->cfg->reg_cfg.num;
int i, ret;
 
-   for (i = 0; i < num; i++)
+   for (i = 0; i < num; i++) {
s[i].supply = regs[i].name;
+   s[i].init_load_uA = regs[i].enable_load;
+   }
 
ret = devm_regulator_bulk_get(dev, num, s);
if (ret < 0) {
@@ -529,15 +531,6 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
return ret;
}
 
-   for (i = 0; i < num; i++) {
-   if (regs[i].enable_load >= 0) {
-   ret = regulator_set_load(s[i].consumer,
-   regs[i].enable_load);
-   if (ret < 0)
-   return ret;
-   }
-   }
-
return 0;
 }
 
-- 
2.37.1.455.g008518b4e5-goog

[PATCH v4 6/6] drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling

[Douglas Anderson]

The dsi_phy_driver_probe() function has a "goto fail" for no
reason. Change it to just always return directly when it sees an
error. Make this simpler by leveraging dev_err_probe() which is
designed to make code like this shorter / simpler.

NOTE: as part of this, we now pass through error codes directly from
msm_ioremap_size() rather than translating to -ENOMEM. This changed
mostly because it's much more convenient when using dev_err_probe()
and also it's usually encouraged not to hide error codes like the old
code was doing unless there is a good reason. I can't see any reason
why we'd need to return -ENOMEM instead of -EINVAL from the probe
function.

Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---

Changes in v4:
- Mention error code change in commit message.

Changes in v3:
- ("Improve dsi_phy_driver_probe() probe error handling") new for v3.

 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 74 ++-
 1 file changed, 27 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 0a00f9b73fc5..57cd525de7a1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -621,12 +621,9 @@ static int dsi_phy_driver_probe(struct platform_device 
*pdev)
phy->pdev = pdev;
 
phy->id = dsi_phy_get_id(phy);
-   if (phy->id < 0) {
-   ret = phy->id;
-   DRM_DEV_ERROR(dev, "%s: couldn't identify PHY index, %d\n",
-   __func__, ret);
-   goto fail;
-   }
+   if (phy->id < 0)
+   return dev_err_probe(dev, phy->id,
+"Couldn't identify PHY index\n");
 
phy->regulator_ldo_mode = of_property_read_bool(dev->of_node,
"qcom,dsi-phy-regulator-ldo-mode");
@@ -634,88 +631,71 @@ static int dsi_phy_driver_probe(struct platform_device 
*pdev)
phy->cphy_mode = (phy_type == PHY_TYPE_CPHY);
 
phy->base = msm_ioremap_size(pdev, "dsi_phy", &phy->base_size);
-   if (IS_ERR(phy->base)) {
-   DRM_DEV_ERROR(dev, "%s: failed to map phy base\n", __func__);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   if (IS_ERR(phy->base))
+   return dev_err_probe(dev, PTR_ERR(phy->base),
+"Failed to map phy base\n");
 
phy->pll_base = msm_ioremap_size(pdev, "dsi_pll", &phy->pll_size);
-   if (IS_ERR(phy->pll_base)) {
-   DRM_DEV_ERROR(&pdev->dev, "%s: failed to map pll base\n", 
__func__);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   if (IS_ERR(phy->pll_base))
+   return dev_err_probe(dev, PTR_ERR(phy->pll_base),
+"Failed to map pll base\n");
 
if (phy->cfg->has_phy_lane) {
phy->lane_base = msm_ioremap_size(pdev, "dsi_phy_lane", 
&phy->lane_size);
-   if (IS_ERR(phy->lane_base)) {
-   DRM_DEV_ERROR(&pdev->dev, "%s: failed to map phy lane 
base\n", __func__);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   if (IS_ERR(phy->lane_base))
+   return dev_err_probe(dev, PTR_ERR(phy->lane_base),
+"Failed to map phy lane base\n");
}
 
if (phy->cfg->has_phy_regulator) {
phy->reg_base = msm_ioremap_size(pdev, "dsi_phy_regulator", 
&phy->reg_size);
-   if (IS_ERR(phy->reg_base)) {
-   DRM_DEV_ERROR(&pdev->dev, "%s: failed to map phy 
regulator base\n", __func__);
-   ret = -ENOMEM;
-   goto fail;
-   }
+   if (IS_ERR(phy->reg_base))
+   return dev_err_probe(dev, PTR_ERR(phy->reg_base),
+"Failed to map phy regulator 
base\n");
}
 
if (phy->cfg->ops.parse_dt_properties) {
ret = phy->cfg->ops.parse_dt_properties(phy);
if (ret)
-   goto fail;
+   return ret;
}
 
ret = devm_regulator_bulk_get_const(dev, phy->cfg->num_regulators,
phy->cfg->regulator_data,
&phy->supplies);
if (ret)
-   goto fail;
+   return ret;
 
phy->ahb_clk = msm_clk_get(pdev, "iface");
-   if (IS_ERR(phy->ahb_clk)) {
-   DRM_DEV_ERROR(dev, "%s: Unable to get ahb clk\n", __func__);
-   ret = PTR_ERR(phy->ahb_clk);
-   goto fail;
-   }
+   if (IS_ERR(phy->ahb_clk))
+   return dev_err_probe(dev, PTR_ERR(phy->ahb_clk),
+"Unable to get ahb clk\n");
 
/* PLL init wi

[PATCH v4 5/6] drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const()

[Douglas Anderson]

As of the commit 1de452a0edda ("regulator: core: Allow drivers to
define their init data as const") we no longer need to do copying of
regulator bulk data from initdata to something dynamic. Let's take
advantage of that.

In addition to saving some code, this also moves us to using
ARRAY_SIZE() to specify how many regulators we have which is less
error prone.

This gets rid of some layers of wrappers which makes it obvious that
we can get rid of an extra error print.
devm_regulator_bulk_get_const() prints errors for you so you don't
need an extra layer of printing.

In all cases here I have preserved the old settings without any
investigation about whether the loads being set are sensible. In the
cases of some of the PHYs if several PHYs in the same file used
exactly the same settings I had them point to the same data structure.

NOTE: Though I haven't done the math, this is likely an overall
savings in terms of "static const" data. We previously always
allocated space for 8 supplies. Each of these supplies took up 36
bytes of data (32 for name, 4 for an int).

Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---

(no changes since v3)

Changes in v3:
- Do all the PHYs too.
- Get rid of error print after devm_regulator_bulk_get_const().
- Just directly call the bulk commands; get rid of the wrapper.
- Update commit message to point at the git hash of the regulator change.

Changes in v2:
- ("Take advantage of devm_regulator_bulk_get_const") new for v2.

 drivers/gpu/drm/msm/dsi/dsi.h |  12 --
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |   3 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c|  42 ++---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  37 +---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |   5 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c|  20 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c|  32 ++--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c|  14 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c|  28 +--
 .../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c   |  12 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c |  32 ++--
 12 files changed, 167 insertions(+), 242 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index bb6a5bd05cb1..d661510d570d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -30,20 +30,8 @@ enum msm_dsi_phy_usecase {
MSM_DSI_PHY_SLAVE,
 };
 
-#define DSI_DEV_REGULATOR_MAX  8
 #define DSI_BUS_CLK_MAX4
 
-/* Regulators for DSI devices */
-struct dsi_reg_entry {
-   char name[32];
-   int enable_load;
-};
-
-struct dsi_reg_config {
-   int num;
-   struct dsi_reg_entry regs[DSI_DEV_REGULATOR_MAX];
-};
-
 struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 901d6fd53800..7e97c239ed48 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -9,16 +9,16 @@ static const char * const dsi_v2_bus_clk_names[] = {
"core_mmss", "iface", "bus",
 };
 
+static const struct regulator_bulk_data apq8064_dsi_regulators[] = {
+   { .supply = "vdda", .init_load_uA = 10 },   /* 1.2 V */
+   { .supply = "avdd", .init_load_uA = 1 },/* 3.0 V */
+   { .supply = "vddio", .init_load_uA = 10 },  /* 1.8 V */
+};
+
 static const struct msm_dsi_config apq8064_dsi_cfg = {
.io_offset = 0,
-   .reg_cfg = {
-   .num = 3,
-   .regs = {
-   {"vdda", 10},   /* 1.2 V */
-   {"avdd", 1},/* 3.0 V */
-   {"vddio", 10},  /* 1.8 V */
-   },
-   },
+   .regulator_data = apq8064_dsi_regulators,
+   .num_regulators = ARRAY_SIZE(apq8064_dsi_regulators),
.bus_clk_names = dsi_v2_bus_clk_names,
.num_bus_clks = ARRAY_SIZE(dsi_v2_bus_clk_names),
.io_start = { 0x470, 0x580 },
@@ -29,16 +29,16 @@ static const char * const dsi_6g_bus_clk_names[] = {
"mdp_core", "iface", "bus", "core_mmss",
 };
 
+static const struct regulator_bulk_data msm8974_apq8084_regulators[] = {
+   { .supply = "vdd", .init_load_uA = 15 },/* 3.0 V */
+   { .supply = "vdda", .init_load_uA = 10 },   /* 1.2 V */
+   { .supply = "vddio", .init_load_uA = 10 },  /* 1.8 V */
+};
+
 static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
-   .reg_cfg = {
-   .num = 3,
-   .regs = {
-   {"vdd", 15},/* 3.0 V */
-   {"vdda", 10},   /* 1.2 V */
-   {"vddio", 10},  /* 1.8 V */
-   },
-   },
+   .regulator_data = msm8974_apq8084_regulators

[PATCH v4 3/6] drm/msm/dsi: Don't set a load before disabling a regulator

[Douglas Anderson]

As of commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually doing anything
useful. Let's remove it.

It should be noted that all of the loads set that were being specified
were pointless noise anyway. The only use for this number is to pick
between low power and high power modes of regulators. Regulators
appear to do this changeover at loads on the order of 1 uA. You
would need a lot of clients of the same rail for that 100 uA number to
count for anything.

Note that now that we get rid of the setting of the load at disable
time, we can just set the load once when we first get the regulator
and then forget it.

It should also be noted that the regulator functions
regulator_bulk_enable() and regulator_set_load() already print error
messages when they encounter problems so while moving things around we
get rid of some extra error prints.

Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---

(no changes since v3)

Changes in v3:
- Fix typo in commit message.
- Just directly call the bulk commands; get rid of the wrapper.

 drivers/gpu/drm/msm/dsi/dsi.h |  1 -
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 52 +++---
 drivers/gpu/drm/msm/dsi/dsi_host.c| 71 ---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 52 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c|  4 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c|  6 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c|  4 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c|  6 +-
 .../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c   |  2 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c |  6 +-
 10 files changed, 60 insertions(+), 144 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 580a1e6358bf..bb6a5bd05cb1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -37,7 +37,6 @@ enum msm_dsi_phy_usecase {
 struct dsi_reg_entry {
char name[32];
int enable_load;
-   int disable_load;
 };
 
 struct dsi_reg_config {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 72c018e26f47..901d6fd53800 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -14,9 +14,9 @@ static const struct msm_dsi_config apq8064_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
-   {"vdda", 10, 100},  /* 1.2 V */
-   {"avdd", 1, 100},   /* 3.0 V */
-   {"vddio", 10, 100}, /* 1.8 V */
+   {"vdda", 10},   /* 1.2 V */
+   {"avdd", 1},/* 3.0 V */
+   {"vddio", 10},  /* 1.8 V */
},
},
.bus_clk_names = dsi_v2_bus_clk_names,
@@ -34,9 +34,9 @@ static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
-   {"vdd", 15, 100},   /* 3.0 V */
-   {"vdda", 10, 100},  /* 1.2 V */
-   {"vddio", 10, 100}, /* 1.8 V */
+   {"vdd", 15},/* 3.0 V */
+   {"vdda", 10},   /* 1.2 V */
+   {"vddio", 10},  /* 1.8 V */
},
},
.bus_clk_names = dsi_6g_bus_clk_names,
@@ -54,8 +54,8 @@ static const struct msm_dsi_config msm8916_dsi_cfg = {
.reg_cfg = {
.num = 2,
.regs = {
-   {"vdda", 10, 100},  /* 1.2 V */
-   {"vddio", 10, 100}, /* 1.8 V */
+   {"vdda", 10},   /* 1.2 V */
+   {"vddio", 10},  /* 1.8 V */
},
},
.bus_clk_names = dsi_8916_bus_clk_names,
@@ -73,8 +73,8 @@ static const struct msm_dsi_config msm8976_dsi_cfg = {
.reg_cfg = {
.num = 2,
.regs = {
-   {"vdda", 10, 100},  /* 1.2 V */
-   {"vddio", 10, 100}, /* 1.8 V */
+   {"vdda", 10},   /* 1.2 V */
+   {"vddio", 10},  /* 1.8 V */
},
},
.bus_clk_names = dsi_8976_bus_clk_names,
@@ -88,12 +88,12 @@ static const struct msm_dsi_config msm8994_dsi_cfg = {
.reg_cfg = {
.num = 6,
.regs = {
-   {"vdda", 10, 100},  /* 1.25 V */
-   {"vddio", 10, 100}, /* 1.8 V */
-   {"vcca", 1, 100},   /* 1.0 V */
-   {"vdd", 10, 100},   /* 1.8 V */
-   {"la

[PATCH v4 2/6] drm/msm/dsi: Fix number of regulators for SDM660

[Douglas Anderson]

1 regulator is listed but the number 2 is specified. This presumably
means we try to get a regulator with no name. Fix it.

Fixes: 462f7017a691 ("drm/msm/dsi: Fix DSI and DSI PHY regulator config from 
SDM660")
Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Reviewed-by: Abhinav Kumar 
---

Changes in v4:
- Correct the commit that this Fixes.
- Use more gooder English in the commit description.

Changes in v2:
- ("Fix number of regulators for SDM660") new for v2.

 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 02000a7b7a18..72c018e26f47 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -148,7 +148,7 @@ static const char * const dsi_sdm660_bus_clk_names[] = {
 static const struct msm_dsi_config sdm660_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
-   .num = 2,
+   .num = 1,
.regs = {
{"vdda", 12560, 4 },/* 1.2 V */
},
-- 
2.37.1.455.g008518b4e5-goog

[PATCH v4 1/6] drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg

[Douglas Anderson]

3 regulators are listed but the number 2 is specified. Fix it.

Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 info in dsi_cfg")
Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---

Changes in v4:
- Use more gooder English in the commit description.

Changes in v2:
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.

 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 2c23324a2296..02000a7b7a18 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -109,7 +109,7 @@ static const char * const dsi_8996_bus_clk_names[] = {
 static const struct msm_dsi_config msm8996_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
-   .num = 2,
+   .num = 3,
.regs = {
{"vdda", 18160, 1 },/* 1.25 V */
{"vcca", 17000, 32 },   /* 0.925 V */
-- 
2.37.1.455.g008518b4e5-goog

RE: imx8mm lcdif->dsi->adv7535 no video, no errors

[Biju Das]

Hi Adam,

> Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> 
> On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch 
> wrote:
> >
> > Hi Dave,
> >
> > On 22-08-04, Dave Stevenson wrote:
> > > Hi Marco
> > >
> > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch 
> wrote:
> > > >
> > > > Hi Dave, Adam,
> > > >
> > > > On 22-08-03, Dave Stevenson wrote:
> > > > > Hi Adam
> > > > >
> > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford 
> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Did managed to get access to the ADV7535 programming guide?
> > > > > > > This is the black box here. Let me check if I can provide
> > > > > > > you a link with our repo so you can test our current DSIM
> state if you want.
> > > > > >
> > > > > > I do have access to the programming guide, but it's under NDA,
> > > > > > but I'll try to answer questions if I can.
> > > > >
> > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > 7535 from previously looking at these chips.
> > > >
> > > > Thanks for stepping into :)
> > > >
> > > > > Mine fairly plainly states:
> > > > > "The DSI receiver input supports DSI video mode operation only,
> > > > > and specifically, only supports nonburst mode with sync pulses".
> > > >
> > > > I've read this also, and we are working in nonburst mode with sync
> > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > > verify it.
> > > >
> > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same
> > > > > as the HDMI pixel rate.
> > > >
> > > > On DSI side you don't have a pixel-clock instead there is bit-
> clock.
> > >
> > > You have an effective pixel clock, with a fixed conversion for the
> > > configuration.
> > >
> > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> >
> > Okay, I just checked the bandwidth which must equal.
> >
> > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > > running at 891 / 2 = 445.5MHz.
> > >
> > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide
> > > > > is even more explicit about the requirement of DSI timing
> > > > > matching
> > > >
> > > > Is it possible to share the key points of the requirements?
> > >
> > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > This mode requires real time data generation as a pulse packet
> > > received becomes a pulse generated. Therefore this mode requires a
> > > continuous stream of data with correct video timing to avoid any
> > > visual artifacts."
> > >
> > > LP mode is supported on data lanes. Clock lane must remain in HS
> mode.
> > >
> > > "... the goal is to accurately convey DPI-type timing over DSI. This
> > > includes matching DPI pixel-transmission rates, and widths of timing
> > > events."
> >
> > Thanks for sharing.
> >
> > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > therefore be correct for 720p operation.
> > > >
> > > > It should be absolute no difference if you work on 891MHz with 2
> > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > you need the minimum required bandwidth which is roughly:
> > > > 1280*720*24*60 = 1.327 GBps.
> > >
> > > Has someone changed the number of lanes in use? I'd missed that if
> > > so, but I'll agree that 891MHz over 2 lanes should work for 720p60.
> >
> > The ADV driver is changing it autom. but this logic is somehow odd and
> > there was already a approach to stop the driver doing this.
> >
> > To sync up: we have two problems:
> >   1) The 720P mode with static DSI host configuration isn't working
> >  without hacks.
> 
> can you share your hacks with me about getting 720p to work?  I've been
> struggling to get 720 to work.

I have problems with 720p working on 3 lanes. Then I switch to 4 lanes [1]
and it starts working on Renesas RZ/G2L SMARC EVK.

[1] 
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220309151109.20957-2-biju.das...@bp.renesas.com/

Cheers,
Biju

Re: New subsystem for acceleration devices

[Jason Gunthorpe]

On Thu, Aug 04, 2022 at 10:43:42AM +0300, Oded Gabbay wrote:

> After all, memory management services, or common device chars handling
> I can get from other subsystems (e.g. rdma) as well. I'm sure I could
> model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI
> there as well), but this doesn't mean I belong there, right ?

You sure can, but there is still an expectation, eg in RDMA, that your
device has a similarity to the established standards (like roce in
habana's case) that RDMA is geared to support.

I think the the most important thing to establish a new subsystem is
to actually identify what commonalities it is supposed to be
providing. Usually this is driven by some standards body, but the
AI/ML space hasn't gone in that direction at all yet.

We don't need a "subsystem" to have a bunch of drivers expose chardevs
with completely unique ioctls.

The flip is true of DRM - DRM is pretty general. I bet I could
implement an RDMA device under DRM - but that doesn't mean it should
be done.

My biggest concern is that this subsystem not turn into a back door
for a bunch of abuse of kernel APIs going forward. Though things are
better now, we still see this in DRM where expediency or performance
justifies hacky shortcuts instead of good in-kernel architecture. At
least DRM has reliable and experienced review these days.

Jason

Re: imx8mm lcdif->dsi->adv7535 no video, no errors

[Dave Stevenson]

On Thu, 4 Aug 2022 at 13:51, Marco Felsch  wrote:
>
> Hi Dave,
>
> On 22-08-04, Dave Stevenson wrote:
> > Hi Marco
> >
> > On Thu, 4 Aug 2022 at 10:38, Marco Felsch  wrote:
> > >
> > > Hi Dave, Adam,
> > >
> > > On 22-08-03, Dave Stevenson wrote:
> > > > Hi Adam
> > > >
> > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford  wrote:
> > >
> > > ...
> > >
> > > > > > Did managed to get access to the ADV7535 programming guide? This is 
> > > > > > the
> > > > > > black box here. Let me check if I can provide you a link with our 
> > > > > > repo
> > > > > > so you can test our current DSIM state if you want.
> > > > >
> > > > > I do have access to the programming guide, but it's under NDA, but
> > > > > I'll try to answer questions if I can.
> > > >
> > > > Not meaning to butt in, but I have datasheets for ADV7533 and 7535
> > > > from previously looking at these chips.
> > >
> > > Thanks for stepping into :)
> > >
> > > > Mine fairly plainly states:
> > > > "The DSI receiver input supports DSI video mode operation only, and
> > > > specifically, only supports nonburst mode with sync pulses".
> > >
> > > I've read this also, and we are working in nonburst mode with sync
> > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > verify it.
> > >
> > > > Non-burst mode meaning that the DSI pixel rate MUST be the same as the
> > > > HDMI pixel rate.
> > >
> > > On DSI side you don't have a pixel-clock instead there is bit-clock.
> >
> > You have an effective pixel clock, with a fixed conversion for the
> > configuration.
> >
> > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
>
> Okay, I just checked the bandwidth which must equal.
>
> > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > running at 891 / 2 = 445.5MHz.
> >
> > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide is
> > > > even more explicit about the requirement of DSI timing matching
> > >
> > > Is it possible to share the key points of the requirements?
> >
> > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. This
> > mode requires real time data generation as a pulse packet received
> > becomes a pulse generated. Therefore this mode requires a continuous
> > stream of data with correct video timing to avoid any visual
> > artifacts."
> >
> > LP mode is supported on data lanes. Clock lane must remain in HS mode.
> >
> > "... the goal is to accurately convey DPI-type timing over DSI. This
> > includes matching DPI pixel-transmission rates, and widths of timing
> > events."
>
> Thanks for sharing.
>
> > > > The NXP kernel switching down to an hs_clk of 445.5MHz would therefore
> > > > be correct for 720p operation.
> > >
> > > It should be absolute no difference if you work on 891MHz with 2 lanes
> > > or on 445.5 MHz with 4 lanes. What must be ensured is that you need the
> > > minimum required bandwidth which is roughly: 1280*720*24*60 = 1.327
> > > GBps.
> >
> > Has someone changed the number of lanes in use? I'd missed that if so,
> > but I'll agree that 891MHz over 2 lanes should work for 720p60.
>
> The ADV driver is changing it autom. but this logic is somehow odd and
> there was already a approach to stop the driver doing this.

I'd missed that bit in the driver where it appears to drop to 3 lanes
for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but
probably the only way it can be achieved in the current framework.

> To sync up: we have two problems:
>   1) The 720P mode with static DSI host configuration isn't working
>  without hacks.
>   2) The DSI link frequency should changed as soon as required
>  automatically. So we can provide all modes.
>
> I would concentrate on problem 1 first before moving on to the 2nd.

If you change your link frequency, it may be worth trying a lower
resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4
lanes is again listed as mandatory for using the timing generator).

> > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as one
> > of the modes that is mandatory to use the timing generator (reg 0x27
> > bit 7 = 1). On 2 lanes it is not required.
> > I don't know why it's referencing the 1000/1001 pixel clock rates and
> > not the base one, as it's only a base clock change with the same
> > timing (74.176MHz clock instead of 74.25MHz).
>
> Interesting! I would like to know how the HDMI block gets fetched by the
> DSI block and how the timing-generator can influence this in good/bad
> way. So that we know what DSI settings (freq, lanes) are sufficient.
>
> > > > If you do program the manual DSI divider register to allow a DSI pixel
> > > > rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, you'd be relying on
> > >
> > > There is no such DSI pixel rate to be precise, we only have a DSI bit
> > > clock/rate.
> > >
> > > > the ADV753x having at least a half-line FIFO between DSI rx and HDMI
> > > > tx to compensate for the d

[PATCH v2 0/4] Documentation/amdgpu/display: describe color and blend mode properties mapping

[Melissa Wen]

As mentioned in the previous version, patches 1 and 2 describe DM
mapping of DRM color correction properties to DC interface and where
detached from 3D LUT RFC series [1]. Patches 3 and 4 describe MPC block
programming that matches the three DRM blend modes and came from
previous work [2][3] and discussions on AMD issue tracker. Let me know
any misleading information.

In this version, typos were fixed and I removed unusual kernel-docs
inside functions, as suggested by Tales. I also added description of
some struct elements thanks to Siqueira's feedback. I restructured the
introdutory text of the color section, but preserved the content.
Unfortunately, there are some missing definitions for mpc_blnd_cfg, that
I appreciate if someone can provide more information:

./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter 
or member 'overlap_only' not described in 'mpcc_blnd_cfg'
./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter 
or member 'bottom_gain_mode' not described in 'mpcc_blnd_cfg'
./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter 
or member 'background_color_bpc' not described in 'mpcc_blnd_cfg'
./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter 
or member 'top_gain' not described in 'mpcc_blnd_cfg'
./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter 
or member 'bottom_inside_gain' not described in 'mpcc_blnd_cfg'
./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:109: warning: Function parameter 
or member 'bottom_outside_gain' not described in 'mpcc_blnd_cfg' 

[1] https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
[2] https://lore.kernel.org/amd-gfx/20220329201835.2393141-1-m...@igalia.com/
[3] 
https://lore.kernel.org/amd-gfx/7a95d6a4-bc2f-b0e8-83f8-8cc5b7559...@amd.com/

Melissa Wen (4):
  Documentation/amdgpu_dm: Add DM color correction documentation
  Documentation/amdgpu/display: add DC color caps info
  drm/amd/display: add doc entries for MPC blending configuration
  Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode

 .../gpu/amdgpu/display/dc-glossary.rst|2 +-
 .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++
 .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 +
 .../gpu/amdgpu/display/display-manager.rst|  141 ++
 Documentation/gpu/drm-kms.rst |2 +
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   |  109 +-
 drivers/gpu/drm/amd/display/dc/dc.h   |   77 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h   |   91 +-
 8 files changed, 3265 insertions(+), 56 deletions(-)
 create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
 create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg

-- 
2.35.1

[PATCH v2 1/4] Documentation/amdgpu_dm: Add DM color correction documentation

[Melissa Wen]

AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.

v2:
- rebase to amd-staging-drm-next
- fix typos (Tales)
- undo kernel-docs inside functions (Tales)

Signed-off-by: Melissa Wen 
Reviewed-by: Harry Wentland 
Reviewed-by: Tales Aparecida 
---
 .../gpu/amdgpu/display/display-manager.rst|   9 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_color.c   | 109 +-
 2 files changed, 90 insertions(+), 28 deletions(-)

diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst 
b/Documentation/gpu/amdgpu/display/display-manager.rst
index 7ce31f89d9a0..b1b0f11aed83 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -40,3 +40,12 @@ Atomic Implementation
 
 .. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
:functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail
+
+Color Management Properties
+===
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+   :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+   :internal:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index a71177305bcd..a4cb23d059bd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -29,7 +29,9 @@
 #include "modules/color/color_gamma.h"
 #include "basics/conversion.h"
 
-/*
+/**
+ * DOC: overview
+ *
  * The DC interface to HW gives us the following color management blocks
  * per pipe (surface):
  *
@@ -71,8 +73,8 @@
 
 #define MAX_DRM_LUT_VALUE 0x
 
-/*
- * Initialize the color module.
+/**
+ * amdgpu_dm_init_color_mod - Initialize the color module.
  *
  * We're not using the full color module, only certain components.
  * Only call setup functions for components that we need.
@@ -82,7 +84,14 @@ void amdgpu_dm_init_color_mod(void)
setup_x_points_distribution();
 }
 
-/* Extracts the DRM lut and lut size from a blob. */
+/**
+ * __extract_blob_lut - Extracts the DRM lut and lut size from a blob.
+ * @blob: DRM color mgmt property blob
+ * @size: lut size
+ *
+ * Returns:
+ * DRM LUT or NULL
+ */
 static const struct drm_color_lut *
 __extract_blob_lut(const struct drm_property_blob *blob, uint32_t *size)
 {
@@ -90,13 +99,18 @@ __extract_blob_lut(const struct drm_property_blob *blob, 
uint32_t *size)
return blob ? (struct drm_color_lut *)blob->data : NULL;
 }
 
-/*
- * Return true if the given lut is a linear mapping of values, i.e. it acts
- * like a bypass LUT.
+/**
+ * __is_lut_linear - check if the given lut is a linear mapping of values
+ * @lut: given lut to check values
+ * @size: lut size
  *
  * It is considered linear if the lut represents:
- * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in
- *   [0, MAX_COLOR_LUT_ENTRIES)
+ * f(a) = (0xFF00/MAX_COLOR_LUT_ENTRIES-1)a; for integer a in [0,
+ * MAX_COLOR_LUT_ENTRIES)
+ *
+ * Returns:
+ * True if the given lut is a linear mapping of values, i.e. it acts like a
+ * bypass LUT. Otherwise, false.
  */
 static bool __is_lut_linear(const struct drm_color_lut *lut, uint32_t size)
 {
@@ -119,9 +133,13 @@ static bool __is_lut_linear(const struct drm_color_lut 
*lut, uint32_t size)
return true;
 }
 
-/*
- * Convert the drm_color_lut to dc_gamma. The conversion depends on the size
- * of the lut - whether or not it's legacy.
+/**
+ * __drm_lut_to_dc_gamma - convert the drm_color_lut to dc_gamma.
+ * @lut: DRM lookup table for color conversion
+ * @gamma: DC gamma to set entries
+ * @is_legacy: legacy or atomic gamma
+ *
+ * The conversion depends on the size of the lut - whether or not it's legacy.
  */
 static void __drm_lut_to_dc_gamma(const struct drm_color_lut *lut,
  struct dc_gamma *gamma, bool is_legacy)
@@ -154,8 +172,11 @@ static void __drm_lut_to_dc_gamma(const struct 
drm_color_lut *lut,
}
 }
 
-/*
- * Converts a DRM CTM to a DC CSC float matrix.
+/**
+ * __drm_ctm_to_dc_matrix - converts a DRM CTM to a DC CSC float matrix
+ * @ctm: DRM color transformation matrix
+ * @matrix: DC CSC float matrix
+ *
  * The matrix needs to be a 3x4 (12 entry) matrix.
  */
 static void __drm_ctm_to_dc_matrix(const struct drm_color_ctm *ctm,
@@ -189,7 +210,18 @@ static void __drm_ctm_to_dc_matrix(const struct 
drm_color_ctm *ctm,
}
 }
 
-/* Calculates the legacy transfer function - only for sRGB input space. */
+/**
+ * __set_legacy_tf - Calculates the legacy transfer function
+ * @func: transfer function
+ * @lut: lookup table that defines the color space
+ * @lut_size: size of respective lut
+ * @has_rom: if ROM can be used for hardcoded curve
+ *
+ * Only for sRGB input s

[PATCH v2 2/4] Documentation/amdgpu/display: add DC color caps info

[Melissa Wen]

Add details about color correction capabilities and explain a bit about
differences between DC hw generations and also how they are mapped
between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted
to svg from the original png) is included to illustrate it. They were
obtained from a discussion[1] in the amd-gfx mailing list.

[1] 
https://lore.kernel.org/amd-gfx/20220422142811.dm6vtk6v64jcw...@mail.igalia.com/

v1:
- remove redundant comments (Harry)
- fix typos (Harry)

v2:
- reword introduction of color section
- add co-dev tag for Harry - who provided most of the info
- fix typos (Tales)
- describe missing struct parameters (Tales and Siqueira)

Co-developed-by: Harry Wentland 
Signed-off-by: Harry Wentland 
Signed-off-by: Melissa Wen 
Reviewed-by: Tales Aparecida 
---
 .../amdgpu/display/dcn2_cm_drm_current.svg| 1370 +++
 .../amdgpu/display/dcn3_cm_drm_current.svg| 1529 +
 .../gpu/amdgpu/display/display-manager.rst|   34 +
 drivers/gpu/drm/amd/display/dc/dc.h   |   77 +-
 4 files changed, 2997 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
 create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg

diff --git a/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg 
b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
new file mode 100644
index ..315ffc5a1a4b
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg
@@ -0,0 +1,1370 @@
+
+
+
+http://www.inkscape.org/namespaces/inkscape";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns="http://www.w3.org/2000/svg";
+   xmlns:svg="http://www.w3.org/2000/svg";>
+  
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Matrix
+1D LUT
+3D LUT
+Unpacking
+Other
+drm_framebuffer
+format
+drm_plane
+drm_crtc
+Stream
+MPC
+DPP
+
+Blender
+Degamma
+CTM
+Gamma
+format
+bias_and_scale
+color space matrix
+input_csc_color_matrix
+in_transfer_func
+hdr_mult
+gamut_remap_matrix
+in_shaper_func
+lut3d_func
+blend_tf
+Blender
+gamut_remap_matrix
+func_shaper
+lut3d_func
+out_transfer_func
+csc_color_matrix
+bit_depth_param
+clamping
+output_color_space
+Plane
+Legend
+DCN 2.0
+DC Interface
+DRM Interface
+
+CNVC
+Input CSC
+DeGammaRAM and ROM(sRGB, BT2020
+HDR Multiply
+Gamut Remap
+Shaper 
LUTRAM
+3D 
LUTRAM
+Blend Gamma
+Blender
+GammaRAM
+OCSC
+
+
+color_encoding
+
+pixel_blend_mode
+
+color_range
+
+
+
+
+
+
+
+
+
+
+
+
+  
+
diff --git a/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg 
b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg
new file mode 100644
index ..7299ee9b6d64
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg
@@ -0,0 +1,1529 @@
+
+
+
+http://www.inkscape.org/namespaces/inkscape";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns="http://www.w3.org/2000/svg";
+   xmlns:svg="http://www.w3.org/2000/svg";>
+  
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Matrix
+1D LUT
+3D LUT
+Unpacking
+Other
+drm_framebuffer
+format
+drm_plane
+drm_crtc
+Stream
+MPC
+DPP
+
+Blender
+Degamma
+CTM
+Gamma
+format
+bias_and_scale
+color space matrix
+input_csc_color_matrix
+in_transfer_func
+hdr_mult
+gamut_remap_matrix
+in_shaper_func
+lut3d_func
+blend_tf
+Blender
+gamut_remap_matrix
+func_shaper
+lut3d_func
+out_transfer_func
+csc_color_matrix
+bit_depth_param
+clamping
+output_color_space
+Plane
+Legend
+DCN 3.0
+DC Interface
+DRM Interface
+
+CNVC
+Input CSC
+DeGammaROM(sRGB,

[PATCH v2 3/4] drm/amd/display: add doc entries for MPC blending configuration

[Melissa Wen]

Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discussions on AMD issue tracker[1][2].

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1734
[2] https://gitlab.freedesktop.org/drm/amd/-/issues/1769

v2:
- fix typos (Tales)
- add MPCC to MPC entry in the glossary

Signed-off-by: Melissa Wen 
Reviewed-by: Tales Aparecida 
---
 .../gpu/amdgpu/display/dc-glossary.rst|  2 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h   | 91 ---
 2 files changed, 78 insertions(+), 15 deletions(-)

diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst 
b/Documentation/gpu/amdgpu/display/dc-glossary.rst
index 116f5f0942fd..0b0ffd428dd2 100644
--- a/Documentation/gpu/amdgpu/display/dc-glossary.rst
+++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst
@@ -170,7 +170,7 @@ consider asking in the amdgfx and update this page.
 MC
   Memory Controller
 
-MPC
+MPC/MPCC
   Multiple pipes and plane combine
 
 MPO
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
index 5097037e3962..8d86159d9de0 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
@@ -22,6 +22,16 @@
  *
  */
 
+/**
+ * DOC: mpc-overview
+ *
+ * Multiple Pipe/Plane Combined (MPC) is a component in the hardware pipeline
+ * that performs blending of multiple planes, using global and per-pixel alpha.
+ * It also performs post-blending color correction operations according to the
+ * hardware capabilities, such as color transformation matrix and gamma 1D and
+ * 3D LUT.
+ */
+
 #ifndef __DC_MPCC_H__
 #define __DC_MPCC_H__
 
@@ -48,14 +58,39 @@ enum mpcc_blend_mode {
MPCC_BLEND_MODE_TOP_BOT_BLENDING
 };
 
+/**
+ * enum mpcc_alpha_blend_mode - define the alpha blend mode regarding pixel
+ * alpha and plane alpha values
+ */
 enum mpcc_alpha_blend_mode {
+   /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA: per pixel alpha using DPP
+* alpha value
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA,
+   /**
+* @MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN: per
+* pixel alpha using DPP alpha value multiplied by a global gain (plane
+* alpha)
+*/
MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN,
+   /**
+* @MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA: global alpha value, ignores
+* pixel alpha and consider only plane alpha
+*/
MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA
 };
 
-/*
- * MPCC blending configuration
+/**
+ * struct mpcc_blnd_cfg - MPCC blending configuration
+ *
+ * @black_color: background color
+ * @alpha_mode: alpha blend mode (MPCC_ALPHA_BLND_MODE)
+ * @pre_multiplied_alpha: whether pixel color values were pre-multiplied by the
+ * alpha channel (MPCC_ALPHA_MULTIPLIED_MODE)
+ * @global_gain: used when blend mode considers both pixel alpha and plane
+ * alpha value and assumes the global alpha value.
+ * @global_alpha: plane alpha value
  */
 struct mpcc_blnd_cfg {
struct tg_color black_color;/* background color */
@@ -107,8 +142,15 @@ struct mpc_dwb_flow_control {
int flow_ctrl_cnt1;
 };
 
-/*
- * MPCC connection and blending configuration for a single MPCC instance.
+/**
+ * struct mpcc - MPCC connection and blending configuration for a single MPCC 
instance.
+ * @mpcc_id: MPCC physical instance
+ * @dpp_id: DPP input to this MPCC
+ * @mpcc_bot: pointer to bottom layer MPCC. NULL when not connected.
+ * @blnd_cfg: the blending configuration for this MPCC
+ * @sm_cfg: stereo mix setting for this MPCC
+ * @shared_bottom: if MPCC output to both OPP and DWB endpoints, true. 
Otherwise, false.
+ *
  * This struct is used as a node in an MPC tree.
  */
 struct mpcc {
@@ -120,8 +162,12 @@ struct mpcc {
bool shared_bottom; /* TRUE if MPCC output to both OPP and 
DWB endpoints, else FALSE */
 };
 
-/*
- * MPC tree represents all MPCC connections for a pipe.
+/**
+ * struct mpc_tree - MPC tree represents all MPCC connections for a pipe.
+ *
+ * @opp_id: the OPP instance that owns this MPC tree
+ * @opp_list: the top MPCC layer of the MPC tree that outputs to OPP endpoint
+ *
  */
 struct mpc_tree {
int opp_id; /* The OPP instance that owns this MPC 
tree */
@@ -149,13 +195,18 @@ struct mpcc_state {
uint32_t busy;
 };
 
+/**
+ * struct mpc_funcs - funcs
+ */
 struct mpc_funcs {
void (*read_mpcc_state)(
struct mpc *mpc,
int mpcc_inst,
struct mpcc_state *s);
 
-   /*
+   /**
+* @insert_plane:
+*
 * Insert DPP into MPC tree based on specified blending position.
 * Only used for planes that are part of blending chain for OPP output
 *
@@ -

[PATCH v2 4/4] Documentation/gpu/amdgpu/amdgpu_dm: add DM docs for pixel blend mode

[Melissa Wen]

AMD GPU display manager (DM) maps DRM pixel blend modes (None,
Pre-multiplied, Coverage) to MPC hw blocks through blend configuration
options. Describe relevant elements and how to set and test them to get
the expected DRM blend mode on DCN hw.

v2:
- add ref tag (Tales)

Signed-off-by: Melissa Wen 
Reviewed-by: Tales Aparecida 
---
 .../gpu/amdgpu/display/display-manager.rst| 98 +++
 Documentation/gpu/drm-kms.rst |  2 +
 2 files changed, 100 insertions(+)

diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst 
b/Documentation/gpu/amdgpu/display/display-manager.rst
index 88e2c08c7014..b7abb18cfc82 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -83,3 +83,101 @@ schemas.
 **DCN 3.0 family color caps and mapping**
 
 .. kernel-figure:: dcn3_cm_drm_current.svg
+
+Blend Mode Properties
+=
+
+Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` 
used to
+describes how pixels from a foreground plane (fg) are composited with the
+background plane (bg). Here, we present main concepts of DRM blend mode to help
+to understand how this property is mapped to AMD DC interface. See more about
+this DRM property and the alpha blending equations in :ref:`DRM Plane
+Composition Properties `.
+
+Basically, a blend mode sets the alpha blending equation for plane
+composition that fits the mode in which the alpha channel affects the state of
+pixel color values and, therefore, the resulted pixel color. For
+example, consider the following elements of the alpha blending equation:
+
+- *fg.rgb*: Each of the RGB component values from the foreground's pixel.
+- *fg.alpha*: Alpha component value from the foreground's pixel.
+- *bg.rgb*: Each of the RGB component values from the background.
+- *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see
+  more in :ref:`DRM Plane Composition Properties 
`.
+
+in the basic alpha blending equation::
+
+   out.rgb = alpha * fg.rgb + (1 - alpha) * bg.rgb
+
+the alpha channel value of each pixel in a plane is ignored and only the plane
+alpha affects the resulted pixel color values.
+
+DRM has three blend mode to define the blend formula in the plane composition:
+
+* **None**: Blend formula that ignores the pixel alpha.
+
+* **Pre-multiplied**: Blend formula that assumes the pixel color values in a
+  plane was already pre-multiplied by its own alpha channel before storage.
+
+* **Coverage**: Blend formula that assumes the pixel color values were not
+  pre-multiplied with the alpha channel values.
+
+and pre-multiplied is the default pixel blend mode, that means, when no blend
+mode property is created or defined, DRM considers the plane's pixels has
+pre-multiplied color values. On IGT GPU tools, the kms_plane_alpha_blend test
+provides a set of subtests to verify plane alpha and blend mode properties.
+
+The DRM blend mode and its elements are then mapped by AMDGPU display manager
+(DM) to program the blending configuration of the Multiple Pipe/Plane Combined
+(MPC), as follows:
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+   :doc: mpc-overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+   :functions: mpcc_blnd_cfg
+
+Therefore, the blending configuration for a single MPCC instance on the MPC
+tree is defined by :c:type:`mpcc_blnd_cfg`, where
+:c:type:`pre_multiplied_alpha` is the alpha pre-multiplied mode flag used to
+set :c:type:`MPCC_ALPHA_MULTIPLIED_MODE`. It controls whether alpha is
+multiplied (true/false), being only true for DRM pre-multiplied blend mode.
+:c:type:`mpcc_alpha_blend_mode` defines the alpha blend mode regarding pixel
+alpha and plane alpha values. It sets one of the three modes for
+:c:type:`MPCC_ALPHA_BLND_MODE`, as described below.
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+   :functions: mpcc_alpha_blend_mode
+
+DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM
+blend formula, as follows:
+
+* *MPC pixel alpha* matches *DRM fg.alpha* as the alpha component value
+  from the plane's pixel
+* *MPC global alpha* matches *DRM plane_alpha* when the pixel alpha should
+  be ignored and, therefore, pixel values are not pre-multiplied
+* *MPC global gain* assumes *MPC global alpha* value when both *DRM
+  fg.alpha* and *DRM plane_alpha* participate in the blend equation
+
+In short, *fg.alpha* is ignored by selecting
+:c:type:`MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA`. On the other hand, (plane_alpha *
+fg.alpha) component becomes available by selecting
+:c:type:`MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN`. And the
+:c:type:`MPCC_ALPHA_MULTIPLIED_MODE` defines if the pixel color values are
+pre-multiplied by alpha or not.
+
+Blend configuration flow
+
+
+The alpha blending equation is configured from DRM to DC interface by the
+following path:
+
+1. When updat

Re: New subsystem for acceleration devices

[Jeffrey Hugo]

On 8/4/2022 6:00 AM, Tvrtko Ursulin wrote:


On 04/08/2022 00:54, Dave Airlie wrote:

On Thu, 4 Aug 2022 at 06:21, Oded Gabbay  wrote:


On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie  wrote:


On Sun, 31 Jul 2022 at 22:04, Oded Gabbay  
wrote:


Hi,
Greg and I talked a couple of months ago about preparing a new accel
subsystem for compute/acceleration devices that are not GPUs and I
think your drivers that you are now trying to upstream fit it as well.


We've had some submissions for not-GPUs to the drm subsystem recently.

Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit.

why is creating a new subsystem at this time necessary?

Are we just creating a subsystem to avoid the open source userspace
consumer rules? Or do we have some concrete reasoning behind it?

Dave.


Hi Dave.
The reason it happened now is because I saw two drivers, which are
doing h/w acceleration for AI, trying to be accepted to the misc
subsystem.
Add to that the fact I talked with Greg a couple of months ago about
doing a subsystem for any compute accelerators, which he was positive
about, I thought it is a good opportunity to finally do it.

I also honestly think that I can contribute much to these drivers from
my experience with the habana driver (which is now deployed in mass at
AWS) and contribute code from the habana driver to a common framework
for AI drivers.


Why not port the habana driver to drm now instead? I don't get why it
wouldn't make sense?

Stepping up to create a new subsystem is great, but we need rules
around what belongs where, we can't just spawn new subsystems when we
have no clear guidelines on where drivers should land.

What are the rules for a new accel subsystem? Do we have to now
retarget the 3 drivers that are queued up to use drm for accelerators,
because 2 drivers don't?


Isn't there three on the "don't prefer drm" side as well? Habana, 
Toshiba and Samsung? Just so the numbers argument is not misrepresented. 
Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't 
care in principle; is in order?


I'll chime in with my opinions.  Take them for what you will.

I would say I fall into the C category, but I'm targeting DRM and will 
be the 5th(?) accel device to do so.


I'll say that the ksummit (from what I see in the LWN article) made me 
very happy.  Finally, the community had clear rules for accel drivers. 
When I targeted misc in the past, it seemed like Greg moved the goal 
post just for me, which stalled our attempt.  It was even more 
frustrating to see that the high bar Greg set for us was not applied to 
other devices of the same "class" in following submissions.


However, the past is the past, and based on ksummit, we've spent a 
number of months retargeting DRM.  In a week (or two), I plan to post 
something to start up the discussions again.


As far as the DRM userspace requirements, unless we've misunderstood 
something, they've been easier to satisfy (pending review I suppose) 
than what misc has set.


I would say that Dave Airlie's feedback on this discussion resonates 
with me.  From the perspective of a vendor wanting to be a part of the 
community, clear rules are important and ksummit seemed to set that. 
Oded's announcement has thrown all of that into the wind.  Without a 
proposal to evaluate (eg show me the code with clear guidelines), I 
cannot seriously consider Oded's idea, and I'm not sure I want to sit by 
another few years to see it settle out.


I expect to move forward with what we were planning prior to seeing this 
thread which is targeting DRM.  We'll see what the DRM folks say when 
they have something to look at.  If our device doesn't fit in DRM per an 
assessment of the DRM folks, then I sure hope they can suggest where we 
do fit because then we'll have tried misc and DRM, and not found a home. 
 Since "drivers/accel" doesn't exist, and realistically won't for a 
long time if ever, I don't see why we should consider it.


Why DRM?  We consume dma_buf and might look to p2pdma in the future. 
ksummit appears clear - we are a DRM device.  Also, someone could 
probably run openCL on our device if they were so inclined to wire it 
up.  Over time, I've come to the thinking that we are a GPU, just 
without display.  Yes, it would have helped if DRM and/or drivers/gpu 
were renamed, but I think I'm past that point.  Once you have everything 
written, it doesn't seem like it matters if the uAPI device is called 
/dev/drmX, /dev/miscX, or /dev/magic.


I will not opine on other devices as I am no expert on them.  Today, my 
opinion is that DRM is the best place for me.  We'll see where that goes.


More to the point, code sharing is a very compelling argument if it can 
be demonstrated to be significant, aka not needing to reinvent the same 
wheel.


Perhaps one route forward could be a) to consider is to rename DRM to 
something more appropriate, removing rendering from the name and 
replacing with accelerators, co-processors, I don't know... Althoug

Re: [PATCH v3 26/32] drm/via: Add via_drm.h

[Sam Ravnborg]

Hi Kevin,

>  1) Get an un-accelerated driver merged without new uapi, ioctls, etc. All
> you need is there already. We already agreed to take the code mostly as-is
> and do the cleanups later on.
> 
>  2a) Stay around on dri-devel, send improvements and fixes for the merged
> code.
> 
>  2b) In parallel, you can work on video, 3d, etc in both kernel and
> userspace.

And on top of this the driver will see all the refactoring going on in
drm drivers all the time, and we may find cases where the driver can use
more of the drm helpers.

I really hope to see next revision where there is focus on the general
un-accelerated case and without the extras as Thomas mentions.

Sam

Re: [PATCH] Revert "drm/amdgpu: add drm buddy support to amdgpu"

[Mike Lothian]

Hi

When is this relanding?

Cheers

Mike

On Mon, 18 Jul 2022 at 21:40, Dixit, Ashutosh  wrote:
>
> On Thu, 14 Jul 2022 08:00:32 -0700, Christian König wrote:
> >
> > Am 14.07.22 um 15:33 schrieb Alex Deucher:
> > > On Thu, Jul 14, 2022 at 9:09 AM Christian König
> > >  wrote:
> > >> Hi Mauro,
> > >>
> > >> well the last time I checked drm-tip was clean.
> > >>
> > >> The revert is necessary because we had some problems with the commit
> > >> which we couldn't fix in the 5.19 cycle.
> > > Would it be worth reverting the revert and applying the actual fix[1]?
> > >   It's a huge revert unfortunately while the actual fix is like 10
> > > lines of code.  I'm concerned there will be subtle fallout from the
> > > revert due to how extensive it is.
> >
> > We have other bug fixes and cleanups around that patch which didn't made it
> > into 5.19 either. I don't want to create an ever greater mess.
> >
> > Real question is why building drm-tip work for me but not for others?
>
> Seeing this on latest drm-tip:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:54:1: error: redefinition of 
> ‘amdgpu_vram_mgr_first_block’
>54 | amdgpu_vram_mgr_first_block(struct list_head *list)
>   | ^~~
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h:29,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu.h:73,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:28:
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h:57:1: note: previous definition 
> of ‘amdgpu_vram_mgr_first_block’ with type ‘struct drm_buddy_block *(struct 
> list_head *)’
>57 | amdgpu_vram_mgr_first_block(struct list_head *list)
>   | ^~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:59:20: error: redefinition of 
> ‘amdgpu_is_vram_mgr_blocks_contiguous’
>59 | static inline bool amdgpu_is_vram_mgr_blocks_contiguous(struct 
> list_head *head)
>   |^~~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h:62:20: note: previous definition 
> of ‘amdgpu_is_vram_mgr_blocks_contiguous’ with type ‘bool(struct list_head 
> *)’ {aka ‘_Bool(struct list_head *)’}
>62 | static inline bool amdgpu_is_vram_mgr_blocks_contiguous(struct 
> list_head *head)
>   |^~~~
> make[4]: *** [scripts/Makefile.build:249: 
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[3]: *** [scripts/Makefile.build:466: drivers/gpu/drm/amd/amdgpu] Error 2
> make[2]: *** [scripts/Makefile.build:466: drivers/gpu/drm] Error 2
> make[1]: *** [scripts/Makefile.build:466: drivers/gpu] Error 2

Re: [PATCH] drm/vmwgfx: cleanup comments

[Zack Rusin]

On Sat, 2022-07-30 at 09:57 -0400, Tom Rix wrote:
> Remove second 'should'
> 
> Spelling replacements
> aqcuire -> acquire
> applcations -> applications
> assumings   -> assumes
> begining-> beginning
> commited-> committed
> contol  -> control
> inbetween   -> in between
> resorces-> resources
> succesful   -> successful
> successfule -> successful
> 
> Signed-off-by: Tom Rix 

Thanks, looks good. I pushed it through drm-misc-next.

z

Re: [v1] drm/msm/disp/dpu1: add support for hierarchical flush for dspp in sc7280

[Dmitry Baryshkov]

On Thu, 4 Aug 2022 at 13:29, Kalyan Thota  wrote:
>
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
>
> representation: master_flush && (PCC_flush | IGC_flush .. etc )
>
> This change adds necessary support for the above design.
>
> Signed-off-by: Kalyan Thota 

I'd like to land at least patches 6-8 from [1] next cycle. They clean
up the CTL interface. Could you please rebase your patch on top of
them?

[1] https://patchwork.freedesktop.org/series/99909/

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  4 +++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  5 +++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  2 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 40 
> +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  3 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|  7 +
>  6 files changed, 59 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 7763558..4eca317 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -703,6 +703,10 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc 
> *crtc)
> mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
> mixer[i].hw_dspp->idx);
>
> +   if(ctl->ops.set_dspp_hierarchical_flush)
> +   ctl->ops.set_dspp_hierarchical_flush(ctl,
> +   mixer[i].hw_dspp->idx, 
> DSPP_SUB_PCC);
> +
> /* stage config flush mask */
> ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 021eb2f..3b27a87 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -58,7 +58,10 @@
> (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
>
>  #define CTL_SC7280_MASK \
> -   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) | 
> BIT(DPU_CTL_VM_CFG))
> +   (BIT(DPU_CTL_ACTIVE_CFG) | \
> +BIT(DPU_CTL_FETCH_ACTIVE) | \
> +BIT(DPU_CTL_VM_CFG) | \
> +BIT(DPU_CTL_HIERARCHICAL_FLUSH))
>
>  #define MERGE_3D_SM8150_MASK (0)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index b85b24b..7922f6c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -185,6 +185,7 @@ enum {
>   * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
>   * @DPU_CTL_FETCH_ACTIVE:  Active CTL for fetch HW (SSPPs)
>   * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
> + * @DPU_CTL_HIERARCHICAL_FLUSH: CTL config to support hierarchical flush
>   * @DPU_CTL_MAX
>   */
>  enum {
> @@ -192,6 +193,7 @@ enum {
> DPU_CTL_ACTIVE_CFG,
> DPU_CTL_FETCH_ACTIVE,
> DPU_CTL_VM_CFG,
> +   DPU_CTL_HIERARCHICAL_FLUSH,
> DPU_CTL_MAX
>  };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 3584f5e..b34fc30 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -28,6 +28,8 @@
>  #define   CTL_INTF_FLUSH0x110
>  #define   CTL_INTF_MASTER   0x134
>  #define   CTL_FETCH_PIPE_ACTIVE 0x0FC
> +#define   CTL_DSPP_0_FLUSH 0x13C

Please change to CTL_DSPP_n_FLUSH(n).

> +
>
>  #define CTL_MIXER_BORDER_OUTBIT(24)
>  #define CTL_FLUSH_MASK_CTL  BIT(17)
> @@ -292,6 +294,36 @@ static uint32_t dpu_hw_ctl_get_bitmask_dspp(struct 
> dpu_hw_ctl *ctx,
> return flushbits;
>  }
>
> +static uint32_t dpu_hw_ctl_get_bitmask_dspp_v1(struct dpu_hw_ctl *ctx,
> +   enum dpu_dspp dspp)
> +{
> +   return BIT(29);
> +}
> +
> +static void dpu_hw_ctl_set_dspp_hierarchical_flush(struct dpu_hw_ctl *ctx,
> +   enum dpu_dspp dspp, enum dpu_dspp_sub_blk dspp_sub_blk)
> +{
> +   uint32_t flushbits = 0, active = 0;
> +
> +   switch (dspp_sub_blk) {
> +   case DSPP_SUB_IGC:
> +   flushbits = BIT(2);
> +   break;
> +   case DSPP_SUB_PCC:
> +   flushbits = BIT(4);
> +   break;
> +   case DSPP_SUB_GC:
> +   flushbits = BIT(5);
> +   break;
> +   default:
> +   return;
> +   }
> +
> +   active = DPU_REG_READ(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4));

So that this line will be simpler to read.

> +
> +   DPU_REG_WRITE(&ctx->hw, CTL_DSPP_0_FLUSH + ((dspp - 1) * 4), active | 
> flushbits);
> +}
> +
>  static u32 dpu_hw_ctl_poll_reset_status(struct dpu_hw_ctl *ctx, u32 
> time

Re: [PATCH v6 00/10] Add PSR support for eDP

[Robert Foss]

On Fri, 29 Jul 2022 at 02:22, Doug Anderson  wrote:
>
> Hi,
>
> On Mon, Jul 11, 2022 at 5:57 AM Vinod Polimera
>  wrote:
> >
> > Changes in v2:
> >   - Use dp bridge to set psr entry/exit instead of dpu_enocder.
> >   - Don't modify whitespaces.
> >   - Set self refresh aware from atomic_check.
> >   - Set self refresh aware only if psr is supported.
> >   - Provide a stub for msm_dp_display_set_psr.
> >   - Move dp functions to bridge code.
> >
> > Changes in v3:
> >   - Change callback names to reflect atomic interfaces.
> >   - Move bridge callback change to separate patch as suggested by Dmitry.
> >   - Remove psr function declaration from msm_drv.h.
> >   - Set self_refresh_aware flag only if psr is supported.
> >   - Modify the variable names to simpler form.
> >   - Define bit fields for PSR settings.
> >   - Add comments explaining the steps to enter/exit psr.
> >   - Change DRM_INFO to drm_dbg_db.
> >
> > Changes in v4:
> >   - Move the get crtc functions to drm_atomic.
> >   - Add atomic functions for DP bridge too.
> >   - Add ternary operator to choose eDP or DP ops.
> >   - Return true/false instead of 1/0.
> >   - mode_valid missing in the eDP bridge ops.
> >   - Move the functions to get crtc into drm_atomic.c.
> >   - Fix compilation issues.
> >   - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc.
> >   - Check for crtc state enable while reserving resources.
> >
> > Changes in v5:
> >   - Move the mode_valid changes into a different patch.
> >   - Complete psr_op_comp only when isr is set.
> >   - Move the DP atomic callback changes to a different patch.
> >   - Get crtc from drm connector state crtc.
> >   - Move to separate patch for check for crtc state enable while
> > reserving resources.
> >
> > Changes in v6:
> >   - Remove crtc from dpu_encoder_virt struct.
> >   - fix crtc check during vblank toggle crtc.
> >   - Misc changes.
> >
> > Signed-off-by: Sankeerth Billakanti 
> > Signed-off-by: Kalyan Thota 
> > Signed-off-by: Vinod Polimera 
> >
> > Vinod Polimera (10):
> >   drm/msm/disp/dpu: clear dpu_assign_crtc and get crtc from connector
> > state instead of dpu_enc
> >   drm: add helper functions to retrieve old and new crtc
> >   drm/msm/dp: use atomic callbacks for DP bridge ops
> >   drm/msm/dp: Add basic PSR support for eDP
> >   drm/msm/dp: use the eDP bridge ops to validate eDP modes
> >   drm/bridge: use atomic enable/disable callbacks for panel bridge
> >   drm/bridge: add psr support for panel bridge callbacks
> >   drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder
> > functions
> >   drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
> >   drm/msm/disp/dpu: check for crtc enable rather than crtc active to
> > release shared resources
> >
> >  drivers/gpu/drm/bridge/panel.c  |  68 --
> >  drivers/gpu/drm/drm_atomic.c|  60 +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  17 ++-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  56 +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |   8 --
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |   2 +-
> >  drivers/gpu/drm/msm/dp/dp_catalog.c |  81 
> >  drivers/gpu/drm/msm/dp/dp_catalog.h |   4 +
> >  drivers/gpu/drm/msm/dp/dp_ctrl.c|  73 +++
> >  drivers/gpu/drm/msm/dp/dp_ctrl.h|   3 +
> >  drivers/gpu/drm/msm/dp/dp_display.c |  31 +++--
> >  drivers/gpu/drm/msm/dp/dp_display.h |   2 +
> >  drivers/gpu/drm/msm/dp/dp_drm.c | 184 
> > ++--
> >  drivers/gpu/drm/msm/dp/dp_drm.h |   9 +-
> >  drivers/gpu/drm/msm/dp/dp_link.c|  36 ++
> >  drivers/gpu/drm/msm/dp/dp_panel.c   |  22 
> >  drivers/gpu/drm/msm/dp/dp_panel.h   |   6 +
> >  drivers/gpu/drm/msm/dp/dp_reg.h |  27 
> >  include/drm/drm_atomic.h|   7 ++
> >  19 files changed, 631 insertions(+), 65 deletions(-)
>

Which tree does this series apply to?

Re: [PATCH 01/12] drm/format-helper: Provide drm_fb_blit()

[Sam Ravnborg]

Hi Thomas,

On Wed, Jul 27, 2022 at 01:33:01PM +0200, Thomas Zimmermann wrote:
> Provide drm_fb_blit() that works with struct iosys_map. Update all
> users of drm_fb_blit_toio(), which required a destination buffer in
> I/O memory. The new function's interface works with multi-plane
> color formats, although the implementation only supports a single
> plane for now.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_format_helper.c | 39 ++---
>  drivers/gpu/drm/tiny/simpledrm.c| 18 +++--
>  include/drm/drm_format_helper.h |  7 +++---
>  3 files changed, 38 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index c6182b5de78b..4d74d46ab155 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -8,9 +8,10 @@
>   * (at your option) any later version.
>   */
>  
> +#include 
> +#include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> @@ -545,9 +546,9 @@ void drm_fb_xrgb_to_gray8(void *dst, unsigned int 
> dst_pitch, const void *vad
>  EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>  
>  /**
> - * drm_fb_blit_toio - Copy parts of a framebuffer to display memory
> - * @dst: The display memory to copy to
> - * @dst_pitch:   Number of bytes between two consecutive scanlines 
> within dst
> + * drm_fb_blit - Copy parts of a framebuffer to display memory
> + * @dst: Array of display-memory addresses to copy to
> + * @dst_pitch:   Array of numbers of bytes between two consecutive 
> scanlines within dst

The rename confused me since this function continue to operate only on
io memory, but I see that this is all fixed up in later patches.
It would be nice to have this mentioned in the changelog, just in case
someone else takes a deeper look at it.

With the changelog updated:
Reviewed-by: Sam Ravnborg 

See also comments below.

>   * @dst_format:  FOURCC code of the display's color format
>   * @vmap:The framebuffer memory to copy from
>   * @fb:  The framebuffer to copy from
> @@ -557,14 +558,18 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_gray8);
>   * formats of the display and the framebuffer mismatch, the blit function
>   * will attempt to convert between them.
>   *
> + * The parameters @dst, @dst_pitch and @vmap refer to arrays. Each array must
> + * have at least as many entries as there are planes in @dst_format's 
> format. Each
> + * entry stores the value for the format's respective color plane at the 
> same index.
> + *
>   * Returns:
>   * 0 on success, or
>   * -EINVAL if the color-format conversion failed, or
>   * a negative error code otherwise.
>   */
> -int drm_fb_blit_toio(void __iomem *dst, unsigned int dst_pitch, uint32_t 
> dst_format,
> -  const void *vmap, const struct drm_framebuffer *fb,
> -  const struct drm_rect *clip)
> +int drm_fb_blit(struct iosys_map *dst, const unsigned int *dst_pitch, 
> uint32_t dst_format,
> + const struct iosys_map *vmap, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip)
>  {
>   uint32_t fb_format = fb->format->format;
>  
> @@ -579,30 +584,35 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
> dst_pitch, uint32_t dst_for
>   dst_format = DRM_FORMAT_XRGB2101010;
>  
>   if (dst_format == fb_format) {
> - drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
> + drm_fb_memcpy_toio(dst[0].vaddr_iomem, dst_pitch[0], 
> vmap[0].vaddr, fb, clip);
>   return 0;
>  
>   } else if (dst_format == DRM_FORMAT_RGB565) {
>   if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb565_toio(dst, dst_pitch, vmap, 
> fb, clip, false);
> + drm_fb_xrgb_to_rgb565_toio(dst[0].vaddr_iomem, 
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip, 
> false);
>   return 0;
>   }
>   } else if (dst_format == DRM_FORMAT_RGB888) {
>   if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap, 
> fb, clip);
> + drm_fb_xrgb_to_rgb888_toio(dst[0].vaddr_iomem, 
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip);
>   return 0;
>   }
>   } else if (dst_format == DRM_FORMAT_XRGB) {
>   if (fb_format == DRM_FORMAT_RGB888) {
> - drm_fb_rgb888_to_xrgb_toio(dst, dst_pitch, vmap, 
> fb, clip);
> + drm_fb_rgb888_to_xrgb_toio(dst[0].vaddr_iomem, 
> dst_pitch[0],
> +vmap[0].vaddr, fb, clip);
>   return 0;
>   } else if (fb_format == DRM_FORMAT_RGB565) {
> - drm_fb_r

Re: mainline build failure due to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training support for PSP_V13")

[Linus Torvalds]

On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink)
 wrote:
>
> I will be happy to test any patch or provide any extra log if needed.

It sounds like that file just needs to get a

#include 

there, and for some reason architectures other than alpha and mips end
up getting it accidentally through other headers.

Mind testing just adding that header file, and perhaps even sending a
patch if (when) that works for you?

Linus

Re: [PATCH] drm/amd/display: restore plane with no modifiers code.

[Linus Torvalds]

On Wed, Aug 3, 2022 at 10:50 PM Dave Airlie  wrote:
>
> With this applied, I get gdm back.

I can confirm that it makes thing work again for me too. Applied.

 Linus

Re: [PATCH 1/2] drm/msm: Move hangcheck timer restart

[Rob Clark]

On Thu, Aug 4, 2022 at 12:53 AM Akhil P Oommen  wrote:
>
> On 8/4/2022 1:59 AM, Rob Clark wrote:
> > On Wed, Aug 3, 2022 at 12:52 PM Akhil P Oommen  
> > wrote:
> >> On 8/3/2022 10:53 PM, Rob Clark wrote:
> >>> From: Rob Clark 
> >>>
> >>> Don't directly restart the hangcheck timer from the timer handler, but
> >>> instead start it after the recover_worker replays remaining jobs.
> >>>
> >>> If the kthread is blocked for other reasons, there is no point to
> >>> immediately restart the timer.  Fixes a random symptom of the problem
> >>> fixed in the next patch.
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> ---
> >>>drivers/gpu/drm/msm/msm_gpu.c | 14 +-
> >>>1 file changed, 9 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> >>> index fba85f894314..8f9c48eabf7d 100644
> >>> --- a/drivers/gpu/drm/msm/msm_gpu.c
> >>> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> >>> @@ -328,6 +328,7 @@ find_submit(struct msm_ringbuffer *ring, uint32_t 
> >>> fence)
> >>>}
> >>>
> >>>static void retire_submits(struct msm_gpu *gpu);
> >>> +static void hangcheck_timer_reset(struct msm_gpu *gpu);
> >>>
> >>>static void get_comm_cmdline(struct msm_gem_submit *submit, char 
> >>> **comm, char **cmd)
> >>>{
> >>> @@ -420,6 +421,8 @@ static void recover_worker(struct kthread_work *work)
> >>>}
> >>>
> >>>if (msm_gpu_active(gpu)) {
> >>> + bool restart_hangcheck = false;
> >>> +
> >>>/* retire completed submits, plus the one that hung: */
> >>>retire_submits(gpu);
> >>>
> >>> @@ -436,10 +439,15 @@ static void recover_worker(struct kthread_work 
> >>> *work)
> >>>unsigned long flags;
> >>>
> >>>spin_lock_irqsave(&ring->submit_lock, flags);
> >>> - list_for_each_entry(submit, &ring->submits, node)
> >>> + list_for_each_entry(submit, &ring->submits, node) {
> >>>gpu->funcs->submit(gpu, submit);
> >>> + restart_hangcheck = true;
> >>> + }
> >>>spin_unlock_irqrestore(&ring->submit_lock, flags);
> >>>}
> >>> +
> >>> + if (restart_hangcheck)
> >>> + hangcheck_timer_reset(gpu);
> >>>}
> >>>
> >>>mutex_unlock(&gpu->lock);
> >>> @@ -515,10 +523,6 @@ static void hangcheck_handler(struct timer_list *t)
> >>>kthread_queue_work(gpu->worker, &gpu->recover_work);
> >>>}
> >>>
> >>> - /* if still more pending work, reset the hangcheck timer: */
> >> In the scenario mentioned here, shouldn't we restart the timer?
> > yeah, actually the case where we don't want to restart the timer is
> > *only* when we schedule recover_work..
> >
> > BR,
> > -R
> Not sure if your codebase is different but based on msm-next branch,
> when "if (fence != ring->hangcheck_fence)" is true, we now skip
> rescheduling the timer. I don't think that is what we want. There should
> be a hangcheck timer running as long as there is an active submit,
> unless we have scheduled a recover_work here.
>

right, v2 will change that to only skip rescheduling the timer in the
recover path

BR,
-R

> -Akhil.
> >
> >> -Akhil.
> >>> - if (fence_after(ring->fctx->last_fence, ring->hangcheck_fence))
> >>> - hangcheck_timer_reset(gpu);
> >>> -
> >>>/* workaround for missing irq: */
> >>>msm_gpu_retire(gpu);
> >>>}
> >>>
>

[PULL] drm-intel-next-fixes

[Rodrigo Vivi]

Hi Dave and Daniel,

Here goes drm-intel-next-fixes-2022-08-04:

- disable pci resize on 32-bit systems (Nirmoy)
- don't leak the ccs state (Matt)
- TLB invalidation fixes (Chris)

Thanks,
Rodrigo.

The following changes since commit 2bc7ea71a73747a77e7f83bc085b0d2393235410:

  Merge tag 'topic/nouveau-misc-2022-07-27' of 
git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2022-08-04

for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71:

  drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400)


- disable pci resize on 32-bit systems (Nirmoy)
- don't leak the ccs state (Matt)
- TLB invalidation fixes (Chris)


Chris Wilson (4):
  drm/i915/gt: Ignore TLB invalidations on idle engines
  drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations
  drm/i915/gt: Skip TLB invalidations once wedged
  drm/i915/gt: Batch TLB invalidations

Matthew Auld (1):
  drm/i915/ttm: don't leak the ccs state

Nirmoy Das (1):
  drm/i915: disable pci resize on 32-bit machine

 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c| 25 +---
 drivers/gpu/drm/i915/gt/intel_gt.c   | 77 ++--
 drivers/gpu/drm/i915/gt/intel_gt.h   | 12 +++-
 drivers/gpu/drm/i915/gt/intel_gt_pm.h|  3 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h | 18 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 23 ++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c|  8 ++-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c  |  4 ++
 drivers/gpu/drm/i915/i915_vma.c  | 33 +++---
 drivers/gpu/drm/i915/i915_vma.h  |  1 +
 drivers/gpu/drm/i915/i915_vma_resource.c |  5 +-
 drivers/gpu/drm/i915/i915_vma_resource.h |  6 +-
 13 files changed, 177 insertions(+), 41 deletions(-)

Re: New subsystem for acceleration devices

[Oded Gabbay]

On Thu, Aug 4, 2022 at 5:50 PM Jason Gunthorpe  wrote:
>
> On Thu, Aug 04, 2022 at 10:43:42AM +0300, Oded Gabbay wrote:
>
> > After all, memory management services, or common device chars handling
> > I can get from other subsystems (e.g. rdma) as well. I'm sure I could
> > model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI
> > there as well), but this doesn't mean I belong there, right ?
>
> You sure can, but there is still an expectation, eg in RDMA, that your
> device has a similarity to the established standards (like roce in
> habana's case) that RDMA is geared to support.
>
> I think the the most important thing to establish a new subsystem is
> to actually identify what commonalities it is supposed to be
> providing. Usually this is driven by some standards body, but the
> AI/ML space hasn't gone in that direction at all yet.
I agree. In the AI-world the standard doesn't exist and I don't see
anything on the horizon. There are the AI frameworks/compilers which
are 30,000 feet above us, and there is CUDA which is closed-source and
I have no idea what it does inside.
>
> We don't need a "subsystem" to have a bunch of drivers expose chardevs
> with completely unique ioctls.
I totally agree with this sentence and this is *exactly* why
personally I don't want to use DRM because when I look at the long
list of common IOCTLs in drm.h, I don't find anything that I can use.
It's simply either not relevant at all to my h/w or it is something
that our h/w implemented differently.

This is in contrast to the rdma, where as you said, we have ibverbs
API. So, when you asked that we write an IBverbs driver I understood
the reasoning. There is a common user-space library which talks to the
rdma drivers and all the rdma applications use that library and once I
will write a (somewhat) standard driver, then hopefully I can enjoy
all that.

>
> The flip is true of DRM - DRM is pretty general. I bet I could
> implement an RDMA device under DRM - but that doesn't mean it should
> be done.
>
> My biggest concern is that this subsystem not turn into a back door
> for a bunch of abuse of kernel APIs going forward. Though things are
How do you suggest to make sure it won't happen ?

> better now, we still see this in DRM where expediency or performance
> justifies hacky shortcuts instead of good in-kernel architecture. At
> least DRM has reliable and experienced review these days.
Definitely. DRM has some parts that are really well written. For
example, the whole char device handling with sysfs/debugfs and managed
resources code. This is something I would gladly either use or
copy-paste into the hw accel subsystem.
And of course more pairs of eyes looking at the code will usually
produce better code.

I think that it is clear from my previous email what I intended to
provide. A clean, simple framework for devices to register with, get
services for the most basic stuff such as device char handling,
sysfs/debugfs. Later on, add more simple stuff such as memory manager
and uapi for memory handling. I guess someone can say all that exists
in drm, but like I said it exists in other subsystems as well.

I want to be perfectly honest and say there is nothing special here
for AI. It's actually the opposite, it is a generic framework for
compute only. Think of it as an easier path to upstream if you just
want to do compute acceleration. Maybe in the future it will be more,
but I can't predict the future.

If that's not enough for a new subsystem, fair enough, I'll withdraw my offer.

Thanks,
Oded

>
> Jason

Re: [PATCH v6 00/10] Add PSR support for eDP

[Doug Anderson]

Hi,

On Thu, Aug 4, 2022 at 9:21 AM Robert Foss  wrote:
>
> On Fri, 29 Jul 2022 at 02:22, Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Mon, Jul 11, 2022 at 5:57 AM Vinod Polimera
> >  wrote:
> > >
> > > Changes in v2:
> > >   - Use dp bridge to set psr entry/exit instead of dpu_enocder.
> > >   - Don't modify whitespaces.
> > >   - Set self refresh aware from atomic_check.
> > >   - Set self refresh aware only if psr is supported.
> > >   - Provide a stub for msm_dp_display_set_psr.
> > >   - Move dp functions to bridge code.
> > >
> > > Changes in v3:
> > >   - Change callback names to reflect atomic interfaces.
> > >   - Move bridge callback change to separate patch as suggested by Dmitry.
> > >   - Remove psr function declaration from msm_drv.h.
> > >   - Set self_refresh_aware flag only if psr is supported.
> > >   - Modify the variable names to simpler form.
> > >   - Define bit fields for PSR settings.
> > >   - Add comments explaining the steps to enter/exit psr.
> > >   - Change DRM_INFO to drm_dbg_db.
> > >
> > > Changes in v4:
> > >   - Move the get crtc functions to drm_atomic.
> > >   - Add atomic functions for DP bridge too.
> > >   - Add ternary operator to choose eDP or DP ops.
> > >   - Return true/false instead of 1/0.
> > >   - mode_valid missing in the eDP bridge ops.
> > >   - Move the functions to get crtc into drm_atomic.c.
> > >   - Fix compilation issues.
> > >   - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc.
> > >   - Check for crtc state enable while reserving resources.
> > >
> > > Changes in v5:
> > >   - Move the mode_valid changes into a different patch.
> > >   - Complete psr_op_comp only when isr is set.
> > >   - Move the DP atomic callback changes to a different patch.
> > >   - Get crtc from drm connector state crtc.
> > >   - Move to separate patch for check for crtc state enable while
> > > reserving resources.
> > >
> > > Changes in v6:
> > >   - Remove crtc from dpu_encoder_virt struct.
> > >   - fix crtc check during vblank toggle crtc.
> > >   - Misc changes.
> > >
> > > Signed-off-by: Sankeerth Billakanti 
> > > Signed-off-by: Kalyan Thota 
> > > Signed-off-by: Vinod Polimera 
> > >
> > > Vinod Polimera (10):
> > >   drm/msm/disp/dpu: clear dpu_assign_crtc and get crtc from connector
> > > state instead of dpu_enc
> > >   drm: add helper functions to retrieve old and new crtc
> > >   drm/msm/dp: use atomic callbacks for DP bridge ops
> > >   drm/msm/dp: Add basic PSR support for eDP
> > >   drm/msm/dp: use the eDP bridge ops to validate eDP modes
> > >   drm/bridge: use atomic enable/disable callbacks for panel bridge
> > >   drm/bridge: add psr support for panel bridge callbacks
> > >   drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder
> > > functions
> > >   drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
> > >   drm/msm/disp/dpu: check for crtc enable rather than crtc active to
> > > release shared resources
> > >
> > >  drivers/gpu/drm/bridge/panel.c  |  68 --
> > >  drivers/gpu/drm/drm_atomic.c|  60 +
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  17 ++-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  56 +
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |   8 --
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |   2 +-
> > >  drivers/gpu/drm/msm/dp/dp_catalog.c |  81 
> > >  drivers/gpu/drm/msm/dp/dp_catalog.h |   4 +
> > >  drivers/gpu/drm/msm/dp/dp_ctrl.c|  73 +++
> > >  drivers/gpu/drm/msm/dp/dp_ctrl.h|   3 +
> > >  drivers/gpu/drm/msm/dp/dp_display.c |  31 +++--
> > >  drivers/gpu/drm/msm/dp/dp_display.h |   2 +
> > >  drivers/gpu/drm/msm/dp/dp_drm.c | 184 
> > > ++--
> > >  drivers/gpu/drm/msm/dp/dp_drm.h |   9 +-
> > >  drivers/gpu/drm/msm/dp/dp_link.c|  36 ++
> > >  drivers/gpu/drm/msm/dp/dp_panel.c   |  22 
> > >  drivers/gpu/drm/msm/dp/dp_panel.h   |   6 +
> > >  drivers/gpu/drm/msm/dp/dp_reg.h |  27 
> > >  include/drm/drm_atomic.h|   7 ++
> > >  19 files changed, 631 insertions(+), 65 deletions(-)
> >
>
> Which tree does this series apply to?

It ought to apply to msm-next, but as I mentioned in my reply to patch
#1 it doesn't apply to the top of msm-next. I think I also had to
manually apply a few of the later patches with "patch -p1".

-Doug

[PATCH] drm/amd/amdgpu: fix build failure due to implicit declaration

[Sudip Mukherjee]

The builds for alpha and mips allmodconfig fails with the error:

drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:23:
  error: implicit declaration of function 'vmalloc'; did you mean
  'kvmalloc'? [-Werror=implicit-function-declaration]

drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:21:
  error: assignment to 'void *' from 'int' makes pointer from integer
  without a cast [-Werror=int-conversion]

drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:545:33: error: implicit declaration
  of function 'vfree'; did you mean 'kvfree'?
  [-Werror=implicit-function-declaration]

Add the header file for vmalloc and vfree.

Reported-by: Sudip Mukherjee 
Suggested-by: Linus Torvalds 
Signed-off-by: Sudip Mukherjee 
---
 drivers/gpu/drm/amd/amdgpu/psp_v13_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c 
b/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c
index 63b2d32545cc..726a5bba40b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_psp.h"
 #include "amdgpu_ucode.h"
-- 
2.30.2

Re: mainline build failure due to 6fdd2077ec03 ("drm/amd/amdgpu: add memory training support for PSP_V13")

[Sudip Mukherjee]

On Thu, Aug 4, 2022 at 6:17 PM Linus Torvalds
 wrote:
>
> On Thu, Aug 4, 2022 at 12:35 AM Sudip Mukherjee (Codethink)
>  wrote:
> >
> > I will be happy to test any patch or provide any extra log if needed.
>
> It sounds like that file just needs to get a
>
> #include 
>
> there, and for some reason architectures other than alpha and mips end
> up getting it accidentally through other headers.
>
> Mind testing just adding that header file, and perhaps even sending a
> patch if (when) that works for you?

Tested on alpha allmodconfig, that worked.
And also sent the patch.


--
Regards
Sudip

mainline build failure for x86_64 allmodconfig with clang

[Sudip Mukherjee (Codethink)]

Hi All,

The latest mainline kernel branch fails to build for x86_64 allmodconfig
with clang. The errors are:

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
 error: stack frame size (2216) exceeds limit (2048) in 
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib 
*mode_lib)

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6:
 error: stack frame size (2184) exceeds limit (2048) in 
'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib 
*mode_lib)

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1726:6:
 error: stack frame size (2176) exceeds limit (2048) in 
'dml32_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml32_ModeSupportAndSystemConfigurationFull(struct display_mode_lib 
*mode_lib)

git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new 
display engine with KCOV enabled").

My last good build for clang was with e2b542100719 ("Merge tag 
'flexible-array-transformations-UAPI-6.0-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux").

I will be happy to test any patch or provide any extra log if needed.


--
Regards
Sudip

Re: mainline build failure for x86_64 allmodconfig with clang

[Linus Torvalds]

On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
 wrote:
>
> git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new 
> display engine with KCOV enabled").

Ahh. So that was presumably why it was disabled before - because it
presumably does disgusting things that make KCOV generate even bigger
stack frames than it already has.

Those functions do seem to have fairly big stack footprints already (I
didn't try to look into why, I assume it's partly due to aggressive
inlining, and probably some automatic structures on stack). But gcc
doesn't seem to make it all that much worse with KCOV (and my clang
build doesn't enable KCOV).

So it's presumably some KCOV-vs-clang thing. Nathan?

  Linus

Re: [Intel-gfx] [PATCH] drm: Fix typo 'the the' in comment

[Summers, Stuart]

On Thu, 2022-07-21 at 14:23 +0800, Slark Xiao wrote:
> Replace 'the the' with 'the' in the comment.
> 
> Signed-off-by: Slark Xiao 

Reviewed-by: Stuart Summers 

> ---
>  drivers/gpu/drm/display/drm_dp_helper.c   | 2 +-
>  drivers/gpu/drm/i915/i915_irq.c   | 2 +-
>  drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e5bab236b3ae..32b295003f49 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const
> struct drm_dp_aux_msg *msg)
>  
>  /*
>   * Calculate the length of the i2c transfer in usec, assuming
> - * the i2c bus speed is as specified. Gives the the "worst"
> + * the i2c bus speed is as specified. Gives the "worst"
>   * case estimate, ie. successful while as long as possible.
>   * Doesn't account the "MOT" bit, and instead assumes each
>   * message includes a START, ADDRESS and STOP. Neither does it
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 73cebc6aa650..783a6ca41a61 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -65,7 +65,7 @@
>  
>  /*
>   * Interrupt statistic for PMU. Increments the counter only if the
> - * interrupt originated from the the GPU so interrupts from a device
> which
> + * interrupt originated from the GPU so interrupts from a device
> which
>   * shares the interrupt line are not accounted.
>   */
>  static inline void pmu_irq_stats(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> index 40ea41b0a5dd..4085822f619a 100644
> --- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> @@ -231,7 +231,7 @@ struct nt35510_config {
>* bits 0..2 in the lower nibble controls HCK, the booster
> clock
>* frequency, the values are the same as for PCK in @bt1ctr.
>* bits 4..5 in the upper nibble controls BTH, the boosting
> -  * amplification for the the step-up circuit.
> +  * amplification for the step-up circuit.
>* 0 = AVDD + VDDB
>* 1 = AVDD - AVEE
>* 2 = AVDD - AVEE + VDDB

Re: [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions

[Randy Dunlap]

Hi Mauro,

On 8/4/22 00:37, Mauro Carvalho Chehab wrote:
> Add a description for the TLB cache invalidation algorithm and for
> the related kAPI functions.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v3 0/3] at: 
> https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
> 
>  Documentation/gpu/i915.rst  |  7 ++
>  drivers/gpu/drm/i915/gt/intel_tlb.c | 25 
>  drivers/gpu/drm/i915/gt/intel_tlb.h | 99 +
>  3 files changed, 131 insertions(+)
> 

> diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
> b/drivers/gpu/drm/i915/gt/intel_tlb.c
> index af8cae979489..16b918ffe824 100644
> --- a/drivers/gpu/drm/i915/gt/intel_tlb.c
> +++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
> @@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
>   intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
>  }
>  
> +/**
> + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> + * @gt: GT structure

In multiple places (here and below) it would be nice to know what a
GT structure is. I looked thru multiple C and header files yesterday
and didn't find any comments about it.

Just saying that @gt is a GT structure isn't very helpful, other
than making kernel-doc shut up.

> + * @seqno: sequence number
> + *
> + * Do a full TLB cache invalidation if the @seqno is bigger than the last
> + * full TLB cache invalidation.
> + *
> + * Note:
> + * The TLB cache invalidation logic depends on GEN-specific registers.
> + * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
> + */
>  void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
>  {
>   intel_wakeref_t wakeref;
> @@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
> u32 seqno)
>   }
>  }
>  
> +/**
> + * intel_gt_init_tlb - initialize TLB-specific vars
> + * @gt: GT structure
> + *
> + * TLB cache invalidation logic internally uses some resources that require
> + * initialization. Should be called before doing any TLB cache invalidation.
> + */
>  void intel_gt_init_tlb(struct intel_gt *gt)
>  {
>   mutex_init(>->tlb.invalidate_lock);
>   seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
>  }
>  
> +/**
> + * intel_gt_fini_tlb - free TLB-specific vars
> + * @gt: GT structure
> + *
> + * Frees any resources needed by TLB cache invalidation logic.
> + */
>  void intel_gt_fini_tlb(struct intel_gt *gt)
>  {
>   mutex_destroy(>->tlb.invalidate_lock);
> diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h 
> b/drivers/gpu/drm/i915/gt/intel_tlb.h
> index 46ce25bf5afe..2838c051f872 100644
> --- a/drivers/gpu/drm/i915/gt/intel_tlb.h
> +++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
> @@ -11,16 +11,115 @@
>  
>  #include "intel_gt_types.h"
>  
> +/**
> + * DOC: TLB cache invalidation logic
> + *
...
> +
>  void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno);
>  
>  void intel_gt_init_tlb(struct intel_gt *gt);
>  void intel_gt_fini_tlb(struct intel_gt *gt);
>  
> +/**
> + * intel_gt_tlb_seqno - Returns the current TLB invlidation sequence number
> + * @gt: GT structure
> + *
> + * There's no need to lock while calling it, as seqprop_sequence is 
> thread-safe
> + */
>  static inline u32 intel_gt_tlb_seqno(const struct intel_gt *gt)
>  {
>   return seqprop_sequence(>->tlb.seqno);
>  }
>  
> +/**
> + * intel_gt_next_invalidate_tlb_full - Returns the next TLB full invalidation
> + *   sequence number
> + * @gt: GT structure
> + *
> + * There's no need to lock while calling it, as seqprop_sequence is 
> thread-safe
> + */
>  static inline u32 intel_gt_next_invalidate_tlb_full(const struct intel_gt 
> *gt)
>  {
>   return intel_gt_tlb_seqno(gt) | 1;

thanks.

-- 
~Randy

Re: [PATCH 2/2] drm/cmdline-parser: Use assert when needed

[kernel test robot]

Hi "Michał,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next 
drm-intel/for-linux-next linus/master v5.19 next-20220803]
[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#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: hexagon-randconfig-r001-20220804 
(https://download.01.org/0day-ci/archive/20220805/202208050217.vhlt1udz-...@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 
26dd42705c2af0b8f6e5d6cdb32c9bd5ed9524eb)
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/intel-lab-lkp/linux/commit/8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
git checkout 8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/tests/

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:72:13: warning: stack frame 
>> size (1152) exceeds limit (1024) in 'drm_cmdline_test_force_D_only_dvi' 
>> [-Wframe-larger-than]
   static void drm_cmdline_test_force_D_only_dvi(struct kunit *test)
   ^
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:51:13: warning: stack frame 
>> size (1152) exceeds limit (1024) in 'drm_cmdline_test_force_D_only_hdmi' 
>> [-Wframe-larger-than]
   static void drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
   ^
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:389:13: warning: stack frame 
>> size (1152) exceeds limit (1024) in 
>> 'drm_cmdline_test_res_bpp_refresh_force_on_digital' [-Wframe-larger-than]
   static void drm_cmdline_test_res_bpp_refresh_force_on_digital(struct kunit 
*test)
   ^
   3 warnings generated.


vim +/drm_cmdline_test_force_D_only_dvi +72 
drivers/gpu/drm/tests/drm_cmdline_parser_test.c

9f0527d22a52ff34 Maíra Canal  2022-07-08  49  
9f0527d22a52ff34 Maíra Canal  2022-07-08  50  
9f0527d22a52ff34 Maíra Canal  2022-07-08 @51  static void 
drm_cmdline_test_force_D_only_hdmi(struct kunit *test)
9f0527d22a52ff34 Maíra Canal  2022-07-08  52  {
9f0527d22a52ff34 Maíra Canal  2022-07-08  53struct drm_cmdline_mode 
mode = { };
8a21a5872b4bbe7b Michał Winiarski 2022-08-04  54const struct 
drm_connector connector_hdmi = {
8a21a5872b4bbe7b Michał Winiarski 2022-08-04  55.connector_type 
= DRM_MODE_CONNECTOR_HDMIB,
8a21a5872b4bbe7b Michał Winiarski 2022-08-04  56};
9f0527d22a52ff34 Maíra Canal  2022-07-08  57const char *cmdline = 
"D";
9f0527d22a52ff34 Maíra Canal  2022-07-08  58  
8a21a5872b4bbe7b Michał Winiarski 2022-08-04  59KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
9f0527d22a52ff34 Maíra Canal  2022-07-08  60
  &connector_hdmi, &mode));
9f0527d22a52ff34 Maíra Canal  2022-07-08  61
KUNIT_EXPECT_FALSE(test, mode.specified);
9f0527d22a52ff34 Maíra Canal  2022-07-08  62
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
9f0527d22a52ff34 Maíra Canal  2022-07-08  63
KUNIT_EXPECT_FALSE(test, mode.bpp_specified);
9f0527d22a52ff34 Maíra Canal  2022-07-08  64  
9f0527d22a52ff34 Maíra Canal  2022-07-08  65
KUNIT_EXPECT_FALSE(test, mode.rb);
9f0527d22a52ff34 Maíra Canal  2022-07-08  66
KUNIT_EXPECT_FALSE(test, mode.cvt);
9f0527d22a52ff34 Maíra Canal  2022-07-08  67
KUNIT_EXPECT_FALSE(test, mode.interlace);
9f0527d22a52ff34 Maíra Canal  2022-07-08  68
KUNIT_EXPECT_FALSE(test, mode.margins);
9f0527d22a52ff34 Maíra Canal  2022-07-08  69KUNIT_EXPECT_EQ(test, 
mode.force, DRM_FORCE_ON_DIGITAL);
9f0527d22a52ff34 Maíra Canal  2022-07-08  70  }
9f0527d22a52ff34 Maíra Canal  2022-07-08  71  
9f0527d22a52ff34 Maíra Canal  2022-07-08 @72  static void 
drm_cmdline_test

Re: mainline build failure for x86_64 allmodconfig with clang

[Arnd Bergmann]

On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
 wrote:
>
> On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
>  wrote:cov_trace_cmp
> >
> > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new 
> > display engine with KCOV enabled").
>
> Ahh. So that was presumably why it was disabled before - because it
> presumably does disgusting things that make KCOV generate even bigger
> stack frames than it already has.
>
> Those functions do seem to have fairly big stack footprints already (I
> didn't try to look into why, I assume it's partly due to aggressive
> inlining, and probably some automatic structures on stack). But gcc
> doesn't seem to make it all that much worse with KCOV (and my clang
> build doesn't enable KCOV).
>
> So it's presumably some KCOV-vs-clang thing. Nathan?

The dependency was originally added to avoid a link failure in 9d1d02ff3678
 ("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported the
problem in 
https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html

The commit from the bisection just turns off KCOV for the entire directory
to avoid the link failure, so it's not actually a problem with KCOV vs clang,
but I think a problem with clang vs badly written code that was obscured
in allmodconfig builds prior to this.

The dml30_ModeSupportAndSystemConfigurationFull() function exercises
a few paths in the compiler that are otherwise rare. On thing it does is to
pass up to 60 arguments to other functions, and it heavily uses float and
double variables. Both of these make it rather fragile when it comes to
unusual compiler options, so the files keep coming up whenever a new
instrumentation feature gets added. There is probably some other flag
in allmodconfig that we can disable to improve this again, but I have not
checked this time.

Arnd

Re: [PATCH 2/2] drm/cmdline-parser: Use assert when needed

[kernel test robot]

Hi "Michał,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to drm/drm-next drm-exynos/exynos-drm-next 
drm-intel/for-linux-next linus/master v5.19 next-20220804]
[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#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: csky-buildonly-randconfig-r001-20220804 
(https://download.01.org/0day-ci/archive/20220805/202208050307.u6yo3hhr-...@intel.com/config)
compiler: csky-linux-gcc (GCC) 12.1.0
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/intel-lab-lkp/linux/commit/8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Micha-Winiarski/drm-cmdline-parser-Merge-negative-tests/20220804-212019
git checkout 8a21a5872b4bbe7bcfec5bc990d182a5c32416a2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=csky SHELL=/bin/bash drivers/gpu/drm/tests/

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

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/tests/drm_cmdline_parser_test.c: In function 
'drm_cmdline_test_res_bpp_refresh_force_on_digital':
>> drivers/gpu/drm/tests/drm_cmdline_parser_test.c:414:1: warning: the frame 
>> size of 1120 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 414 | }
 | ^
   drivers/gpu/drm/tests/drm_cmdline_parser_test.c: In function 
'drm_cmdline_test_force_D_only_hdmi':
   drivers/gpu/drm/tests/drm_cmdline_parser_test.c:70:1: warning: the frame 
size of 1120 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  70 | }
 | ^
   drivers/gpu/drm/tests/drm_cmdline_parser_test.c: In function 
'drm_cmdline_test_force_D_only_dvi':
   drivers/gpu/drm/tests/drm_cmdline_parser_test.c:91:1: warning: the frame 
size of 1124 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  91 | }
 | ^


vim +414 drivers/gpu/drm/tests/drm_cmdline_parser_test.c

9f0527d22a52ff Maíra Canal  2022-07-08  388  
9f0527d22a52ff Maíra Canal  2022-07-08  389  static void 
drm_cmdline_test_res_bpp_refresh_force_on_digital(struct kunit *test)
9f0527d22a52ff Maíra Canal  2022-07-08  390  {
9f0527d22a52ff Maíra Canal  2022-07-08  391 struct drm_cmdline_mode 
mode = { };
8a21a5872b4bbe Michał Winiarski 2022-08-04  392 const struct 
drm_connector connector = {
9f0527d22a52ff Maíra Canal  2022-07-08  393 .connector_type 
= DRM_MODE_CONNECTOR_DVII,
9f0527d22a52ff Maíra Canal  2022-07-08  394 };
9f0527d22a52ff Maíra Canal  2022-07-08  395 const char *cmdline = 
"720x480-24@60D";
9f0527d22a52ff Maíra Canal  2022-07-08  396  
8a21a5872b4bbe Michał Winiarski 2022-08-04  397 KUNIT_ASSERT_TRUE(test, 
drm_mode_parse_command_line_for_connector(cmdline,
9f0527d22a52ff Maíra Canal  2022-07-08  398 
  &connector, &mode));
9f0527d22a52ff Maíra Canal  2022-07-08  399 KUNIT_EXPECT_TRUE(test, 
mode.specified);
9f0527d22a52ff Maíra Canal  2022-07-08  400 KUNIT_EXPECT_EQ(test, 
mode.xres, 720);
9f0527d22a52ff Maíra Canal  2022-07-08  401 KUNIT_EXPECT_EQ(test, 
mode.yres, 480);
9f0527d22a52ff Maíra Canal  2022-07-08  402  
9f0527d22a52ff Maíra Canal  2022-07-08  403 KUNIT_EXPECT_TRUE(test, 
mode.refresh_specified);
9f0527d22a52ff Maíra Canal  2022-07-08  404 KUNIT_EXPECT_EQ(test, 
mode.refresh, 60);
9f0527d22a52ff Maíra Canal  2022-07-08  405  
9f0527d22a52ff Maíra Canal  2022-07-08  406 KUNIT_EXPECT_TRUE(test, 
mode.bpp_specified);
9f0527d22a52ff Maíra Canal  2022-07-08  407 KUNIT_EXPECT_EQ(test, 
mode.bpp, 24);
9f0527d22a52ff Maíra Canal  2022-07-08  408  
9f0527d22a52ff Maíra Canal  2022-07-08  409 
KUNIT_EXPECT_FALSE(test, mode.rb);
9f0527d22a52ff Maíra Canal  2022-07-08  410 
KUNIT_EXPECT_FALSE(test, mode.cvt);
9f0527d22a52ff Maíra Canal  2022-07-08  411 
KUNIT_EXPECT_FALSE(test, mode.interlace);
9f0527d22a52ff Maíra Canal  2022-07-08  412 
KUNIT_EXPECT_FALSE(test, mode.margins);

[PATCH] drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()

[Nícolas F . R . A . Prado]

As the comment right before the mtk_dsi_stop() call advises,
mtk_dsi_stop() should only be called after
mtk_drm_crtc_atomic_disable(). That's because that function calls
drm_crtc_wait_one_vblank(), which requires the vblank irq to be enabled.

Previously mtk_dsi_stop(), being in mtk_dsi_poweroff() and guarded by a
refcount, would only be called at the end of
mtk_drm_crtc_atomic_disable(), through the call to mtk_crtc_ddp_hw_fini().
Commit cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from
enable/disable and define new funcs") moved the mtk_dsi_stop() call to
mtk_output_dsi_disable(), causing it to be called before
mtk_drm_crtc_atomic_disable(), and consequently generating vblank
timeout warnings during suspend.

Move the mtk_dsi_stop() call back to mtk_dsi_poweroff() so that we have
a working vblank irq during mtk_drm_crtc_atomic_disable() and stop
getting vblank timeout warnings.

Fixes: cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from 
enable/disable and define new funcs")
Signed-off-by: Nícolas F. R. A. Prado 

---

 drivers/gpu/drm/mediatek/mtk_dsi.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 9cc406e1eee1..f8ad59771551 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -685,6 +685,16 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
if (--dsi->refcount != 0)
return;
 
+   /*
+* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
+* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
+* which needs irq for vblank, and mtk_dsi_stop() will disable irq.
+* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
+* after dsi is fully set.
+*/
+   mtk_dsi_stop(dsi);
+
+   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -735,17 +745,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
 
-   /*
-* mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
-* mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
-* which needs irq for vblank, and mtk_dsi_stop() will disable irq.
-* mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
-* after dsi is fully set.
-*/
-   mtk_dsi_stop(dsi);
-
-   mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
-
dsi->enabled = false;
 }
 
-- 
2.37.1

Re: [PATCH 02/12] drm/format-helper: Merge drm_fb_memcpy() and drm_fb_memcpy_toio()

[Sam Ravnborg]

Hi Thomas,

On Wed, Jul 27, 2022 at 01:33:02PM +0200, Thomas Zimmermann wrote:
> Merge drm_fb_memcpy() and drm_fb_memcpy() into drm_fb_memcpy() that
One of these is drm_fb_memcpy_toio()
> uses struct iosys_map for buffers. The new function also supports
> multi-plane color formats. Convert all users of the original helpers.

A few comments in the patch below.

Sam

> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_format_helper.c | 77 +
>  drivers/gpu/drm/drm_mipi_dbi.c  |  3 +-
>  drivers/gpu/drm/gud/gud_pipe.c  |  4 +-
>  drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 11 +--
>  drivers/gpu/drm/mgag200/mgag200_mode.c  | 11 +--
>  drivers/gpu/drm/tiny/cirrus.c   | 21 +++---
>  include/drm/drm_format_helper.h |  7 +-
>  7 files changed, 63 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index 4d74d46ab155..49589b442f18 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -131,63 +131,48 @@ static int drm_fb_xfrm_toio(void __iomem *dst, unsigned 
> long dst_pitch, unsigned
>  
>  /**
>   * drm_fb_memcpy - Copy clip buffer
> - * @dst: Destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: Source buffer
> + * @dst: Array of destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines 
> within dst
Document that this may be NULL, in which case the distance is considered
0.

> + * @vmap: Array of source buffers
It would have helped my understanding if this argument was named src,
so it is a little more obvious that we copy from src to dst.
Maybe document that data is copied from src based on the pitch info in
the framebuffer, and likewise the format_info in the framebuffer.

>   * @fb: DRM framebuffer
>   * @clip: Clip rectangle area to copy
>   *
>   * This function does not apply clipping on dst, i.e. the destination
>   * is at the top-left corner.
>   */
> -void drm_fb_memcpy(void *dst, unsigned int dst_pitch, const void *vaddr,
> -const struct drm_framebuffer *fb, const struct drm_rect 
> *clip)
> +void drm_fb_memcpy(struct iosys_map *dst, const unsigned int *dst_pitch,
> +const struct iosys_map *vmap, const struct drm_framebuffer 
> *fb,
> +const struct drm_rect *clip)
>  {
> - unsigned int cpp = fb->format->cpp[0];
> - size_t len = (clip->x2 - clip->x1) * cpp;
> - unsigned int y, lines = clip->y2 - clip->y1;
> -
> - if (!dst_pitch)
> - dst_pitch = len;
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
This is used in several places in this series. What I read is that a static
variable is declared where the first element in the array is set to all zeroes.
But the other elements in the array are ignored - but since it is static
they are also set to 0 so we are good here.
In some cases I see it removed again, I did not check the end result if
we end up dropping them all again.

>  
> - vaddr += clip_offset(clip, fb->pitches[0], cpp);
> - for (y = 0; y < lines; y++) {
> - memcpy(dst, vaddr, len);
> - vaddr += fb->pitches[0];
> - dst += dst_pitch;
> - }
> -}
> -EXPORT_SYMBOL(drm_fb_memcpy);
> -
> -/**
> - * drm_fb_memcpy_toio - Copy clip buffer
> - * @dst: Destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: Source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - *
> - * This function does not apply clipping on dst, i.e. the destination
> - * is at the top-left corner.
> - */
> -void drm_fb_memcpy_toio(void __iomem *dst, unsigned int dst_pitch, const 
> void *vaddr,
> - const struct drm_framebuffer *fb, const struct drm_rect 
> *clip)
> -{
> - unsigned int cpp = fb->format->cpp[0];
> - size_t len = (clip->x2 - clip->x1) * cpp;
> - unsigned int y, lines = clip->y2 - clip->y1;
> + const struct drm_format_info *format = fb->format;
> + unsigned int i, y, lines = drm_rect_height(clip);
>  
>   if (!dst_pitch)
> - dst_pitch = len;
> -
> - vaddr += clip_offset(clip, fb->pitches[0], cpp);
> - for (y = 0; y < lines; y++) {
> - memcpy_toio(dst, vaddr, len);
> - vaddr += fb->pitches[0];
> - dst += dst_pitch;
> + dst_pitch = default_dst_pitch;
> +
> + for (i = 0; i < format->num_planes; ++i) {
> + unsigned int cpp_i = format->cpp[i];
unsigned int cpp_i = drm_format_info_bpp(format, i) / 8;

This avoid adding more uses of the deprecated cpp[] array.

> + size_t len_i = drm_rect_width(clip) * cpp_i;
> + unsigned int dst_pitch_i = dst_pitch[i];
> + 

Re: New subsystem for acceleration devices

[Oded Gabbay]

On Thu, Aug 4, 2022 at 6:04 PM Jeffrey Hugo  wrote:
>
> On 8/4/2022 6:00 AM, Tvrtko Ursulin wrote:
> >
> > On 04/08/2022 00:54, Dave Airlie wrote:
> >> On Thu, 4 Aug 2022 at 06:21, Oded Gabbay  wrote:
> >>>
> >>> On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie  wrote:
> 
>  On Sun, 31 Jul 2022 at 22:04, Oded Gabbay 
>  wrote:
> >
> > Hi,
> > Greg and I talked a couple of months ago about preparing a new accel
> > subsystem for compute/acceleration devices that are not GPUs and I
> > think your drivers that you are now trying to upstream fit it as well.
> 
>  We've had some submissions for not-GPUs to the drm subsystem recently.
> 
>  Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit.
> 
>  why is creating a new subsystem at this time necessary?
> 
>  Are we just creating a subsystem to avoid the open source userspace
>  consumer rules? Or do we have some concrete reasoning behind it?
> 
>  Dave.
> >>>
> >>> Hi Dave.
> >>> The reason it happened now is because I saw two drivers, which are
> >>> doing h/w acceleration for AI, trying to be accepted to the misc
> >>> subsystem.
> >>> Add to that the fact I talked with Greg a couple of months ago about
> >>> doing a subsystem for any compute accelerators, which he was positive
> >>> about, I thought it is a good opportunity to finally do it.
> >>>
> >>> I also honestly think that I can contribute much to these drivers from
> >>> my experience with the habana driver (which is now deployed in mass at
> >>> AWS) and contribute code from the habana driver to a common framework
> >>> for AI drivers.
> >>
> >> Why not port the habana driver to drm now instead? I don't get why it
> >> wouldn't make sense?
> >>
> >> Stepping up to create a new subsystem is great, but we need rules
> >> around what belongs where, we can't just spawn new subsystems when we
> >> have no clear guidelines on where drivers should land.
> >>
> >> What are the rules for a new accel subsystem? Do we have to now
> >> retarget the 3 drivers that are queued up to use drm for accelerators,
> >> because 2 drivers don't?
> >
> > Isn't there three on the "don't prefer drm" side as well? Habana,
> > Toshiba and Samsung? Just so the numbers argument is not misrepresented.
> > Perhaps a poll like a) prefer DRM, b) prefer a new subsystem, c) don't
> > care in principle; is in order?
>
> I'll chime in with my opinions.  Take them for what you will.
>
> I would say I fall into the C category, but I'm targeting DRM and will
> be the 5th(?) accel device to do so.
>
> I'll say that the ksummit (from what I see in the LWN article) made me
> very happy.  Finally, the community had clear rules for accel drivers.
> When I targeted misc in the past, it seemed like Greg moved the goal
> post just for me, which stalled our attempt.  It was even more
> frustrating to see that the high bar Greg set for us was not applied to
> other devices of the same "class" in following submissions.
>
> However, the past is the past, and based on ksummit, we've spent a
> number of months retargeting DRM.  In a week (or two), I plan to post
> something to start up the discussions again.
>
> As far as the DRM userspace requirements, unless we've misunderstood
> something, they've been easier to satisfy (pending review I suppose)
> than what misc has set.
I think it is quite the opposite. In misc originally there was very
minimal userspace requirements, but when my driver started to use
dma-buf, Dave asked for more.
e.g. a driver that wants to get accepted to DRM and use a fork of LLVM
must not only open-source his code, but also to upstream his fork to
the mainline LLVM tree. In misc there is nothing that closely comes to
that requirement afaik.
>
> I would say that Dave Airlie's feedback on this discussion resonates
> with me.  From the perspective of a vendor wanting to be a part of the
> community, clear rules are important and ksummit seemed to set that.
> Oded's announcement has thrown all of that into the wind.  Without a
That wasn't my intention. I simply wanted to:
1. Offload Greg with these types of drivers.
2. Offer to the new drivers a standard char device handling
3. Start a community of kernel hackers that are writing device drivers
for compute accelerators.

> proposal to evaluate (eg show me the code with clear guidelines), I
> cannot seriously consider Oded's idea, and I'm not sure I want to sit by
> another few years to see it settle out.
I thought of posting something quick (but not dirty) but this backlash
has made me rethink that.

>
> I expect to move forward with what we were planning prior to seeing this
> thread which is targeting DRM.  We'll see what the DRM folks say when
> they have something to look at.  If our device doesn't fit in DRM per an
> assessment of the DRM folks, then I sure hope they can suggest where we
> do fit because then we'll have tried misc and DRM, and not found a home.
>   Since "drivers/accel" doesn't exist, and 

Re: [PATCH 03/12] drm/format-helper: Convert drm_fb_swab() to struct iosys_map

[Sam Ravnborg]

Hi Thomas,

On Wed, Jul 27, 2022 at 01:33:03PM +0200, Thomas Zimmermann wrote:
> Convert drm_fb_swab() to use struct iosys_map() and convert users. The
> new interface supports multi-plane color formats.
It swabs only plane[0], sbut this is maybe enough to say so.

A few comments in the following.

Sam

> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_format_helper.c | 38 +
>  drivers/gpu/drm/drm_mipi_dbi.c  |  2 +-
>  drivers/gpu/drm/gud/gud_pipe.c  |  2 +-
>  include/drm/drm_format_helper.h |  6 ++---
>  4 files changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index 49589b442f18..fa22d3cb11e8 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -196,9 +196,9 @@ static void drm_fb_swab32_line(void *dbuf, const void 
> *sbuf, unsigned int pixels
>  
>  /**
>   * drm_fb_swab - Swap bytes into clip buffer
> - * @dst: Destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: Source buffer
> + * @dst: Array of destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines 
> within dst
Document that it may be NULL?

> + * @vmap: Array of source buffers
Prefer that the source is named src, and vmap smells like system
(virtual) memory to me.
Also vmap must be system memory - but this is maybe fixed later.


>   * @fb: DRM framebuffer
>   * @clip: Clip rectangle area to copy
>   * @cached: Source buffer is mapped cached (eg. not write-combined)
> @@ -209,24 +209,42 @@ static void drm_fb_swab32_line(void *dbuf, const void 
> *sbuf, unsigned int pixels
>   * This function does not apply clipping on dst, i.e. the destination
>   * is at the top-left corner.
>   */
> -void drm_fb_swab(void *dst, unsigned int dst_pitch, const void *src,
> -  const struct drm_framebuffer *fb, const struct drm_rect *clip,
> -  bool cached)
> +void drm_fb_swab(struct iosys_map *dst, const unsigned int *dst_pitch,
> +  const struct iosys_map *vmap, const struct drm_framebuffer *fb,
> +  const struct drm_rect *clip, bool cached)
>  {
> - u8 cpp = fb->format->cpp[0];
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> + const struct drm_format_info *format = fb->format;
> + u8 cpp = format->cpp[0];
u8 cpp = drm_format_info_bpp(format, 0) / 8;

> + void (*swab_line)(void *dbuf, const void *sbuf, unsigned int npixels);
>  
>   switch (cpp) {
>   case 4:
> - drm_fb_xfrm(dst, dst_pitch, cpp, src, fb, clip, cached, 
> drm_fb_swab32_line);
> + swab_line = drm_fb_swab32_line;
>   break;
>   case 2:
> - drm_fb_xfrm(dst, dst_pitch, cpp, src, fb, clip, cached, 
> drm_fb_swab16_line);
> + swab_line = drm_fb_swab16_line;
>   break;
>   default:
>   drm_warn_once(fb->dev, "Format %p4cc has unsupported pixel 
> size.\n",
> -   &fb->format->format);
> +   &format->format);
> + swab_line = NULL;
>   break;
>   }
> + if (!swab_line)
> + return;
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst->is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], cpp,
> +  vmap[0].vaddr, fb, clip, cached, swab_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], cpp, vmap[0].vaddr, fb,
> + clip, cached, swab_line);
Here vmap is assumes system memory, not IO. I assume this is fixed
later.

>  }
>  EXPORT_SYMBOL(drm_fb_swab);
>  
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 22451806fb5c..973a75585cad 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -221,7 +221,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
> *fb,
>   switch (fb->format->format) {
>   case DRM_FORMAT_RGB565:
>   if (swap)
> - drm_fb_swab(dst, 0, src, fb, clip, !gem->import_attach);
> + drm_fb_swab(&dst_map, NULL, data, fb, clip, 
> !gem->import_attach);
>   else
>   drm_fb_memcpy(&dst_map, NULL, data, fb, clip);
>   break;
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index 449c95a4aee0..a15cda9ba058 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -205,7 +205,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct 
> drm_framebuffer *fb,
>   len = gud_xrgb_to_color(buf, format, vaddr, fb, 
> rect);
>   }
>   } else if (gud_is_big_endian()

Re: [PATCH 04/12] drm/format-helper: Rework XRGB8888-to-RGBG332 conversion

[Sam Ravnborg]

Hi Thomas,

On Wed, Jul 27, 2022 at 01:33:04PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB332 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
> 
> Signed-off-by: Thomas Zimmermann 

I am not going to repeat my naming rant here, so
Reviewed-by: Sam Ravnborg 

> ---
>  drivers/gpu/drm/drm_format_helper.c   | 25 ++-
>  drivers/gpu/drm/gud/gud_pipe.c|  2 +-
>  .../gpu/drm/tests/drm_format_helper_test.c| 14 ++-
>  include/drm/drm_format_helper.h   |  5 ++--
>  4 files changed, 31 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index fa22d3cb11e8..2b5c3746ff4a 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -265,18 +265,31 @@ static void drm_fb_xrgb_to_rgb332_line(void *dbuf, 
> const void *sbuf, unsigne
>  
>  /**
>   * drm_fb_xrgb_to_rgb332 - Convert XRGB to RGB332 clip buffer
> - * @dst: RGB332 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @src: XRGB source buffer
> + * @dst: Array of RGB332 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines 
> within dst
> + * @vmap: Array of XRGB source buffers
>   * @fb: DRM framebuffer
>   * @clip: Clip rectangle area to copy
>   *
>   * Drivers can use this function for RGB332 devices that don't natively 
> support XRGB.
>   */
> -void drm_fb_xrgb_to_rgb332(void *dst, unsigned int dst_pitch, const void 
> *src,
> -const struct drm_framebuffer *fb, const struct 
> drm_rect *clip)
> +void drm_fb_xrgb_to_rgb332(struct iosys_map *dst, const unsigned int 
> *dst_pitch,
> +const struct iosys_map *vmap, const struct 
> drm_framebuffer *fb,
> +const struct drm_rect *clip)
>  {
> - drm_fb_xfrm(dst, dst_pitch, 1, src, fb, clip, false, 
> drm_fb_xrgb_to_rgb332_line);
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 1, 
> vmap[0].vaddr, fb, clip,
> +  false, drm_fb_xrgb_to_rgb332_line);
> + else
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 1, vmap[0].vaddr, fb, 
> clip,
> + false, drm_fb_xrgb_to_rgb332_line);
>  }
>  EXPORT_SYMBOL(drm_fb_xrgb_to_rgb332);
>  
> diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
> index a15cda9ba058..426a3ae6cc50 100644
> --- a/drivers/gpu/drm/gud/gud_pipe.c
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> @@ -196,7 +196,7 @@ static int gud_prep_flush(struct gud_device *gdrm, struct 
> drm_framebuffer *fb,
>   } else if (format->format == DRM_FORMAT_R8) {
>   drm_fb_xrgb_to_gray8(buf, 0, vaddr, fb, rect);
>   } else if (format->format == DRM_FORMAT_RGB332) {
> - drm_fb_xrgb_to_rgb332(buf, 0, vaddr, fb, rect);
> + drm_fb_xrgb_to_rgb332(&dst, NULL, map_data, fb, 
> rect);
>   } else if (format->format == DRM_FORMAT_RGB565) {
>   drm_fb_xrgb_to_rgb565(buf, 0, vaddr, fb, rect, 
> gud_is_big_endian());
>   } else if (format->format == DRM_FORMAT_RGB888) {
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c 
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 98583bf56044..b74dba06f704 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -124,7 +124,8 @@ static void xrgb_to_rgb332_test(struct kunit *test)
>  {
>   const struct xrgb_to_rgb332_case *params = test->param_value;
>   size_t dst_size;
> - __u8 *dst = NULL;
> + struct iosys_map dst, xrgb;
> + __u8 *buf = NULL;
>  
>   struct drm_framebuffer fb = {
>   .format = drm_format_info(DRM_FORMAT_XRGB),
> @@ -135,12 +136,13 @@ static void xrgb_to_rgb332_test(struct kunit *test)
>  ¶ms->clip);
>   KUNIT_ASSERT_GT(test, dst_size, 0);
>  
> - dst = kunit_kzalloc(test, dst_size, GFP_KERNEL);
> - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dst);
> + buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
>  
> - drm_fb_xrgb_to_rgb332(dst, params->dst_pitch, params->xrgb,
> -   &fb, ¶ms->clip);
> - KUNIT_EXPECT_EQ(test, memcmp(dst, params->expected, dst_size), 0);
> + iosys_map_set_vaddr(&ds

Re: [PATCH 05/12] drm/format-helper: Rework XRGB8888-to-RGBG565 conversion

[Sam Ravnborg]

On Wed, Jul 27, 2022 at 01:33:05PM +0200, Thomas Zimmermann wrote:
> Update XRGB-to-RGB565 conversion to support struct iosys_map
> and convert all users. Although these are single-plane color formats,
> the new interface supports multi-plane formats for consistency with
> drm_fb_blit().
> 
> Signed-off-by: Thomas Zimmermann 
Reviewed-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/drm_format_helper.c | 59 +++--
>  drivers/gpu/drm/drm_mipi_dbi.c  |  4 +-
>  drivers/gpu/drm/gud/gud_pipe.c  |  3 +-
>  drivers/gpu/drm/tiny/cirrus.c   |  3 +-
>  include/drm/drm_format_helper.h |  9 ++---
>  5 files changed, 30 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index 2b5c3746ff4a..8bf5655f5ce0 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -330,9 +330,9 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void 
> *dbuf, const void *sbuf,
>  
>  /**
>   * drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> + * @dst: Array of RGB565 destination buffers
> + * @dst_pitch: Array of numbers of bytes between two consecutive scanlines 
> within dst
> + * @vmap: Array of XRGB source buffer
>   * @fb: DRM framebuffer
>   * @clip: Clip rectangle area to copy
>   * @swab: Swap bytes
> @@ -340,43 +340,31 @@ static void drm_fb_xrgb_to_rgb565_swab_line(void 
> *dbuf, const void *sbuf,
>   * Drivers can use this function for RGB565 devices that don't natively
>   * support XRGB.
>   */
> -void drm_fb_xrgb_to_rgb565(void *dst, unsigned int dst_pitch, const void 
> *vaddr,
> -const struct drm_framebuffer *fb, const struct 
> drm_rect *clip,
> -bool swab)
> +void drm_fb_xrgb_to_rgb565(struct iosys_map *dst, const unsigned int 
> *dst_pitch,
> +const struct iosys_map *vmap, const struct 
> drm_framebuffer *fb,
> +const struct drm_rect *clip, bool swab)
>  {
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> + void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned int npixels);
> +
>   if (swab)
> - drm_fb_xfrm(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_swab_line);
> + xfrm_line = drm_fb_xrgb_to_rgb565_swab_line;
>   else
> - drm_fb_xfrm(dst, dst_pitch, 2, vaddr, fb, clip, false,
> - drm_fb_xrgb_to_rgb565_line);
> -}
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
> + xfrm_line = drm_fb_xrgb_to_rgb565_line;
>  
> -/**
> - * drm_fb_xrgb_to_rgb565_toio - Convert XRGB to RGB565 clip buffer
> - * @dst: RGB565 destination buffer (iomem)
> - * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> - * @vaddr: XRGB source buffer
> - * @fb: DRM framebuffer
> - * @clip: Clip rectangle area to copy
> - * @swab: Swap bytes
> - *
> - * Drivers can use this function for RGB565 devices that don't natively
> - * support XRGB.
> - */
> -void drm_fb_xrgb_to_rgb565_toio(void __iomem *dst, unsigned int 
> dst_pitch,
> - const void *vaddr, const struct 
> drm_framebuffer *fb,
> - const struct drm_rect *clip, bool swab)
> -{
> - if (swab)
> - drm_fb_xfrm_toio(dst, dst_pitch, 2, vaddr, fb, clip, false,
> -  drm_fb_xrgb_to_rgb565_swab_line);
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0], 2, 
> vmap[0].vaddr, fb, clip,
> +  false, xfrm_line);
>   else
> - drm_fb_xfrm_toio(dst, dst_pitch, 2, vaddr, fb, clip, false,
> -  drm_fb_xrgb_to_rgb565_line);
> + drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], 2, vmap[0].vaddr, fb, 
> clip,
> + false, xfrm_line);
>  }
> -EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_toio);
> +EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
>  
>  static void drm_fb_xrgb_to_rgb888_line(void *dbuf, const void *sbuf, 
> unsigned int pixels)
>  {
> @@ -605,8 +593,7 @@ int drm_fb_blit(struct iosys_map *dst, const unsigned int 
> *dst_pitch, uint32_t d
>  
>   } else if (dst_format == DRM_FORMAT_RGB565) {
>   if (fb_format == DRM_FORMAT_XRGB) {
> - drm_fb_xrgb_to_rgb565_toio(dst[0].vaddr_iomem, 
> dst_pitch[0],
> -vmap[0].vaddr, fb, clip, 
> false);
> + drm_fb_xrgb_to_rgb565(dst, dst