date:20201218

As far as I can tell the buffer_count was never used by an
userspace application.

The number of BOs in the system is far better suited in
debugfs than sysfs and we now should be able to add other
information here as well.

v2: add that additionally to sysfs

Signed-off-by: Christian König 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 48 ++--
 drivers/gpu/drm/ttm/ttm_module.c |  4 +++
 drivers/gpu/drm/ttm/ttm_module.h |  6 ++--
 3 files changed, 11 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31e8b3da5563..cd55e3104e50 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -44,8 +44,6 @@
 
 #include "ttm_module.h"
 
-static void ttm_bo_global_kobj_release(struct kobject *kobj);
-
 /*
  * ttm_global_mutex - protecting the global BO state
  */
@@ -54,11 +52,6 @@ unsigned ttm_bo_glob_use_count;
 struct ttm_bo_global ttm_bo_glob;
 EXPORT_SYMBOL(ttm_bo_glob);
 
-static struct attribute ttm_bo_count = {
-   .name = "bo_count",
-   .mode = S_IRUGO
-};
-
 /* default destructor */
 static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
 {
@@ -84,32 +77,6 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object 
*bo,
}
 }
 
-static ssize_t ttm_bo_global_show(struct kobject *kobj,
- struct attribute *attr,
- char *buffer)
-{
-   struct ttm_bo_global *glob =
-   container_of(kobj, struct ttm_bo_global, kobj);
-
-   return snprintf(buffer, PAGE_SIZE, "%d\n",
-   atomic_read(>bo_count));
-}
-
-static struct attribute *ttm_bo_global_attrs[] = {
-   _bo_count,
-   NULL
-};
-
-static const struct sysfs_ops ttm_bo_global_ops = {
-   .show = _bo_global_show
-};
-
-static struct kobj_type ttm_bo_glob_kobj_type  = {
-   .release = _bo_global_kobj_release,
-   .sysfs_ops = _bo_global_ops,
-   .default_attrs = ttm_bo_global_attrs
-};
-
 static void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
 {
struct ttm_bo_device *bdev = bo->bdev;
@@ -1226,14 +1193,6 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
 }
 EXPORT_SYMBOL(ttm_bo_dma_acc_size);
 
-static void ttm_bo_global_kobj_release(struct kobject *kobj)
-{
-   struct ttm_bo_global *glob =
-   container_of(kobj, struct ttm_bo_global, kobj);
-
-   __free_page(glob->dummy_read_page);
-}
-
 static void ttm_bo_global_release(void)
 {
struct ttm_bo_global *glob = _bo_glob;
@@ -1245,6 +1204,7 @@ static void ttm_bo_global_release(void)
kobject_del(>kobj);
kobject_put(>kobj);
ttm_mem_global_release(_mem_glob);
+   __free_page(glob->dummy_read_page);
memset(glob, 0, sizeof(*glob));
 out:
mutex_unlock(_global_mutex);
@@ -1277,10 +1237,8 @@ static int ttm_bo_global_init(void)
INIT_LIST_HEAD(>device_list);
atomic_set(>bo_count, 0);
 
-   ret = kobject_init_and_add(
-   >kobj, _bo_glob_kobj_type, ttm_get_kobj(), 
"buffer_objects");
-   if (unlikely(ret != 0))
-   kobject_put(>kobj);
+   debugfs_create_atomic_t("buffer_objects", 0444, ttm_debugfs_root,
+   >bo_count);
 out:
mutex_unlock(_global_mutex);
return ret;
diff --git a/drivers/gpu/drm/ttm/ttm_module.c b/drivers/gpu/drm/ttm/ttm_module.c
index c0906437cb1c..f6566603a60f 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -32,12 +32,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "ttm_module.h"
 
 static DECLARE_WAIT_QUEUE_HEAD(exit_q);
 static atomic_t device_released;
+struct dentry *ttm_debugfs_root;
 
 static struct device_type ttm_drm_class_type = {
.name = "ttm",
@@ -77,6 +79,7 @@ static int __init ttm_init(void)
if (unlikely(ret != 0))
goto out_no_dev_reg;
 
+   ttm_debugfs_root = debugfs_create_dir("ttm", NULL);
return 0;
 out_no_dev_reg:
atomic_set(_released, 1);
@@ -94,6 +97,7 @@ static void __exit ttm_exit(void)
 */
 
wait_event(exit_q, atomic_read(_released) == 1);
+   debugfs_remove(ttm_debugfs_root);
 }
 
 module_init(ttm_init);
diff --git a/drivers/gpu/drm/ttm/ttm_module.h b/drivers/gpu/drm/ttm/ttm_module.h
index 45fa318c1585..2f03c2fcf570 100644
--- a/drivers/gpu/drm/ttm/ttm_module.h
+++ b/drivers/gpu/drm/ttm/ttm_module.h
@@ -31,10 +31,12 @@
 #ifndef _TTM_MODULE_H_
 #define _TTM_MODULE_H_
 
-#include 
+#define TTM_PFX "[TTM] "
+
 struct kobject;
+struct dentry;
 
-#define TTM_PFX "[TTM] "
 extern struct kobject *ttm_get_kobj(void);
+extern struct dentry *ttm_debugfs_root;
 
 #endif /* _TTM_MODULE_H_ */
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/ttm: optimize ttm pool shrinker a bit

Only initialize the DMA coherent pools if they are used.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 1cdacd58753a..f09e34614226 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -504,10 +504,12 @@ void ttm_pool_init(struct ttm_pool *pool, struct device 
*dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
 
-   for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
-   for (j = 0; j < MAX_ORDER; ++j)
-   ttm_pool_type_init(>caching[i].orders[j],
-  pool, i, j);
+   if (use_dma_alloc) {
+   for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+   for (j = 0; j < MAX_ORDER; ++j)
+   ttm_pool_type_init(>caching[i].orders[j],
+  pool, i, j);
+   }
 }
 EXPORT_SYMBOL(ttm_pool_init);
 
@@ -523,9 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
 {
unsigned int i, j;
 
-   for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
-   for (j = 0; j < MAX_ORDER; ++j)
-   ttm_pool_type_fini(>caching[i].orders[j]);
+   if (pool->use_dma_alloc) {
+   for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+   for (j = 0; j < MAX_ORDER; ++j)
+   ttm_pool_type_fini(>caching[i].orders[j]);
+   }
 }
 EXPORT_SYMBOL(ttm_pool_fini);
 
@@ -630,6 +634,11 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct 
seq_file *m)
 {
unsigned int i;
 
+   if (!pool->use_dma_alloc) {
+   seq_puts(m, "unused\n");
+   return 0;
+   }
+
ttm_pool_debugfs_header(m);
 
spin_lock(_lock);
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/ttm: add debugfs entry to test pool shrinker

Useful for testing.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 50 ++
 1 file changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 1d61e8fc0e81..1cdacd58753a 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -529,6 +529,28 @@ void ttm_pool_fini(struct ttm_pool *pool)
 }
 EXPORT_SYMBOL(ttm_pool_fini);
 
+/* As long as pages are available make sure to release at least one */
+static unsigned long ttm_pool_shrinker_scan(struct shrinker *shrink,
+   struct shrink_control *sc)
+{
+   unsigned long num_freed = 0;
+
+   do
+   num_freed += ttm_pool_shrink();
+   while (!num_freed && atomic_long_read(_pages));
+
+   return num_freed;
+}
+
+/* Return the number of pages available or SHRINK_EMPTY if we have none */
+static unsigned long ttm_pool_shrinker_count(struct shrinker *shrink,
+struct shrink_control *sc)
+{
+   unsigned long num_pages = atomic_long_read(_pages);
+
+   return num_pages ? num_pages : SHRINK_EMPTY;
+}
+
 #ifdef CONFIG_DEBUG_FS
 /* Count the number of pages available in a pool_type */
 static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
@@ -633,29 +655,19 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct 
seq_file *m)
 }
 EXPORT_SYMBOL(ttm_pool_debugfs);
 
-#endif
-
-/* As long as pages are available make sure to release at least one */
-static unsigned long ttm_pool_shrinker_scan(struct shrinker *shrink,
-   struct shrink_control *sc)
+/* Test the shrinker functions and dump the result */
+static int ttm_pool_debugfs_shrink_show(struct seq_file *m, void *data)
 {
-   unsigned long num_freed = 0;
+   struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
 
-   do
-   num_freed += ttm_pool_shrink();
-   while (!num_freed && atomic_long_read(_pages));
+   seq_printf(m, "%lu/%lu\n", ttm_pool_shrinker_count(_shrinker, ),
+  ttm_pool_shrinker_scan(_shrinker, ));
 
-   return num_freed;
+   return 0;
 }
+DEFINE_SHOW_ATTRIBUTE(ttm_pool_debugfs_shrink);
 
-/* Return the number of pages available or SHRINK_EMPTY if we have none */
-static unsigned long ttm_pool_shrinker_count(struct shrinker *shrink,
-struct shrink_control *sc)
-{
-   unsigned long num_pages = atomic_long_read(_pages);
-
-   return num_pages ? num_pages : SHRINK_EMPTY;
-}
+#endif
 
 /**
  * ttm_pool_mgr_init - Initialize globals
@@ -688,6 +700,8 @@ int ttm_pool_mgr_init(unsigned long num_pages)
 #ifdef CONFIG_DEBUG_FS
debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
_pool_debugfs_globals_fops);
+   debugfs_create_file("page_pool_shrink", 0400, ttm_debugfs_root, NULL,
+   _pool_debugfs_shrink_fops);
 #endif
 
mm_shrinker.count_objects = ttm_pool_shrinker_count;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm/ttm: add a debugfs file for the global page pools

Instead of printing this on the per device pool.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 70 --
 1 file changed, 50 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 7b2f60616750..1d61e8fc0e81 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -42,6 +42,8 @@
 #include 
 #include 
 
+#include "ttm_module.h"
+
 /**
  * struct ttm_pool_dma - Helper object for coherent DMA mappings
  *
@@ -543,6 +545,17 @@ static unsigned int ttm_pool_type_count(struct 
ttm_pool_type *pt)
return count;
 }
 
+/* Print a nice header for the order */
+static void ttm_pool_debugfs_header(struct seq_file *m)
+{
+   unsigned int i;
+
+   seq_puts(m, "\t ");
+   for (i = 0; i < MAX_ORDER; ++i)
+   seq_printf(m, " ---%2u---", i);
+   seq_puts(m, "\n");
+}
+
 /* Dump information about the different pool types */
 static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
struct seq_file *m)
@@ -554,6 +567,35 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type 
*pt,
seq_puts(m, "\n");
 }
 
