date:20220127


Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.

Add a helper that copies the struct and add the offset to the proper
address.


Well what you propose here can lead to all kind of problems and is 
rather bad design as far as I can see.


The struct dma_buf_map is only to be filled in by the exporter and 
should not be modified in this way by the importer.


humn... not sure if I was  clear. There is no importer and exporter here.


Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to the 
driver. That is an absolutely clear NAK!


We could discuss that, but you guys are just sending around patches to 
do this without any consensus that this is a good idea.


Regards,
Christian.



There is a role delegation on filling out and reading a buffer when
that buffer represents a struct layout.

struct bla {
int a;
int b;
int c;
struct foo foo;
struct bar bar;
int d;
}


This implementation allows you to have:

fill_foo(struct dma_buf_map *bla_map) { ... }
fill_bar(struct dma_buf_map *bla_map) { ... }

and the first thing these do is to make sure the map it's pointing to
is relative to the struct it's supposed to write/read. Otherwise you're
suggesting everything to be relative to struct bla, or to do the same
I'm doing it, but IMO more prone to error:

struct dma_buf_map map = *bla_map;
dma_buf_map_incr(map, offsetof(...));

IMO this construct is worse because at a point in time in the function
the map was pointing to the wrong thing the function was supposed to
read/write.

It's also useful when the function has double duty, updating a global
part of the struct and a table inside it (see example in patch 6)

thanks
Lucas De Marchi

[PATCH] drm/amdgpu: fix that issue that the number of the crtc of the 3250c is not correct

2022-01-27 Thread RyanLin

[Why]
External displays take priority over internal display when there are fewer 
display controllers than displays.

[How]
The root cause is because of that number of the crtc is not correct.
The number of the crtc on the 3250c is 3, but on the 3500c is 4.
On the source code, we can see that number of the crtc has been fixed at 4.
Needs to set the num_crtc to 3 for 3250c platform.

Signed-off-by: RyanLin 
Change-Id: I837df7101cc4849d2c3021fd529b4061edab4bb1
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 40c91b448f7d..dbeef7b57a9b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2738,9 +2738,15 @@ static int dm_early_init(void *handle)
break;
 #if defined(CONFIG_DRM_AMD_DC_DCN1_0)
case CHIP_RAVEN:
-   adev->mode_info.num_crtc = 4;
-   adev->mode_info.num_hpd = 4;
-   adev->mode_info.num_dig = 4;
+   if (adev->rev_id >= 8) { //chip_name = "raven2";
+   adev->mode_info.num_crtc = 3;
+   adev->mode_info.num_hpd = 3;
+   adev->mode_info.num_dig = 3;
+   } else {
+   adev->mode_info.num_crtc = 4;
+   adev->mode_info.num_hpd = 4;
+   adev->mode_info.num_dig = 4;
+   }
break;
 #endif
 #if defined(CONFIG_DRM_AMD_DC_DCN2_0)
-- 
2.25.1

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

2022-01-27 Thread Lucas De Marchi


On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.

Add a helper that copies the struct and add the offset to the proper
address.


Well what you propose here can lead to all kind of problems and is 
rather bad design as far as I can see.


The struct dma_buf_map is only to be filled in by the exporter and 
should not be modified in this way by the importer.


humn... not sure if I was  clear. There is no importer and exporter here.


Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to the 
driver. That is an absolutely clear NAK!


We could discuss that, but you guys are just sending around patches to 
do this without any consensus that this is a good idea.


s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in
these patches. I'm sending these to _build consensus_ on what may be a good
use for it showing a real problem it's helping to fix.

From its documentation:

 * The type :c:type:`struct dma_buf_map ` and its helpers are
 * actually independent from the dma-buf infrastructure. When sharing buffers
 * among devices, drivers have to know the location of the memory to access
 * the buffers in a safe way. :c:type:`struct dma_buf_map `
 * solves this problem for dma-buf and its users. If other drivers or
 * sub-systems require similar functionality, the type could be generalized
 * and moved to a more prominent header file.

if there is no consensus and a better alternative, I'm perfectly fine in
throwing it out and using the better approach.

Lucas De Marchi

[PATCH] drm/doc: Add section in the introduction page about learning material

The Linux DRM subsystem supports complex graphics devices and it could be
quite overwhelming for newcomers to learn about the subsystem's internals.

There are lots of useful talks, slides and articles available that can be
used to get familiar with the needed concepts and ease the learning curve.

Add a section to the intro that contains these DRM introductory materials.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
---

 Documentation/gpu/introduction.rst | 36 ++
 1 file changed, 36 insertions(+)

diff --git a/Documentation/gpu/introduction.rst 
b/Documentation/gpu/introduction.rst
index 25a56e9c0cfd..35986784f916 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -112,3 +112,39 @@ Please conduct yourself in a respectful and civilised 
manner when
 interacting with community members on mailing lists, IRC, or bug
 trackers. The community represents the project as a whole, and abusive
 or bullying behaviour is not tolerated by the project.