+/* Dump the total amount of allocated pages */
+static void ttm_pool_debugfs_footer(struct seq_file *m)
+{
+   seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
+  atomic_long_read(_pages), page_pool_size);
+}
+
+/* Dump the information for the global pools */
+static int ttm_pool_debugfs_globals_show(struct seq_file *m, void *data)
+{
+   ttm_pool_debugfs_header(m);
+
+   spin_lock(_lock);
+   seq_puts(m, "wc\t:");
+   ttm_pool_debugfs_orders(global_write_combined, m);
+   seq_puts(m, "uc\t:");
+   ttm_pool_debugfs_orders(global_uncached, m);
+   seq_puts(m, "wc 32\t:");
+   ttm_pool_debugfs_orders(global_dma32_write_combined, m);
+   seq_puts(m, "uc 32\t:");
+   ttm_pool_debugfs_orders(global_dma32_uncached, m);
+   spin_unlock(_lock);
+
+   ttm_pool_debugfs_footer(m);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(ttm_pool_debugfs_globals);
+
 /**
  * ttm_pool_debugfs - Debugfs dump function for a pool
  *
@@ -566,23 +608,9 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct 
seq_file *m)
 {
unsigned int i;
 
-   spin_lock(_lock);
-
-   seq_puts(m, "\t ");
-   for (i = 0; i < MAX_ORDER; ++i)
-   seq_printf(m, " ---%2u---", i);
-   seq_puts(m, "\n");
-
-   seq_puts(m, "wc\t:");
-   ttm_pool_debugfs_orders(global_write_combined, m);
-   seq_puts(m, "uc\t:");
-   ttm_pool_debugfs_orders(global_uncached, m);
-
-   seq_puts(m, "wc 32\t:");
-   ttm_pool_debugfs_orders(global_dma32_write_combined, m);
-   seq_puts(m, "uc 32\t:");
-   ttm_pool_debugfs_orders(global_dma32_uncached, m);
+   ttm_pool_debugfs_header(m);
 
+   spin_lock(_lock);
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
seq_puts(m, "DMA ");
switch (i) {
@@ -598,12 +626,9 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct 
seq_file *m)
}
ttm_pool_debugfs_orders(pool->caching[i].orders, m);
}
-
-   seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
-  atomic_long_read(_pages), page_pool_size);
-
spin_unlock(_lock);
 
+   ttm_pool_debugfs_footer(m);
return 0;
 }
 EXPORT_SYMBOL(ttm_pool_debugfs);
@@ -660,6 +685,11 @@ int ttm_pool_mgr_init(unsigned long num_pages)
   ttm_uncached, i);
}
 
+#ifdef CONFIG_DEBUG_FS
+   debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
+   _pool_debugfs_globals_fops);
+#endif
+
mm_shrinker.count_objects = ttm_pool_shrinker_count;
mm_shrinker.scan_objects = ttm_pool_shrinker_scan;
mm_shrinker.seeks = 1;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-next, part 2 + fixes

Hi Linus,

Merge window -fixes pull, but bigger: We've somehow missed one subtree
pull (which also contained the amdgpu multihop fix you cherry-pick, oops).
But that pull was pending for almost 3 weeks on the list and most of it
for even longer in linux-next, so really not seeing a reason why it should
be delayed. It contains vma_set_file helper, acked by Andrew and reviewed
by other mm folks, and a few other smaller things. Otherwise this is all
fixes, overview below the tag.

Dave's back next week, there's some minor things in-flight, you'll get a
nice Christmas pull before -rc1 I think. I'll be around until Tue next
week still.

Cheers, Daniel

PS: I remembered my pgp passphrase, somewhat shocking :-)

drm-next-2020-12-18:
UAPI Changes:

- Only enable char/agp uapi when CONFIG_DRM_LEGACY is set

Cross-subsystem Changes:

- vma_set_file helper to make vma->vm_file changing less brittle,
  acked by Andrew

Core Changes:

- dma-buf heaps improvements
- pass full atomic modeset state to driver callbacks
- shmem helpers: cached bo by default
- cleanups for fbdev, fb-helpers
- better docs for drm modes and SCALING_FITLER uapi
- ttm: fix dma32 page pool regression

Driver Changes:

- multi-hop regression fixes for amdgpu, radeon, nouveau
- lots of small amdgpu hw enabling fixes (display, pm, ...)
- fixes for imx, mcde, meson, some panels, virtio, qxl, i915, all
  fairly minor
- some cleanups for legacy drm/fbdev drivers

Cheers, Daniel

The following changes since commit 1d36dffa5d887715dacca0f717f4519b7be5e498:

  Merge tag 'drm-next-2020-12-11' of git://anongit.freedesktop.org/drm/drm 
(2020-12-14 11:07:56 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-12-18

for you to fetch changes up to 4efd7faba5e0687ae9143b7e6a19547ede20a7dd:

  Merge tag 'drm-intel-next-fixes-2020-12-18' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-12-18 16:22:10 
+0100)


UAPI Changes:

- Only enable char/agp uapi when CONFIG_DRM_LEGACY is set

Cross-subsystem Changes:

- vma_set_file helper to make vma->vm_file changing less brittle,
  acked by Andrew

Core Changes:

- dma-buf heaps improvements
- pass full atomic modeset state to driver callbacks
- shmem helpers: cached bo by default
- cleanups for fbdev, fb-helpers
- better docs for drm modes and SCALING_FITLER uapi
- ttm: fix dma32 page pool regression

Driver Changes:

- multi-hop regression fixes for amdgpu, radeon, nouveau
- lots of small amdgpu hw enabling fixes (display, pm, ...)
- fixes for imx, mcde, meson, some panels, virtio, qxl, i915, all
  fairly minor
- some cleanups for legacy drm/fbdev drivers


Aditya Swarup (1):
  drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping

Alex Deucher (10):
  drm/amdgpu/display: move link_bandwidth_kbps under CONFIG_DRM_AMD_DC_DCN
  drm/amdgpu: split BOCO and ATPX handling
  drm/amdgpu: add check for ACPI power resources
  drm/amdgpu: update amdgpu_device_supports_boco()
  drm/amdgpu: support runtime pm for GPUs that support BOCO
  drm/amdgpu: no need to call pci_ignore_hotplug for _PR3
  drm/amdgpu: simplify logic in atpx resume handling
  drm/amdgpu: print what method we are using for runtime pm
  drm/amdgpu: fix regression in vbios reservation handling on headless
  drm/amdgpu/disply: fix documentation warnings in display manager

Anthoine Bourgeois (3):
  drm/virtio: suffix create blob call with _ioctl like any ioctl
  drm/virtio: fix a file name comment reference
  virtio-gpu api: Add a comment on VIRTIO_GPU_SHM_ID_HOST_VISIBLE

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.46

Aric Cyr (4):
  drm/amd/display: HP Reverb G2 VR fails to light up
  drm/amd/display: Only update FP2 for full updates
  drm/amd/display: Fix cleanup typo in MPCC visual confirm
  drm/amd/display: 3.2.116

Bernard Zhao (1):
  drm/via: fix assignment in if condition

Chris Wilson (2):
  Revert "drm/i915: re-order if/else ladder for hpd_irq_setup"
  drm/i915: Fix mismatch between misplaced vma check and vma insert

Christian König (7):
  drm/amdgpu: fix check order in amdgpu_bo_move
  mm: mmap: fix fput in error path v2
  mm: introduce vma_set_file function v5
  drm/ttm: fix DMA32 handling in the global page pool
  drm/amdgpu: limit the amdgpu_vm_update_ptes trace point
  drm/radeon: fix check order in radeon_bo_move
  drm/qxl: don't allocate a dma_address array

Colin Ian King (2):
  drm/mcde: fix masking and bitwise-or on variable val
  drm/amdgpu: Fix spelling mistake "Heterogenous" -> "Heterogeneous"

Daniel Vetter (6):
  char/agp: Disable frontend without CONFIG_DRM_LEGACY
  Merge tag 'drm-misc-next-2020-11-27-1' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next
  dma-buf:

Re: WARNING: suspicious RCU usage in modeset_lock

On Fri, Dec 18, 2020 at 5:10 PM Steven Rostedt  wrote:
>
> On Thu, 17 Dec 2020 11:03:20 +0100
> Daniel Vetter  wrote:
>
> > I think we're tripping over the might_sleep() all the mutexes have,
> > and that's not as good as yours, but good enough to catch a missing
> > rcu_read_unlock(). That's kinda why I'm baffled, since like almost
> > every 2nd function in the backtrace grabbed a mutex and it was all
> > fine until the very last.
> >
> > I think it would be really nice if the rcu checks could retain (in
> > debugging only) the backtrace of the outermost rcu_read_lock, so we
> > could print that when something goes wrong in cases where it's leaked.
> > For normal locks lockdep does that already (well not full backtrace I
> > think, just the function that acquired the lock, but that's often
> > enough). I guess that doesn't exist yet?
> >
> > Also yes without reproducer this is kinda tough nut to crack.
>
> I'm looking at drm_client_modeset_commit_atomic(), where it triggered after
> the "retry:" label, which to get to, does a bit of goto spaghetti, with
> a -EDEADLK detected and a goto backoff, which calls goto retry, and then
> the next mutex taken is the one that triggers the bug.

This is standard drm locking spaghetti using ww_mutexes. Enable
CONFIG_DEBUG_WW_MUTEX_SLOWPATH and you'll hit this all the time, in
all kinds of situations. We're using this all the time because it's
way too easy to to get the error cases wrong.

> As this is hard to reproduce, but reproducible by a fuzzer, I'm guessing
> there's some error return path somewhere in there that doesn't release an
> rcu_read_lock().

We're maybe a bit too happy to use funny locking schemes like
ww_mutex, but at least to my knowledge there's no rcu anywhere near
these. Or preempt disable fwiw (which I think the consensus is the
more likely culprit). So I have no idea how this leaks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: WARNING: suspicious RCU usage in modeset_lock

2020-12-18 Thread Steven Rostedt

On Thu, 17 Dec 2020 11:03:20 +0100
Daniel Vetter  wrote:

> I think we're tripping over the might_sleep() all the mutexes have,
> and that's not as good as yours, but good enough to catch a missing
> rcu_read_unlock(). That's kinda why I'm baffled, since like almost
> every 2nd function in the backtrace grabbed a mutex and it was all
> fine until the very last.
> 
> I think it would be really nice if the rcu checks could retain (in
> debugging only) the backtrace of the outermost rcu_read_lock, so we
> could print that when something goes wrong in cases where it's leaked.
> For normal locks lockdep does that already (well not full backtrace I
> think, just the function that acquired the lock, but that's often
> enough). I guess that doesn't exist yet?
> 
> Also yes without reproducer this is kinda tough nut to crack.

I'm looking at drm_client_modeset_commit_atomic(), where it triggered after
the "retry:" label, which to get to, does a bit of goto spaghetti, with
a -EDEADLK detected and a goto backoff, which calls goto retry, and then
the next mutex taken is the one that triggers the bug.

As this is hard to reproduce, but reproducible by a fuzzer, I'm guessing
there's some error return path somewhere in there that doesn't release an
rcu_read_lock().

-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type

2020-12-18 Thread Liviu Dudau

On Fri, Dec 18, 2020 at 03:08:12PM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler 
> 
> KASAN found this problem. find_first_bit() expects to look at a
> pointer pointing to a long, but we look at a u32 - this is going to be
> an issue with endianess but, KSAN already flags this as out-of-bounds
> stack reads. This fixes it by just importing inot a local long.
> 
> Signed-off-by: Carsten Haitzler 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> index 452e505a1fd3..719a79728e24 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> @@ -137,9 +137,10 @@ komeda_pipeline_get_first_component(struct 
> komeda_pipeline *pipe,
>   u32 comp_mask)
>  {
>   struct komeda_component *c = NULL;
> + unsigned long comp_mask_local = (unsigned long)comp_mask;
>   int id;
>  
> - id = find_first_bit((unsigned long *)_mask, 32);
> + id = find_first_bit(_mask_local, 32);
>   if (id < 32)
>   c = komeda_pipeline_get_component(pipe, id);
>  
> -- 
> 2.29.2
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-next-fixes

On Fri, Dec 18, 2020 at 05:04:09PM +0200, Jani Nikula wrote:
> 
> Hi Dave & Daniel -
> 
> drm-intel-next-fixes-2020-12-18:
> drm/i915 fixes for the merge window

Pulled, thanks a lot.
-Daniel

> 
> 
> BR,
> Jani.
> 
> The following changes since commit efd3043790c6e92f0bbe1fe385db9b544131c59c:
> 
>   Merge tag 'amd-drm-fixes-5.11-2020-12-16' of 
> git://people.freedesktop.org/~agd5f/linux into drm-next (2020-12-16 23:25:51 
> +0100)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel 
> tags/drm-intel-next-fixes-2020-12-18
> 
> for you to fetch changes up to 046f70d31ddb2069941aec54966fec5b7fbc7b7b:
> 
>   drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping 
> (2020-12-18 12:30:10 +0200)
> 
> 
> drm/i915 fixes for the merge window
> 
> 
> Aditya Swarup (1):
>   drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping
> 
> Chris Wilson (2):
>   Revert "drm/i915: re-order if/else ladder for hpd_irq_setup"
>   drm/i915: Fix mismatch between misplaced vma check and vma insert
> 
> Lionel Landwerlin (1):
>   drm/i915/perf: also include Gen11 in OATAILPTR workaround
> 
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h| 12 ++--
>  drivers/gpu/drm/i915/i915_irq.c| 27 
> ++
>  drivers/gpu/drm/i915/i915_perf.c   |  2 +-
>  4 files changed, 23 insertions(+), 20 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem

2020-12-18 Thread Robin Murphy


On 2020-12-18 14:33, Christian König wrote:

Am 18.12.20 um 15:17 schrieb Robin Murphy:

On 2020-12-17 14:02, Christian König wrote:

[SNIP]
Do you have some background why some ARM boards fail with that?

We had a couple of reports that memset/memcpy fail in userspace 
(usually system just spontaneously reboots or becomes unresponsive), 
but so far nobody could tell us why that happens?


Part of it is that Arm doesn't really have an ideal memory type for 
mapping RAM behind PCI (much like we also struggle with the vague 
expectations of what write-combine might mean beyond x86). Device 
memory can be relaxed to allow gathering, reordering and 
write-buffering, but is still a bit too restrictive in other ways - 
aligned, non-speculative, etc. - for something that's really just RAM 
and expected to be usable as such. Thus to map PCI memory as 
"write-combine" we use Normal non-cacheable, which means the CPU MMU 
is going to allow software to do all the things it might expect of 
RAM, but we're now at the mercy of the menagerie of interconnects and 
PCI implementations out there.


I see. As far as I know we already correctly map the RAM from the GPU as 
"write-combine".


Atomic operations, for example, *might* be resolved by the CPU 
coherency mechanism or in the interconnect, such that the PCI host 
bridge only sees regular loads and stores, but more often than not 
they'll just result in an atomic transaction going all the way to the 
host bridge. A super-duper-clever host bridge implementation might 
even support that, but the vast majority are likely to just reject it 
as invalid.


Support for atomics is actually specified by an PCIe extension. As far 
as I know that extension is even necessary for full KFD support on AMD 
and full Cuda support for NVidia GPUs.




Similarly, unaligned accesses, cache line fills/evictions, and such 
will often work, since they're essentially just larger read/write 
bursts, but some host bridges can be picky and might reject access 
sizes they don't like (there's at least one where even 64-bit accesses 
don't work. On a 64-bit system...)


This is breaking our neck here. We need 64bit writes on 64bit systems to 
end up as one 64bit write at the hardware and not two 32bit writes or 
otherwise the doorbells won't work correctly.


Just to clarify, that particular case *is* considered catastrophically 
broken ;)


In general you can assume that on AArch64, any aligned 64-bit load or 
store is atomic (64-bit accesses on 32-bit Arm are less well-defined, 
but hopefully nobody cares by now).


Larger writes are pretty much unproblematic, for P2P our bus interface 
even supports really large multi byte transfers.


If an invalid transaction does reach the host bridge, it's going to 
come back to the CPU as an external abort. If we're really lucky that 
could be taken synchronously, attributable to a specific instruction, 
and just oops/SIGBUS the relevant kernel/userspace thread. Often 
though, (particularly with big out-of-order CPUs) it's likely to be 
asynchronous and no longer attributable, and thus taken as an SError 
event, which in general roughly translates to "part of the SoC has 
fallen off". The only reasonable response we have to that is to panic 
the system.


Yeah, that sounds exactly like what we see on some of the ARM boards out 
there. At least we have an explanation for that behavior now.


Going to talk about this with our hardware engineers. We might be able 
to work around some of that stuff, but that is rather tricky to get 
working under those conditions.


Yeah, unfortunately there's no easy way to judge the quality of any 
given SoC's PCI implementation until you throw your required traffic at 
it and things either break or don't...


Cheers,
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/komeda: Fix bit check to import to value of proper type

2020-12-18 Thread carsten . haitzler

From: Carsten Haitzler 

KASAN found this problem. find_first_bit() expects to look at a
pointer pointing to a long, but we look at a u32 - this is going to be
an issue with endianess but, KSAN already flags this as out-of-bounds
stack reads. This fixes it by just importing inot a local long.

Signed-off-by: Carsten Haitzler 
---
 drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 452e505a1fd3..719a79728e24 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -137,9 +137,10 @@ komeda_pipeline_get_first_component(struct komeda_pipeline 
*pipe,
u32 comp_mask)
 {
struct komeda_component *c = NULL;
+   unsigned long comp_mask_local = (unsigned long)comp_mask;
int id;
 
-   id = find_first_bit((unsigned long *)_mask, 32);
+   id = find_first_bit(_mask_local, 32);
if (id < 32)
c = komeda_pipeline_get_component(pipe, id);
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next-fixes

2020-12-18 Thread Jani Nikula



Hi Dave & Daniel -

drm-intel-next-fixes-2020-12-18:
drm/i915 fixes for the merge window


BR,
Jani.

The following changes since commit efd3043790c6e92f0bbe1fe385db9b544131c59c:

  Merge tag 'amd-drm-fixes-5.11-2020-12-16' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-12-16 23:25:51 
+0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2020-12-18

for you to fetch changes up to 046f70d31ddb2069941aec54966fec5b7fbc7b7b:

  drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping (2020-12-18 
12:30:10 +0200)


drm/i915 fixes for the merge window


Aditya Swarup (1):
  drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping

Chris Wilson (2):
  Revert "drm/i915: re-order if/else ladder for hpd_irq_setup"
  drm/i915: Fix mismatch between misplaced vma check and vma insert

Lionel Landwerlin (1):
  drm/i915/perf: also include Gen11 in OATAILPTR workaround

 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 12 ++--
 drivers/gpu/drm/i915/i915_irq.c| 27 ++
 drivers/gpu/drm/i915/i915_perf.c   |  2 +-
 4 files changed, 23 insertions(+), 20 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/15] drm/vc4: hdmi: Restore cec physical address on reconnect

On Fri, 18 Dec 2020 at 14:21, Dave Stevenson
 wrote:
>
> Hi  Maxime & Dom
>
> On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
> >
> > From: Dom Cobley 
> >
> > Currently we call cec_phys_addr_invalidate on a hotplug deassert.
> > That may be due to a TV power cycling, or an AVR being switched
> > on (and switching edid).
> >
> > This makes CEC unusable since our controller wouldn't have a physical
> > address anymore.
> >
> > Set it back up again on the hotplug assert.
> >
> > Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
> > Signed-off-by: Dom Cobley 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> >  1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 28b78ea885ea..eff3bac562c6 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -136,20 +136,29 @@ static enum drm_connector_status
> >  vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> >  {
> > struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
> > +   bool connected = false;
> >
> > if (vc4_hdmi->hpd_gpio) {
> > if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
> > vc4_hdmi->hpd_active_low)
> > -   return connector_status_connected;
> > -   cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> > -   return connector_status_disconnected;
> > -   }
> > -
> > -   if (drm_probe_ddc(vc4_hdmi->ddc))
> > -   return connector_status_connected;
> > -
> > +   connected = true;
> > +   } else if (drm_probe_ddc(vc4_hdmi->ddc))
> > +   connected = true;
> > if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
>
> This needs to become an "else if(...".
> It used to be that all the other paths would return, so were mutually
> exclusive to this. Now they set a thing and keep going we need to
> avoid reading the register should there be a HPD gpio or the ddc probe
> succeeds.
> Memory says that otherwise Pi3 always reports connected.
>
> I fixed this in a downstream patch already -
> https://github.com/raspberrypi/linux/commit/d345caec1e9b2317b9cd7eb5b92ae453a0d3e98c
>
> Otherwise fine.
>
>   Dave
>
> > +   connected = true;
> > +   if (connected) {
> > +   if (connector->status != connector_status_connected) {
> > +   struct edid *edid = drm_get_edid(connector, 
> > vc4_hdmi->ddc);
> > +
> > +   if (edid) {
> > +   
> > cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap, edid);
> > +   vc4_hdmi->encoder.hdmi_monitor = 
> > drm_detect_hdmi_monitor(edid);
> > +   
> > drm_connector_update_edid_property(connector, edid);

Actually looking at this again in the context of the other changes, do
we need to call drm_connector_update_edid_property() here?

We've just called drm_get_edid() to get the edid, and that calls
drm_connector_update_edid_property() as well [1]
Updating vc4_hdmi->encoder.hdmi_monitor may be necessary. It's
otherwise done in vc4_hdmi_connector_get_modes, which I sort of expect
to be called almost immediately by the framework when connector_detect
returns "connected". I haven't checked if that is guaranteed though.

vc4_hdmi_connector_get_modes also includes a manual call to
drm_connector_update_edid_property after having just called
drm_get_edid, so that one feels redundant too.

  Dave

[1] 
https://elixir.bootlin.com/linux/v5.10/source/drivers/gpu/drm/drm_edid.c#L2059

> > +   kfree(edid);
> > +   }
> > +   }
> > return connector_status_connected;
> > +   }
> > cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> > return connector_status_disconnected;
> >  }
> > --
> > 2.28.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem

2020-12-18 Thread Robin Murphy

On 2020-12-18 06:14, Chen Li wrote:
[...]

No, not performance. See standards like OpenGL, Vulkan as well as VA-API and
VDPAU require that you can mmap() device memory and execute memset/memcpy on
the memory from userspace.

If your ARM base board can't do that for some then you can't use the hardware
with that board.

If the VRAM lives in a prefetchable PCI bar then on most sane Arm-based systems
I believe it should be able to mmap() to userspace with the Normal memory type,
where unaligned accesses and such are allowed, as opposed to the Device memory
type intended for MMIO mappings, which has more restrictions but stricter
ordering guarantees.

Hi, Robin. I cannot understand it allow unaligned accesses. prefetchable PCI bar should also be mmio, and accesses will end with device memory, so why does this allow unaligned access?

Because even Device-GRE is a bit too restrictive to expose to userspace
that's likely to expect it to behave as regular memory, so, for better
or worse, we use MT_NORMAL_MC for pgrprot_writecombine().

Regardless of what happens elsewhere though, if something is mapped *into the
kernel* with ioremap(), then it is fundamentally wrong per the kernel memory
model to reference that mapping directly without using I/O accessors. That is
not specific to any individual architecture, and Sparse should be screaming
about it already. I guess in this case the UVD code needs to pay more attention
to whether radeon_bo_kmap() ends up going via ttm_bo_ioremap() or not.

(I'm assuming the initial fault was memset() with 0 trying to perform "DC ZVA"
on a Device-type mapping from ioremap() - FYI a stacktrace on its own without
the rest of the error dump showing what actually triggered it isn't overly
useful)

Robin.

why it may be 'DC ZVA'? I'm not sure the pc in initial kernel fault memset, but
I capture the userspace crash pc: stp(128bit) or str with neon(also 128bit) to
render node(/dev/dri/renderD128).

As I said it was an assumption. I guessed at it being more likely to be
an MMU fault than an external abort, and given the size and the fact
that it's a variable initialisation guessed at it being slightly more
likely to hit the ZVA special-case rather than being unaligned. Looking
again, I guess starting at an odd-numbered 32-bit element might lead to
an unaligned store of XZR, but either way it doesn't really matter -
what it showed is it clearly *could* be an MMU fault because TTM seems
to be a bit careless with iomem pointers.

That said, if you're also getting external aborts from your host bridge
not liking 128-bit transactions, then as Christian says you're probably
going to have a bad time on this platform either way.

Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 2/3] dma-buf: system_heap: Add pagepool support to system heap

On Thu, Dec 17, 2020 at 11:06:11PM +, John Stultz wrote:
> Reuse/abuse the pagepool code from the network code to speed
> up allocation performance.
> 
> This is similar to the ION pagepool usage, but tries to
> utilize generic code instead of a custom implementation.
> 
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Chris Goldsworthy 
> Cc: Laura Abbott 
> Cc: Brian Starkey 
> Cc: Hridya Valsaraju 
> Cc: Suren Baghdasaryan 
> Cc: Sandeep Patil 
> Cc: Daniel Mentz 
> Cc: Ørjan Eide 
> Cc: Robin Murphy 
> Cc: Ezequiel Garcia 
> Cc: Simon Ser 
> Cc: James Jones 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz 

We also have one of these in ttm. I think we should have at most one of
these for the gpu ecosystem overall, maybe as a helper that can be plugged
into all the places.

Or I'm kinda missing something, which could be since I only glanced at
yours for a bit. But it's also called page pool for buffer allocations,
and I don't think there's that many ways to implement that really :-)
-Daniel

> ---
>  drivers/dma-buf/heaps/Kconfig   |  1 +
>  drivers/dma-buf/heaps/system_heap.c | 68 +++--
>  2 files changed, 65 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index ecf65204f714..fa5e1c330cce 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -4,6 +4,7 @@ config DMABUF_HEAPS_DEFERRED_FREE
>  config DMABUF_HEAPS_SYSTEM
>   bool "DMA-BUF System Heap"
>   depends on DMABUF_HEAPS
> + select PAGE_POOL
>   help
> Choose this option to enable the system dmabuf heap. The system heap
> is backed by pages from the buddy allocator. If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/system_heap.c 
> b/drivers/dma-buf/heaps/system_heap.c
> index 17e0e9a68baf..885e30894b77 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static struct dma_heap *sys_heap;
>  
> @@ -53,6 +54,7 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, 
> LOW_ORDER_GFP, LOW_ORDER_GFP};
>   */
>  static const unsigned int orders[] = {8, 4, 0};
>  #define NUM_ORDERS ARRAY_SIZE(orders)
> +struct page_pool *pools[NUM_ORDERS];
>  
>  static struct sg_table *dup_sg_table(struct sg_table *table)
>  {
> @@ -281,18 +283,59 @@ static void system_heap_vunmap(struct dma_buf *dmabuf, 
> struct dma_buf_map *map)
>   dma_buf_map_clear(map);
>  }
>  
> +static int system_heap_clear_pages(struct page **pages, int num, pgprot_t 
> pgprot)
> +{
> + void *addr = vmap(pages, num, VM_MAP, pgprot);
> +
> + if (!addr)
> + return -ENOMEM;
> + memset(addr, 0, PAGE_SIZE * num);
> + vunmap(addr);
> + return 0;
> +}
> +
> +static int system_heap_zero_buffer(struct system_heap_buffer *buffer)
> +{
> + struct sg_table *sgt = >sg_table;
> + struct sg_page_iter piter;
> + struct page *pages[32];
> + int p = 0;
> + int ret = 0;
> +
> + for_each_sgtable_page(sgt, , 0) {
> + pages[p++] = sg_page_iter_page();
> + if (p == ARRAY_SIZE(pages)) {
> + ret = system_heap_clear_pages(pages, p, PAGE_KERNEL);
> + if (ret)
> + return ret;
> + p = 0;
> + }
> + }
> + if (p)
> + ret = system_heap_clear_pages(pages, p, PAGE_KERNEL);
> +
> + return ret;
> +}
> +
>  static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
>  {
>   struct system_heap_buffer *buffer = dmabuf->priv;
>   struct sg_table *table;
>   struct scatterlist *sg;
> - int i;
> + int i, j;
> +
> + /* Zero the buffer pages before adding back to the pool */
> + system_heap_zero_buffer(buffer);
>  
>   table = >sg_table;
>   for_each_sg(table->sgl, sg, table->nents, i) {
>   struct page *page = sg_page(sg);
>  
> - __free_pages(page, compound_order(page));
> + for (j = 0; j < NUM_ORDERS; j++) {
> + if (compound_order(page) == orders[j])
> + break;
> + }
> + page_pool_put_full_page(pools[j], page, false);
>   }
>   sg_free_table(table);
>   kfree(buffer);
> @@ -322,8 +365,7 @@ static struct page *alloc_largest_available(unsigned long 
> size,
>   continue;
>   if (max_order < orders[i])
>   continue;
> -
> - page = alloc_pages(order_flags[i], orders[i]);
> + page = page_pool_alloc_pages(pools[i], order_flags[i]);
>   if (!page)
>   continue;
>   return page;
> @@ -428,6 +470,24 @@ static const struct dma_heap_ops system_heap_ops = {
>  static int system_heap_create(void)
>  {
>   struct dma_heap_export_info

Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem


Am 18.12.20 um 15:17 schrieb Robin Murphy:

On 2020-12-17 14:02, Christian König wrote:

[SNIP]
Do you have some background why some ARM boards fail with that?

We had a couple of reports that memset/memcpy fail in userspace 
(usually system just spontaneously reboots or becomes unresponsive), 
but so far nobody could tell us why that happens?


Part of it is that Arm doesn't really have an ideal memory type for 
mapping RAM behind PCI (much like we also struggle with the vague 
expectations of what write-combine might mean beyond x86). Device 
memory can be relaxed to allow gathering, reordering and 
write-buffering, but is still a bit too restrictive in other ways - 
aligned, non-speculative, etc. - for something that's really just RAM 
and expected to be usable as such. Thus to map PCI memory as 
"write-combine" we use Normal non-cacheable, which means the CPU MMU 
is going to allow software to do all the things it might expect of 
RAM, but we're now at the mercy of the menagerie of interconnects and 
PCI implementations out there.


I see. As far as I know we already correctly map the RAM from the GPU as 
"write-combine".


Atomic operations, for example, *might* be resolved by the CPU 
coherency mechanism or in the interconnect, such that the PCI host 
bridge only sees regular loads and stores, but more often than not 
they'll just result in an atomic transaction going all the way to the 
host bridge. A super-duper-clever host bridge implementation might 
even support that, but the vast majority are likely to just reject it 
as invalid.


Support for atomics is actually specified by an PCIe extension. As far 
as I know that extension is even necessary for full KFD support on AMD 
and full Cuda support for NVidia GPUs.




Similarly, unaligned accesses, cache line fills/evictions, and such 
will often work, since they're essentially just larger read/write 
bursts, but some host bridges can be picky and might reject access 
sizes they don't like (there's at least one where even 64-bit accesses 
don't work. On a 64-bit system...)


This is breaking our neck here. We need 64bit writes on 64bit systems to 
end up as one 64bit write at the hardware and not two 32bit writes or 
otherwise the doorbells won't work correctly.


Larger writes are pretty much unproblematic, for P2P our bus interface 
even supports really large multi byte transfers.


If an invalid transaction does reach the host bridge, it's going to 
come back to the CPU as an external abort. If we're really lucky that 
could be taken synchronously, attributable to a specific instruction, 
and just oops/SIGBUS the relevant kernel/userspace thread. Often 
though, (particularly with big out-of-order CPUs) it's likely to be 
asynchronous and no longer attributable, and thus taken as an SError 
event, which in general roughly translates to "part of the SoC has 
fallen off". The only reasonable response we have to that is to panic 
the system.


Yeah, that sounds exactly like what we see on some of the ARM boards out 
there. At least we have an explanation for that behavior now.


Going to talk about this with our hardware engineers. We might be able 
to work around some of that stuff, but that is rather tricky to get 
working under those conditions.


Thanks,
Christian.




Robin.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use

On Thu, Dec 17, 2020 at 04:06:38PM -0500, Andrey Grodzovsky wrote:
> 
> On 12/17/20 3:48 PM, Daniel Vetter wrote:
> > On Thu, Dec 17, 2020 at 9:38 PM Andrey Grodzovsky
> >  wrote:
> > > 
> > > On 12/17/20 3:10 PM, Christian König wrote:
> > > > [SNIP]
> > > > > > > By eliminating such users, and replacing them with local maps 
> > > > > > > which
> > > > > > > > are strictly bound in how long they can exist (and hence we can
> > > > > > > > serialize against them finishing in our hotunplug code).
> > > > > > > Not sure I see how serializing against BO map/unmap helps - our 
> > > > > > > problem as
> > > > > > > you described is that once
> > > > > > > device is extracted and then something else quickly takes it's 
> > > > > > > place in the
> > > > > > > PCI topology
> > > > > > > and gets assigned same physical IO ranges, then our driver will 
> > > > > > > start
> > > > > > > accessing this
> > > > > > > new device because our 'zombie' BOs are still pointing to those 
> > > > > > > ranges.
> > > > > > Until your driver's remove callback is finished the ranges stay 
> > > > > > reserved.
> > > > > 
> > > > > The ranges stay reserved until unmapped which happens in bo->destroy
> > > > I'm not sure of that. Why do you think that?
> > > 
> > > Because of this sequence
> > > ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap->...->iounmap
> > > Is there another place I am missing ?
> > iounmap is just the mapping, it doesn't reserve anything in the resource 
> > tree.
> > 
> > And I don't think we should keep resources reserved past the pci
> > remove callback, because that would upset the pci subsystem trying to
> > assign resources to a newly hotplugged pci device.
> 
> 
> I assumed we are talking about VA ranges still mapped in the page table. I
> just assumed
> that part of ioremap is also reservation of the mapped physical ranges. In
> fact, if we
> do can explicitly reserve those ranges (as you mention here) then together
> with postponing
> system memory pages freeing/releasing back to the page pool until after BO
> is unmapped
> from the kernel address space I believe this could solve the issue of quick
> HW reinsertion
> and make all the drm_dev_ener/exit guarding obsolete.

We can't reserve these ranges, that's what I tried to explaine:
- kernel/resource.c isn't very consistently used
- the pci core will get pissed if there's suddenly a range in the middle
  of a bridge that it can't use
- nesting is allowed for resources, so this doesn't actually garuantee
  much

I just wanted to point out that ioremap does do any reserving, so not
enough by far.

We really have to stop using any mmio ranges before the pci remove
callback is finished.
-Daniel

> 
> Andrey
> 
> 
> > Also from a quick check amdgpu does not reserve the pci bars it's
> > using. Somehow most drm drivers don't do that, not exactly sure why,
> > maybe auto-enumeration of resources just works too good and we don't
> > need the safety net of kernel/resource.c anymore.
> > -Daniel
> > 
> > 
> > > > > which for most internally allocated buffers is during sw_fini when 
> > > > > last drm_put
> > > > > is called.
> > > > > 
> > > > > 
> > > > > > If that's not the case, then hotunplug would be fundamentally 
> > > > > > impossible
> > > > > > ot handle correctly.
> > > > > > 
> > > > > > Of course all the mmio actions will time out, so it might take some 
> > > > > > time
> > > > > > to get through it all.
> > > > > 
> > > > > I found that PCI code provides pci_device_is_present function
> > > > > we can use to avoid timeouts - it reads device vendor and checks if 
> > > > > all 1s is
> > > > > returned
> > > > > or not. We can call it from within register accessors before trying 
> > > > > read/write
> > > > That's way to much overhead! We need to keep that much lower or it will 
> > > > result
> > > > in quite a performance drop.
> > > > 
> > > > I suggest to rather think about adding drm_dev_enter/exit guards.
> > > 
> > > Sure, this one is just a bit upstream to the disconnect event. Eventually 
> > > none
> > > of them is watertight.
> > > 
> > > Andrey
> > > 
> > > 
> > > > Christian.
> > > > 
> > > > > > > Another point regarding serializing - problem  is that some of 
> > > > > > > those BOs are
> > > > > > > very long lived, take for example the HW command
> > > > > > > ring buffer Christian mentioned before -
> > > > > > > (amdgpu_ring_init->amdgpu_bo_create_kernel), it's life span
> > > > > > > is basically for the entire time the device exists, it's 
> > > > > > > destroyed only in
> > > > > > > the SW fini stage (when last drm_dev
> > > > > > > reference is dropped) and so should I grab it's dma_resv_lock from
> > > > > > > amdgpu_pci_remove code and wait
> > > > > > > for it to be unmapped before proceeding with the PCI remove code 
> > > > > > > ? This can
> > > > > > > take unbound time and that why I don't understand
> > > > > > > how serializing will help.
> > > > > > Uh you need to untangle that. After hw cleanup

Re: [PATCH 11/15] drm/vc4: hdmi: Remove cec_available flag

Hi Dom & Maxime

On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> Now that our HDMI controller supports CEC for the BCM2711, let's remove
> that flag.
>
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 4 
>  drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ---
>  2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index d208b7d1d937..327638d93032 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1658,9 +1658,6 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> u32 value;
> int ret;
>
> -   if (!vc4_hdmi->variant->cec_available)
> -   return 0;
> -
> vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
>   vc4_hdmi, "vc4",
>   CEC_CAP_DEFAULTS |
> @@ -2074,7 +2071,6 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
> .debugfs_name   = "hdmi_regs",
> .card_name  = "vc4-hdmi",
> .max_pixel_clock= 16200,
> -   .cec_available  = true,
> .registers  = vc4_hdmi_fields,
> .num_registers  = ARRAY_SIZE(vc4_hdmi_fields),
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 27352827f70c..c93ada62f429 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -42,9 +42,6 @@ struct vc4_hdmi_variant {
> /* Filename to expose the registers in debugfs */
> const char *debugfs_name;
>
> -   /* Set to true when the CEC support is available */
> -   bool cec_available;
> -
> /* Maximum pixel clock supported by the controller (in Hz) */
> unsigned long long max_pixel_clock;
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/15] drm/vc4: hdmi: Don't register the CEC adapter if there's no interrupts

On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
>
> We introduced the BCM2711 support to the vc4 HDMI controller with 5.10,
> but this was lacking any of the interrupts of the CEC controller so we
> have to deal with the backward compatibility.
>
> Do so by simply ignoring the CEC setup if the DT doesn't have the
> interrupts property.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 327638d93032..69217c68d3a4 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1655,9 +1655,15 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
>  {
> struct cec_connector_info conn_info;
> struct platform_device *pdev = vc4_hdmi->pdev;
> +   struct device *dev = >dev;
> u32 value;
> int ret;
>
> +   if (!of_find_property(dev->of_node, "interrupts", NULL)) {
> +   dev_warn(dev, "'interrupts' DT property is missing, no 
> CEC\n");
> +   return 0;
> +   }
> +
> vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
>   vc4_hdmi, "vc4",
>   CEC_CAP_DEFAULTS |
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/15] drm/vc4: hdmi: Update the CEC clock divider on HSM rate change

Hi Maxime

On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
>
> As part of the enable sequence we might change the HSM clock rate if the
> pixel rate is different than the one we were already dealing with.
>
> On the BCM2835 however, the CEC clock derives from the HSM clock so any
> rate change will need to be reflected in the CEC clock divider to output
> 40kHz.
>
> Fixes: cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel 
> rate")
> Signed-off-by: Maxime Ripard 

I thought we'd got a duplicate patch here, but it's moving code that
was changed in patch 6/15 so it can be called from
vc4_hdmi_encoder_pre_crtc_configure too. Good for confusing me!

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 39 +-
>  1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 0c53d7427d15..b93ee3e26e2b 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -132,6 +132,27 @@ static void vc5_hdmi_reset(struct vc4_hdmi *vc4_hdmi)
>HDMI_READ(HDMI_CLOCK_STOP) | VC4_DVP_HT_CLOCK_STOP_PIXEL);
>  }
>
> +#ifdef CONFIG_DRM_VC4_HDMI_CEC
> +static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi *vc4_hdmi)
> +{
> +   u16 clk_cnt;
> +   u32 value;
> +
> +   value = HDMI_READ(HDMI_CEC_CNTRL_1);
> +   value &= ~VC4_HDMI_CEC_DIV_CLK_CNT_MASK;
> +
> +   /*
> +* Set the clock divider: the hsm_clock rate and this divider
> +* setting will give a 40 kHz CEC clock.
> +*/
> +   clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> +   value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> +   HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> +}
> +#else
> +static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi *vc4_hdmi) {}
> +#endif
> +
>  static enum drm_connector_status
>  vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
>  {
> @@ -761,6 +782,8 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
> drm_encoder *encoder,
> return;
> }
>
> +   vc4_hdmi_cec_update_clk_div(vc4_hdmi);
> +
> /*
>  * FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
>  * at 300MHz.
> @@ -1586,7 +1609,6 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
>  {
> struct cec_connector_info conn_info;
> struct platform_device *pdev = vc4_hdmi->pdev;
> -   u16 clk_cnt;
> u32 value;
> int ret;
>
> @@ -1605,17 +1627,14 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi 
> *vc4_hdmi)
> cec_s_conn_info(vc4_hdmi->cec_adap, _info);
>
> HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, 0x);
> +
> value = HDMI_READ(HDMI_CEC_CNTRL_1);
> -   value &= ~VC4_HDMI_CEC_DIV_CLK_CNT_MASK;
> -   /*
> -* Set the logical address to Unregistered and set the clock
> -* divider: the hsm_clock rate and this divider setting will
> -* give a 40 kHz CEC clock.
> -*/
> -   clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> -   value |= VC4_HDMI_CEC_ADDR_MASK |
> -(clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> +   /* Set the logical address to Unregistered */
> +   value |= VC4_HDMI_CEC_ADDR_MASK;
> HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> +
> +   vc4_hdmi_cec_update_clk_div(vc4_hdmi);
> +
> ret = devm_request_threaded_irq(>dev, platform_get_irq(pdev, 0),
> vc4_cec_irq_handler,
> vc4_cec_irq_handler_thread, 0,
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/15] drm/vc4: hdmi: Restore cec physical address on reconnect

Hi  Maxime & Dom

On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> Currently we call cec_phys_addr_invalidate on a hotplug deassert.
> That may be due to a TV power cycling, or an AVR being switched
> on (and switching edid).
>
> This makes CEC unusable since our controller wouldn't have a physical
> address anymore.
>
> Set it back up again on the hotplug assert.
>
> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 28b78ea885ea..eff3bac562c6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -136,20 +136,29 @@ static enum drm_connector_status
>  vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
>  {
> struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
> +   bool connected = false;
>
> if (vc4_hdmi->hpd_gpio) {
> if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
> vc4_hdmi->hpd_active_low)
> -   return connector_status_connected;
> -   cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> -   return connector_status_disconnected;
> -   }
> -
> -   if (drm_probe_ddc(vc4_hdmi->ddc))
> -   return connector_status_connected;
> -
> +   connected = true;
> +   } else if (drm_probe_ddc(vc4_hdmi->ddc))
> +   connected = true;
> if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)

This needs to become an "else if(...".
It used to be that all the other paths would return, so were mutually
exclusive to this. Now they set a thing and keep going we need to
avoid reading the register should there be a HPD gpio or the ddc probe
succeeds.
Memory says that otherwise Pi3 always reports connected.

I fixed this in a downstream patch already -
https://github.com/raspberrypi/linux/commit/d345caec1e9b2317b9cd7eb5b92ae453a0d3e98c

Otherwise fine.

  Dave

> +   connected = true;
> +   if (connected) {
> +   if (connector->status != connector_status_connected) {
> +   struct edid *edid = drm_get_edid(connector, 
> vc4_hdmi->ddc);
> +
> +   if (edid) {
> +   cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap, 
> edid);
> +   vc4_hdmi->encoder.hdmi_monitor = 
> drm_detect_hdmi_monitor(edid);
> +   drm_connector_update_edid_property(connector, 
> edid);
> +   kfree(edid);
> +   }
> +   }
> return connector_status_connected;
> +   }
> cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> return connector_status_disconnected;
>  }
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem

2020-12-18 Thread Robin Murphy

On 2020-12-17 14:02, Christian König wrote:

Am 17.12.20 um 14:45 schrieb Robin Murphy:

On 2020-12-17 10:25, Christian König wrote:

Am 17.12.20 um 02:07 schrieb Chen Li:

On Wed, 16 Dec 2020 22:19:11 +0800,
Christian König wrote:

Am 16.12.20 um 14:48 schrieb Chen Li:

On Wed, 16 Dec 2020 15:59:37 +0800,
Christian König wrote:

[SNIP]
Hi, Christian. I'm not sure why this change is a hack here. I
cannot see the problem and wll be grateful if you give more
explainations.
__memset is supposed to work on those addresses, otherwise you
can't use the

e8860 on your arm64 system.
If __memset is supposed to work on those adresses, why this
commit(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2Fba0b2275a6781b2f3919d931d63329b5548f6d5fdata=04%7C01%7Cchristian.koenig%40amd.com%7C3551ae4972b044bb831608d8a291f81c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637438095114292394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xns81uCGfN1tjsVn5LBU8QhmUinZRJQlXz8w%2FJ7%2FGTM%3Dreserved=0)
is needed? (I also notice drm/radeon didn't take this change though)
just out of curiosity.

We generally accept those patches as cleanup in the kernel with the
hope that we can find a way to work around the userspace restrictions.

But when you also have this issue in userspace then there isn't much
we can do for you.

Replacing the the direct write in the kernel with calls to writel() or
memset_io() will fix that temporary, but you have a more general
problem here.
I cannot see what's the more general problem here :( u mean
performance?

No, not performance. See standards like OpenGL, Vulkan as well as
VA-API and VDPAU require that you can mmap() device memory and
execute memset/memcpy on the memory from userspace.

If your ARM base board can't do that for some then you can't use the
hardware with that board.

If the VRAM lives in a prefetchable PCI bar then on most sane
Arm-based systems I believe it should be able to mmap() to userspace
with the Normal memory type, where unaligned accesses and such are
allowed, as opposed to the Device memory type intended for MMIO
mappings, which has more restrictions but stricter ordering guarantees.

Do you have some background why some ARM boards fail with that?

We had a couple of reports that memset/memcpy fail in userspace (usually
system just spontaneously reboots or becomes unresponsive), but so far
nobody could tell us why that happens?

Part of it is that Arm doesn't really have an ideal memory type for
mapping RAM behind PCI (much like we also struggle with the vague
expectations of what write-combine might mean beyond x86). Device memory
can be relaxed to allow gathering, reordering and write-buffering, but
is still a bit too restrictive in other ways - aligned, non-speculative,
etc. - for something that's really just RAM and expected to be usable as
such. Thus to map PCI memory as "write-combine" we use Normal
non-cacheable, which means the CPU MMU is going to allow software to do
all the things it might expect of RAM, but we're now at the mercy of the
menagerie of interconnects and PCI implementations out there.

Atomic operations, for example, *might* be resolved by the CPU coherency
mechanism or in the interconnect, such that the PCI host bridge only
sees regular loads and stores, but more often than not they'll just
result in an atomic transaction going all the way to the host bridge. A
super-duper-clever host bridge implementation might even support that,
but the vast majority are likely to just reject it as invalid.

Similarly, unaligned accesses, cache line fills/evictions, and such will
often work, since they're essentially just larger read/write bursts, but
some host bridges can be picky and might reject access sizes they don't
like (there's at least one where even 64-bit accesses don't work. On a
64-bit system...)

If an invalid transaction does reach the host bridge, it's going to come
back to the CPU as an external abort. If we're really lucky that could
be taken synchronously, attributable to a specific instruction, and just
oops/SIGBUS the relevant kernel/userspace thread. Often though,
(particularly with big out-of-order CPUs) it's likely to be asynchronous
and no longer attributable, and thus taken as an SError event, which in
general roughly translates to "part of the SoC has fallen off". The only
reasonable response we have to that is to panic the system.

Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix multihop when move doesn't work.

On Thu, Dec 17, 2020 at 09:29:03PM +0100, Daniel Vetter wrote:
> On Fri, Dec 18, 2020 at 06:09:43AM +1000, Dave Airlie wrote:
> > From: Dave Airlie 
> > 
> > As per the radeon/amdgpu fix don't use multihop is hw moves
> > aren't enabled.
> > 
> > Reported-by: Mike Galbraith 
> > Tested-by: Mike Galbraith 
> > Fixes: 0c8c0659d74 ("drm/nouveau/ttm: use multihop")

Also fixed the Fixes: line here, it was pointing at something else (old
rebased version from your own tree maybe?).
-Daniel

> > Signed-off-by: Dave Airlie 
> 
> Pulled to drm-next directly, will go out to Linus tomorrow.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 31 ++--
> >  1 file changed, 16 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 1386b0fc1640..c85b1af06b7b 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -942,16 +942,6 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> > evict,
> > struct nouveau_drm_tile *new_tile = NULL;
> > int ret = 0;
> >  
> > -   if ((old_reg->mem_type == TTM_PL_SYSTEM &&
> > -new_reg->mem_type == TTM_PL_VRAM) ||
> > -   (old_reg->mem_type == TTM_PL_VRAM &&
> > -new_reg->mem_type == TTM_PL_SYSTEM)) {
> > -   hop->fpfn = 0;
> > -   hop->lpfn = 0;
> > -   hop->mem_type = TTM_PL_TT;
> > -   hop->flags = 0;
> > -   return -EMULTIHOP;
> > -   }
> >  
> > if (new_reg->mem_type == TTM_PL_TT) {
> > ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, new_reg);
> > @@ -995,14 +985,25 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> > evict,
> >  
> > /* Hardware assisted copy. */
> > if (drm->ttm.move) {
> > +   if ((old_reg->mem_type == TTM_PL_SYSTEM &&
> > +new_reg->mem_type == TTM_PL_VRAM) ||
> > +   (old_reg->mem_type == TTM_PL_VRAM &&
> > +new_reg->mem_type == TTM_PL_SYSTEM)) {
> > +   hop->fpfn = 0;
> > +   hop->lpfn = 0;
> > +   hop->mem_type = TTM_PL_TT;
> > +   hop->flags = 0;
> > +   return -EMULTIHOP;
> > +   }
> > ret = nouveau_bo_move_m2mf(bo, evict, ctx,
> >new_reg);
> > -   if (!ret)
> > -   goto out;
> > -   }
> > +   } else
> > +   ret = -ENODEV;
> >  
> > -   /* Fallback to software copy. */
> > -   ret = ttm_bo_move_memcpy(bo, ctx, new_reg);
> > +   if (ret) {
> > +   /* Fallback to software copy. */
> > +   ret = ttm_bo_move_memcpy(bo, ctx, new_reg);
> > +   }
> >  
> >  out:
> > if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA) {
> > -- 
> > 2.27.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/qxl: don't allocate a dma_address array

On Fri, Dec 18, 2020 at 02:42:43PM +0100, Christian König wrote:
> That seems to be unused.
> 
> Signed-off-by: Christian König 
> Reviewed-by: David Airlie 

Dave asked me to pull this into drm-next directly, so I've done that.

For next time around please reference the bug reporter and credit them
properly. I've fixed that up while applying.

Cheers, Daniel

> ---
>  drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index d8ecfb8b3193..66640f4947bd 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -116,7 +116,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct 
> ttm_buffer_object *bo,
>   ttm = kzalloc(sizeof(struct ttm_tt), GFP_KERNEL);
>   if (ttm == NULL)
>   return NULL;
> - if (ttm_dma_tt_init(ttm, bo, page_flags, ttm_cached)) {
> + if (ttm_tt_init(ttm, bo, page_flags, ttm_cached)) {
>   kfree(ttm);
>   return NULL;
>   }
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/qxl: don't allocate a dma_address array

That seems to be unused.

Signed-off-by: Christian König 
Reviewed-by: David Airlie 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index d8ecfb8b3193..66640f4947bd 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -116,7 +116,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct 
ttm_buffer_object *bo,
ttm = kzalloc(sizeof(struct ttm_tt), GFP_KERNEL);
if (ttm == NULL)
return NULL;
-   if (ttm_dma_tt_init(ttm, bo, page_flags, ttm_cached)) {
+   if (ttm_tt_init(ttm, bo, page_flags, ttm_cached)) {
kfree(ttm);
return NULL;
}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] dt-bindings: display: bridge: tc358768: Change maintainer information

2020-12-18 Thread Peter Ujfalusi

My employment with TI is coming to an end and I will not have access to
the board where this bridge is connected to and I will also loose access to
the manual of the chip.

Add the missing copyright information, author and change the maintainer to
Sam Ravnborg (thank you for volenteering!)

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml  | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
index c036a75db8f7..c08fd42be2d0 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated
+# Author: Peter Ujfalusi 
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
 
 maintainers:
-  - Peter Ujfalusi 
+  - Sam Ravnborg 
 
 description: |
   The TC358768/TC358778 is bridge device which converts RGB to DSI.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/15] drm/vc4: hdmi: Introduce a CEC clock

On Fri, 18 Dec 2020 at 12:23, Maxime Ripard  wrote:
>
> Hi Dave,
>
> On Fri, Dec 18, 2020 at 11:37:50AM +, Dave Stevenson wrote:
> > Hi Maxime
> >
> > On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
> > >
> > > While the BCM2835 had the CEC clock derived from the HSM clock, the
> > > BCM2711 has a dedicated parent clock for it.
> > >
> > > Let's introduce a separate clock for it so that we can handle both
> > > cases.
> > >
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  drivers/gpu/drm/vc4/vc4_hdmi.c | 9 -
> > >  drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> > >  2 files changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c 
> > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > index b93ee3e26e2b..0debd22bc992 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > @@ -145,7 +145,7 @@ static void vc4_hdmi_cec_update_clk_div(struct 
> > > vc4_hdmi *vc4_hdmi)
> > >  * Set the clock divider: the hsm_clock rate and this divider
> > >  * setting will give a 40 kHz CEC clock.
> > >  */
> > > -   clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> > > +   clk_cnt = clk_get_rate(vc4_hdmi->cec_clock) / CEC_CLOCK_FREQ;
> > > value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> > > HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> > >  }
> > > @@ -1740,6 +1740,7 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi 
> > > *vc4_hdmi)
> > > return PTR_ERR(vc4_hdmi->hsm_clock);
> > > }
> > > vc4_hdmi->audio_clock = vc4_hdmi->hsm_clock;
> > > +   vc4_hdmi->cec_clock = vc4_hdmi->hsm_clock;
> > >
> > > return 0;
> > >  }
> > > @@ -1833,6 +1834,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
> > > *vc4_hdmi)
> > > return PTR_ERR(vc4_hdmi->audio_clock);
> > > }
> > >
> > > +   vc4_hdmi->cec_clock = devm_clk_get(dev, "cec");
> > > +   if (IS_ERR(vc4_hdmi->cec_clock)) {
> > > +   DRM_ERROR("Failed to get CEC clock\n");
> > > +   return PTR_ERR(vc4_hdmi->cec_clock);
> > > +   }
> >
> > Aren't we adding to the DT binding here and breaking backwards 
> > compatibility?
> > Admittedly CEC didn't work before (and was masked out) for vc5, but do
> > we need to worry about those with existing DT files that currently
> > work happily?
>
> The DT compatibility is not a worry here: I made sure the CEC clock and
> range were part of the binding since it's been introduced:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e3725b05b785e73482a194b99bff3d5a1c85140
>
> So we were not using it so far, but it was in the DT all along

I guess I should have read it then :-)
In which case
Reviewed-by: Dave Stevenson 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

2020-12-18 Thread Peter Ujfalusi

Hi Sam,

On 17/12/2020 19.25, Sam Ravnborg wrote:
>>> dtschema/dtc warnings/errors:
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>>>  'maintainers' is a required property
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>>>  ignoring, error in schema: 
>>> warning: no schema found in file: 
>>> ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>>
>> Right, so it is not that easy to not been able to maintain this... :o
>>
>> Who should be documented as maintainer?
>> Andrzej, Neil, David or Daniel?
> 
> I have no problem being listed as maintainer despite my very limited
> knowledge on the HW. So unless you end up volunteering then just
> add me.

thank you. it is not easy to give up on something one has spent time on,
but without the hardware and manual it would be not right to just move
it to my private email as I did for the DMA and Audio drivers:

https://lore.kernel.org/lkml/20201215130512.8753-1-peter.ujfal...@ti.com/

https://lore.kernel.org/lkml/20201215131348.11282-1-peter.ujfal...@ti.com/

I'll send v2 as may last patch from ti.com

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/15] drm/vc4: hdmi: Introduce a CEC clock

Hi Maxime

On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
>
> While the BCM2835 had the CEC clock derived from the HSM clock, the
> BCM2711 has a dedicated parent clock for it.
>
> Let's introduce a separate clock for it so that we can handle both
> cases.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 9 -
>  drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index b93ee3e26e2b..0debd22bc992 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -145,7 +145,7 @@ static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi 
> *vc4_hdmi)
>  * Set the clock divider: the hsm_clock rate and this divider
>  * setting will give a 40 kHz CEC clock.
>  */
> -   clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> +   clk_cnt = clk_get_rate(vc4_hdmi->cec_clock) / CEC_CLOCK_FREQ;
> value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
>  }
> @@ -1740,6 +1740,7 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi 
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->hsm_clock);
> }
> vc4_hdmi->audio_clock = vc4_hdmi->hsm_clock;
> +   vc4_hdmi->cec_clock = vc4_hdmi->hsm_clock;
>
> return 0;
>  }
> @@ -1833,6 +1834,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->audio_clock);
> }
>
> +   vc4_hdmi->cec_clock = devm_clk_get(dev, "cec");
> +   if (IS_ERR(vc4_hdmi->cec_clock)) {
> +   DRM_ERROR("Failed to get CEC clock\n");
> +   return PTR_ERR(vc4_hdmi->cec_clock);
> +   }

Aren't we adding to the DT binding here and breaking backwards compatibility?
Admittedly CEC didn't work before (and was masked out) for vc5, but do
we need to worry about those with existing DT files that currently
work happily?

Otherwise I'm happy with the patch.

  Dave