+
+Learning material
+=
+
+Since the Linux DRM layer supports complex graphics devices, it can be quite
+overwhelming for newcomers to get familiar with all the needed concepts and
+learn the subsystem's internals.
+
+To shallow the learning curve, this section contains a list of presentations
+and documents that can be used to learn about DRM/KMS and graphics in general.
+
+The list is sorted in reverse chronological order, to keep the most up-to-date
+material at the top. But all of them contain useful information, and it can be
+valuable to go through older material to understand the rationale and context
+in which the recent changes to the DRM subsystem were made.
+
+Talks
+-
+
+* `An Overview of the Linux and Userspace Graphics Stack 
`_ - Paul Kocialkowski (2020)
+* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting 
`_ - Simon Ser (2020)
+* `An introduction to the Linux DRM subsystem 
`_ - Maxime Ripard (2017)
+* `Embrace the Atomic (Display) Age 
`_ - Daniel Vetter (2016)
+* `Anatomy of an Atomic KMS Driver 
`_ - Laurent Pinchart (2015)
+* `Atomic Modesetting for Drivers 
`_ - Daniel Vetter (2015)
+* `Anatomy of an Embedded KMS Driver 
`_ - Laurent Pinchart (2013
+
+Slides and articles
+---
+
+* `Understanding the Linux Graphics Stack 
`_ - Bootlin 
(2022)
+* `DRM KMS overview `_ - 
STMicroelectronics (2021)
+* `Linux graphic stack 
`_ - Nathan 
Gauër (2017)
+* `The DRM/KMS subsystem from a newbie’s point of view 
`_
 - Boris Brezillon (2014)
+* `A brief introduction to the Linux graphics stack 
`_
 - Iago Toral (2014)
+* `The Linux Graphics Stack 
`_ - Jasper St. 
Pierre (2012)
-- 
2.34.1

[PATCH] drm/tilcdc: Fix typo in comment

2022-01-27 Thread tangmeng

Replace disbale with disable

Signed-off-by: tangmeng 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 29890d704cb4..b986946b3b10 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -996,7 +996,7 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
if (stat & LCDC_FRAME_DONE) {
tilcdc_crtc->frame_done = true;
wake_up(&tilcdc_crtc->frame_done_wq);
-   /* rev 1 lcdc appears to hang if irq is not disbaled here */
+   /* rev 1 lcdc appears to hang if irq is not disabled here */
if (priv->rev == 1)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
 LCDC_V1_FRAME_DONE_INT_ENA);
-- 
2.20.1

Re: [PATCH v1, 4/8] media: mtk-vcodec: Adds compatible for mt8195

2022-01-27 Thread Macpaul Lin



On 1/27/22 10:55 AM, Yunfei Dong wrote:

Adds compatible for mt8195 platform.

Signed-off-by: Yunfei Dong 
---
  drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 2d21d0010c9c..938bf14e4e8c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -468,6 +468,10 @@ static const struct of_device_id mtk_vcodec_match[] = {
.compatible = "mediatek,mt8186-vcodec-dec",
.data = &mtk_vdec_single_core_pdata,
},
+   {
+   .compatible = "mediatek,mt8195-vcodec-dec",
+   .data = &mtk_lat_sig_core_pdata,
+   },
{},
  };
  



Reviewed-by: Macpaul Lin 

Regards,
Macpaul Lin

[PATCH on v5.17-rc1 11/14] dept: Introduce split map concept and new APIs for them

There is a case where all maps used for a type of wait/event is so large
in size. For instance, struct page can be a type for (un)lock_page().
The additional memory size for the maps would be 'the # of pages *
sizeof(struct dept_map)' if each struct page keeps its map all the way,
which might be too big to accept in some system.

It'd better to have splitted map, one is for each instance and the other
is for the type which is commonly used, and new APIs using them. So
introduced split map and new APIs for them.

Signed-off-by: Byungchul Park 
---
 include/linux/dept.h |  36 ++
 kernel/dependency/dept.c | 122 +++
 2 files changed, 158 insertions(+)

diff --git a/include/linux/dept.h b/include/linux/dept.h
index 8665629..5a726bf 100644
--- a/include/linux/dept.h
+++ b/include/linux/dept.h
@@ -441,6 +441,30 @@ struct dept_map {
bool nocheck;
 };
 
+struct dept_map_each {
+   /*
+* wait timestamp associated to this map
+*/
+   unsigned int wgen;
+};
+
+struct dept_map_common {
+   const char *name;
+   struct dept_key *keys;
+   int sub_usr;
+
+   /*
+* It's local copy for fast acces to the associated classes. And
+* Also used for dept_key instance for statically defined map.
+*/
+   struct dept_key keys_local;
+
+   /*
+* whether this map should be going to be checked or not
+*/
+   bool nocheck;
+};
+
 #define DEPT_TASK_INITIALIZER(t)   \
.dept_task.wait_hist = { { .wait = NULL, } },   \
.dept_task.ecxt_held_pos = 0,   \
@@ -469,6 +493,11 @@ struct dept_map {
 extern void dept_ecxt_exit(struct dept_map *m, unsigned long ip);
 extern struct dept_map *dept_top_map(void);
 extern void dept_warn_on(bool cond);
+extern void dept_split_map_each_init(struct dept_map_each *me);
+extern void dept_split_map_common_init(struct dept_map_common *mc, struct 
dept_key *k, const char *n);
+extern void dept_wait_split_map(struct dept_map_each *me, struct 
dept_map_common *mc, unsigned long ip, const char *w_fn, int ne);
+extern void dept_event_split_map(struct dept_map_each *me, struct 
dept_map_common *mc, unsigned long ip, const char *e_fn);
+extern void dept_asked_event_split_map(struct dept_map_each *me, struct 
dept_map_common *mc);
 
 /*
  * for users who want to manage external keys
@@ -505,6 +534,8 @@ struct dept_map {
 struct dept_task { };
 struct dept_key  { };
 struct dept_map  { };
+struct dept_map_each{ };
+struct dept_map_commmon { };
 
 #define DEPT_TASK_INITIALIZER(t)
 
@@ -525,6 +556,11 @@ struct dept_map {
 #define dept_ecxt_exit(m, ip)  do { } while (0)
 #define dept_top_map() NULL
 #define dept_warn_on(c)do { } while (0)
+#define dept_split_map_each_init(me)   do { } while (0)
+#define dept_split_map_common_init(mc, k, n)   do { (void)(n); 
(void)(k); } while (0)
+#define dept_wait_split_map(me, mc, ip, w_fn, ne)  do { } while (0)
+#define dept_event_split_map(me, mc, ip, e_fn) do { } while (0)
+#define dept_asked_event_split_map(me, mc) do { } while (0)
 #define dept_key_init(k)   do { (void)(k); } while 
(0)
 #define dept_key_destroy(k)do { (void)(k); } while 
(0)
 
diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
index b682bf9..bc764cc 100644
--- a/kernel/dependency/dept.c
+++ b/kernel/dependency/dept.c
@@ -2233,6 +2233,128 @@ void dept_event(struct dept_map *m, unsigned long e_f, 
unsigned long ip,
 }
 EXPORT_SYMBOL_GPL(dept_event);
 
+void dept_split_map_each_init(struct dept_map_each *me)
+{
+   struct dept_task *dt = dept_task();
+   unsigned long flags;
+
+   if (READ_ONCE(dept_stop) || dt->recursive)
+   return;
+
+   flags = dept_enter();
+
+   me->wgen = 0U;
+
+   dept_exit(flags);
+}
+EXPORT_SYMBOL_GPL(dept_split_map_each_init);
+
+void dept_split_map_common_init(struct dept_map_common *mc,
+   struct dept_key *k, const char *n)
+{
+   struct dept_task *dt = dept_task();
+   unsigned long flags;
+
+   if (READ_ONCE(dept_stop) || dt->recursive)
+   return;
+
+   flags = dept_enter();
+
+   if (mc->keys != k)
+   mc->keys = k;
+   clean_classes_cache(&mc->keys_local);
+
+   /*
+* sub_usr is not used with split map.
+*/
+   mc->sub_usr = 0;
+   mc->name = n;
+   mc->nocheck = false;
+
+   dept_exit(flags);
+}
+EXPORT_SYMBOL_GPL(dept_split_map_common_init);
+
+void dept_wait_split_map(struct dept_map_each *me,
+struct dept_map_common *mc,
+unsigned long ip, const char *w_fn, int ne)
+{
+   struct dept_task *dt = dept_task();
+

[PATCH on v5.17-rc1 04/14] dept: Apply Dept to spinlock

Makes Dept able to track dependencies by spinlock.

Signed-off-by: Byungchul Park 
---
 include/linux/lockdep.h| 18 +++---
 include/linux/spinlock.h   | 24 
 include/linux/spinlock_types_raw.h | 13 +
 3 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index c56f6b6..1da8b95 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -582,9 +582,21 @@ static inline void print_irqtrace_events(struct 
task_struct *curr)
 #define lock_acquire_shared(l, s, t, n, i) lock_acquire(l, s, t, 
1, 1, n, i)
 #define lock_acquire_shared_recursive(l, s, t, n, i)   lock_acquire(l, s, t, 
2, 1, n, i)
 
-#define spin_acquire(l, s, t, i)   lock_acquire_exclusive(l, s, t, 
NULL, i)
-#define spin_acquire_nest(l, s, t, n, i)   lock_acquire_exclusive(l, s, t, 
n, i)
-#define spin_release(l, i) lock_release(l, i)
+#define spin_acquire(l, s, t, i)   \
+do {   \
+   lock_acquire_exclusive(l, s, t, NULL, i);   \
+   dept_spin_lock(&(l)->dmap, s, t, NULL, "spin_unlock", i);   \
+} while (0)
+#define spin_acquire_nest(l, s, t, n, i)   \
+do {   \
+   lock_acquire_exclusive(l, s, t, n, i);  \
+   dept_spin_lock(&(l)->dmap, s, t, (n) ? &(n)->dmap : NULL, 
"spin_unlock", i); \
+} while (0)
+#define spin_release(l, i) \
+do {   \
+   lock_release(l, i); \
+   dept_spin_unlock(&(l)->dmap, i);\
+} while (0)
 
 #define rwlock_acquire(l, s, t, i) lock_acquire_exclusive(l, s, t, 
NULL, i)
 #define rwlock_acquire_read(l, s, t, i)
\
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 5c0c517..4d1f5e4 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -95,6 +95,30 @@
 # include 
 #endif
 
+#ifdef CONFIG_DEPT
+#define dept_spin_lock(m, ne, t, n, e_fn, ip)  \
+do {   \
+   if (t) {\
+   dept_ecxt_enter(m, 1UL, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   } else if (n) { \
+   dept_warn_on(dept_top_map() != (n));\
+   } else {\
+   dept_wait(m, 1UL, ip, __func__, ne);\
+   dept_ecxt_enter(m, 1UL, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   }   \
+} while (0)
+#define dept_spin_unlock(m, ip)
\
+do {   \
+   dept_event(m, 1UL, ip, __func__);   \
+   dept_ecxt_exit(m, ip);  \
+} while (0)
+#else
+#define dept_spin_lock(m, ne, t, n, e_fn, ip)  do { } while (0)
+#define dept_spin_unlock(m, ip)do { } while (0)
+#endif
+
 #ifdef CONFIG_DEBUG_SPINLOCK
   extern void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name,
   struct lock_class_key *key, short inner);
diff --git a/include/linux/spinlock_types_raw.h 
b/include/linux/spinlock_types_raw.h
index 91cb36b..5a9b25d 100644
--- a/include/linux/spinlock_types_raw.h
+++ b/include/linux/spinlock_types_raw.h
@@ -26,16 +26,28 @@
 
 #define SPINLOCK_OWNER_INIT((void *)-1L)
 
+#ifdef CONFIG_DEPT
+# define RAW_SPIN_DMAP_INIT(lockname)  .dmap = { .name = #lockname },
+# define SPIN_DMAP_INIT(lockname)  .dmap = { .name = #lockname },
+# define LOCAL_SPIN_DMAP_INIT(lockname).dmap = { .name = #lockname },
+#else
+# define RAW_SPIN_DMAP_INIT(lockname)
+# define SPIN_DMAP_INIT(lockname)
+# define LOCAL_SPIN_DMAP_INIT(lockname)
+#endif
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 # define RAW_SPIN_DEP_MAP_INIT(lockname)   \
.dep_map = {\
.name = #lockname,  \
.wait_type_inner = LD_WAIT_SPIN,\
+   RAW_SPIN_DMAP_INIT(lockname)\
}
 # define SPIN_DEP_MAP_INIT(lockname)   \
.dep_map = {\
.name = #lock

Patches(Dept) for v5.17-rc1

The following messages are for the latest tag, v5.17-rc1.
Hope you are gonna be satisfied with it!

Thanks,
Byungchul

--->8---
>From 68ee7ab996fc7d67b6b506f48da106493ca2546a Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Tue, 25 Jan 2022 10:12:54 +0900
Subject: [RFC 00/14] DEPT(DEPendency Tracker)

Hi forks,

I've been developing a tool for detecting deadlock possibilities by
tracking wait/event rather than lock(?) acquisition order to try to
cover all synchonization machanisms. It's done on v5.10 tag. I bet
it would work great! Try it and see what's gonna happen.

Now that there's a porting issue, I made Dept rely on Lockdep. But it
should be separated from Lockdep once it's considered worth having.

Benifit:

0. Works with all lock primitives.
1. Works with wait_for_completion()/complete().
2. Works with 'wait' on PG_locked.
3. Works with 'wait' on PG_writeback.
4. Works with swait/wakeup.
5. Multiple reports are allowed.
6. Deduplication control on multiple reports.
7. Withstand false positives thanks to 5.
8. Easy to tag any wait/event.

Future work:

0. To make it more stable.
1. To separates Dept from Lockdep.
2. To improves performance in terms of time and space.
3. To use Dept as a dependency engine for Lockdep.
4. To add any missing tags of wait/event in the kernel.
5. To deduplicate stack trace.

I hope you guys are gonna be satisfied with Dept. Don't hesitate to
give any feedback. I will adopt any feedbacks if reasonable.

Thanks,
Byungchul

Byungchul Park (14):
  llist: Move llist_{head,node} definition to types.h
  dept: Implement Dept(Dependency Tracker)
  dept: Embed Dept data in Lockdep
  dept: Apply Dept to spinlock
  dept: Apply Dept to mutex families
  dept: Apply Dept to rwlock
  dept: Apply Dept to wait_for_completion()/complete()
  dept: Apply Dept to seqlock
  dept: Apply Dept to rwsem
  dept: Add proc knobs to show stats and dependency graph
  dept: Introduce split map concept and new APIs for them
  dept: Apply Dept to wait/event of PG_{locked,writeback}
  dept: Separate out SDT(Single-event Dependency Tracker) header
  dept: Apply SDT to swait

 include/linux/completion.h|   48 +-
 include/linux/dept.h  |  541 
 include/linux/dept_page.h |   71 +
 include/linux/dept_sdt.h  |   53 +
 include/linux/hardirq.h   |3 +
 include/linux/irqflags.h  |   33 +-
 include/linux/llist.h |9 +-
 include/linux/lockdep.h   |  156 ++-
 include/linux/lockdep_types.h |3 +
 include/linux/mutex.h |   31 +
 include/linux/page-flags.h|   26 +-
 include/linux/pagemap.h   |7 +-
 include/linux/percpu-rwsem.h  |   10 +-
 include/linux/rtmutex.h   |   11 +-
 include/linux/rwlock.h|   48 +
 include/linux/rwlock_api_smp.h|8 +-
 include/linux/rwlock_types.h  |7 +
 include/linux/rwsem.h |   31 +
 include/linux/sched.h |3 +
 include/linux/seqlock.h   |   19 +-
 include/linux/spinlock.h  |   24 +
 include/linux/spinlock_types.h|   10 +
 include/linux/swait.h |4 +
 include/linux/types.h |8 +
 init/init_task.c  |2 +
 init/main.c   |4 +
 kernel/Makefile   |1 +
 kernel/dependency/Makefile|5 +
 kernel/dependency/dept.c  | 2593 +
 kernel/dependency/dept_hash.h |   11 +
 kernel/dependency/dept_internal.h |   26 +
 kernel/dependency/dept_object.h   |   14 +
 kernel/dependency/dept_proc.c |   97 ++
 kernel/exit.c |1 +
 kernel/fork.c |2 +
 kernel/locking/lockdep.c  |   12 +-
 kernel/module.c   |2 +
 kernel/sched/completion.c |   12 +-
 kernel/sched/swait.c  |8 +
 kernel/softirq.c  |6 +-
 kernel/trace/trace_preemptirq.c   |   19 +-
 lib/Kconfig.debug |   21 +
 mm/filemap.c  |   62 +
 mm/page_ext.c |5 +
 44 files changed, 4009 insertions(+), 58 deletions(-)
 create mode 100644 include/linux/dept.h
 create mode 100644 include/linux/dept_page.h
 create mode 100644 include/linux/dept_sdt.h
 create mode 100644 kernel/dependency/Makefile
 create mode 100644 kernel/dependency/dept.c
 create mode 100644 kernel/dependency/dept_hash.h
 create mode 100644 kernel/dependency/dept_internal.h
 create mode 100644 kernel/dependency/dept_object.h
 create mode 100644 kernel/dependency/dept_proc.c

-- 
1.9.1

Re: [PATCH v1, 3/8] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8195

2022-01-27 Thread Macpaul Lin


On 1/27/22 10:55 AM, Yunfei Dong wrote:

Adds decoder dt-bindings for mt8195.

Signed-off-by: Yunfei Dong 
---
  .../bindings/media/mediatek,vcodec-subdev-decoder.yaml   | 1 +
  1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml 
b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
index a3c892338ac0..a2f2db29daed 100644
--- 
a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
+++ 
b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
@@ -50,6 +50,7 @@ properties:
  enum:
- mediatek,mt8192-vcodec-dec
- mediatek,mt8186-vcodec-dec
+  - mediatek,mt8195-vcodec-dec
  
reg:

  maxItems: 1



Reviewed-by: Macpaul Lin 

Regards,
Macpaul Lin

[PATCH on v5.17-rc1 06/14] dept: Apply Dept to rwlock

Makes Dept able to track dependencies by rwlock.

Signed-off-by: Byungchul Park 
---
 include/linux/lockdep.h| 25 +-
 include/linux/rwlock.h | 48 ++
 include/linux/rwlock_api_smp.h |  8 +++
 include/linux/rwlock_types.h   |  7 ++
 4 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 4c6c2a1..306c22d 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -598,16 +598,31 @@ static inline void print_irqtrace_events(struct 
task_struct *curr)
dept_spin_unlock(&(l)->dmap, i);\
 } while (0)
 
-#define rwlock_acquire(l, s, t, i) lock_acquire_exclusive(l, s, t, 
NULL, i)
+#define rwlock_acquire(l, s, t, i) \
+do {   \
+   lock_acquire_exclusive(l, s, t, NULL, i);   \
+   dept_rwlock_wlock(&(l)->dmap, s, t, NULL, "write_unlock", i);   \
+} while (0)
 #define rwlock_acquire_read(l, s, t, i)
\
 do {   \
-   if (read_lock_is_recursive())   \
+   if (read_lock_is_recursive()) { \
lock_acquire_shared_recursive(l, s, t, NULL, i);\
-   else\
+   dept_rwlock_rlock(&(l)->dmap, s, t, NULL, "read_unlock", i, 0);\
+   } else {\
lock_acquire_shared(l, s, t, NULL, i);  \
+   dept_rwlock_rlock(&(l)->dmap, s, t, NULL, "read_unlock", i, 1);\
+   }   \
+} while (0)
+#define rwlock_release(l, i)   \
+do {   \
+   lock_release(l, i); \
+   dept_rwlock_wunlock(&(l)->dmap, i); \
+} while (0)
+#define rwlock_release_read(l, i)  \
+do {   \
+   lock_release(l, i); \
+   dept_rwlock_runlock(&(l)->dmap, i); \
 } while (0)
-
-#define rwlock_release(l, i)   lock_release(l, i)
 
 #define seqcount_acquire(l, s, t, i)   lock_acquire_exclusive(l, s, t, 
NULL, i)
 #define seqcount_acquire_read(l, s, t, i)  
lock_acquire_shared_recursive(l, s, t, NULL, i)
diff --git a/include/linux/rwlock.h b/include/linux/rwlock.h
index 8f416c5..7bc8c40 100644
--- a/include/linux/rwlock.h
+++ b/include/linux/rwlock.h
@@ -28,6 +28,54 @@
do { *(lock) = __RW_LOCK_UNLOCKED(lock); } while (0)
 #endif
 
+#ifdef CONFIG_DEPT
+#define DEPT_EVT_RWLOCK_R  1UL
+#define DEPT_EVT_RWLOCK_W  (1UL << 1)
+#define DEPT_EVT_RWLOCK_RW (DEPT_EVT_RWLOCK_R | DEPT_EVT_RWLOCK_W)
+
+#define dept_rwlock_wlock(m, ne, t, n, e_fn, ip)   \
+do {   \
+   if (t) {\
+   dept_ecxt_enter(m, DEPT_EVT_RWLOCK_W, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   } else if (n) { \
+   dept_warn_on(dept_top_map() != (n));\
+   } else {\
+   dept_wait(m, DEPT_EVT_RWLOCK_RW, ip, __func__, ne); \
+   dept_ecxt_enter(m, DEPT_EVT_RWLOCK_W, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   }   \
+}while (0)
+#define dept_rwlock_rlock(m, ne, t, n, e_fn, ip, q)\
+do {   \
+   if (t) {\
+   dept_ecxt_enter(m, DEPT_EVT_RWLOCK_R, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   } else if (n) { \
+   dept_warn_on(dept_top_map() != (n));\
+   } else {\
+   dept_wait(m, (q) ? DEPT_EVT_RWLOCK_RW : DEPT_EVT_RWLOCK_W, ip, 
__func__, ne);\
+   dept_ecxt_enter(m, DEPT_EVT_RWLOCK_R, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);

Re: [PATCH v1, 6/8] media: mtk-vcodec: prevent kernel crash when scp ipi timeout

2022-01-27 Thread Macpaul Lin




On 1/27/22 10:55 AM, Yunfei Dong wrote:

From: Tinghan Shen 

When SCP timeout during playing video, kernel crashes with following
message. It's caused by accessing NULL pointer in vpu_dec_ipi_handler.
This patch doesn't solve the root cause of NULL pointer, but merely
prevent kernel crashed when encounter the NULL pointer.

After applied this patch, kernel keeps alive, only the video player turns
to green screen.

[67242.065474] pc : vpu_dec_ipi_handler+0xa0/0xb20 [mtk_vcodec_dec]
[67242.065485] [MTK_V4L2] level=0 fops_vcodec_open(),334:
1800.vcodec_dec decoder [135]
[67242.065523] lr : scp_ipi_handler+0x11c/0x244 [mtk_scp]
[67242.065540] sp : ffbb4207fb10
[67242.065557] x29: ffbb4207fb30 x28: ffd00a1d5000
[67242.065592] x27: 1ffa0143aa24 x26: 
[67242.065625] x25: dfd0 x24: ffd0168bfdb0
[67242.065659] x23: 1ff76840ff74 x22: ffbb41fa8a88
[67242.065692] x21: ffbb4207fb9c x20: ffbb4207fba0
[67242.065725] x19: ffbb4207fb98 x18: 
[67242.065758] x17:  x16: ffd042022094
[67242.065791] x15: 1ff77ed4b71a x14: 1ff77ed4b719
[67242.065824] x13:  x12: 
[67242.065857] x11:  x10: dfd1
[67242.065890] x9 :  x8 : 0002
[67242.065923] x7 :  x6 : 003f
[67242.065956] x5 : 0040 x4 : ffe0
[67242.065989] x3 : ffd043b841b8 x2 : 
[67242.066021] x1 : 0010 x0 : 0010
[67242.066055] Call trace:
[67242.066092]  vpu_dec_ipi_handler+0xa0/0xb20 [mtk_vcodec_dec
12220d230d83a7426fc38c56b3e7bc6066955bae]
[67242.066119]  scp_ipi_handler+0x11c/0x244 [mtk_scp
8fb69c2ef141dd3192518b952b65aba35627b8bf]
[67242.066145]  mt8192_scp_irq_handler+0x70/0x128 [mtk_scp
8fb69c2ef141dd3192518b952b65aba35627b8bf]
[67242.066172]  scp_irq_handler+0xa0/0x114 [mtk_scp
8fb69c2ef141dd3192518b952b65aba35627b8bf]
[67242.066200]  irq_thread_fn+0x84/0xf8
[67242.066220]  irq_thread+0x170/0x1ec
[67242.066242]  kthread+0x2f8/0x3b8
[67242.066264]  ret_from_fork+0x10/0x30
[67242.066292] Code: 38f96908 35003628 91004340 d343fc08 (38f96908)

Signed-off-by: Tinghan Shen 
Signed-off-by: Yunfei Dong 
---
  drivers/media/platform/mtk-vcodec/vdec_vpu_if.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 35f4d5583084..1041dd663e76 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -91,6 +91,11 @@ static void vpu_dec_ipi_handler(void *data, unsigned int 
len, void *priv)
struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
(unsigned long)msg->ap_inst_addr;
  
+	if (!vpu) {

+   mtk_v4l2_err("ap_inst_addr is NULL");
+   return;
+   }
+
mtk_vcodec_debug(vpu, "+ id=%X", msg->msg_id);
  
  	vpu->failure = msg->status;




Reviewed-by: Macpaul Lin 

Regards,
Macpaul Lin

[PATCH on v5.17-rc1 07/14] dept: Apply Dept to wait_for_completion()/complete()

Makes Dept able to track dependencies by
wait_for_completion()/complete().

Signed-off-by: Byungchul Park 
---
 include/linux/completion.h | 42 --
 kernel/sched/completion.c  | 12 ++--
 2 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/include/linux/completion.h b/include/linux/completion.h
index 51d9ab0..2bba7b1 100644
--- a/include/linux/completion.h
+++ b/include/linux/completion.h
@@ -26,14 +26,48 @@
 struct completion {
unsigned int done;
struct swait_queue_head wait;
+   struct dept_map dmap;
 };
 
+#ifdef CONFIG_DEPT
+#define dept_wfc_init(m, k, s, n)  dept_map_init(m, k, s, n)
+#define dept_wfc_reinit(m) dept_map_reinit(m)
+#define dept_wfc_wait(m, ip)   \
+do {   \
+   dept_asked_event(m);\
+   dept_wait(m, 1UL, ip, __func__, 0); \
+} while (0)
+#define dept_wfc_complete(m, ip)   dept_event(m, 1UL, ip, __func__)
+#define dept_wfc_enter(m, ip)  dept_ecxt_enter(m, 1UL, ip, 
"completion_context_enter", "complete", 0)
+#define dept_wfc_exit(m, ip)   dept_ecxt_exit(m, ip)
+#else
+#define dept_wfc_init(m, k, s, n)  do { (void)(n); (void)(k); } 
while (0)
+#define dept_wfc_reinit(m) do { } while (0)
+#define dept_wfc_wait(m, ip)   do { } while (0)
+#define dept_wfc_complete(m, ip)   do { } while (0)
+#define dept_wfc_enter(m, ip)  do { } while (0)
+#define dept_wfc_exit(m, ip)   do { } while (0)
+#endif
+
+#ifdef CONFIG_DEPT
+#define WFC_DEPT_MAP_INIT(work) .dmap = { .name = #work }
+#else
+#define WFC_DEPT_MAP_INIT(work)
+#endif
+
+#define init_completion(x) \
+   do {\
+   static struct dept_key __dkey;  \
+   __init_completion(x, &__dkey, #x);  \
+   } while (0)
+
 #define init_completion_map(x, m) init_completion(x)
 static inline void complete_acquire(struct completion *x) {}
 static inline void complete_release(struct completion *x) {}
 
 #define COMPLETION_INITIALIZER(work) \
-   { 0, __SWAIT_QUEUE_HEAD_INITIALIZER((work).wait) }
+   { 0, __SWAIT_QUEUE_HEAD_INITIALIZER((work).wait), \
+   WFC_DEPT_MAP_INIT(work) }
 
 #define COMPLETION_INITIALIZER_ONSTACK_MAP(work, map) \
(*({ init_completion_map(&(work), &(map)); &(work); }))
@@ -81,9 +115,12 @@ static inline void complete_release(struct completion *x) {}
  * This inline function will initialize a dynamically created completion
  * structure.
  */
-static inline void init_completion(struct completion *x)
+static inline void __init_completion(struct completion *x,
+struct dept_key *dkey,
+const char *name)
 {
x->done = 0;
+   dept_wfc_init(&x->dmap, dkey, 0, name);
init_swait_queue_head(&x->wait);
 }
 
@@ -97,6 +134,7 @@ static inline void init_completion(struct completion *x)
 static inline void reinit_completion(struct completion *x)
 {
x->done = 0;
+   dept_wfc_reinit(&x->dmap);
 }
 
 extern void wait_for_completion(struct completion *);
diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index a778554..6e31cc0 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -29,6 +29,7 @@ void complete(struct completion *x)
 {
unsigned long flags;
 
+   dept_wfc_complete(&x->dmap, _RET_IP_);
raw_spin_lock_irqsave(&x->wait.lock, flags);
 
if (x->done != UINT_MAX)
@@ -58,6 +59,7 @@ void complete_all(struct completion *x)
 {
unsigned long flags;
 
+   dept_wfc_complete(&x->dmap, _RET_IP_);
lockdep_assert_RT_in_threaded_ctx();
 
raw_spin_lock_irqsave(&x->wait.lock, flags);
@@ -112,17 +114,23 @@ void complete_all(struct completion *x)
 }
 
 static long __sched
-wait_for_common(struct completion *x, long timeout, int state)
+_wait_for_common(struct completion *x, long timeout, int state)
 {
return __wait_for_common(x, schedule_timeout, timeout, state);
 }
 
 static long __sched
-wait_for_common_io(struct completion *x, long timeout, int state)
+_wait_for_common_io(struct completion *x, long timeout, int state)
 {
return __wait_for_common(x, io_schedule_timeout, timeout, state);
 }
 
+#define wait_for_common(x, t, s)   \
+({ dept_wfc_wait(&(x)->dmap, _RET_IP_); _wait_for_common(x, t, s); })
+
+#define wait_for_common_io(x, t, s)\
+({ dept_wfc_wait(&(x)->dmap, _RET_IP_); _wait_for_common_io(x, t, s); })
+
 /**
  * wait_for_completion: - waits for completion of a task
  * @x:  holds the state of

Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

2022-01-27 Thread Sven Schnelle

Helge Deller  writes:

> On 1/26/22 12:24, Daniel Vetter wrote:
>> And that point was about 5 years ago, and has been discussed at some
>> plumbers meanwhile, resulting in the staging TODO patches to make
>> these drm drivers to destage them.
>>
>> Fixing bugs in fbdev is all fine, reopening it for merging new drivers is 
>> not.
>
> We are on the same page!
> I'm not at all proposing to include new drivers for (relatively) new
> hardware into fbdev, which is capable to be written as DRM driver.

In my opinion that should be decided depending on the main usecase: If
it's X11 or similar, it should go to DRM. If its main use case is kernel
text console, it should go to fbdev.

I think the main concern/trouble about fbdev is the userspace interface,
and i personally would be totally fine seeing that go away (except the
ability to change video mode with fbset). For me its important as kernel
console for old systems, and don't want to run X11 on them.

Given the ongoing discussion about performance and drm, i don't expect
DRM gaining HW acceleration capabilities for text consoles. So i think
both should exist, just for different usecases.

[PATCH on v5.17-rc1 02/14] dept: Implement Dept(Dependency Tracker)

CURRENT STATUS
--
Lockdep tracks acquisition order of locks in order to detect deadlock,
and IRQ and IRQ enable/disable state as well to take accident
acquisitions into account.

Lockdep should be turned off once it detects and reports a deadlock
since the data structure and algorithm are not reusable after detection
because of the complex design.

PROBLEM
---
*Waits* and their *events* that never reach eventually cause deadlock.
However, Lockdep is only interested in lock acquisition order, forcing
to emulate lock acqusition even for just waits and events that have
nothing to do with real lock.

Even worse, no one likes Lockdep's false positive detection because that
prevents further one that might be more valuable. That's why all the
kernel developers are sensitive to Lockdep's false positive.

Besides those, by tracking acquisition order, it cannot correctly deal
with read lock and cross-event e.g. wait_for_completion()/complete() for
deadlock detection. Lockdep is no longer a good tool for that purpose.

SOLUTION

Again, *waits* and their *events* that never reach eventually cause
deadlock. The new solution, Dept(DEPendency Tracker), focuses on waits
and events themselves. Dept tracks waits and events and report it if
any event would be never reachable.

Dept does:
   . Works with read lock in the right way.
   . Works with any wait and event e.i. cross-event.
   . Continue to work even after reporting multiple times.
   . Provides simple and intuitive APIs.
   . Does exactly what dependency checker should do.

Q & A
-
Q. Is this the first try ever to address the problem?
A. No. Cross-release feature (b09be676e0ff2 locking/lockdep: Implement
   the 'crossrelease' feature) addressed it 2 years ago that was a
   Lockdep extention and merged but reverted shortly because:

   Cross-release started to report valuable hidden problems but started
   to give report false positive reports as well. For sure, no one
   likes Lockdep's false positive reports since it makes Lockdep stop,
   preventing reporting further real problems.

Q. Why not Dept was developed as an extention of Lockdep?
A. Lockdep definitely includes all the efforts great developers have
   made for a long time so as to be quite stable enough. But I had to
   design and implement newly because of the following:

   1) Lockdep was designed to track lock acquisition order. The APIs and
  implementation do not fit on wait-event model.
   2) Lockdep is turned off on detection including false positive. Which
  is terrible and prevents developing any extention for stronger
  detection.

Q. Do you intend to totally replace Lockdep?
A. No. Lockdep also checks if lock usage is correct. Of course, the
   dependency check routine should be replaced but the other functions
   should be still there.

Q. Do you mean the dependency check routine should be replaced right
   away?
A. No. I admit Lockdep is stable enough thanks to great efforts kernel
   developers have made. Lockdep and Dept, both should be in the kernel
   until Dept gets considered stable.

Q. Stronger detection capability would give more false positive report.
   Which was a big problem when cross-release was introduced. Is it ok
   with Dept?
A. It's ok. Dept allows multiple reporting thanks to simple and quite
   generalized design. Of course, false positive reports should be fixed
   anyway but it's no longer as a critical problem as it was.

Signed-off-by: Byungchul Park 
---
 include/linux/dept.h|  541 +
 include/linux/hardirq.h |3 +
 include/linux/irqflags.h|   33 +-
 include/linux/sched.h   |3 +
 init/init_task.c|2 +
 init/main.c |2 +
 kernel/Makefile |1 +
 kernel/dependency/Makefile  |4 +
 kernel/dependency/dept.c| 2477 +++
 kernel/dependency/dept_hash.h   |   11 +
 kernel/dependency/dept_object.h |   14 +
 kernel/exit.c   |1 +
 kernel/fork.c   |2 +
 kernel/module.c |2 +
 kernel/softirq.c|6 +-
 kernel/trace/trace_preemptirq.c |   19 +-
 lib/Kconfig.debug   |   20 +
 17 files changed, 3132 insertions(+), 9 deletions(-)
 create mode 100644 include/linux/dept.h
 create mode 100644 kernel/dependency/Makefile
 create mode 100644 kernel/dependency/dept.c
 create mode 100644 kernel/dependency/dept_hash.h
 create mode 100644 kernel/dependency/dept_object.h

diff --git a/include/linux/dept.h b/include/linux/dept.h
new file mode 100644
index 000..8665629
--- /dev/null
+++ b/include/linux/dept.h
@@ -0,0 +1,541 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Dept(DEPendency Tracker) - runtime dependency tracker
+ *
+ * Started by Byungchul Park :
+ *
+ *  Copyright (c) 2020 LG Electronics, Inc., Byungchul Park
+ */
+
+#ifndef __LINUX_DEPT_H
+#define __LINUX_DEPT_H
+
+#ifdef CONFIG_DEPT
+
+#inc

[PATCH on v5.17-rc1 01/14] llist: Move llist_{head, node} definition to types.h

llist_head and llist_node can be used by very primitives. For example,
Dept for tracking dependency uses llist things in its header. To avoid
header dependency, move those to types.h.

Signed-off-by: Byungchul Park 
---
 include/linux/llist.h | 8 
 include/linux/types.h | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index 85bda2d..99cc3c3 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -53,14 +53,6 @@
 #include 
 #include 
 
-struct llist_head {
-   struct llist_node *first;
-};
-
-struct llist_node {
-   struct llist_node *next;
-};
-
 #define LLIST_HEAD_INIT(name)  { NULL }
 #define LLIST_HEAD(name)   struct llist_head name = LLIST_HEAD_INIT(name)
 
diff --git a/include/linux/types.h b/include/linux/types.h
index ac825ad..4662d6e 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -187,6 +187,14 @@ struct hlist_node {
struct hlist_node *next, **pprev;
 };
 
+struct llist_head {
+   struct llist_node *first;
+};
+
+struct llist_node {
+   struct llist_node *next;
+};
+
 struct ustat {
__kernel_daddr_tf_tfree;
 #ifdef CONFIG_ARCH_32BIT_USTAT_F_TINODE
-- 
1.9.1

[PATCH on v5.17-rc1 08/14] dept: Apply Dept to seqlock

Makes Dept able to track dependencies by seqlock with adding wait
annotation on read side of seqlock.

Signed-off-by: Byungchul Park 
---
 include/linux/seqlock.h | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 37ded6b..35929c9 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -23,6 +23,13 @@
 
 #include 
 
+#ifdef CONFIG_DEPT
+#define DEPT_EVT_ALL   ((1UL << DEPT_MAX_SUBCLASSES_EVT) - 1)
+#define dept_seq_wait(m, ip)   dept_wait(m, DEPT_EVT_ALL, ip, __func__, 0)
+#else
+#define dept_seq_wait(m, ip)   do { } while (0)
+#endif
+
 /*
  * The seqlock seqcount_t interface does not prescribe a precise sequence of
  * read begin/retry/end. For readers, typically there is a call to
@@ -148,7 +155,7 @@ static inline void seqcount_lockdep_reader_access(const 
seqcount_t *s)
  * This lock-unlock technique must be implemented for all of PREEMPT_RT
  * sleeping locks.  See Documentation/locking/locktypes.rst
  */
-#if defined(CONFIG_LOCKDEP) || defined(CONFIG_PREEMPT_RT)
+#if defined(CONFIG_LOCKDEP) || defined(CONFIG_DEPT) || 
defined(CONFIG_PREEMPT_RT)
 #define __SEQ_LOCK(expr)   expr
 #else
 #define __SEQ_LOCK(expr)
@@ -203,6 +210,12 @@ static inline void seqcount_lockdep_reader_access(const 
seqcount_t *s)
__SEQ_LOCK(locktype *lock); \
 } seqcount_##lockname##_t; \
\
+static __always_inline void\
+__seqprop_##lockname##_wait(const seqcount_##lockname##_t *s)  \
+{  \
+   __SEQ_LOCK(dept_seq_wait(&(lockmember)->dep_map.dmap, _RET_IP_));\
+}  \
+   \
 static __always_inline seqcount_t *\
 __seqprop_##lockname##_ptr(seqcount_##lockname##_t *s) \
 {  \
@@ -271,6 +284,8 @@ static inline void __seqprop_assert(const seqcount_t *s)
lockdep_assert_preemption_disabled();
 }
 
+static inline void __seqprop_wait(const seqcount_t *s) { }
+
 #define __SEQ_RT   IS_ENABLED(CONFIG_PREEMPT_RT)
 
 SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t,  false,s->lock,
raw_spin, raw_spin_lock(s->lock))
@@ -311,6 +326,7 @@ static inline void __seqprop_assert(const seqcount_t *s)
 #define seqprop_sequence(s)__seqprop(s, sequence)
 #define seqprop_preemptible(s) __seqprop(s, preemptible)
 #define seqprop_assert(s)  __seqprop(s, assert)
+#define seqprop_dept_wait(s)   __seqprop(s, wait)
 
 /**
  * __read_seqcount_begin() - begin a seqcount_t read section w/o barrier
@@ -360,6 +376,7 @@ static inline void __seqprop_assert(const seqcount_t *s)
 #define read_seqcount_begin(s) \
 ({ \
seqcount_lockdep_reader_access(seqprop_ptr(s)); \
+   seqprop_dept_wait(s);   \
raw_read_seqcount_begin(s); \
 })
 
-- 
1.9.1

[PATCH on v5.17-rc1 03/14] dept: Embed Dept data in Lockdep

Dept should work independently from Lockdep. However, there's no choise
but to rely on Lockdep code and its instances for now.

Signed-off-by: Byungchul Park 
---
 include/linux/lockdep.h   | 71 ---
 include/linux/lockdep_types.h |  3 ++
 kernel/locking/lockdep.c  | 12 
 3 files changed, 76 insertions(+), 10 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 467b942..c56f6b6 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -20,6 +20,33 @@
 extern int prove_locking;
 extern int lock_stat;
 
+#ifdef CONFIG_DEPT
+static inline void dept_after_copy_map(struct dept_map *to,
+  struct dept_map *from)
+{
+   int i;
+
+   if (from->keys == &from->keys_local)
+   to->keys = &to->keys_local;
+
+   if (!to->keys)
+   return;
+
+   /*
+* Since the class cache can be modified concurrently we could observe
+* half pointers (64bit arch using 32bit copy insns). Therefore clear
+* the caches and take the performance hit.
+*
+* XXX it doesn't work well with lockdep_set_class_and_subclass(), since
+* that relies on cache abuse.
+*/
+   for (i = 0; i < DEPT_MAX_SUBCLASSES_CACHE; i++)
+   to->keys->classes[i] = NULL;
+}
+#else
+#define dept_after_copy_map(t, f)  do { } while (0)
+#endif
+
 #ifdef CONFIG_LOCKDEP
 
 #include 
@@ -43,6 +70,8 @@ static inline void lockdep_copy_map(struct lockdep_map *to,
 */
for (i = 0; i < NR_LOCKDEP_CACHING_CLASSES; i++)
to->class_cache[i] = NULL;
+
+   dept_after_copy_map(&to->dmap, &from->dmap);
 }
 
 /*
@@ -176,8 +205,19 @@ struct held_lock {
current->lockdep_recursion -= LOCKDEP_OFF;  \
 } while (0)
 
-extern void lockdep_register_key(struct lock_class_key *key);
-extern void lockdep_unregister_key(struct lock_class_key *key);
+extern void __lockdep_register_key(struct lock_class_key *key);
+extern void __lockdep_unregister_key(struct lock_class_key *key);
+
+#define lockdep_register_key(k)\
+do {   \
+   __lockdep_register_key(k);  \
+   dept_key_init(&(k)->dkey);  \
+} while (0)
+#define lockdep_unregister_key(k)  \
+do {   \
+   __lockdep_unregister_key(k);\
+   dept_key_destroy(&(k)->dkey);   \
+} while (0)
 
 /*
  * These methods are used by specific locking variants (spinlocks,
@@ -185,9 +225,18 @@ struct held_lock {
  * to lockdep:
  */
 
-extern void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
+extern void __lockdep_init_map_type(struct lockdep_map *lock, const char *name,
struct lock_class_key *key, int subclass, u8 inner, u8 outer, u8 
lock_type);
 
+#define lockdep_init_map_type(l, n, k, s, i, o, t) \
+do {   \
+   __lockdep_init_map_type(l, n, k, s, i, o, t);   \
+   if ((k) == &__lockdep_no_validate__)\
+   dept_map_nocheck(&(l)->dmap);   \
+   else\
+   dept_map_init(&(l)->dmap, &(k)->dkey, s, n);\
+} while (0)
+
 static inline void
 lockdep_init_map_waits(struct lockdep_map *lock, const char *name,
   struct lock_class_key *key, int subclass, u8 inner, u8 
outer)
@@ -431,13 +480,27 @@ enum xhlock_context_t {
XHLOCK_CTX_NR,
 };
 
+#ifdef CONFIG_DEPT
+/*
+ * TODO: I found the case to use an address of other than a real key as
+ * _key, for instance, in workqueue. So for now, we cannot use the
+ * assignment like '.dmap.keys = &(_key)->dkey' unless it's fixed.
+ */
+#define STATIC_DEPT_MAP_INIT(_name, _key) .dmap = {\
+   .name = (_name),\
+   .keys = NULL },
+#else
+#define STATIC_DEPT_MAP_INIT(_name, _key)
+#endif
+
 #define lockdep_init_map_crosslock(m, n, k, s) do {} while (0)
 /*
  * To initialize a lockdep_map statically use this macro.
  * Note that _name must not be NULL.
  */
 #define STATIC_LOCKDEP_MAP_INIT(_name, _key) \
-   { .name = (_name), .key = (void *)(_key), }
+   { .name = (_name), .key = (void *)(_key), \
+   STATIC_DEPT_MAP_INIT(_name, _key) }
 
 static inline void lockdep_invariant_state(bool force) {}
 static inline void lockdep_free_task(struct task_struct *task) {}
diff --git a/include/linux/lockdep_types.h b/include/linux/lockdep_types.h
index d224308..50c8879 100644
--- a/include/linux/lockdep_types.h
+++ b/include/linux/lockdep_types.h
@@ -11,6 +11,7 @@
 #define __LINUX_LOCKDEP_TYPES_H
 
 #include 
+#include 
 
 #define MAX_LOCKDEP_SUBCLASSES 8UL
 
@@ -76,6 +77,7 @@ struct

[PATCH on v5.17-rc1 12/14] dept: Apply Dept to wait/event of PG_{locked, writeback}

Makes Dept able to track dependencies by PG_{locked,writeback}. For
instance, (un)lock_page() generates that type of dependency.

Signed-off-by: Byungchul Park 
---
 include/linux/dept_page.h   | 71 +
 include/linux/page-flags.h  | 43 +++--
 include/linux/pagemap.h |  6 +++-
 init/main.c |  2 ++
 kernel/dependency/dept_object.h |  2 +-
 lib/Kconfig.debug   |  1 +
 mm/filemap.c| 62 +++
 mm/page_ext.c   |  5 +++
 8 files changed, 188 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/dept_page.h

diff --git a/include/linux/dept_page.h b/include/linux/dept_page.h
new file mode 100644
index 000..d5a79af
--- /dev/null
+++ b/include/linux/dept_page.h
@@ -0,0 +1,71 @@
+#ifndef __LINUX_DEPT_PAGE_H
+#define __LINUX_DEPT_PAGE_H
+
+#ifdef CONFIG_DEPT
+#include 
+
+extern struct page_ext_operations dept_pglocked_ops;
+extern struct page_ext_operations dept_pgwriteback_ops;
+extern struct dept_map_common pglocked_mc;
+extern struct dept_map_common pgwriteback_mc;
+
+extern void dept_page_init(void);
+extern struct dept_map_each *get_pglocked_me(struct page *page);
+extern struct dept_map_each *get_pgwriteback_me(struct page *page);
+
+#define dept_pglocked_wait(f)  \
+do {   \
+   struct dept_map_each *me = get_pglocked_me(&(f)->page); \
+   if (likely(me)) \
+   dept_wait_split_map(me, &pglocked_mc, _RET_IP_, \
+   __func__, 0);   \
+} while (0)
+
+#define dept_pglocked_set_bit(f)   \
+do {   \
+   struct dept_map_each *me = get_pglocked_me(&(f)->page); \
+   if (likely(me)) \
+   dept_asked_event_split_map(me, &pglocked_mc);   \
+} while (0)
+
+#define dept_pglocked_event(f) \
+do {   \
+   struct dept_map_each *me = get_pglocked_me(&(f)->page); \
+   if (likely(me)) \
+   dept_event_split_map(me, &pglocked_mc, _RET_IP_,\
+__func__); \
+} while (0)
+
+#define dept_pgwriteback_wait(f)   \
+do {   \
+   struct dept_map_each *me = get_pgwriteback_me(&(f)->page);\
+   if (likely(me)) \
+   dept_wait_split_map(me, &pgwriteback_mc, _RET_IP_,\
+   __func__, 0);   \
+} while (0)
+
+#define dept_pgwriteback_set_bit(f)\
+do {   \
+   struct dept_map_each *me = get_pgwriteback_me(&(f)->page);\
+   if (likely(me)) \
+   dept_asked_event_split_map(me, &pgwriteback_mc);\
+} while (0)
+
+#define dept_pgwriteback_event(f)  \
+do {   \
+   struct dept_map_each *me = get_pgwriteback_me(&(f)->page);\
+   if (likely(me)) \
+   dept_event_split_map(me, &pgwriteback_mc, _RET_IP_,\
+__func__); \
+} while (0)
+#else
+#define dept_page_init()   do { } while (0)
+#define dept_pglocked_wait(f)  do { } while (0)
+#define dept_pglocked_set_bit(f)   do { } while (0)
+#define dept_pglocked_event(f) do { } while (0)
+#define dept_pgwriteback_wait(f)   do { } while (0)
+#define dept_pgwriteback_set_bit(f)do { } while (0)
+#define dept_pgwriteback_event(f)  do { } while (0)
+#endif
+
+#endif /* __LINUX_DEPT_PAGE_H */
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 1c3b6e5..d1c78a2 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -411,7 +411,6 @@ static unsigned long *folio_flags(struct folio *folio, 
unsigned n)
 #define TESTSCFLAG_FALSE(uname, lname) \
TESTSETFLAG_FALSE(uname, lname) TESTCLEARFLAG_FALSE(uname, lname)
 
-__PAGEFLAG(Locked, locked, PF_NO_TAIL)
 PAGEFLAG(Waiters, waiters, PF_ONLY_HEAD) __CLEARPAGEFLAG(Waiters, waiters, 
PF_ONLY_HEAD)
 PAGEFLAG(Error, error, PF_NO_TAIL) TESTCLEARFLAG(Error, error, PF_NO_TAIL)
 PAGEFLAG(Referenced, referenced, PF_HEAD)
@@ -459,7 +458,6 @@ static unsigned long *folio_flags(struct folio *folio, 
unsigned n)
  * risky: they bypass page accounting.
  */
 TESTPAGEFLAG(Writeback, writeback, PF_NO_TAIL)
-   TESTSCFLAG(Writeback, writeback,

[PATCH on v5.17-rc1 09/14] dept: Apply Dept to rwsem

Makes Dept able to track dependencies by rwsem.

Signed-off-by: Byungchul Park 
---
 include/linux/lockdep.h  | 24 
 include/linux/percpu-rwsem.h | 10 +-
 include/linux/rwsem.h| 31 +++
 3 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 306c22d..6aab26c 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -644,10 +644,26 @@ static inline void print_irqtrace_events(struct 
task_struct *curr)
dept_mutex_unlock(&(l)->dmap, i);   \
 } while (0)
 
-#define rwsem_acquire(l, s, t, i)  lock_acquire_exclusive(l, s, t, 
NULL, i)
-#define rwsem_acquire_nest(l, s, t, n, i)  lock_acquire_exclusive(l, s, t, 
n, i)
-#define rwsem_acquire_read(l, s, t, i) lock_acquire_shared(l, s, t, 
NULL, i)
-#define rwsem_release(l, i)lock_release(l, i)
+#define rwsem_acquire(l, s, t, i)  \
+do {   \
+   lock_acquire_exclusive(l, s, t, NULL, i);   \
+   dept_rwsem_lock(&(l)->dmap, s, t, NULL, "up_write", i); \
+} while (0)
+#define rwsem_acquire_nest(l, s, t, n, i)  \
+do {   \
+   lock_acquire_exclusive(l, s, t, n, i);  \
+   dept_rwsem_lock(&(l)->dmap, s, t, (n) ? &(n)->dmap : NULL, "up_write", 
i);\
+} while (0)
+#define rwsem_acquire_read(l, s, t, i) \
+do {   \
+   lock_acquire_shared(l, s, t, NULL, i);  \
+   dept_rwsem_lock(&(l)->dmap, s, t, NULL, "up_read", i);  \
+} while (0)
+#define rwsem_release(l, i)\
+do {   \
+   lock_release(l, i); \
+   dept_rwsem_unlock(&(l)->dmap, i);   \
+} while (0)
 
 #define lock_map_acquire(l)lock_acquire_exclusive(l, 0, 0, 
NULL, _THIS_IP_)
 #define lock_map_acquire_read(l)   
lock_acquire_shared_recursive(l, 0, 0, NULL, _THIS_IP_)
diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 5fda40f..7ec5625 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -20,8 +20,16 @@ struct percpu_rw_semaphore {
 #endif
 };
 
+#ifdef CONFIG_DEPT
+#define __PERCPU_RWSEM_DMAP_INIT(lockname) .dmap = { .name = #lockname }
+#else
+#define __PERCPU_RWSEM_DMAP_INIT(lockname)
+#endif
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
-#define __PERCPU_RWSEM_DEP_MAP_INIT(lockname)  .dep_map = { .name = #lockname 
},
+#define __PERCPU_RWSEM_DEP_MAP_INIT(lockname)  .dep_map = {\
+   .name = #lockname,  \
+   __PERCPU_RWSEM_DMAP_INIT(lockname) },
 #else
 #define __PERCPU_RWSEM_DEP_MAP_INIT(lockname)
 #endif
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index f934876..ec3bc1d 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -16,11 +16,18 @@
 #include 
 #include 
 
+#ifdef CONFIG_DEPT
+# define RWSEM_DMAP_INIT(lockname) .dmap = { .name = #lockname },
+#else
+# define RWSEM_DMAP_INIT(lockname)
+#endif
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 # define __RWSEM_DEP_MAP_INIT(lockname)\
.dep_map = {\
.name = #lockname,  \
.wait_type_inner = LD_WAIT_SLEEP,   \
+   RWSEM_DMAP_INIT(lockname)   \
},
 #else
 # define __RWSEM_DEP_MAP_INIT(lockname)
@@ -32,6 +39,30 @@
 #include 
 #endif
 
+#ifdef CONFIG_DEPT
+#define dept_rwsem_lock(m, ne, t, n, e_fn, ip) \
+do {   \
+   if (t) {\
+   dept_ecxt_enter(m, 1UL, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   } else if (n) { \
+   dept_warn_on(dept_top_map() != (n));\
+   } else {\
+   dept_wait(m, 1UL, ip, __func__, ne);\
+   dept_ecxt_enter(m, 1UL, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   }   \
+} while (0)
+#define dept_rwsem_unlock(m, ip)   \
+do {   \

[PATCH on v5.17-rc1 10/14] dept: Add proc knobs to show stats and dependency graph

It'd be useful to show Dept internal stats and dependency graph on
runtime via proc for better information. Introduced the knobs.

Signed-off-by: Byungchul Park 
---
 kernel/dependency/Makefile|  1 +
 kernel/dependency/dept.c  | 24 --
 kernel/dependency/dept_internal.h | 26 +++
 kernel/dependency/dept_proc.c | 97 +++
 4 files changed, 133 insertions(+), 15 deletions(-)
 create mode 100644 kernel/dependency/dept_internal.h
 create mode 100644 kernel/dependency/dept_proc.c

diff --git a/kernel/dependency/Makefile b/kernel/dependency/Makefile
index 9f7778e..49152ad 100644
--- a/kernel/dependency/Makefile
+++ b/kernel/dependency/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_DEPT) += dept.o
+obj-$(CONFIG_DEPT) += dept_proc.o
 
diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
index 64287894..b682bf9 100644
--- a/kernel/dependency/dept.c
+++ b/kernel/dependency/dept.c
@@ -90,6 +90,7 @@
 #include 
 #include 
 #include 
+#include "dept_internal.h"
 
 static int dept_stop;
 static int dept_per_cpu_ready;
@@ -241,20 +242,13 @@ static inline struct dept_task *dept_task(void)
  *   have been freed will be placed.
  */
 
-enum object_t {
-#define OBJECT(id, nr) OBJECT_##id,
-   #include "dept_object.h"
-#undef  OBJECT
-   OBJECT_NR,
-};
-
 #define OBJECT(id, nr) \
 static struct dept_##id spool_##id[nr];
\
 static DEFINE_PER_CPU(struct llist_head, lpool_##id);
#include "dept_object.h"
 #undef  OBJECT
 
-static struct dept_pool pool[OBJECT_NR] = {
+struct dept_pool dept_pool[OBJECT_NR] = {
 #define OBJECT(id, nr) {   \
.name = #id,\
.obj_sz = sizeof(struct dept_##id), \
@@ -283,7 +277,7 @@ static void *from_pool(enum object_t t)
if (DEPT_WARN_ON(!irqs_disabled()))
return NULL;
 
-   p = &pool[t];
+   p = &dept_pool[t];
 
/*
 * Try local pool first.
@@ -312,7 +306,7 @@ static void *from_pool(enum object_t t)
 
 static void to_pool(void *o, enum object_t t)
 {
-   struct dept_pool *p = &pool[t];
+   struct dept_pool *p = &dept_pool[t];
struct llist_head *h;
 
preempt_disable();
@@ -1986,7 +1980,7 @@ void dept_map_nocheck(struct dept_map *m)
 }
 EXPORT_SYMBOL_GPL(dept_map_nocheck);
 
-static LIST_HEAD(classes);
+LIST_HEAD(dept_classes);
 
 static inline bool within(const void *addr, void *start, unsigned long size)
 {
@@ -2031,7 +2025,7 @@ void dept_free_range(void *start, unsigned int sz)
 */
free_staleie_staleiw_range(start, sz);
 
-   list_for_each_entry_safe(c, n, &classes, all_node) {
+   list_for_each_entry_safe(c, n, &dept_classes, all_node) {
if (!within((void *)c->key, start, sz) &&
!within(c->name, start, sz))
continue;
@@ -2100,7 +2094,7 @@ static struct dept_class *check_new_class(struct dept_key 
*local,
c->sub = sub;
c->key = (unsigned long)(k->subkeys + sub);
hash_add_class(c);
-   list_add(&c->all_node, &classes);
+   list_add(&c->all_node, &dept_classes);
 unlock:
dept_unlock();
 caching:
@@ -2429,8 +2423,8 @@ static void migrate_per_cpu_pool(void)
struct llist_head *from;
struct llist_head *to;
 
-   from = &pool[i].boot_pool;
-   to = per_cpu_ptr(pool[i].lpool, boot_cpu);
+   from = &dept_pool[i].boot_pool;
+   to = per_cpu_ptr(dept_pool[i].lpool, boot_cpu);
move_llist(to, from);
}
 }
diff --git a/kernel/dependency/dept_internal.h 
b/kernel/dependency/dept_internal.h
new file mode 100644
index 000..007c1ee
--- /dev/null
+++ b/kernel/dependency/dept_internal.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Dept(DEPendency Tracker) - runtime dependency tracker internal header
+ *
+ * Started by Byungchul Park :
+ *
+ *  Copyright (c) 2020 LG Electronics, Inc., Byungchul Park
+ */
+
+#ifndef __DEPT_INTERNAL_H
+#define __DEPT_INTERNAL_H
+
+#ifdef CONFIG_DEPT
+
+enum object_t {
+#define OBJECT(id, nr) OBJECT_##id,
+   #include "dept_object.h"
+#undef  OBJECT
+   OBJECT_NR,
+};
+
+extern struct list_head dept_classes;
+extern struct dept_pool dept_pool[];
+
+#endif
+#endif /* __DEPT_INTERNAL_H */
diff --git a/kernel/dependency/dept_proc.c b/kernel/dependency/dept_proc.c
new file mode 100644
index 000..5e5afa3
--- /dev/null
+++ b/kernel/dependency/dept_proc.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * kernel/dependency/dept_proc.c
+ *
+ * Runtime dependency tracker
+ *
+ * Started by Byungchul Park :
+ *
+ *  Copyright (C) 2021 LG Electronics, Inc. , Byungchul Park
+ *
+ * Code for /proc/dept_*:
+ *
+ */
+

[PATCH on v5.17-rc1 05/14] dept: Apply Dept to mutex families

Makes Dept able to track dependencies by mutex families.

Signed-off-by: Byungchul Park 
---
 include/linux/lockdep.h | 18 +++---
 include/linux/mutex.h   | 31 +++
 include/linux/rtmutex.h |  7 +++
 3 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 1da8b95..4c6c2a1 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -613,9 +613,21 @@ static inline void print_irqtrace_events(struct 
task_struct *curr)
 #define seqcount_acquire_read(l, s, t, i)  
lock_acquire_shared_recursive(l, s, t, NULL, i)
 #define seqcount_release(l, i) lock_release(l, i)
 
-#define mutex_acquire(l, s, t, i)  lock_acquire_exclusive(l, s, t, 
NULL, i)
-#define mutex_acquire_nest(l, s, t, n, i)  lock_acquire_exclusive(l, s, t, 
n, i)
-#define mutex_release(l, i)lock_release(l, i)
+#define mutex_acquire(l, s, t, i)  \
+do {   \
+   lock_acquire_exclusive(l, s, t, NULL, i);   \
+   dept_mutex_lock(&(l)->dmap, s, t, NULL, "mutex_unlock", i); \
+} while (0)
+#define mutex_acquire_nest(l, s, t, n, i)  \
+do {   \
+   lock_acquire_exclusive(l, s, t, n, i);  \
+   dept_mutex_lock(&(l)->dmap, s, t, (n) ? &(n)->dmap : NULL, 
"mutex_unlock", i);\
+} while (0)
+#define mutex_release(l, i)\
+do {   \
+   lock_release(l, i); \
+   dept_mutex_unlock(&(l)->dmap, i);   \
+} while (0)
 
 #define rwsem_acquire(l, s, t, i)  lock_acquire_exclusive(l, s, t, 
NULL, i)
 #define rwsem_acquire_nest(l, s, t, n, i)  lock_acquire_exclusive(l, s, t, 
n, i)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 8f226d4..0955760 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -20,11 +20,18 @@
 #include 
 #include 
 
+#ifdef CONFIG_DEPT
+# define DMAP_MUTEX_INIT(lockname) .dmap = { .name = #lockname },
+#else
+# define DMAP_MUTEX_INIT(lockname)
+#endif
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 # define __DEP_MAP_MUTEX_INITIALIZER(lockname) \
, .dep_map = {  \
.name = #lockname,  \
.wait_type_inner = LD_WAIT_SLEEP,   \
+   DMAP_MUTEX_INIT(lockname)   \
}
 #else
 # define __DEP_MAP_MUTEX_INITIALIZER(lockname)
@@ -75,6 +82,30 @@ struct mutex {
 #endif
 };
 
+#ifdef CONFIG_DEPT
+#define dept_mutex_lock(m, ne, t, n, e_fn, ip) \
+do {   \
+   if (t) {\
+   dept_ecxt_enter(m, 1UL, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   } else if (n) { \
+   dept_warn_on(dept_top_map() != (n));\
+   } else {\
+   dept_wait(m, 1UL, ip, __func__, ne);\
+   dept_ecxt_enter(m, 1UL, ip, __func__, e_fn, ne);\
+   dept_asked_event(m);\
+   }   \
+} while (0)
+#define dept_mutex_unlock(m, ip)   \
+do {   \
+   dept_event(m, 1UL, ip, __func__);   \
+   dept_ecxt_exit(m, ip);  \
+} while (0)
+#else
+#define dept_mutex_lock(m, ne, t, n, e_fn, ip) do { } while (0)
+#define dept_mutex_unlock(m, ip)   do { } while (0)
+#endif
+
 #ifdef CONFIG_DEBUG_MUTEXES
 
 #define __DEBUG_MUTEX_INITIALIZER(lockname)\
diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
index 7d04988..60cebb0 100644
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -76,11 +76,18 @@ static inline void rt_mutex_debug_task_free(struct 
task_struct *tsk) { }
__rt_mutex_init(mutex, __func__, &__key); \
 } while (0)
 
+#ifdef CONFIG_DEPT
+#define DMAP_RT_MUTEX_INIT(mutexname)  .dmap = { .name = #mutexname },
+#else
+#define DMAP_RT_MUTEX_INIT(mutexname)
+#endif
+
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 #define __DEP_MAP_RT_MUTEX_INITIALIZER(mutexname)  \
.dep_map = {\
.name =

[PATCH on v5.17-rc1 14/14] dept: Apply SDT to swait

Makes SDT able to track dependencies by swait.

Signed-off-by: Byungchul Park 
---
 include/linux/swait.h | 4 
 kernel/sched/swait.c  | 8 
 2 files changed, 12 insertions(+)

diff --git a/include/linux/swait.h b/include/linux/swait.h
index 6a8c22b..dbdf2ce 100644
--- a/include/linux/swait.h
+++ b/include/linux/swait.h
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -43,6 +44,7 @@
 struct swait_queue_head {
raw_spinlock_t  lock;
struct list_headtask_list;
+   struct dept_map dmap;
 };
 
 struct swait_queue {
@@ -61,6 +63,7 @@ struct swait_queue {
 #define __SWAIT_QUEUE_HEAD_INITIALIZER(name) { \
.lock   = __RAW_SPIN_LOCK_UNLOCKED(name.lock),  \
.task_list  = LIST_HEAD_INIT((name).task_list), \
+   .dmap   = DEPT_SDT_MAP_INIT(name),  \
 }
 
 #define DECLARE_SWAIT_QUEUE_HEAD(name) \
@@ -72,6 +75,7 @@ extern void __init_swait_queue_head(struct swait_queue_head 
*q, const char *name
 #define init_swait_queue_head(q)   \
do {\
static struct lock_class_key __key; \
+   sdt_map_init(&(q)->dmap);   \
__init_swait_queue_head((q), #q, &__key);   \
} while (0)
 
diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
index e1c655f..b6c2efb 100644
--- a/kernel/sched/swait.c
+++ b/kernel/sched/swait.c
@@ -27,6 +27,7 @@ void swake_up_locked(struct swait_queue_head *q)
return;
 
curr = list_first_entry(&q->task_list, typeof(*curr), task_list);
+   sdt_event(&q->dmap);
wake_up_process(curr->task);
list_del_init(&curr->task_list);
 }
@@ -69,6 +70,7 @@ void swake_up_all(struct swait_queue_head *q)
while (!list_empty(&tmp)) {
curr = list_first_entry(&tmp, typeof(*curr), task_list);
 
+   sdt_event(&q->dmap);
wake_up_state(curr->task, TASK_NORMAL);
list_del_init(&curr->task_list);
 
@@ -97,6 +99,9 @@ void prepare_to_swait_exclusive(struct swait_queue_head *q, 
struct swait_queue *
__prepare_to_swait(q, wait);
set_current_state(state);
raw_spin_unlock_irqrestore(&q->lock, flags);
+
+   if (state & TASK_NORMAL)
+   sdt_wait(&q->dmap);
 }
 EXPORT_SYMBOL(prepare_to_swait_exclusive);
 
@@ -119,6 +124,9 @@ long prepare_to_swait_event(struct swait_queue_head *q, 
struct swait_queue *wait
}
raw_spin_unlock_irqrestore(&q->lock, flags);
 
+   if (!ret && state & TASK_NORMAL)
+   sdt_wait(&q->dmap);
+
return ret;
 }
 EXPORT_SYMBOL(prepare_to_swait_event);
-- 
1.9.1

[PATCH on v5.17-rc1 13/14] dept: Separate out SDT(Single-event Dependency Tracker) header

Now that Dept has already been applied to major synchronization
machanisms e.g. spinlock, wait_for_completion and the like, we can take
advantage of Dept by default if CONFIG_DEPT is on.

However, sometimes we need to manually tag wait/event on places where
Dept hasn't been applied. SDT(Single-event Dependency Tracker) would be
useful in that case to tag those. The usage is like:

1. Initialize dmap in the instance associated to the wait/event.

sdt_map_init(dmap);

2. Add the following just before the wait.

sdt_wait(dmap);

3. Add the following just before the event.

sdt_event(dmap);

For better reference of SDT APIs, separated the APIs from dept.h.

Signed-off-by: Byungchul Park 
---
 include/linux/dept.h | 36 
 include/linux/dept_sdt.h | 53 
 2 files changed, 53 insertions(+), 36 deletions(-)
 create mode 100644 include/linux/dept_sdt.h

diff --git a/include/linux/dept.h b/include/linux/dept.h
index 5a726bf..10ef7fc 100644
--- a/include/linux/dept.h
+++ b/include/linux/dept.h
@@ -504,32 +504,6 @@ struct dept_map_common {
  */
 extern void dept_key_init(struct dept_key *k);
 extern void dept_key_destroy(struct dept_key *k);
-
-#define DEPT_SDT_MAP_INIT(dname)   { .name = #dname }
-#define DEFINE_DEPT_SDT(x) \
-   struct dept_map x = DEPT_SDT_MAP_INIT(x)
-
-/*
- * SDT(Single-event Dependency Tracker) APIs
- *
- * In case that one dept_map instance maps to a single event, SDT APIs
- * can be used.
- */
-#define sdt_map_init(m)
\
-   do {\
-   static struct dept_key __key;   \
-   dept_map_init(m, &__key, 0, #m);\
-   } while (0)
-#define sdt_map_init_key(m, k) dept_map_init(m, k, 0, #m)
-
-#define sdt_wait(m)\
-   do {\
-   dept_asked_event(m);\
-   dept_wait(m, 1UL, _THIS_IP_, "wait", 0);\
-   } while (0)
-#define sdt_ecxt_enter(m)  dept_ecxt_enter(m, 1UL, _THIS_IP_, 
"start", "event", 0)
-#define sdt_event(m)   dept_event(m, 1UL, _THIS_IP_, "event")
-#define sdt_ecxt_exit(m)   dept_ecxt_exit(m, _THIS_IP_)
 #else /* !CONFIG_DEPT */
 struct dept_task { };
 struct dept_key  { };
@@ -563,15 +537,5 @@ struct dept_map_common {
 #define dept_asked_event_split_map(me, mc) do { } while (0)
 #define dept_key_init(k)   do { (void)(k); } while 
(0)
 #define dept_key_destroy(k)do { (void)(k); } while 
(0)
-
-#define DEPT_SDT_MAP_INIT(dname)
-#define DEFINE_DEPT_SDT(x)
-
-#define sdt_map_init(m)do { } while (0)
-#define sdt_map_init_key(m, k) do { (void)(k); } while 
(0)
-#define sdt_wait(m)do { } while (0)
-#define sdt_ecxt_enter(m)  do { } while (0)
-#define sdt_event(m)   do { } while (0)
-#define sdt_ecxt_exit(m)   do { } while (0)
 #endif
 #endif /* __LINUX_DEPT_H */
diff --git a/include/linux/dept_sdt.h b/include/linux/dept_sdt.h
new file mode 100644
index 000..32a4a9e
--- /dev/null
+++ b/include/linux/dept_sdt.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Dept Single-event Dependency Tracker
+ *
+ * Started by Byungchul Park :
+ *
+ *  Copyright (c) 2020 LG Electronics, Inc., Byungchul Park
+ */
+
+#ifndef __LINUX_DEPT_SDT_H
+#define __LINUX_DEPT_SDT_H
+
+#ifdef CONFIG_DEPT
+
+#include 
+
+#define DEPT_SDT_MAP_INIT(dname)   { .name = #dname }
+#define DEFINE_DEPT_SDT(x) \
+   struct dept_map x = DEPT_SDT_MAP_INIT(x)
+
+/*
+ * SDT(Single-event Dependency Tracker) APIs
+ *
+ * In case that one dept_map instance maps to a single event, SDT APIs
+ * can be used.
+ */
+#define sdt_map_init(m)
\
+   do {\
+   static struct dept_key __key;   \
+   dept_map_init(m, &__key, 0, #m);\
+   } while (0)
+#define sdt_map_init_key(m, k) dept_map_init(m, k, 0, #m)
+
+#define sdt_wait(m)\
+   do {\
+   dept_asked_event(m);\
+   dept_wait(m, 1UL, _THIS_IP_, "wait", 0);\
+   } while (0)
+#define sdt_ecxt_enter(m)  dept_ecxt_enter(m, 1UL, _THIS_IP_, 
"start", "event", 0)
+#

Re: [RFC 00/14] DEPT(DEPendency Tracker)

+cc

linux...@kvack.org
a...@linux-foundation.org
mho...@kernel.org
minc...@kernel.org
han...@cmpxchg.org
vdavydov@gmail.com
s...@kernel.org
jgli...@redhat.com
den...@kernel.org
c...@linux.com
penb...@kernel.org
rient...@google.com
vba...@suse.cz
ngu...@vflare.org
linux-bl...@vger.kernel.org
ax...@kernel.dk
paolo.vale...@linaro.org
jo...@toxicpanda.com
linux-fsde...@vger.kernel.org
v...@zeniv.linux.org.uk
j...@suse.cz
jlay...@kernel.org
dan.j.willi...@intel.com
h...@infradead.org
djw...@kernel.org
dri-devel@lists.freedesktop.org
airl...@linux.ie
rodrigosiqueiram...@gmail.com
melissa@gmail.com
hamohammed...@gmail.com

--->8---
>From 68ee7ab996fc7d67b6b506f48da106493ca2546a Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Tue, 25 Jan 2022 10:12:54 +0900
Subject: [RFC 00/14] DEPT(DEPendency Tracker)

Hi forks,

I've been developing a tool for detecting deadlock possibilities by
tracking wait/event rather than lock(?) acquisition order to try to
cover all synchonization machanisms. It's done on v5.10 tag. I bet
it would work great! Try it and see what's gonna happen.

Now that there's a porting issue, I made Dept rely on Lockdep. But it
should be separated from Lockdep once it's considered worth having.

Benifit:

0. Works with all lock primitives.
1. Works with wait_for_completion()/complete().
2. Works with 'wait' on PG_locked.
3. Works with 'wait' on PG_writeback.
4. Works with swait/wakeup.
5. Multiple reports are allowed.
6. Deduplication control on multiple reports.
7. Withstand false positives thanks to 5.
8. Easy to tag any wait/event.

Future work:

0. To make it more stable.
1. To separates Dept from Lockdep.
2. To improves performance in terms of time and space.
3. To use Dept as a dependency engine for Lockdep.
4. To add any missing tags of wait/event in the kernel.
5. To deduplicate stack trace.

I hope you guys are gonna be satisfied with Dept. Don't hesitate to
give any feedback. I will adopt any feedbacks if reasonable.

Thanks,
Byungchul

Byungchul Park (14):
  llist: Move llist_{head,node} definition to types.h
  dept: Implement Dept(Dependency Tracker)
  dept: Embed Dept data in Lockdep
  dept: Apply Dept to spinlock
  dept: Apply Dept to mutex families
  dept: Apply Dept to rwlock
  dept: Apply Dept to wait_for_completion()/complete()
  dept: Apply Dept to seqlock
  dept: Apply Dept to rwsem
  dept: Add proc knobs to show stats and dependency graph
  dept: Introduce split map concept and new APIs for them
  dept: Apply Dept to wait/event of PG_{locked,writeback}
  dept: Separate out SDT(Single-event Dependency Tracker) header
  dept: Apply SDT to swait

 include/linux/completion.h|   48 +-
 include/linux/dept.h  |  541 
 include/linux/dept_page.h |   71 +
 include/linux/dept_sdt.h  |   53 +
 include/linux/hardirq.h   |3 +
 include/linux/irqflags.h  |   33 +-
 include/linux/llist.h |9 +-
 include/linux/lockdep.h   |  156 ++-
 include/linux/lockdep_types.h |3 +
 include/linux/mutex.h |   31 +
 include/linux/page-flags.h|   26 +-
 include/linux/pagemap.h   |7 +-
 include/linux/percpu-rwsem.h  |   10 +-
 include/linux/rtmutex.h   |   11 +-
 include/linux/rwlock.h|   48 +
 include/linux/rwlock_api_smp.h|8 +-
 include/linux/rwlock_types.h  |7 +
 include/linux/rwsem.h |   31 +
 include/linux/sched.h |3 +
 include/linux/seqlock.h   |   19 +-
 include/linux/spinlock.h  |   24 +
 include/linux/spinlock_types.h|   10 +
 include/linux/swait.h |4 +
 include/linux/types.h |8 +
 init/init_task.c  |2 +
 init/main.c   |4 +
 kernel/Makefile   |1 +
 kernel/dependency/Makefile|5 +
 kernel/dependency/dept.c  | 2593 +
 kernel/dependency/dept_hash.h |   11 +
 kernel/dependency/dept_internal.h |   26 +
 kernel/dependency/dept_object.h   |   14 +
 kernel/dependency/dept_proc.c |   97 ++
 kernel/exit.c |1 +
 kernel/fork.c |2 +
 kernel/locking/lockdep.c  |   12 +-
 kernel/module.c   |2 +
 kernel/sched/completion.c |   12 +-
 kernel/sched/swait.c  |8 +
 kernel/softirq.c  |6 +-
 kernel/trace/trace_preemptirq.c   |   19 +-
 lib/Kconfig.debug |   21 +
 mm/filemap.c  |   62 +
 mm/page_ext.c |5 +
 44 files changed, 4009 insertions(+), 58 deletions(-)
 create mode 100644 include/linux/dept.h
 create mode 100644 include/linux/dept_page.h
 create mode 100644 include/linux/dept_sdt.h
 create mode 100644 kernel/dependency/Makefile
 create mode 100644 ke

[PATCH] drivers: Fix typo in comment

2022-01-27 Thread tangmeng

Replace disbale with disable and replace unavaibale with unavailable.

Signed-off-by: tangmeng 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c  | 2 +-
 drivers/pcmcia/rsrc_nonstatic.c   | 2 +-
 drivers/usb/chipidea/udc.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index aef9d059ae52..a642c04cf17d 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -544,7 +544,7 @@ static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device 
*adev,
 {
int r;
 
-   /* trigger gpu-reset by hypervisor only if TDR disbaled */
+   /* trigger gpu-reset by hypervisor only if TDR disabled */
if (!amdgpu_gpu_recovery) {
/* see what event we get */
r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 29890d704cb4..b986946b3b10 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -996,7 +996,7 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
if (stat & LCDC_FRAME_DONE) {
tilcdc_crtc->frame_done = true;
wake_up(&tilcdc_crtc->frame_done_wq);
-   /* rev 1 lcdc appears to hang if irq is not disbaled here */
+   /* rev 1 lcdc appears to hang if irq is not disabled here */
if (priv->rev == 1)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
 LCDC_V1_FRAME_DONE_INT_ENA);
diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
index 6b6c578b5f92..ad1141fddb4c 100644
--- a/drivers/pcmcia/rsrc_nonstatic.c
+++ b/drivers/pcmcia/rsrc_nonstatic.c
@@ -394,7 +394,7 @@ static int do_validate_mem(struct pcmcia_socket *s,
  * do_mem_probe() checks a memory region for use by the PCMCIA subsystem.
  * To do so, the area is split up into sensible parts, and then passed
  * into the @validate() function. Only if @validate() and @fallback() fail,
- * the area is marked as unavaibale for use by the PCMCIA subsystem. The
+ * the area is marked as unavailable for use by the PCMCIA subsystem. The
  * function returns the size of the usable memory area.
  */
 static int do_mem_probe(struct pcmcia_socket *s, u_long base, u_long num,
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f9ca5010f65b..dc6c96e04bcf 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -2152,7 +2152,7 @@ static void udc_id_switch_for_host(struct ci_hdrc *ci)
 {
/*
 * host doesn't care B_SESSION_VALID event
-* so clear and disbale BSV irq
+* so clear and disable BSV irq
 */
if (ci->is_otg)
hw_write_otgsc(ci, OTGSC_BSVIE | OTGSC_BSVIS, OTGSC_BSVIS);
-- 
2.20.1

[PATCH] drm/amd/amdgpu: fix spelling mistake "disbale" -> "disable"

2022-01-27 Thread tangmeng

There is a spelling mistake. Fix it.

Signed-off-by: tangmeng 
---
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index aef9d059ae52..a642c04cf17d 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -544,7 +544,7 @@ static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device 
*adev,
 {
int r;
 
-   /* trigger gpu-reset by hypervisor only if TDR disbaled */
+   /* trigger gpu-reset by hypervisor only if TDR disabled */
if (!amdgpu_gpu_recovery) {
/* see what event we get */
r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION);
-- 
2.20.1

Re: [PATCH 04/12] drm/ttm: add common accounting to the resource mgr v2

On Wed, Jan 26, 2022 at 03:42:21PM +0100, Christian König wrote:
> Am 25.01.22 um 17:37 schrieb Daniel Vetter:
> > On Mon, Jan 24, 2022 at 01:25:06PM +0100, Christian König wrote:
> > > It makes sense to have this in the common manager for debugging and
> > > accounting of how much resources are used.
> > > 
> > > v2: cleanup kerneldoc a bit
> > > 
> > > Signed-off-by: Christian König 
> > > Reviewed-by: Huang Rui 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_resource.c |  8 
> > >   include/drm/ttm/ttm_resource.h | 20 +++-
> > >   2 files changed, 27 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
> > > b/drivers/gpu/drm/ttm/ttm_resource.c
> > > index 7fdd58b53c61..b8362492980d 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_resource.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> > > @@ -33,6 +33,8 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
> > >  const struct ttm_place *place,
> > >  struct ttm_resource *res)
> > >   {
> > > + struct ttm_resource_manager *man;
> > > +
> > >   res->start = 0;
> > >   res->num_pages = PFN_UP(bo->base.size);
> > >   res->mem_type = place->mem_type;
> > > @@ -42,12 +44,16 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
> > >   res->bus.is_iomem = false;
> > >   res->bus.caching = ttm_cached;
> > >   res->bo = bo;
> > > +
> > > + man = ttm_manager_type(bo->bdev, place->mem_type);
> > > + atomic64_add(bo->base.size, &man->usage);
> > Doing this with atomics doesn't make a lot of sense to me. Yes with the
> > current organization it's the only thing to do in drivers, but if we move
> > this into ttm there's no reason we can track this together with the lru,
> > consistently with the lru, and under the same spinlock like the lru.
> > 
> > And at least spot-checking a few places the very next thing we generally
> > do is take the lru lock since there's really no other way to get the
> > resource into or out of the resource manager.
> > 
> > I think doing atomics for statistics when there's no need is not great,
> > because then people start using atomics for all kinds of other things, and
> > then get the barriers wrong. In i915 (simply due to the grotesque amount
> > of buggy overuse of atomics, both atomic_t and atomic bitfields) we've put
> > a hard block in place for any atomic addition. So that's why I'm a bit on
> > a crusade, but I also genuinely don't see why we need them here. All they
> > do is cost more since we have to take the spinlock anyway, the accounting
> > is just going to be a slight different (and imo more accurate) place.
> > 
> > Thoughts?
> 
> Well it depends. We have two use cases for those statistics:
> 1. Early abort when there isn't enough free resources.
> 2. Debugging
> 
> For the debugging it's completely irrelevant if we grab the lock or not, but
> for the early abort I'm not that sure.
> 
> Anyway I will just put that under the lock instead for now, if we really
> find that it is contended we could still switch back to an atomic.

To clarify, I don't mind using atomic for statistics, it's kinda the prime
example use case for them (and the reason really why they're unordered
atomics by default). It's just if you already do take a lock anyway might
as well include the statistics in there too, because except in really
silly cases that should be all faster. Worst case you need to make sure
that the datastructure and statistics (list_head and u64 here) are in the
same cacheline, and with that the statistics practically become free when
done under the spinlock.

Anyway just figured I'll drop a bit more of my thinking on this topic
here, we're agreeing already on what the code should look like anyway :-)

Cheers, Daniel

> 
> Regards,
> Christian.
> 
> > 
> > Cheers, Daniel
> > 
> > >   }
> > >   EXPORT_SYMBOL(ttm_resource_init);
> > >   void ttm_resource_fini(struct ttm_resource_manager *man,
> > >  struct ttm_resource *res)
> > >   {
> > > + atomic64_sub(res->bo->base.size, &man->usage);
> > >   }
> > >   EXPORT_SYMBOL(ttm_resource_fini);
> > > @@ -149,6 +155,7 @@ void ttm_resource_manager_init(struct 
> > > ttm_resource_manager *man,
> > >   spin_lock_init(&man->move_lock);
> > >   man->bdev = bdev;
> > >   man->size = p_size;
> > > + atomic64_set(&man->usage, 0);
> > >   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
> > >   INIT_LIST_HEAD(&man->lru[i]);
> > > @@ -221,6 +228,7 @@ void ttm_resource_manager_debug(struct 
> > > ttm_resource_manager *man,
> > >   drm_printf(p, "  use_type: %d\n", man->use_type);
> > >   drm_printf(p, "  use_tt: %d\n", man->use_tt);
> > >   drm_printf(p, "  size: %llu\n", man->size);
> > > + drm_printf(p, "  usage: %llu\n", atomic64_read(&man->usage));
> > >   if (man->func->debug)
> > >   man->func->debug(man, p);
> > >   }
> >

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map


Am 27.01.22 um 09:18 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

[SNIP]
humn... not sure if I was  clear. There is no importer and exporter 
here.


Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to 
the driver. That is an absolutely clear NAK!


We could discuss that, but you guys are just sending around patches 
to do this without any consensus that this is a good idea.


s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in
these patches. I'm sending these to _build consensus_ on what may be a 
good

use for it showing a real problem it's helping to fix.


Well a cover letter would have been helpful, my impression was that you 
have a larger set and just want to upstream some minor DMA-buf changes 
necessary for it.


Now I know why people are bugging me all the time to add cover letters 
to add more context to my sets.




From its documentation:

 * The type :c:type:`struct dma_buf_map ` and its helpers 
are
 * actually independent from the dma-buf infrastructure. When sharing 
buffers
 * among devices, drivers have to know the location of the memory to 
access

 * the buffers in a safe way. :c:type:`struct dma_buf_map `
 * solves this problem for dma-buf and its users. If other drivers or
 * sub-systems require similar functionality, the type could be 
generalized

 * and moved to a more prominent header file.

if there is no consensus and a better alternative, I'm perfectly fine in
throwing it out and using the better approach.


When Thomas Zimmermann upstreamed the dma_buf_map work we had a 
discussion if that shouldn't be independent of the DMA-buf framework.


The consensus was that as soon as we have more widely use for it this 
should be made independent. So basically that is what's happening now.


I suggest the following approach:
1. Find a funky name for this, something like iomem_, kiomap_ or similar.
2. Separate this from all you driver dependent work and move the 
dma_buf_map structure out of DMA-buf into this new whatever_ prefix.
3. Ping Thomas, LKML, me and probably a couple of other core people if 
this is the right idea or not.
4. Work on dropping the map parameter from dma_buf_vunmap(). This is 
basically why we can't modify the pointers returned from dma_buf_vmap() 
and has already cause a few problems with dma_buf_map_incr().


Regards,
Christian.



Lucas De Marchi

Re: [PATCH 02/19] dma-buf-map: Add helper to initialize second map

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > When dma_buf_map struct is passed around, it's useful to be able to
> > > > initialize a second map that takes care of reading/writing to an offset
> > > > of the original map.
> > > > 
> > > > Add a helper that copies the struct and add the offset to the proper
> > > > address.
> > > 
> > > Well what you propose here can lead to all kind of problems and is
> > > rather bad design as far as I can see.
> > > 
> > > The struct dma_buf_map is only to be filled in by the exporter and
> > > should not be modified in this way by the importer.
> > 
> > humn... not sure if I was  clear. There is no importer and exporter here.
> 
> Yeah, and exactly that's what I'm pointing out as problem here.
> 
> You are using the inter driver framework for something internal to the
> driver. That is an absolutely clear NAK!
> 
> We could discuss that, but you guys are just sending around patches to do
> this without any consensus that this is a good idea.

Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.

Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.

> > There is a role delegation on filling out and reading a buffer when
> > that buffer represents a struct layout.
> > 
> > struct bla {
> > int a;
> > int b;
> > int c;
> > struct foo foo;
> > struct bar bar;
> > int d;
> > }
> > 
> > 
> > This implementation allows you to have:
> > 
> > fill_foo(struct dma_buf_map *bla_map) { ... }
> > fill_bar(struct dma_buf_map *bla_map) { ... }
> > 
> > and the first thing these do is to make sure the map it's pointing to
> > is relative to the struct it's supposed to write/read. Otherwise you're
> > suggesting everything to be relative to struct bla, or to do the same
> > I'm doing it, but IMO more prone to error:
> > 
> > struct dma_buf_map map = *bla_map;
> > dma_buf_map_incr(map, offsetof(...));

Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.
-Daniel

> > IMO this construct is worse because at a point in time in the function
> > the map was pointing to the wrong thing the function was supposed to
> > read/write.
> > 
> > It's also useful when the function has double duty, updating a global
> > part of the struct and a table inside it (see example in patch 6)
> > 
> > thanks
> > Lucas De Marchi
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm: rcar-du: Drop LVDS device tree backward compatibility

2022-01-27 Thread Geert Uytterhoeven

Hi Laurent,

Thanks for your patch!

On Wed, Jan 26, 2022 at 9:30 PM Laurent Pinchart
 wrote:
> The rcar-du driver goes to great lengths to preserve device tree
> backward compatibility for the LVDS encoders by patching old device
> trees at runtime.
>
> The last R-Car Gen2 platform was converted to the new bindings commit
> edb0c3affe5214a2 ("ARM: dts: r8a7793: Convert to new LVDS DT bindings"),
> in v4.17, and the last RZ/G1 platform converted in commit
> 6a6a797625b5fe85 ("ARM: dts: r8a7743: Convert to new LVDS DT bindings"),
> in v5.0. Both are older than commit 58256143cff7c2e0 ("clk: renesas:
> Remove R-Car Gen2 legacy DT clock support"), in v5.5, which removes
> support for legacy bindings for clocks. The LBDS compatibility code is

LVDS

> thus not needed anymore. Drop it.
>
> Signed-off-by: Laurent Pinchart 

>  .../drm/rcar-du/rcar_du_of_lvds_r8a7795.dts   |  43 ---
>  .../drm/rcar-du/rcar_du_of_lvds_r8a7796.dts   |  43 ---

I had completely forgotten this was used on R-Car Gen3, too, until
commit 58e8ed2ee9abe718 ("arm64: dts: renesas: Convert to new LVDS
DT bindings") in v4.20.  I guess that's old enough?

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Intel-gfx] [PATCH 01/19] dma-buf-map: Add read/write helpers

On Thu, Jan 27, 2022 at 08:59:36AM +0100, Christian König wrote:
> Am 27.01.22 um 08:36 schrieb Matthew Brost:
> > [SNIP]
> > > >/**
> > > > * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> > > > * @dst: The dma-buf mapping structure
> > > > @@ -263,4 +304,44 @@ static inline void dma_buf_map_incr(struct 
> > > > dma_buf_map *map, size_t incr)
> > > > map->vaddr += incr;
> > > >}
> > > > +/**
> > > > + * dma_buf_map_read_field - Read struct member from dma-buf mapping 
> > > > with
> > > > + * arbitrary size and handling un-aligned accesses
> > > > + *
> > > > + * @map__: The dma-buf mapping structure
> > > > + * @type__:The struct to be used containing the field to read
> > > > + * @field__:   Member from struct we want to read
> > > > + *
> > > > + * Read a value from dma-buf mapping calculating the offset and size: 
> > > > this assumes
> > > > + * the dma-buf mapping is aligned with a a struct type__. A single u8, 
> > > > u16, u32
> > > > + * or u64 can be read, based on the offset and size of type__.field__.
> > > > + */
> > > > +#define dma_buf_map_read_field(map__, type__, field__) ({  
> > > > \
> > > > +   type__ *t__;
> > > > \
> > > > +   typeof(t__->field__) val__; 
> > > > \
> > > > +   dma_buf_map_memcpy_from_offset(&val__, map__, offsetof(type__, 
> > > > field__),\
> > > > +  sizeof(t__->field__));   
> > > > \
> > > > +   val__;  
> > > > \
> > > > +})
> > > > +
> > > > +/**
> > > > + * dma_buf_map_write_field - Write struct member to the dma-buf 
> > > > mapping with
> > > > + * arbitrary size and handling un-aligned accesses
> > > > + *
> > > > + * @map__: The dma-buf mapping structure
> > > > + * @type__:The struct to be used containing the field to write
> > > > + * @field__:   Member from struct we want to write
> > > > + * @val__: Value to be written
> > > > + *
> > > > + * Write a value to the dma-buf mapping calculating the offset and 
> > > > size.
> > > > + * A single u8, u16, u32 or u64 can be written based on the offset and 
> > > > size of
> > > > + * type__.field__.
> > > > + */
> > > > +#define dma_buf_map_write_field(map__, type__, field__, val__) ({  
> > > > \
> > > > +   type__ *t__;
> > > > \
> > > > +   typeof(t__->field__) val = val__;   
> > > > \
> > > > +   dma_buf_map_memcpy_to_offset(map__, offsetof(type__, field__),  
> > > > \
> > > > +&val, sizeof(t__->field__));   
> > > > \
> > > > +})
> > > > +
> > > Uff well that absolutely looks like overkill to me.
> > > 
> > Hold on...
> > 
> > > That's a rather special use case as far as I can see and I think we should
> > > only have this in the common framework if more than one driver is using 
> > > it.
> > > 
> > I disagree, this is rather elegant.
> > 
> > The i915 can't be the *only* driver that defines a struct which
> > describes the layout of a dma_buf object.
> 
> That's not the problem, amdgpu as well as nouveau are doing that as well.
> The problem is DMA-buf is a buffer sharing framework between drivers.
> 
> In other words which importer is supposed to use this with a DMA-buf
> exported by another device?
> 
> > IMO this base macro allows *all* other drivers to build on this write
> > directly to fields in structures those drivers have defined.
> 
> Exactly that's the point. This is something drivers should absolutely *NOT*
> do.
> 
> That are driver internals and it is extremely questionable to move this into
> the common framework.

See my other reply.

This is about struct dma_buf_map, which is just a tagged pointer.

Which happens to be used by the dma_buf cross-driver interface, but it's
also used plenty internally in buffer allocation helpers, fbdev,
everything else. And it was _meant_ to be used like that - this thing is
my idea, I know :-)

I guess we could move/rename it, but like I said I really don't have any
good ideas. Got some?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] drm-misc-fixes

Hi Dave and Daniel,

here's this week's PR for drm-misc-fixes. Besides the bug fixes, it
contains a backmerge from drm/drm-fixes to get the tree to v5.17-rc1.

Best regards
Thomas

drm-misc-fixes-2022-01-27:
 * drm/ast: Revert 1600x800 with 108MHz PCLK
 * drm/atomic: fix CRTC handling during modeset
 * drm/privacy-screen: Honor acpi=off
 * drm/ttm: build fix for ARCH=um
The following changes since commit e783362eb54cd99b2cac8b3a9aeac942e6f6ac07:

  Linux 5.17-rc1 (2022-01-23 10:12:53 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-01-27

for you to fetch changes up to 7fde14d705985dd933a3d916d39daa72b1668098:

  drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen 
(2022-01-26 15:25:50 +0100)


 * drm/ast: Revert 1600x800 with 108MHz PCLK
 * drm/atomic: fix CRTC handling during modeset
 * drm/privacy-screen: Honor acpi=off
 * drm/ttm: build fix for ARCH=um


Dave Airlie (1):
  Revert "drm/ast: Support 1600x900 with 108MHz PCLK"

Manasi Navare (1):
  drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

Thomas Zimmermann (1):
  Merge drm/drm-fixes into drm-misc-fixes

Tong Zhang (1):
  drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen

 drivers/gpu/drm/ast/ast_tables.h |  2 --
 drivers/gpu/drm/drm_atomic.c | 12 
 drivers/gpu/drm/drm_privacy_screen_x86.c |  3 +++
 3 files changed, 11 insertions(+), 6 deletions(-)

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

Re: [PATCH] drm/doc: Add section in the introduction page about learning material

2022-01-27 Thread Pekka Paalanen

On Thu, 27 Jan 2022 09:20:58 +0100
Javier Martinez Canillas  wrote:

> The Linux DRM subsystem supports complex graphics devices and it could be
> quite overwhelming for newcomers to learn about the subsystem's internals.
> 
> There are lots of useful talks, slides and articles available that can be
> used to get familiar with the needed concepts and ease the learning curve.
> 
> Add a section to the intro that contains these DRM introductory materials.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  Documentation/gpu/introduction.rst | 36 ++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/Documentation/gpu/introduction.rst 
> b/Documentation/gpu/introduction.rst
> index 25a56e9c0cfd..35986784f916 100644
> --- a/Documentation/gpu/introduction.rst
> +++ b/Documentation/gpu/introduction.rst
> @@ -112,3 +112,39 @@ Please conduct yourself in a respectful and civilised 
> manner when
>  interacting with community members on mailing lists, IRC, or bug
>  trackers. The community represents the project as a whole, and abusive
>  or bullying behaviour is not tolerated by the project.
> +
> +Learning material
> +=
> +
> +Since the Linux DRM layer supports complex graphics devices, it can be quite
> +overwhelming for newcomers to get familiar with all the needed concepts and
> +learn the subsystem's internals.

Hi,

this seems to say that DRM is going to be complicated no matter what
hardware one wants to drive, but is that true?

Is there no way to say that if your display hardware is simple (no
GPU), then the driver can be simple to write too?

> +
> +To shallow the learning curve, this section contains a list of presentations
> +and documents that can be used to learn about DRM/KMS and graphics in 
> general.
> +
> +The list is sorted in reverse chronological order, to keep the most 
> up-to-date
> +material at the top. But all of them contain useful information, and it can 
> be
> +valuable to go through older material to understand the rationale and context
> +in which the recent changes to the DRM subsystem were made.
> +
> +Talks
> +-
> +
> +* `An Overview of the Linux and Userspace Graphics Stack 
> `_ - Paul Kocialkowski (2020)
> +* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting 
> `_ - Simon Ser (2020)
> +* `An introduction to the Linux DRM subsystem 
> `_ - Maxime Ripard (2017)
> +* `Embrace the Atomic (Display) Age 
> `_ - Daniel Vetter (2016)
> +* `Anatomy of an Atomic KMS Driver 
> `_ - Laurent Pinchart (2015)
> +* `Atomic Modesetting for Drivers 
> `_ - Daniel Vetter (2015)
> +* `Anatomy of an Embedded KMS Driver 
> `_ - Laurent Pinchart (2013
> +
> +Slides and articles
> +---
> +
> +* `Understanding the Linux Graphics Stack 
> `_ - Bootlin 
> (2022)
> +* `DRM KMS overview `_ - 
> STMicroelectronics (2021)
> +* `Linux graphic stack 
> `_ - 
> Nathan Gauër (2017)
> +* `The DRM/KMS subsystem from a newbie’s point of view 
> `_
>  - Boris Brezillon (2014)
> +* `A brief introduction to the Linux graphics stack 
> `_
>  - Iago Toral (2014)
> +* `The Linux Graphics Stack 
> `_ - Jasper St. 
> Pierre (2012)

That's an impressive list of links!

However, given the discussions that prompted this doc, I think the gist
is missing. The reader is just flooded with stuff to read and learn
which can be discouraging.

Your audience are developers who know nothing about DRM. They may have
been writing fb drivers instead. The display hardware they want to
drive has no GPU. Where should they get started? Which presentations to
read/watch first? Which driver to look at for a simple example?

Maybe add one more section targeting that specific audience?


Thanks,
pq


pgpPXiam_QD6_.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

2022-01-27 Thread Lucas De Marchi


On Thu, Jan 27, 2022 at 09:55:05AM +0100, Christian König wrote:

Am 27.01.22 um 09:18 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

[SNIP]
humn... not sure if I was  clear. There is no importer and 
exporter here.


Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to 
the driver. That is an absolutely clear NAK!


We could discuss that, but you guys are just sending around 
patches to do this without any consensus that this is a good idea.


s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in
these patches. I'm sending these to _build consensus_ on what may be 
a good

use for it showing a real problem it's helping to fix.


Well a cover letter would have been helpful, my impression was that 
you have a larger set and just want to upstream some minor DMA-buf 
changes necessary for it.


I missed adding this sentence to the cover letter, as my impression was that
dma-buf-map was already used outside inter-driver framework. But there
is actually a cover letter:

https://lore.kernel.org/all/20220126203702.1784589-1-lucas.demar...@intel.com/

And looking at it now, it seems I missed adding Thomas Zimmermann to Cc.



Now I know why people are bugging me all the time to add cover letters 
to add more context to my sets.




From its documentation:

 * The type :c:type:`struct dma_buf_map ` and its 
helpers are
 * actually independent from the dma-buf infrastructure. When 
sharing buffers
 * among devices, drivers have to know the location of the memory to 
access

 * the buffers in a safe way. :c:type:`struct dma_buf_map `
 * solves this problem for dma-buf and its users. If other drivers or
 * sub-systems require similar functionality, the type could be 
generalized

 * and moved to a more prominent header file.

if there is no consensus and a better alternative, I'm perfectly fine in
throwing it out and using the better approach.


When Thomas Zimmermann upstreamed the dma_buf_map work we had a 
discussion if that shouldn't be independent of the DMA-buf framework.


The consensus was that as soon as we have more widely use for it this 
should be made independent. So basically that is what's happening now.


I suggest the following approach:
1. Find a funky name for this, something like iomem_, kiomap_ or similar.


iosys_map?

2. Separate this from all you driver dependent work and move the 
dma_buf_map structure out of DMA-buf into this new whatever_ prefix.


should this be a follow up to the driver work or a prerequisite?

thanks
Lucas De Marchi

3. Ping Thomas, LKML, me and probably a couple of other core people if 
this is the right idea or not.
4. Work on dropping the map parameter from dma_buf_vunmap(). This is 
basically why we can't modify the pointers returned from 
dma_buf_vmap() and has already cause a few problems with 
dma_buf_map_incr().


Regards,
Christian.



Lucas De Marchi

Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

On Wed, Jan 26, 2022 at 03:30:35PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 12:38:09PM +0100, Helge Deller wrote:
> > On 1/26/22 12:24, Daniel Vetter wrote:
> > > On Wed, Jan 26, 2022 at 12:18 PM Javier Martinez Canillas
> > >  wrote:
> > >> On 1/26/22 11:59, Helge Deller wrote:
> > >>> On 1/26/22 11:02, Andy Shevchenko wrote:
> 
> ...
> 
> >  P.S. For the record, I will personally NAK any attempts to remove that
> >  driver from the kernel. And this is another point why it's better not
> >  to be under the staging.
> > >>>
> > >>> I agree. Same as for me to NAK the disabling of fbcon's acceleration
> > >>> features or even attempting to remove fbdev altogether (unless all
> > >>> relevant drivers are ported to DRM).
> > >>
> > >> But that will never happen if we keep moving the goal post.
> > >>
> > >> At some point new fbdev drivers should not be added anymore, otherwise
> > >> the number of existing drivers that need conversion will keep growing.
> > >
> > > And that point was about 5 years ago, and has been discussed at some
> > > plumbers meanwhile, resulting in the staging TODO patches to make
> > > these drm drivers to destage them.
> > >
> > > Fixing bugs in fbdev is all fine, reopening it for merging new drivers is 
> > > not.
> > 
> > We are on the same page!
> > I'm not at all proposing to include new drivers for (relatively) new
> > hardware into fbdev, which is capable to be written as DRM driver.
> 
> Agree. The point here is neither in opening it for new comers nor for
> expanding, the drivers in question are all in the kernel in different folder
> that is not suitable for them, but I gave up. I see that nobody wants
> maintainers to be appearing for the old _working_ code, as it was shown
> already by the DVB case few month ago.

I mean, the main reason fbtft was in staging all this time has never
been about fbdev. It was about the device tree bindings that have never
been documented, reviewed and agreed upon. And given its bindings, we're
very far from it.

That's what Noralf has been mostly working on all this time, and yeah,
it takes time but we're getting there.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] drm/doc: Add section in the introduction page about learning material


Hi Javier,

thanks for this patch.

Acked-by: Thomas Zimmermann 

Find some ideas for consideration below.

Am 27.01.22 um 09:20 schrieb Javier Martinez Canillas:

The Linux DRM subsystem supports complex graphics devices and it could be
quite overwhelming for newcomers to learn about the subsystem's internals.

There are lots of useful talks, slides and articles available that can be
used to get familiar with the needed concepts and ease the learning curve.

Add a section to the intro that contains these DRM introductory materials.

Suggested-by: Daniel Vetter 
Signed-off-by: Javier Martinez Canillas 
---

  Documentation/gpu/introduction.rst | 36 ++
  1 file changed, 36 insertions(+)

diff --git a/Documentation/gpu/introduction.rst 
b/Documentation/gpu/introduction.rst
index 25a56e9c0cfd..35986784f916 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -112,3 +112,39 @@ Please conduct yourself in a respectful and civilised 
manner when
  interacting with community members on mailing lists, IRC, or bug
  trackers. The community represents the project as a whole, and abusive
  or bullying behaviour is not tolerated by the project.
+
+Learning material
+=


Maybe 'External References'.


+
+Since the Linux DRM layer supports complex graphics devices, it can be quite
+overwhelming for newcomers to get familiar with all the needed concepts and
+learn the subsystem's internals.


It sounds a bit intimdating to me. Can we give it a positive spin?

IMHO we could add a separate section that talks about complexity and 
provides guidelines about how to deal with it:  trivial HW? use simple 
pipe;  dedicated VRAM? try TTM;  awkward color formats?  see 
drm_format_helper.c


Best regards
Thomas


+
+To shallow the learning curve, this section contains a list of presentations
+and documents that can be used to learn about DRM/KMS and graphics in general.
+
+The list is sorted in reverse chronological order, to keep the most up-to-date
+material at the top. But all of them contain useful information, and it can be
+valuable to go through older material to understand the rationale and context
+in which the recent changes to the DRM subsystem were made.
+
+Talks
+-
+
+* `An Overview of the Linux and Userspace Graphics Stack 
`_ - Paul Kocialkowski (2020)
+* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting 
`_ - Simon Ser (2020)
+* `An introduction to the Linux DRM subsystem 
`_ - Maxime Ripard (2017)
+* `Embrace the Atomic (Display) Age 
`_ - Daniel Vetter (2016)
+* `Anatomy of an Atomic KMS Driver 
`_ - Laurent Pinchart (2015)
+* `Atomic Modesetting for Drivers 
`_ - Daniel Vetter (2015)
+* `Anatomy of an Embedded KMS Driver 
`_ - Laurent Pinchart (2013
+
+Slides and articles
+---
+
+* `Understanding the Linux Graphics Stack 
`_ - Bootlin 
(2022)
+* `DRM KMS overview `_ - 
STMicroelectronics (2021)
+* `Linux graphic stack 
`_ - Nathan 
Gauër (2017)
+* `The DRM/KMS subsystem from a newbie’s point of view 
`_
 - Boris Brezillon (2014)
+* `A brief introduction to the Linux graphics stack 
`_
 - Iago Toral (2014)
+* `The Linux Graphics Stack 
`_ - Jasper St. 
Pierre (2012)


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

Am 27.01.22 um 10:12 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 09:55:05AM +0100, Christian König wrote:

Am 27.01.22 um 09:18 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

[SNIP]
humn... not sure if I was clear. There is no importer and
exporter here.

Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to
the driver. That is an absolutely clear NAK!

We could discuss that, but you guys are just sending around patches
to do this without any consensus that this is a good idea.

s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in
these patches. I'm sending these to _build consensus_ on what may be
a good

use for it showing a real problem it's helping to fix.

Well a cover letter would have been helpful, my impression was that
you have a larger set and just want to upstream some minor DMA-buf
changes necessary for it.

I missed adding this sentence to the cover letter, as my impression
was that

dma-buf-map was already used outside inter-driver framework. But there
is actually a cover letter:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220126203702.1784589-1-lucas.demarchi%40intel.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb36def4a6ebd4879731c08d9e1753ccd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637788715933199161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gwW05OaUq%2FxlBWnY%2FPuPfl0YDdKp5VTbllaSmn45nE8%3D&reserved=0

And looking at it now, it seems I missed adding Thomas Zimmermann to Cc.

Now I know why people are bugging me all the time to add cover
letters to add more context to my sets.

From its documentation:

* The type :c:type:`struct dma_buf_map ` and its
helpers are
* actually independent from the dma-buf infrastructure. When
sharing buffers
* among devices, drivers have to know the location of the memory to
access
* the buffers in a safe way. :c:type:`struct dma_buf_map
`

* solves this problem for dma-buf and its users. If other drivers or
* sub-systems require similar functionality, the type could be
generalized

* and moved to a more prominent header file.

if there is no consensus and a better alternative, I'm perfectly
fine in

throwing it out and using the better approach.

When Thomas Zimmermann upstreamed the dma_buf_map work we had a
discussion if that shouldn't be independent of the DMA-buf framework.

The consensus was that as soon as we have more widely use for it this
should be made independent. So basically that is what's happening now.

I suggest the following approach:
1. Find a funky name for this, something like iomem_, kiomap_ or
similar.

iosys_map?

Works for me.

2. Separate this from all you driver dependent work and move the
dma_buf_map structure out of DMA-buf into this new whatever_ prefix.

should this be a follow up to the driver work or a prerequisite?

Prerequisite. Structural changes like this always separate to the
actually work switching over to them because the later needs a much
fewer audience for review.

Regards,
Christian.

thanks
Lucas De Marchi

3. Ping Thomas, LKML, me and probably a couple of other core people
if this is the right idea or not.
4. Work on dropping the map parameter from dma_buf_vunmap(). This is
basically why we can't modify the pointers returned from
dma_buf_vmap() and has already cause a few problems with
dma_buf_map_incr().

Regards,
Christian.

Lucas De Marchi

Re: [PATCH v1, 7/8] media: uapi: Init VP9 stateless decode params

2022-01-27 Thread Chen-Yu Tsai

Hi,

On Thu, Jan 27, 2022 at 10:56 AM Yunfei Dong  wrote:
>
> Init some of VP9 frame decode params to default value.
>
> Signed-off-by: Yunfei Dong 

Maybe add

Fixes: b88dbe38dca8 ("media: uapi: Add VP9 stateless decoder controls")

> ---
>  drivers/media/v4l2-core/v4l2-ctrls-core.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c 
> b/drivers/media/v4l2-core/v4l2-ctrls-core.c
> index 54abe5245dcc..b25c77b8a445 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
> @@ -112,6 +112,7 @@ static void std_init_compound(const struct v4l2_ctrl 
> *ctrl, u32 idx,
> struct v4l2_ctrl_mpeg2_picture *p_mpeg2_picture;
> struct v4l2_ctrl_mpeg2_quantisation *p_mpeg2_quant;
> struct v4l2_ctrl_vp8_frame *p_vp8_frame;
> +   struct v4l2_ctrl_vp9_frame *p_vp9_frame;
> struct v4l2_ctrl_fwht_params *p_fwht_params;
> void *p = ptr.p + idx * ctrl->elem_size;
>
> @@ -152,6 +153,13 @@ static void std_init_compound(const struct v4l2_ctrl 
> *ctrl, u32 idx,
> p_vp8_frame = p;
> p_vp8_frame->num_dct_parts = 1;
> break;
> +   case V4L2_CTRL_TYPE_VP9_FRAME:
> +   p_vp9_frame = p;
> +   p_vp9_frame->profile = 0;
> +   p_vp9_frame->bit_depth = 8;
> +   p_vp9_frame->flags |= V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING |
> +   V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING;
> +   break;
> case V4L2_CTRL_TYPE_FWHT_PARAMS:
> p_fwht_params = p;
> p_fwht_params->version = V4L2_FWHT_VERSION;
> --
> 2.25.1
>

Re: [PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate

Hi Peter,

On Wed, Jan 26, 2022 at 03:24:26PM -0500, Peter Geis wrote:
> The hdmi-cec clock must be 32khz in order for cec to work correctly.
> Ensure after enabling the clock we set it in order for the hardware to
> work as expected.
> Warn on failure, in case this is a static clock that is slighty off.
> Fixes hdmi-cec support on Rockchip devices.

You removed this sentence in v2, but I just wanted to mention that
clk_set_rate() won't fail when the desired clock rate can't be
archieved. Instead, you will get the best rate that actually can be
reached. If you want to check that you are happy with the rate you'll
have to do a clk_round_rate() before setting the rate or a
clk_get_rate() afterwards.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

2022-01-27 Thread Lucas De Marchi

On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > When dma_buf_map struct is passed around, it's useful to be able to
> > > initialize a second map that takes care of reading/writing to an offset
> > > of the original map.
> > >
> > > Add a helper that copies the struct and add the offset to the proper
> > > address.
> >
> > Well what you propose here can lead to all kind of problems and is
> > rather bad design as far as I can see.
> >
> > The struct dma_buf_map is only to be filled in by the exporter and
> > should not be modified in this way by the importer.
>
> humn... not sure if I was  clear. There is no importer and exporter here.

Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!

We could discuss that, but you guys are just sending around patches to do
this without any consensus that this is a good idea.

Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.

Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.

I suggest iosys_map since it abstracts access to IO and system memory.

> There is a role delegation on filling out and reading a buffer when
> that buffer represents a struct layout.
>
> struct bla {
> int a;
> int b;
> int c;
> struct foo foo;
> struct bar bar;
> int d;
> }
>
>
> This implementation allows you to have:
>
> fill_foo(struct dma_buf_map *bla_map) { ... }
> fill_bar(struct dma_buf_map *bla_map) { ... }
>
> and the first thing these do is to make sure the map it's pointing to
> is relative to the struct it's supposed to write/read. Otherwise you're
> suggesting everything to be relative to struct bla, or to do the same
> I'm doing it, but IMO more prone to error:
>
> struct dma_buf_map map = *bla_map;
> dma_buf_map_incr(map, offsetof(...));

Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.

I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start

struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */

is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding

While with the construct below

other_map;
...
other_map = INITIALIZER()

I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the beggining of the
function when the offset is constant:

struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));

Lucas De Marchi

-Daniel

> IMO this construct is worse because at a point in time in the function
> the map was pointing to the wrong thing the function was supposed to
> read/write.
>
> It's also useful when the function has double duty, updating a global
> part of the struct and a table inside it (see example in patch 6)
>
> thanks
> Lucas De Marchi

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

RE: [PATCH 1/3] drm: add writeback pointers to drm_connector

2022-01-27 Thread Kandpal, Suraj

> 
> + laurent on this
> 
> Hi Suraj
> Jani pointed me to this thread as i had posted something similar here :
> https://patchwork.freedesktop.org/patch/470296/ but since this thread was
> posted earlier, we can discuss further here.
> 
> Overall, its similar to what I had posted in the RFC and your commit text also
> covers my concerns too.
> 
> One question I have about your change is since you have changed
> wb_connector::encoder to be a pointer, i saw the other changes in the series
> but they do not allocate an encoder. Would this not affect the other drivers
> which are assuming that the encoder in wb_connector is struct drm_encoder
> encoder and not struct drm_encoder* encoder.
> 
> Your changes fix the compilation issue but wouldnt this crash as encoder
> wasnt allocated for other drivers.
> 

Hi Abhinav,
That shouldn't be an issue as normally drivers tend to have their own output
structure which has drm_connector and drm_encoder embedded in it depending 
on the level of binding they have decided to give the connector and encoder in
their respective output and the addresses of these are passed to the 
drm_connector* and drm_encoder* in drm_writeback_connector structure 
which then gets initialized in drm_writeback_connector_init().

In our i915 code we have intel_connector structure with drm_connector base 
field and intel_wd with a intel_encoder base which in turn has drm_encoder
field and both intel_connector and intel_wd are initialized not requiring 
explicit
alloc and dealloc for drm_encoder
intel_wd = kzalloc(sizeof(*intel_wd), GFP_KERNEL);

intel_connector = intel_connector_alloc();
wb_conn = &intel_connector->wb_conn;
wb_conn->base = &intel_connector->base;
wb_conn->encoder = &intel_wd->base.base;

Similary for komeda driver has 
struct komeda_wb_connector {
struct drm_connector conn;
/** @base: &drm_writeback_connector */
struct drm_writeback_connector base;

/** @wb_layer: represents associated writeback pipeline of komeda */
struct komeda_layer *wb_layer;
};

static int komeda_wb_connector_add(struct komeda_kms_dev *kms,
   struct komeda_crtc *kcrtc)
{
struct komeda_wb_connector *kwb_conn;
struct drm_writeback_connector *wb_conn;

kwb_conn = kzalloc(sizeof(*kwb_conn), GFP_KERNEL);

wb_conn = &kwb_conn->base;
wb_conn->base = &kwb_conn->conn;
  
and they do not depend on the encoder binding so changes will work for them
Also in vkms driver we have the 
struct vkms_output {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
struct drm_writeback_connector wb_connector;
struct hrtimer vblank_hrtimer;
ktime_t period_ns;
struct drm_pending_vblank_event *event;
/* ordered wq for composer_work */
struct workqueue_struct *composer_workq;
/* protects concurrent access to composer */
spinlock_t lock;

/* protected by @lock */
bool composer_enabled;
struct vkms_crtc_state *composer_state;

spinlock_t composer_lock;
};

Which gets allocated covering for the drm_encoder alloc and dealloc

Regards,
Suraj Kandpal

Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

Hi Rob,

On Mon, Jan 24, 2022 at 10:42:37AM -0600, Rob Herring wrote:
> On Mon, Jan 24, 2022 at 10:28 AM Noralf Trønnes  wrote:
> >
> >
> >
> > Den 24.01.2022 17.08, skrev Rob Herring:
> > > On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes  
> > > wrote:
> > >>
> > >> Add binding for MIPI DBI compatible SPI panels.
> > >
> > > I'm sure we already have MIPI DBI panels. What's this for?
> > >
> >
> > It aims to use one driver to cover all MIPI DBI panels where the
> > controller setup is loaded from userspace in a firmware file.
> 
> What's the solution when the user wants a splash screen in the
> bootloader and also wants multiple panels supported?
> 
> Also, 1 driver doesn't dictate 1 compatible. A one to many
> relationship is fine and makes the decision entirely the OS's.
> 
> > The cover
> > letter points to the discussion where Maxime proposed this:
> >
> > https://lore.kernel.org/dri-devel/20211129093946.xhp22mvdut3m67sc@houat/
> 
> The proposal there is:
> 
> > compatible = "panel-spi";
> > model = "panel-from-random-place-42";
> 
> The same thing can be accomplished with this:
> 
> compatible = "panel-from-random-place-42", "panel-spi";
> 
> What's the advantage of hijacking 'model'?

So, the main issue is that a panel is essentially two things: a
controller and the actual panel.

The controller has an initialization sequence of its own, and part of it
is parameters to match the panel.

So you can have identical controllers that won't have the same
initialization sequence because they don't have the same panel.

I was assuming that a compatible would be more about the controller, so
we needed something else, thus "model"

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

Hi,

On Tue, Jan 25, 2022 at 06:56:58PM +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
> 
> v2:
> - Fix path for panel-common.yaml
> - Use unevaluatedProperties
> - Drop properties which are in the allOf section
> - Drop model property (Rob)
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  .../display/panel/panel-mipi-dbi-spi.yaml | 59 +++
>  1 file changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> new file mode 100644
> index ..b7cbeea0f8aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MIPI DBI SPI Panels Device Tree Bindings
> +
> +maintainers:
> +  - Noralf Trønnes 
> +
> +description:
> +  This binding is for display panels using a MIPI DBI controller
> +  in SPI mode.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> +  compatible:
> +const: panel-mipi-dbi-spi

You need contains here, otherwise it will error out if you have two compatibles.

> +  write-only:
> +type: boolean
> +description:
> +  Controller is not readable (ie. MISO is not wired up).
> +
> +  dc-gpios:
> +maxItems: 1
> +description: |
> +  Controller data/command selection (D/CX) in 4-line SPI mode.
> +  If not set, the controller is in 3-line SPI mode.
> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +display@0{
> +compatible = "panel-mipi-dbi-spi";

We should have two compatibles in the example too

Maxime


signature.asc
Description: PGP signature

Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: add needs_compact_pt flag

2022-01-27 Thread Intel




On 1/26/22 18:11, Robert Beckett wrote:



On 26/01/2022 13:49, Thomas Hellström (Intel) wrote:


On 1/25/22 20:35, Robert Beckett wrote:

From: Ramalingam C 

Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.

With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.

Suggested-by: Matthew Auld 
Signed-off-by: Ramalingam C 
Signed-off-by: Robert Beckett 
---
  drivers/gpu/drm/i915/i915_drv.h  | 10 +++---
  drivers/gpu/drm/i915/i915_pci.c  |  2 ++
  drivers/gpu/drm/i915/intel_device_info.h |  1 +
  3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 44c1f98144b4..1258b7779705 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,16 @@ IS_SUBPLATFORM(const struct drm_i915_private 
*i915,

  /*
   * Set this flag, when platform requires 64K GTT page sizes or 
larger for
- * device local memory access. Also this flag implies that we 
require or
- * at least support the compact PT layout for the ppGTT when using 
the 64K

- * GTT pages.


Why do we remove these comment lines?
Because HAS_64K_PAGES now means just 64K page, it no longer means also 
requires compact pt.
This is to support other products that will have 64K but not have the 
PDE non-sharing restriction in future.


Those lines moved to the next change NEEDS_COMPACT_PT, which is now 
separate.


Yes, NEEDS_COMPACT_PT indicates that compact is *required* but does 
"HAS_64K_PAGES" still mean compact is supported? That information is lost.


/Thomas

Re: mmotm 2022-01-26-21-04 uploaded (gpu/drm/i915/i915_gem_evict.h)

2022-01-27 Thread Jani Nikula

On Wed, 26 Jan 2022, Randy Dunlap  wrote:
> On 1/26/22 21:04, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2022-01-26-21-04 has been uploaded to
>> 
>>https://www.ozlabs.org/~akpm/mmotm/
>> 
>> mmotm-readme.txt says
>> 
>> README for mm-of-the-moment:
>> 
>> https://www.ozlabs.org/~akpm/mmotm/
>> 
>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>> more than once a week.
>> 
>> You will need quilt to apply these patches to the latest Linus release (5.x
>> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>> https://ozlabs.org/~akpm/mmotm/series
>> 
>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>> followed by the base kernel version against which this patch series is to
>> be applied.
>
> on x86_64:
> (from linux-next.patch)
>
>
>   HDRTEST drivers/gpu/drm/i915/i915_gem_evict.h
> In file included from :0:0:
> ./../drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: ‘struct 
> i915_gem_ww_ctx’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
> struct i915_gem_ww_ctx *ww,
>^~~
> ./../drivers/gpu/drm/i915/i915_gem_evict.h:21:14: error: ‘struct 
> i915_gem_ww_ctx’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
>struct i915_gem_ww_ctx *ww,
>   ^~~
> ./../drivers/gpu/drm/i915/i915_gem_evict.h:25:16: error: ‘struct 
> i915_gem_ww_ctx’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
>  struct i915_gem_ww_ctx *ww);
> ^~~
> cc1: all warnings being treated as errors

Thanks for the report.

This is only visible with CONFIG_DRM_I915_WERROR=y which depends on
COMPILE_TEST=n. We use the "HDRTEST" and -Werror for development and CI
to keep the driver clean, but it's not really intended for general
consumption. Usually when something like this even hits the tree it's
because of a merge mishap somewhere down the line.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
> On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> > > Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > > > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > > > When dma_buf_map struct is passed around, it's useful to be able to
> > > > > > initialize a second map that takes care of reading/writing to an 
> > > > > > offset
> > > > > > of the original map.
> > > > > >
> > > > > > Add a helper that copies the struct and add the offset to the proper
> > > > > > address.
> > > > >
> > > > > Well what you propose here can lead to all kind of problems and is
> > > > > rather bad design as far as I can see.
> > > > >
> > > > > The struct dma_buf_map is only to be filled in by the exporter and
> > > > > should not be modified in this way by the importer.
> > > >
> > > > humn... not sure if I was  clear. There is no importer and exporter 
> > > > here.
> > > 
> > > Yeah, and exactly that's what I'm pointing out as problem here.
> > > 
> > > You are using the inter driver framework for something internal to the
> > > driver. That is an absolutely clear NAK!
> > > 
> > > We could discuss that, but you guys are just sending around patches to do
> > > this without any consensus that this is a good idea.
> > 
> > Uh I suggested this, also we're already using dma_buf_map all over the
> > place as a convenient abstraction. So imo that's all fine, it should allow
> > drivers to simplify some code where on igpu it's in normal kernel memory
> > and on dgpu it's behind some pci bar.
> > 
> > Maybe we should have a better name for that struct (and maybe also a
> > better place), but way back when we discussed that bikeshed I didn't come
> > up with anything better really.
> 
> I suggest iosys_map since it abstracts access to IO and system memory.
> 
> > 
> > > > There is a role delegation on filling out and reading a buffer when
> > > > that buffer represents a struct layout.
> > > >
> > > > struct bla {
> > > > int a;
> > > > int b;
> > > > int c;
> > > > struct foo foo;
> > > > struct bar bar;
> > > > int d;
> > > > }
> > > >
> > > >
> > > > This implementation allows you to have:
> > > >
> > > > fill_foo(struct dma_buf_map *bla_map) { ... }
> > > > fill_bar(struct dma_buf_map *bla_map) { ... }
> > > >
> > > > and the first thing these do is to make sure the map it's pointing to
> > > > is relative to the struct it's supposed to write/read. Otherwise you're
> > > > suggesting everything to be relative to struct bla, or to do the same
> > > > I'm doing it, but IMO more prone to error:
> > > >
> > > > struct dma_buf_map map = *bla_map;
> > > > dma_buf_map_incr(map, offsetof(...));
> > 
> > Wrt the issue at hand I think the above is perfectly fine code. The idea
> > with dma_buf_map is really that it's just a special pointer, so writing
> > the code exactly as pointer code feels best. Unfortunately you cannot make
> > them typesafe (because of C), so the code sometimes looks a bit ugly.
> > Otherwise we could do stuff like container_of and all that with
> > typechecking in the macros.
> 
> I had exactly this code above, but after writting quite a few patches
> using it, particularly with functions that have to write to 2 maps (see
> patch 6 for example), it felt much better to have something to
> initialize correctly from the start
> 
>   struct dma_buf_map other_map = *bla_map;
>   /* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
> 
> is error prone and hard to debug since you will be reading/writting
> from/to another location rather than exploding
> 
> While with the construct below
> 
>   other_map;
>   ...
>   other_map = INITIALIZER()
> 
> I can rely on the compiler complaining about uninitialized var. And
> in most of the cases I can just have this single line in the beggining of the
> function when the offset is constant:
> 
>   struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));

Hm yeah that's a good point that this allows us to rely on the compiler to
check for uninitialized variables.

Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my

Acked-by: Daniel Vetter 

I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.
-Daniel

> 
> Lucas De Marchi
> 
> > -Daniel
> > 
> > > > IMO this construct is worse because at a point in time in the function
> > > > the map was pointing to the wrong thing the function was supposed to
> > > > read/write.
> > > >
> > > > It's also useful when the function has double duty, updating a global
> > > > part of the struct and a table inside it (see example in patch 6)
> > > >
> > > > thanks
> > > > Lucas De Marchi
> > > 
> > 
> > -

Re: [RFC PATCH v5 0/3] Add support modifiers for drivers whose planes only support linear layout

On Thu, Jan 27, 2022 at 12:25:36PM +0900, Tomohito Esaki wrote:
> Some drivers whose planes only support linear layout fb do not support format
> modifiers.
> These drivers should support modifiers, however the DRM core should handle 
> this
> rather than open-coding in every driver.
> 
> In this patch series, these drivers expose format modifiers based on the
> following suggestion[1].
> 
> On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote:
> > I think the best way forward here is:
> >   - add a new mode_config.cannot_support_modifiers flag, and enable
> > this in radeon (plus any other drivers in the same boat)
> >   - change drm_universal_plane_init() to advertise the LINEAR modifier
> > when NULL is passed as the modifier list (including installing a
> > default .format_mod_supported hook)
> >   - remove the mode_config.allow_fb_modifiers hook and always
> > advertise modifier support, unless
> > mode_config.cannot_support_modifiers is set
> 
> 
> [1] 
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@igel.co.jp/#24602575

Two procedural things:
- There's an r-b on all the patches from Andy from the last round, please
  include that.
- Please also include a changelog per-patch (at least going forward), that
  helps with judging where a patch series is.

But aside from this I think this looks ready.

Cheers, Daniel

> 
> v5:
> * rebase to the latest master branch (5.17-rc1+)
>   + "drm/plane: Make format_mod_supported truly optional" patch [2]
>   [2] https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
> 
> * change default_modifiers array from non-static to static
> * remove terminator in default_modifiers array
> * use ARRAY_SIZE to get the format_modifier_count
> * keep a sanity check in plane init func
> * modify several kerneldocs
> 
> v4: https://www.spinics.net/lists/dri-devel/msg329508.html
> * modify documentation for fb_modifiers_not_supported flag in kerneldoc
> 
> v3: https://www.spinics.net/lists/dri-devel/msg329102.html
> * change the order as follows:
>1. add fb_modifiers_not_supported flag
>2. add default modifiers
>3. remove allow_fb_modifiers flag
> * add a conditional disable in amdgpu_dm_plane_init()
> 
> v2: https://www.spinics.net/lists/dri-devel/msg328939.html
> * rebase to the latest master branch (5.16.0+)
>   + "drm/plane: Make format_mod_supported truly optional" patch [2]
> 
> v1: https://www.spinics.net/lists/dri-devel/msg327352.html
> * The initial patch set
> 
> Tomohito Esaki (3):
>   drm: introduce fb_modifiers_not_supported flag in mode_config
>   drm: add support modifiers for drivers whose planes only support
> linear layout
>   drm: remove allow_fb_modifiers
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  6 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 ++
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +++
>  drivers/gpu/drm/drm_framebuffer.c |  6 ++---
>  drivers/gpu/drm/drm_ioctl.c   |  2 +-
>  drivers/gpu/drm/drm_plane.c   | 23 +++
>  drivers/gpu/drm/nouveau/nouveau_display.c |  6 +++--
>  drivers/gpu/drm/radeon/radeon_display.c   |  2 ++
>  .../gpu/drm/selftests/test-drm_framebuffer.c  |  1 -
>  include/drm/drm_mode_config.h | 18 +--
>  include/drm/drm_plane.h   |  3 +++
>  14 files changed, 45 insertions(+), 32 deletions(-)
> 
> -- 
> 2.25.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 3/3] drm/panel: Add MIPI DBI compatible SPI driver

On Tue, Jan 25, 2022 at 06:57:00PM +0100, Noralf Trønnes wrote:
> Add a driver that will work with most MIPI DBI compatible SPI panels.
> This avoids adding a driver for every new MIPI DBI compatible controller
> that is to be used by Linux. The 'compatible' Device Tree property with
> a '.bin' suffix will be used to load a firmware file that contains the
> controller configuration.
> 
> Example (driver will load sainsmart18.bin):
> 
> display@0 {
>   compatible = "sainsmart18", "panel-mipi-dbi-spi";
>   reg = <0>;
>   reset-gpios = <&gpio 25 0>;
>   dc-gpios = <&gpio 24 0>;
> };
> 
> v2:
> - Drop model property and use compatible instead (Rob)
> - Add wiki entry in MAINTAINERS
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/panel/Kconfig  |  11 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-mipi-dbi.c | 394 +
>  4 files changed, 414 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-mipi-dbi.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d03ad8da1f36..8baa98723bdc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6047,6 +6047,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
>  F:   Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
>  F:   drivers/gpu/drm/tiny/mi0283qt.c
>  
> +DRM DRIVER FOR MIPI DBI compatible panels
> +M:   Noralf Trønnes 
> +S:   Maintained
> +W:   https://github.com/notro/panel-mipi-dbi/wiki
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +F:   Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> +F:   drivers/gpu/drm/panel/panel-mipi-dbi.c
> +
>  DRM DRIVER FOR MSM ADRENO GPU
>  M:   Rob Clark 
>  M:   Sean Paul 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 434c2861bb40..1851cda5f877 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -274,6 +274,17 @@ config DRM_PANEL_LG_LG4573
> Say Y here if you want to enable support for LG4573 RGB panel.
> To compile this driver as a module, choose M here.
>  
> +config DRM_PANEL_MIPI_DBI
> + tristate "MIPI DBI compatible panel"
> + depends on SPI
> + depends on BACKLIGHT_CLASS_DEVICE
> + depends on DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DBI
> + help
> +   Say Y here if you want to enable support for MIPI DBI compatible 
> panels.
> +   To compile this driver as a module, choose M here.
> +
>  config DRM_PANEL_NEC_NL8048HL11
>   tristate "NEC NL8048HL11 RGB panel"
>   depends on GPIOLIB && OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index d99fbbce49d1..a90c30459964 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += 
> panel-leadtek-ltk050h3146w.o
>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
>  obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> +obj-$(CONFIG_DRM_PANEL_MIPI_DBI) += panel-mipi-dbi.o
>  obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
>  obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
>  obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
> diff --git a/drivers/gpu/drm/panel/panel-mipi-dbi.c 
> b/drivers/gpu/drm/panel/panel-mipi-dbi.c
> new file mode 100644
> index ..6e3dc2de21d2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-mipi-dbi.c
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DRM driver for MIPI DBI compatible display panels
> + *
> + * Copyright 2022 Noralf Trønnes
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const u8 panel_mipi_dbi_magic[15] = { 'M', 'I', 'P', 'I', ' ', 'D', 
> 'B', 'I',
> +  0, 0, 0, 0, 0, 0, 0 };
> +
> +/*
> + * The display panel configuration is stored in a firmware file. The Device 
> Tree 'compatible'
> + * property value with a '.bin' suffix is passed to request_firmware() to 
> fetch this file.
> + */
> +struct panel_mipi_dbi_config {
> + /* Magic string: panel_mipi_dbi_magic */
> + u8 magic[15];
> +
> + /* Config file format version */
> + u8 file_format_version;
> +
> + /* Width in pixels */
> + __be16 width;
> + /* Height in pixels */
> + __be16 height;
> +
> + /* Width in millimeters (optional) */
> + __be16 width_mm;
> + /* Height in millimeters (optional) */
> + __be16 height_mm;
> +
> + /* X-axis panel offset */
> + __be16 x_offset;
> + /* Y-axis panel offset */
> + __be16

Re: [PATCH] drivers: Fix typo in comment

On Thu, Jan 27, 2022 at 07:56:05AM +0100, Greg KH wrote:
> On Thu, Jan 27, 2022 at 02:51:56PM +0800, tangmeng wrote:
> > Replace disbale with disable and replace unavaibale with unavailable.
> > 
> > Signed-off-by: tangmeng 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
> >  drivers/gpu/drm/tilcdc/tilcdc_crtc.c  | 2 +-
> >  drivers/pcmcia/rsrc_nonstatic.c   | 2 +-
> >  drivers/usb/chipidea/udc.c| 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> This needs to be broken up per-subsystem, thanks.

For drm please also split it per-driver, so one patch per file you change
here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm/v3d: fix missing unlock

2022-01-27 Thread Yongzhi Liu

[why]
Unlock is needed on the error handling path to prevent dead lock.
v3d_submit_cl_ioctl and v3d_submit_csd_ioctl is missing unlock.

[how]
Fix this by change goto target on the error handling path.
As unlock is handle in fail_unreserve, i keep the failures
handling around there. So the goto targets a place between
`fail_unreserve:` and `fail:`.

Signed-off-by: Yongzhi Liu 
---
 drivers/gpu/drm/v3d/v3d_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index c7ed2e1..d9c7b39 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -798,7 +798,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
 
if (!render->base.perfmon) {
ret = -ENOENT;
-   goto fail;
+   goto v3d_unlock;
}
}
 
@@ -847,6 +847,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
 
 fail_unreserve:
mutex_unlock(&v3d->sched_lock);
+v3d_unlock:
drm_gem_unlock_reservations(last_job->bo,
last_job->bo_count, &acquire_ctx);
 fail:
@@ -1027,7 +1028,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
 args->perfmon_id);
if (!job->base.perfmon) {
ret = -ENOENT;
-   goto fail;
+   goto v3d_unlock;
}
}
 
@@ -1056,6 +1057,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
 
 fail_unreserve:
mutex_unlock(&v3d->sched_lock);
+v3d_unlock:
drm_gem_unlock_reservations(clean_job->bo, clean_job->bo_count,
&acquire_ctx);
 fail:
-- 
2.7.4

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map


Am 27.01.22 um 11:00 schrieb Daniel Vetter:

On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:

On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.

Add a helper that copies the struct and add the offset to the proper
address.

Well what you propose here can lead to all kind of problems and is
rather bad design as far as I can see.

The struct dma_buf_map is only to be filled in by the exporter and
should not be modified in this way by the importer.

humn... not sure if I was  clear. There is no importer and exporter here.

Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!

We could discuss that, but you guys are just sending around patches to do
this without any consensus that this is a good idea.

Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.

Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.

I suggest iosys_map since it abstracts access to IO and system memory.


There is a role delegation on filling out and reading a buffer when
that buffer represents a struct layout.

struct bla {
 int a;
 int b;
 int c;
 struct foo foo;
 struct bar bar;
 int d;
}


This implementation allows you to have:

 fill_foo(struct dma_buf_map *bla_map) { ... }
 fill_bar(struct dma_buf_map *bla_map) { ... }

and the first thing these do is to make sure the map it's pointing to
is relative to the struct it's supposed to write/read. Otherwise you're
suggesting everything to be relative to struct bla, or to do the same
I'm doing it, but IMO more prone to error:

 struct dma_buf_map map = *bla_map;
 dma_buf_map_incr(map, offsetof(...));

Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.

I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start

struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */

is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding

While with the construct below

other_map;
...
other_map = INITIALIZER()

I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the beggining of the
function when the offset is constant:

struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));

Hm yeah that's a good point that this allows us to rely on the compiler to
check for uninitialized variables.

Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my

Acked-by: Daniel Vetter 

I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.


There is one major issue remaining with this and that is dma_buf_vunmap():

void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);

Here we expect the original pointer as returned by dma_buf_map(), 
otherwise we vunmap() the wrong area!


For all TTM based driver this doesn't matter since we keep the vmap base 
separately in the BO anyway (IIRC), but we had at least one case where 
this made boom last year.


Christian.


-Daniel


Lucas De Marchi


-Daniel


IMO this construct is worse because at a point in time in the function
the map was pointing to the wrong thing the function was supposed to
read/write.

It's also useful when the function has double duty, updating a global
part of the struct and a table inside it (see example in patch 6)

thanks
Lucas De Marchi

--
Daniel Vetter
Software Engineer, Intel Corporation
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&dat

[PATCH] drm/fb-helper: Mark screen buffers in system memory with FB_VIRTFB

Mark screen buffers in system memory with FB_VIRTFB. Otherwise, the
buffers are mmap'ed as I/O memory (i.e., VM_IO). For shadow buffers,
also set the FB_READS_FAST hint.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_fb_helper.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ed43b987d306..f15127a32f7a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = sizes->surface_height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+   fbi->flags = FBINFO_DEFAULT;
 
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
 
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+   fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
 
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
-   if (map.is_iomem)
+   if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
-   else
+   } else {
fbi->screen_buffer = map.vaddr;
+   fbi->flags |= FBINFO_VIRTFB;
+   }
 
/*
 * Shamelessly leak the physical address to user-space. As
-- 
2.34.1

[PATCH 1/2] drm/gem-shmem: Set vm_ops in static initializer

Initialize default vm_ops in static initialization of the GEM SHMEM funcs,
instead of the mmap code. It's simply better style. GEM helpers will later
set a VMA's vm_ops from the default automatically.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 621924116eb4..2ced2ca83825 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -25,6 +25,8 @@
 
 MODULE_IMPORT_NS(DMA_BUF);
 
+static const struct vm_operations_struct drm_gem_shmem_vm_ops;
+
 /**
  * DOC: overview
  *
@@ -46,6 +48,7 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs 
= {
.vmap = drm_gem_shmem_object_vmap,
.vunmap = drm_gem_shmem_object_vunmap,
.mmap = drm_gem_shmem_object_mmap,
+   .vm_ops = &drm_gem_shmem_vm_ops,
 };
 
 static struct drm_gem_shmem_object *
@@ -625,7 +628,6 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, 
struct vm_area_struct
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
if (shmem->map_wc)
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-   vma->vm_ops = &drm_gem_shmem_vm_ops;
 
return 0;
 }
-- 
2.34.1

[PATCH 2/2] drm/gem-shmem: Don't store mmap'ed buffers in core dumps

Set the VM_DONTDUMP flag on mmap'ed VMAs to omit them from core
dumps. It's display-buffer memory; who knows what secrets these
buffers contain.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 2ced2ca83825..676575be5881 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -624,7 +624,7 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, 
struct vm_area_struct
return ret;
}
 
-   vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND;
+   vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
if (shmem->map_wc)
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-- 
2.34.1

Re: [PATCH] drm/fb-helper: Mark screen buffers in system memory with FB_VIRTFB




Am 27.01.22 um 11:26 schrieb Thomas Zimmermann:

Mark screen buffers in system memory with FB_VIRTFB. Otherwise, the


FBINFO_ is the name. Will be fixed before merging


buffers are mmap'ed as I/O memory (i.e., VM_IO). For shadow buffers,
also set the FB_READS_FAST hint.

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/drm_fb_helper.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ed43b987d306..f15127a32f7a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = sizes->surface_height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+   fbi->flags = FBINFO_DEFAULT;
  
  	drm_fb_helper_fill_info(fbi, fb_helper, sizes);
  
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,

fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+   fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
  
  		fbi->fbdefio = &drm_fbdev_defio;

-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
-   if (map.is_iomem)
+   if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
-   else
+   } else {
fbi->screen_buffer = map.vaddr;
+   fbi->flags |= FBINFO_VIRTFB;
+   }
  
  		/*

 * Shamelessly leak the physical address to user-space. As


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2] drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with external bridge

2022-01-27 Thread AngeloGioacchino Del Regno


Il 12/01/22 08:09, Jagan Teki ha scritto:

On Tue, Jan 4, 2022 at 3:30 PM AngeloGioacchino Del Regno
 wrote:


DRM bridge drivers are now attaching their DSI device at probe time,
which requires us to register our DSI host in order to let the bridge
to probe: this recently started producing an endless -EPROBE_DEFER
loop on some machines that are using external bridges, like the
parade-ps8640, found on the ACER Chromebook R13.

Now that the DSI hosts/devices probe sequence is documented, we can
do adjustments to the mtk_dsi driver as to both fix now and make sure
to avoid this situation in the future: for this, following what is
documented in drm_bridge.c, move the mtk_dsi component_add() to the
mtk_dsi_ops.attach callback and delete it in the detach callback;
keeping in mind that we are registering a drm_bridge for our DSI,
which is only used/attached if the DSI Host is bound, it wouldn't
make sense to keep adding our bridge at probe time (as it would
be useless to have it if mtk_dsi_ops.attach() fails!), so also move
that one to the dsi host attach function (and remove it in detach).

Signed-off-by: AngeloGioacchino Del Regno 

Reviewed-by: Andrzej Hajda 
---


Eventually I've observed similar issue on other Component based DSI
controllers, hence

Reviewed-by: Jagan Teki 



Hello dri-devel,
can you please pick this patch?

All MediaTek platforms are broken in v5.17 without this one.

Thanks,
Angelo

Re: [PATCH v1, 7/8] media: uapi: Init VP9 stateless decode params

2022-01-27 Thread AngeloGioacchino Del Regno


Il 27/01/22 03:55, Yunfei Dong ha scritto:

Init some of VP9 frame decode params to default value.

Signed-off-by: Yunfei Dong 


Hello Yunfei,

This patch is not strictly related to MediaTek SoCs, since it's
modfying v4l2-core.
Can you please send this patch separately?

Thanks,
Angelo


---
  drivers/media/v4l2-core/v4l2-ctrls-core.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c 
b/drivers/media/v4l2-core/v4l2-ctrls-core.c
index 54abe5245dcc..b25c77b8a445 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
@@ -112,6 +112,7 @@ static void std_init_compound(const struct v4l2_ctrl *ctrl, 
u32 idx,
struct v4l2_ctrl_mpeg2_picture *p_mpeg2_picture;
struct v4l2_ctrl_mpeg2_quantisation *p_mpeg2_quant;
struct v4l2_ctrl_vp8_frame *p_vp8_frame;
+   struct v4l2_ctrl_vp9_frame *p_vp9_frame;
struct v4l2_ctrl_fwht_params *p_fwht_params;
void *p = ptr.p + idx * ctrl->elem_size;
  
@@ -152,6 +153,13 @@ static void std_init_compound(const struct v4l2_ctrl *ctrl, u32 idx,

p_vp8_frame = p;
p_vp8_frame->num_dct_parts = 1;
break;
+   case V4L2_CTRL_TYPE_VP9_FRAME:
+   p_vp9_frame = p;
+   p_vp9_frame->profile = 0;
+   p_vp9_frame->bit_depth = 8;
+   p_vp9_frame->flags |= V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING |
+   V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING;
+   break;
case V4L2_CTRL_TYPE_FWHT_PARAMS:
p_fwht_params = p;
p_fwht_params->version = V4L2_FWHT_VERSION;

Re: [PATCH] drm/doc: Add section in the introduction page about learning material

Hello Pekka,

Thanks a lot for your feedback.

On 1/27/22 10:05, Pekka Paalanen wrote:
> On Thu, 27 Jan 2022 09:20:58 +0100
> Javier Martinez Canillas  wrote:
> 
>> The Linux DRM subsystem supports complex graphics devices and it could be
>> quite overwhelming for newcomers to learn about the subsystem's internals.
>>
>> There are lots of useful talks, slides and articles available that can be
>> used to get familiar with the needed concepts and ease the learning curve.
>>
>> Add a section to the intro that contains these DRM introductory materials.
>>
>> Suggested-by: Daniel Vetter 
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  Documentation/gpu/introduction.rst | 36 ++
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/Documentation/gpu/introduction.rst 
>> b/Documentation/gpu/introduction.rst
>> index 25a56e9c0cfd..35986784f916 100644
>> --- a/Documentation/gpu/introduction.rst
>> +++ b/Documentation/gpu/introduction.rst
>> @@ -112,3 +112,39 @@ Please conduct yourself in a respectful and civilised 
>> manner when
>>  interacting with community members on mailing lists, IRC, or bug
>>  trackers. The community represents the project as a whole, and abusive
>>  or bullying behaviour is not tolerated by the project.
>> +
>> +Learning material
>> +=
>> +
>> +Since the Linux DRM layer supports complex graphics devices, it can be quite
>> +overwhelming for newcomers to get familiar with all the needed concepts and
>> +learn the subsystem's internals.
> 
> Hi,
> 
> this seems to say that DRM is going to be complicated no matter what
> hardware one wants to drive, but is that true?
> 
> Is there no way to say that if your display hardware is simple (no
> GPU), then the driver can be simple to write too?
>

I do wonder how much one could abstract of the uAPI when writing a simpler 
driver.

In other words, writing the driver should be simple but I believe that grasping
all the needed details about DRM may not be.
 
>> +
>> +To shallow the learning curve, this section contains a list of presentations
>> +and documents that can be used to learn about DRM/KMS and graphics in 
>> general.
>> +
>> +The list is sorted in reverse chronological order, to keep the most 
>> up-to-date
>> +material at the top. But all of them contain useful information, and it can 
>> be
>> +valuable to go through older material to understand the rationale and 
>> context
>> +in which the recent changes to the DRM subsystem were made.
>> +
>> +Talks
>> +-
>> +
>> +* `An Overview of the Linux and Userspace Graphics Stack 
>> `_ - Paul Kocialkowski (2020)
>> +* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting 
>> `_ - Simon Ser (2020)
>> +* `An introduction to the Linux DRM subsystem 
>> `_ - Maxime Ripard (2017)
>> +* `Embrace the Atomic (Display) Age 
>> `_ - Daniel Vetter (2016)
>> +* `Anatomy of an Atomic KMS Driver 
>> `_ - Laurent Pinchart (2015)
>> +* `Atomic Modesetting for Drivers 
>> `_ - Daniel Vetter (2015)
>> +* `Anatomy of an Embedded KMS Driver 
>> `_ - Laurent Pinchart (2013
>> +
>> +Slides and articles
>> +---
>> +
>> +* `Understanding the Linux Graphics Stack 
>> `_ - Bootlin 
>> (2022)
>> +* `DRM KMS overview `_ 
>> - STMicroelectronics (2021)
>> +* `Linux graphic stack 
>> `_ - 
>> Nathan Gauër (2017)
>> +* `The DRM/KMS subsystem from a newbie’s point of view 
>> `_
>>  - Boris Brezillon (2014)
>> +* `A brief introduction to the Linux graphics stack 
>> `_
>>  - Iago Toral (2014)
>> +* `The Linux Graphics Stack 
>> `_ - Jasper St. 
>> Pierre (2012)
> 
> That's an impressive list of links!
> 
> However, given the discussions that prompted this doc, I think the gist
> is missing. The reader is just flooded with stuff to read and learn
> which can be discouraging.
> 
> Your audience are developers who know nothing about DRM. They may have
> been writing fb drivers instead. The display hardware they want to
> drive has no GPU. Where should they get started? Which presentations to
> read/watch first? Which driver to look at for a simple example?
> 
> Maybe add one more section targeting that specific audience?
>

Yes, I did not ignore your suggestions made over IRC but it's just that I
didn't know to w

Re: [PATCH] drm/doc: Add section in the introduction page about learning material

Hello Thomas,

On 1/27/22 10:18, Thomas Zimmermann wrote:
> Hi Javier,
> 
> thanks for this patch.
> 
> Acked-by: Thomas Zimmermann 
>

Thanks!

> Find some ideas for consideration below.
> 

[snip]

>> +
>> +Learning material
>> +=
> 
> Maybe 'External References'.
>

Agreed, I'll change it.

>> +
>> +Since the Linux DRM layer supports complex graphics devices, it can be quite
>> +overwhelming for newcomers to get familiar with all the needed concepts and
>> +learn the subsystem's internals.
> 
> It sounds a bit intimdating to me. Can we give it a positive spin?
>

Pekka also had reservations about this paragraph, so I think that will just
drop it. The goal of having this section was to ease the learning curve but
the way I worded it may reinforce the perception that DRM is hard to learn.

> IMHO we could add a separate section that talks about complexity and 
> provides guidelines about how to deal with it:  trivial HW? use simple 
> pipe;  dedicated VRAM? try TTM;  awkward color formats?  see 
> drm_format_helper.c
>

Indeed. And we can add such section as a follow-up. Maybe referring to some
of the drivers in drivers/gpu/drm/tiny.

Best regards, -- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 27/27] drm: rockchip: Add VOP2 driver

On Thu, Jan 27, 2022 at 10:17:13AM +0100, Piotr Oniszczuk wrote:
> Sascha,
> 
> FYI 
> small report regarding 4k modes support in v4:
> 
> -on rk3399 it gives me 4k screen where right vertical 1/3 part of screen is 
> garbage
> -on rk3566 my samsung 4k monitor has black screen and cycle of OSD msgs: 
> HDMI2 connected; HDMI2 disconnected; 

Same here on my rk3568, also with a samsung monitor. Was it 4k@60Hz or
4k@30Hz? If the former, could you give 4k@30Hz a try? That mode works
well here.

> 
> I would suggest split v4 into 2 separated series:

Yeah, splitting up the series makes sense. At the moment I have it all
in one series to ease others testing it.

Sascha

> 
> -VOP2 support
> -HDMI 4k modes support
> 
> BTW: getting well working 4k HDMI modes on rk3399 was real story for me.
> There is many different series of patches to address this - but all have some 
> subtle issues for me (i.e. 4k HDMI modes works but i.e. Qt is failing with 
> DRM atomic commits in EGLFS)
> I developed well working [1] giving me reliable 4k on rk3399 (including 
> working Qt DRM drawing in EGLFS mode) 
> Maybe it will be somehow helpful to get 4k modes solution for rk3566 _and_ 
> rk3399 (on single kernel binary)?
> 
> [1] 
> https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.16/files/0730-drm-rockchip-add-4k-videomodes-support.patch

At least there are patches in it that I have in my series as well and
keep popping up everywhere like "drm/rockchip: dw_hdmi: Use
auto-generated tables" and "drm/rockchip: dw_hdmi: Set cur_ctr to 0
always"

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 09/27] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