> +
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(vc4_hdmi->reset)) {
> DRM_ERROR("Failed to get HDMI reset line\n");
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 720914761261..adc4bf33ff15 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -155,6 +155,7 @@ struct vc4_hdmi {
> bool cec_tx_ok;
> bool cec_irq_was_rx;
>
> +   struct clk *cec_clock;
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/15] drm/vc4: hdmi: Compute the CEC clock divider from the clock rate

Hi Maxime

On Thu, 10 Dec 2020 at 13:47, Maxime Ripard  wrote:
>
> The CEC clock divider needs to output a frequency of 40kHz from the HSM
> rate on the BCM2835. The driver used to have a fixed frequency for it,
> but that changed and we now need to compute it dynamically to maintain
> the proper rate.
>
> Fixes: cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel 
> rate")
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

(To be a total pedant it's still a fixed frequency on vc4, but it's
configurable via the variant entry).

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index eff3bac562c6..0c53d7427d15 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1586,6 +1586,7 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
>  {
> struct cec_connector_info conn_info;
> struct platform_device *pdev = vc4_hdmi->pdev;
> +   u16 clk_cnt;
> u32 value;
> int ret;
>
> @@ -1611,8 +1612,9 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
>  * divider: the hsm_clock rate and this divider setting will
>  * give a 40 kHz CEC clock.
>  */
> +   clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> value |= VC4_HDMI_CEC_ADDR_MASK |
> -(4091 << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> +(clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> ret = devm_request_threaded_irq(>dev, platform_get_irq(pdev, 0),
> vc4_cec_irq_handler,
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/15] drm/vc4: hdmi: Fix up CEC registers

Hi Maxime & Dom

On Thu, 10 Dec 2020 at 13:46, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> The commit 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout
> abstraction") forgot one CEC register, and made a copy and paste mistake
> for another one. Fix those mistakes.
>
> Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h 
> b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> index 013fd57febd8..20a1438a72cb 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> @@ -29,6 +29,7 @@ enum vc4_hdmi_field {
> HDMI_CEC_CPU_MASK_SET,
> HDMI_CEC_CPU_MASK_STATUS,
> HDMI_CEC_CPU_STATUS,
> +   HDMI_CEC_CPU_SET,
>
> /*
>  * Transmit data, first byte is low byte of the 32-bit reg.
> @@ -199,9 +200,10 @@ static const struct vc4_hdmi_register vc4_hdmi_fields[] 
> = {
> VC4_HDMI_REG(HDMI_TX_PHY_RESET_CTL, 0x02c0),
> VC4_HDMI_REG(HDMI_TX_PHY_CTL_0, 0x02c4),
> VC4_HDMI_REG(HDMI_CEC_CPU_STATUS, 0x0340),
> +   VC4_HDMI_REG(HDMI_CEC_CPU_SET, 0x0344),
> VC4_HDMI_REG(HDMI_CEC_CPU_CLEAR, 0x0348),
> VC4_HDMI_REG(HDMI_CEC_CPU_MASK_STATUS, 0x034c),
> -   VC4_HDMI_REG(HDMI_CEC_CPU_MASK_SET, 0x034c),
> +   VC4_HDMI_REG(HDMI_CEC_CPU_MASK_SET, 0x0350),
> VC4_HDMI_REG(HDMI_CEC_CPU_MASK_CLEAR, 0x0354),
> VC4_HDMI_REG(HDMI_RAM_PACKET_START, 0x0400),
>  };
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 1/1] drm/amdgpu: cleanup vce/vcn selftests

2020-12-18 Thread Nirmoy Das

Use amdgpu_sa_bo instead of amdgpu_bo.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 17 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 47 -
 2 files changed, 31 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 0d5284b936e4..bce29d6975d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -81,7 +81,7 @@ MODULE_FIRMWARE(FIRMWARE_VEGA20);
 
 static void amdgpu_vce_idle_work_handler(struct work_struct *work);
 static int amdgpu_vce_get_create_msg(struct amdgpu_ring *ring, uint32_t handle,
-struct amdgpu_bo *bo,
+struct amdgpu_sa_bo *bo,
 struct dma_fence **fence);
 static int amdgpu_vce_get_destroy_msg(struct amdgpu_ring *ring, uint32_t 
handle,
  bool direct, struct dma_fence **fence);
@@ -437,7 +437,7 @@ void amdgpu_vce_free_handles(struct amdgpu_device *adev, 
struct drm_file *filp)
  * Open up a stream for HW test
  */
 static int amdgpu_vce_get_create_msg(struct amdgpu_ring *ring, uint32_t handle,
-struct amdgpu_bo *bo,
+struct amdgpu_sa_bo *bo,
 struct dma_fence **fence)
 {
const unsigned ib_size_dw = 1024;
@@ -454,7 +454,7 @@ static int amdgpu_vce_get_create_msg(struct amdgpu_ring 
*ring, uint32_t handle,
 
ib = >ibs[0];
 
-   addr = amdgpu_bo_gpu_offset(bo);
+   addr = amdgpu_sa_bo_gpu_addr(bo);
 
/* stitch together an VCE create msg */
ib->length_dw = 0;
@@ -1130,16 +1130,16 @@ int amdgpu_vce_ring_test_ring(struct amdgpu_ring *ring)
 int amdgpu_vce_ring_test_ib(struct amdgpu_ring *ring, long timeout)
 {
struct dma_fence *fence = NULL;
-   struct amdgpu_bo *bo = NULL;
+   struct amdgpu_sa_bo *bo = NULL;
+   struct amdgpu_device *adev = ring->adev;
long r;
 
/* skip vce ring1/2 ib test for now, since it's not reliable */
if (ring != >adev->vce.ring[0])
return 0;
 
-   r = amdgpu_bo_create_reserved(ring->adev, 512, PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM,
- , NULL, NULL);
+   r = amdgpu_sa_bo_new(>ib_pools[AMDGPU_IB_POOL_DIRECT],
+, 512, PAGE_SIZE);
if (r)
return r;
 
@@ -1158,8 +1158,7 @@ int amdgpu_vce_ring_test_ib(struct amdgpu_ring *ring, 
long timeout)
r = 0;
 
 error:
+   amdgpu_sa_bo_free(adev, , fence);
dma_fence_put(fence);
-   amdgpu_bo_unreserve(bo);
-   amdgpu_bo_unref();
return r;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 4a77c7424dfc..ae4a80724ce2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -488,7 +488,7 @@ int amdgpu_vcn_dec_sw_ring_test_ring(struct amdgpu_ring 
*ring)
 }
 
 static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring *ring,
-  struct amdgpu_bo *bo,
+  struct amdgpu_sa_bo *bo,
   struct dma_fence **fence)
 {
struct amdgpu_device *adev = ring->adev;
@@ -504,7 +504,8 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring *ring,
goto err;
 
ib = >ibs[0];
-   addr = amdgpu_bo_gpu_offset(bo);
+   addr = amdgpu_sa_bo_gpu_addr(bo);
+
ib->ptr[0] = PACKET0(adev->vcn.internal.data0, 0);
ib->ptr[1] = addr;
ib->ptr[2] = PACKET0(adev->vcn.internal.data1, 0);
@@ -521,9 +522,7 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring *ring,
if (r)
goto err_free;
 
-   amdgpu_bo_fence(bo, f, false);
-   amdgpu_bo_unreserve(bo);
-   amdgpu_bo_unref();
+   amdgpu_sa_bo_free(adev, , f);
 
if (fence)
*fence = dma_fence_get(f);
@@ -535,25 +534,27 @@ static int amdgpu_vcn_dec_send_msg(struct amdgpu_ring 
*ring,
amdgpu_job_free(job);
 
 err:
-   amdgpu_bo_unreserve(bo);
-   amdgpu_bo_unref();
+   amdgpu_sa_bo_free(adev, , f);
return r;
 }
 
 static int amdgpu_vcn_dec_get_create_msg(struct amdgpu_ring *ring, uint32_t 
handle,
-struct amdgpu_bo **bo)
+struct amdgpu_sa_bo **bo)
 {
struct amdgpu_device *adev = ring->adev;
uint32_t *msg;
int r, i;
 
*bo = NULL;
-   r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM,
- bo, NULL, (void **));
+
+   r = amdgpu_sa_bo_new(>ib_pools[AMDGPU_IB_POOL_DIRECT],
+

Re: [PATCH 02/15] drm/vc4: hdmi: Move hdmi reset to bind

Hi Maxime & Dom

On Thu, 10 Dec 2020 at 13:46, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> The hdmi reset got moved to a later point in the commit 9045e91a476b
> ("drm/vc4: hdmi: Add reset callback").
>
> However, the reset now occurs after vc4_hdmi_cec_init and so tramples
> the setup of registers like HDMI_CEC_CNTRL_1
>
> This only affects pi0-3 as on pi4 the cec registers are in a separate
> block

It does mean that this reset only happens once on bind rather than on
every pre_crtc_configure, but as this really is the big reset the
entire block I don't see it needing to be triggered on every
configure.

> Fixes: 9045e91a476b ("drm/vc4: hdmi: Add reset callback")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 8006bddc8fbb..3df1747dd917 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -773,9 +773,6 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
> drm_encoder *encoder,
> return;
> }
>
> -   if (vc4_hdmi->variant->reset)
> -   vc4_hdmi->variant->reset(vc4_hdmi);
> -
> if (vc4_hdmi->variant->phy_init)
> vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
>
> @@ -1865,6 +1862,9 @@ static int vc4_hdmi_bind(struct device *dev, struct 
> device *master, void *data)
> vc4_hdmi->disable_wifi_frequencies =
> of_property_read_bool(dev->of_node, 
> "wifi-2.4ghz-coexistence");
>
> +   if (vc4_hdmi->variant->reset)
> +   vc4_hdmi->variant->reset(vc4_hdmi);
> +
> pm_runtime_enable(dev);
>
> drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v7 15/15] drm/i915/display: Let PCON convert from RGB to YCbCr if it can

2020-12-18 Thread Shankar, Uma




> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Friday, December 18, 2020 4:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
> 
> Subject: [PATCH v7 15/15] drm/i915/display: Let PCON convert from RGB to
> YCbCr if it can
> 
> If PCON has capability to convert RGB->YCbCr colorspace and also to 444->420
> downsampling then for any YUV420 only mode, we can let the PCON do all the
> conversion. If the PCON supports
> RGB->YCbCr conversion for all BT2020, BT709, BT601, choose
> the one that is selected by userspace via connector colorspace property,
> otherwise default to BT601.
> 
> v2: As suggested by Uma Shankar, considered case for colorspace
> BT709 and BT2020, and default to BT601. Also appended dir 'display' in commit
> message.
> 
> v3: Fixed typo in condition for printing one of the error msg.
> 
> v4: As suggested by Uma Shankar:
> -Fixed bug in determining the colorspace for RGB->YCbCr conversion.
> -Fixed minor formatting issues
> Also updated the commit message as per latest changes.

Changes look good, please work on color fixup as a separate series.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +-
>  .../drm/i915/display/intel_display_types.h|  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 72 +++
>  drivers/gpu/drm/i915/display/intel_dp.h   |  3 +-
>  4 files changed, 65 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index fbc07a93504b..17eaa56c5a99 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>   if (!is_mst)
>   intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
> 
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
>   intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
>   /*
>* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
> @@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>   intel_ddi_init_dp_buf_reg(encoder, crtc_state);
>   if (!is_mst)
>   intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
> - intel_dp_configure_protocol_converter(intel_dp);
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
>   intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
>   intel_dp_sink_set_fec_ready(intel_dp, crtc_state); diff --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 4c01c7c23dfd..2009ae9e9678 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1460,6 +1460,7 @@ struct intel_dp {
>   int pcon_max_frl_bw;
>   u8 max_bpc;
>   bool ycbcr_444_to_420;
> + bool rgb_to_ycbcr;
>   } dfp;
> 
>   /* Display stream compression testing */ diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index fdc028b7db07..d7e01482c808 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector
> *connector,
>   !drm_mode_is_420_only(info, mode))
>   return INTEL_OUTPUT_FORMAT_RGB;
> 
> + if (intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
>   if (intel_dp->dfp.ycbcr_444_to_420)
>   return INTEL_OUTPUT_FORMAT_YCBCR444;
>   else
> @@ -4319,7 +4323,8 @@ static void intel_dp_enable_port(struct intel_dp
> *intel_dp,
>   intel_de_posting_read(dev_priv, intel_dp->output_reg);  }
> 
> -void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
> +void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
> +const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   u8 tmp;
> @@ -4348,12 +4353,42 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp)
>   enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
> 
>   tmp = 0;
> + if (intel_dp->dfp.rgb_to_ycbcr) {
> + bool bt2020, bt709;
> 
> - if (drm_dp_dpcd_writeb(_dp->aux,
> -DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
> + /*
> +  * FIXME: Currently if userspace selects BT2020 or BT709, but
> PCON supports

RE: [PATCH v7 11/15] drm/i915: Add support for enabling link status and recovery

2020-12-18 Thread Shankar, Uma



> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Friday, December 18, 2020 4:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
> 
> Subject: [PATCH v7 11/15] drm/i915: Add support for enabling link status and
> recovery
> 
> From: Swati Sharma 
> 
> In this patch enables support for detecting link failures between PCON and 
> HDMI
> sink in i915 driver. HDMI link loss indication to upstream DP source is 
> indicated
> via IRQ_HPD. This is followed by reading of HDMI link configuration status
> (HDMI_TX_LINK_ACTIVE_STATUS).
> If the PCON → HDMI 2.1 link status is off; reinitiate frl link training to 
> recover.
> Also, report HDMI FRL link error count range for each individual FRL active 
> lane is
> indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
> 
> v2: Checked for dpcd read and write failures and added debug message.
> (Uma Shankar)
> 
> v3: Rearranged code to re-start FRL link training or fall back to TMDS mode.
> 
> v4: Resused function to check frl which inturn restarts FRL and fallback to 
> TMDS
> mode.
> 
> Signed-off-by: Swati Sharma 
> Signed-off-by: Ankit Nautiyal 
> Reviewed-by: Uma Shankar  (v2)

Change looks fine, you can keep RB.

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 53 +++--
>  1 file changed, 50 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1e0ff39bb927..66f35e7c9903 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6013,6 +6013,28 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>   return link_ok;
>  }
> 
> +static void
> +intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp) {
> + bool is_active;
> + u8 buf = 0;
> +
> + is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
> + if (intel_dp->frl.is_trained && !is_active) {
> + if (drm_dp_dpcd_readb(_dp->aux,
> DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
> + return;
> +
> + buf &=  ~DP_PCON_ENABLE_HDMI_LINK;
> + if (drm_dp_dpcd_writeb(_dp->aux,
> DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
> + return;
> +
> + drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
> +_dp->attached_connector->base);
> +
> + /* Restart FRL training or fall back to TMDS mode */
> + intel_dp_check_frl_training(intel_dp);
> + }
> +}
> +
>  static bool
>  intel_dp_needs_link_retrain(struct intel_dp *intel_dp)  { @@ -6378,7 +6400,7
> @@ intel_dp_hotplug(struct intel_encoder *encoder,
>   return state;
>  }
> 
> -static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
> +static void intel_dp_check_device_service_irq(struct intel_dp
> +*intel_dp)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   u8 val;
> @@ -6402,6 +6424,30 @@ static void intel_dp_check_service_irq(struct intel_dp
> *intel_dp)
>   drm_dbg_kms(>drm, "Sink specific irq unhandled\n");  }
> 
> +static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 val;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
> + return;
> +
> + if (drm_dp_dpcd_readb(_dp->aux,
> +   DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
> !val) {
> + drm_dbg_kms(>drm, "Error in reading link service irq
> vector\n");
> + return;
> + }
> +
> + if (drm_dp_dpcd_writeb(_dp->aux,
> +DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
> + drm_dbg_kms(>drm, "Error in writing link service irq
> vector\n");
> + return;
> + }
> +
> + if (val & HDMI_LINK_STATUS_CHANGED)
> + intel_dp_handle_hdmi_link_status_change(intel_dp);
> +}
> +
>  /*
>   * According to DP spec
>   * 5.1.2:
> @@ -6441,7 +6487,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>   return false;
>   }
> 
> - intel_dp_check_service_irq(intel_dp);
> + intel_dp_check_device_service_irq(intel_dp);
> + intel_dp_check_link_service_irq(intel_dp);
> 
>   /* Handle CEC interrupts, if any */
>   drm_dp_cec_irq(_dp->aux);
> @@ -6871,7 +6918,7 @@ intel_dp_detect(struct drm_connector *connector,
>   to_intel_connector(connector)->detect_edid)
>   status = connector_status_connected;
> 
> - intel_dp_check_service_irq(intel_dp);
> + intel_dp_check_device_service_irq(intel_dp);
> 
>  out:
>   if (status != connector_status_connected && !intel_dp->is_mst)
> --
> 2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v7 04/15] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON

2020-12-18 Thread Shankar, Uma




> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Friday, December 18, 2020 4:07 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
> 
> Subject: [PATCH v7 04/15] drm/dp_helper: Add Helpers for FRL Link Training
> support for DP-HDMI2.1 PCON
> 
> This patch adds support for configuring a PCON device, connected as a DP
> branched device to enable FRL Link training with a HDMI2.1 + sink.
> 
> v2: Fixed typos and addressed other review comments from Uma Shankar.
> -changed the commit message for better clarity (Uma Shankar) -removed
> unnecessary argument supplied to a drm helper function.
> -fixed return value for max frl read from pcon.
> 
> v3: Removed DPCD 0x3035 for MAX Sink FRL b/w as per new version of spec.
> 
> Signed-off-by: Ankit Nautiyal 
> Reviewed-by: Uma Shankar  (v2)

Changes look good, you can keep the RB.

>  drivers/gpu/drm/drm_dp_helper.c | 263 
>  include/drm/drm_dp_helper.h |  70 +
>  2 files changed, 333 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 5bd0934004e3..f501e3890921 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2596,3 +2596,266 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> device *dev,  #undef DP_SDP_LOG  }  EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> +
> +/**
> + * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns maximum frl bandwidth supported by PCON in GBPS,
> + * returns 0 if not supported.
> + */
> +int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + int bw;
> + u8 buf;
> +
> + buf = port_cap[2];
> + bw = buf & DP_PCON_MAX_FRL_BW;
> +
> + switch (bw) {
> + case DP_PCON_MAX_9GBPS:
> + return 9;
> + case DP_PCON_MAX_18GBPS:
> + return 18;
> + case DP_PCON_MAX_24GBPS:
> + return 24;
> + case DP_PCON_MAX_32GBPS:
> + return 32;
> + case DP_PCON_MAX_40GBPS:
> + return 40;
> + case DP_PCON_MAX_48GBPS:
> + return 48;
> + case DP_PCON_MAX_0GBPS:
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
> +
> +/**
> + * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 if success, else returns negative error code.
> + */
> +int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool
> +enable_frl_ready_hpd) {
> + int ret;
> + u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
> +  DP_PCON_ENABLE_LINK_FRL_MODE;
> +
> + if (enable_frl_ready_hpd)
> + buf |= DP_PCON_ENABLE_HPD_READY;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
> +
> +/**
> + * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns true if success, else returns false.
> + */
> +bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux) {
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
> + if (ret < 0)
> + return false;
> +
> + if (buf & DP_PCON_FRL_READY)
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
> +
> +/**
> + * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
> + * @aux: DisplayPort AUX channel
> + * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI
> +sink
> + * @concurrent_mode: true if concurrent mode or operation is required,
> + * false otherwise.
> + *
> + * Returns 0 if success, else returns negative error code.
> + */
> +
> +int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
> + bool concurrent_mode)
> +{
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
> + if (ret < 0)
> + return ret;
> +
> + if (concurrent_mode)
> + buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
> + else
> + buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
> +
> + switch (max_frl_gbps) {
> + case 9:
> + buf |=  DP_PCON_ENABLE_MAX_BW_9GBPS;
> + break;
> + case 18:
> + buf |=  DP_PCON_ENABLE_MAX_BW_18GBPS;
> + break;
> + case 24:
> + buf |=  DP_PCON_ENABLE_MAX_BW_24GBPS;
> + break;
> + case 32:
> + buf |=  DP_PCON_ENABLE_MAX_BW_32GBPS;
> + break;
> + case 40:
> + buf |=

[PATCH v7 14/15] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding

When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.

This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.

v2: Addressed review comments from Uma Shankar:
-fixed the error in packing pps parameter values
-added check for pcon in the pcon related function
-appended display in commit message

v3: Only consider non-zero DSC FRL b/w for determining max FRL b/w
supported by sink.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |   1 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 118 ++-
 drivers/gpu/drm/i915/display/intel_dp.h  |   2 +
 3 files changed, 119 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 974cf42351bc..fbc07a93504b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3653,6 +3653,7 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
 
intel_dp_check_frl_training(intel_dp);
+   intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
 
/*
 * 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7e2c334b3a17..fdc028b7db07 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4043,9 +4043,22 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp 
*intel_dp)
 {
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
+   int max_frl_rate;
+   int max_lanes, rate_per_lane;
+   int max_dsc_lanes, dsc_rate_per_lane;
 
-   return (connector->display_info.hdmi.max_frl_rate_per_lane *
-   connector->display_info.hdmi.max_lanes);
+   max_lanes = connector->display_info.hdmi.max_lanes;
+   rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+   max_frl_rate = max_lanes * rate_per_lane;
+
+   if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+   max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
+   dsc_rate_per_lane = 
connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+   if (max_dsc_lanes && dsc_rate_per_lane)
+   max_frl_rate = min(max_frl_rate, max_dsc_lanes * 
dsc_rate_per_lane);
+   }
+
+   return max_frl_rate;
 }
 
 static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4152,6 +4165,105 @@ void intel_dp_check_frl_training(struct intel_dp 
*intel_dp)
}
 }
 
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+   int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+   return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
+   int hdmi_throughput = 
connector->display_info.hdmi.dsc_cap.clk_per_slice;
+   int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
+   int pcon_max_slices = 
drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
+   int pcon_max_slice_width = 
drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
+
+
+   return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
+   int output_format = crtc_state->output_format;
+   bool hdmi_all_bpp = connector->display_info.hdmi.dsc_cap.all_bpp;
+   int pcon_fractional_bpp = 
drm_dp_pcon_dsc_bpp_incr(intel_dp->pcon_dsc_dpcd);
+   int hdmi_max_chunk_bytes =
+   connector->display_info.hdmi.dsc_cap.total_chunk_kbytes * 1024;
+
+   return intel_hdmi_dsc_get_bpp(pcon_fractional_bpp, slice_width,
+ num_slices, output_format, hdmi_all_bpp,
+ hdmi_max_chunk_bytes);
+}
+
+void

[PATCH v7 15/15] drm/i915/display: Let PCON convert from RGB to YCbCr if it can

If PCON has capability to convert RGB->YCbCr colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion. If the PCON supports
RGB->YCbCr conversion for all BT2020, BT709, BT601, choose
the one that is selected by userspace via connector colorspace
property, otherwise default to BT601.

v2: As suggested by Uma Shankar, considered case for colorspace
BT709 and BT2020, and default to BT601. Also appended dir
'display' in commit message.

v3: Fixed typo in condition for printing one of the error msg.

v4: As suggested by Uma Shankar:
-Fixed bug in determining the colorspace for RGB->YCbCr conversion.
-Fixed minor formatting issues
Also updated the commit message as per latest changes.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 72 +++
 drivers/gpu/drm/i915/display/intel_dp.h   |  3 +-
 4 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index fbc07a93504b..17eaa56c5a99 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
if (!is_mst)
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
 
+   intel_dp_configure_protocol_converter(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
/*
 * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
@@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
intel_ddi_init_dp_buf_reg(encoder, crtc_state);
if (!is_mst)
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
-   intel_dp_configure_protocol_converter(intel_dp);
+   intel_dp_configure_protocol_converter(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
  true);
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4c01c7c23dfd..2009ae9e9678 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,7 @@ struct intel_dp {
int pcon_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
+   bool rgb_to_ycbcr;
} dfp;
 
/* Display stream compression testing */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index fdc028b7db07..d7e01482c808 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector *connector,
!drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_RGB;
 
+   if (intel_dp->dfp.rgb_to_ycbcr &&
+   intel_dp->dfp.ycbcr_444_to_420)
+   return INTEL_OUTPUT_FORMAT_RGB;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
@@ -4319,7 +4323,8 @@ static void intel_dp_enable_port(struct intel_dp 
*intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 }
 
-void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
+void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
+  const struct intel_crtc_state 
*crtc_state)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 tmp;
@@ -4348,12 +4353,42 @@ void intel_dp_configure_protocol_converter(struct 
intel_dp *intel_dp)
enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
 
tmp = 0;
+   if (intel_dp->dfp.rgb_to_ycbcr) {
+   bool bt2020, bt709;
 
-   if (drm_dp_dpcd_writeb(_dp->aux,
-  DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
+   /*
+* FIXME: Currently if userspace selects BT2020 or BT709, but 
PCON supports only
+* RGB->YCbCr for BT601 colorspace, we go ahead with BT601, as 
default.
+*
+*/
+   tmp = DP_CONVERSION_BT601_RGB_YCBCR_ENABLE;
+
+   bt2020 = 
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+  
intel_dp->downstream_ports,
+  
DP_DS_HDMI_BT2020_RGB_YCBCR_CONV);
+   bt709 = 
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+

[PATCH v7 12/15] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder

This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.

v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.

v3: rebase

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 20 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index daecff9783ea..4c01c7c23dfd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1362,6 +1362,7 @@ struct intel_dp {
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
+   u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
/* source rates */
int num_source_rates;
const int *source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 66f35e7c9903..7e2c334b3a17 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3988,6 +3988,24 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 }
 
+static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   /* Clear the cached register set to avoid using stale values */
+
+   memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_PCON_DSC_ENCODER,
+intel_dp->pcon_dsc_dpcd,
+sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
+   drm_err(>drm, "Failed to read DPCD register 0x%x\n",
+   DP_PCON_DSC_ENCODER);
+
+   drm_dbg_kms(>drm, "PCON ENCODER DSC DPCD: %*ph\n",
+  (int)sizeof(intel_dp->pcon_dsc_dpcd), 
intel_dp->pcon_dsc_dpcd);
+}
+
 static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
 {
int bw_gbps[] = {9, 18, 24, 32, 40, 48};
@@ -6720,6 +6738,8 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->dfp.min_tmds_clock,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw);
+
+   intel_dp_get_pcon_dsc_cap(intel_dp);
 }
 
 static void
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 11/15] drm/i915: Add support for enabling link status and recovery

From: Swati Sharma 

In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.

v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)

v3: Rearranged code to re-start FRL link training or fall back to
TMDS mode.

v4: Resused function to check frl which inturn restarts FRL and
fallback to TMDS mode.

Signed-off-by: Swati Sharma 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 drivers/gpu/drm/i915/display/intel_dp.c | 53 +++--
 1 file changed, 50 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1e0ff39bb927..66f35e7c9903 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6013,6 +6013,28 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
 }
 
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+   bool is_active;
+   u8 buf = 0;
+
+   is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
+   if (intel_dp->frl.is_trained && !is_active) {
+   if (drm_dp_dpcd_readb(_dp->aux, 
DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
+   return;
+
+   buf &=  ~DP_PCON_ENABLE_HDMI_LINK;
+   if (drm_dp_dpcd_writeb(_dp->aux, 
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+   return;
+
+   drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux, 
_dp->attached_connector->base);
+
+   /* Restart FRL training or fall back to TMDS mode */
+   intel_dp_check_frl_training(intel_dp);
+   }
+}
+
 static bool
 intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
 {
@@ -6378,7 +6400,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
 }
 
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6402,6 +6424,30 @@ static void intel_dp_check_service_irq(struct intel_dp 
*intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
 }
 
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 val;
+
+   if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+   return;
+
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 || 
!val) {
+   drm_dbg_kms(>drm, "Error in reading link service irq 
vector\n");
+   return;
+   }
+
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
+   drm_dbg_kms(>drm, "Error in writing link service irq 
vector\n");
+   return;
+   }
+
+   if (val & HDMI_LINK_STATUS_CHANGED)
+   intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
 /*
  * According to DP spec
  * 5.1.2:
@@ -6441,7 +6487,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
 
-   intel_dp_check_service_irq(intel_dp);
+   intel_dp_check_device_service_irq(intel_dp);
+   intel_dp_check_link_service_irq(intel_dp);
 
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -6871,7 +6918,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
 
-   intel_dp_check_service_irq(intel_dp);
+   intel_dp_check_device_service_irq(intel_dp);
 
 out:
if (status != connector_status_connected && !intel_dp->is_mst)
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 13/15] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1

The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.

This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.

v2: Addressed review comments given by Uma Shankar:
-added documentation for functions
-fixed typos and errors

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 233 ++
 drivers/gpu/drm/i915/display/intel_hdmi.h |   7 +
 2 files changed, 240 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e10fdb369daa..41eb1c175a0e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3428,3 +3428,236 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
 }
+
+/*
+ * intel_hdmi_dsc_get_slice_height - get the dsc slice_height
+ * @vactive: Vactive of a display mode
+ *
+ * @return: appropriate dsc slice height for a given mode.
+ */
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+   int slice_height;
+
+   /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+   for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+   if (vactive % slice_height == 0)
+   return slice_height;
+
+   return 0;
+}
+
+/*
+ * intel_hdmi_dsc_get_num_slices - get no. of dsc slices based on dsc encoder
+ * and dsc decoder capabilites
+ *
+ * @crtc_state: intel crtc_state
+ * @src_max_slices: maximum slices supported by the DSC encoder
+ * @src_max_slice_width: maximum slice width supported by DSC encoder
+ * @hdmi_max_slices: maximum slices supported by sink DSC decoder
+ * @hdmi_throughput: maximum clock per slice (MHz) supported by HDMI sink
+ *
+ * @return: num of dsc slices that can be supported by the dsc encoder
+ * and decoder.
+ */
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE   272
+/*
+ * Rates at which the source and sink are required to process pixels in each
+ * slice, can be two levels: either atleast 34KHz or atleast 4KHz.
+ */
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0  34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1  40
+
+/* Spec limits the slice width to 2720 pixels */
+#define MAX_HDMI_SLICE_WIDTH   2720
+   int kslice_adjust;
+   int adjusted_clk_khz;
+   int min_slices;
+   int target_slices;
+   int max_throughput; /* max clock freq. in khz per slice */
+   int max_slice_width;
+   int slice_width;
+   int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+   if (!hdmi_throughput)
+   return 0;
+
+   /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0, and 4:2:2 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
+   crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
+   kslice_adjust = 10;
+   else
+   kslice_adjust = 5;
+
+   /*
+* As per spec, the rate at which the source and the sink process
+* the pixels per slice are at two levels: atleast 340Mhz or 400Mhz.
+* This depends upon the pixel clock rate and output formats
+* (kslice adjust).
+* If pixel clock * kslice adjust >= 2720MHz slices can be processed
+* at max 340MHz, otherwise they can be processed at max 400MHz.
+*/
+
+   adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+   if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+   max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+   else
+   max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+   /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+   max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+   min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+   max_slice_width =

[PATCH v7 10/15] drm/i915: Check for FRL training before DP Link training

This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.

v2: moved check_frl_training() just after FEC READY, before
starting DP link training.

v3: rebase

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
 drivers/gpu/drm/i915/display/intel_dp.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6863236df1d0..974cf42351bc 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3652,6 +3652,8 @@ static void tgl_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
 */
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
 
+   intel_dp_check_frl_training(intel_dp);
+
/*
 * 7.i Follow DisplayPort specification training sequence (see notes for
 * failure handling)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 43027a6d5e5e..1e0ff39bb927 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4264,6 +4264,7 @@ static void intel_enable_dp(struct intel_atomic_state 
*state,
 
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
intel_dp_configure_protocol_converter(intel_dp);
+   intel_dp_check_frl_training(intel_dp);
intel_dp_start_link_train(intel_dp, pipe_config);
intel_dp_stop_link_train(intel_dp, pipe_config);
 
@@ -6185,6 +6186,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
!intel_dp_mst_is_master_trans(crtc_state))
continue;
 
+   intel_dp_check_frl_training(intel_dp);
intel_dp_start_link_train(intel_dp, crtc_state);
intel_dp_stop_link_train(intel_dp, crtc_state);
break;
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 08/15] drm/i915: Capture max frl rate for PCON in dfp cap structure

HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON.

This patch captures this in dfp cap structure in intel_dp and uses
this to prune connector modes that cannot be supported by the PCON
and FRL bandwidth.

v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 30 +--
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..c88d2b918d9f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1451,6 +1451,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+   int pcon_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index b2bc0c8c39c7..0596d6c24e73 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -716,6 +716,25 @@ intel_dp_mode_valid_downstream(struct intel_connector 
*connector,
const struct drm_display_info *info = >base.display_info;
int tmds_clock;
 
+   /* If PCON supports FRL MODE, check FRL bandwidth constraints */
+   if (intel_dp->dfp.pcon_max_frl_bw) {
+   int target_bw;
+   int max_frl_bw;
+   int bpp = intel_dp_mode_min_output_bpp(>base, mode);
+
+   target_bw = bpp * target_clock;
+
+   max_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+
+   /* converting bw from Gbps to Kbps*/
+   max_frl_bw = max_frl_bw * 100;
+
+   if (target_bw > max_frl_bw)
+   return MODE_CLOCK_HIGH;
+
+   return MODE_OK;
+   }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6492,13 +6511,18 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
 intel_dp->downstream_ports,
 edid);
 
+   intel_dp->dfp.pcon_max_frl_bw =
+   drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+  intel_dp->downstream_ports);
+
drm_dbg_kms(>drm,
-   "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS 
clock %d-%d\n",
+   "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS 
clock %d-%d, PCON Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
-   intel_dp->dfp.max_tmds_clock);
+   intel_dp->dfp.max_tmds_clock,
+   intel_dp->dfp.pcon_max_frl_bw);
 }
 
 static void
@@ -6590,6 +6614,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
 
+   intel_dp->dfp.pcon_max_frl_bw = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
 }
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 09/15] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON

This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.

v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.

v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().

v4: Fixed typo in initialization of frl structure.

v5: Always use FRL if its possible, instead of enabling only for
higher modes as done in v3.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 .../drm/i915/display/intel_display_types.h|   7 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 151 ++
 drivers/gpu/drm/i915/display/intel_dp.h   |   2 +
 3 files changed, 160 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c88d2b918d9f..daecff9783ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1339,6 +1339,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
 };
 
+struct intel_dp_pcon_frl {
+   bool is_trained;
+   int trained_rate_gbps;
+};
+
 struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1461,6 +1466,8 @@ struct intel_dp {
 
bool hobl_failed;
bool hobl_active;
+
+   struct intel_dp_pcon_frl frl;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0596d6c24e73..43027a6d5e5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3891,6 +3891,8 @@ static void intel_disable_dp(struct intel_atomic_state 
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+   intel_dp->frl.is_trained = false;
+   intel_dp->frl.trained_rate_gbps = 0;
 }
 
 static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3986,6 +3988,152 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
 }
 
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+   int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+   int i;
+
+   for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+   if (frl_bw_mask & (1 << i))
+   return bw_gbps[i];
+   }
+   return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+
+   switch (max_frl) {
+   case 48:
+   return DP_PCON_FRL_BW_MASK_48GBPS;
+   case 40:
+   return DP_PCON_FRL_BW_MASK_40GBPS;
+   case 32:
+   return DP_PCON_FRL_BW_MASK_32GBPS;
+   case 24:
+   return DP_PCON_FRL_BW_MASK_24GBPS;
+   case 18:
+   return DP_PCON_FRL_BW_MASK_18GBPS;
+   case 9:
+   return DP_PCON_FRL_BW_MASK_9GBPS;
+   }
+
+   return 0;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
+
+   return (connector->display_info.hdmi.max_frl_rate_per_lane *
+   connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
+   u8 max_frl_bw_mask = 0, frl_trained_mask;
+   bool is_active;
+
+   ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+   if (ret < 0)
+   return ret;
+
+   max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+   drm_dbg(>drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+   max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
+   drm_dbg(>drm, "Sink max rate from EDID = %d Gbps\n", 
max_edid_frl_bw);
+
+   max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
+
+   if (max_frl_bw <= 0)
+   return -EINVAL;
+
+   ret = drm_dp_pcon_frl_prepare(_dp->aux, false);
+   if (ret < 0)
+   return ret;
+   /* Wait for PCON to be FRL Ready */
+   wait_for(is_active = drm_dp_pcon_is_frl_ready(_dp->aux) == true, 
TIMEOUT_FRL_READY_MS);
+
+   if (!is_active)
+   return

[PATCH v7 07/15] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion

DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion
of colorspace from RGB to YCbCr.
https://groups.vesa.org/wg/DP/document/previewpdf/15651

This patch adds the relavant registers and helper functions to
get the capability and set the color conversion bits for rgb->ycbcr
conversion through PCON.

v2: As suggested in review comments:
-Fixed bug in the check condition in a drm_helper as reported by
 Dan Carpenter and Kernel test robot. (Dan Carepenter)
-Modified the color-conversion cap helper function, to accomodate
 BT709 and BT2020 colorspace. (Uma Shankar)
-Added spec details for the new cap for color conversion. (Uma Shankar)

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_dp_helper.c | 61 +
 include/drm/drm_dp_helper.h | 19 +-
 2 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 689fd0d5f6c5..9abd65c694ab 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -949,6 +949,38 @@ bool drm_dp_downstream_444_to_420_conversion(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]
 }
 EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
 
+/**
+ * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream facing 
port
+ *   RGB->YCbCr conversion 
capability
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: downstream facing port capabilities
+ * @colorspc: Colorspace for which conversion cap is sought
+ *
+ * Returns: whether the downstream facing port can convert RGB->YCbCr for a 
given
+ * colorspace.
+ */
+bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
+  const u8 port_cap[4],
+  u8 color_spc)
+{
+   if (!drm_dp_is_branch(dpcd))
+   return false;
+
+   if (dpcd[DP_DPCD_REV] < 0x13)
+   return false;
+
+   switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
+   case DP_DS_PORT_TYPE_HDMI:
+   if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
+   return false;
+
+   return port_cap[3] & color_spc;
+   default:
+   return false;
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
+
 /**
  * drm_dp_downstream_mode() - return a mode for downstream facing port
  * @dev: DRM device
@@ -3101,3 +3133,32 @@ int drm_dp_pcon_pps_override_param(struct drm_dp_aux 
*aux, u8 pps_param[6])
return 0;
 }
 EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
+
+/*
+ * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert RGB to 
Ycbcr
+ * @aux: displayPort AUX channel
+ * @color_spc: Color-space/s for which conversion is to be enabled, 0 for 
disable.
+ *
+ * Returns 0 on success, else returns negative error code.
+ */
+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc)
+{
+   int ret;
+   u8 buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, );
+   if (ret < 0)
+   return ret;
+
+   if (color_spc & DP_CONVERSION_RGB_YCBCR_MASK)
+   buf |= (color_spc & DP_CONVERSION_RGB_YCBCR_MASK);
+   else
+   buf &= ~DP_CONVERSION_RGB_YCBCR_MASK;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index baad87fe6b0a..e096ee98842b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -432,6 +432,17 @@ struct drm_device;
 # define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
 # define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
 
+/*
+ * VESA DP-to-HDMI PCON Specification adds caps for colorspace
+ * conversion in DFP cap DPCD 83h. Sec6.1 Table-3.
+ * Based on the available support the source can enable
+ * color conversion by writing into PROTOCOL_COVERTER_CONTROL_2
+ * DPCD 3052h.
+ */
+# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
+# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
+# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV   (1 << 7)
+
 #define DP_MAX_DOWNSTREAM_PORTS0x10
 
 /* DP Forward error Correction Registers */
@@ -1207,7 +1218,10 @@ struct drm_device;
 # define DP_PCON_ENC_PPS_OVERRIDE_DISABLED  0
 # define DP_PCON_ENC_PPS_OVERRIDE_EN_PARAMS 1
 # define DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER 2
-
+# define DP_CONVERSION_RGB_YCBCR_MASK (7 << 4)
+# define DP_CONVERSION_BT601_RGB_YCBCR_ENABLE  (1 << 4)
+# define DP_CONVERSION_BT709_RGB_YCBCR_ENABLE  (1 << 5)
+# define DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE (1 << 6)
 
 /* PCON Downstream HDMI ERROR Status per Lane */
 #define DP_PCON_HDMI_ERROR_STATUS_LN0

[PATCH v7 06/15] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon

This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.

v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as suggested by Uma Shankar.

v3: Only setting the DSC bits for the Protocol Convertor control
registers, avoiding overwritining color conversion bits.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 drivers/gpu/drm/drm_dp_helper.c | 203 
 include/drm/drm_dp_helper.h | 114 ++
 2 files changed, 317 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a1d518b3a173..689fd0d5f6c5 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2898,3 +2898,206 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct 
drm_dp_aux *aux,
}
 }
 EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+/*
+ * drm_dp_pcon_enc_is_dsc_1_2 - Does PCON Encoder supports DSC 1.2
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns true is PCON encoder is DSC 1.2 else returns false.
+ */
+bool drm_dp_pcon_enc_is_dsc_1_2(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 buf;
+   u8 major_v, minor_v;
+
+   buf = pcon_dsc_dpcd[DP_PCON_DSC_VERSION - DP_PCON_DSC_ENCODER];
+   major_v = (buf & DP_PCON_DSC_MAJOR_MASK) >> DP_PCON_DSC_MAJOR_SHIFT;
+   minor_v = (buf & DP_PCON_DSC_MINOR_MASK) >> DP_PCON_DSC_MINOR_SHIFT;
+
+   if (major_v == 1 && minor_v == 2)
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_enc_is_dsc_1_2);
+
+/*
+ * drm_dp_pcon_dsc_max_slices - Get max slices supported by PCON DSC Encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum no. of slices supported by the PCON DSC Encoder.
+ */
+int drm_dp_pcon_dsc_max_slices(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 slice_cap1, slice_cap2;
+
+   slice_cap1 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_1 - 
DP_PCON_DSC_ENCODER];
+   slice_cap2 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_2 - 
DP_PCON_DSC_ENCODER];
+
+   if (slice_cap2 & DP_PCON_DSC_24_PER_DSC_ENC)
+   return 24;
+   if (slice_cap2 & DP_PCON_DSC_20_PER_DSC_ENC)
+   return 20;
+   if (slice_cap2 & DP_PCON_DSC_16_PER_DSC_ENC)
+   return 16;
+   if (slice_cap1 & DP_PCON_DSC_12_PER_DSC_ENC)
+   return 12;
+   if (slice_cap1 & DP_PCON_DSC_10_PER_DSC_ENC)
+   return 10;
+   if (slice_cap1 & DP_PCON_DSC_8_PER_DSC_ENC)
+   return 8;
+   if (slice_cap1 & DP_PCON_DSC_6_PER_DSC_ENC)
+   return 6;
+   if (slice_cap1 & DP_PCON_DSC_4_PER_DSC_ENC)
+   return 4;
+   if (slice_cap1 & DP_PCON_DSC_2_PER_DSC_ENC)
+   return 2;
+   if (slice_cap1 & DP_PCON_DSC_1_PER_DSC_ENC)
+   return 1;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slices);
+
+/*
+ * drm_dp_pcon_dsc_max_slice_width() - Get max slice width for Pcon DSC encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum width of the slices in pixel width i.e. no. of pixels x 320.
+ */
+int drm_dp_pcon_dsc_max_slice_width(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 buf;
+
+   buf = pcon_dsc_dpcd[DP_PCON_DSC_MAX_SLICE_WIDTH - DP_PCON_DSC_ENCODER];
+
+   return buf * DP_DSC_SLICE_WIDTH_MULTIPLIER;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slice_width);
+
+/*
+ * drm_dp_pcon_dsc_bpp_incr() - Get bits per pixel increment for PCON DSC 
encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns the bpp precision supported by the PCON encoder.
+ */
+int drm_dp_pcon_dsc_bpp_incr(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+   u8 buf;
+
+   buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
+
+   switch (buf & DP_PCON_DSC_BPP_INCR_MASK) {
+   case DP_PCON_DSC_ONE_16TH_BPP:
+   return 16;
+   case DP_PCON_DSC_ONE_8TH_BPP:
+   return 8;
+   case DP_PCON_DSC_ONE_4TH_BPP:
+   return 4;
+   case DP_PCON_DSC_ONE_HALF_BPP:
+   return 2;
+   case DP_PCON_DSC_ONE_BPP:
+   return 1;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_bpp_incr);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, );
+   if (ret < 0)
+   return ret;
+
+   buf |= DP_PCON_ENABLE_DSC_ENCODER;
+
+   if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+   buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+   buf |= pps_buf_config << 2;
+   }
+
+

[PATCH v7 05/15] drm/dp_helper: Add support for link failure detection

From: Swati Sharma 

There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechanism. While source can always read final HDMI sink's status using
I2C over AUX, it is easier and faster to read the PCONs already read
HDMI sink status registers.

This patch adds the DPCDs required for link failure detection and
provide a helper function for printing error count/lane which might
help in debugging the link failure issues.

v2: Addressed comments from Uma Shankar:
-rephrased the commit message, as per the code.
-fixed styling issues
-added documentation for the helper function.

Signed-off-by: Swati Sharma 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_dp_helper.c | 39 +
 include/drm/drm_dp_helper.h | 17 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f501e3890921..a1d518b3a173 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2859,3 +2859,42 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, 
u8 *frl_trained_mask)
return mode;
 }
 EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+/**
+ * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per lane
+ * during link failure between PCON and HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @connector: DRM connector
+ * code.
+ **/
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+  struct drm_connector *connector)
+{
+   u8 buf, error_count;
+   int i, num_error;
+   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+   for (i = 0; i < hdmi->max_lanes; i++) {
+   if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i, 
) < 0)
+   return;
+
+   error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+   switch (error_count) {
+   case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+   num_error = 100;
+   break;
+   case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+   num_error = 10;
+   break;
+   case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+   num_error = 3;
+   break;
+   default:
+   num_error = 0;
+   }
+
+   DRM_ERROR("More than %d errors since the last read for lane 
%d", num_error, i);
+   }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c66f570eadc2..871e8c051642 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
 # define DP_CEC_IRQ  (1 << 2)
 
 #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
+# define RX_CAP_CHANGED  (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED   (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED   (1 << 4)
 
 #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
 # define DP_PSR_LINK_CRC_ERROR  (1 << 0)
@@ -1120,6 +1125,16 @@ struct drm_device;
 #define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
 # define DP_CONVERSION_TO_YCBCR422_ENABLE  (1 << 0) /* DP 1.3 */
 
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0  0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1  0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2  0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3  0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS   (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
 /* HDCP 1.3 and HDCP 2.2 */
 #define DP_AUX_HDCP_BKSV   0x68000
 #define DP_AUX_HDCP_RI_PRIME   0x68005
@@ -2036,5 +2051,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
 
 bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
 int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);
 
 #endif /* _DRM_DP_HELPER_H_ */
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 04/15] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON

This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.

v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.

v3: Removed DPCD 0x3035 for MAX Sink FRL b/w as per new version of spec.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar  (v2)
---
 drivers/gpu/drm/drm_dp_helper.c | 263 
 include/drm/drm_dp_helper.h |  70 +
 2 files changed, 333 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..f501e3890921 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,266 @@ void drm_dp_vsc_sdp_log(const char *level, struct 
device *dev,
 #undef DP_SDP_LOG
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ */
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+  const u8 port_cap[4])
+{
+   int bw;
+   u8 buf;
+
+   buf = port_cap[2];
+   bw = buf & DP_PCON_MAX_FRL_BW;
+
+   switch (bw) {
+   case DP_PCON_MAX_9GBPS:
+   return 9;
+   case DP_PCON_MAX_18GBPS:
+   return 18;
+   case DP_PCON_MAX_24GBPS:
+   return 24;
+   case DP_PCON_MAX_32GBPS:
+   return 32;
+   case DP_PCON_MAX_40GBPS:
+   return 40;
+   case DP_PCON_MAX_48GBPS:
+   return 48;
+   case DP_PCON_MAX_0GBPS:
+   default:
+   return 0;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ */
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+   int ret;
+   u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+   if (enable_frl_ready_hpd)
+   buf |= DP_PCON_ENABLE_HPD_READY;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ */
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+   int ret;
+   u8 buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
+   if (ret < 0)
+   return false;
+
+   if (buf & DP_PCON_FRL_READY)
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ */
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+   bool concurrent_mode)
+{
+   int ret;
+   u8 buf;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
+   if (ret < 0)
+   return ret;
+
+   if (concurrent_mode)
+   buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+   else
+   buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+   switch (max_frl_gbps) {
+   case 9:
+   buf |=  DP_PCON_ENABLE_MAX_BW_9GBPS;
+   break;
+   case 18:
+   buf |=  DP_PCON_ENABLE_MAX_BW_18GBPS;
+   break;
+   case 24:
+   buf |=  DP_PCON_ENABLE_MAX_BW_24GBPS;
+   break;
+   case 32:
+   buf |=  DP_PCON_ENABLE_MAX_BW_32GBPS;
+   break;
+   case 40:
+   buf |=  DP_PCON_ENABLE_MAX_BW_40GBPS;
+   break;
+   case 48:
+   buf |=  DP_PCON_ENABLE_MAX_BW_48GBPS;
+   break;
+   case 0:
+   buf |=  DP_PCON_ENABLE_MAX_BW_0GBPS;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
+
+/**
+ * drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
+ * @aux: DisplayPort AUX channel
+ * @max_frl_mask : Max FRL BW to

[PATCH v7 03/15] drm/edid: Parse DSC1.2 cap fields from HFVSDB block

This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.

v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c  | 59 +
 include/drm/drm_connector.h | 43 +++
 2 files changed, 102 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e657c321d9e4..ca368df2e5ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4941,11 +4941,70 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
 
if (hf_vsdb[7]) {
u8 max_frl_rate;
+   u8 dsc_max_frl_rate;
+   u8 dsc_max_slices;
+   struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
 
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
+   hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
+
+   if (hdmi_dsc->v_1p2) {
+   hdmi_dsc->native_420 = hf_vsdb[11] & 
DRM_EDID_DSC_NATIVE_420;
+   hdmi_dsc->all_bpp = hf_vsdb[11] & DRM_EDID_DSC_ALL_BPP;
+
+   if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
+   hdmi_dsc->bpc_supported = 16;
+   else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
+   hdmi_dsc->bpc_supported = 12;
+   else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
+   hdmi_dsc->bpc_supported = 10;
+   else
+   hdmi_dsc->bpc_supported = 0;
+
+   dsc_max_frl_rate = (hf_vsdb[12] & 
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+   drm_get_max_frl_rate(dsc_max_frl_rate, 
_dsc->max_lanes,
+   _dsc->max_frl_rate_per_lane);
+   hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] & 
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+   dsc_max_slices = hf_vsdb[12] & DRM_EDID_DSC_MAX_SLICES;
+   switch (dsc_max_slices) {
+   case 1:
+   hdmi_dsc->max_slices = 1;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 2:
+   hdmi_dsc->max_slices = 2;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 3:
+   hdmi_dsc->max_slices = 4;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 4:
+   hdmi_dsc->max_slices = 8;
+   hdmi_dsc->clk_per_slice = 340;
+   break;
+   case 5:
+   hdmi_dsc->max_slices = 8;
+   hdmi_dsc->clk_per_slice = 400;
+   break;
+   case 6:
+   hdmi_dsc->max_slices = 12;
+   hdmi_dsc->clk_per_slice = 400;
+   break;
+   case 7:
+   hdmi_dsc->max_slices = 16;
+   hdmi_dsc->clk_per_slice = 400;
+   break;
+   case 0:
+   default:
+   hdmi_dsc->max_slices = 0;
+   hdmi_dsc->clk_per_slice = 0;
+   }
+   }
}
 
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1a3b4776b458..1922b278ffad 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -175,6 +175,46 @@ struct drm_scdc {
struct drm_scrambling scrambling;
 };
 
+/**
+ * struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
+ *
+ * Describes the DSC support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_dsc_cap {
+   /** @v_1p2: flag for dsc1.2 version support by sink */
+   bool v_1p2;
+
+   /** @native_420: Does sink support DSC with 4:2:0 compression */
+   bool native_420;
+
+   /**
+* @all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
+

[PATCH v7 02/15] drm/edid: Parse MAX_FRL field from HFVSDB block

From: Swati Sharma 

This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.

v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)

Signed-off-by: Sharma, Swati2 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_edid.c  | 44 +
 include/drm/drm_connector.h |  6 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..e657c321d9e4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4851,6 +4851,41 @@ static void drm_parse_vcdb(struct drm_connector 
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
 }
 
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8 
*max_rate_per_lane)
+{
+   switch (max_frl_rate) {
+   case 1:
+   *max_lanes = 3;
+   *max_rate_per_lane = 3;
+   break;
+   case 2:
+   *max_lanes = 3;
+   *max_rate_per_lane = 6;
+   break;
+   case 3:
+   *max_lanes = 4;
+   *max_rate_per_lane = 6;
+   break;
+   case 4:
+   *max_lanes = 4;
+   *max_rate_per_lane = 8;
+   break;
+   case 5:
+   *max_lanes = 4;
+   *max_rate_per_lane = 10;
+   break;
+   case 6:
+   *max_lanes = 4;
+   *max_rate_per_lane = 12;
+   break;
+   case 0:
+   default:
+   *max_lanes = 0;
+   *max_rate_per_lane = 0;
+   }
+}
+
 static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
   const u8 *db)
 {
@@ -4904,6 +4939,15 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
}
}
 
+   if (hf_vsdb[7]) {
+   u8 max_frl_rate;
+
+   DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+   max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+   drm_get_max_frl_rate(max_frl_rate, >max_lanes,
+   >max_frl_rate_per_lane);
+   }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fcdc58d8b88b..1a3b4776b458 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
 
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+   /** @max_frl_rate_per_lane: support fixed rate link */
+   u8 max_frl_rate_per_lane;
+
+   /** @max_lanes: supported by sink */
+   u8 max_lanes;
 };
 
 /**
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 01/15] drm/edid: Add additional HFVSDB fields for HDMI2.1

From: Swati Sharma 

The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.

This patch adds the new HFVSDB fields that are required for
HDMI2.1.

v2: Minor fixes + consistent naming for DPCD register masks
(Uma Shankar)

Signed-off-by: Sharma, Swati2 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 include/drm/drm_edid.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index e97daf6ffbb1..a158f585f658 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
 
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION   (1 << 0)
+#define DRM_EDID_ALLM  (1 << 1)
+#define DRM_EDID_FVA   (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420  (1 << 0)
+#define DRM_EDID_DC_36BIT_420  (1 << 1)
+#define DRM_EDID_DC_48BIT_420  (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK  0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP   (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2   (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 00/15] Add support for DP-HDMI2.1 PCON

This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
The details are mentioned in:
VESA DP-to-HDMI PCON Specification Standalone Document
https://groups.vesa.org/wg/DP/document/15651

This series starts with adding support for FRL (Fixed Rate Link)
Training between the PCON and HDMI2.1 sink.
As per HDMI2.1 specification, a new data-channel or lane is added in
FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher
bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4
lanes).

With these patches, the HDMI2.1 PCON can be configured to achieve FRL
training based on the maximum FRL rate supported by the panel, source
and the PCON.
The approach is to add the support for FRL training between PCON and
HDMI2.1 sink and gradually add other blocks for supporting higher
resolutions and other HDMI2.1 features, that can be supported by pcon
for the sources that do not natively support HDMI2.1.

This is done before the DP Link training between the source and PCON
is started. In case of FRL training is not achieved, the PCON will
work in the regular TMDS mode, without HDMI2.1 feature support.
Any interruption in FRL training between the PCON and HDMI2.1 sink is
notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD
registers are read and FRL training is re-attempted.

Currently, we have tested the FRL training and are able to enable 4K
display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting
panel.

v2: Addressed review comments and re-organized patches as suggested in
comments on RFC patches.

v3: Addressed review comments on previous version.

v4: Added support for RGB->YCBCR conversion through PCON

v5: Addressed review comments on previous version.

v6: Fix typo in one of the patch.

v7: Rebased on latest drm-tip and addressed the review comments.

Ankit Nautiyal (11):
  drm/edid: Parse DSC1.2 cap fields from HFVSDB block
  drm/dp_helper: Add Helpers for FRL Link Training support for
DP-HDMI2.1 PCON
  drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
  drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
  drm/i915: Capture max frl rate for PCON in dfp cap structure
  drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
  drm/i915: Check for FRL training before DP Link training
  drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
  drm/i915: Add helper functions for calculating DSC parameters for
HDMI2.1
  drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
  drm/i915/display: Let PCON convert from RGB to YCbCr if it can

Swati Sharma (4):
  drm/edid: Add additional HFVSDB fields for HDMI2.1
  drm/edid: Parse MAX_FRL field from HFVSDB block
  drm/dp_helper: Add support for link failure detection
  drm/i915: Add support for enabling link status and recovery

 drivers/gpu/drm/drm_dp_helper.c   | 566 ++
 drivers/gpu/drm/drm_edid.c| 103 
 drivers/gpu/drm/i915/display/intel_ddi.c  |   6 +-
 .../drm/i915/display/intel_display_types.h|  10 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 442 +-
 drivers/gpu/drm/i915/display/intel_dp.h   |   7 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 233 +++
 drivers/gpu/drm/i915/display/intel_hdmi.h |   7 +
 include/drm/drm_connector.h   |  49 ++
 include/drm/drm_dp_helper.h   | 218 +++
 include/drm/drm_edid.h|  30 +
 11 files changed, 1652 insertions(+), 19 deletions(-)

-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem


Am 18.12.20 um 09:52 schrieb Chen Li:

On Fri, 18 Dec 2020 16:10:12 +0800,
Christian König wrote:

Am 18.12.20 um 04:51 schrieb Chen Li:

[SNIP]

If your ARM base board can't do that for some then you can't use the hardware
with that board.

Good to know, thanks! BTW, have you ever seen or heard boards like mine which 
cannot mmap device memory correctly from userspace correctly?

Unfortunately yes. We haven't been able to figure out what exactly goes wrong in
those cases.

Ok. one more question: only e8860 or all radeon cards have this issue?

This applies to all hardware with dedicated memory which needs to be mapped to
userspace.

That includes all graphics hardware from AMD as well as NVidia and probably a
whole bunch of other PCIe devices.

Can mmio on these devices work fine in kernel space?


The kernel drivers know that this is MMIO and can use special 
instructions/functions like 
writel()/writeq()/memcpy_fromio()/memcpy_toio() etc...



I cannot see the difference here except user space should use uncacheable mmap 
to map virtual memory to device space(though I don't know how to use 
uncacheable mmap), while kernel use uncache ioremap.


The problem with mmap() of MMIO into the userspace is that this can 
easily crash the whole system.


When an application uses memset()/memcpy() on the mapped region and the 
system spontaneous reboots than that's a rather big hardware problem.


Regards,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 47/48] ARM: tegra: ventana: Support CPU voltage scaling and thermal throttling

18.12.2020 00:19, Daniel Lezcano пишет:
> On 17/12/2020 21:28, Dmitry Osipenko wrote:
>> 17.12.2020 22:36, Daniel Lezcano пишет:
>> +type = "critical";
>> +};
>> +};
>> +
>> +cooling-maps {
>> +map0 {
>> +trip = <>;
>> +cooling-device = < 
>> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> You should add all CPUs here.

 All CPU cores are coupled on Tegra in regards to CPUFreq, hence I think
 it won't make any difference if secondary CPU cores will be added here,
 isn't it?
>>> The explanation is in the description of commit ef4734500407ce4d
>>
>> I think that really only makes sense if CPU cores have independent clock
>> rate management. 
> 
> ATM I did not see any ARM platform having a clock line per CPU but I may
> be wrong.
> 
>> IIRC, I actually made some research about this in the
>> past and intentionally removed the secondary cores from the
>> cooling-device since they didn't make any difference for a coupled CPU
>> cores.
>>
>> That commit also says:
>>
>> "But as soon as this CPU ordering changes and any other CPU is used to
>> bring up the cooling device, we will start seeing failures."
>>
>> I don't quite understand to what "failures" that commit referrers. I
>> tried to change the cpu0 to cpu1 in the cooling-device and don't see any
>> failures. Could you please clarify this?
>>
>> In general it should be fine to add all the cores to the cooling-device
>> and I'll do it in v3, but I want to make it clear why this is needed.
> 
> AFAIR, if CPU0 is unplugged the cooling device can not rebind to CPU1.
> And if CPU0 is plugged in again, the cooling device fails to initialize.
> 
> And, if the CPUs are mapped with the physical CPU0 to Linux numbering
> CPU1, the cooling device mapping will fail.

Alright, thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 27/48] soc/tegra: Add CONFIG_SOC_TEGRA_COMMON and select PM_OPP by default

Add new Kconfig SOC_TEGRA_COMMON option which selects configuration
options that are common for all Tegra SoCs. Select PM_OPP by default
since from now on OPPs will be used by Tegra drivers which present on
all SoC generations, like display controller driver for example.

Signed-off-by: Dmitry Osipenko 
---
 drivers/soc/tegra/Kconfig | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 976dee036470..bcd61ae59ba3 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -13,6 +13,7 @@ config ARCH_TEGRA_2x_SOC
select PINCTRL_TEGRA20
select PL310_ERRATA_727915 if CACHE_L2X0
select PL310_ERRATA_769419 if CACHE_L2X0
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select SOC_TEGRA20_VOLTAGE_COUPLER
@@ -27,6 +28,7 @@ config ARCH_TEGRA_3x_SOC
select ARM_ERRATA_764369 if SMP
select PINCTRL_TEGRA30
select PL310_ERRATA_769419 if CACHE_L2X0
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select SOC_TEGRA30_VOLTAGE_COUPLER
@@ -40,6 +42,7 @@ config ARCH_TEGRA_114_SOC
select ARM_ERRATA_798181 if SMP
select HAVE_ARM_ARCH_TIMER
select PINCTRL_TEGRA114
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select TEGRA_TIMER
@@ -51,6 +54,7 @@ config ARCH_TEGRA_124_SOC
bool "Enable support for Tegra124 family"
select HAVE_ARM_ARCH_TIMER
select PINCTRL_TEGRA124
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select TEGRA_TIMER
@@ -66,6 +70,7 @@ if ARM64
 config ARCH_TEGRA_132_SOC
bool "NVIDIA Tegra132 SoC"
select PINCTRL_TEGRA124
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
help
@@ -77,6 +82,7 @@ config ARCH_TEGRA_132_SOC
 config ARCH_TEGRA_210_SOC
bool "NVIDIA Tegra210 SoC"
select PINCTRL_TEGRA210
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select TEGRA_TIMER
@@ -99,6 +105,7 @@ config ARCH_TEGRA_186_SOC
select TEGRA_BPMP
select TEGRA_HSP_MBOX
select TEGRA_IVC
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_PMC
help
  Enable support for the NVIDIA Tegar186 SoC. The Tegra186 features a
@@ -115,6 +122,7 @@ config ARCH_TEGRA_194_SOC
select TEGRA_BPMP
select TEGRA_HSP_MBOX
select TEGRA_IVC
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_PMC
help
  Enable support for the NVIDIA Tegra194 SoC.
@@ -125,6 +133,7 @@ config ARCH_TEGRA_234_SOC
select TEGRA_BPMP
select TEGRA_HSP_MBOX
select TEGRA_IVC
+   select SOC_TEGRA_COMMON
select SOC_TEGRA_PMC
help
  Enable support for the NVIDIA Tegra234 SoC.
@@ -132,6 +141,10 @@ config ARCH_TEGRA_234_SOC
 endif
 endif
 
+config SOC_TEGRA_COMMON
+   bool
+   select PM_OPP
+
 config SOC_TEGRA_FUSE
def_bool y
depends on ARCH_TEGRA
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver

Add myself as the maintainer of the i.MX8qxp DPU DRM driver.

Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* No change.

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 17b92e6..96e05cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5846,6 +5846,15 @@ F:   Documentation/devicetree/bindings/display/imx/
 F: drivers/gpu/drm/imx/
 F: drivers/gpu/ipu-v3/
 
+DRM DRIVERS FOR FREESCALE i.MX8QXP
+M: Liu Ying 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
+F: drivers/gpu/drm/imx/dpu/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-devel@lists.freedesktop.org
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding

This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch.  Otherwise, imx8-lpcg.h
won't be found.

v4->v5:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml

diff --git 
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..9e05c83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+  fetches display data before the display pipeline needs the data to drive
+  pixels in the active display region.  This data is transformed, or resolved,
+  from a variety of tiled buffer formats into linear format, if needed.
+  The DPR works with a double bank memory structure.  This memory structure is
+  implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+  as A and B.  Each bank is either 4 or 8 lines high depending on the source
+  frame buffer format.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-dpr-channel
+  - fsl,imx8qm-dpr-channel
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: apb clock
+  - description: b clock
+  - description: rtram clock
+
+  clock-names:
+items:
+  - const: apb
+  - const: b
+  - const: rtram
+
+  fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+  fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+  List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+  associated with this DPRC instance.
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - fsl,sc-resource
+  - fsl,prgs
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <_prg4>, <_prg5>;
+power-domains = < IMX_SC_R_DC_0>;
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/48] dt-bindings: memory: tegra30: emc: Replace core regulator with power domain

Power domain fits much better than a voltage regulator in regards to
a proper hardware description and from a software perspective as well.
Hence replace the core regulator with the power domain. Note that this
doesn't affect any existing DTBs because we haven't started to use the
regulator yet, and thus, it's okay to change it.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra30-emc.yaml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
index 0a2e2c0d0fdd..7b4af9169b0b 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
@@ -39,9 +39,9 @@ properties:
 description:
   Phandle of the Memory Controller node.
 
-  core-supply:
+  power-domains:
 description:
-  Phandle of voltage regulator of the SoC "core" power domain.
+  Phandle to the SoC "core" power domain.
 
   operating-points-v2:
 description:
@@ -241,7 +241,7 @@ examples:
 
 nvidia,memory-controller = <>;
 operating-points-v2 = <_opp_table>;
-core-supply = <_core>;
+power-domains = <>;
 
 #interconnect-cells = <0>;
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/14] drm/bridge: imx: Add i.MX8qm/qxp display pixel link support

This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays).  It consists of two distinct
functions, a pixel transfer function and a control interface.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig  |   8 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 411 
 3 files changed, 420 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index f1c91b6..4d1f027 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,3 +6,11 @@ config DRM_IMX8QXP_PIXEL_COMBINER
help
  Choose this to enable pixel combiner found in
  Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK
+   tristate "Freescale i.MX8QM/QXP display pixel link"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable display pixel link found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 7d7c8d6..c15469f 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
new file mode 100644
index ..1af7467
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"imx8qxp-display-pixel-link"
+#define PL_MAX_MST_ADDR3
+
+struct imx8qxp_pixel_link {
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct device *dev;
+   struct imx_sc_ipc *ipc_handle;
+   int id;
+   int stream_id;
+   int dc_id;
+   u32 sink_rsc;
+   u32 mst_addr;
+   u8 mst_addr_ctrl;
+   u8 mst_en_ctrl;
+   u8 mst_vld_ctrl;
+   u8 sync_ctrl;
+};
+
+#define DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(name)\
+static void\
+imx8qxp_pixel_link_enable_##name(struct imx8qxp_pixel_link *pl)
\
+{  \
+   int ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc, \
+ pl->name##_ctrl, true);   \
+   if (ret)\
+   DRM_DEV_ERROR(pl->dev,  \
+   "failed to enable DC%d stream%d pixel link "\
+   #name ": %d\n", pl->dc_id, pl->stream_id, ret); \
+}
+
+DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(mst_en)
+DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(mst_vld)
+DEFINE_IMX8QXP_PIXEL_LINK_ENABLE_CTRL(sync)
+
+#define DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(name)   \
+static int \
+imx8qxp_pixel_link_disable_##name(struct imx8qxp_pixel_link *pl)   \
+{  \
+   int ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc, \
+ pl->name##_ctrl, false);  \
+   if (ret)\
+   DRM_DEV_ERROR(pl->dev,  \
+   "failed to disable DC%d stream%d pixel link "   \
+   #name ": %d\n", pl->dc_id, pl->stream_id, ret); \
+   \
+   return ret; \
+}
+
+DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(mst_en)
+DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(mst_vld)
+DEFINE_IMX8QXP_PIXEL_LINK_DISABLE_CTRL(sync)
+
+static void imx8qxp_pixel_link_set_mst_addr(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc_handle,
+ pl->sink_rsc, pl->mst_addr_ctrl,
+ pl->mst_addr);
+   if (ret)
+   DRM_DEV_ERROR(pl->dev,
+   "failed to set DC%d stream%d pixel link mst addr(%u): %d\n",
+   pl->dc_id, pl->stream_id, pl->mst_addr, ret);
+}
+
+static int imx8qxp_pixel_link_bridge_attach(struct

[PATCH v2 14/48] opp: Filter out OPPs based on availability of a required-OPP

A required OPP may not be available, and thus, all OPPs which are using
this required OPP should be unavailable too.

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index d9feb7639598..3d02fe33630b 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1588,7 +1588,7 @@ int _opp_add(struct device *dev, struct dev_pm_opp 
*new_opp,
 struct opp_table *opp_table, bool rate_not_available)
 {
struct list_head *head;
-   int ret;
+   int i, ret;
 
mutex_lock(_table->lock);
head = _table->opp_list;
@@ -1615,6 +1615,15 @@ int _opp_add(struct device *dev, struct dev_pm_opp 
*new_opp,
 __func__, new_opp->rate);
}
 
+   for (i = 0; i < opp_table->required_opp_count && new_opp->available; 
i++) {
+   if (new_opp->required_opps[i]->available)
+   continue;
+
+   new_opp->available = false;
+   dev_warn(dev, "%s: OPP not supported by required OPP %pOF 
(%lu)\n",
+__func__, new_opp->required_opps[i]->np, 
new_opp->rate);
+   }
+
return 0;
 }
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/14] drm/bridge: imx: Add LDB support for i.MX8qm

This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB).
The LDB has two channels.  Each of them supports up to 30bpp parallel
input color format and can map the input to VESA or JEIDA standards.
The two channels can be used simultaneously, either in dual mode or
split mode.  In dual mode, the two channels output identical data.
In split mode, channel0 outputs odd pixels and channel1 outputs even
pixels.  This patch supports the LDB single mode and split mode.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig  |  10 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx8qm-ldb.c | 589 
 3 files changed, 600 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 2a32ad3..46981f3 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,6 +6,16 @@ config DRM_IMX_LVDS_BRIDGE_HELPER
  Helper to support Freescale i.MX LVDS Display Bridge(LDB).
  This bridge is embedded in a SoC.
 
+config DRM_IMX8QM_LDB
+   tristate "Freescale i.MX8QM LVDS display bridge"
+   depends on DRM_IMX_LVDS_BRIDGE_HELPER
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qm processor.
+
 config DRM_IMX8QXP_LDB
tristate "Freescale i.MX8QXP LVDS display bridge"
depends on DRM_IMX_LVDS_BRIDGE_HELPER
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 13160f0..a964efc 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_IMX_LVDS_BRIDGE_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c 
b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
new file mode 100644
index ..9860320
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define  LDB_CH0_10BIT_EN  (1 << 22)
+#define  LDB_CH1_10BIT_EN  (1 << 23)
+#define  LDB_CH0_DATA_WIDTH_24BIT  (1 << 24)
+#define  LDB_CH1_DATA_WIDTH_24BIT  (1 << 26)
+#define  LDB_CH0_DATA_WIDTH_30BIT  (2 << 24)
+#define  LDB_CH1_DATA_WIDTH_30BIT  (2 << 26)
+
+#define SS_CTRL0x20
+#define  CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define  CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define  CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define  CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qm-ldb"
+
+struct imx8qm_ldb_channel {
+   struct ldb_channel base;
+   struct phy *phy;
+};
+
+struct imx8qm_ldb {
+   struct ldb base;
+   struct device *dev;
+   struct imx8qm_ldb_channel channel[MAX_LDB_CHAN_NUM];
+   struct clk *clk_pixel;
+   struct clk *clk_bypass;
+   int active_chno;
+};
+
+static inline struct imx8qm_ldb_channel *
+base_to_imx8qm_ldb_channel(struct ldb_channel *base)
+{
+   return container_of(base, struct imx8qm_ldb_channel, base);
+}
+
+static inline struct imx8qm_ldb *base_to_imx8qm_ldb(struct ldb *base)
+{
+   return container_of(base, struct imx8qm_ldb, base);
+}
+
+static void imx8qm_ldb_set_phy_cfg(struct imx8qm_ldb *imx8qm_ldb,
+  unsigned long di_clk,
+  bool is_split, bool is_slave,
+  struct phy_configure_opts_lvds *phy_cfg)
+{
+   phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+   phy_cfg->lanes = 4;
+   phy_cfg->differential_clk_rate = is_split ? di_clk / 2 : di_clk;
+   phy_cfg->is_slave = is_slave;
+}
+
+static int imx8qm_ldb_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state 
*conn_state)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+   struct imx8qm_ldb_channel *imx8qm_ldb_ch =
+   base_to_imx8qm_ldb_channel(ldb_ch);
+   struct imx8qm_ldb *imx8qm_ldb = base_to_imx8qm_ldb(ldb);
+   struct

[PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()

Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if
levels don't start from 0 in OPP table and zero usually means a minimal
level.

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/core.c | 49 ++
 include/linux/pm_opp.h |  8 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index eab37b3a27bb..0783a4ac819a 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -449,6 +449,55 @@ struct dev_pm_opp *dev_pm_opp_find_level_exact(struct 
device *dev,
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_find_level_exact);
 
+/**
+ * dev_pm_opp_find_level_ceil() - search for an rounded up level
+ * @dev:   device for which we do this operation
+ * @level: level to search for
+ *
+ * Return: Searches for rounded up match in the opp table and returns pointer
+ * to the  matching opp if found, else returns ERR_PTR in case of error and
+ * should be handled using IS_ERR. Error return values can be:
+ * EINVAL: for bad pointer
+ * ERANGE: no match found for search
+ * ENODEV: if device not found in list of registered devices
+ *
+ * The callers are required to call dev_pm_opp_put() for the returned OPP after
+ * use.
+ */
+struct dev_pm_opp *dev_pm_opp_find_level_ceil(struct device *dev,
+ unsigned int *level)
+{
+   struct opp_table *opp_table;
+   struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
+
+   opp_table = _find_opp_table(dev);
+   if (IS_ERR(opp_table)) {
+   int r = PTR_ERR(opp_table);
+
+   dev_err(dev, "%s: OPP table not found (%d)\n", __func__, r);
+   return ERR_PTR(r);
+   }
+
+   mutex_lock(_table->lock);
+
+   list_for_each_entry(temp_opp, _table->opp_list, node) {
+   if (temp_opp->available && temp_opp->level >= *level) {
+   opp = temp_opp;
+   *level = opp->level;
+
+   /* Increment the reference count of OPP */
+   dev_pm_opp_get(opp);
+   break;
+   }
+   }
+
+   mutex_unlock(_table->lock);
+   dev_pm_opp_put_opp_table(opp_table);
+
+   return opp;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_find_level_ceil);
+
 static noinline struct dev_pm_opp *_find_freq_ceil(struct opp_table *opp_table,
   unsigned long *freq)
 {
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index f311a8b2ca04..a17d92d923cc 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -111,6 +111,8 @@ struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device 
*dev,
  bool available);
 struct dev_pm_opp *dev_pm_opp_find_level_exact(struct device *dev,
   unsigned int level);
+struct dev_pm_opp *dev_pm_opp_find_level_ceil(struct device *dev,
+ unsigned int *level);
 
 struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct device *dev,
  unsigned long *freq);
@@ -228,6 +230,12 @@ static inline struct dev_pm_opp 
*dev_pm_opp_find_level_exact(struct device *dev,
return ERR_PTR(-ENOTSUPP);
 }
 
+static inline struct dev_pm_opp *dev_pm_opp_find_level_ceil(struct device *dev,
+   unsigned int *level)
+{
+   return ERR_PTR(-ENOTSUPP);
+}
+
 static inline struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct device *dev,
unsigned long *freq)
 {
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 04/48] dt-bindings: host1x: Document OPP and power domain properties