On Wed, Jan 26, 2022 at 07:42:48AM -0800, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer  wrote:
> >
> > From: Douglas Anderson 
> >
> > Jitter was improved by lowering the MPLL bandwidth to account for high
> > frequency noise in the rk3288 PLL.  In each case MPLL bandwidth was
> > lowered only enough to get us a comfortable margin.  We believe that
> > lowering the bandwidth like this is safe given sufficient testing.
> >
> > Changes since v3:
> > - new patch
> >
> > Signed-off-by: Douglas Anderson 
> > Signed-off-by: Yakir Yang 
> > (am from https://patchwork.kernel.org/patch/9223301/)
> 
> Probably remove the "am from" line? It's not standard in upstream and
> that link doesn't seem to go anywhere anymore...
> 
> 
> > Signed-off-by: Sascha Hauer 
> > ---
> >  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++--
> >  1 file changed, 2 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> > b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > index c44eb4d2e2d5..77f82a4fd027 100644
> > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> > @@ -176,20 +176,8 @@ static const struct dw_hdmi_mpll_config 
> > rockchip_mpll_cfg[] = {
> >  static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
> > /*  pixelclkbpp8bpp10   bpp12 */
> > {
> > -   4000,  { 0x0018, 0x0018, 0x0018 },
> > -   }, {
> > -   6500,  { 0x0028, 0x0028, 0x0028 },
> > -   }, {
> > -   6600,  { 0x0038, 0x0038, 0x0038 },
> > -   }, {
> > -   7425,  { 0x0028, 0x0038, 0x0038 },
> > -   }, {
> > -   8350,  { 0x0028, 0x0038, 0x0038 },
> > -   }, {
> > -   14625, { 0x0038, 0x0038, 0x0038 },
> > -   }, {
> > -   14850, { 0x, 0x0038, 0x0038 },
> > -   }, {
> > +   6, { 0x, 0x, 0x },
> > +   },  {
> 
> This is what we did for rk3288. I can't personally vouch for the
> effects on other SoCs.

Fair enough. Rockchip has this patch in their downstream Kernel, so I am
confident it works on SoCs newer as the rk3288 as well. I don't know how
much they care about the older SoCs, but it seems there is only the
rk3228 that is older than the rk3288 that is supported by this driver.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] drm/doc: Add section in the introduction page about learning material

2022-01-27 Thread Pekka Paalanen

On Thu, 27 Jan 2022 11:46:44 +0100
Javier Martinez Canillas  wrote:

> Hello Pekka,
> 
> Thanks a lot for your feedback.
> 
> On 1/27/22 10:05, Pekka Paalanen wrote:
> > On Thu, 27 Jan 2022 09:20:58 +0100
> > Javier Martinez Canillas  wrote:
> >   
> >> The Linux DRM subsystem supports complex graphics devices and it could be
> >> quite overwhelming for newcomers to learn about the subsystem's internals.
> >>
> >> There are lots of useful talks, slides and articles available that can be
> >> used to get familiar with the needed concepts and ease the learning curve.
> >>
> >> Add a section to the intro that contains these DRM introductory materials.
> >>
> >> Suggested-by: Daniel Vetter 
> >> Signed-off-by: Javier Martinez Canillas 
> >> ---
> >>
> >>  Documentation/gpu/introduction.rst | 36 ++
> >>  1 file changed, 36 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/introduction.rst 
> >> b/Documentation/gpu/introduction.rst
> >> index 25a56e9c0cfd..35986784f916 100644
> >> --- a/Documentation/gpu/introduction.rst
> >> +++ b/Documentation/gpu/introduction.rst
> >> @@ -112,3 +112,39 @@ Please conduct yourself in a respectful and civilised 
> >> manner when
> >>  interacting with community members on mailing lists, IRC, or bug
> >>  trackers. The community represents the project as a whole, and abusive
> >>  or bullying behaviour is not tolerated by the project.
> >> +
> >> +Learning material
> >> +=
> >> +
> >> +Since the Linux DRM layer supports complex graphics devices, it can be 
> >> quite
> >> +overwhelming for newcomers to get familiar with all the needed concepts 
> >> and
> >> +learn the subsystem's internals.  
> > 
> > Hi,
> > 
> > this seems to say that DRM is going to be complicated no matter what
> > hardware one wants to drive, but is that true?
> > 
> > Is there no way to say that if your display hardware is simple (no
> > GPU), then the driver can be simple to write too?
> >  
> 
> I do wonder how much one could abstract of the uAPI when writing a simpler 
> driver.
> 
> In other words, writing the driver should be simple but I believe that 
> grasping
> all the needed details about DRM may not be.
>  
> >> +
> >> +To shallow the learning curve, this section contains a list of 
> >> presentations
> >> +and documents that can be used to learn about DRM/KMS and graphics in 
> >> general.
> >> +
> >> +The list is sorted in reverse chronological order, to keep the most 
> >> up-to-date
> >> +material at the top. But all of them contain useful information, and it 
> >> can be
> >> +valuable to go through older material to understand the rationale and 
> >> context
> >> +in which the recent changes to the DRM subsystem were made.
> >> +
> >> +Talks
> >> +-
> >> +
> >> +* `An Overview of the Linux and Userspace Graphics Stack 
> >> `_ - Paul Kocialkowski (2020)
> >> +* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting 
> >> `_ - Simon Ser (2020)
> >> +* `An introduction to the Linux DRM subsystem 
> >> `_ - Maxime Ripard (2017)
> >> +* `Embrace the Atomic (Display) Age 
> >> `_ - Daniel Vetter (2016)
> >> +* `Anatomy of an Atomic KMS Driver 
> >> `_ - Laurent Pinchart (2015)
> >> +* `Atomic Modesetting for Drivers 
> >> `_ - Daniel Vetter (2015)
> >> +* `Anatomy of an Embedded KMS Driver 
> >> `_ - Laurent Pinchart (2013
> >> +
> >> +Slides and articles
> >> +---
> >> +
> >> +* `Understanding the Linux Graphics Stack 
> >> `_ - 
> >> Bootlin (2022)
> >> +* `DRM KMS overview 
> >> `_ - 
> >> STMicroelectronics (2021)
> >> +* `Linux graphic stack 
> >> `_ - 
> >> Nathan Gauër (2017)
> >> +* `The DRM/KMS subsystem from a newbie’s point of view 
> >> `_
> >>  - Boris Brezillon (2014)
> >> +* `A brief introduction to the Linux graphics stack 
> >> `_
> >>  - Iago Toral (2014)
> >> +* `The Linux Graphics Stack 
> >> `_ - Jasper 
> >> St. Pierre (2012)  
> > 
> > That's an impressive list of links!
> > 
> > However, given the discussions that prompted this doc, I think the gist
> > is missing. The reader is just flooded with stuff to read and learn
> > which can be discouraging.
> > 
> > Your audience are developers who know nothing about DRM. They may have
> > been writing fb drivers instea

Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

On Thu, Jan 27, 2022 at 11:32:58AM +0100, Dmitry Vyukov wrote:
> On Thu, 27 Jan 2022 at 07:30, Dan Carpenter  wrote:
> >
> > On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote:
> > > dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter  
> > > wrote:
> > > >
> > > > The other advantage of staging is the I don't think syzbot enables it.
> > > > I guess it's easier to persuade Dmitry to ignore STAGING than it was to
> > > > get him to disable FBDEV.  :P
> > > >
> > > > The memory corruption in fbdev was a real headache for everyone because
> > > > the stack traces ended up all over the kernel.
> > >
> > > Uh Dmitry disabled all of FBDEV?
> >
> > No that's the opposite of what I meant.  STAGING is disabled in syzbot
> > and FBDEV is enabled.
> 
> Is there still any problem with syzbot config?
> syzbot configs are stored here:
> https://github.com/google/syzkaller/tree/master/dashboard/config/linux

CONFIG_FB and CONFIG_FRAMEBUFFER_CONSOLE are set, which are the things I
care about. The one exception is upstream-kcsan.config, which doesn't have
fbcon enabled.

Also looking through your fbdev drivers, really the only ones you want to
ever enable are:
CONFIG_FB_VGA16=y
CONFIG_FB_VESA=y
CONFIG_FB_VIRTUAL=y

The following isn't enabled, but I guess if you don't have EFI doesn't
make sense, otherwise you really want it:
CONFIG_FB_EFI=y

The below are enabled in some configs and should be ditched
CONFIG_FB_SIMPLE=y (use CONFIG_DRM_SIMPLEDRM instead, at least on kernels that 
have it)
CONFIG_FB_I740=y (you don't have this hw or I'm blown away, this last shipped 
20 years ago)
CONFIG_FB_UDL=y (use CONFIG_DRM_UDL instead)
CONFIG_FB_UVESA=y (does modesets by calling into a userspace helper to run x86 
vbios code, just don't)
CONFIG_FB_SMSCUFX=y (if you really have these then someone should port this to 
drm asap)
CONFIG_FB_CIRRUS=y (use CONFIG_DRM_CIRRUS_QEMU instead since I'm pretty sure 
you don't have a real cirrus pci card)

Also note that the simpledrm driver will eat all the firmware fbdev
drivers and unload them. So you need to run two configs to really cover
both sets of drivers in all cases.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/vc4: hdmi: Simplify the connector state retrieval

When we have the entire DRM state, retrieving the connector state only
requires the drm_connector pointer. Fortunately for us, we have
allocated it as a part of the vc4_hdmi structure, so we can retrieve get
a pointer by simply accessing our field in that structure.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 21 +++--
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 2c83252819e9..efffe21d2e73 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1002,30 +1002,15 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi 
*vc4_hdmi)
  "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
 }
 
-static struct drm_connector_state *
-vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
-struct drm_atomic_state *state)
-{
-   struct drm_connector_state *conn_state;
-   struct drm_connector *connector;
-   unsigned int i;
-
-   for_each_new_connector_in_state(state, connector, conn_state, i) {
-   if (conn_state->best_encoder == encoder)
-   return conn_state;
-   }
-
-   return NULL;
-}
-
 static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
 {
+   struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+   struct drm_connector *connector = &vc4_hdmi->connector;
struct drm_connector_state *conn_state =
-   vc4_hdmi_encoder_get_connector_state(encoder, state);
+   drm_atomic_get_new_connector_state(state, connector);
struct vc4_hdmi_connector_state *vc4_conn_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
-   struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
unsigned long pixel_rate = vc4_conn_state->pixel_rate;
unsigned long bvb_rate, hsm_rate;
-- 
2.34.1

[PATCH] drm/vc4: hdmi: Unregister codec device on unbind

On bind we will register the HDMI codec device but we don't unregister
it on unbind, leading to a device leakage. Unregister our device at
unbind.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 8 
 drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 502d5bea5f61..395a9e9c1e5a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1746,6 +1746,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
dev_err(dev, "Couldn't register the HDMI codec: %ld\n", 
PTR_ERR(codec_pdev));
return PTR_ERR(codec_pdev);
}
+   vc4_hdmi->audio.codec_pdev = codec_pdev;
 
dai_link->cpus  = &vc4_hdmi->audio.cpu;
dai_link->codecs= &vc4_hdmi->audio.codec;
@@ -1785,6 +1786,12 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
 
 }
 
+static void vc4_hdmi_audio_exit(struct vc4_hdmi *vc4_hdmi)
+{
+   platform_device_unregister(vc4_hdmi->audio.codec_pdev);
+   vc4_hdmi->audio.codec_pdev = NULL;
+}
+
 static irqreturn_t vc4_hdmi_hpd_irq_thread(int irq, void *priv)
 {
struct vc4_hdmi *vc4_hdmi = priv;
@@ -2689,6 +2696,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct 
device *master,
kfree(vc4_hdmi->hdmi_regset.regs);
kfree(vc4_hdmi->hd_regset.regs);
 
+   vc4_hdmi_audio_exit(vc4_hdmi);
vc4_hdmi_cec_exit(vc4_hdmi);
vc4_hdmi_hotplug_exit(vc4_hdmi);
vc4_hdmi_connector_destroy(&vc4_hdmi->connector);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index db53500a8435..275c4674d50f 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -113,6 +113,7 @@ struct vc4_hdmi_audio {
struct snd_soc_dai_link_component platform;
struct snd_dmaengine_dai_dma_data dma_data;
struct hdmi_audio_infoframe infoframe;
+   struct platform_device *codec_pdev;
bool streaming;
 };
 
-- 
2.34.1

Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

On Thu, Jan 27, 2022 at 11:21:20AM +0100, Christian König wrote:
> Am 27.01.22 um 11:00 schrieb Daniel Vetter:
> > On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
> > > On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
> > > > On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> > > > > Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > > > > > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > > > > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > > > > > When dma_buf_map struct is passed around, it's useful to be 
> > > > > > > > able to
> > > > > > > > initialize a second map that takes care of reading/writing to 
> > > > > > > > an offset
> > > > > > > > of the original map.
> > > > > > > > 
> > > > > > > > Add a helper that copies the struct and add the offset to the 
> > > > > > > > proper
> > > > > > > > address.
> > > > > > > Well what you propose here can lead to all kind of problems and is
> > > > > > > rather bad design as far as I can see.
> > > > > > > 
> > > > > > > The struct dma_buf_map is only to be filled in by the exporter and
> > > > > > > should not be modified in this way by the importer.
> > > > > > humn... not sure if I was  clear. There is no importer and exporter 
> > > > > > here.
> > > > > Yeah, and exactly that's what I'm pointing out as problem here.
> > > > > 
> > > > > You are using the inter driver framework for something internal to the
> > > > > driver. That is an absolutely clear NAK!
> > > > > 
> > > > > We could discuss that, but you guys are just sending around patches 
> > > > > to do
> > > > > this without any consensus that this is a good idea.
> > > > Uh I suggested this, also we're already using dma_buf_map all over the
> > > > place as a convenient abstraction. So imo that's all fine, it should 
> > > > allow
> > > > drivers to simplify some code where on igpu it's in normal kernel memory
> > > > and on dgpu it's behind some pci bar.
> > > > 
> > > > Maybe we should have a better name for that struct (and maybe also a
> > > > better place), but way back when we discussed that bikeshed I didn't 
> > > > come
> > > > up with anything better really.
> > > I suggest iosys_map since it abstracts access to IO and system memory.
> > > 
> > > > > > There is a role delegation on filling out and reading a buffer when
> > > > > > that buffer represents a struct layout.
> > > > > > 
> > > > > > struct bla {
> > > > > >  int a;
> > > > > >  int b;
> > > > > >  int c;
> > > > > >  struct foo foo;
> > > > > >  struct bar bar;
> > > > > >  int d;
> > > > > > }
> > > > > > 
> > > > > > 
> > > > > > This implementation allows you to have:
> > > > > > 
> > > > > >  fill_foo(struct dma_buf_map *bla_map) { ... }
> > > > > >  fill_bar(struct dma_buf_map *bla_map) { ... }
> > > > > > 
> > > > > > and the first thing these do is to make sure the map it's pointing 
> > > > > > to
> > > > > > is relative to the struct it's supposed to write/read. Otherwise 
> > > > > > you're
> > > > > > suggesting everything to be relative to struct bla, or to do the 
> > > > > > same
> > > > > > I'm doing it, but IMO more prone to error:
> > > > > > 
> > > > > >  struct dma_buf_map map = *bla_map;
> > > > > >  dma_buf_map_incr(map, offsetof(...));
> > > > Wrt the issue at hand I think the above is perfectly fine code. The idea
> > > > with dma_buf_map is really that it's just a special pointer, so writing
> > > > the code exactly as pointer code feels best. Unfortunately you cannot 
> > > > make
> > > > them typesafe (because of C), so the code sometimes looks a bit ugly.
> > > > Otherwise we could do stuff like container_of and all that with
> > > > typechecking in the macros.
> > > I had exactly this code above, but after writting quite a few patches
> > > using it, particularly with functions that have to write to 2 maps (see
> > > patch 6 for example), it felt much better to have something to
> > > initialize correctly from the start
> > > 
> > >   struct dma_buf_map other_map = *bla_map;
> > >   /* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
> > > 
> > > is error prone and hard to debug since you will be reading/writting
> > > from/to another location rather than exploding
> > > 
> > > While with the construct below
> > > 
> > >   other_map;
> > >   ...
> > >   other_map = INITIALIZER()
> > > 
> > > I can rely on the compiler complaining about uninitialized var. And
> > > in most of the cases I can just have this single line in the beggining of 
> > > the
> > > function when the offset is constant:
> > > 
> > >   struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
> > Hm yeah that's a good point that this allows us to rely on the compiler to
> > check for uninitialized variables.
> > 
> > Maybe include the above (with editing, but keeping the examples) in the
> > kerneldoc to explain why/how to use this? With that the concept at least
> > has my
> > 
> > A

Re: [PATCH v1] drm/panel: simple: Tune timing for ET057090DHU

2022-01-27 Thread kernel test robot

Hi Francesco,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v5.17-rc1 next-20220127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Francesco-Dolcini/drm-panel-simple-Tune-timing-for-ET057090DHU/20220127-153123
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: ia64-allmodconfig 
(https://download.01.org/0day-ci/archive/20220127/202201271923.ebyuua3x-...@intel.com/config)
compiler: ia64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/db3299763c5ae747c148fc1d85af84f9360189fc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Francesco-Dolcini/drm-panel-simple-Tune-timing-for-ET057090DHU/20220127-153123
git checkout db3299763c5ae747c148fc1d85af84f9360189fc
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/gpu/drm/panel/

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

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/panel/panel-simple.c:1607:10: error: 'const struct 
>> drm_display_mode' has no member named 'vrefresh'
1607 | .vrefresh = 60,
 |  ^~~~


vim +1607 drivers/gpu/drm/panel/panel-simple.c

  1596  
  1597  static const struct drm_display_mode edt_et057090dhu_mode = {
  1598  .clock = 25175,
  1599  .hdisplay = 640,
  1600  .hsync_start = 640 + 16,
  1601  .hsync_end = 640 + 16 + 48,
  1602  .htotal = 640 + 16 + 48 + 96,
  1603  .vdisplay = 480,
  1604  .vsync_start = 480 + 10,
  1605  .vsync_end = 480 + 10 + 2,
  1606  .vtotal = 480 + 10 + 2 + 33,
> 1607  .vrefresh = 60,
  1608  .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
  1609  };
  1610  

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

Re: [PATCH 07/27] drm/rockchip: dw_hdmi: Use auto-generated tables

On Wed, Jan 26, 2022 at 07:54:53AM -0800, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer  wrote:
> >
> > From: Douglas Anderson 
> >
> > The previous tables for mpll_cfg and curr_ctrl were created using the
> > 20-pages of example settings provided by the PHY vendor.  Those
> > example settings weren't particularly dense, so there were places
> > where we were guessing what the settings would be for 10-bit and
> > 12-bit (not that we use those anyway).  It was also always a lot of
> > extra work every time we wanted to add a new clock rate since we had
> > to cross-reference several tables.
> >
> > In  I've gone through the work to figure
> 
> The `crosreview.com` syntax doesn't seem to work anymore. Could maybe
> update to https://crrev.com/c/285855 ?

did that, thanks.

> 
> > out how to generate this table automatically.  Let's now use the
> > automatically generated table and then we'll never need to look at it
> > again.
> >
> > We only support 8-bit mode right now and only support a small number
> > of clock rates and and I've verified that the only 8-bit rate that was
> > affected was 148.5.  That mode appears to have been wrong in the old
> > table.
> >
> > Changes since v3:
> > - new patch
> >
> > Signed-off-by: Douglas Anderson 
> > Signed-off-by: Yakir Yang 
> 
> Should probably change the "at" to "@" ?

yes.

> 
> > Reviewed-by: Stéphane Marchesin 
> 
> In general shouldn't carry downstream reviews when posting upstream
> unless you're certain that the person intended it...
> 
> 
> It's been a long time, but in general I think I was fairly confident
> in the numbers that my script pumped out, at least given the caveat of
> no pixel repetition and 8-bit only. That being said, I didn't have any
> inside knowledge of the hardware and just figured out formulas that
> seemed to match the table that I had. YMMV.

Rockchip adopted this patch for their downstream Kernel, so they haven't
been able to come up with better values. Given that you created this
patch for a fairly old SoC and the values are still usable on rk3568 I
think that's the way to go.

> 
> I'll also say that when I did a rebase of veyron (rk3288-based
> Chromebook) to 4.19 about 2.5 years ago, I ended up squashing several
> of these patches into 1. That can be found at
> . That also has details about why some of
> these patches never made it upstream. The main reason, at least in the
> case of rk3288, was the PLL sharing problem that nobody ever solved.
> rk3288 didn't have quite enough PLLs and thus, if you were using both
> VOPs, one of the VOPs was going to be severely limited in what pixel
> clocks it could make. There was no framework deciding which VOP should
> be limited and how the system should react to this...
> 
> 
> In any case, I'm pretty far disconnected from all this stuff now, but
> I wish you the best of luck in trying to get it all solved!

Nah, sorry, I won't get that all solved ;)

I am not that interested in rk3288, my main concern is the rk3568. That
one has two spare PLLs for three heads instead of one PLL for two heads,
so the problem is less pressing.

I'll stick to this version of the patch instead of the combined one
because this patch seems to be correct regardless of the PLL problem.

Thanks for the link though, it gives me some insights why things are the
way they are currently.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] drm/vc4: hdmi: Simplify the connector state retrieval




Am 27.01.22 um 12:14 schrieb Maxime Ripard:

When we have the entire DRM state, retrieving the connector state only
requires the drm_connector pointer. Fortunately for us, we have
allocated it as a part of the vc4_hdmi structure, so we can retrieve get
a pointer by simply accessing our field in that structure.

Signed-off-by: Maxime Ripard 


Acked-by: Thomas Zimmermann 


---
  drivers/gpu/drm/vc4/vc4_hdmi.c | 21 +++--
  1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 2c83252819e9..efffe21d2e73 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1002,30 +1002,15 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi 
*vc4_hdmi)
  "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
  }
  
-static struct drm_connector_state *

-vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
-struct drm_atomic_state *state)
-{
-   struct drm_connector_state *conn_state;
-   struct drm_connector *connector;
-   unsigned int i;
-
-   for_each_new_connector_in_state(state, connector, conn_state, i) {
-   if (conn_state->best_encoder == encoder)
-   return conn_state;
-   }
-
-   return NULL;
-}
-
  static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
  {
+   struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+   struct drm_connector *connector = &vc4_hdmi->connector;
struct drm_connector_state *conn_state =
-   vc4_hdmi_encoder_get_connector_state(encoder, state);
+   drm_atomic_get_new_connector_state(state, connector);
struct vc4_hdmi_connector_state *vc4_conn_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
-   struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
struct drm_display_mode *mode = &vc4_hdmi->saved_adjusted_mode;
unsigned long pixel_rate = vc4_conn_state->pixel_rate;
unsigned long bvb_rate, hsm_rate;


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm/doc: Add section in the introduction page about learning material

On Thu, Jan 27, 2022 at 11:50:30AM +0100, Javier Martinez Canillas wrote:
> Hello Thomas,
> 
> On 1/27/22 10:18, Thomas Zimmermann wrote:
> > Hi Javier,
> > 
> > thanks for this patch.
> > 
> > Acked-by: Thomas Zimmermann 
> >
> 
> Thanks!
>  
> > Find some ideas for consideration below.
> > 
> 
> [snip]
> 
> >> +
> >> +Learning material
> >> +=
> > 
> > Maybe 'External References'.
> >
> 
> Agreed, I'll change it.
> 
> >> +
> >> +Since the Linux DRM layer supports complex graphics devices, it can be 
> >> quite
> >> +overwhelming for newcomers to get familiar with all the needed concepts 
> >> and
> >> +learn the subsystem's internals.
> > 
> > It sounds a bit intimdating to me. Can we give it a positive spin?
> >
> 
> Pekka also had reservations about this paragraph, so I think that will just
> drop it. The goal of having this section was to ease the learning curve but
> the way I worded it may reinforce the perception that DRM is hard to learn.
> 
> > IMHO we could add a separate section that talks about complexity and 
> > provides guidelines about how to deal with it:  trivial HW? use simple 
> > pipe;  dedicated VRAM? try TTM;  awkward color formats?  see 
> > drm_format_helper.c
> >
> 
> Indeed. And we can add such section as a follow-up. Maybe referring to some
> of the drivers in drivers/gpu/drm/tiny.

Do we have a talk anywhere for tiny?

Otherwise I think it'd be good to just add a paragraph about "hey tiny
exists" and maybe link to fbdev helpers and simple pipe helpers to get
people started with the right entry points for simple drivers.

And make it clear that the above pile of links is more for general
overview and if you don't yet know what exactly it is you need.

Also I guess for this year's xdc I really need to volunteer someone to do
a drm/tiny intro :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/fb-helper: Mark screen buffers in system memory with FB_VIRTFB

On Thu, Jan 27, 2022 at 11:26:21AM +0100, Thomas Zimmermann wrote:
> Mark screen buffers in system memory with FB_VIRTFB. Otherwise, the
> buffers are mmap'ed as I/O memory (i.e., VM_IO). For shadow buffers,
> also set the FB_READS_FAST hint.

Maybe clarify that this only holds for the defio case, and since we have
our own shadow copy for that anyway it shouldn't matter. I'm also not sure
how much the memcpy gains us compared to just redrawing ...

What's the motivation here, or just something you spotted?
-Daniel

> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ed43b987d306..f15127a32f7a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(struct 
> drm_fb_helper *fb_helper,
>   fbi->fbops = &drm_fbdev_fb_ops;
>   fbi->screen_size = sizes->surface_height * fb->pitches[0];
>   fbi->fix.smem_len = fbi->screen_size;
> + fbi->flags = FBINFO_DEFAULT;
>  
>   drm_fb_helper_fill_info(fbi, fb_helper, sizes);
>  
> @@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(struct 
> drm_fb_helper *fb_helper,
>   fbi->screen_buffer = vzalloc(fbi->screen_size);
>   if (!fbi->screen_buffer)
>   return -ENOMEM;
> + fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
>  
>   fbi->fbdefio = &drm_fbdev_defio;
> -
>   fb_deferred_io_init(fbi);
>   } else {
>   /* buffer is mapped for HW framebuffer */
>   ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
>   if (ret)
>   return ret;
> - if (map.is_iomem)
> + if (map.is_iomem) {
>   fbi->screen_base = map.vaddr_iomem;
> - else
> + } else {
>   fbi->screen_buffer = map.vaddr;
> + fbi->flags |= FBINFO_VIRTFB;
> + }
>  
>   /*
>* Shamelessly leak the physical address to user-space. As
> -- 
> 2.34.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Linaro-mm-sig] Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map


Am 27.01.22 um 12:16 schrieb Daniel Vetter:

On Thu, Jan 27, 2022 at 11:21:20AM +0100, Christian König wrote:

Am 27.01.22 um 11:00 schrieb Daniel Vetter:

On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:

On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:

On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:

Am 27.01.22 um 08:57 schrieb Lucas De Marchi:

On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:

Am 26.01.22 um 21:36 schrieb Lucas De Marchi:

When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.

Add a helper that copies the struct and add the offset to the proper
address.

Well what you propose here can lead to all kind of problems and is
rather bad design as far as I can see.

The struct dma_buf_map is only to be filled in by the exporter and
should not be modified in this way by the importer.

humn... not sure if I was  clear. There is no importer and exporter here.

Yeah, and exactly that's what I'm pointing out as problem here.

You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!

We could discuss that, but you guys are just sending around patches to do
this without any consensus that this is a good idea.

Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.

Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.

I suggest iosys_map since it abstracts access to IO and system memory.


There is a role delegation on filling out and reading a buffer when
that buffer represents a struct layout.

struct bla {
  int a;
  int b;
  int c;
  struct foo foo;
  struct bar bar;
  int d;
}


This implementation allows you to have:

  fill_foo(struct dma_buf_map *bla_map) { ... }
  fill_bar(struct dma_buf_map *bla_map) { ... }

and the first thing these do is to make sure the map it's pointing to
is relative to the struct it's supposed to write/read. Otherwise you're
suggesting everything to be relative to struct bla, or to do the same
I'm doing it, but IMO more prone to error:

  struct dma_buf_map map = *bla_map;
  dma_buf_map_incr(map, offsetof(...));

Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.

I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start

struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */

is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding

While with the construct below

other_map;
...
other_map = INITIALIZER()

I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the beggining of the
function when the offset is constant:

struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));

Hm yeah that's a good point that this allows us to rely on the compiler to
check for uninitialized variables.

Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my

Acked-by: Daniel Vetter 

I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.

There is one major issue remaining with this and that is dma_buf_vunmap():

void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);

Here we expect the original pointer as returned by dma_buf_map(), otherwise
we vunmap() the wrong area!

For all TTM based driver this doesn't matter since we keep the vmap base
separately in the BO anyway (IIRC), but we had at least one case where this
made boom last year.

Yeah but isn't that the same if it's just a void *?

If you pass the wrong pointer to an unmap function and not exactly what
you go from the map function, then things go boom. This is like
complaining that the following code wont work

u32 *stuff

stuff = kmap_local(some_page);
*stuff++ = 0;
*stuff = 1;
kunmap_locak(stuff);

It's just ... don't do

[PATCH v2] drm/panel: simple: Tune timing for ET057090DHU

2022-01-27 Thread Francesco Dolcini

From: Oleksandr Suvorov 

VESA Display Monitor Timing v1.13 has recommendations for the historical
VGA mode 640x480 60Hz. These parameters are compatible with EDT
ET057090DHU recommended timings.

Use VESA DMT timing parameters for EDT ET057090DHU panel.

Signed-off-by: Oleksandr Suvorov 
Cc: Oleksandr Suvorov 
Signed-off-by: Francesco Dolcini 
---
v2: removed stale vrefresh field
---
 drivers/gpu/drm/panel/panel-simple.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 0c8786ebffd1..52e936dd2d6f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1598,12 +1598,12 @@ static const struct drm_display_mode 
edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
.hsync_start = 640 + 16,
-   .hsync_end = 640 + 16 + 30,
-   .htotal = 640 + 16 + 30 + 114,
+   .hsync_end = 640 + 16 + 48,
+   .htotal = 640 + 16 + 48 + 96,
.vdisplay = 480,
.vsync_start = 480 + 10,
-   .vsync_end = 480 + 10 + 3,
-   .vtotal = 480 + 10 + 3 + 32,
+   .vsync_end = 480 + 10 + 2,
+   .vtotal = 480 + 10 + 2 + 33,
.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
 };
 
-- 
2.25.1

[PATCH] drm/i915: Fix a race between vma / object destruction and unbinding

The vma destruction code was using an unlocked advisory check for
drm_mm_node_allocated() to avoid racing with eviction code unbinding
the vma.

This is very fragile and prohibits the dereference of non-refcounted
pointers of dying vmas after a call to __i915_vma_unbind(). It also
prohibits the dereference of vma->obj of refcounted pointers of
dying vmas after a call to __i915_vma_unbind(), since even if a
refcount is held on the vma, that won't guarantee that its backing
object doesn't get destroyed.

So introduce an unbind under the vm mutex at object destroy time,
removing all weak references of the vma and its object from the
object vma list and from the vm bound list.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 1a9e1f940a7d..e03e362d320b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -280,6 +280,12 @@ void __i915_gem_object_pages_fini(struct 
drm_i915_gem_object *obj)
GEM_BUG_ON(vma->obj != obj);
spin_unlock(&obj->vma.lock);
 
+   /* Verify that the vma is unbound under the vm mutex. */
+   mutex_lock(&vma->vm->mutex);
+   atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
+   __i915_vma_unbind(vma);
+   mutex_unlock(&vma->vm->mutex);
+
__i915_vma_put(vma);
 
spin_lock(&obj->vma.lock);
-- 
2.34.1

Re: [Linaro-mm-sig] Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map

On Thu, Jan 27, 2022 at 12:44:21PM +0100, Christian König wrote:
> Am 27.01.22 um 12:16 schrieb Daniel Vetter:
> > On Thu, Jan 27, 2022 at 11:21:20AM +0100, Christian König wrote:
> > > Am 27.01.22 um 11:00 schrieb Daniel Vetter:
> > > > On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
> > > > > On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
> > > > > > On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> > > > > > > Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > > > > > > > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > > > > > > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > > > > > > > When dma_buf_map struct is passed around, it's useful to be 
> > > > > > > > > > able to
> > > > > > > > > > initialize a second map that takes care of reading/writing 
> > > > > > > > > > to an offset
> > > > > > > > > > of the original map.
> > > > > > > > > > 
> > > > > > > > > > Add a helper that copies the struct and add the offset to 
> > > > > > > > > > the proper
> > > > > > > > > > address.
> > > > > > > > > Well what you propose here can lead to all kind of problems 
> > > > > > > > > and is
> > > > > > > > > rather bad design as far as I can see.
> > > > > > > > > 
> > > > > > > > > The struct dma_buf_map is only to be filled in by the 
> > > > > > > > > exporter and
> > > > > > > > > should not be modified in this way by the importer.
> > > > > > > > humn... not sure if I was  clear. There is no importer and 
> > > > > > > > exporter here.
> > > > > > > Yeah, and exactly that's what I'm pointing out as problem here.
> > > > > > > 
> > > > > > > You are using the inter driver framework for something internal 
> > > > > > > to the
> > > > > > > driver. That is an absolutely clear NAK!
> > > > > > > 
> > > > > > > We could discuss that, but you guys are just sending around 
> > > > > > > patches to do
> > > > > > > this without any consensus that this is a good idea.
> > > > > > Uh I suggested this, also we're already using dma_buf_map all over 
> > > > > > the
> > > > > > place as a convenient abstraction. So imo that's all fine, it 
> > > > > > should allow
> > > > > > drivers to simplify some code where on igpu it's in normal kernel 
> > > > > > memory
> > > > > > and on dgpu it's behind some pci bar.
> > > > > > 
> > > > > > Maybe we should have a better name for that struct (and maybe also a
> > > > > > better place), but way back when we discussed that bikeshed I 
> > > > > > didn't come
> > > > > > up with anything better really.
> > > > > I suggest iosys_map since it abstracts access to IO and system memory.
> > > > > 
> > > > > > > > There is a role delegation on filling out and reading a buffer 
> > > > > > > > when
> > > > > > > > that buffer represents a struct layout.
> > > > > > > > 
> > > > > > > > struct bla {
> > > > > > > >   int a;
> > > > > > > >   int b;
> > > > > > > >   int c;
> > > > > > > >   struct foo foo;
> > > > > > > >   struct bar bar;
> > > > > > > >   int d;
> > > > > > > > }
> > > > > > > > 
> > > > > > > > 
> > > > > > > > This implementation allows you to have:
> > > > > > > > 
> > > > > > > >   fill_foo(struct dma_buf_map *bla_map) { ... }
> > > > > > > >   fill_bar(struct dma_buf_map *bla_map) { ... }
> > > > > > > > 
> > > > > > > > and the first thing these do is to make sure the map it's 
> > > > > > > > pointing to
> > > > > > > > is relative to the struct it's supposed to write/read. 
> > > > > > > > Otherwise you're
> > > > > > > > suggesting everything to be relative to struct bla, or to do 
> > > > > > > > the same
> > > > > > > > I'm doing it, but IMO more prone to error:
> > > > > > > > 
> > > > > > > >   struct dma_buf_map map = *bla_map;
> > > > > > > >   dma_buf_map_incr(map, offsetof(...));
> > > > > > Wrt the issue at hand I think the above is perfectly fine code. The 
> > > > > > idea
> > > > > > with dma_buf_map is really that it's just a special pointer, so 
> > > > > > writing
> > > > > > the code exactly as pointer code feels best. Unfortunately you 
> > > > > > cannot make
> > > > > > them typesafe (because of C), so the code sometimes looks a bit 
> > > > > > ugly.
> > > > > > Otherwise we could do stuff like container_of and all that with
> > > > > > typechecking in the macros.
> > > > > I had exactly this code above, but after writting quite a few patches
> > > > > using it, particularly with functions that have to write to 2 maps 
> > > > > (see
> > > > > patch 6 for example), it felt much better to have something to
> > > > > initialize correctly from the start
> > > > > 
> > > > >   struct dma_buf_map other_map = *bla_map;
> > > > >   /* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); 
> > > > > */
> > > > > 
> > > > > is error prone and hard to debug since you will be reading/writting
> > > > > from/to another location rather than exploding
> > > > > 
> > > > > While with the construct below
> > > > > 
> > >

Re: [PATCH] drm/i915: Fix a race between vma / object destruction and unbinding

Op 27-01-2022 om 12:56 schreef Thomas Hellström:
> The vma destruction code was using an unlocked advisory check for
> drm_mm_node_allocated() to avoid racing with eviction code unbinding
> the vma.
>
> This is very fragile and prohibits the dereference of non-refcounted
> pointers of dying vmas after a call to __i915_vma_unbind(). It also
> prohibits the dereference of vma->obj of refcounted pointers of
> dying vmas after a call to __i915_vma_unbind(), since even if a
> refcount is held on the vma, that won't guarantee that its backing
> object doesn't get destroyed.
>
> So introduce an unbind under the vm mutex at object destroy time,
> removing all weak references of the vma and its object from the
> object vma list and from the vm bound list.
>
> Signed-off-by: Thomas Hellström 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 1a9e1f940a7d..e03e362d320b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -280,6 +280,12 @@ void __i915_gem_object_pages_fini(struct 
> drm_i915_gem_object *obj)
>   GEM_BUG_ON(vma->obj != obj);
>   spin_unlock(&obj->vma.lock);
>  
> + /* Verify that the vma is unbound under the vm mutex. */
> + mutex_lock(&vma->vm->mutex);
> + atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
> + __i915_vma_unbind(vma);
> + mutex_unlock(&vma->vm->mutex);
> +
>   __i915_vma_put(vma);
>  
>   spin_lock(&obj->vma.lock);

Reviewed-by: Maarten Lankhorst

[PULL] drm-misc-next

Hi Dave & Daniel,

First pull for v5.18

drm-misc-next-2022-01-27:
drm-misc-next for v5.18:

UAPI Changes:
- Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL.

Cross-subsystem Changes:
- Assorted dt bindings updates.
- Fix vga16fb vga checking on x86.
- Fix extra semicolon in rwsem.h's _down_write_nest_lock.
- Assorted small fixes to agp and fbdev drivers.
- Fix oops in creating a udmabuf with 0 pages.
- Hot-unplug firmware fb devices on forced removal
- Reqquest memory region in simplefb and simpledrm, and don't make the 
ioresource as busy.

Core Changes:
- Mock a drm_plane in drm-plane-helper selftest.
- Assorted bug fixes to device logging, dbi.
- Use DP helper for sink count in mst.
- Assorted documentation fixes.
- Assorted small fixes.
- Move DP headers to drm/dp, and add a drm dp helper module.
- Move the buddy allocator from i915 to common drm.
- Add simple pci and platform module init macros to remove a lot of boilerplate 
from some drivers.
- Support microsoft extension for HMDs and specialized monitors.
- Improve edid parser's deep color handling.
- Add type 7 timing support to edid parser.
- Add a weak backpointer to the ttm_bo from ttm_resource
- Add 3 eDP panels.

Driver Changes:
- Add support for HDMI and JZ4780 to ingenic.
- Add support for higher DP/eDP bitrates to nouveau.
- Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, 
v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge 
drivers.
- Convert and revert exynos dsi support to bridge driver.
- Add vcc supply regulator support for sn65dsi83.
- More conversion of bridge/chipone-icn6211 to atomic.
- Remove conflicting fb's from stm, and add support for new hw version.
- Add device link in parade-ps8640 to fix suspend/resume.
- Update Boe-tv110c9m init sequence.
- Add wide screen support to AST2600.
- Fix omapdrm implicit dma_buf fencing.
- Add support for multiple overlay planes to vkms.
- Convert bridge/anx7625 to atomic, add HDCP support,
  add eld support for audio, and fix HPD.
- Add driver for ChromeOS privacy screen.
- Handover display from firmware to vc4 more gracefully, and support nomodeset.
- Add flexible and ycbcr pixel formats to stm/ltdc.
- Convert exynos mipi dsi to atomic.
- Add initial dual core group GPUs support to panfrost.
- No longer add exclusive fence in amdgpu as shared fence.
- Add CSC and full range supoprt to vc4.
- Shutdown the display on system shutdown and unbind.
- Add Multi-Inno Technology MI0700S4T-6 simple panel.
The following changes since commit 9758ff2fa240173e9a45613b07774b7a78b7653e:

  Merge drm/drm-next into drm-misc-next (2021-12-16 14:48:27 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-01-27

for you to fetch changes up to a5d092d37eb5d25520d283985082e977bda68eb7:

  drm/panel: simple: add Multi-Inno Technology MI0700S4T-6 (2022-01-27 09:29:16 
+0100)


drm-misc-next for v5.18:

UAPI Changes:
- Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL.

Cross-subsystem Changes:
- Assorted dt bindings updates.
- Fix vga16fb vga checking on x86.
- Fix extra semicolon in rwsem.h's _down_write_nest_lock.
- Assorted small fixes to agp and fbdev drivers.
- Fix oops in creating a udmabuf with 0 pages.
- Hot-unplug firmware fb devices on forced removal
- Reqquest memory region in simplefb and simpledrm, and don't make the 
ioresource as busy.

Core Changes:
- Mock a drm_plane in drm-plane-helper selftest.
- Assorted bug fixes to device logging, dbi.
- Use DP helper for sink count in mst.
- Assorted documentation fixes.
- Assorted small fixes.
- Move DP headers to drm/dp, and add a drm dp helper module.
- Move the buddy allocator from i915 to common drm.
- Add simple pci and platform module init macros to remove a lot of boilerplate 
from some drivers.
- Support microsoft extension for HMDs and specialized monitors.
- Improve edid parser's deep color handling.
- Add type 7 timing support to edid parser.
- Add a weak backpointer to the ttm_bo from ttm_resource
- Add 3 eDP panels.

Driver Changes:
- Add support for HDMI and JZ4780 to ingenic.
- Add support for higher DP/eDP bitrates to nouveau.
- Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, 
v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge 
drivers.
- Convert and revert exynos dsi support to bridge driver.
- Add vcc supply regulator support for sn65dsi83.
- More conversion of bridge/chipone-icn6211 to atomic.
- Remove conflicting fb's from stm, and add support for new hw version.
- Add device link in parade-ps8640 to fix suspend/resume.
- Update Boe-tv110c9m init sequence.
- Add wide screen support to AST2600.
- Fix omapdrm implicit dma_buf fencing.
- Add support for multiple overlay planes to vkms.
- Convert bridge/anx7625 to atomic, add HDCP support,
  add eld support for audio, an

Re: [PATCH] drm/fb-helper: Mark screen buffers in system memory with FB_VIRTFB


Hi

Am 27.01.22 um 12:42 schrieb Daniel Vetter:

On Thu, Jan 27, 2022 at 11:26:21AM +0100, Thomas Zimmermann wrote:

Mark screen buffers in system memory with FB_VIRTFB. Otherwise, the
buffers are mmap'ed as I/O memory (i.e., VM_IO). For shadow buffers,
also set the FB_READS_FAST hint.


Maybe clarify that this only holds for the defio case, and since we have
our own shadow copy for that anyway it shouldn't matter. I'm also not sure
how much the memcpy gains us compared to just redrawing ...

What's the motivation here, or just something you spotted?


Correctness mostly. fbdev's fbdefio tests for (the absence of) this flag 
and sets VM_IO accordingly.


It's actually for userspace. Maybe userspace tests these flags as well 
and can optimize memcpy pattern for different types of caching. But I 
wouldn't expect it TBH.


Best regards
Thomas


-Daniel



Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/drm_fb_helper.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ed43b987d306..f15127a32f7a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = sizes->surface_height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+   fbi->flags = FBINFO_DEFAULT;
  
  	drm_fb_helper_fill_info(fbi, fb_helper, sizes);
  
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,

fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+   fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
  
  		fbi->fbdefio = &drm_fbdev_defio;

-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
-   if (map.is_iomem)
+   if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
-   else
+   } else {
fbi->screen_buffer = map.vaddr;
+   fbi->flags |= FBINFO_VIRTFB;
+   }
  
  		/*

 * Shamelessly leak the physical address to user-space. As
--
2.34.1





--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.

Op 26-01-2022 om 13:55 schreef Gwan-gyeong Mun:
>
>
> On 1/26/22 9:37 AM, Maarten Lankhorst wrote:
>> set_cache_level may unbind the object, which will result in the below
>> lockdep splat:
>> <6> [184.578145] [IGT] kms_addfb_basic: starting subtest 
>> addfb25-framebuffer-vs-set-tiling
>> <4> [184.578220] [ cut here ]
>> <4> [184.578221] WARN_ON(debug_locks && 
>> !(lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map) != 0))
>> <4> [184.578237] WARNING: CPU: 6 PID: 5544 at 
>> drivers/gpu/drm/i915/i915_gem.c:123 i915_gem_object_unbind+0x4a9/0x510 [i915]
>> <4> [184.578323] Modules linked in: vgem drm_shmem_helper snd_hda_codec_hdmi 
>> i915 mei_hdcp x86_pkg_temp_thermal snd_hda_intel coretemp crct10dif_pclmul 
>> snd_intel_dspcfg crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel 
>> snd_hwdep drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm 
>> sysfillrect mei pps_core sysimgblt fb_sys_fops prime_numbers intel_lpss_pci 
>> smsc75xx usbnet mii
>> <4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted 
>> 5.16.0-CI-Patchwork_22006+ #1
>> <4> [184.578351] Hardware name: Intel Corporation Alder Lake Client 
>> Platform/AlderLake-P DDR4 RVP, BIOS ADLPFWI1.R00.2422.A00.2110131104 
>> 10/13/2021
>> <4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510 [i915]
>> <4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b e1 85 c0 0f 
>> 85 b1 fb ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1 a0 e8 a3 54 26 e1 <0f> 
>> 0b e9 97 fb ff ff 31 ed 48 8b 5c 24 58 65 48 33 1c 25 28 00 00
>> <4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
>> <4> [184.578428] RAX:  RBX: c900013b3bb0 RCX: 
>> 0001
>> <4> [184.578429] RDX: 8001 RSI: 8230b42d RDI: 
>> 
>> <4> [184.578430] RBP: 888120e1 R08:  R09: 
>> c0007fff
>> <4> [184.578431] R10: 0001 R11: c900013b3980 R12: 
>> 8881176ea740
>> <4> [184.578432] R13: 888120e1 R14:  R15: 
>> 0001
>> <4> [184.578433] FS:  7f65074f5e40() GS:8f30() 
>> knlGS:
>> <4> [184.578435] CS:  0010 DS:  ES:  CR0: 80050033
>> <4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4: 
>> 00770ee0
>> <4> [184.578437] PKRU: 5554
>> <4> [184.578438] Call Trace:
>> <4> [184.578439]  
>> <4> [184.578440]  ? dma_resv_iter_first_unlocked+0x78/0xf0
>> <4> [184.578447]  intel_dpt_create+0x88/0x220 [i915]
>> <4> [184.578530]  intel_framebuffer_init+0x5b8/0x620 [i915]
>> <4> [184.578612]  intel_framebuffer_create+0x3d/0x60 [i915]
>> <4> [184.578691]  intel_user_framebuffer_create+0x18f/0x2c0 [i915]
>> <4> [184.578775]  drm_internal_framebuffer_create+0x36d/0x4c0
>> <4> [184.578779]  drm_mode_addfb2+0x2f/0xd0
>> <4> [184.578781]  ? drm_mode_addfb_ioctl+0x10/0x10
>> <4> [184.578784]  drm_ioctl_kernel+0xac/0x140
>> <4> [184.578787]  drm_ioctl+0x201/0x3d0
>> <4> [184.578789]  ? drm_mode_addfb_ioctl+0x10/0x10
>> <4> [184.578796]  __x64_sys_ioctl+0x6a/0xa0
>> <4> [184.578800]  do_syscall_64+0x37/0xb0
>> <4> [184.578803]  entry_SYSCALL_64_after_hwframe+0x44/0xae
>> <4> [184.578805] RIP: 0033:0x7f6506736317
>> <4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 
>> c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 
>> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
>> <4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246 ORIG_RAX: 
>> 0010
>> <4> [184.578810] RAX: ffda RBX: 0006 RCX: 
>> 7f6506736317
>> <4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI: 
>> 0006
>> <4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09: 
>> 
>> <4> [184.578813] R10: 0008 R11: 0246 R12: 
>> c06864b8
>> <4> [184.578813] R13: 0006 R14:  R15: 
>> 
>> <4> [184.578819]  
>> <4> [184.578820] irq event stamp: 47931
>> <4> [184.578821] hardirqs last  enabled at (47937): [] 
>> __up_console_sem+0x62/0x70
>> <4> [184.578824] hardirqs last disabled at (47942): [] 
>> __up_console_sem+0x47/0x70
>> <4> [184.578826] softirqs last  enabled at (47340): [] 
>> __do_softirq+0x32d/0x493
>> <4> [184.578828] softirqs last disabled at (47335): [] 
>> irq_exit_rcu+0xa6/0xe0
>> <4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---
>>
>> Changes since v1:
>> - Fix intel_pin_fb_obj_dpt too.
>>
>> Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and take obj 
>> lock for i915_vma_unbind, v2.")
>> Signed-off-by: Maarten Lankhorst 
>> Testcase: kms_addfb_basic
>> ---
>>   drivers/gpu/drm/i915/display/intel_dpt.c    | 6 +-
>>   drivers/gpu/drm/i915/display/intel_fb_pin.c | 6 +-
>>   2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
>> b/drivers

[PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API

2022-01-27 Thread Zhi Wang

From: Zhi Wang 

To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be separated into two phases:

a) Early initialization.

The early initialization of GVT requires to be done when loading i915.
Mostly it's because the initial clean HW state needs to be saved before
i915 touches the HW.

b) Late initalization.

This phases of initalization will setup the rest components of GVT-g,
which can be done later when the dedicated module is being loaded.

v5:

- Re-design the mmio table framework. (Chirstoph)

v4:

- Fix the errors of patch checking scripts.

v3:

- Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)

v2:

- Implement a mmio table instead of generating it by marco in i915. (Jani)

Cc: Christoph Hellwig 
Cc: Jason Gunthorpe 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Vivi Rodrigo 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Tested-by: Terrence Xu 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |2 +-
 drivers/gpu/drm/i915/gvt/gvt.c|   19 +-
 drivers/gpu/drm/i915/gvt/gvt.h|   21 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 1878 +
 drivers/gpu/drm/i915/gvt/mmio.h   |2 -
 drivers/gpu/drm/i915/gvt/mmio_table.c | 1386 ++
 drivers/gpu/drm/i915/gvt/mmio_table.h |   58 +
 drivers/gpu/drm/i915/gvt/reg.h|9 +-
 9 files changed, 1796 insertions(+), 1581 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.c
 create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26e6736bebb..029e5f5e0955 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -318,7 +318,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
 i915-y += i915_vgpu.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
-i915-y += intel_gvt.o
+i915-y += intel_gvt.o gvt/mmio_table.o
 include $(src)/gvt/Makefile
 endif
 
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index ec18122cc216..e9b5c70bb004 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3205,7 +3205,7 @@ int intel_gvt_scan_engine_context(struct 
intel_vgpu_workload *workload)
 
 static int init_cmd_table(struct intel_gvt *gvt)
 {
-   unsigned int gen_type = intel_gvt_get_device_type(gvt);
+   unsigned int gen_type = intel_gvt_get_device_type(gvt->gt->i915);
int i;
 
for (i = 0; i < ARRAY_SIZE(cmd_info); i++) {
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index f0b69e4dcb52..a0243e863613 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -63,23 +63,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.emulate_hotplug = intel_vgpu_emulate_hotplug,
 };
 
-static void init_device_info(struct intel_gvt *gvt)
-{
-   struct intel_gvt_device_info *info = &gvt->device_info;
-   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
-
-   info->max_support_vgpus = 8;
-   info->cfg_space_size = PCI_CFG_SPACE_EXP_SIZE;
-   info->mmio_size = 2 * 1024 * 1024;
-   info->mmio_bar = 0;
-   info->gtt_start_offset = 8 * 1024 * 1024;
-   info->gtt_entry_size = 8;
-   info->gtt_entry_size_shift = 3;
-   info->gmadr_bytes_in_cmd = 8;
-   info->max_surface_size = 36 * 1024 * 1024;
-   info->msi_cap_offset = pdev->msi_cap;
-}
-
 static void intel_gvt_test_and_emulate_vblank(struct intel_gvt *gvt)
 {
struct intel_vgpu *vgpu;
@@ -208,7 +191,7 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
gvt->gt = to_gt(i915);
i915->gvt = gvt;
 
-   init_device_info(gvt);
+   intel_gvt_init_device_info(i915, &gvt->device_info);
 
ret = intel_gvt_setup_mmio_info(gvt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 0ebffc327528..e4513e2ce469 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -40,6 +40,7 @@
 #include "debug.h"
 #include "hypercall.h"
 #include "mmio.h"
+#include "mmio_table.h"
 #include "reg.h"
 #include "interrupt.h"
 #include "gtt.h"
@@ -65,20 +66,6 @@ struct intel_gvt_host {
 
 extern struct intel_gvt_host intel_gvt_host;
 
-/* Describe per-platform limitations. */
-struct intel_gvt_device_info {
-   u32 max_support_vgpus;
-   u32 cfg_space_size;
-   u32 mmio_size;
-   u32 mmio_bar;
-   unsigned long msi_cap_offset;
-   u32 gtt_start_offset;
-   u32 gtt_entry_size;
-   u32 gtt_entry_size_shift;
-   int gmadr_bytes_in_cmd;
-   u32 max_surface_size;
-};
-
 /* GM resources owned by a vGPU */
 struct intel_vgpu_gm {
u64 aperture_sz;
@@ -239,9 +226,9 @@ struct intel_gvt_fence {
 };
 
 /* Special MMIO blocks. */
-struct gvt_mmio_block {
+str

[PATCH 2/3] i915/gvt: save the initial HW state snapshot in i915.

2022-01-27 Thread Zhi Wang

Save the inital HW state snapshot in i915 so that the rest code of GVT-g
can be moved into a dedicated module while it can still get a clean
initial HW state saved at the correct time during the initialization of
i915. The futhrer vGPU created by GVT-g will use this HW state as the
initial HW state.

Cc: Christoph Hellwig 
Cc: Jason Gunthorpe 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Vivi Rodrigo 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_gvt.c | 110 ++-
 2 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44c1f98144b4..2a230840cdfa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -606,6 +606,8 @@ struct i915_virtual_gpu {
struct mutex lock; /* serialises sending of g2v_notify command pkts */
bool active;
u32 caps;
+   u32 *initial_mmio;
+   u8 *initial_cfg_space;
 };
 
 struct i915_selftest_stash {
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index cf6e98962d82..a3d8bdb24d3f 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -86,6 +86,103 @@ void intel_gvt_sanitize_options(struct drm_i915_private 
*dev_priv)
dev_priv->params.enable_gvt = 0;
 }
 
+static void free_initial_hw_state(struct drm_i915_private *dev_priv)
+{
+   struct i915_virtual_gpu *vgpu = &dev_priv->vgpu;
+
+   vfree(vgpu->initial_mmio);
+   vgpu->initial_mmio = NULL;
+
+   kfree(vgpu->initial_cfg_space);
+   vgpu->initial_cfg_space = NULL;
+}
+
+static void save_mmio(struct intel_gvt_mmio_table_iter *iter, u32 offset,
+ u32 size)
+{
+   struct drm_i915_private *dev_priv = iter->i915;
+   void *mmio = iter->data;
+   u32 start, end, i;
+
+   start = offset;
+   end = offset + size;
+
+   for (i = start; i < end; i += 4) {
+   *(u32 *)(mmio + i) = intel_uncore_read_notrace(
+   to_gt(dev_priv)->uncore, _MMIO(offset));
+   }
+}
+
+static int do_mmio(u32 offset, u16 flags, u32 size, u32 addr_mask,
+  u32 ro_mask, u32 device,
+  struct intel_gvt_mmio_table_iter *iter)
+{
+   if (WARN_ON(!IS_ALIGNED(offset, 4)))
+   return -EINVAL;
+
+   save_mmio(iter, offset, size);
+   return 0;
+}
+
+static int do_mmio_block(u32 offset, u32 size, u32 device,
+struct intel_gvt_mmio_table_iter *iter)
+{
+   if (WARN_ON(!IS_ALIGNED(offset, 4)))
+   return -EINVAL;
+
+   save_mmio(iter, offset, size);
+   return 0;
+}
+
+static int save_inital_hw_state(struct drm_i915_private *dev_priv)
+{
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
+   struct intel_gvt_device_info info;
+   struct i915_virtual_gpu *vgpu = &dev_priv->vgpu;
+   struct intel_gvt_mmio_table_iter iter;
+   void *mem;
+   int i, ret;
+
+   intel_gvt_init_device_info(dev_priv, &info);
+
+   mem = kzalloc(info.cfg_space_size, GFP_KERNEL);
+   if (!mem)
+   return -ENOMEM;
+
+   vgpu->initial_cfg_space = mem;
+
+   for (i = 0; i < PCI_CFG_SPACE_EXP_SIZE; i += 4)
+   pci_read_config_dword(pdev, i, mem + i);
+
+   mem = vzalloc(info.mmio_size);
+   if (!mem) {
+   ret = -ENOMEM;
+   goto err_mmio;
+   }
+
+   vgpu->initial_mmio = mem;
+
+   iter.i915 = dev_priv;
+   iter.data = vgpu->initial_mmio;
+   iter.do_mmio = do_mmio;
+   iter.do_mmio_block = do_mmio_block;
+
+   ret = intel_gvt_iterate_mmio_table(&iter);
+   if (ret)
+   goto err_iterate;
+
+   return 0;
+
+err_iterate:
+   vfree(vgpu->initial_mmio);
+   vgpu->initial_mmio = NULL;
+err_mmio:
+   kfree(vgpu->initial_cfg_space);
+   vgpu->initial_cfg_space = NULL;
+
+   return ret;
+}
+
 /**
  * intel_gvt_init - initialize GVT components
  * @dev_priv: drm i915 private data
@@ -115,15 +212,23 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
return -EIO;
}
 
+   ret = save_inital_hw_state(dev_priv);
+   if (ret) {
+   drm_dbg(&dev_priv->drm, "Fail to save inital HW state\n");
+   goto err_save_hw_state;
+   }
+
ret = intel_gvt_init_device(dev_priv);
if (ret) {
drm_dbg(&dev_priv->drm, "Fail to init GVT device\n");
-   goto bail;
+   goto err_init_device;
}
 
return 0;
 
-bail:
+err_init_device:
+   free_initial_hw_state(dev_priv);
+err_save_hw_state:
dev_priv->params.enable_gvt = 0;
return 0;
 }
@@ -147,6 +252,7 @@ void intel_gvt_driver_remove(struct drm_i915_private 
*dev_priv)
return;
 
intel_gvt_clean_device(dev_priv);
+   free_initi

[PATCH 3/3] i915/gvt: Use the initial HW state snapshot saved in i915

2022-01-27 Thread Zhi Wang

The code of saving initial HW state snapshot has been moved into i915.
Let the GVT-g core logic use that snapshot.

Cc: Christoph Hellwig 
Cc: Jason Gunthorpe 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Vivi Rodrigo 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/gvt/firmware.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 1a8274a3f4b1..1d55920bfd42 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -66,22 +66,16 @@ static struct bin_attribute firmware_attr = {
.mmap = NULL,
 };
 
-static int mmio_snapshot_handler(struct intel_gvt *gvt, u32 offset, void *data)
-{
-   *(u32 *)(data + offset) = intel_uncore_read_notrace(gvt->gt->uncore,
-   _MMIO(offset));
-   return 0;
-}
-
 static int expose_firmware_sysfs(struct intel_gvt *gvt)
 {
struct intel_gvt_device_info *info = &gvt->device_info;
-   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
+   struct drm_i915_private *i915 = gvt->gt->i915;
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct gvt_firmware_header *h;
void *firmware;
void *p;
unsigned long size, crc32_start;
-   int i, ret;
+   int ret;
 
size = sizeof(*h) + info->mmio_size + info->cfg_space_size;
firmware = vzalloc(size);
@@ -99,17 +93,16 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
 
p = firmware + h->cfg_space_offset;
 
-   for (i = 0; i < h->cfg_space_size; i += 4)
-   pci_read_config_dword(pdev, i, p + i);
-
-   memcpy(gvt->firmware.cfg_space, p, info->cfg_space_size);
+   memcpy(gvt->firmware.cfg_space, i915->vgpu.initial_cfg_space,
+   info->cfg_space_size);
+   memcpy(p, gvt->firmware.cfg_space, info->cfg_space_size);
 
p = firmware + h->mmio_offset;
 
-   /* Take a snapshot of hw mmio registers. */
-   intel_gvt_for_each_tracked_mmio(gvt, mmio_snapshot_handler, p);
+   memcpy(gvt->firmware.mmio, i915->vgpu.initial_mmio,
+   info->mmio_size);
 
-   memcpy(gvt->firmware.mmio, p, info->mmio_size);
+   memcpy(p, gvt->firmware.mmio, info->mmio_size);
 
crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
h->crc32 = crc32_le(0, firmware + crc32_start, size - crc32_start);
-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.

On Thu, 2022-01-27 at 13:02 +0100, Maarten Lankhorst wrote:
> Op 26-01-2022 om 13:55 schreef Gwan-gyeong Mun:
> > 
> > 
> > On 1/26/22 9:37 AM, Maarten Lankhorst wrote:
> > > set_cache_level may unbind the object, which will result in the
> > > below
> > > lockdep splat:
> > > <6> [184.578145] [IGT] kms_addfb_basic: starting subtest addfb25-
> > > framebuffer-vs-set-tiling
> > > <4> [184.578220] [ cut here ]
> > > <4> [184.578221] WARN_ON(debug_locks && !(lock_is_held(&(&((obj)-
> > > >base.resv)->lock.base)->dep_map) != 0))
> > > <4> [184.578237] WARNING: CPU: 6 PID: 5544 at
> > > drivers/gpu/drm/i915/i915_gem.c:123
> > > i915_gem_object_unbind+0x4a9/0x510 [i915]
> > > <4> [184.578323] Modules linked in: vgem drm_shmem_helper
> > > snd_hda_codec_hdmi i915 mei_hdcp x86_pkg_temp_thermal
> > > snd_hda_intel coretemp crct10dif_pclmul snd_intel_dspcfg
> > > crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel snd_hwdep
> > > drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm
> > > sysfillrect mei pps_core sysimgblt fb_sys_fops prime_numbers
> > > intel_lpss_pci smsc75xx usbnet mii
> > > <4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not
> > > tainted 5.16.0-CI-Patchwork_22006+ #1
> > > <4> [184.578351] Hardware name: Intel Corporation Alder Lake
> > > Client Platform/AlderLake-P DDR4 RVP, BIOS
> > > ADLPFWI1.R00.2422.A00.2110131104 10/13/2021
> > > <4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510
> > > [i915]
> > > <4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b
> > > e1 85 c0 0f 85 b1 fb ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1
> > > a0 e8 a3 54 26 e1 <0f> 0b e9 97 fb ff ff 31 ed 48 8b 5c 24 58 65
> > > 48 33 1c 25 28 00 00
> > > <4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
> > > <4> [184.578428] RAX:  RBX: c900013b3bb0 RCX:
> > > 0001
> > > <4> [184.578429] RDX: 8001 RSI: 8230b42d RDI:
> > > 
> > > <4> [184.578430] RBP: 888120e1 R08:  R09:
> > > c0007fff
> > > <4> [184.578431] R10: 0001 R11: c900013b3980 R12:
> > > 8881176ea740
> > > <4> [184.578432] R13: 888120e1 R14:  R15:
> > > 0001
> > > <4> [184.578433] FS:  7f65074f5e40()
> > > GS:8f30() knlGS:
> > > <4> [184.578435] CS:  0010 DS:  ES:  CR0:
> > > 80050033
> > > <4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4:
> > > 00770ee0
> > > <4> [184.578437] PKRU: 5554
> > > <4> [184.578438] Call Trace:
> > > <4> [184.578439]  
> > > <4> [184.578440]  ? dma_resv_iter_first_unlocked+0x78/0xf0
> > > <4> [184.578447]  intel_dpt_create+0x88/0x220 [i915]
> > > <4> [184.578530]  intel_framebuffer_init+0x5b8/0x620 [i915]
> > > <4> [184.578612]  intel_framebuffer_create+0x3d/0x60 [i915]
> > > <4> [184.578691]  intel_user_framebuffer_create+0x18f/0x2c0
> > > [i915]
> > > <4> [184.578775]  drm_internal_framebuffer_create+0x36d/0x4c0
> > > <4> [184.578779]  drm_mode_addfb2+0x2f/0xd0
> > > <4> [184.578781]  ? drm_mode_addfb_ioctl+0x10/0x10
> > > <4> [184.578784]  drm_ioctl_kernel+0xac/0x140
> > > <4> [184.578787]  drm_ioctl+0x201/0x3d0
> > > <4> [184.578789]  ? drm_mode_addfb_ioctl+0x10/0x10
> > > <4> [184.578796]  __x64_sys_ioctl+0x6a/0xa0
> > > <4> [184.578800]  do_syscall_64+0x37/0xb0
> > > <4> [184.578803]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> > > <4> [184.578805] RIP: 0033:0x7f6506736317
> > > <4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26
> > > 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8
> > > 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d
> > > 00 f7 d8 64 89 01 48
> > > <4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246
> > > ORIG_RAX: 0010
> > > <4> [184.578810] RAX: ffda RBX: 0006 RCX:
> > > 7f6506736317
> > > <4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI:
> > > 0006
> > > <4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09:
> > > 
> > > <4> [184.578813] R10: 0008 R11: 0246 R12:
> > > c06864b8
> > > <4> [184.578813] R13: 0006 R14:  R15:
> > > 
> > > <4> [184.578819]  
> > > <4> [184.578820] irq event stamp: 47931
> > > <4> [184.578821] hardirqs last  enabled at (47937):
> > > [] __up_console_sem+0x62/0x70
> > > <4> [184.578824] hardirqs last disabled at (47942):
> > > [] __up_console_sem+0x47/0x70
> > > <4> [184.578826] softirqs last  enabled at (47340):
> > > [] __do_softirq+0x32d/0x493
> > > <4> [184.578828] softirqs last disabled at (47335):
> > > [] irq_exit_rcu+0xa6/0xe0
> > > <4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---
> > > 
> > > Changes since v1:
> > > - Fix intel_pin_fb_obj_dpt too.
> > > 
> > > Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and
> > > tak

Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.




On 1/27/22 13:05, Thomas Hellström wrote:



The bug on vm_close is a separate bug, and would probably best be
fixed in a separate patch.

Could I get a r-b on this? It should fix some issues, even if the
unbind there is a separate bug.

~Maarten


Recognizing that it doesn't fix the vm_close issue,

Reviewed-by: Thomas Hellström 


Oh, BTW should probably carefully review those seemingly unrelated stall 
warnings from BAT to check whether the newly introduced object lock 
might stall a workqueue causing those.


/Thomas

Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.

Op 27-01-2022 om 13:09 schreef Thomas Hellström:
>
> On 1/27/22 13:05, Thomas Hellström wrote:
>>
>>> The bug on vm_close is a separate bug, and would probably best be
>>> fixed in a separate patch.
>>>
>>> Could I get a r-b on this? It should fix some issues, even if the
>>> unbind there is a separate bug.
>>>
>>> ~Maarten
>>>
>> Recognizing that it doesn't fix the vm_close issue,
>>
>> Reviewed-by: Thomas Hellström 
>
> Oh, BTW should probably carefully review those seemingly unrelated stall 
> warnings from BAT to check whether the newly introduced object lock might 
> stall a workqueue causing those.
>
> /Thomas

Which ones? I mostly see ext4 failures, where it doesn't seem to have any i915 
lock held at all.

Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.




On 1/27/22 13:38, Maarten Lankhorst wrote:

Op 27-01-2022 om 13:09 schreef Thomas Hellström:

On 1/27/22 13:05, Thomas Hellström wrote:

The bug on vm_close is a separate bug, and would probably best be
fixed in a separate patch.

Could I get a r-b on this? It should fix some issues, even if the
unbind there is a separate bug.

~Maarten


Recognizing that it doesn't fix the vm_close issue,

Reviewed-by: Thomas Hellström 

Oh, BTW should probably carefully review those seemingly unrelated stall 
warnings from BAT to check whether the newly introduced object lock might stall 
a workqueue causing those.

/Thomas

Which ones? I mostly see ext4 failures, where it doesn't seem to have any i915 
lock held at all.

Oh, I was looking at v1 version of the patch, but just noticed a hang. 
Didn't look to carefully at what was the cause.


/Thomas

Re: acpi_get_devices() crash when acpi_disabled==true (was [PATCH v2] drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen)

2022-01-27 Thread Hans de Goede

Hi,

On 1/26/22 18:11, Rafael J. Wysocki wrote:
> On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 1/26/22 16:54, Rafael J. Wysocki wrote:
>>> On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede  wrote:

 Hi All,

 On 1/23/22 10:10, Tong Zhang wrote:
> when acpi=off is provided in bootarg, kernel crash with
>
> [1.252739] BUG: kernel NULL pointer dereference, address: 
> 0018
> [1.258308] Call Trace:
> [1.258490]  ? acpi_walk_namespace+0x147/0x147
> [1.258770]  acpi_get_devices+0xe4/0x137
> [1.258921]  ? drm_core_init+0xc0/0xc0 [drm]
> [1.259108]  detect_thinkpad_privacy_screen+0x5e/0xa8 [drm]
> [1.259337]  drm_privacy_screen_lookup_init+0xe/0xe85 [drm]
>
> The reason is that acpi_walk_namespace expects acpi related stuff
> initialized but in fact it wouldn't when acpi is set to off. In this case
> we should honor acpi=off in detect_thinkpad_privacy_screen().
>
> Signed-off-by: Tong Zhang 

 Thank you for catching this and thank you for your patch. I was about to 
 merge
 this, but then I realized that this might not be the best way to fix this.

 A quick grep shows 10 acpi_get_devices() calls outside of drivers/acpi,
 and at a first glance about half of those are missing an acpi_disabled
 check. IMHO it would be better to simply add an acpi_disabled check to
 acpi_get_devices() itself.

 Rafael, do you agree ?
>>>
>>> Yes, I do.
>>
>> Did you see my follow-up that that is not going to work because
>> acpi_get_devices() is an acpica function ?
> 
> No, I didn't, but it is possible to add a wrapper doing the check
> around it and convert all of the users.

Yes I did think about that. Note that I've gone ahead and pushed
the fix which started this to drm-misc-fixes, to resolve the crash
for now.

If we add such a wrapper we can remove a bunch of acpi_disabled checks
from various callers.

> Alternatively, the ACPICA function can check acpi_gbl_root_node
> against NULL, like in the attached (untested) patch.

That is probably an even better idea, as that avoids the need
for a wrapper altogether. So I believe that that is the best
solution.

Regards,

Hans

Re: [PATCH] drm/doc: Add section in the introduction page about learning material

On 1/27/22 12:31, Daniel Vetter wrote:
> On Thu, Jan 27, 2022 at 11:50:30AM +0100, Javier Martinez Canillas wrote:

[snip]

>> Indeed. And we can add such section as a follow-up. Maybe referring to some
>> of the drivers in drivers/gpu/drm/tiny.
> 
> Do we have a talk anywhere for tiny?
>

I couldn't find one for tiny.
 
> Otherwise I think it'd be good to just add a paragraph about "hey tiny
> exists" and maybe link to fbdev helpers and simple pipe helpers to get
> people started with the right entry points for simple drivers.
>

Ok. I can add some sentences about drm/tiny and point out that the DRM
drivers there could be used as a good references for simple drivers.
 
> And make it clear that the above pile of links is more for general
> overview and if you don't yet know what exactly it is you need.
> 

Sure, I'll add that too.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH] drm/vc4: hdmi: Ensure we don't use 2711 HPD registers on Pi0-3

From: Dave Stevenson 

The existing logic was flawed in that it could try reading the
2711 specific registers for HPD on a CM1/3 where the HPD GPIO
hadn't been defined in DT.

Ensure we don't do the 2711 register read on invalid hardware,
and then

Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 24 
 drivers/gpu/drm/vc4/vc4_hdmi.h |  3 +++
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index e3121eb5f605..33ecfa1e3661 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -205,14 +205,8 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
if (gpiod_get_value_cansleep(vc4_hdmi->hpd_gpio))
connected = true;
} else {
-   unsigned long flags;
-   u32 hotplug;
-
-   spin_lock_irqsave(&vc4_hdmi->hw_lock, flags);
-   hotplug = HDMI_READ(HDMI_HOTPLUG);
-   spin_unlock_irqrestore(&vc4_hdmi->hw_lock, flags);
-
-   if (hotplug & VC4_HDMI_HOTPLUG_CONNECTED)
+   if (vc4_hdmi->variant->hp_detect &&
+   vc4_hdmi->variant->hp_detect(vc4_hdmi))
connected = true;
}
 
@@ -1367,6 +1361,18 @@ static u32 vc5_hdmi_channel_map(struct vc4_hdmi 
*vc4_hdmi, u32 channel_mask)
return channel_map;
 }
 
+static bool vc5_hdmi_hp_detect(struct vc4_hdmi *vc4_hdmi)
+{
+   unsigned long flags;
+   u32 hotplug;
+
+   spin_lock_irqsave(&vc4_hdmi->hw_lock, flags);
+   hotplug = HDMI_READ(HDMI_HOTPLUG);
+   spin_unlock_irqrestore(&vc4_hdmi->hw_lock, flags);
+
+   return !!(hotplug & VC4_HDMI_HOTPLUG_CONNECTED);
+}
+
 /* HDMI audio codec callbacks */
 static void vc4_hdmi_audio_set_mai_clock(struct vc4_hdmi *vc4_hdmi,
 unsigned int samplerate)
@@ -2747,6 +2753,7 @@ static const struct vc4_hdmi_variant 
bcm2711_hdmi0_variant = {
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
.supports_hdr   = true,
+   .hp_detect  = vc5_hdmi_hp_detect,
 };
 
 static const struct vc4_hdmi_variant bcm2711_hdmi1_variant = {
@@ -2775,6 +2782,7 @@ static const struct vc4_hdmi_variant 
bcm2711_hdmi1_variant = {
.phy_rng_disable= vc5_hdmi_phy_rng_disable,
.channel_map= vc5_hdmi_channel_map,
.supports_hdr   = true,
+   .hp_detect  = vc5_hdmi_hp_detect,
 };
 
 static const struct of_device_id vc4_hdmi_dt_match[] = {
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2b6aaafc020a..933a468e10f3 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -103,6 +103,9 @@ struct vc4_hdmi_variant {
 
/* Enables HDR metadata */
bool supports_hdr;
+
+   /* Callback for hardware specific hotplug detect */
+   bool (*hp_detect)(struct vc4_hdmi *vc4_hdmi);
 };
 
 /* HDMI audio information */
-- 
2.34.1

Re: [PATCH] misc: fastrpc: avoid double fput() on failed usercopy

2022-01-27 Thread Greg Kroah-Hartman

On Thu, Jan 27, 2022 at 02:24:29PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 27, 2022 at 02:02:18PM +0100, Mathias Krause wrote:
> > If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF
> > ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact,
> > dma_buf_fd() called fd_install() before, i.e. "consumed" one reference,
> > leaving us with none.
> > 
> > Calling dma_buf_put() will therefore put a reference we no longer own,
> > leading to a valid file descritor table entry for an already released
> > 'file' object which is a straight use-after-free.
> > 
> > Simply avoid calling dma_buf_put() and rely on the process exit code to
> > do the necessary cleanup, if needed, i.e. if the file descriptor is
> > still valid.
> > 
> > Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter")
> > Signed-off-by: Mathias Krause 
> > ---
> >  drivers/misc/fastrpc.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> > index 4ccbf43e6bfa..aa1682b94a23 100644
> > --- a/drivers/misc/fastrpc.c
> > +++ b/drivers/misc/fastrpc.c
> > @@ -1288,7 +1288,14 @@ static int fastrpc_dmabuf_alloc(struct fastrpc_user 
> > *fl, char __user *argp)
> > }
> >  
> > if (copy_to_user(argp, &bp, sizeof(bp))) {
> > -   dma_buf_put(buf->dmabuf);
> > +   /*
> > +* The usercopy failed, but we can't do much about it, as
> > +* dma_buf_fd() already called fd_install() and made the
> > +* file descriptor accessible for the current process. It
> > +* might already be closed and dmabuf no longer valid when
> > +* we reach this point. Therefore "leak" the fd and rely on
> > +* the process exit path to do any required cleanup.
> > +*/
> > return -EFAULT;
> > }
> >  
> 
> This feels wrong.  How do all other dma buf users handle this?
> 
> And you forgot to cc: the dmabuf developers, I think get_maintainers.pl
> should have caught them on this patch.

Odd, it didn't, not your fault, my apologies.

DMA BUFFER maintainers, what happened to the MAINTAINERS regex that
caused the above patch to not catch you all?

thanks,

greg k-h

Re: acpi_get_devices() crash when acpi_disabled==true (was [PATCH v2] drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen)

2022-01-27 Thread Rafael J. Wysocki

On Thu, Jan 27, 2022 at 2:05 PM Hans de Goede  wrote:
>
> Hi,
>
> On 1/26/22 18:11, Rafael J. Wysocki wrote:
> > On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede  wrote:
> >>
> >> Hi,
> >>
> >> On 1/26/22 16:54, Rafael J. Wysocki wrote:
> >>> On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede  wrote:
> 
>  Hi All,
> 
>  On 1/23/22 10:10, Tong Zhang wrote:
> > when acpi=off is provided in bootarg, kernel crash with
> >
> > [1.252739] BUG: kernel NULL pointer dereference, address: 
> > 0018
> > [1.258308] Call Trace:
> > [1.258490]  ? acpi_walk_namespace+0x147/0x147
> > [1.258770]  acpi_get_devices+0xe4/0x137
> > [1.258921]  ? drm_core_init+0xc0/0xc0 [drm]
> > [1.259108]  detect_thinkpad_privacy_screen+0x5e/0xa8 [drm]
> > [1.259337]  drm_privacy_screen_lookup_init+0xe/0xe85 [drm]
> >
> > The reason is that acpi_walk_namespace expects acpi related stuff
> > initialized but in fact it wouldn't when acpi is set to off. In this 
> > case
> > we should honor acpi=off in detect_thinkpad_privacy_screen().
> >
> > Signed-off-by: Tong Zhang 
> 
>  Thank you for catching this and thank you for your patch. I was about to 
>  merge
>  this, but then I realized that this might not be the best way to fix 
>  this.
> 
>  A quick grep shows 10 acpi_get_devices() calls outside of drivers/acpi,
>  and at a first glance about half of those are missing an acpi_disabled
>  check. IMHO it would be better to simply add an acpi_disabled check to
>  acpi_get_devices() itself.
> 
>  Rafael, do you agree ?
> >>>
> >>> Yes, I do.
> >>
> >> Did you see my follow-up that that is not going to work because
> >> acpi_get_devices() is an acpica function ?
> >
> > No, I didn't, but it is possible to add a wrapper doing the check
> > around it and convert all of the users.
>
> Yes I did think about that. Note that I've gone ahead and pushed
> the fix which started this to drm-misc-fixes, to resolve the crash
> for now.

OK

> If we add such a wrapper we can remove a bunch of acpi_disabled checks
> from various callers.
>
> > Alternatively, the ACPICA function can check acpi_gbl_root_node
> > against NULL, like in the attached (untested) patch.
>
> That is probably an even better idea, as that avoids the need
> for a wrapper altogether. So I believe that that is the best
> solution.

Allright, let me cut an analogous patch for the upstream ACPICA, then.

Re: acpi_get_devices() crash when acpi_disabled==true (was [PATCH v2] drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen)

2022-01-27 Thread Hans de Goede

Hi,

On 1/27/22 14:33, Rafael J. Wysocki wrote:
> On Thu, Jan 27, 2022 at 2:05 PM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 1/26/22 18:11, Rafael J. Wysocki wrote:
>>> On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede  wrote:

 Hi,

 On 1/26/22 16:54, Rafael J. Wysocki wrote:
> On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede  wrote:
>>
>> Hi All,
>>
>> On 1/23/22 10:10, Tong Zhang wrote:
>>> when acpi=off is provided in bootarg, kernel crash with
>>>
>>> [1.252739] BUG: kernel NULL pointer dereference, address: 
>>> 0018
>>> [1.258308] Call Trace:
>>> [1.258490]  ? acpi_walk_namespace+0x147/0x147
>>> [1.258770]  acpi_get_devices+0xe4/0x137
>>> [1.258921]  ? drm_core_init+0xc0/0xc0 [drm]
>>> [1.259108]  detect_thinkpad_privacy_screen+0x5e/0xa8 [drm]
>>> [1.259337]  drm_privacy_screen_lookup_init+0xe/0xe85 [drm]
>>>
>>> The reason is that acpi_walk_namespace expects acpi related stuff
>>> initialized but in fact it wouldn't when acpi is set to off. In this 
>>> case
>>> we should honor acpi=off in detect_thinkpad_privacy_screen().
>>>
>>> Signed-off-by: Tong Zhang 
>>
>> Thank you for catching this and thank you for your patch. I was about to 
>> merge
>> this, but then I realized that this might not be the best way to fix 
>> this.
>>
>> A quick grep shows 10 acpi_get_devices() calls outside of drivers/acpi,
>> and at a first glance about half of those are missing an acpi_disabled
>> check. IMHO it would be better to simply add an acpi_disabled check to
>> acpi_get_devices() itself.
>>
>> Rafael, do you agree ?
>
> Yes, I do.

 Did you see my follow-up that that is not going to work because
 acpi_get_devices() is an acpica function ?
>>>
>>> No, I didn't, but it is possible to add a wrapper doing the check
>>> around it and convert all of the users.
>>
>> Yes I did think about that. Note that I've gone ahead and pushed
>> the fix which started this to drm-misc-fixes, to resolve the crash
>> for now.
> 
> OK
> 
>> If we add such a wrapper we can remove a bunch of acpi_disabled checks
>> from various callers.
>>
>>> Alternatively, the ACPICA function can check acpi_gbl_root_node
>>> against NULL, like in the attached (untested) patch.
>>
>> That is probably an even better idea, as that avoids the need
>> for a wrapper altogether. So I believe that that is the best
>> solution.
> 
> Allright, let me cut an analogous patch for the upstream ACPICA, then.

Great, thank you.

I have added a note about checking for when this has found its way
into Linus' tree to my own TODO list, with the goal of doing
a cleanup series removing the then no longer needed acpi_disabled
checks in a bunch of places.

Regards,

Hans

[PATCH] drm/vc4: hdmi: Don't try disabling SCDC on Pi0-3.

From: Dave Stevenson 

The code that set the scdc_enabled flag to ensure it was
disabled at boot time also ran on Pi0-3 where there is no
SCDC support. This lead to a warning in vc4_hdmi_encoder_post_crtc_disable
due to vc4_hdmi_disable_scrambling being called and trying to
read (and write) register HDMI_SCRAMBLER_CTL which doesn't
exist on those platforms.

Only set the flag should the interface be configured to support
more than HDMI 1.4.

Fixes: 1998646129fa ("drm/vc4: hdmi: Introduce a scdc_enabled flag")
Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 33ecfa1e3661..0ee446df50a0 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -2534,7 +2534,8 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
 * vc4_hdmi_disable_scrambling() will thus run at boot, make
 * sure it's disabled, and avoid any inconsistency.
 */
-   vc4_hdmi->scdc_enabled = true;
+   if (variant->max_pixel_clock > HDMI_14_MAX_TMDS_CLK)
+   vc4_hdmi->scdc_enabled = true;
 
ret = variant->init_resources(vc4_hdmi);
if (ret)
-- 
2.34.1

[PATCH] drm/vc4: hdmi: Allow DBLCLK modes even if horz timing is odd.

From: Dave Stevenson 

The 2711 pixel valve can't produce odd horizontal timings, and
checks were added to vc4_hdmi_encoder_atomic_check and
vc4_hdmi_encoder_mode_valid to filter out/block selection of
such modes.

Modes with DRM_MODE_FLAG_DBLCLK double all the horizontal timing
values before programming them into the PV. The PV values,
therefore, can not be odd, and so the modes can be supported.

Amend the filtering appropriately.

Fixes: 57fb32e632be ("drm/vc4: hdmi: Block odd horizontal timings")
Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 0ee446df50a0..92b1530aa17b 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1269,6 +1269,7 @@ static int vc4_hdmi_encoder_atomic_check(struct 
drm_encoder *encoder,
unsigned long long tmds_rate;
 
if (vc4_hdmi->variant->unsupported_odd_h_timings &&
+   !(mode->flags & DRM_MODE_FLAG_DBLCLK) &&
((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
 (mode->hsync_end % 2) || (mode->htotal % 2)))
return -EINVAL;
@@ -1316,6 +1317,7 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
 
if (vc4_hdmi->variant->unsupported_odd_h_timings &&
+   !(mode->flags & DRM_MODE_FLAG_DBLCLK) &&
((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
 (mode->hsync_end % 2) || (mode->htotal % 2)))
return MODE_H_ILLEGAL;
-- 
2.34.1

Re: [PATCH] misc: fastrpc: avoid double fput() on failed usercopy


Am 27.01.22 um 14:26 schrieb Greg Kroah-Hartman:

On Thu, Jan 27, 2022 at 02:24:29PM +0100, Greg Kroah-Hartman wrote:

On Thu, Jan 27, 2022 at 02:02:18PM +0100, Mathias Krause wrote:

If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF
ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact,
dma_buf_fd() called fd_install() before, i.e. "consumed" one reference,
leaving us with none.

Calling dma_buf_put() will therefore put a reference we no longer own,
leading to a valid file descritor table entry for an already released
'file' object which is a straight use-after-free.

Simply avoid calling dma_buf_put() and rely on the process exit code to
do the necessary cleanup, if needed, i.e. if the file descriptor is
still valid.

Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter")
Signed-off-by: Mathias Krause 
---
  drivers/misc/fastrpc.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 4ccbf43e6bfa..aa1682b94a23 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -1288,7 +1288,14 @@ static int fastrpc_dmabuf_alloc(struct fastrpc_user *fl, 
char __user *argp)
}
  
  	if (copy_to_user(argp, &bp, sizeof(bp))) {

-   dma_buf_put(buf->dmabuf);
+   /*
+* The usercopy failed, but we can't do much about it, as
+* dma_buf_fd() already called fd_install() and made the
+* file descriptor accessible for the current process. It
+* might already be closed and dmabuf no longer valid when
+* we reach this point. Therefore "leak" the fd and rely on
+* the process exit path to do any required cleanup.
+*/
return -EFAULT;
}
  

This feels wrong.  How do all other dma buf users handle this?

And you forgot to cc: the dmabuf developers, I think get_maintainers.pl
should have caught them on this patch.

Odd, it didn't, not your fault, my apologies.

DMA BUFFER maintainers, what happened to the MAINTAINERS regex that
caused the above patch to not catch you all?


That worked as expected: \bdma_(?:buf|fence|resv)\b

We are only automatically getting CCed when any of the dma_buf, 
dma_fence or dma_resv structures are mentioned.


We could remove the trailing \b and match the function names as well.

Regards,
Christian.



thanks,

greg k-h

[PATCH v5 0/6] drm/vc4: hdmi: Yet Another Approach to HDMI YUV output

Hi,

This is another attempt at supporting the HDMI YUV output in the vc4 HDMI
driver.

This is a follow-up of
https://lore.kernel.org/dri-devel/20210317154352.732095-1-max...@cerno.tech/

And the discussions that occured recently on the mailing lists and IRC about
this.

The series mentioned above had multiple issues, the main one being that it was
a bit too much complicated for what we wanted to achieve. This series is taking
a much simpler approach with an ad-hoc solution.

I think some parts of it could still be moved to KMS helpers (notably, the
output format enum, and the helper to set the infoframe for it) and structures
(the output format stored in drm_connector_state). This would also interact
nicely with the work done here:

https://lore.kernel.org/dri-devel/2028103814.524670-1-max...@cerno.tech/

This can come as a second step though.

The other issues with the first attempt was that nothing was reported to
userspace about the decision we made about the format, and that this decision
was essentially policy, without any way for the userspace to influence it.

Those two points however are being worked on by Werner in a cross-driver
effort:

https://lore.kernel.org/dri-devel/e452775c-5b95-bbfd-e818-f1480f556...@tuxedocomputers.com/

Since it's a KMS decision, I don't think we should hold off any driver as long
as it's consistent with what the other drivers are doing.

Let me know what you think,
Maxime

---

Changes from v4:
  - Fix a clock calculation
  - Rebased on latest drm-misc-next tag

Changes from v3:
  - Rebased on latest next
  - Fixed build error

Changes from v2:
  - Rename the output format enum
  - Split the edid_hdmi_dc_modes in two for RGB444 and YUV444
  - Remove color_formats modifications from _parse_deep_color entirely
  - Fixed comment formatting
  - Fixed mode_valid that would always return true
  - Fixed max_tmds_clock handling

Changes from v1:
  - Fixed an EDID parsing error for YUV422
  - Fixed the scrambling setup when using a bpc > 8
  - Added some logging
  - Fixed some build-bot warnings
  - Fixed a number of HDMI specifications and EDID issues
  - Try to max out the bpc every time

Maxime Ripard (6):
  drm/vc4: hdmi: Move clock validation to its own function
  drm/vc4: hdmi: Move clock calculation into its own function
  drm/vc4: hdmi: Take the sink maximum TMDS clock into account
  drm/vc4: hdmi: Take bpp into account for the scrambler
  drm/vc4: hdmi: Always try to have the highest bpc
  drm/vc4: hdmi: Support HDMI YUV output

 drivers/gpu/drm/vc4/vc4_hdmi.c  | 401 +---
 drivers/gpu/drm/vc4/vc4_hdmi.h  |  21 ++
 drivers/gpu/drm/vc4/vc4_hdmi_regs.h |   6 +
 drivers/gpu/drm/vc4/vc4_regs.h  |  16 ++
 4 files changed, 409 insertions(+), 35 deletions(-)

-- 
2.34.1

[PATCH v5 1/6] drm/vc4: hdmi: Move clock validation to its own function

Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index e3121eb5f605..105911644b02 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1261,6 +1261,19 @@ static void vc4_hdmi_encoder_atomic_mode_set(struct 
drm_encoder *encoder,
mutex_unlock(&vc4_hdmi->mutex);
 }
 
+static enum drm_mode_status
+vc4_hdmi_encoder_clock_valid(const struct vc4_hdmi *vc4_hdmi,
+unsigned long long clock)
+{
+   if (clock > vc4_hdmi->variant->max_pixel_clock)
+   return MODE_CLOCK_HIGH;
+
+   if (vc4_hdmi->disable_4kp60 && clock > HDMI_14_MAX_TMDS_CLK)
+   return MODE_CLOCK_HIGH;
+
+   return MODE_OK;
+}
+
 #define WIFI_2_4GHz_CH1_MIN_FREQ   24ULL
 #define WIFI_2_4GHz_CH1_MAX_FREQ   242200ULL
 
@@ -1304,10 +1317,7 @@ static int vc4_hdmi_encoder_atomic_check(struct 
drm_encoder *encoder,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
pixel_rate = pixel_rate * 2;
 
-   if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
-   return -EINVAL;
-
-   if (vc4_hdmi->disable_4kp60 && (pixel_rate > HDMI_14_MAX_TMDS_CLK))
+   if (vc4_hdmi_encoder_clock_valid(vc4_hdmi, pixel_rate) != MODE_OK)
return -EINVAL;
 
vc4_state->pixel_rate = pixel_rate;
@@ -1326,13 +1336,7 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
 (mode->hsync_end % 2) || (mode->htotal % 2)))
return MODE_H_ILLEGAL;
 
-   if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
-   return MODE_CLOCK_HIGH;
-
-   if (vc4_hdmi->disable_4kp60 && vc4_hdmi_mode_needs_scrambling(mode))
-   return MODE_CLOCK_HIGH;
-
-   return MODE_OK;
+   return vc4_hdmi_encoder_clock_valid(vc4_hdmi, mode->clock * 1000);
 }
 
 static const struct drm_encoder_helper_funcs vc4_hdmi_encoder_helper_funcs = {
-- 
2.34.1

[PATCH v5 2/6] drm/vc4: hdmi: Move clock calculation into its own function

The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
 1 file changed, 34 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 105911644b02..a1fa37ad350d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1274,6 +1274,35 @@ vc4_hdmi_encoder_clock_valid(const struct vc4_hdmi 
*vc4_hdmi,
return MODE_OK;
 }
 
+static unsigned long long
+vc4_hdmi_encoder_compute_mode_clock(const struct drm_display_mode *mode,
+   unsigned int bpc)
+{
+   unsigned long long clock = mode->clock * 1000;
+
+   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+   clock = clock * 2;
+
+   return clock * bpc / 8;
+}
+
+static int
+vc4_hdmi_encoder_compute_clock(const struct vc4_hdmi *vc4_hdmi,
+  struct vc4_hdmi_connector_state *vc4_state,
+  const struct drm_display_mode *mode,
+  unsigned int bpc)
+{
+   unsigned long long clock;
+
+   clock = vc4_hdmi_encoder_compute_mode_clock(mode, bpc);
+   if (vc4_hdmi_encoder_clock_valid(vc4_hdmi, clock) != MODE_OK)
+   return -EINVAL;
+
+   vc4_state->pixel_rate = clock;
+
+   return 0;
+}
+
 #define WIFI_2_4GHz_CH1_MIN_FREQ   24ULL
 #define WIFI_2_4GHz_CH1_MAX_FREQ   242200ULL
 
@@ -1286,6 +1315,7 @@ static int vc4_hdmi_encoder_atomic_check(struct 
drm_encoder *encoder,
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
unsigned long long tmds_rate;
+   int ret;
 
if (vc4_hdmi->variant->unsupported_odd_h_timings &&
((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
@@ -1306,21 +1336,10 @@ static int vc4_hdmi_encoder_atomic_check(struct 
drm_encoder *encoder,
pixel_rate = mode->clock * 1000;
}
 
-   if (conn_state->max_bpc == 12) {
-   pixel_rate = pixel_rate * 150;
-   do_div(pixel_rate, 100);
-   } else if (conn_state->max_bpc == 10) {
-   pixel_rate = pixel_rate * 125;
-   do_div(pixel_rate, 100);
-   }
-
-   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
-   pixel_rate = pixel_rate * 2;
-
-   if (vc4_hdmi_encoder_clock_valid(vc4_hdmi, pixel_rate) != MODE_OK)
-   return -EINVAL;
-
-   vc4_state->pixel_rate = pixel_rate;
+   ret = vc4_hdmi_encoder_compute_clock(vc4_hdmi, vc4_state, mode,
+conn_state->max_bpc);
+   if (ret)
+   return ret;
 
return 0;
 }
-- 
2.34.1

[PATCH v5 5/6] drm/vc4: hdmi: Always try to have the highest bpc