Document new DVFS OPP table and power domain properties of the Host1x bus
and devices sitting on the bus.

Signed-off-by: Dmitry Osipenko 
---
 .../display/tegra/nvidia,tegra20-host1x.txt   | 49 +++
 1 file changed, 49 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 34d993338453..43c38f01fd77 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -20,6 +20,18 @@ Required properties:
 - reset-names: Must include the following entries:
   - host1x
 
+Optional properties:
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to HEG or core power domain.
+
+For each opp entry in 'operating-points-v2' table of host1x and its modules:
+- opp-supported-hw: One bitfield indicating:
+   On Tegra20: SoC process ID mask
+   On Tegra30+: SoC speedo ID mask
+
+   A bitwise AND is performed against the value and if any bit
+   matches, the OPP gets enabled.
+
 Each host1x client module having to perform DMA through the Memory Controller
 should have the interconnect endpoints set to the Memory Client and External
 Memory respectively.
@@ -45,6 +57,8 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to MPE power domain.
 
 - vi: video input
 
@@ -128,6 +142,8 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to VENC power domain.
 
 - epp: encoder pre-processor
 
@@ -147,6 +163,8 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to HEG or core power domain.
 
 - isp: image signal processor
 
@@ -166,6 +184,7 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - power-domains: Phandle to VENC or core power domain.
 
 - gr2d: 2D graphics engine
 
@@ -185,6 +204,8 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to HEG or core power domain.
 
 - gr3d: 3D graphics engine
 
@@ -209,6 +230,8 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandles to 3D or core power domain.
 
 - dc: display controller
 
@@ -241,6 +264,8 @@ of the following host1x client modules:
   - interconnect-names: Must include name of the interconnect path for each
 interconnect entry. Consult TRM documentation for information about
 available memory clients, see MEMORY CONTROLLER section.
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to core power domain.
 
 - hdmi: High Definition Multimedia Interface
 
@@ -267,6 +292,7 @@ of the following host1x client modules:
   - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
   - nvidia,edid: supplies a binary EDID blob
   - nvidia,panel: phandle of a display panel
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
 
 - tvo: TV encoder output
 
@@ -277,6 +303,10 @@ of the following host1x client modules:
   - clocks: Must contain one entry, for the module clock.
 See ../clocks/clock-bindings.txt for details.
 
+  Optional properties:
+  - operating-points-v2: See ../bindings/opp/opp.txt for details.
+  - power-domains: Phandle to core power domain.
+
 - dsi: display serial interface
 
   Required properties:
@@ -305,6 +335,7 @@ of the

[PATCH v2 08/48] regulator: Make regulator_sync_voltage() usable by coupled regulators

Make regulator_sync_voltage() to re-balance voltage state of a coupled
regulators instead of changing the voltage directly.

Signed-off-by: Dmitry Osipenko 
---
 drivers/regulator/core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ca03d8e70bd1..576efb815eb8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4131,6 +4131,12 @@ int regulator_sync_voltage(struct regulator *regulator)
if (ret < 0)
goto out;
 
+   /* balance only if there are regulators coupled */
+   if (rdev->coupling_desc.n_coupled > 1) {
+   ret = regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+   goto out;
+   }
+
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
 
 out:
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 10/48] opp: Add dev_pm_opp_set_voltage()

Add dev_pm_opp_set_voltage() which allows OPP table users to set voltage
in accordance to a given OPP. In particular this is needed for driving
voltage of a generic power domain which uses OPPs and doesn't have a
clock.

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/core.c | 52 ++
 include/linux/pm_opp.h | 11 +
 2 files changed, 58 insertions(+), 5 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 500d6c716283..eab37b3a27bb 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -2541,3 +2541,55 @@ int dev_pm_opp_sync_regulators(struct device *dev)
return ret;
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_sync_regulators);
+
+/**
+ * dev_pm_opp_set_voltage() - Change voltage of regulators
+ * @dev:   device for which we do this operation
+ * @opp:   opp based on which the voltages are to be configured
+ *
+ * Change voltage of the OPP table regulators.
+ *
+ * Return: 0 on success or a negative error value.
+ */
+int dev_pm_opp_set_voltage(struct device *dev, struct dev_pm_opp *opp)
+{
+   struct opp_table *opp_table;
+   struct regulator *reg;
+   int ret = 0;
+
+   /* Device may not have OPP table */
+   opp_table = _find_opp_table(dev);
+   if (IS_ERR(opp_table))
+   return 0;
+
+   /* Regulator may not be required for the device */
+   if (!opp_table->regulators)
+   goto put_table;
+
+   /* This function only supports single regulator per device */
+   if (WARN_ON(opp_table->regulator_count > 1)) {
+   dev_err(dev, "multiple regulators are not supported\n");
+   ret = -EINVAL;
+   goto put_table;
+   }
+
+   reg = opp_table->regulators[0];
+   ret = _set_opp_voltage(dev, reg, opp->supplies);
+
+   if (!opp_table->enabled) {
+   ret = regulator_enable(reg);
+   if (ret < 0) {
+   dev_warn(dev, "Failed to enable regulator: %d", ret);
+   goto put_table;
+   }
+
+   opp_table->enabled = true;
+   }
+
+put_table:
+   /* Drop reference taken by _find_opp_table() */
+   dev_pm_opp_put_opp_table(opp_table);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_set_voltage);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 4c79faa2025e..f311a8b2ca04 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -157,6 +157,7 @@ int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, 
struct cpumask *cpumask)
 void dev_pm_opp_remove_table(struct device *dev);
 void dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask);
 int dev_pm_opp_sync_regulators(struct device *dev);
+int dev_pm_opp_set_voltage(struct device *dev, struct dev_pm_opp *opp);
 #else
 static inline struct opp_table *dev_pm_opp_get_opp_table(struct device *dev)
 {
@@ -372,6 +373,11 @@ static inline int dev_pm_opp_sync_regulators(struct device 
*dev)
return -ENOTSUPP;
 }
 
+static inline int dev_pm_opp_set_voltage(struct device *dev, struct dev_pm_opp 
*opp)
+{
+   return -ENOTSUPP;
+}
+
 #endif /* CONFIG_PM_OPP */
 
 #if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
@@ -448,11 +454,6 @@ static inline int dev_pm_opp_of_find_icc_paths(struct 
device *dev, struct opp_ta
 {
return -ENOTSUPP;
 }
-
-static inline int dev_pm_opp_sync_regulators(struct device *dev)
-{
-   return -ENOTSUPP;
-}
 #endif
 
 #endif /* __LINUX_OPP_H__ */
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 41/48] memory: tegra20-emc: Use devm_tegra_core_dev_init_opp_table()

Use common devm_tegra_core_dev_init_opp_table() helper for the OPP table
initialization.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 57 +++---
 1 file changed, 4 insertions(+), 53 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 686aaf477d8a..4be847442fc7 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -908,58 +908,6 @@ static int tegra_emc_interconnect_init(struct tegra_emc 
*emc)
return err;
 }
 
-static int tegra_emc_opp_table_init(struct tegra_emc *emc)
-{
-   u32 hw_version = BIT(tegra_sku_info.soc_process_id);
-   struct opp_table *clk_opp_table, *hw_opp_table;
-   int err;
-
-   clk_opp_table = dev_pm_opp_set_clkname(emc->dev, NULL);
-   err = PTR_ERR_OR_ZERO(clk_opp_table);
-   if (err) {
-   dev_err(emc->dev, "failed to set OPP clk: %d\n", err);
-   return err;
-   }
-
-   hw_opp_table = dev_pm_opp_set_supported_hw(emc->dev, _version, 1);
-   err = PTR_ERR_OR_ZERO(hw_opp_table);
-   if (err) {
-   dev_err(emc->dev, "failed to set OPP supported HW: %d\n", err);
-   goto put_clk_table;
-   }
-
-   err = dev_pm_opp_of_add_table(emc->dev);
-   if (err) {
-   if (err == -ENODEV)
-   dev_err(emc->dev, "OPP table not found, please update 
your device tree\n");
-   else
-   dev_err(emc->dev, "failed to add OPP table: %d\n", err);
-
-   goto put_hw_table;
-   }
-
-   dev_info(emc->dev, "OPP HW ver. 0x%x, current clock rate %lu MHz\n",
-hw_version, clk_get_rate(emc->clk) / 100);
-
-   /* first dummy rate-set initializes voltage state */
-   err = dev_pm_opp_set_rate(emc->dev, clk_get_rate(emc->clk));
-   if (err) {
-   dev_err(emc->dev, "failed to initialize OPP clock: %d\n", err);
-   goto remove_table;
-   }
-
-   return 0;
-
-remove_table:
-   dev_pm_opp_of_remove_table(emc->dev);
-put_hw_table:
-   dev_pm_opp_put_supported_hw(hw_opp_table);
-put_clk_table:
-   dev_pm_opp_put_clkname(clk_opp_table);
-
-   return err;
-}
-
 static void devm_tegra_emc_unset_callback(void *data)
 {
tegra20_clk_set_emc_round_callback(NULL, NULL);
@@ -1086,6 +1034,7 @@ static int tegra_emc_devfreq_init(struct tegra_emc *emc)
 
 static int tegra_emc_probe(struct platform_device *pdev)
 {
+   struct tegra_core_opp_params opp_params = {};
struct device_node *np;
struct tegra_emc *emc;
int irq, err;
@@ -1131,7 +1080,9 @@ static int tegra_emc_probe(struct platform_device *pdev)
if (err)
return err;
 
-   err = tegra_emc_opp_table_init(emc);
+   opp_params.init_state = true;
+
+   err = devm_tegra_core_dev_init_opp_table(>dev, _params);
if (err)
return err;
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding

This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch.  Otherwise, imx8-lpcg.h
won't be found.

v4->v5:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../bindings/display/imx/fsl,imx8qxp-prg.yaml  | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+  RTRAM controller and Display Controller.  The main function is to convert
+  the AXI interface to the RTRAM interface, which includes re-mapping the
+  ARADDR to a RTRAM address.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-prg
+  - fsl,imx8qm-prg
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: rtram clock
+  - description: apb clock
+
+  clock-names:
+items:
+  - const: rtram
+  - const: apb
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 48/48] ARM: tegra: cardhu: Support CPU voltage scaling and thermal throttling

Enable CPU voltage scaling and thermal throttling on Tegra30 Cardhu board.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-cardhu.dtsi | 61 ++-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi 
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index d74c9ca78a7f..08c0ea4e6228 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -1,6 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include "tegra30.dtsi"
+#include "tegra30-cpu-opp.dtsi"
+#include "tegra30-cpu-opp-microvolt.dtsi"
 
 /**
  * This file contains common DT entry for all fab version of Cardhu.
@@ -339,12 +342,13 @@ ldo8_reg: ldo8 {
};
};
 
-   temperature-sensor@4c {
+   nct1008: temperature-sensor@4c {
compatible = "onnn,nct1008";
reg = <0x4c>;
vcc-supply = <_3v3_reg>;
interrupt-parent = <>;
interrupts = ;
+   #thermal-sensor-cells = <1>;
};
 
vdd_core: tps62361@60 {
@@ -438,6 +442,29 @@ clk32k_in: clock@0 {
#clock-cells = <0>;
};
 
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
+   };
+
+   cpu@1 {
+   cpu-supply = <_reg>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   cpu@2 {
+   cpu-supply = <_reg>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   cpu@3 {
+   cpu-supply = <_reg>;
+   operating-points-v2 = <_opp_table>;
+   };
+   };
+
panel: panel {
compatible = "chunghwa,claa101wb01";
ddc-i2c-bus = <>;
@@ -617,6 +644,38 @@ sound {
 <_car TEGRA30_CLK_EXTERN1>;
};
 
+   thermal-zones {
+   cpu-thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   thermal-sensors = < 1>;
+
+   trips {
+   trip0: cpu-alert0 {
+   /* throttle at 57C until temperature 
drops to 56.8C */
+   temperature = <57000>;
+   hysteresis = <200>;
+   type = "passive";
+   };
+
+   trip1: cpu-crit {
+   /* shut down at 60C */
+   temperature = <6>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+   };
+
gpio-keys {
compatible = "gpio-keys";
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 22/48] soc/tegra: pmc: Fix imbalanced clock disabling in error code path

The tegra_powergate_power_up() has a typo in the error code path where it
will try to disable clocks twice, fix it. In practice that error never
happens, so this is a minor correction.

Signed-off-by: Dmitry Osipenko 
---
 drivers/soc/tegra/pmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index df9a5ca8c99c..fd2ba3c59178 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -638,7 +638,7 @@ static int tegra_powergate_power_up(struct tegra_powergate 
*pg,
 
err = tegra_powergate_enable_clocks(pg);
if (err)
-   goto disable_clks;
+   goto powergate_off;
 
usleep_range(10, 20);
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: WARNING: suspicious RCU usage in modeset_lock

2020-12-18 Thread Boqun Feng

On Thu, Dec 17, 2020 at 07:21:18AM -0800, Paul E. McKenney wrote:
> On Thu, Dec 17, 2020 at 11:03:20AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney  wrote:
> > >
> > > On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> > > > On Wed, Dec 16, 2020 at 2:14 AM syzbot
> > > >  wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following issue on:
> > > > >
> > > > > HEAD commit:94801e5c Merge tag 'pinctrl-v5.10-3' of 
> > > > > git://git.kernel.o..
> > > > > git tree:   upstream
> > > > > console output: 
> > > > > https://syzkaller.appspot.com/x/log.txt?x=130558c550
> > > > > kernel config:  
> > > > > https://syzkaller.appspot.com/x/.config?x=ee8a1012a5314210
> > > > > dashboard link: 
> > > > > https://syzkaller.appspot.com/bug?extid=972b924c988834e868b2
> > > > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > > > userspace arch: i386
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > > >
> > > > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > > > commit:
> > > > > Reported-by: syzbot+972b924c988834e86...@syzkaller.appspotmail.com
> > > > >
> > > > > =
> > > > > WARNING: suspicious RCU usage
> > > > > 5.10.0-rc7-syzkaller #0 Not tainted
> > > > > -
> > > > > kernel/sched/core.c:7270 Illegal context switch in RCU-sched 
> > > > > read-side critical section!
> > > > >
> > > > > other info that might help us debug this:
> > > > >
> > > > >
> > > > > rcu_scheduler_active = 2, debug_locks = 0
> > > > > 7 locks held by syz-executor.1/9232:
> > > > >  #0: 8b328c60 (console_lock){+.+.}-{0:0}, at: 
> > > > > do_fb_ioctl+0x2e4/0x690 drivers/video/fbdev/core/fbmem.c:1106
> > > > >  #1: 888041bd4078 (_info->lock){+.+.}-{3:3}, at: lock_fb_info 
> > > > > include/linux/fb.h:636 [inline]
> > > > >  #1: 888041bd4078 (_info->lock){+.+.}-{3:3}, at: 
> > > > > do_fb_ioctl+0x2ee/0x690 drivers/video/fbdev/core/fbmem.c:1107
> > > > >  #2: 888041adca78 (>lock){+.+.}-{3:3}, at: 
> > > > > drm_fb_helper_pan_display+0xce/0x970 
> > > > > drivers/gpu/drm/drm_fb_helper.c:1448
> > > > >  #3: 8880159f01b8 (>master_mutex){+.+.}-{3:3}, at: 
> > > > > drm_master_internal_acquire+0x1d/0x70 drivers/gpu/drm/drm_auth.c:407
> > > > >  #4: 888041adc898 (>modeset_mutex){+.+.}-{3:3}, at: 
> > > > > drm_client_modeset_commit_locked+0x44/0x580 
> > > > > drivers/gpu/drm/drm_client_modeset.c:1143
> > > > >  #5: c90001c07730 (crtc_ww_class_acquire){+.+.}-{0:0}, at: 
> > > > > drm_client_modeset_commit_atomic+0xb7/0x7c0 
> > > > > drivers/gpu/drm/drm_client_modeset.c:981
> > > > >  #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at: 
> > > > > ww_mutex_lock_slow include/linux/ww_mutex.h:287 [inline]
> > > > >  #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at: 
> > > > > modeset_lock+0x31c/0x650 drivers/gpu/drm/drm_modeset_lock.c:260
> > > >
> > > > Given that we managed to take all these locks without upsetting anyone
> > > > the rcu section is very deep down. And looking at the backtrace below
> > > > I just couldn't find anything.
> > > >
> > > > Best I can think of is that an interrupt of some sort leaked an rcu
> > > > section, and we got shot here. But I'd assume the rcu debugging would
> > > > catch this? Backtrace of the start of that rcu read side section would
> > > > be really useful here, but I'm not seeing that in the logs. There's
> > > > more stuff there, but it's just the usual "everything falls apart"
> > > > stuff of little value to understanding how we got there.
> > >
> > > In my experience, lockdep will indeed complain if an interrupt handler
> > > returns while in an RCU read-side critical section.
> > >
> > > > Adding some rcu people for more insights on what could have gone wrong 
> > > > here.
> > > > -Daniel
> > > >
> > > > > stack backtrace:
> > > > > CPU: 1 PID: 9232 Comm: syz-executor.1 Not tainted 
> > > > > 5.10.0-rc7-syzkaller #0
> > > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> > > > > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> > > > > Call Trace:
> > > > >  __dump_stack lib/dump_stack.c:77 [inline]
> > > > >  dump_stack+0x107/0x163 lib/dump_stack.c:118
> > > > >  ___might_sleep+0x25d/0x2b0 kernel/sched/core.c:7270
> > > > >  __mutex_lock_common kernel/locking/mutex.c:935 [inline]
> > > > >  __ww_mutex_lock.constprop.0+0xa9/0x2cc0 kernel/locking/mutex.c:
> > > > >  ww_mutex_lock+0x3d/0x170 kernel/locking/mutex.c:1190
> > >
> > > Acquiring a mutex while under the influence of rcu_read_lock() will
> > > definitely get you this lockdep complaint, and rightfully so.
> > >
> > > If you need to acquire a mutex with RCU-like protection, one approach
> > > is to use SRCU.  But usually this indicates (as you suspected) that
> > > someone forgot to invoke rcu_read_unlock().
> > >
> > > One way to locate this is to enlist the aid of

[PATCH v5 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM

Hi,


This patch set introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support.

DPU is comprised of a blit engine for 2D graphics, a display controller
and a command sequencer.  Outside of DPU, optional prefetch engines can
fetch data from memory prior to some DPU fetchunits of blit engine and
display controller.  The pre-fetchers support linear formats and Vivante
GPU tile formats.

Reference manual can be found at:
https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM


This patch set adds kernel modesetting support for the display controller part.
It supports two CRTCs per display controller, several planes, prefetch
engines and some properties of CRTC and plane.  Currently, the registers of
the controller is accessed without command sequencer involved, instead just by
using CPU.  DRM connectors would be created from the DPU KMS driver.


If people want to try this series with i.MX8qxp, clock patches can be found at:
https://www.spinics.net/lists/arm-kernel/msg859763.html

and, power domain patches have already landed in Shawn's
i.MX for-next git branch.

Version2 dropped the device tree patches because we'll use new dt binding
way to support i.MX8qm/qxp clocks.  It depends on the below series to do basic
conversions for the platforms which has not landed yet:
https://www.spinics.net/lists/linux-mmc/msg61965.html


I've sent the below series to add downstream bridges(embedded in i.MX8qm/qxp)
to support LVDS displays:
https://www.spinics.net/lists/linux-media/msg183650.html


Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines.
Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver
uses it.
Patch 5 introduces the DPU DRM support.
Patch 6 updates MAINTAINERS.

Welcome comments, thanks.

v4->v5:
* Rebase up onto the latest drm-misc-next branch and remove the hook to
  drm_atomic_helper_legacy_gamma_set() from patch 5/6, because it was dropped
  by the newly landed commit 'drm: automatic legacy gamma support'.
* Remove a redundant blank line from dpu_plane_atomic_update() in patch 5/6.

v3->v4:
* Improve compatible properties in DPU and prefetch engines' dt bindings
  by using enum instead of oneOf+const.
* Add Rob's R-b tags on dt binding patches(patch 1/6, 2/6 and 3/6).
* Add Daniel's A-b tag on patch 4/6.

v2->v3:
* Fix DPU DRM driver build warnings which are
  Reported-by: kernel test robot .
* Drop DPU DRM driver build dependency on IMX_SCU, as dummy SCU functions have
  been added in header files by the patch 'firmware: imx: add dummy functions'
  which has landed in linux-next/master branch.
* Add a missing blank line in include/drm/drm_atomic.h.

v1->v2:
* Test this patch set also with i.MX8qm LVDS displays.
* Drop the device tree patches because we'll use new dt binding way to
  support i.MX8qm/qxp clocks.  This depends on a not-yet-landed patch set
  to do basic conversions for the platforms.
* Fix dt binding yamllint warnings.
* Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's
  dt binding documentation.
* Use new dt binding way to add clocks in the dt binding examples.
* Address several comments from Laurentiu on the DPU DRM patch.

Liu Ying (6):
  dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
  dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
  dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
  drm/atomic: Avoid unused-but-set-variable warning on
for_each_old_plane_in_state
  drm/imx: Introduce i.MX8qm/qxp DPU DRM
  MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver

 .../bindings/display/imx/fsl,imx8qxp-dprc.yaml |  87 ++
 .../bindings/display/imx/fsl,imx8qxp-dpu.yaml  | 416 +
 .../bindings/display/imx/fsl,imx8qxp-prg.yaml  |  60 ++
 MAINTAINERS|   9 +
 drivers/gpu/drm/imx/Kconfig|   1 +
 drivers/gpu/drm/imx/Makefile   |   1 +
 drivers/gpu/drm/imx/dpu/Kconfig|  10 +
 drivers/gpu/drm/imx/dpu/Makefile   |  10 +
 drivers/gpu/drm/imx/dpu/dpu-constframe.c   | 170 
 drivers/gpu/drm/imx/dpu/dpu-core.c | 881 
 drivers/gpu/drm/imx/dpu/dpu-crtc.c | 925 +
 drivers/gpu/drm/imx/dpu/dpu-crtc.h |  62 ++
 drivers/gpu/drm/imx/dpu/dpu-disengcfg.c| 114 +++
 drivers/gpu/drm/imx/dpu/dpu-dprc.c | 721 
 drivers/gpu/drm/imx/dpu/dpu-dprc.h |  40 +
 drivers/gpu/drm/imx/dpu/dpu-drv.c  | 297 +++
 drivers/gpu/drm/imx/dpu/dpu-drv.h  |  28 +
 drivers/gpu/drm/imx/dpu/dpu-extdst.c   | 296 +++
 drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c  | 291 +++
 drivers/gpu/drm/imx/dpu/dpu-fetcheco.c | 221 +
 drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c   | 151 
 drivers/gpu/drm/imx/dpu/dpu-fetchunit.c| 609 ++

[PATCH v2 19/48] opp: Fix adding OPP entries in a wrong order if rate is unavailable

Fix adding OPP entries in a wrong (opposite) order if OPP rate is
unavailable. The OPP comparison is erroneously skipped if OPP rate is
missing, thus OPPs are left unsorted.

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/core.c | 23 ---
 drivers/opp/opp.h  |  2 +-
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 34f7e530d941..5c7f130a8de2 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1531,9 +1531,10 @@ static bool _opp_supported_by_regulators(struct 
dev_pm_opp *opp,
return true;
 }
 
-int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
+int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2,
+bool rate_not_available)
 {
-   if (opp1->rate != opp2->rate)
+   if (!rate_not_available && opp1->rate != opp2->rate)
return opp1->rate < opp2->rate ? -1 : 1;
if (opp1->bandwidth && opp2->bandwidth &&
opp1->bandwidth[0].peak != opp2->bandwidth[0].peak)
@@ -1545,7 +1546,8 @@ int _opp_compare_key(struct dev_pm_opp *opp1, struct 
dev_pm_opp *opp2)
 
 static int _opp_is_duplicate(struct device *dev, struct dev_pm_opp *new_opp,
 struct opp_table *opp_table,
-struct list_head **head)
+struct list_head **head,
+bool rate_not_available)
 {
struct dev_pm_opp *opp;
int opp_cmp;
@@ -1559,13 +1561,13 @@ static int _opp_is_duplicate(struct device *dev, struct 
dev_pm_opp *new_opp,
 * loop.
 */
list_for_each_entry(opp, _table->opp_list, node) {
-   opp_cmp = _opp_compare_key(new_opp, opp);
+   opp_cmp = _opp_compare_key(new_opp, opp, rate_not_available);
if (opp_cmp > 0) {
*head = >node;
continue;
}
 
-   if (opp_cmp < 0)
+   if (opp_cmp < 0 || rate_not_available)
return 0;
 
/* Duplicate OPPs */
@@ -1601,12 +1603,11 @@ int _opp_add(struct device *dev, struct dev_pm_opp 
*new_opp,
mutex_lock(_table->lock);
head = _table->opp_list;
 
-   if (likely(!rate_not_available)) {
-   ret = _opp_is_duplicate(dev, new_opp, opp_table, );
-   if (ret) {
-   mutex_unlock(_table->lock);
-   return ret;
-   }
+   ret = _opp_is_duplicate(dev, new_opp, opp_table, ,
+   rate_not_available);
+   if (ret) {
+   mutex_unlock(_table->lock);
+   return ret;
}
 
list_add(_opp->node, head);
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index 4ced7ffa8158..6f5be6c72f13 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -219,7 +219,7 @@ struct opp_table *_find_opp_table(struct device *dev);
 struct opp_device *_add_opp_dev(const struct device *dev, struct opp_table 
*opp_table);
 struct dev_pm_opp *_opp_allocate(struct opp_table *opp_table);
 void _opp_free(struct dev_pm_opp *opp);
-int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2);
+int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2, bool 
rate_not_available);
 int _opp_add(struct device *dev, struct dev_pm_opp *new_opp, struct opp_table 
*opp_table, bool rate_not_available);
 int _opp_add_v1(struct opp_table *opp_table, struct device *dev, unsigned long 
freq, long u_volt, bool dynamic);
 void _dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask, int 
last_cpu);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/14] MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs

Add myself as the maintainer of DRM bridge drivers for i.MX SoCs.

Signed-off-by: Liu Ying 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7b073c4..4b4e40e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5846,6 +5846,16 @@ F:   Documentation/devicetree/bindings/display/imx/
 F: drivers/gpu/drm/imx/
 F: drivers/gpu/ipu-v3/
 
+DRM DRIVERS FOR FREESCALE IMX BRIDGE
+M: Liu Ying 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
+F: drivers/gpu/drm/bridge/imx/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-devel@lists.freedesktop.org
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/6] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight

2020-12-18 Thread cy_huang

From: ChiYuan Huang 

Adds DT binding document for Richtek RT4831 backlight.

Signed-off-by: ChiYuan Huang 
---
since v5
- Drop the example in dt-binding. Aready full example in mfd dt-binding.

since v3
- Move inlcude/dt-bindings/leds/rt4831-backlight.h from patch 0004 to here.
- Add dual license tag in header and backlight binding document.
- Left backlight dt-binding example only.
---
 .../leds/backlight/richtek,rt4831-backlight.yaml   | 65 ++
 include/dt-bindings/leds/rt4831-backlight.h| 23 
 2 files changed, 88 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
 create mode 100644 include/dt-bindings/leds/rt4831-backlight.h

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
 
b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
new file mode 100644
index ..4da6a66
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/leds/backlight/richtek,rt4831-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT4831 Backlight
+
+maintainers:
+  - ChiYuan Huang 
+
+description: |
+  RT4831 is a mutifunctional device that can provide power to the LCD display
+  and LCD backlight.
+
+  For the LCD backlight, it can provide four channel WLED driving capability.
+  Each channel driving current is up to 30mA
+
+  Datasheet is available at
+  https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf
+
+properties:
+  compatible:
+const: richtek,rt4831-backlight
+
+  default-brightness:
+description: |
+  The default brightness that applied to the system on start-up.
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 2048
+
+  max-brightness:
+description: |
+  The max brightness for the H/W limit
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 2048
+
+  richtek,pwm-enable:
+description: |
+  Specify the backlight dimming following by PWM duty or by SW control.
+type: boolean
+
+  richtek,bled-ovp-sel:
+description: |
+  Backlight OVP level selection, currently support 17V/21V/25V/29V.
+$ref: /schemas/types.yaml#/definitions/uint8
+default: 1
+minimum: 0
+maximum: 3
+
+  richtek,channel-use:
+description: |
+  Backlight LED channel to be used.
+  BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable or disable.
+$ref: /schemas/types.yaml#/definitions/uint8
+minimum: 1
+maximum: 15
+
+required:
+  - compatible
+  - richtek,channel-use
+
+additionalProperties: false
diff --git a/include/dt-bindings/leds/rt4831-backlight.h 
b/include/dt-bindings/leds/rt4831-backlight.h
new file mode 100644
index ..125c635
--- /dev/null
+++ b/include/dt-bindings/leds/rt4831-backlight.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * This header provides constants for rt4831 backlight bindings.
+ *
+ * Copyright (C) 2020, Richtek Technology Corp.
+ * Author: ChiYuan Huang 
+ */
+
+#ifndef _DT_BINDINGS_RT4831_BACKLIGHT_H
+#define _DT_BINDINGS_RT4831_BACKLIGHT_H
+
+#define RT4831_BLOVPLVL_17V0
+#define RT4831_BLOVPLVL_21V1
+#define RT4831_BLOVPLVL_25V2
+#define RT4831_BLOVPLVL_29V3
+
+#define RT4831_BLED_CH1EN  (1 << 0)
+#define RT4831_BLED_CH2EN  (1 << 1)
+#define RT4831_BLED_CH3EN  (1 << 2)
+#define RT4831_BLED_CH4EN  (1 << 3)
+#define RT4831_BLED_ALLCHEN((1 << 4) - 1)
+
+#endif /* _DT_BINDINGS_RT4831_BACKLIGHT_H */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 47/48] ARM: tegra: ventana: Support CPU voltage scaling and thermal throttling

Enable CPU voltage scaling and thermal throttling on Tegra20 Ventana board.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-ventana.dts | 40 ++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra20-ventana.dts 
b/arch/arm/boot/dts/tegra20-ventana.dts
index 14ace2ef749c..c2d9f38960bc 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -2,8 +2,10 @@
 /dts-v1/;
 
 #include 
+#include 
 #include "tegra20.dtsi"
 #include "tegra20-cpu-opp.dtsi"
+#include "tegra20-cpu-opp-microvolt.dtsi"
 
 / {
model = "NVIDIA Tegra20 Ventana evaluation board";
@@ -527,9 +529,10 @@ ldo_rtc {
};
};
 
-   temperature-sensor@4c {
+   nct1008: temperature-sensor@4c {
compatible = "onnn,nct1008";
reg = <0x4c>;
+   #thermal-sensor-cells = <1>;
};
};
 
@@ -615,10 +618,13 @@ clk32k_in: clock@0 {
 
cpus {
cpu0: cpu@0 {
+   cpu-supply = <_cpu>;
operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
};
 
cpu@1 {
+   cpu-supply = <_cpu>;
operating-points-v2 = <_opp_table>;
};
};
@@ -717,4 +723,36 @@ sound {
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   thermal-zones {
+   cpu-thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <5000>; /* milliseconds */
+
+   thermal-sensors = < 1>;
+
+   trips {
+   trip0: cpu-alert0 {
+   /* start throttling at 50C */
+   temperature = <5>;
+   hysteresis = <200>;
+   type = "passive";
+   };
+
+   trip1: cpu-crit {
+   /* shut down at 60C */
+   temperature = <6>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+   };
 };
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 15/48] opp: Support set_opp() customization without requiring to use regulators

Support set_opp() customization without requiring to use regulators. This
is needed by drivers which want to use dev_pm_opp_set_rate() for changing
rates of a multiple clocks and don't need to touch regulator.

One example is NVIDIA Tegra30/114 SoCs which have two sibling 3D hardware
units which should be use to the same clock rate, meanwhile voltage
scaling is done using a power domain. In this case OPP table doesn't have
a regulator, causing a NULL dereference in _set_opp_custom().

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/core.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 3d02fe33630b..625dae7a5ecb 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -828,17 +828,25 @@ static int _set_opp_custom(const struct opp_table 
*opp_table,
   struct dev_pm_opp_supply *old_supply,
   struct dev_pm_opp_supply *new_supply)
 {
-   struct dev_pm_set_opp_data *data;
+   struct dev_pm_set_opp_data *data, tmp_data;
+   unsigned int regulator_count;
int size;
 
-   data = opp_table->set_opp_data;
+   if (opp_table->set_opp_data) {
+   data = opp_table->set_opp_data;
+   regulator_count = opp_table->regulator_count;
+   } else {
+   data = _data;
+   regulator_count = 0;
+   }
+
data->regulators = opp_table->regulators;
-   data->regulator_count = opp_table->regulator_count;
+   data->regulator_count = regulator_count;
data->clk = opp_table->clk;
data->dev = dev;
 
data->old_opp.rate = old_freq;
-   size = sizeof(*old_supply) * opp_table->regulator_count;
+   size = sizeof(*old_supply) * regulator_count;
if (!old_supply)
memset(data->old_opp.supplies, 0, size);
else
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 47/48] ARM: tegra: ventana: Support CPU voltage scaling and thermal throttling

17.12.2020 21:28, Daniel Lezcano пишет:
> On 17/12/2020 19:06, Dmitry Osipenko wrote:
>> Enable CPU voltage scaling and thermal throttling on Tegra20 Ventana board.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  arch/arm/boot/dts/tegra20-ventana.dts | 40 ++-
>>  1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra20-ventana.dts 
>> b/arch/arm/boot/dts/tegra20-ventana.dts
>> index 14ace2ef749c..c2d9f38960bc 100644
>> --- a/arch/arm/boot/dts/tegra20-ventana.dts
>> +++ b/arch/arm/boot/dts/tegra20-ventana.dts
>> @@ -2,8 +2,10 @@
>>  /dts-v1/;
>>  
>>  #include 
>> +#include 
>>  #include "tegra20.dtsi"
>>  #include "tegra20-cpu-opp.dtsi"
>> +#include "tegra20-cpu-opp-microvolt.dtsi"
>>  
>>  / {
>>  model = "NVIDIA Tegra20 Ventana evaluation board";
>> @@ -527,9 +529,10 @@ ldo_rtc {
>>  };
>>  };
>>  
>> -temperature-sensor@4c {
>> +nct1008: temperature-sensor@4c {
>>  compatible = "onnn,nct1008";
>>  reg = <0x4c>;
>> +#thermal-sensor-cells = <1>;
>>  };
>>  };
>>  
>> @@ -615,10 +618,13 @@ clk32k_in: clock@0 {
>>  
>>  cpus {
>>  cpu0: cpu@0 {
>> +cpu-supply = <_cpu>;
>>  operating-points-v2 = <_opp_table>;
>> +#cooling-cells = <2>;
>>  };
>>  
>>  cpu@1 {
>> +cpu-supply = <_cpu>;
>>  operating-points-v2 = <_opp_table>;
>>  };
>>  };
>> @@ -717,4 +723,36 @@ sound {
>>   <_car TEGRA20_CLK_CDEV1>;
>>  clock-names = "pll_a", "pll_a_out0", "mclk";
>>  };
>> +
>> +thermal-zones {
>> +cpu-thermal {
>> +polling-delay-passive = <1000>; /* milliseconds */
>> +polling-delay = <5000>; /* milliseconds */
>> +
>> +thermal-sensors = < 1>;
>> +
>> +trips {
>> +trip0: cpu-alert0 {
>> +/* start throttling at 50C */
>> +temperature = <5>;
>> +hysteresis = <200>;
> 
> Did you mean <2000> ?

The <200> is correct.

Please see this commit for example:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b22393b27670b45a2c870bce3df6579efd9a86a

>> +type = "passive";
>> +};
>> +
>> +trip1: cpu-crit {
>> +/* shut down at 60C */
>> +temperature = <6>;
>> +hysteresis = <2000>;
> 
> I think you can drop the hysteresis here, when the critical temperature
> is reached, there is an emergency shutdown.

Yes, perhaps you're right. Hysteresis doesn't make sense for a critical
trip. I'll improve it in the next revision, thanks.

> 50°C and 60°C sound very low values, no ?

Tegra20 CPU is very cold in comparison to later generations, it should
stay under 50°C even at a full load.

>> +type = "critical";
>> +};
>> +};
>> +
>> +cooling-maps {
>> +map0 {
>> +trip = <>;
>> +cooling-device = < 
>> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 
> You should add all CPUs here.


All CPU cores are coupled on Tegra in regards to CPUFreq, hence I think
it won't make any difference if secondary CPU cores will be added here,
isn't it?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state

Artifically use 'plane' and 'old_plane_state' to avoid 'not used' warning.
The precedent has already been set by other macros in the same file.

Acked-by: Daniel Vetter 
Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* Add Daniel's A-b tag.

v2->v3:
* Add a missing blank line.

v1->v2:
* No change.

 include/drm/drm_atomic.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index ce7023e..6ade7a1 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -908,7 +908,10 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if ((__state)->planes[__i].ptr &&  \
 ((plane) = (__state)->planes[__i].ptr, \
- (old_plane_state) = 
(__state)->planes[__i].old_state, 1))
+ (void)(plane) /* Only to avoid 
unused-but-set-variable warning */, \
+ (old_plane_state) = 
(__state)->planes[__i].old_state, \
+ (void)(old_plane_state) /* Only to avoid 
unused-but-set-variable warning */, 1))
+
 /**
  * for_each_new_plane_in_state - iterate over all planes in an atomic update
  * @__state:  drm_atomic_state pointer
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v6] drm/bridge: add it6505 driver

2020-12-18 Thread allen.chen

Hi Mathieu

For google reference design(mt8183+it6505), the maximum 95000kHz is depends on 
mt8183 requirement.

-Original Message-
From: Mathieu Tournier [mailto:mathieutourn...@gmail.com] 
Sent: Thursday, December 17, 2020 2:47 AM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Kenneth Hung (洪家倫); 
laurent.pinch...@ideasonboard.com; a.ha...@samsung.com; airl...@linux.ie; 
dri-devel@lists.freedesktop.org; Hermes Wu (吳佳宏); jernej.skra...@siol.net; 
jitao@mediatek.com; jo...@kwiboo.se; linux-arm-ker...@lists.infradead.org; 
linux-ker...@vger.kernel.org; linux-media...@lists.infradead.org; 
matthias@gmail.com; narmstr...@baylibre.com; pih...@chromium.org; 
yl...@google.com
Subject: Re: [PATCH v6] drm/bridge: add it6505 driver

Hi Allen.

As it6505 is compatible with DisplayPort 1.1a,
Should DPI_PIXEL_CLK_MAX be 165 000 instead of 95 000 khz ?
This would permit 1080p support, as it may be supported.

Mathieu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 18/48] opp: Print OPP level in debug message of _opp_add_static_v2()

Print OPP level in debug message of _opp_add_static_v2(). This helps to
chase GENPD bugs.

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/of.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 1f2038a4420b..56b153ea5c56 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -822,10 +822,11 @@ static struct dev_pm_opp *_opp_add_static_v2(struct 
opp_table *opp_table,
if (new_opp->clock_latency_ns > opp_table->clock_latency_ns_max)
opp_table->clock_latency_ns_max = new_opp->clock_latency_ns;
 
-   pr_debug("%s: turbo:%d rate:%lu uv:%lu uvmin:%lu uvmax:%lu 
latency:%lu\n",
+   pr_debug("%s: turbo:%d rate:%lu uv:%lu uvmin:%lu uvmax:%lu latency:%lu 
level:%u\n",
 __func__, new_opp->turbo, new_opp->rate,
 new_opp->supplies[0].u_volt, new_opp->supplies[0].u_volt_min,
-new_opp->supplies[0].u_volt_max, new_opp->clock_latency_ns);
+new_opp->supplies[0].u_volt_max, new_opp->clock_latency_ns,
+new_opp->level);
 
/*
 * Notify the changes in the availability of the operable
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/14] drm/bridge: imx: Add i.MX8qxp pixel link to DPI support

This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI).  The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color codings between those modules. The PXL2DPI is purely
combinatorial.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/imx/Kconfig   |   8 +
 drivers/gpu/drm/bridge/imx/Makefile  |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 494 +++
 3 files changed, 503 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 4d1f027..1ea1ce7 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -14,3 +14,11 @@ config DRM_IMX8QXP_PIXEL_LINK
help
  Choose this to enable display pixel link found in
  Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
+   tristate "Freescale i.MX8QXP pixel link to display pixel interface"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable pixel link to display pixel interface(PXL2DPI)
+ found in Freescale i.MX8qxp processor.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index c15469f..e74dd64 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
new file mode 100644
index ..95ed89e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -0,0 +1,494 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define PXL2DPI_CTRL   0x40
+#define  CFG1_16BIT0x0
+#define  CFG2_16BIT0x1
+#define  CFG3_16BIT0x2
+#define  CFG1_18BIT0x3
+#define  CFG2_18BIT0x4
+#define  CFG_24BIT 0x5
+
+#define DRIVER_NAME"imx8qxp-pxl2dpi"
+
+struct imx8qxp_pxl2dpi {
+   struct regmap *regmap;
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct drm_bridge *companion;
+   struct device *dev;
+   struct imx_sc_ipc *ipc_handle;
+   u32 rsc;
+   u32 in_bus_format;
+   u32 out_bus_format;
+   u32 pl_sel;
+   int id;
+};
+
+#define bridge_to_p2d(b)   container_of(b, struct imx8qxp_pxl2dpi, bridge)
+
+static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+   DRM_DEV_ERROR(p2d->dev,
+ "do not support creating a drm_connector\n");
+   return -EINVAL;
+   }
+
+   if (!bridge->encoder) {
+   DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
+   return -ENODEV;
+   }
+
+   return drm_bridge_attach(bridge->encoder,
+p2d->next_bridge, bridge,
+DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static int
+imx8qxp_pxl2dpi_bridge_atomic_check(struct drm_bridge *bridge,
+   struct drm_bridge_state *bridge_state,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+   p2d->in_bus_format = bridge_state->input_bus_cfg.format;
+   p2d->out_bus_format = bridge_state->output_bus_cfg.format;
+
+   return 0;
+}
+
+static void
+imx8qxp_pxl2dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+   struct imx8qxp_pxl2dpi *companion_p2d;
+   int ret;
+
+   ret = pm_runtime_get_sync(p2d->dev);
+   if (ret < 0)
+   DRM_DEV_ERROR(p2d->dev,
+ "failed to get runtime PM sync: %d\n", ret);
+
+   ret = imx_sc_misc_set_control(p2d->ipc_handle, p2d->rsc,
+ IMX_SC_C_PXL_LINK_SEL, p2d->pl_sel);
+   if (ret)
+   DRM_DEV_ERROR(p2d->dev,
+ "failed to set pixel link selection(%u): %d\n",
+

Re: [PATCH v2 34/48] gpu: host1x: Support power management

17.12.2020 21:45, Dmitry Osipenko пишет:
> 17.12.2020 21:21, Mikko Perttunen пишет:
>> On 12/17/20 8:06 PM, Dmitry Osipenko wrote:
>>> Add suspend/resume and generic power domain support to the Host1x driver.
>>> This is required for enabling system-wide DVFS and supporting dynamic
>>> power management using a generic power domain.
>>>
>>> Tested-by: Peter Geis 
>>> Tested-by: Nicolas Chauvet 
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>   drivers/gpu/host1x/dev.c | 102 ++-
>>>   1 file changed, 91 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
>>> index d0ebb70e2fdd..c1525cffe7b1 100644
>>> --- a/drivers/gpu/host1x/dev.c
>>> +++ b/drivers/gpu/host1x/dev.c
>>> @@ -12,6 +12,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>     #define CREATE_TRACE_POINTS
>>> @@ -417,7 +418,7 @@ static int host1x_probe(struct platform_device *pdev)
>>>   return err;
>>>   }
>>>   -    host->rst = devm_reset_control_get(>dev, "host1x");
>>> +    host->rst = devm_reset_control_get_exclusive_released(>dev,
>>> "host1x");
>>>   if (IS_ERR(host->rst)) {
>>>   err = PTR_ERR(host->rst);
>>>   dev_err(>dev, "failed to get reset: %d\n", err);
>>> @@ -437,16 +438,15 @@ static int host1x_probe(struct platform_device
>>> *pdev)
>>>   goto iommu_exit;
>>>   }
>>>   -    err = clk_prepare_enable(host->clk);
>>> -    if (err < 0) {
>>> -    dev_err(>dev, "failed to enable clock\n");
>>> -    goto free_channels;
>>> -    }
>>> +    pm_runtime_enable(>dev);
>>> +    err = pm_runtime_get_sync(>dev);
>>> +    if (err < 0)
>>> +    goto rpm_disable;
>>>     err = reset_control_deassert(host->rst);
>>>   if (err < 0) {
>>>   dev_err(>dev, "failed to deassert reset: %d\n", err);
>>> -    goto unprepare_disable;
>>> +    goto rpm_disable;
>>>   }
>>>     err = host1x_syncpt_init(host);
>>> @@ -485,9 +485,10 @@ static int host1x_probe(struct platform_device
>>> *pdev)
>>>   host1x_syncpt_deinit(host);
>>>   reset_assert:
>>>   reset_control_assert(host->rst);
>>> -unprepare_disable:
>>> -    clk_disable_unprepare(host->clk);
>>> -free_channels:
>>> +rpm_disable:
>>> +    pm_runtime_put(>dev);
>>> +    pm_runtime_disable(>dev);
>>> +
>>>   host1x_channel_list_free(>channel_list);
>>>   iommu_exit:
>>>   host1x_iommu_exit(host);
>>> @@ -504,16 +505,95 @@ static int host1x_remove(struct platform_device
>>> *pdev)
>>>   host1x_intr_deinit(host);
>>>   host1x_syncpt_deinit(host);
>>>   reset_control_assert(host->rst);
>>> -    clk_disable_unprepare(host->clk);
>>> +    pm_runtime_put(>dev);
>>> +    pm_runtime_disable(>dev);
>>>   host1x_iommu_exit(host);
>>>     return 0;
>>>   }
>>>   +static int __maybe_unused host1x_runtime_suspend(struct device *dev)
>>> +{
>>> +    struct host1x *host = dev_get_drvdata(dev);
>>> +
>>> +    clk_disable_unprepare(host->clk);
>>> +    reset_control_release(host->rst);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int __maybe_unused host1x_runtime_resume(struct device *dev)
>>> +{
>>> +    struct host1x *host = dev_get_drvdata(dev);
>>> +    int err;
>>> +
>>> +    err = reset_control_acquire(host->rst);
>>> +    if (err) {
>>> +    dev_err(dev, "failed to acquire reset: %d\n", err);
>>> +    return err;
>>> +    }
>>> +
>>> +    err = clk_prepare_enable(host->clk);
>>> +    if (err) {
>>> +    dev_err(dev, "failed to enable clock: %d\n", err);
>>> +    goto release_reset;
>>> +    }
>>> +
>>> +    return 0;
>>> +
>>> +release_reset:
>>> +    reset_control_release(host->rst);
>>> +
>>> +    return err;
>>> +}
>>> +
>>> +static __maybe_unused int host1x_suspend(struct device *dev)
>>> +{
>>> +    struct host1x *host = dev_get_drvdata(dev);
>>> +    int err;
>>> +
>>> +    host1x_syncpt_save(host);
>>> +
>>> +    err = pm_runtime_force_suspend(dev);
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static __maybe_unused int host1x_resume(struct device *dev)
>>> +{
>>> +    struct host1x *host = dev_get_drvdata(dev);
>>> +    struct host1x_channel *channel;
>>> +    unsigned int index;
>>> +    int err;
>>> +
>>> +    err = pm_runtime_force_resume(dev);
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    host1x_syncpt_restore(host);
>>
>> We also need to execute 'host1x_setup_sid_table' upon resume.
> 
> Indeed, thanks. I'll correct it in the next revision.
> 
> Perhaps the actual save/restore needs to be moved to the runtime
> callbacks. At least I can't remember right now why this wasn't done in
> the first place.
> 

I looked at the save/restore once again and recalled why it's done so.
The reason is that the host1x touches hardware during the driver probe,
and thus, RPM needs to be resumed first. It will be a bigger change to
properly decouple the hardware initialization so that it all could be

[PATCH 04/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding

This patch adds bindings for i.MX8qm/qxp pixel combiner.

Signed-off-by: Liu Ying 
---
 .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 160 +
 1 file changed, 160 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
new file mode 100644
index ..bacacd8
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Pixel Combiner
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
+  single display controller and manipulates the two streams to support a number
+  of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as
+  either one screen, two screens, or virtual screens.  The pixel combiner is
+  also responsible for generating some of the control signals for the pixel 
link
+  output channel.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-pixel-combiner
+  - fsl,imx8qxp-pixel-combiner
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: apb
+
+  power-domains:
+maxItems: 1
+
+patternProperties:
+  "^channel@[0-1]$":
+type: object
+description: Represents a display stream of pixel combiner.
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The display stream index.
+oneOf:
+  - const: 0
+  - const: 1
+
+  port@0:
+type: object
+description: Input endpoint of the display stream.
+
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+  port@1:
+type: object
+description: Output endpoint of the display stream.
+
+properties:
+  reg:
+const: 1
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+pixel-combiner@5602 {
+compatible = "fsl,imx8qxp-pixel-combiner";
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x5602 0x1>;
+clocks = <_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
+clock-names = "apb";
+power-domains = < IMX_SC_R_DC_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
+remote-endpoint = <_dpu_disp0_dc0_pixel_combiner_ch0>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
+remote-endpoint = 
<_pixel_link0_dc0_pixel_combiner_ch0>;
+};
+};
+};
+
+channel@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
+remote-endpoint = <_dpu_disp1_dc0_pixel_combiner_ch1>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
+remote-endpoint = 
<_pixel_link1_dc0_pixel_combiner_ch1>;
+};
+};
+};
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 05/48] media: dt: bindings: tegra-vde: Document OPP and power domain properties

Document new DVFS OPP table and power domain properties of the video
decoder engine.

Signed-off-by: Dmitry Osipenko 
---
 .../devicetree/bindings/media/nvidia,tegra-vde.txt   | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt 
b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
index 602169b8aa19..02fe2af3bd13 100644
--- a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
+++ b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
@@ -36,6 +36,16 @@ Optional properties:
 - reset-names : Must include the following entries:
   - mc
 - iommus: Must contain phandle to the IOMMU device node.
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+- power-domains: Phandle to VDEC power domain.
+
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: One bitfield indicating:
+   On Tegra20: SoC process ID mask
+   On Tegra30+: SoC speedo ID mask
+
+   A bitwise AND is performed against the value and if any bit
+   matches, the OPP gets enabled.
 
 Example:
 
@@ -61,4 +71,6 @@ video-codec@6001a000 {
reset-names = "vde", "mc";
resets = <_car 61>, < TEGRA20_MC_RESET_VDE>;
iommus = < TEGRA_SWGROUP_VDE>;
+   operating-points-v2 = <_opp_table>;
+   power-domains = <>;
 };
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 35/48] drm/tegra: dc: Support OPP and SoC core voltage scaling

Add OPP and SoC core voltage scaling support to the display controller
driver. This is required for enabling system-wide DVFS on pre-Tegra186
SoCs.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c | 66 +-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b6676f1fe358..105ad786e432 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -11,9 +11,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -1699,6 +1702,48 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
return 0;
 }
 
+static void tegra_dc_update_voltage_state(struct tegra_dc *dc,
+ struct tegra_dc_state *state)
+{
+   unsigned long rate, pstate;
+   struct dev_pm_opp *opp;
+   int err;
+
+   /* calculate actual pixel clock rate which depends on internal divider 
*/
+   rate = DIV_ROUND_UP(clk_get_rate(dc->clk) * 2, state->div + 2);
+
+   /* find suitable OPP for the rate */
+   opp = dev_pm_opp_find_freq_ceil(dc->dev, );
+
+   if (opp == ERR_PTR(-ERANGE))
+   opp = dev_pm_opp_find_freq_floor(dc->dev, );
+
+   /* -ENOENT means that this device-tree doesn't have OPP table */
+   if (opp == ERR_PTR(-ENOENT))
+   return;
+
+   if (IS_ERR(opp)) {
+   dev_err(dc->dev, "failed to find OPP for %luHz: %pe\n",
+   rate, opp);
+   return;
+   }
+
+   pstate = dev_pm_opp_get_voltage(opp);
+   dev_pm_opp_put(opp);
+
+   /*
+* The minimum core voltage depends on the pixel clock rate (which
+* depends on internal clock divider of the CRTC) and not on the
+* rate of the display controller clock. This is why we're not using
+* dev_pm_opp_set_rate() API and instead controlling the power domain
+* directly.
+*/
+   err = dev_pm_genpd_set_performance_state(dc->dev, pstate);
+   if (err)
+   dev_err(dc->dev, "failed to set power domain state to %lu: 
%d\n",
+   pstate, err);
+}
+
 static void tegra_dc_commit_state(struct tegra_dc *dc,
  struct tegra_dc_state *state)
 {
@@ -1738,6 +1783,8 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
if (err < 0)
dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
dc->clk, state->pclk, err);
+
+   tegra_dc_update_voltage_state(dc, state);
 }
 
 static void tegra_dc_stop(struct tegra_dc *dc)
@@ -1931,6 +1978,8 @@ static void tegra_crtc_atomic_disable(struct drm_crtc 
*crtc,
err = host1x_client_suspend(>client);
if (err < 0)
dev_err(dc->dev, "failed to suspend: %d\n", err);
+
+   dev_pm_genpd_set_performance_state(dc->dev, 0);
 }
 
 static void tegra_crtc_atomic_enable(struct drm_crtc *crtc,
@@ -2523,7 +2572,6 @@ static int tegra_dc_runtime_suspend(struct host1x_client 
*client)
 
clk_disable_unprepare(dc->clk);
pm_runtime_put_sync(dev);
-
return 0;
 }
 
@@ -2881,6 +2929,18 @@ static int tegra_dc_couple(struct tegra_dc *dc)
return 0;
 }
 
+static int tegra_dc_init_opp_table(struct tegra_dc *dc)
+{
+   struct tegra_core_opp_params opp_params = {};
+   int err;
+
+   err = devm_tegra_core_dev_init_opp_table(dc->dev, _params);
+   if (err && err != -ENODEV)
+   return err;
+
+   return 0;
+}
+
 static int tegra_dc_probe(struct platform_device *pdev)
 {
struct tegra_dc *dc;
@@ -2939,6 +2999,10 @@ static int tegra_dc_probe(struct platform_device *pdev)
tegra_powergate_power_off(dc->powergate);
}
 
+   err = tegra_dc_init_opp_table(dc);
+   if (err < 0)
+   return err;
+
dc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(dc->regs))
return PTR_ERR(dc->regs);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] cma_heap: fix implicit function declaration

2020-12-18 Thread siyanteng01

From: siyanteng 

When building cma_heap the following error shows up:

drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration of 
function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration]
195 |  vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
|  ^~~~
|  kmap

Use this include: linux-next/include/linux/vmalloc.h

Signed-off-by: siyanteng 
---
 drivers/dma-buf/heaps/cma_heap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 5e7c3436310c..3c4e34301172 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 struct cma_heap {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem

2020-12-18 Thread Chen Li

On Thu, 17 Dec 2020 22:16:59 +0800,
Christian König wrote:
> 
> Am 17.12.20 um 14:37 schrieb Chen Li:
> > On Thu, 17 Dec 2020 18:25:11 +0800,
> > Christian König wrote:
> >> Am 17.12.20 um 02:07 schrieb Chen Li:
> >>> On Wed, 16 Dec 2020 22:19:11 +0800,
> >>> Christian König wrote:
>  Am 16.12.20 um 14:48 schrieb Chen Li:
> > On Wed, 16 Dec 2020 15:59:37 +0800,
> > Christian König wrote:
> >> [SNIP]
> > Hi, Christian. I'm not sure why this change is a hack here. I cannot 
> > see the problem and wll be grateful if you give more explainations.
>  __memset is supposed to work on those addresses, otherwise you can't use 
>  the
>  e8860 on your arm64 system.
> >>> If __memset is supposed to work on those adresses, why this 
> >>> commit(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2Fba0b2275a6781b2f3919d931d63329b5548f6d5fdata=04%7C01%7Cchristian.koenig%40amd.com%7Cfdb4ca3e05ad4ea4882408d8a2914fbc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637438092297678363%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=88oAUlEhnsVNSqYIfXk%2B811oXYd18XPScVZ4ceAurNk%3Dreserved=0)
> >>>  is needed? (I also notice drm/radeon didn't take this change though) 
> >>> just out of curiosity.
> >> We generally accept those patches as cleanup in the kernel with the hope 
> >> that we
> >> can find a way to work around the userspace restrictions.
> > What's the userspace restriction here? mmap device memory?
> 
> Yes, exactly that.
> 
> >> But when you also have this issue in userspace then there isn't much we 
> >> can do
> >> for you.
> >> 
>  Replacing the the direct write in the kernel with calls to writel() or
>  memset_io() will fix that temporary, but you have a more general problem 
>  here.
> >>>I cannot see what's the more general problem here :( u mean 
> >>> performance?
> >> No, not performance. See standards like OpenGL, Vulkan as well as VA-API 
> >> and
> >> VDPAU require that you can mmap() device memory and execute memset/memcpy 
> >> on the
> >> memory from userspace.
> >> 
> >> If your ARM base board can't do that for some then you can't use the 
> >> hardware
> >> with that board.
> > Good to know, thanks! BTW, have you ever seen or heard boards like mine 
> > which cannot mmap device memory correctly from userspace correctly?
> 
> Unfortunately yes. We haven't been able to figure out what exactly goes wrong 
> in
> those cases.

Ok. one more question: only e8860 or all radeon cards have this issue?
 
> >> For amdgpu I suggest that we allocate the UVD message in GTT instead 
> >> of VRAM
> >> since we don't have the hardware restriction for that on the new 
> >> generations.
> >> 
> > Thanks, I will try to dig into deeper. But what's the "hardware 
> > restriction" meaning here? I'm not familiar with video driver stack and 
> > amd gpu, sorry.
>  On older hardware (AGP days) the buffer had to be in VRAM (MMIO) memory, 
>  but on
>  modern system GTT (system memory) works as well.
> >>> IIUC, e8860 can use amdgpu(I use radeon now) beause its device id 6822 is 
> >>> in amdgpu's table. But I cannot tell whether e8860 has iommu, and I 
> >>> cannot find iommu from lspci, so graphics translation table may not work 
> >>> here?
> >> That is not related to IOMMU. IOMMU is a feature of the CPU/motherboard. 
> >> This is
> >> implemented using GTT, e.g. the VM page tables inside the GPU.
> >> 
> >> And yes it should work I will prepare a patch for it.
> > I think you mean mmu :)
> 
> No, I really meant IOMMU.
> 
> > Refer to wikipedia: 
> > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fen.wikipedia.org%2Fwiki%2FInput%25E2%2580%2593output_memory_management_unit%23:~:text%3DIn%2520computing%252C%2520an%2520input%25E2%2580%2593output%2Cbus%2520to%2520the%2520main%2520memorydata=04%7C01%7Cchristian.koenig%40amd.com%7Cfdb4ca3e05ad4ea4882408d8a2914fbc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637438092297678363%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=t6NDi8didU7GFzaCSMFvdSTKA%2FmRZ1cgPCpY7lf7UKo%3Dreserved=0.
> > 
> >  In computing, an input–output memory management unit (IOMMU) is a 
> > memory management unit (MMU) that connects a direct-memory-access–capable 
> > (DMA-capable) I/O bus to the main memory. Like a traditional MMU, which 
> > translates CPU-visible virtual addresses to physical addresses, the IOMMU 
> > maps device-visible virtual addresses (also called device addresses or I/O 
> > addresses in this context) to physical addresses. Some units also provide 
> > memory protection from faulty or malicious devices.
> >  An example IOMMU is the graphics address remapping table (GART) used 
> > by AGP and PCI Express graphics cards on Intel Architecture and AMD 
> > computers.
> 
> Maybe somebody should clarify the

[PATCH 05/14] drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support

This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two screens, or virtual screens.  The pixel
combiner is also responsible for generating some of the control signals
for the pixel link output channel.  For now, the driver only supports
the bypass mode.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/Kconfig |   2 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/imx/Kconfig |   8 +
 drivers/gpu/drm/bridge/imx/Makefile|   1 +
 .../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 452 +
 5 files changed, 464 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6c..84944e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -256,6 +256,8 @@ source "drivers/gpu/drm/bridge/adv7511/Kconfig"
 
 source "drivers/gpu/drm/bridge/cadence/Kconfig"
 
+source "drivers/gpu/drm/bridge/imx/Kconfig"
+
 source "drivers/gpu/drm/bridge/synopsys/Kconfig"
 
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc..bc80cae 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -27,4 +27,5 @@ obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
 
 obj-y += analogix/
 obj-y += cadence/
+obj-y += imx/
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
new file mode 100644
index ..f1c91b6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -0,0 +1,8 @@
+config DRM_IMX8QXP_PIXEL_COMBINER
+   tristate "Freescale i.MX8QM/QXP pixel combiner"
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable pixel combiner found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
new file mode 100644
index ..7d7c8d6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
new file mode 100644
index ..cd5b1be
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -0,0 +1,452 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PC_CTRL_REG0x0
+#define  PC_COMBINE_ENABLE BIT(0)
+#define  PC_DISP_BYPASS(n) BIT(1 + 21 * (n))
+#define  PC_DISP_HSYNC_POLARITY(n) BIT(2 + 11 * (n))
+#define  PC_DISP_HSYNC_POLARITY_POS(n) DISP_HSYNC_POLARITY(n)
+#define  PC_DISP_VSYNC_POLARITY(n) BIT(3 + 11 * (n))
+#define  PC_DISP_VSYNC_POLARITY_POS(n) DISP_VSYNC_POLARITY(n)
+#define  PC_DISP_DVALID_POLARITY(n)BIT(4 + 11 * (n))
+#define  PC_DISP_DVALID_POLARITY_POS(n)DISP_DVALID_POLARITY(n)
+#define  PC_VSYNC_MASK_ENABLE  BIT(5)
+#define  PC_SKIP_MODE  BIT(6)
+#define  PC_SKIP_NUMBER_MASK   GENMASK(12, 7)
+#define  PC_SKIP_NUMBER(n) FIELD_PREP(PC_SKIP_NUMBER_MASK, (n))
+#define  PC_DISP0_PIX_DATA_FORMAT_MASK GENMASK(18, 16)
+#define  PC_DISP0_PIX_DATA_FORMAT(fmt) \
+   FIELD_PREP(PC_DISP0_PIX_DATA_FORMAT_MASK, (fmt))
+#define  PC_DISP1_PIX_DATA_FORMAT_MASK GENMASK(21, 19)
+#define  PC_DISP1_PIX_DATA_FORMAT(fmt) \
+   FIELD_PREP(PC_DISP1_PIX_DATA_FORMAT_MASK, (fmt))
+
+#define PC_BUF_PARA_REG0x10
+#define  PC_BUF_ACTIVE_DEPTH_MASK  GENMASK(10, 0)
+#define  PC_BUF_ACTIVE_DEPTH(n)
FIELD_PREP(PC_BUF_ACTIVE_DEPTH_MASK, (n))
+
+#define PC_SW_RESET_REG0x20
+#define  PC_SW_RESET_N BIT(0)
+#define  PC_DISP_SW_RESET_N(n) BIT(1 + (n))
+#define  PC_FULL_RESET_N   (PC_SW_RESET_N |\
+PC_DISP_SW_RESET_N(0) |\
+PC_DISP_SW_RESET_N(1))
+
+#define PC_REG_SET 0x4
+#define PC_REG_CLR 0x8
+
+#define DRIVER_NAME"imx8qxp-pixel-combiner"
+
+enum imx8qxp_pc_pix_data_format {
+   RGB,
+   YUV444,
+   YUV422,
+   SPLIT_RGB,
+};
+
+struct imx8qxp_pc_channel {
+   struct

[PATCH v2 46/48] ARM: tegra: ventana: Enable core voltage scaling

Allow lower core voltages on Ventana board.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-ventana.dts | 32 ---
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-ventana.dts 
b/arch/arm/boot/dts/tegra20-ventana.dts
index 0b03b3b0fd0c..14ace2ef749c 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -422,16 +422,26 @@ sys_reg: sys {
 
vdd_core: sm0 {
regulator-name = "vdd_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd 
_cpu>;
+   regulator-coupled-max-spread = <17 
55>;
regulator-always-on;
+   regulator-boot-on;
+
+   nvidia,tegra-core-regulator;
};
 
-   sm1 {
+   vdd_cpu: sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
+   regulator-coupled-with = <_core 
_vdd>;
+   regulator-coupled-max-spread = <55 
55>;
regulator-always-on;
+   regulator-boot-on;
+
+   nvidia,tegra-cpu-regulator;
};
 
sm2_reg: sm2 {
@@ -450,10 +460,16 @@ ldo1 {
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_core 
_cpu>;
+   regulator-coupled-max-spread = <17 
55>;
+   regulator-always-on;
+   regulator-boot-on;
+
+   nvidia,tegra-rtc-regulator;
};
 
ldo3 {
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding

This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).

Signed-off-by: Liu Ying 
---
 .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 134 +
 1 file changed, 134 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
new file mode 100644
index ..1649622
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
+  interfaces the pixel link 36-bit data output and the DSI controller’s
+  MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
+  used in LVDS mode, to remap the pixel color codings between those modules.
+  This module is purely combinatorial.
+
+properties:
+  compatible:
+const: fsl,imx8qxp-pxl2dpi
+
+  power-domains:
+maxItems: 1
+
+  fsl,syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to Control and Status Registers(CSR) module.
+
+  fsl,companion-pxl2dpi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to companion PXL2DPI which is used by downstream
+  LVDS Display Bridge(LDB) in split mode.
+
+  ports:
+type: object
+description: |
+  A node containing PXL2DPI input & output port nodes with endpoint
+  definitions as documented in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+  Documentation/devicetree/bindings/graph.txt
+
+properties:
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  port@0:
+type: object
+description: The PXL2DPI input port node from pixel link.
+
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+  port@1:
+type: object
+description: The PXL2DPI output port node to downstream bridge.
+
+properties:
+  reg:
+const: 1
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - compatible
+  - power-domains
+  - fsl,syscon
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+power-domains = < IMX_SC_R_MIPI_0>;
+fsl,syscon = <_lvds_0_csr>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint = 
<_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint = 
<_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 20/48] PM: domains: Make set_performance_state() callback optional

Make set_performance_state() callback optional in order to remove the
need from power domain drivers to implement a dummy callback. If callback
isn't implemented by a GENPD driver, then the performance state is passed
to the parent domain.

Signed-off-by: Dmitry Osipenko 
---
 drivers/base/power/domain.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 9a14eedacb92..a3e1bfc233d4 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -339,9 +339,11 @@ static int _genpd_set_performance_state(struct 
generic_pm_domain *genpd,
goto err;
}
 
-   ret = genpd->set_performance_state(genpd, state);
-   if (ret)
-   goto err;
+   if (genpd->set_performance_state) {
+   ret = genpd->set_performance_state(genpd, state);
+   if (ret)
+   goto err;
+   }
 
genpd->performance_state = state;
return 0;
@@ -399,9 +401,6 @@ int dev_pm_genpd_set_performance_state(struct device *dev, 
unsigned int state)
if (!genpd)
return -ENODEV;
 
-   if (unlikely(!genpd->set_performance_state))
-   return -EINVAL;
-
if (WARN_ON(!dev->power.subsys_data ||
 !dev->power.subsys_data->domain_data))
return -EINVAL;
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 09/48] opp: Add dev_pm_opp_sync_regulators()