Re: [PATCH v6 7/9] drm/msm/dpu: add support for virtual planes

[Abhinav Kumar]

On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:

On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:



On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:

Hi Abhinav,

On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar  wrote:




On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:

On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:



On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote:

Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features.  Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.

To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.

As the planes are attached to the CRTC and not the encoder, the SSPP
blocks are also allocated per CRTC ID (all other resources are currently
allocated per encoder ID). This also matches the hardware requirement,
where both rectangles of a single SSPP can only be used with the LM
pair.

Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.

Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  50 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  10 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   4 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 237 
++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  16 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c|  68 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|  27 
 7 files changed, 383 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 58595dcc3889..a7eea094aa14 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1166,6 +1166,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state 
*cstate)
  return false;
 }
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct 
drm_crtc_state *crtc_state)
+{
+   int total_planes = crtc->dev->mode_config.num_total_plane;
+   struct drm_atomic_state *state = crtc_state->state;
+   struct dpu_global_state *global_state;
+   struct drm_plane_state **states;
+   struct drm_plane *plane;
+   int ret;
+
+   global_state = dpu_kms_get_global_state(crtc_state->state);
+   if (IS_ERR(global_state))
+   return PTR_ERR(global_state);
+
+   dpu_rm_release_all_sspp(global_state, crtc);
+
+   if (!crtc_state->enable)
+   return 0;
+
+   states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
+   if (!states)
+   return -ENOMEM;
+
+   drm_atomic_crtc_state_for_each_plane(plane, crtc_state) {
+   struct drm_plane_state *plane_state =
+   drm_atomic_get_plane_state(state, plane);
+
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto done;
+   }
+
+   states[plane_state->normalized_zpos] = plane_state;
+   }
+
+   ret = dpu_assign_plane_resources(global_state, state, crtc, states, 
total_planes);
+
+done:
+   kfree(states);
+   return ret;
+
+   return 0;
+}
+
 static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
  struct drm_atomic_state *state)
 {
@@ -1181,6 +1224,13 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
  bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+   if (dpu_use_virtual_planes &&
+   (crtc_state->planes_changed || crtc_state->zpos_changed)) {
+   rc = dpu_crtc_reassign_planes(crtc, crtc_state);
+   if (rc < 0)
+   return rc;
+   }


planes_changed is set only for format changes . Will it cover all
needs_modeset cases?

OR do we also need to set planes_changed when
drm_atomic_crtc_needs_modeset()?

Unless I am missing something, I think we have to otherwise sspp
reallocation wont happen in modeset cases.


I was depending on the planes being included in the state by the client.
I don't think we really care about the modeset per se. We care about
plane size changes. And changing the size means that the plane is
included into the commit.



The global state mapping for SSPPs has to be cleared across mo

[PATCH v4 1/4] proc_pid_fdinfo.5: Reduce indent for most of the page

[Ian Rogers]

When /proc/pid/fdinfo was part of proc.5 man page the indentation made
sense. As a standalone man page the indentation doesn't need to be so
far over to the right. Remove the initial tagged pragraph, move the
"since Linux 2.6.22" to a new history subsection.

Suggested-by: G. Branden Robinson 
Signed-off-by: Ian Rogers 
---
v4. Move since to history from Alejandro Colomar's  review
comment.

---
 man/man5/proc_pid_fdinfo.5 | 51 +++---
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index 1e23bbe02..ad739bd84 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -8,8 +8,6 @@
 .SH NAME
 /proc/pid/fdinfo/ \- information about file descriptors
 .SH DESCRIPTION
-.TP
-.IR /proc/ pid /fdinfo/ " (since Linux 2.6.22)"
 This is a subdirectory containing one entry for each file which the
 process has open, named by its file descriptor.
 The files in this directory are readable only by the owner of the process.
@@ -17,9 +15,9 @@ The contents of each file can be read to obtain information
 about the corresponding file descriptor.
 The content depends on the type of file referred to by the
 corresponding file descriptor.
-.IP
+.P
 For regular files and directories, we see something like:
-.IP
+.P
 .in +4n
 .EX
 .RB "$" " cat /proc/12015/fdinfo/4"
@@ -28,7 +26,7 @@ flags:  01002002
 mnt_id: 21
 .EE
 .in
-.IP
+.P
 The fields are as follows:
 .RS
 .TP
@@ -51,7 +49,6 @@ this field incorrectly displayed the setting of
 at the time the file was opened,
 rather than the current setting of the close-on-exec flag.
 .TP
-.I
 .I mnt_id
 This field, present since Linux 3.15,
 .\" commit 49d063cb353265c3af701bab215ac438ca7df36d
@@ -59,13 +56,13 @@ is the ID of the mount containing this file.
 See the description of
 .IR /proc/ pid /mountinfo .
 .RE
-.IP
+.P
 For eventfd file descriptors (see
 .BR eventfd (2)),
 we see (since Linux 3.8)
 .\" commit cbac5542d48127b546a23d816380a7926eee1c25
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -74,16 +71,16 @@ mnt_id: 10
 eventfd\-count:   40
 .EE
 .in
-.IP
+.P
 .I eventfd\-count
 is the current value of the eventfd counter, in hexadecimal.
-.IP
+.P
 For epoll file descriptors (see
 .BR epoll (7)),
 we see (since Linux 3.8)
 .\" commit 138d22b58696c506799f8de759804083ff9effae
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -93,7 +90,7 @@ tfd:9 events:   19 data: 74253d250009
 tfd:7 events:   19 data: 74253d250007
 .EE
 .in
-.IP
+.P
 Each of the lines beginning
 .I tfd
 describes one of the file descriptors being monitored via
@@ -110,13 +107,13 @@ descriptor.
 The
 .I data
 field is the data value associated with this file descriptor.
-.IP
+.P
 For signalfd file descriptors (see
 .BR signalfd (2)),
 we see (since Linux 3.8)
 .\" commit 138d22b58696c506799f8de759804083ff9effae
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -125,7 +122,7 @@ mnt_id: 10
 sigmask:   0006
 .EE
 .in
-.IP
+.P
 .I sigmask
 is the hexadecimal mask of signals that are accepted via this
 signalfd file descriptor.
@@ -135,12 +132,12 @@ and
 .BR SIGQUIT ;
 see
 .BR signal (7).)
-.IP
+.P
 For inotify file descriptors (see
 .BR inotify (7)),
 we see (since Linux 3.8)
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -150,7 +147,7 @@ inotify wd:2 ino:7ef82a sdev:81 mask:800afff 
ignored_mask:0 fhandle\-bytes:8
 inotify wd:1 ino:192627 sdev:81 mask:800afff ignored_mask:0 
fhandle\-bytes:8 fhandle\-type:1 f_handle:27261900802dfd73
 .EE
 .in
-.IP
+.P
 Each of the lines beginning with "inotify" displays information about
 one file or directory that is being monitored.
 The fields in this line are as follows:
@@ -168,19 +165,19 @@ The ID of the device where the target file resides (in 
hexadecimal).
 .I mask
 The mask of events being monitored for the target file (in hexadecimal).
 .RE
-.IP
+.P
 If the kernel was built with exportfs support, the path to the target
 file is exposed as a file handle, via three hexadecimal fields:
 .IR fhandle\-bytes ,
 .IR fhandle\-type ,
 and
 .IR f_handle .
-.IP
+.P
 For fanotify file descriptors (see
 .BR fanotify (7)),
 we see (since Linux 3.8)
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -190,7 +187,7 @@ fanotify flags:0 event\-flags:88002
 fanotify ino:19264f sdev:81 mflags:0 mask:1 ignored_mask:0 
fhandle\-bytes:8 fhandle\-type:1 f_handle:4f261900a82dfd73
 .EE
 .in
-.IP
+.P
 The fourth line displays information defined when the fanotify group
 was created via
 .BR fanotify_init (2):
@@ -210,7 +207,7 @@ argument given to
 .BR fanotify_init (2)
 (expressed in hexadecimal).
 .RE
-.IP
+.P
 Each additional line shown in the file contains information
 about one of the marks in the fanotify group.
 Most of these fields are as for inotify, except:
@@ -228,16 +225,16 @@ The events mask for this mark
 The mask of events that are ignored f

Re: [PATCH v2] drm/xe: Fix build error for XE_IOCTL_DBG macro

[gyeyoung]

> >--- a/drivers/gpu/drm/xe/xe_macros.h
> >+++ b/drivers/gpu/drm/xe/xe_macros.h
> >@@ -11,8 +11,12 @@
> > #define XE_WARN_ON WARN_ON
> >
> > #define XE_IOCTL_DBG(xe, cond) \
> >-  ((cond) && (drm_dbg(&(xe)->drm, \
> >-  "Ioctl argument check failed at %s:%d: %s", \
> >-  __FILE__, __LINE__, #cond), 1))
> >+({ \
> >+  if ((cond)) \
> >+  drm_dbg(&(xe)->drm, \
> >+  "Ioctl argument check failed at %s:%d: %s", \
> >+  __FILE__, __LINE__, #cond); \
> >+  (cond); \
>
> there's a double cond evaluation here and given any expression can be
> given to XE_IOCTL_DBG(), this doens't look very safe. I think this would
> be safer as:
>
> #define XE_IOCTL_DBG(xe, cond) ({   \
>  int cond__ = !!(cond);  \
>  if (cond__) \
>  drm_dbg(&(xe)->drm, \
>  "Ioctl argument check failed at %s:%d: %s", \
>  __FILE__, __LINE__, #cond); \
>  cond__; \
> })
>
> as it then evaluates cond just once. Also the generated code seems to be
> sane compared to what we had before too.
>

Yes, if (cond) has operator like ++, it will be a bug. I miss that...
I will revise a patch again by referring to your review, thanks.

> And I also needed this to build-test:
>
> | diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> | index 08cfea04e22bd..82585d442f017 100644
> | --- a/drivers/gpu/drm/drm_print.c
> | +++ b/drivers/gpu/drm/drm_print.c
> | @@ -215,9 +215,8 @@ void __drm_printfn_dbg(struct drm_printer *p, struct 
> va_format *vaf)
> |  {
> | const struct drm_device *drm = p->arg;
> | const struct device *dev = drm ? drm->dev : NULL;
> | -   enum drm_debug_category category = p->category;
> |
> | -   if (!__drm_debug_enabled(category))
> | +   if (!__drm_debug_enabled(p->category))
> | return;
> |
> | __drm_dev_vprintk(dev, KERN_DEBUG, p->origin, p->prefix, vaf);
>
> as otherwise it complains category is unused.
>

I also submitted a seperate patch to fix '__drm_debug_enabled' macro,
from '#define __drm_debug_enabled(category)  true'
to '#define __drm_debug_enabled(category)  ({ void(category);  true; })'
This removes the build error caused by the unused 'category', too.

Anyway, it can be build. I tested both cases.
I realize now that these two patches should have been submitted as a
patch series
I'm sorry for my mistakes.

Thanks,
Gyeyoung Baek

> Lucas De Marchi

[PATCH bpf-next 0/2] drm, bpf: User drm_mm in bpf

[Alexei Starovoitov]

From: Alexei Starovoitov 

Hi DRM folks,

we'd like to start using drm_mm in bpf arena.
The drm_mm logic fits particularly well to bpf use case.
See individual patches.

objdump -h lib/drm_mm.o 
.text 12c7

So no vmlinux size concerns.

Alexei Starovoitov (2):
  drm, bpf: Move drm_mm.c to lib to be used by bpf arena
  bpf: Switch bpf arena to use drm_mm instead of maple_tree

 MAINTAINERS   |  1 +
 drivers/gpu/drm/Makefile  |  1 -
 drivers/gpu/drm/drm_print.c   | 39 ++
 kernel/bpf/arena.c| 67 ---
 lib/Makefile  |  2 +
 {drivers/gpu/drm => lib}/drm_mm.c | 40 +-
 6 files changed, 95 insertions(+), 55 deletions(-)
 rename {drivers/gpu/drm => lib}/drm_mm.c (96%)

-- 
2.43.5

[PATCH bpf-next 2/2] bpf: Switch bpf arena to use drm_mm instead of maple_tree

[Alexei Starovoitov]

From: Alexei Starovoitov 

bpf arena is moving towards non-sleepable allocations in tracing
context while maple_tree does kmalloc/kfree deep inside. Hence switch
bpf arena to drm_mm algorithm that works with externally provided
drm_mm_node-s. This patch kmalloc/kfree-s drm_mm_node-s, but the next
patch will switch to bpf_mem_alloc and preallocated drm_mm_node-s.

Signed-off-by: Alexei Starovoitov 
---
 kernel/bpf/arena.c | 67 +++---
 lib/Makefile   |  1 +
 2 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
index e52b3ad231b9..ef1de26020f2 100644
--- a/kernel/bpf/arena.c
+++ b/kernel/bpf/arena.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * bpf_arena is a sparsely populated shared memory region between bpf program 
and
@@ -45,7 +46,7 @@ struct bpf_arena {
u64 user_vm_start;
u64 user_vm_end;
struct vm_struct *kern_vm;
-   struct maple_tree mt;
+   struct drm_mm mm;
struct list_head vma_list;
struct mutex lock;
 };
@@ -132,7 +133,7 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr)
 
INIT_LIST_HEAD(&arena->vma_list);
bpf_map_init_from_attr(&arena->map, attr);
-   mt_init_flags(&arena->mt, MT_FLAGS_ALLOC_RANGE);
+   drm_mm_init(&arena->mm, 0, attr->max_entries);
mutex_init(&arena->lock);
 
return &arena->map;
@@ -164,6 +165,7 @@ static int existing_page_cb(pte_t *ptep, unsigned long 
addr, void *data)
 static void arena_map_free(struct bpf_map *map)
 {
struct bpf_arena *arena = container_of(map, struct bpf_arena, map);
+   struct drm_mm_node *node, *next;
 
/*
 * Check that user vma-s are not around when bpf map is freed.
@@ -183,7 +185,11 @@ static void arena_map_free(struct bpf_map *map)
apply_to_existing_page_range(&init_mm, 
bpf_arena_get_kern_vm_start(arena),
 KERN_VM_SZ - GUARD_SZ, existing_page_cb, 
NULL);
free_vm_area(arena->kern_vm);
-   mtree_destroy(&arena->mt);
+   drm_mm_for_each_node_safe(node, next, &arena->mm) {
+   drm_mm_remove_node(node);
+   kfree(node);
+   }
+   drm_mm_takedown(&arena->mm);
bpf_map_area_free(arena);
 }
 
@@ -257,6 +263,7 @@ static vm_fault_t arena_vm_fault(struct vm_fault *vmf)
 {
struct bpf_map *map = vmf->vma->vm_file->private_data;
struct bpf_arena *arena = container_of(map, struct bpf_arena, map);
+   struct drm_mm_node *node;
struct page *page;
long kbase, kaddr;
int ret;
@@ -274,20 +281,30 @@ static vm_fault_t arena_vm_fault(struct vm_fault *vmf)
/* User space requested to segfault when page is not allocated 
by bpf prog */
return VM_FAULT_SIGSEGV;
 
-   ret = mtree_insert(&arena->mt, vmf->pgoff, MT_ENTRY, GFP_KERNEL);
-   if (ret)
+   node = kzalloc(sizeof(*node), GFP_KERNEL);
+   if (!node)
+   return VM_FAULT_SIGSEGV;
+
+   node->start = vmf->pgoff;
+   node->size = 1;
+   ret = drm_mm_reserve_node(&arena->mm, node);
+   if (ret) {
+   kfree(node);
return VM_FAULT_SIGSEGV;
+   }
 
/* Account into memcg of the process that created bpf_arena */
ret = bpf_map_alloc_pages(map, GFP_KERNEL | __GFP_ZERO, NUMA_NO_NODE, 
1, &page);
if (ret) {
-   mtree_erase(&arena->mt, vmf->pgoff);
+   drm_mm_remove_node(node);
+   kfree(node);
return VM_FAULT_SIGSEGV;
}
 
ret = vm_area_map_pages(arena->kern_vm, kaddr, kaddr + PAGE_SIZE, 
&page);
if (ret) {
-   mtree_erase(&arena->mt, vmf->pgoff);
+   drm_mm_remove_node(node);
+   kfree(node);
__free_page(page);
return VM_FAULT_SIGSEGV;
}
@@ -420,6 +437,7 @@ static long arena_alloc_pages(struct bpf_arena *arena, long 
uaddr, long page_cnt
/* user_vm_end/start are fixed before bpf prog runs */
long page_cnt_max = (arena->user_vm_end - arena->user_vm_start) >> 
PAGE_SHIFT;
u64 kern_vm_start = bpf_arena_get_kern_vm_start(arena);
+   struct drm_mm_node *node;
struct page **pages;
long pgoff = 0;
u32 uaddr32;
@@ -442,14 +460,21 @@ static long arena_alloc_pages(struct bpf_arena *arena, 
long uaddr, long page_cnt
if (!pages)
return 0;
 
+   node = kzalloc(sizeof(*node), GFP_KERNEL);
+   if (!node) {
+   kvfree(pages);
+   return 0;
+   }
guard(mutex)(&arena->lock);
 
-   if (uaddr)
-   ret = mtree_insert_range(&arena->mt, pgoff, pgoff + page_cnt - 
1,
-MT_ENTRY, GFP_KERNEL);
-   else
-   ret = mtree_alloc_range(&arena->mt, &pgoff, MT_ENTRY,
-   page_cnt, 

[PATCH bpf-next 1/2] drm, bpf: Move drm_mm.c to lib to be used by bpf arena

[Alexei Starovoitov]

From: Alexei Starovoitov 

Move drm_mm.c to lib. The next commit will use drm_mm to manage
memory regions in bpf arena. Move drm_mm_print to
drivers/gpu/drm/drm_print.c, since it's not a core functionality
of drm_mm and it depeneds on drm_printer while drm_mm is
generic and usuable as-is by other subsystems.
Also add __maybe_unused to suppress compiler warnings.
Update MAINTAINERS file as well.

Signed-off-by: Alexei Starovoitov 
---
 MAINTAINERS   |  1 +
 drivers/gpu/drm/Makefile  |  1 -
 drivers/gpu/drm/drm_print.c   | 39 ++
 lib/Makefile  |  1 +
 {drivers/gpu/drm => lib}/drm_mm.c | 40 +--
 5 files changed, 42 insertions(+), 40 deletions(-)
 rename {drivers/gpu/drm => lib}/drm_mm.c (96%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6880a8fac74c..1bfaa335fae7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7504,6 +7504,7 @@ F:drivers/gpu/vga/
 F: include/drm/drm
 F: include/linux/vga*
 F: include/uapi/drm/
+F: lib/drm_mm.c
 X: drivers/gpu/drm/amd/
 X: drivers/gpu/drm/armada/
 X: drivers/gpu/drm/etnaviv/
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 784229d4504d..e35d5de2b9f0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -59,7 +59,6 @@ drm-y := \
drm_ioctl.o \
drm_lease.o \
drm_managed.o \
-   drm_mm.o \
drm_mode_config.o \
drm_mode_object.o \
drm_modes.o \
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 0081190201a7..2a8a5e0d691e 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * __drm_debug: Enable debug output.
@@ -267,6 +268,44 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
 }
 EXPORT_SYMBOL(drm_printf);
 
+static u64 drm_mm_dump_hole(struct drm_printer *p, const struct drm_mm_node 
*entry)
+{
+   u64 start, size;
+
+   size = entry->hole_size;
+   if (size) {
+   start = drm_mm_hole_node_start(entry);
+   drm_printf(p, "%#018llx-%#018llx: %llu: free\n",
+  start, start + size, size);
+   }
+
+   return size;
+}
+/**
+ * drm_mm_print - print allocator state
+ * @mm: drm_mm allocator to print
+ * @p: DRM printer to use
+ */
+void drm_mm_print(const struct drm_mm *mm, struct drm_printer *p)
+{
+   const struct drm_mm_node *entry;
+   u64 total_used = 0, total_free = 0, total = 0;
+
+   total_free += drm_mm_dump_hole(p, &mm->head_node);
+
+   drm_mm_for_each_node(entry, mm) {
+   drm_printf(p, "%#018llx-%#018llx: %llu: used\n", entry->start,
+  entry->start + entry->size, entry->size);
+   total_used += entry->size;
+   total_free += drm_mm_dump_hole(p, entry);
+   }
+   total = total_free + total_used;
+
+   drm_printf(p, "total: %llu, used %llu free %llu\n", total,
+  total_used, total_free);
+}
+EXPORT_SYMBOL(drm_mm_print);
+
 /**
  * drm_print_bits - print bits to a &drm_printer stream
  *
diff --git a/lib/Makefile b/lib/Makefile
index 773adf88af41..605aa25b71ab 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o
 obj-y += kstrtox.o
 obj-$(CONFIG_FIND_BIT_BENCHMARK) += find_bit_benchmark.o
 obj-$(CONFIG_TEST_BPF) += test_bpf.o
+obj-$(CONFIG_DRM) += drm_mm.o
 test_dhry-objs := dhry_1.o dhry_2.o dhry_run.o
 obj-$(CONFIG_TEST_DHRY) += test_dhry.o
 obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o
diff --git a/drivers/gpu/drm/drm_mm.c b/lib/drm_mm.c
similarity index 96%
rename from drivers/gpu/drm/drm_mm.c
rename to lib/drm_mm.c
index 5ace481c1901..45ea9864ed2e 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/lib/drm_mm.c
@@ -151,7 +151,7 @@ static void show_leaks(struct drm_mm *mm) { }
 
 INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
 u64, __subtree_last,
-START, LAST, static inline, drm_mm_interval_tree)
+START, LAST, static inline __maybe_unused, 
drm_mm_interval_tree)
 
 struct drm_mm_node *
 __drm_mm_interval_first(const struct drm_mm *mm, u64 start, u64 last)
@@ -966,41 +966,3 @@ void drm_mm_takedown(struct drm_mm *mm)
show_leaks(mm);
 }
 EXPORT_SYMBOL(drm_mm_takedown);
-
-static u64 drm_mm_dump_hole(struct drm_printer *p, const struct drm_mm_node 
*entry)
-{
-   u64 start, size;
-
-   size = entry->hole_size;
-   if (size) {
-   start = drm_mm_hole_node_start(entry);
-   drm_printf(p, "%#018llx-%#018llx: %llu: free\n",
-  start, start + size, size);
-   }
-
-   return size;
-}
-/**
- * drm_mm_print - print allocator state
- * @mm: drm_mm allocator to print
- * @p: DRM printer to use
- */
-void drm_mm_print(const struct drm_mm *mm, struct drm_printer *p)
-{
- 

[PATCH v3 1/4] proc_pid_fdinfo.5: Reduce indent for most of the page

[Ian Rogers]

When /proc/pid/fdinfo was part of proc.5 man page the indentation made
sense. As a standalone man page the indentation doesn't need to be so
far over to the right. Remove the initial tagged pragraph.

Suggested-by: G. Branden Robinson 
Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 52 ++
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index 1e23bbe02..87e6dbe56 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -8,18 +8,17 @@
 .SH NAME
 /proc/pid/fdinfo/ \- information about file descriptors
 .SH DESCRIPTION
-.TP
-.IR /proc/ pid /fdinfo/ " (since Linux 2.6.22)"
-This is a subdirectory containing one entry for each file which the
+Since Linux 2.6.22,
+this is a subdirectory containing one entry for each file which the
 process has open, named by its file descriptor.
 The files in this directory are readable only by the owner of the process.
 The contents of each file can be read to obtain information
 about the corresponding file descriptor.
 The content depends on the type of file referred to by the
 corresponding file descriptor.
-.IP
+.P
 For regular files and directories, we see something like:
-.IP
+.P
 .in +4n
 .EX
 .RB "$" " cat /proc/12015/fdinfo/4"
@@ -28,7 +27,7 @@ flags:  01002002
 mnt_id: 21
 .EE
 .in
-.IP
+.P
 The fields are as follows:
 .RS
 .TP
@@ -51,7 +50,6 @@ this field incorrectly displayed the setting of
 at the time the file was opened,
 rather than the current setting of the close-on-exec flag.
 .TP
-.I
 .I mnt_id
 This field, present since Linux 3.15,
 .\" commit 49d063cb353265c3af701bab215ac438ca7df36d
@@ -59,13 +57,13 @@ is the ID of the mount containing this file.
 See the description of
 .IR /proc/ pid /mountinfo .
 .RE
-.IP
+.P
 For eventfd file descriptors (see
 .BR eventfd (2)),
 we see (since Linux 3.8)
 .\" commit cbac5542d48127b546a23d816380a7926eee1c25
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -74,16 +72,16 @@ mnt_id: 10
 eventfd\-count:   40
 .EE
 .in
-.IP
+.P
 .I eventfd\-count
 is the current value of the eventfd counter, in hexadecimal.
-.IP
+.P
 For epoll file descriptors (see
 .BR epoll (7)),
 we see (since Linux 3.8)
 .\" commit 138d22b58696c506799f8de759804083ff9effae
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -93,7 +91,7 @@ tfd:9 events:   19 data: 74253d250009
 tfd:7 events:   19 data: 74253d250007
 .EE
 .in
-.IP
+.P
 Each of the lines beginning
 .I tfd
 describes one of the file descriptors being monitored via
@@ -110,13 +108,13 @@ descriptor.
 The
 .I data
 field is the data value associated with this file descriptor.
-.IP
+.P
 For signalfd file descriptors (see
 .BR signalfd (2)),
 we see (since Linux 3.8)
 .\" commit 138d22b58696c506799f8de759804083ff9effae
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -125,7 +123,7 @@ mnt_id: 10
 sigmask:   0006
 .EE
 .in
-.IP
+.P
 .I sigmask
 is the hexadecimal mask of signals that are accepted via this
 signalfd file descriptor.
@@ -135,12 +133,12 @@ and
 .BR SIGQUIT ;
 see
 .BR signal (7).)
-.IP
+.P
 For inotify file descriptors (see
 .BR inotify (7)),
 we see (since Linux 3.8)
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -150,7 +148,7 @@ inotify wd:2 ino:7ef82a sdev:81 mask:800afff 
ignored_mask:0 fhandle\-bytes:8
 inotify wd:1 ino:192627 sdev:81 mask:800afff ignored_mask:0 
fhandle\-bytes:8 fhandle\-type:1 f_handle:27261900802dfd73
 .EE
 .in
-.IP
+.P
 Each of the lines beginning with "inotify" displays information about
 one file or directory that is being monitored.
 The fields in this line are as follows:
@@ -168,19 +166,19 @@ The ID of the device where the target file resides (in 
hexadecimal).
 .I mask
 The mask of events being monitored for the target file (in hexadecimal).
 .RE
-.IP
+.P
 If the kernel was built with exportfs support, the path to the target
 file is exposed as a file handle, via three hexadecimal fields:
 .IR fhandle\-bytes ,
 .IR fhandle\-type ,
 and
 .IR f_handle .
-.IP
+.P
 For fanotify file descriptors (see
 .BR fanotify (7)),
 we see (since Linux 3.8)
 the following fields:
-.IP
+.P
 .in +4n
 .EX
 pos:   0
@@ -190,7 +188,7 @@ fanotify flags:0 event\-flags:88002
 fanotify ino:19264f sdev:81 mflags:0 mask:1 ignored_mask:0 
fhandle\-bytes:8 fhandle\-type:1 f_handle:4f261900a82dfd73
 .EE
 .in
-.IP
+.P
 The fourth line displays information defined when the fanotify group
 was created via
 .BR fanotify_init (2):
@@ -210,7 +208,7 @@ argument given to
 .BR fanotify_init (2)
 (expressed in hexadecimal).
 .RE
-.IP
+.P
 Each additional line shown in the file contains information
 about one of the marks in the fanotify group.
 Most of these fields are as for inotify, except:
@@ -228,16 +226,16 @@ The events mask for this mark
 The mask of events that are ignored for this mark
 (expressed in hexadecimal).
 .RE
-.IP
+.P
 For 

Re: [PATCH] drm/msm/hdmi: mark interlace_allowed as true

[Abhinav Kumar]

On 11/1/2024 3:26 PM, Dmitry Baryshkov wrote:

On Fri, 1 Nov 2024 at 23:41, Abhinav Kumar  wrote:




On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:

The MSM HDMI driver supports interlaced modes. Set the corresponding
flag to allow interlaced modes on the corresponding connectors.

Signed-off-by: Dmitry Baryshkov 
---
   drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 4a5b5112227f..643c152e6380 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -336,6 +336,7 @@ int msm_hdmi_bridge_init(struct hdmi *hdmi)
   bridge->funcs = &msm_hdmi_bridge_funcs;
   bridge->ddc = hdmi->i2c;
   bridge->type = DRM_MODE_CONNECTOR_HDMIA;
+ bridge->interlace_allowed = true;
   bridge->ops = DRM_BRIDGE_OP_HPD |
   DRM_BRIDGE_OP_DETECT |
   DRM_BRIDGE_OP_EDID;



I had quite a bit of discussion on this internally because this spans
quite a few generations of chipsets.

On very old hardware, even before msm8996, there was dedicated hardware
de-interlacer. But even on msm8996 or other HDMI supported chipsets
where the handling of if (mode->flags & DRM_MODE_FLAG_INTERLACE) is
present, these were because its carry forward of older interface code.

The way we handle interlaced formats today, is software needs to handle
the part of dividing height / 2 and width * 2 and adjust the source crop
if necessary. This part has moved to userspace for recent chips.

Othwerise, we will need to add this part in the dpu driver to adjust
this. I am not seeing this part there yet. So may I know how you
validated this change? Something similar to :

https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/LE.UM.1.3.r3.25/drivers/gpu/drm/msm/sde/sde_plane.c#L1340

If we add this part first to dpu code, then we can mark interlace_allowed.


I think you are mixing the interlaced formats and interlaced output.
The code that you have pointed to is related to hardware deinterlacing
- in other words taking the interlaced framebuffer and outputting it
to the progressive display.

The interlace_allowed flag controls a different feature - filtering of
the internalced modes (aka 576i, 1080i, etc). In this case we are
using progressive frames, but the HDMI outputs a picture as two
separate fields. I have validated this by outputting image (modetest)
to the external HDMI display on IFC6410 and on DB820c boards.



Yes I did think that this was to show interlaced content but that being 
said, I traced through the HDMI code a bit, it does have support for 
changing the HDMI timing but without the support of dpu, progressive 
content really cannot be converted to interlaced. So I think the HDMI 
pieces there were supposed to go along with the rest of the dpu pipeline 
that is the entire pipeline shows out interlaced content. But dpu 
support for giving out interlaced content is not there, so this hdmi 
piece by itself is not complete enough to mark interlace_allowed as true.

[PATCH v3] drm/xe: Fix build error for XE_IOCTL_DBG macro

[Gyeyoung Baek]

if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement.
so in the previous code, there are the following build errors.

include/linux/dynamic_debug.h:221:58: error: expected expression before ‘do’
  221 | #define __dynamic_func_call_cls(id, cls, fmt, func, ...) do {   \
  |  ^~
include/linux/dynamic_debug.h:248:9: note: in expansion of macro 
‘__dynamic_func_call_cls’
  248 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, 
##__VA_ARGS__)
  | ^~~
include/drm/drm_print.h:425:9: note: in expansion of macro 
‘_dynamic_func_call_cls’
  425 | _dynamic_func_call_cls(cat, fmt, __drm_dev_dbg, \
  | ^~
include/drm/drm_print.h:504:9: note: in expansion of macro ‘drm_dev_dbg’
  504 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
  | ^~~
include/drm/drm_print.h:522:33: note: in expansion of macro ‘drm_dbg_driver’
  522 | #define drm_dbg(drm, fmt, ...)  drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
  | ^~
drivers/gpu/drm/xe/xe_macros.h:14:21: note: in expansion of macro ‘drm_dbg’
   14 | ((cond) && (drm_dbg(&(xe)->drm, \
  | ^~~
drivers/gpu/drm/xe/xe_bo.c:2029:13: note: in expansion of macro ‘XE_IOCTL_DBG’
 2029 | if (XE_IOCTL_DBG(xe, !gem_obj))

the problem is that,
XE_IOCTL_DBG uses this function for conditional expr.

so I fix the expr to be compatible with the do while statement,
by referring to "https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html";.

v2: I modified this to print when only cond is true.
v3: Modify to evaluate cond only once.

Signed-off-by: Gyeyoung Baek 
---
 drivers/gpu/drm/xe/xe_macros.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_macros.h b/drivers/gpu/drm/xe/xe_macros.h
index daf56c846d03..b956acbe4000 100644
--- a/drivers/gpu/drm/xe/xe_macros.h
+++ b/drivers/gpu/drm/xe/xe_macros.h
@@ -10,9 +10,11 @@
 
 #define XE_WARN_ON WARN_ON
 
-#define XE_IOCTL_DBG(xe, cond) \
-   ((cond) && (drm_dbg(&(xe)->drm, \
-   "Ioctl argument check failed at %s:%d: %s", \
-   __FILE__, __LINE__, #cond), 1))
-
-#endif
+#define XE_IOCTL_DBG(xe, cond) ({  \
+   int cond__ = !!(cond);  \
+   if (cond__) \
+   drm_dbg(&(xe)->drm, \
+   "Ioctl argument check failed at %s:%d: %s", \
+   __FILE__, __LINE__, #cond); \
+   cond__; \
+})
-- 
2.34.1

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

[Alejandro Colomar]

On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote:
> When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> sense. As a standalone man page the indentation doesn't need to be so
> far over to the right. Remove the initial tagged pragraph and move the
> styling to the initial summary description.
> 
> Suggested-by: G. Branden Robinson 
> Signed-off-by: Ian Rogers 
> ---
>  man/man5/proc_pid_fdinfo.5 | 66 ++
>  1 file changed, 32 insertions(+), 34 deletions(-)
> 
> diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
> index 1e23bbe02..8678caf4a 100644
> --- a/man/man5/proc_pid_fdinfo.5
> +++ b/man/man5/proc_pid_fdinfo.5
> @@ -6,20 +6,19 @@
>  .\"
>  .TH proc_pid_fdinfo 5 (date) "Linux man-pages (unreleased)"
>  .SH NAME
> -/proc/pid/fdinfo/ \- information about file descriptors
> +.IR /proc/ pid /fdinfo " \- information about file descriptors"

I wouldn't add formatting here for now.  That's something I prefer to be
cautious about, and if we do it, we should do it in a separate commit.

>  .SH DESCRIPTION
> -.TP
> -.IR /proc/ pid /fdinfo/ " (since Linux 2.6.22)"
> -This is a subdirectory containing one entry for each file which the
> -process has open, named by its file descriptor.
> -The files in this directory are readable only by the owner of the process.
> -The contents of each file can be read to obtain information
> -about the corresponding file descriptor.
> -The content depends on the type of file referred to by the
> -corresponding file descriptor.
> -.IP
> +Since Linux 2.6.22,

You could move this information to a HISTORY section.

> +this subdirectory contains one entry for each file that process
> +.I pid
> +has open, named by its file descriptor.  The files in this directory

Please don't reflow existing text.  Please read about semantic newlines
in man-pages(7):

$ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
   Use semantic newlines
 In  the  source of a manual page, new sentences should be started
 on new lines, long sentences should be split into lines at clause
 breaks (commas, semicolons, colons, and so on), and long  clauses
 should be split at phrase boundaries.  This convention, sometimes
 known  as  "semantic newlines", makes it easier to see the effect
 of patches, which often operate at the level of  individual  sen‐
 tences, clauses, or phrases.

Have a lovely day!
Alex

> +are readable only by the owner of the process.  The contents of each
> +file can be read to obtain information about the corresponding file
> +descriptor.  The content depends on the type of file referred to by
> +the corresponding file descriptor.
> +.P
>  For regular files and directories, we see something like:
> -.IP
> +.P
>  .in +4n
>  .EX
>  .RB "$" " cat /proc/12015/fdinfo/4"
> @@ -28,7 +27,7 @@ flags:  01002002
>  mnt_id: 21
>  .EE
>  .in
> -.IP
> +.P
>  The fields are as follows:
>  .RS
>  .TP
> @@ -51,7 +50,6 @@ this field incorrectly displayed the setting of
>  at the time the file was opened,
>  rather than the current setting of the close-on-exec flag.
>  .TP
> -.I
>  .I mnt_id
>  This field, present since Linux 3.15,
>  .\" commit 49d063cb353265c3af701bab215ac438ca7df36d
> @@ -59,13 +57,13 @@ is the ID of the mount containing this file.
>  See the description of
>  .IR /proc/ pid /mountinfo .
>  .RE
> -.IP
> +.P
>  For eventfd file descriptors (see
>  .BR eventfd (2)),
>  we see (since Linux 3.8)
>  .\" commit cbac5542d48127b546a23d816380a7926eee1c25
>  the following fields:
> -.IP
> +.P
>  .in +4n
>  .EX
>  pos: 0
> @@ -74,16 +72,16 @@ mnt_id:   10
>  eventfd\-count:   40
>  .EE
>  .in
> -.IP
> +.P
>  .I eventfd\-count
>  is the current value of the eventfd counter, in hexadecimal.
> -.IP
> +.P
>  For epoll file descriptors (see
>  .BR epoll (7)),
>  we see (since Linux 3.8)
>  .\" commit 138d22b58696c506799f8de759804083ff9effae
>  the following fields:
> -.IP
> +.P
>  .in +4n
>  .EX
>  pos: 0
> @@ -93,7 +91,7 @@ tfd:9 events:   19 data: 74253d250009
>  tfd:7 events:   19 data: 74253d250007
>  .EE
>  .in
> -.IP
> +.P
>  Each of the lines beginning
>  .I tfd
>  describes one of the file descriptors being monitored via
> @@ -110,13 +108,13 @@ descriptor.
>  The
>  .I data
>  field is the data value associated with this file descriptor.
> -.IP
> +.P
>  For signalfd file descriptors (see
>  .BR signalfd (2)),
>  we see (since Linux 3.8)
>  .\" commit 138d22b58696c506799f8de759804083ff9effae
>  the following fields:
> -.IP
> +.P
>  .in +4n
>  .EX
>  pos: 0
> @@ -125,7 +123,7 @@ mnt_id:   10
>  sigmask: 0006
>  .EE
>  .in
> -.IP
> +.P
>  .I sigmask
>  is the hexadecimal mask of signals that are accepted via this
>  signalfd file descriptor.
> @@ -135,12 +133,12 @@ and
>  .BR SIGQUIT ;
>  see
>  .BR signal (7).)
> -.IP
> +.P
>  For inotify file descriptors (see
>  .BR inotify (7)),
>  we see (since Linux 3.8)
>  the fo

[PATCH] drm/vc4: cast calculation to __u64 in vc4_dumb_fixup_args()

[Gax-c]

From: Zichen Xie 

Like commit b0b0d811eac6 ("drm/mediatek: Fix coverity issue with
unintentional integer overflow"), directly multiply args->pitch and
args->height may lead to integer overflow. Add a cast to avoid it.

Fixes: 3d7637423be8 ("drm/vc4: bo: Split out Dumb buffers fixup")
Signed-off-by: Zichen Xie 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index c133e96b8aca..ac02afc3acc5 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -69,8 +69,8 @@ int vc4_dumb_fixup_args(struct drm_mode_create_dumb *args)
if (args->pitch < min_pitch)
args->pitch = min_pitch;
 
-   if (args->size < args->pitch * args->height)
-   args->size = args->pitch * args->height;
+   if (args->size < (__u64)args->pitch * args->height)
+   args->size = (__u64)args->pitch * args->height;
 
return 0;
 }
-- 
2.25.1

Re: [PATCH v3 1/2] arm64: dts: qcom: sa8775p: Add gpu and gmu nodes

[Akhil P Oommen]

On 11/1/2024 2:00 AM, Konrad Dybcio wrote:
> On 30.10.2024 8:02 AM, Akhil P Oommen wrote:
>> From: Puranam V G Tejaswi 
>>
>> Add gpu and gmu nodes for sa8775p chipset. As of now all
>> SKUs have the same GPU fmax, so there is no requirement of
>> speed bin support.
>>
>> Signed-off-by: Puranam V G Tejaswi 
>> Signed-off-by: Akhil P Oommen 
>> Reviewed-by: Dmitry Baryshkov 
>> ---
>>  arch/arm64/boot/dts/qcom/sa8775p.dtsi | 94 
>> +++
>>  1 file changed, 94 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi 
>> b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
>> index e8dbc8d820a6..c6cb18193787 100644
>> --- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
>> @@ -3072,6 +3072,100 @@ tcsr_mutex: hwlock@1f4 {
>>  #hwlock-cells = <1>;
>>  };
>>  
>> +gpu: gpu@3d0 {
>> +compatible = "qcom,adreno-663.0", "qcom,adreno";
> 
> Is the patchlevel zero for this SKU?

Yes. There is only a single revision implemented downstream.


> 
> 
>> +reg = <0x0 0x03d0 0x0 0x4>,
>> +  <0x0 0x03d9e000 0x0 0x1000>,
>> +  <0x0 0x03d61000 0x0 0x800>;
>> +reg-names = "kgsl_3d0_reg_memory",
>> +"cx_mem",
>> +"cx_dbgc";
>> +interrupts = ;
>> +iommus = <&adreno_smmu 0 0xc00>,
>> + <&adreno_smmu 1 0xc00>;
>> +operating-points-v2 = <&gpu_opp_table>;
>> +qcom,gmu = <&gmu>;
>> +interconnects = <&gem_noc MASTER_GFX3D 
>> QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 
>> QCOM_ICC_TAG_ALWAYS>;
>> +interconnect-names = "gfx-mem";
>> +#cooling-cells = <2>;
> 
> You might want to hook this up to a thermal-zone right away

I am checking with our Thermal team on this. Will get back shortly.

-Akhil.

> 
> Konrad

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

[Ian Rogers]

On Fri, Nov 1, 2024 at 6:24 AM Alejandro Colomar  wrote:
>
> On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote:
> > When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> > sense. As a standalone man page the indentation doesn't need to be so
> > far over to the right. Remove the initial tagged pragraph and move the
> > styling to the initial summary description.
> >
> > Suggested-by: G. Branden Robinson 
> > Signed-off-by: Ian Rogers 
> > ---
> >  man/man5/proc_pid_fdinfo.5 | 66 ++
> >  1 file changed, 32 insertions(+), 34 deletions(-)
> >
> > diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
> > index 1e23bbe02..8678caf4a 100644
> > --- a/man/man5/proc_pid_fdinfo.5
> > +++ b/man/man5/proc_pid_fdinfo.5
> > @@ -6,20 +6,19 @@
> >  .\"
> >  .TH proc_pid_fdinfo 5 (date) "Linux man-pages (unreleased)"
> >  .SH NAME
> > -/proc/pid/fdinfo/ \- information about file descriptors
> > +.IR /proc/ pid /fdinfo " \- information about file descriptors"
>
> I wouldn't add formatting here for now.  That's something I prefer to be
> cautious about, and if we do it, we should do it in a separate commit.

I'll move it to a separate patch. Is the caution due to a lack of test
infrastructure? That could be something to get resolved, perhaps
through Google summer-of-code and the like.

> >  .SH DESCRIPTION
> > -.TP
> > -.IR /proc/ pid /fdinfo/ " (since Linux 2.6.22)"
> > -This is a subdirectory containing one entry for each file which the
> > -process has open, named by its file descriptor.
> > -The files in this directory are readable only by the owner of the process.
> > -The contents of each file can be read to obtain information
> > -about the corresponding file descriptor.
> > -The content depends on the type of file referred to by the
> > -corresponding file descriptor.
> > -.IP
> > +Since Linux 2.6.22,
>
> You could move this information to a HISTORY section.

Sure, tbh I'm not sure anybody cares about this information and it
could be as well to delete it. Sorry people running 17 year old
kernels. For now I'll try to leave it unchanged.

> > +this subdirectory contains one entry for each file that process
> > +.I pid
> > +has open, named by its file descriptor.  The files in this directory
>
> Please don't reflow existing text.  Please read about semantic newlines
> in man-pages(7):
>
> $ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
>Use semantic newlines
>  In  the  source of a manual page, new sentences should be started
>  on new lines, long sentences should be split into lines at clause
>  breaks (commas, semicolons, colons, and so on), and long  clauses
>  should be split at phrase boundaries.  This convention, sometimes
>  known  as  "semantic newlines", makes it easier to see the effect
>  of patches, which often operate at the level of  individual  sen‐
>  tences, clauses, or phrases.

I'll update for v3 but I'm reminded of `git diff --word-diff=color` so
perhaps this recommendation is outdated.

Thanks,
Ian

> Have a lovely day!
> Alex
>
> > +are readable only by the owner of the process.  The contents of each
> > +file can be read to obtain information about the corresponding file
> > +descriptor.  The content depends on the type of file referred to by
> > +the corresponding file descriptor.
> > +.P
> >  For regular files and directories, we see something like:
> > -.IP
> > +.P
> >  .in +4n
> >  .EX
> >  .RB "$" " cat /proc/12015/fdinfo/4"
> > @@ -28,7 +27,7 @@ flags:  01002002
> >  mnt_id: 21
> >  .EE
> >  .in
> > -.IP
> > +.P
> >  The fields are as follows:
> >  .RS
> >  .TP
> > @@ -51,7 +50,6 @@ this field incorrectly displayed the setting of
> >  at the time the file was opened,
> >  rather than the current setting of the close-on-exec flag.
> >  .TP
> > -.I
> >  .I mnt_id
> >  This field, present since Linux 3.15,
> >  .\" commit 49d063cb353265c3af701bab215ac438ca7df36d
> > @@ -59,13 +57,13 @@ is the ID of the mount containing this file.
> >  See the description of
> >  .IR /proc/ pid /mountinfo .
> >  .RE
> > -.IP
> > +.P
> >  For eventfd file descriptors (see
> >  .BR eventfd (2)),
> >  we see (since Linux 3.8)
> >  .\" commit cbac5542d48127b546a23d816380a7926eee1c25
> >  the following fields:
> > -.IP
> > +.P
> >  .in +4n
> >  .EX
> >  pos: 0
> > @@ -74,16 +72,16 @@ mnt_id:   10
> >  eventfd\-count:   40
> >  .EE
> >  .in
> > -.IP
> > +.P
> >  .I eventfd\-count
> >  is the current value of the eventfd counter, in hexadecimal.
> > -.IP
> > +.P
> >  For epoll file descriptors (see
> >  .BR epoll (7)),
> >  we see (since Linux 3.8)
> >  .\" commit 138d22b58696c506799f8de759804083ff9effae
> >  the following fields:
> > -.IP
> > +.P
> >  .in +4n
> >  .EX
> >  pos: 0
> > @@ -93,7 +91,7 @@ tfd:9 events:   19 data: 74253d250009
> >  tfd:7 events:   19 data: 74253d250007
> >  .EE
> >  .in
> > -.IP
> > +.P
> >  Each of the lines beginni

[PATCH RESEND v9 2/2] drm/amdgpu: Enable async flip on overlay planes

[André Almeida]

amdgpu can handle async flips on overlay planes, so allow it for atomic
async checks.

Signed-off-by: André Almeida 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 
495e3cd70426db0182cb2811bc6d5d09f52f8a4b..4c6aed5ca777d76245f5f2865046f0f598be342a
 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1266,8 +1266,7 @@ static int amdgpu_dm_plane_atomic_async_check(struct 
drm_plane *plane,
struct drm_plane_state *new_plane_state;
struct dm_crtc_state *dm_new_crtc_state;
 
-   /* Only support async updates on cursor planes. */
-   if (plane->type != DRM_PLANE_TYPE_CURSOR)
+   if (plane->type != DRM_PLANE_TYPE_CURSOR && plane->type != 
DRM_PLANE_TYPE_OVERLAY)
return -EINVAL;
 
new_plane_state = drm_atomic_get_new_plane_state(state, plane);

-- 
2.47.0

[PATCH RESEND v9 1/2] drm/atomic: Let drivers decide which planes to async flip

[André Almeida]

Currently, DRM atomic uAPI allows only primary planes to be flipped
asynchronously. However, each driver might be able to perform async
flips in other different plane types. To enable drivers to set their own
restrictions on which type of plane they can or cannot flip, use the
existing atomic_async_check() from struct drm_plane_helper_funcs to
enhance this flexibility, thus allowing different plane types to be able
to do async flips as well.

In order to prevent regressions and such, we keep the current policy: we
skip the driver check for the primary plane, because it is always
allowed to do async flips on it.

Signed-off-by: André Almeida 
---
Changes from v8:
- Rebased on top of 6.12-rc1
---
 drivers/gpu/drm/drm_atomic_uapi.c | 39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 
370dc676e3aa543c9827b50df20df78f02b738c9..a0120df4b63e6b3419b53eb3d3673882559501c6
 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -27,8 +27,9 @@
  * Daniel Vetter 
  */
 
-#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1063,6 +1064,7 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
struct drm_plane *plane = obj_to_plane(obj);
struct drm_plane_state *plane_state;
struct drm_mode_config *config = &plane->dev->mode_config;
+   const struct drm_plane_helper_funcs *plane_funcs = 
plane->helper_private;
 
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
@@ -1070,15 +1072,32 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
-   if (async_flip &&
-   (plane_state->plane->type != DRM_PLANE_TYPE_PRIMARY ||
-(prop != config->prop_fb_id &&
- prop != config->prop_in_fence_fd &&
- prop != config->prop_fb_damage_clips))) {
-   ret = drm_atomic_plane_get_property(plane, plane_state,
-   prop, &old_val);
-   ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);
-   break;
+   if (async_flip) {
+   /* check if the prop does a nop change */
+   if ((plane_state->plane->type != 
DRM_PLANE_TYPE_PRIMARY) ||
+   (prop != config->prop_fb_id &&
+prop != config->prop_in_fence_fd &&
+prop != config->prop_fb_damage_clips)) {
+   ret = drm_atomic_plane_get_property(plane, 
plane_state,
+   prop, 
&old_val);
+   ret = drm_atomic_check_prop_changes(ret, 
old_val, prop_value, prop);
+   break;
+   }
+
+   /* ask the driver if this non-primary plane is 
supported */
+   if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
+   ret = -EINVAL;
+
+   if (plane_funcs && 
plane_funcs->atomic_async_check)
+   ret = 
plane_funcs->atomic_async_check(plane, state);
+
+   if (ret) {
+   drm_dbg_atomic(prop->dev,
+  "[PLANE:%d] does not 
support async flips\n",
+  obj->id);
+   break;
+   }
+   }
}
 
ret = drm_atomic_plane_set_property(plane,

-- 
2.47.0

[PATCH RESEND v9 0/2] drm/atomic: Ease async flip restrictions

[André Almeida]

Hi,

As per my previous patchsets, the goal of this work is to find a nice way to
allow amdgpu to perform async page flips in the overlay plane as well, not
only on the primary one. Currently, when using the atomic uAPI, this is the only
type of plane allowed to do async flips, and every driver accepts it.

In my last version, I had created a static field `bool async_flip` for
drm_planes. When creating new planes, drivers could tell if such plane was
allowed or not to do async flips. This would be latter checked on the atomic
uAPI whenever the DRM_MODE_PAGE_FLIP_ASYNC was present.

However, Dmitry Baryshkov raised a valid point about getting confused with the 
existing atomic_async_check() code, giving that is a function to do basically
what I want: to let drivers tell DRM whether a giving plane can do async flips
or not. It turns out atomic_async_check() is implemented by drivers to deal with
the legacy cursor update, so it's not wired with the atomic uAPI because is
something that precedes such API.

So my new proposal is to just reuse this same function in the atomic uAPI path.
The plane restrictions defined at atomic_async_check() should work in this
codepath as well. And I will be able to allow overlays planes by modifying
amdgpu_dm_plane_atomic_async_check(), and anyone else have a proper place to
play with async plane restrictions as well.

One note is that currently we always allow async flips for primary planes,
regardless of the drivers, but not every atomic_async_check() implementation
allows primary planes (because they were writing targeting cursor planes
anyway...). To avoid regressions, my patch only calls atomic_async_check() for
non primary planes, and always allows primary ones.

Thoughts?

Changelog
 v8: 
https://lore.kernel.org/lkml/20240806135300.114469-1-andrealm...@igalia.com/
 - Rebased on top of 6.12-rc1 (drm/drm-next)

Changelog
 v7: 
https://lore.kernel.org/dri-devel/20240618030024.500532-1-andrealm...@igalia.com/
 - Complete rewrite

---
Changes in v10:
- EDITME: describe what is new in this series revision.
- EDITME: use bulletpoints and terse descriptions.
- Link to v9: 
https://lore.kernel.org/r/20241002-tonyk-async_flip-v9-0-453b1b897...@igalia.com

---
André Almeida (2):
  drm/atomic: Let drivers decide which planes to async flip
  drm/amdgpu: Enable async flip on overlay planes

 .../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c|  3 +-
 drivers/gpu/drm/drm_atomic_uapi.c  | 39 --
 2 files changed, 30 insertions(+), 12 deletions(-)
---
base-commit: 81983758430957d9a5cbfe324fd70cf63e7e
change-id: 20241002-tonyk-async_flip-828cfe9cf3ca

Best regards,
-- 
André Almeida 

Re: [PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior

[Jason Gunthorpe]

On Fri, Nov 01, 2024 at 11:58:29AM +, Will Deacon wrote:
> On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> > Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> > arm_lpae is unique in how it handles partial unmap of large IOPTEs.
> > 
> > All other drivers will unmap the large IOPTE and return it's length.  For
> > example if a 2M IOPTE is present and the first 4K is requested to be
> > unmapped then unmap will remove the whole 2M and report 2M as the result.
> > 
> > arm_lpae instead replaces the IOPTE with a table of smaller IOPTEs, unmaps
> > the 4K and returns 4k. This is actually an illegal/non-hitless operation
> > on at least SMMUv3 because of the BBM level 0 rules.
> > 
> > Long ago VFIO could trigger a path like this, today I know of no user of
> > this functionality.
> > 
> > Given it doesn't work fully correctly on SMMUv3 and would create
> > portability problems if any user depends on it, remove the unique support
> > in arm_lpae and align with the expected iommu interface.
> > 
> > Outside the iommu users, this will potentially effect io_pgtable users of
> > ARM_32_LPAE_S1, ARM_32_LPAE_S2, ARM_64_LPAE_S1, ARM_64_LPAE_S2, and
> > ARM_MALI_LPAE formats.
> > 
> > Cc: Boris Brezillon 
> > Cc: Steven Price 
> > Cc: Liviu Dudau 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Jason Gunthorpe 
> > ---
> >  drivers/iommu/io-pgtable-arm.c | 72 +++---
> >  1 file changed, 6 insertions(+), 66 deletions(-)
> > 
> > I don't know anything in the iommu space that needs this, and this is the 
> > only
> > page table implementation in iommu that does it.
> 
> I think the v7s code does it as well, so please can you apply the same
> treatment to arm_v7s_split_blk_unmap()?

I have that patch written, I'm not as confident in it as it is much
more complex, but it passes my simple tests.

However, if we make it fail and WARN_ON that should simplify it alot.

> > @@ -678,12 +618,12 @@ static size_t __arm_lpae_unmap(struct 
> > arm_lpae_io_pgtable *data,
> >  
> > return i * size;
> > } else if (iopte_leaf(pte, lvl, iop->fmt)) {
> > -   /*
> > -* Insert a table at the next level to map the old region,
> > -* minus the part we want to unmap
> > -*/
> > -   return arm_lpae_split_blk_unmap(data, gather, iova, size, pte,
> > -   lvl + 1, ptep, pgcount);
> > +   /* Unmap the entire large IOPTE and return its size */
> > +   size = ARM_LPAE_BLOCK_SIZE(lvl, data);
> 
> If I understand your other message correctly, we shouldn't actually get
> into this situation any more, right? In which case, can we WARN_ONCE()
> and return 0 instead? Over-unmapping is filthy!

VFIO won't do it (except on AMD), I have not tried to figure out if
something else might depend on it over-unmapping.

So, OK, let's try the WARN_ON and it is very easy to put the above
hunk back as a fixup if someone hits it.

Jason

[PATCH v5 0/5] mm: add more kernel parameters to control mTHP

[Maíra Canal]

This series introduces four patches related to the kernel parameters
controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
in the file `mm/huge_memory.c`.

The first patch is a straightforward documentation update, correcting
the format of the kernel parameter ``thp_anon=``.

The second, third, and fourth patches focus on controlling THP support for
shmem via the kernel command line. The second patch introduces a parameter to
control the global default huge page allocation policy for the internal
shmem mount. The third patch moves a piece of code to a shared header to ease
the implementation of the fourth patch. Finally, the fourth patch implements
a parameter similar to ``thp_anon=``, but for shmem.

The goal of these changes is to simplify the configuration of systems that
rely on mTHP support for shmem. For instance, a platform with a GPU that
benefits from huge pages may want to enable huge pages for shmem. Having
these kernel parameters streamlines the configuration process and ensures
consistency across setups.

Let me know your thoughts.

v1 -> v2: 
https://lore.kernel.org/linux-mm/20241027175743.1056710-1-mca...@igalia.com/T/

* [1/3] s/fix the format/fix the doc in the commit's subject (Barry Song & 
David Hildenbrand)
* [1/3] Add Barry's A-b to PATCH 1/3 (Barry Song)
* [1/3] s/64KB/64K (David Hildenbrand)
* [1/3] Add David's A-b to PATCH 1/3 (David Hildenbrand)
* [2/3] Create the function `shmem_valid_huge()` to reduce code-duplication 
(Baolin Wang)
* [3/4] New PATCH: generalize the function `setup_thp_anon()` and add it to 
common file
* [4/4] Fix typo in the documentation: s/shmem_anon/thp_shmem (Barry Song)
* [4/4] Reduce code-duplication (Barry Song)

v2 -> v3: 
https://lore.kernel.org/linux-mm/20241029002324.1062723-1-mca...@igalia.com/T/

* [2/4] Apply Wang's suggestion (Baolin Wang)
* [3/4] Delete PATCH 3/4 from v2 and implement ``thp_shmem=`` just like in v1 
(Barry Song)
* [4/4] New PATCH: "mm: huge_memory: Use strscpy() instead of strcpy()"

v3 -> v4: 
https://lore.kernel.org/linux-mm/20241030130308.1066299-1-mca...@igalia.com/T/

* [2/5] Improve commit message by including details about the use of the kernel 
parameter (Andrew Morton)
* [2/5] Add Baolin's R-b to PATCH 2/5 (Baolin Wang)
* [2/5] Add David's R-b to PATCH 2/5 (David Hildenbrand)
* [3/5] New PATCH: "mm: move ``get_order_from_str()`` to internal.h" (Barry 
Song & David Hildenbrand)
* [4/5] Improve commit message by including details about the use of the kernel 
parameter (Andrew Morton)
* [5/5] Add Lance's R-b to PATCH 5/5 (Lance Yang)

v4 -> v5: 
https://lore.kernel.org/linux-mm/20241101164313.1073238-2-mca...@igalia.com/T/

* [3/5] Don't use personal e-mail address (Maíra Canal)

Best Regards,
- Maíra

Maíra Canal (5):
  mm: fix docs for the kernel parameter ``thp_anon=``
  mm: shmem: control THP support through the kernel command line
  mm: move ``get_order_from_str()`` to internal.h
  mm: shmem: override mTHP shmem default with a kernel parameter
  mm: huge_memory: Use strscpy() instead of strcpy()

 .../admin-guide/kernel-parameters.txt |  19 +-
 Documentation/admin-guide/mm/transhuge.rst|  25 ++-
 mm/huge_memory.c  |  42 ++---
 mm/internal.h |  22 +++
 mm/shmem.c| 177 +++---
 5 files changed, 234 insertions(+), 51 deletions(-)

-- 
2.46.2

Re: [PATCH v2 03/29] mm/migrate: Trylock device page in do_swap_page

[Matthew Brost]

On Tue, Oct 29, 2024 at 05:37:45PM +1100, Alistair Popple wrote:
> 
> Matthew Brost  writes:
> 
> > On Thu, Oct 17, 2024 at 12:51:08PM +1100, Alistair Popple wrote:
> >> 
> >> Matthew Brost  writes:
> >> 
> >> > On Wed, Oct 16, 2024 at 03:00:08PM +1100, Alistair Popple wrote:
> >> >> 
> >> >> Matthew Brost  writes:
> >> >> 
> >> >> > Avoid multiple CPU page faults to the same device page racing by 
> >> >> > trying
> >> >> > to lock the page in do_swap_page before taking an extra reference to 
> >> >> > the
> >> >> > page. This prevents scenarios where multiple CPU page faults each take
> >> >> > an extra reference to a device page, which could abort migration in
> >> >> > folio_migrate_mapping. With the device page being locked in
> >> >> > do_swap_page, the migrate_vma_* functions need to be updated to avoid
> >> >> > locking the fault_page argument.
> >> >> >
> >> >> > Prior to this change, a livelock scenario could occur in Xe's (Intel 
> >> >> > GPU
> >> >> > DRM driver) SVM implementation if enough threads faulted the same 
> >> >> > device
> >> >> > page.
> >> >> >
> >> >> > Cc: Philip Yang 
> >> >> > Cc: Felix Kuehling 
> >> >> > Cc: Christian König 
> >> >> > Cc: Andrew Morton 
> >> >> > Suggessted-by: Simona Vetter 
> >> >> > Signed-off-by: Matthew Brost 
> >> >> > ---
> >> >> >  mm/memory.c | 13 ++---
> >> >> >  mm/migrate_device.c | 69 
> >> >> > ++---
> >> >> >  2 files changed, 56 insertions(+), 26 deletions(-)
> >> >> >
> >> >> > diff --git a/mm/memory.c b/mm/memory.c
> >> >> > index 2366578015ad..b72bde782611 100644
> >> >> > --- a/mm/memory.c
> >> >> > +++ b/mm/memory.c
> >> >> > @@ -4252,10 +4252,15 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >> >> >* Get a page reference while we know the page 
> >> >> > can't be
> >> >> >* freed.
> >> >> >*/
> >> >> > - get_page(vmf->page);
> >> >> > - pte_unmap_unlock(vmf->pte, vmf->ptl);
> >> >> > - ret = 
> >> >> > vmf->page->pgmap->ops->migrate_to_ram(vmf);
> >> >> > - put_page(vmf->page);
> >> >> > + if (trylock_page(vmf->page)) {
> >> >> > + get_page(vmf->page);
> >> >> > + pte_unmap_unlock(vmf->pte, vmf->ptl);
> >> >> > + ret = 
> >> >> > vmf->page->pgmap->ops->migrate_to_ram(vmf);
> >> >> > + put_page(vmf->page);
> >> >> > + unlock_page(vmf->page);
> >> >> 
> >> >> I don't think my previous review of this change has really been
> >> >> addressed. Why don't we just install the migration entry here? Seems
> >> >> like it would be a much simpler way of solving this.
> >> >> 
> >> >
> >> > I should have mentioned this in the cover-letter, I haven't got around
> >> > to trying that out yet. Included this existing version for correctness
> >> > but I also think this is not strickly required to merge this series as
> >> > our locking in migrate_to_ram only relies on the core MM locks so
> >> > some thread would eventually win the race and make forward progress.
> >> >
> >> > So I guess just ignore this patch and will send an updated version
> >> > individually with installing a migration entry in do_swap_page. If for
> >> > some reason that doesn't work, I'll respond here explaining why.
> >> 
> >> That would be great. I have a fairly strong preference for doing that
> >> instead of adding more special cases for the fault page in the migration
> >> code. And if we can't do that it would be good to understand
> >> why. Thanks.
> >> 
> >
> > I've looked into this and actually prefer the approach in this patch.
> 
> Thanks for looking into this.
> 
> > Consider the scenario where we install a migration entry, but
> > migrate_to_ram fails. How do we handle this?
> >
> > We don't know where migrate_to_ram failed. Was migrate_device_finalize
> > called, removing the migration PTE? Do we need to special-case failures
> > in migrate_to_ram to prevent migrate_device_finalize from removing the
> > faulting page's migration entry? Should we check for a migration entry
> > after migrate_to_ram and remove it if it exists?
> 
> The driver should always call migrate_device_finalize(). On failure it
> will remove the migration entry and remap the original device private
> page. That obviously doesn't handle the fault but the process is about
> to die anyway with a SIGBUS because migrate_to_ram() can't fail.
> 

What if migrate_to_ram fails before calling migrate_vma_setup - e.g. a
kmalloc of the arguments fails? Very ackward situation.

> > Now, if migrate_to_ram succeeds, it seems the migration entry should be
> > removed in migrate_device_finalize since the new page is only available
> > there. We could return the new page in migrate_to_ram, but that feels
> > messy.
> 
> Agreed - I would expect migrat

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Rob Herring]

On Tue, Oct 29, 2024 at 04:25:52PM +0800, Liu Ying wrote:
> On 10/29/2024, Biju Das wrote:
> > 
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> > 
> >> -Original Message-
> >> From: dri-devel  On Behalf Of Liu 
> >> Ying
> >> Sent: 29 October 2024 07:35
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link 
> >> LVDS display common properties
> >>
> >> On 10/29/2024, Biju Das wrote:
> >>> Hi Liu Ying,
> >>
> >> Hi Biju,
> >>
> >>>
>  -Original Message-
>  From: Liu Ying 
>  Sent: 29 October 2024 07:13
>  Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
>  dual-link LVDS display common properties
> 
>  On 10/29/2024, Biju Das wrote:
> > Hi Liu Ying,
> 
>  Hi Biju,
> 
> >
> >> -Original Message-
> >> From: Liu Ying 
> >> Sent: 29 October 2024 06:17
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >> dual-link LVDS display common properties
> >>
> >> On 10/28/2024, Liu Ying wrote:
> >>> Dual-link LVDS displays receive odd pixels and even pixels
> >>> separately from dual LVDS links.  One link receives odd pixels and
> >>> the other receives even pixels.  Some of those displays may also
> >>> use only one LVDS link to receive all pixels, being odd and even 
> >>> agnostic.
> >>> Document common properties for those displays by extending LVDS
> >>> display common properties defined in lvds.yaml.
> >>>
> >>> Suggested-by: Dmitry Baryshkov 
> >>> Signed-off-by: Liu Ying 
> >>> ---
> >>> v4:
> >>> * Squash change for advantech,idk-2121wr.yaml and
> >>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
> >>> (Rob)
> >>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >>>
> >>> v3:
> >>> * New patch.  (Dmitry)
> >>>
> >>>  .../bindings/display/lvds-dual-ports.yaml | 76 
> >>> +++
> >>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +
> >>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> >>> 100644
> >>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>> new file mode 100644
> >>> index ..5f7a30640404
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.ya
> >>> +++ ml
> >>> @@ -0,0 +1,76 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> >>> +1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Dual-link LVDS Display Common Properties
> >>> +
> >>> +maintainers:
> >>> +  - Liu Ying 
> >>> +
> >>> +description: |
> >>> +  Common properties for LVDS displays with dual LVDS links.
> >>> +Extend LVDS display
> >>> +  common properties defined in lvds.yaml.
> >>> +
> >>> +  Dual-link LVDS displays receive odd pixels and even pixels
> >>> + separately from  the dual LVDS links. One link receives odd
> >>> + pixels and the other receives  even pixels. Some of those
> >>> + displays may also use only one LVDS link to  receive all pixels, 
> >>> being odd and even agnostic.
> >>> +
> >>> +allOf:
> >>> +  - $ref: lvds.yaml#
> >>> +
> >>> +properties:
> >>> +  ports:
> >>> +$ref: /schemas/graph.yaml#/properties/ports
> >>> +
> >>> +properties:
> >>> +  port@0:
> >>> +$ref: /schemas/graph.yaml#/$defs/port-base
> >>> +unevaluatedProperties: false
> >>> +description: the first LVDS input link
> >>> +
> >>> +properties:
> >>> +  dual-lvds-odd-pixels:
> >>> +type: boolean
> >>> +description: the first LVDS input link for odd pixels
> >>> +
> >>> +  dual-lvds-even-pixels:
> >>> +type: boolean
> >>> +description: the first LVDS input link for even
> >>> + pixels
> >>> +
> >>> +oneOf:
> >>> +  - required: [dual-lvds-odd-pixels]
> >>> +  - required: [dual-lvds-even-pixels]
> >>> +  - properties:
> >>> +  dual-lvds-odd-pixels: false
> >>> +  dual-lvds-even-pixels: false
> >>> +
> >>> +  port@1:
> >>> +$ref: /schemas/graph.yaml#/$defs/port-base
> >>> +unevaluatedProperties: false
> >>> +description: the second LVDS input link
> >>> +
> >>> +properties:
> >>> +  dual-lvds-odd-pixels:
> >>> +type: bool

Re: [PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter

[Rob Herring (Arm)]

On Mon, 28 Oct 2024 10:37:36 +0800, Liu Ying wrote:
> Document ITE IT6263 LVDS to HDMI converter.
> 
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
> 
> Signed-off-by: Liu Ying 
> ---
> v4:
> * Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for
>   port@1.
> * Drop "data-mirror: true"(30-bit LVDS data bit order is not reversed).
> 
> v3:
> * Reference lvds-dual-ports.yaml.  (Dmitry)
> * Add data-mapping DT property.  (Dmitry, Biju)
> * Allow data-mirror.
> * Drop ite,lvds-link-num-data-lanes DT property.  (Dmitry, Biju)
> 
> v2:
> * Document number of LVDS link data lanes.  (Biju)
> * Simplify ports property by dropping "oneOf".  (Rob)
> 
>  .../bindings/display/bridge/ite,it6263.yaml   | 250 ++
>  1 file changed, 250 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> 

Reviewed-by: Rob Herring (Arm) 

Re: [PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior

[Will Deacon]

Hi Jason,

On Thu, Oct 24, 2024 at 10:44:11AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 24, 2024 at 02:05:53PM +0100, Will Deacon wrote:
> 
> > My recollection is hazy, but I seem to remember VFIO using the largest
> > page sizes in the IOMMU 'pgsize_bitmap' for map() requests but then
> > using the smallest page size for unmap() requests, so you'd end up
> > cracking block mappings when tearing down a VM with assigne devices.
> >
> > Is this what you're referring to when you say?
> 
> Sounds like it, but I'm really hazy on the long ago history here.
> 
> >   > Long ago VFIO could trigger a path like this, today I know of no user of
> >   > this functionality.
> > 
> > If so, please can you provide a reference to the patch that moved VFIO
> > off that problematic behaviour?
> 
> Looking more deeply, I'm not really sure VFIO ever required this.
> 
> vfio commit 166fd7d94afd ("vfio: hugepage support for
> vfio_iommu_type1") is the thing that added the huge page support, and
> it called map like:
> 
> +   ret = iommu_map(iommu->domain, iova,
> +   (phys_addr_t)pfn << PAGE_SHIFT,
> +   npage << PAGE_SHIFT, prot);
> 
> But then the unmap path still looked like:
> 
> +   unmapped = iommu_unmap(iommu->domain, iova, PAGE_SIZE);
> +   unlocked += vfio_unpin_pages(phys >> PAGE_SHIFT,
> +unmapped >> PAGE_SHIFT,
> +dma->prot, false);
> 
> So at that time it was relying on the "unmap smaller gives the larger
> size" trick that we see Intel and AMD implementing today. No
> requirement for split, but the ARM split code could be triggered.

Urgh, I'm not sure I was ever fully aware of that "trick". That's really
horrible!

> Next came the introduction of VFIO_TYPE1v2_IOMMU which eliminated the
> ability for userspace to request splitting a mapping. Userspace can
> only unmap what userspace maps. commit 1ef3e2bc0422
> ("vfio/iommu_type1: Multi-IOMMU domain support")
> 
> To do this, our DMA tracking needs to change.  We currently try to
> coalesce user mappings into as few tracking entries as possible.  The
> problem then becomes that we lose granularity of user mappings.  We've
> never guaranteed that a user is able to unmap at a finer granularity
> than the original mapping, but we must honor the granularity of the
> original mapping.  This coalescing code is therefore removed, allowing
> only unmaps covering complete maps.  The change in accounting is
> fairly small here, a typical QEMU VM will start out with roughly a
> dozen entries, so it's arguable if this coalescing was ever needed.
> 
> That blocked any requirement for splitting driven by the uAPI. Noting
> uAPI based splitting never worked right and AFAICT AMD didn't
> implement split at the time.
> 
> Finally, commit 6fe1010d6d9c ("vfio/type1: DMA unmap chunking")
> changed the unmap loop to this:
> 
> -   unmapped = iommu_unmap(domain->domain, iova, PAGE_SIZE);
> +   /*
> +* To optimize for fewer iommu_unmap() calls, each of which
> +* may require hardware cache flushing, try to find the
> +* largest contiguous physical memory chunk to unmap.
> +*/
> +   for (len = PAGE_SIZE;
> +!domain->fgsp && iova + len < end; len += PAGE_SIZE) {
> +   next = iommu_iova_to_phys(domain->domain, iova + len);
> +   if (next != phys + len)
> +   break;
> +   }
> +
> +   unmapped = iommu_unmap(domain->domain, iova, len);
> 
> fgsp=true is only possible on AMD, and this loop effectively
> guarantees that the iommu driver will never see a partial huge page
> unmap as the size is discovered via iommu_iova_to_phys() before
> calling unmap.

Talking to Robin, he reminded me of:

7c6d90e2bb1a ("iommu/io-pgtable-arm: Fix iova_to_phys for block entries")

which looks like it fixes a bug which would've defeated the VFIO chunking
in your snippet above.

But we're all good now, so I'm in favour of dropping this. Let's just
cram some of this history into the commit message so we know why we're
happy to do so.

Lemme go look at the actual diff now...

Cheers,

Will

Re: lockdep and ww mutex debug interactions in hdmi tests

[Maxime Ripard]

Hi,

On Wed, Oct 30, 2024 at 05:03:50AM +1000, Dave Airlie wrote:
> Hi,
> 
> I mentioned this internally, but wanted to get it on the list,
> 
> I ran the hdmi kunit tests with LOCKDEP and WW_MUTEX_SLOWPATH enabled
> and hit some issues.
> 
> With the slowpath we get the occasional EDEADLK to test the paths are
> doing things right, I think you should handle EDEADLK in the tests
> with a retry loop.

Thanks for the report, I've just sent a patch fixing this.

The vc4 have the same issue though, and I haven't been able to fix all
of them yet.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v2] amdgpu: prevent NULL pointer dereference if ATIF is not supported

[Mario Limonciello]

On 10/31/2024 15:50, Antonio Quartulli wrote:

On 31/10/2024 20:37, Mario Limonciello wrote:

On 10/31/2024 10:28, Antonio Quartulli wrote:

acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.

Although this case may be unrealistic for the current code, it is
still better to protect against possible bugs.

Bail out also when status is AE_NOT_FOUND.

This fixes 1 FORWARD_NULL issue reported by Coverity
Report: CID 1600951:  Null pointer dereferences  (FORWARD_NULL)

Signed-off-by: Antonio Quartulli 


Can you please dig up the right Fixes: tag?


Fixes: c9b7c809b89f ("drm/amd: Guard against bad data for ATIF ACPI 
method")


Your commit :)

Should I send v3 with the Fixes tag in it?


Don't worry about it, I'll pick it up while we commit it.

Thanks!



Interestingly, this pattern of checking for AE_NOT_FOUND is shared by 
other functions, however, they don't try to dereference the pointer to 
the buffer before the return statement (which caused the Coverity report).

It's the caller that checks if the return value is NULL or not.

For this function it was the same, until you added this extra check on 
obj->type, without checking if obj was NULL or not.


If we want to keep the original pattern and continue checking for 
AE_NOT_FOUND, we could rather do:


-   if (obj->type != ACPI_TYPE_BUFFER) {
+   if (obj && obj->type != ACPI_TYPE_BUFFER) {

But this feel more like "bike shed color picking" than anything else :)
Anyway, up to you Mario, I am open to change the patch again if the 
latter pattern is more preferable.


Regards,



Besides that, LGTM.

Reviewed-by: Mario Limonciello 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c b/drivers/gpu/ 
drm/amd/amdgpu/amdgpu_acpi.c

index cce85389427f..b8d4e07d2043 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -172,8 +172,8 @@ static union acpi_object *amdgpu_atif_call(struct 
amdgpu_atif *atif,

    &buffer);
  obj = (union acpi_object *)buffer.pointer;
-    /* Fail if calling the method fails and ATIF is supported */
-    if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+    /* Fail if calling the method fails */
+    if (ACPI_FAILURE(status)) {
  DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
   acpi_format_exception(status));
  kfree(obj);

Re: [PATCH v2 2/3] dt-bindings: opp: Add v2-qcom-adreno vendor bindings

[Akhil P Oommen]

On 10/25/2024 11:58 AM, Dmitry Baryshkov wrote:
> On Thu, Oct 24, 2024 at 12:56:58AM +0530, Akhil P Oommen wrote:
>> On 10/22/2024 11:19 AM, Krzysztof Kozlowski wrote:
>>> On Mon, Oct 21, 2024 at 05:23:43PM +0530, Akhil P Oommen wrote:
 Add a new schema which extends opp-v2 to support a new vendor specific
 property required for Adreno GPUs found in Qualcomm's SoCs. The new
 property called "qcom,opp-acd-level" carries a u32 value recommended
 for each opp needs to be shared to GMU during runtime.

 Cc: Rob Clark 
 Signed-off-by: Akhil P Oommen 
 ---
  .../bindings/opp/opp-v2-qcom-adreno.yaml   | 96 
 ++
  1 file changed, 96 insertions(+)

 diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml 
 b/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
 new file mode 100644
 index ..6d50c0405ef8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
 @@ -0,0 +1,96 @@
 +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 +%YAML 1.2
 +---
 +$id: http://devicetree.org/schemas/opp/opp-v2-qcom-adreno.yaml#
 +$schema: http://devicetree.org/meta-schemas/core.yaml#
 +
 +title: Qualcomm Adreno compatible OPP supply
 +
 +description:
 +  Adreno GPUs present in Qualcomm's Snapdragon chipsets uses an OPP 
 specific
 +  ACD related information tailored for the specific chipset. This binding
 +  provides the information needed to describe such a hardware value.
 +
 +maintainers:
 +  - Rob Clark 
 +
 +allOf:
 +  - $ref: opp-v2-base.yaml#
 +
 +properties:
 +  compatible:
 +items:
 +  - const: operating-points-v2-adreno
 +  - const: operating-points-v2
 +
 +patternProperties:
 +  '^opp-?[0-9]+$':
>>>
>>> '-' should not be optional. opp1 is not expected name.
>>
>> Agree. Will change this to '^opp-[0-9]+$'
>>
>>>
 +type: object
 +additionalProperties: false
 +
 +properties:
 +  opp-hz: true
 +
 +  opp-level: true
 +
 +  opp-peak-kBps: true
 +
 +  opp-supported-hw: true
 +
 +  qcom,opp-acd-level:
 +description: |
 +  A positive value representing the ACD (Adaptive Clock 
 Distribution,
 +  a fancy name for clk throttling during voltage droop) level 
 associated
 +  with this OPP node. This value is shared to a co-processor 
 inside GPU
 +  (called Graphics Management Unit a.k.a GMU) during wake up. It 
 may not
 +  be present for some OPPs and GMU will disable ACD while 
 transitioning
 +  to that OPP. This value encodes a voltage threshold and few 
 other knobs
 +  which are identified by characterization of the SoC. So, it 
 doesn't have
 +  any unit.
>>>
>>> Thanks for explanation and other updates. I am still not happy with this
>>> property. I do not see reason why DT should encode magic values in a
>>> quite generic piece of code. This creates poor ABI, difficult to
>>> maintain or understand.
>>>
>>
>> Configuring GPU ACD block with its respective value is a requirement for 
>> each OPP.
>> So OPP node seems like the natural place for this data.
>>
>> If it helps to resolve your concerns, I can elaborate the documentation with
>> details on the GMU HFI interface where this value should be passed on to the
>> hardware. Also replace "few other knobs" with "Delay cycles & Calibration 
>> margin"
>> in the above doc.
> 
> Usually the preference for DT is to specify data in a sensible way
> rather than just the values being programmed to the register. Is it
> possible to implement this approach for ACD values?

I am still checking about this. Will get back.

-Akhil

> 
>>  
>>>
> 

Re: [PATCH RFC v2 6/7] drm/display/hdmi: implement connector update functions

[Dmitry Baryshkov]

On Fri, Nov 01, 2024 at 12:59:38PM +0200, Jani Nikula wrote:
> On Fri, 01 Nov 2024, Dmitry Baryshkov  wrote:
> > The HDMI Connectors need to perform a variety of tasks when the HDMI
> > connector state changes. Such tasks include setting or invalidating CEC
> > address, notifying HDMI codec driver, updating scrambler data, etc.
> >
> > Implementing such tasks in a driver-specific callbacks is error prone.
> > Start implementing the generic helper function (currently handling only
> > the HDMI Codec framework) to be used by driver utilizing HDMI Connector
> > framework.
> >
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >  drivers/gpu/drm/display/drm_hdmi_state_helper.c | 56 
> > +
> >  include/drm/display/drm_hdmi_state_helper.h |  4 ++
> >  2 files changed, 60 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c 
> > b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> > index 
> > feb7a3a759811aed70c679be8704072093e2a79b..dc9d0cc162b2197dcbadda26686a9c5652e74107
> >  100644
> > --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> > +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> > @@ -748,3 +748,59 @@ 
> > drm_atomic_helper_connector_hdmi_clear_audio_infoframe(struct drm_connector 
> > *con
> > return ret;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_clear_audio_infoframe);
> > +
> > +/**
> > + * __drm_atomic_helper_connector_hdmi_update_edid - Update the HDMI 
> > Connector basing on passed EDID
> > + * @connector: A pointer to the HDMI connector
> > + * @drm_edid: EDID to process
> > + *
> > + * This function should be called as a part of the .detect() / 
> > .detect_ctx()
> > + * and .force() callbacks, updating the HDMI-specific connector's data. The
> > + * function consumes passed EDID, there is no need to free it afterwards. 
> > Most
> > + * of the drivers should be able to use
> > + * @drm_atomic_helper_connector_hdmi_update() instead.
> > + *
> > + * Returns:
> > + * Zero on success, error code on failure.
> > + */
> > +int
> > +__drm_atomic_helper_connector_hdmi_update_edid(struct drm_connector 
> > *connector,
> > +  const struct drm_edid *drm_edid)
> > +{
> > +   drm_edid_connector_update(connector, drm_edid);
> > +   drm_edid_free(drm_edid);
> 
> Not fond of splitting resource management responsibilities
> asymmetrically like this.

Ack, I can remove drm_edid_free() call.

> 
> > +
> > +   if (!drm_edid) {
> > +   drm_connector_hdmi_codec_plugged_notify(connector, false);
> 
> Is it a good idea to tie connection status to EDID presence at the
> helper level? Nearly the same, but still orthogonal.

Yes. We have been discussing this in v1 review. Basically, CEC, HDMI
codec and some other features should be pinged without any userspace
interaction. This means that get_modes / fill_modes is mostly out of
question. The final agreement was that the .detect is the best place to
handle them (BTW: this matches the i915 driver, see
intel_hdmi_detect()).

> 
> > +
> > +   // TODO: also handle CEC and scramber, HDMI sink disconnected.
> > +
> > +   return 0;
> > +   }
> > +
> > +   drm_connector_hdmi_codec_plugged_notify(connector, true);
> > +
> > +   // TODO: also handle CEC and scramber, HDMI sink is now connected.
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_update_edid);
> 
> Feels wrong to export and document double underscored functions to
> actually be used.

We have enough examples of EXPORT_SYMBOL(__drm_foo) in DRM helpers. But
I can drop double-underscore if that's the issue.

> 
> > +
> > +/**
> > + * drm_atomic_helper_connector_hdmi_update - Update the HDMI Connector 
> > after reading the EDID
> > + * @connector: A pointer to the HDMI connector
> > + *
> > + * This function should be called as a part of the .detect() / 
> > .detect_ctx()
> > + * and .force() callbacks, updating the HDMI-specific connector's data.
> > + *
> > + * Returns:
> > + * Zero on success, error code on failure.
> > + */
> > +int
> > +drm_atomic_helper_connector_hdmi_update(struct drm_connector *connector)
> > +{
> > +   const struct drm_edid *drm_edid = drm_edid_read(connector);
> > +
> > +   return __drm_atomic_helper_connector_hdmi_update_edid(connector, 
> > drm_edid);
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_update);
> > diff --git a/include/drm/display/drm_hdmi_state_helper.h 
> > b/include/drm/display/drm_hdmi_state_helper.h
> > index 
> > 2d45fcfa461985065a5e5ad67eddc0b1c556d526..ea0980aa25cbbfdd36f44201888c139b0ee943da
> >  100644
> > --- a/include/drm/display/drm_hdmi_state_helper.h
> > +++ b/include/drm/display/drm_hdmi_state_helper.h
> > @@ -20,4 +20,8 @@ int 
> > drm_atomic_helper_connector_hdmi_clear_audio_infoframe(struct drm_connector
> >  int drm_atomic_helper_connector_hdmi_update_infoframes(struct 
> > drm_connector *connector,
> >struct drm_

[PATCH] drm/tests: hdmi: Fix WW_MUTEX_SLOWPATH failures

[Maxime Ripard]

The light_up_connector helper function in the HDMI infrastructure unit
tests uses drm_atomic_set_crtc_for_connector(), but fails when it
returns an error.

This function can return EDEADLK though if the sequence needs to be
restarted, and WW_MUTEX_SLOWPATH is meant to test that we handle it
properly.

Let's handle EDEADLK and restart the sequence in our tests as well.

Fixes: eb66d34d793e ("drm/tests: Add output bpc tests")
Closes: 
https://lore.kernel.org/r/CAPM=9tzJ4-ERDxvuwrCyUPY0=+p44orhp1klwvgl7mcfpqj...@mail.gmail.com/
Reported-by: Dave Airlie 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c 
b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
index 34ee95d41f29..e2441092a8e9 100644
--- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
@@ -68,14 +68,21 @@ static int light_up_connector(struct kunit *test,
int ret;
 
state = drm_kunit_helper_atomic_state_alloc(test, drm, ctx);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
 
+retry:
conn_state = drm_atomic_get_connector_state(state, connector);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
 
ret = drm_atomic_set_crtc_for_connector(conn_state, crtc);
+   if (ret == -EDEADLK) {
+   drm_atomic_state_clear(state);
+   ret = drm_modeset_backoff(ctx);
+   if (!ret)
+   goto retry;
+   }
KUNIT_EXPECT_EQ(test, ret, 0);
 
crtc_state = drm_atomic_get_crtc_state(state, crtc);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
 
-- 
2.47.0

[PATCH v4 1/3] dt-bindings: lcdif: Document a imx6sx-lcdif fallback

[Fabio Estevam]

From: Fabio Estevam 

imx6sx.dtsi has the following lcdif entries:

compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";

This causes the following dt-schema warning:

['fsl,imx6sx-lcdif', 'fsl,imx28-lcdif'] is too long

To keep DT compatibility, document 'fsl,imx28-lcdif' as a possible
'fsl,imx6sx-lcdif' fallback.

Signed-off-by: Fabio Estevam 
---
Changes since v3:
- Also update the example.

 Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 8e3a98aeec32..aa3204b6aff9 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -19,7 +19,6 @@ properties:
   - enum:
   - fsl,imx23-lcdif
   - fsl,imx28-lcdif
-  - fsl,imx6sx-lcdif
   - fsl,imx8mp-lcdif
   - fsl,imx93-lcdif
   - items:
@@ -32,6 +31,10 @@ properties:
   - fsl,imx8mn-lcdif
   - fsl,imx8mq-lcdif
   - const: fsl,imx6sx-lcdif
+  - items:
+  - enum:
+  - fsl,imx6sx-lcdif
+  - const: fsl,imx28-lcdif
 
   reg:
 maxItems: 1
@@ -182,7 +185,7 @@ examples:
 #include 
 
 display-controller@222 {
-compatible = "fsl,imx6sx-lcdif";
+compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 reg = <0x0222 0x4000>;
 interrupts = ;
 clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
-- 
2.34.1

Re: [PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior

[Will Deacon]

On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
> 
> All other drivers will unmap the large IOPTE and return it's length.  For
> example if a 2M IOPTE is present and the first 4K is requested to be
> unmapped then unmap will remove the whole 2M and report 2M as the result.
> 
> arm_lpae instead replaces the IOPTE with a table of smaller IOPTEs, unmaps
> the 4K and returns 4k. This is actually an illegal/non-hitless operation
> on at least SMMUv3 because of the BBM level 0 rules.
> 
> Long ago VFIO could trigger a path like this, today I know of no user of
> this functionality.
> 
> Given it doesn't work fully correctly on SMMUv3 and would create
> portability problems if any user depends on it, remove the unique support
> in arm_lpae and align with the expected iommu interface.
> 
> Outside the iommu users, this will potentially effect io_pgtable users of
> ARM_32_LPAE_S1, ARM_32_LPAE_S2, ARM_64_LPAE_S1, ARM_64_LPAE_S2, and
> ARM_MALI_LPAE formats.
> 
> Cc: Boris Brezillon 
> Cc: Steven Price 
> Cc: Liviu Dudau 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/iommu/io-pgtable-arm.c | 72 +++---
>  1 file changed, 6 insertions(+), 66 deletions(-)
> 
> I don't know anything in the iommu space that needs this, and this is the only
> page table implementation in iommu that does it.

I think the v7s code does it as well, so please can you apply the same
treatment to arm_v7s_split_blk_unmap()?

> @@ -678,12 +618,12 @@ static size_t __arm_lpae_unmap(struct 
> arm_lpae_io_pgtable *data,
>  
>   return i * size;
>   } else if (iopte_leaf(pte, lvl, iop->fmt)) {
> - /*
> -  * Insert a table at the next level to map the old region,
> -  * minus the part we want to unmap
> -  */
> - return arm_lpae_split_blk_unmap(data, gather, iova, size, pte,
> - lvl + 1, ptep, pgcount);
> + /* Unmap the entire large IOPTE and return its size */
> + size = ARM_LPAE_BLOCK_SIZE(lvl, data);

If I understand your other message correctly, we shouldn't actually get
into this situation any more, right? In which case, can we WARN_ONCE()
and return 0 instead? Over-unmapping is filthy!

Will

Re: [PATCH v4] drm/edid: add CTA Video Format Data Block support

[Ian Forbes]

We'd like to use the OVT modes for vmwgfx. Can you export the main OVT
function so it matches the CVT one? Something like this:

struct drm_display_mode *drm_ovt_mode(struct drm_device *dev, int rid,
int vrefresh);

On Mon, Sep 9, 2024 at 12:17 PM Hamza Mahfooz  wrote:
>
> +
> +/* OVT Algorthim as specified in CTA-861-I */
> +static struct drm_display_mode *
> +calculate_ovt_mode(struct drm_connector *connector, const struct cta_rid 
> *rid,
> +  u16 vrate)

Also all instances of CEA should probably be replaced with CTA, not
necessarily in this series, but they changed their name ~10 years ago.

Ian,

Re: [PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior

[Jason Gunthorpe]

On Fri, Oct 18, 2024 at 02:19:26PM -0300, Jason Gunthorpe wrote:
> Of the page table implementations (AMD v1/2, VT-D SS, ARM32, DART)
> arm_lpae is unique in how it handles partial unmap of large IOPTEs.
> 
> All other drivers will unmap the large IOPTE and return it's length.  For
> example if a 2M IOPTE is present and the first 4K is requested to be
> unmapped then unmap will remove the whole 2M and report 2M as the result.
> 
> arm_lpae instead replaces the IOPTE with a table of smaller IOPTEs, unmaps
> the 4K and returns 4k. This is actually an illegal/non-hitless operation
> on at least SMMUv3 because of the BBM level 0 rules.
> 
> Long ago VFIO could trigger a path like this, today I know of no user of
> this functionality.
> 
> Given it doesn't work fully correctly on SMMUv3 and would create
> portability problems if any user depends on it, remove the unique support
> in arm_lpae and align with the expected iommu interface.
> 
> Outside the iommu users, this will potentially effect io_pgtable users of
> ARM_32_LPAE_S1, ARM_32_LPAE_S2, ARM_64_LPAE_S1, ARM_64_LPAE_S2, and
> ARM_MALI_LPAE formats.
> 
> Cc: Boris Brezillon 
> Cc: Steven Price 
> Cc: Liviu Dudau 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/iommu/io-pgtable-arm.c | 72 +++---
>  1 file changed, 6 insertions(+), 66 deletions(-)

Updated commit message - Will let me know if you want me to resend
with this, or any changes:

iommu/io-pgtable-arm: Remove split on unmap behavior

A minority of page table implementations (arm_lpae, armv7) are unique in
how they handle partial unmap of large IOPTEs.

Other implementations will unmap the large IOPTE and return it's
length. For example if a 2M IOPTE is present and the first 4K is requested
to be unmapped then unmap will remove the whole 2M and report 2M as the
result.

arm_lpae instead replaces the IOPTE with a table of smaller IOPTEs, unmaps
the 4K and returns 4k. This is actually an illegal/non-hitless operation
on at least SMMUv3 because of the BBM level 0 rules.

Will says this was done to support VFIO, but upon deeper analysis this was
never strictly necessary:

 https://lore.kernel.org/all/20241024134411.ga6...@nvidia.com/

In summary, historical VFIO supported the AMD behavior of unmapping the
whole large IOPTE and returning the size, even if asked to unmap a
portion. The driver would see this as a request to split a large IOPTE.
Modern VFIO always unmaps entire large IOPTEs (except on AMD) and drivers
don't see an IOPTE split.

Given it doesn't work fully correctly on SMMUv3 and relying on ARM unique
behavior would create portability problems across IOMMU drivers, retire
this functionality.

Outside the iommu users, this will potentially effect io_pgtable users of
ARM_32_LPAE_S1, ARM_32_LPAE_S2, ARM_64_LPAE_S1, ARM_64_LPAE_S2, and
ARM_MALI_LPAE formats.

[PATCH v5 3/5] mm: move ``get_order_from_str()`` to internal.h

[Maíra Canal]

In order to implement a kernel parameter similar to ``thp_anon=`` for
shmem, we'll need the function ``get_order_from_str()``.

Instead of duplicating the function, move the function to a shared
header, in which both mm/shmem.c and mm/huge_memory.c will be able to
use it.

Signed-off-by: Maíra Canal 
---
 mm/huge_memory.c | 38 +++---
 mm/internal.h| 22 ++
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f92068864469..a6edbd8c4f49 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -958,26 +958,6 @@ static int __init setup_transparent_hugepage(char *str)
 }
 __setup("transparent_hugepage=", setup_transparent_hugepage);
 
-static inline int get_order_from_str(const char *size_str)
-{
-   unsigned long size;
-   char *endptr;
-   int order;
-
-   size = memparse(size_str, &endptr);
-
-   if (!is_power_of_2(size))
-   goto err;
-   order = get_order(size);
-   if (BIT(order) & ~THP_ORDERS_ALL_ANON)
-   goto err;
-
-   return order;
-err:
-   pr_err("invalid size %s in thp_anon boot parameter\n", size_str);
-   return -EINVAL;
-}
-
 static char str_dup[PAGE_SIZE] __initdata;
 static int __init setup_thp_anon(char *str)
 {
@@ -1007,10 +987,22 @@ static int __init setup_thp_anon(char *str)
start_size = strsep(&subtoken, "-");
end_size = subtoken;
 
-   start = get_order_from_str(start_size);
-   end = get_order_from_str(end_size);
+   start = get_order_from_str(start_size, 
THP_ORDERS_ALL_ANON);
+   end = get_order_from_str(end_size, 
THP_ORDERS_ALL_ANON);
} else {
-   start = end = get_order_from_str(subtoken);
+   start_size = end_size = subtoken;
+   start = end = get_order_from_str(subtoken,
+
THP_ORDERS_ALL_ANON);
+   }
+
+   if (start == -EINVAL) {
+   pr_err("invalid size %s in thp_anon boot 
parameter\n", start_size);
+   goto err;
+   }
+
+   if (end == -EINVAL) {
+   pr_err("invalid size %s in thp_anon boot 
parameter\n", end_size);
+   goto err;
}
 
if (start < 0 || end < 0 || start > end)
diff --git a/mm/internal.h b/mm/internal.h
index d5b93c5b6364..5a7302baeed7 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -1291,6 +1291,28 @@ static inline bool alloc_zeroed(void)
&init_on_alloc);
 }
 
+/*
+ * Parses a string with mem suffixes into its order. Useful to parse kernel
+ * parameters.
+ */
+static inline int get_order_from_str(const char *size_str,
+unsigned long valid_orders)
+{
+   unsigned long size;
+   char *endptr;
+   int order;
+
+   size = memparse(size_str, &endptr);
+
+   if (!is_power_of_2(size))
+   return -EINVAL;
+   order = get_order(size);
+   if (BIT(order) & ~valid_orders)
+   return -EINVAL;
+
+   return order;
+}
+
 enum {
/* mark page accessed */
FOLL_TOUCH = 1 << 16,
-- 
2.46.2

[PATCH v5 1/5] mm: fix docs for the kernel parameter ``thp_anon=``

[Maíra Canal]

If we add ``thp_anon=32,64K:always`` to the kernel command line, we
will see the following error:

[0.00] huge_memory: thp_anon=32,64K:always: error parsing string, 
ignoring setting

This happens because the correct format isn't 
``thp_anon=,[KMG]:```,
as [KMG] must follow each number to especify its unit. So, the correct
format is ``thp_anon=[KMG],[KMG]:```.

Therefore, adjust the documentation to reflect the correct format of the
parameter ``thp_anon=``.

Fixes: dd4d30d1cdbe ("mm: override mTHP "enabled" defaults at kernel cmdline")
Signed-off-by: Maíra Canal 
Acked-by: Barry Song 
Acked-by: David Hildenbrand 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 +-
 Documentation/admin-guide/mm/transhuge.rst  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1518343bbe22..1666576acc0e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6688,7 +6688,7 @@
0: no polling (default)
 
thp_anon=   [KNL]
-   Format: 
,[KMG]:;-[KMG]:
+   Format: 
[KMG],[KMG]:;[KMG]-[KMG]:
state is one of "always", "madvise", "never" or 
"inherit".
Control the default behavior of the system with respect
to anonymous transparent hugepages.
diff --git a/Documentation/admin-guide/mm/transhuge.rst 
b/Documentation/admin-guide/mm/transhuge.rst
index 5caa3fb2feb1..abdf10a1c7db 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -303,7 +303,7 @@ control by passing the parameter 
``transparent_hugepage=always`` or
 kernel command line.
 
 Alternatively, each supported anonymous THP size can be controlled by
-passing ``thp_anon=,[KMG]:;-[KMG]:``,
+passing 
``thp_anon=[KMG],[KMG]:;[KMG]-[KMG]:``,
 where  is the THP size (must be a power of 2 of PAGE_SIZE and
 supported anonymous THP)  and  is one of ``always``, ``madvise``,
 ``never`` or ``inherit``.
-- 
2.46.2

[PATCH v5 2/5] mm: shmem: control THP support through the kernel command line

[Maíra Canal]

Add a new kernel command line to control the hugepage allocation policy
for the internal shmem mount, ``transparent_hugepage_shmem``. The
parameter is similar to ``transparent_hugepage`` and has the following
format:

transparent_hugepage_shmem=

where  is one of the seven valid policies available for
shmem.

Configuring the default huge page allocation policy for the internal
shmem mount can be beneficial for DRM GPU drivers. Just as CPU
architectures, GPUs can also take advantage of huge pages, but this is
possible only if DRM GEM objects are backed by huge pages.

Since GEM uses shmem to allocate anonymous pageable memory, having control
over the default huge page allocation policy allows for the exploration of
huge pages use on GPUs that rely on GEM objects backed by shmem.

Signed-off-by: Maíra Canal 
Reviewed-by: Baolin Wang 
Acked-by: David Hildenbrand 
---
 .../admin-guide/kernel-parameters.txt |  7 ++
 Documentation/admin-guide/mm/transhuge.rst|  6 ++
 mm/shmem.c| 72 +--
 3 files changed, 62 insertions(+), 23 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1666576acc0e..acabb04d0dd4 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6926,6 +6926,13 @@
See Documentation/admin-guide/mm/transhuge.rst
for more details.
 
+   transparent_hugepage_shmem= [KNL]
+   Format: [always|within_size|advise|never|deny|force]
+   Can be used to control the hugepage allocation policy 
for
+   the internal shmem mount.
+   See Documentation/admin-guide/mm/transhuge.rst
+   for more details.
+
trusted.source= [KEYS]
Format: 
This parameter identifies the trust source as a backend
diff --git a/Documentation/admin-guide/mm/transhuge.rst 
b/Documentation/admin-guide/mm/transhuge.rst
index abdf10a1c7db..9c6f6da612c4 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -326,6 +326,12 @@ PMD_ORDER THP policy will be overridden. If the policy for 
PMD_ORDER
 is not defined within a valid ``thp_anon``, its policy will default to
 ``never``.
 
+Similarly to ``transparent_hugepage``, you can control the hugepage
+allocation policy for the internal shmem mount by using the kernel parameter
+``transparent_hugepage_shmem=``, where  is one of the
+seven valid policies for shmem (``always``, ``within_size``, ``advise``,
+``never``, ``deny``, and ``force``).
+
 Hugepages in tmpfs/shmem
 
 
diff --git a/mm/shmem.c b/mm/shmem.c
index 275251abd596..dfcc88ec6e34 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -582,24 +582,39 @@ static bool shmem_huge_global_enabled(struct inode 
*inode, pgoff_t index,
}
 }
 
-#if defined(CONFIG_SYSFS)
 static int shmem_parse_huge(const char *str)
 {
+   int huge;
+
+   if (!str)
+   return -EINVAL;
+
if (!strcmp(str, "never"))
-   return SHMEM_HUGE_NEVER;
-   if (!strcmp(str, "always"))
-   return SHMEM_HUGE_ALWAYS;
-   if (!strcmp(str, "within_size"))
-   return SHMEM_HUGE_WITHIN_SIZE;
-   if (!strcmp(str, "advise"))
-   return SHMEM_HUGE_ADVISE;
-   if (!strcmp(str, "deny"))
-   return SHMEM_HUGE_DENY;
-   if (!strcmp(str, "force"))
-   return SHMEM_HUGE_FORCE;
-   return -EINVAL;
+   huge = SHMEM_HUGE_NEVER;
+   else if (!strcmp(str, "always"))
+   huge = SHMEM_HUGE_ALWAYS;
+   else if (!strcmp(str, "within_size"))
+   huge = SHMEM_HUGE_WITHIN_SIZE;
+   else if (!strcmp(str, "advise"))
+   huge = SHMEM_HUGE_ADVISE;
+   else if (!strcmp(str, "deny"))
+   huge = SHMEM_HUGE_DENY;
+   else if (!strcmp(str, "force"))
+   huge = SHMEM_HUGE_FORCE;
+   else
+   return -EINVAL;
+
+   if (!has_transparent_hugepage() &&
+   huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY)
+   return -EINVAL;
+
+   /* Do not override huge allocation policy with non-PMD sized mTHP */
+   if (huge == SHMEM_HUGE_FORCE &&
+   huge_shmem_orders_inherit != BIT(HPAGE_PMD_ORDER))
+   return -EINVAL;
+
+   return huge;
 }
-#endif
 
 #if defined(CONFIG_SYSFS) || defined(CONFIG_TMPFS)
 static const char *shmem_format_huge(int huge)
@@ -5066,15 +5081,7 @@ static ssize_t shmem_enabled_store(struct kobject *kobj,
 
huge = shmem_parse_huge(tmp);
if (huge == -EINVAL)
-   return -EINVAL;
-   if (!has_transparent_hugepage() &&
-   huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY)
-   retu

[PATCH v5 4/5] mm: shmem: override mTHP shmem default with a kernel parameter

[Maíra Canal]

Add the ``thp_shmem=`` kernel command line to allow specifying the
default policy of each supported shmem hugepage size. The kernel parameter
accepts the following format:

thp_shmem=[KMG],[KMG]:;[KMG]-[KMG]:

For example,

thp_shmem=16K-64K:always;128K,512K:inherit;256K:advise;1M-2M:never;4M-8M:within_size

Some GPUs may benefit from using huge pages. Since DRM GEM uses shmem
to allocate anonymous pageable memory, it’s essential to control the huge
page allocation policy for the internal shmem mount. This control can be
achieved through the ``transparent_hugepage_shmem=`` parameter.

Beyond just setting the allocation policy, it’s crucial to have granular
control over the size of huge pages that can be allocated. The GPU may
support only specific huge page sizes, and allocating pages larger/smaller
than those sizes would be ineffective.

Signed-off-by: Maíra Canal 
---
 .../admin-guide/kernel-parameters.txt |  10 ++
 Documentation/admin-guide/mm/transhuge.rst|  17 +++
 mm/shmem.c| 105 +-
 3 files changed, 131 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index acabb04d0dd4..b48d744d99b0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6700,6 +6700,16 @@
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
 
+   thp_shmem=  [KNL]
+   Format: 
[KMG],[KMG]:;[KMG]-[KMG]:
+   Control the default policy of each hugepage size for the
+   internal shmem mount.  is one of policies 
available
+   for the shmem mount ("always", "inherit", "never", 
"within_size",
+   and "advise").
+   It can be used multiple times for multiple shmem THP 
sizes.
+   See Documentation/admin-guide/mm/transhuge.rst for more
+   details.
+
topology=   [S390,EARLY]
Format: {off | on}
Specify if the kernel should make use of the cpu
diff --git a/Documentation/admin-guide/mm/transhuge.rst 
b/Documentation/admin-guide/mm/transhuge.rst
index 9c6f6da612c4..5034915f4e8e 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -332,6 +332,23 @@ allocation policy for the internal shmem mount by using 
the kernel parameter
 seven valid policies for shmem (``always``, ``within_size``, ``advise``,
 ``never``, ``deny``, and ``force``).
 
+In the same manner as ``thp_anon`` controls each supported anonymous THP
+size, ``thp_shmem`` controls each supported shmem THP size. ``thp_shmem``
+has the same format as ``thp_anon``, but also supports the policy
+``within_size``.
+
+``thp_shmem=`` may be specified multiple times to configure all THP sizes
+as required. If ``thp_shmem=`` is specified at least once, any shmem THP
+sizes not explicitly configured on the command line are implicitly set to
+``never``.
+
+``transparent_hugepage_shmem`` setting only affects the global toggle. If
+``thp_shmem`` is not specified, PMD_ORDER hugepage will default to
+``inherit``. However, if a valid ``thp_shmem`` setting is provided by the
+user, the PMD_ORDER hugepage policy will be overridden. If the policy for
+PMD_ORDER is not defined within a valid ``thp_shmem``, its policy will
+default to ``never``.
+
 Hugepages in tmpfs/shmem
 
 
diff --git a/mm/shmem.c b/mm/shmem.c
index dfcc88ec6e34..d2bf98aece40 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -136,6 +136,7 @@ static unsigned long huge_shmem_orders_always __read_mostly;
 static unsigned long huge_shmem_orders_madvise __read_mostly;
 static unsigned long huge_shmem_orders_inherit __read_mostly;
 static unsigned long huge_shmem_orders_within_size __read_mostly;
+static bool shmem_orders_configured __initdata;
 #endif
 
 #ifdef CONFIG_TMPFS
@@ -5027,7 +5028,8 @@ void __init shmem_init(void)
 * Default to setting PMD-sized THP to inherit the global setting and
 * disable all other multi-size THPs.
 */
-   huge_shmem_orders_inherit = BIT(HPAGE_PMD_ORDER);
+   if (!shmem_orders_configured)
+   huge_shmem_orders_inherit = BIT(HPAGE_PMD_ORDER);
 #endif
return;
 
@@ -5195,6 +5197,107 @@ static int __init setup_transparent_hugepage_shmem(char 
*str)
 }
 __setup("transparent_hugepage_shmem=", setup_transparent_hugepage_shmem);
 
+static char str_dup[PAGE_SIZE] __initdata;
+static int __init setup_thp_shmem(char *str)
+{
+   char *token, *range, *policy, *subtoken;
+   unsigned long always, inherit, madvise, within_size;
+   char *start_size, *end_size;
+   int start, end, nr;
+   char *p;
+
+   if (!str || strlen(str) + 1 > PAGE_SIZE)
+

[PATCH v5 5/5] mm: huge_memory: Use strscpy() instead of strcpy()

[Maíra Canal]

Replace strcpy() with strscpy() in mm/huge_memory.c

strcpy() has been deprecated because it is generally unsafe, so help to
eliminate it from the kernel source.

Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Maíra Canal 
Reviewed-by: Lance Yang 
---
 mm/huge_memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a6edbd8c4f49..1ebe18ec4560 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -969,7 +969,7 @@ static int __init setup_thp_anon(char *str)
 
if (!str || strlen(str) + 1 > PAGE_SIZE)
goto err;
-   strcpy(str_dup, str);
+   strscpy(str_dup, str);
 
always = huge_anon_orders_always;
madvise = huge_anon_orders_madvise;
@@ -4167,7 +4167,7 @@ static ssize_t split_huge_pages_write(struct file *file, 
const char __user *buf,
 
tok = strsep(&buf, ",");
if (tok) {
-   strcpy(file_path, tok);
+   strscpy(file_path, tok);
} else {
ret = -EINVAL;
goto out;
-- 
2.46.2

[PATCH v4 4/5] mm: shmem: override mTHP shmem default with a kernel parameter

[Maíra Canal]

Add the ``thp_shmem=`` kernel command line to allow specifying the
default policy of each supported shmem hugepage size. The kernel parameter
accepts the following format:

thp_shmem=[KMG],[KMG]:;[KMG]-[KMG]:

For example,

thp_shmem=16K-64K:always;128K,512K:inherit;256K:advise;1M-2M:never;4M-8M:within_size

Some GPUs may benefit from using huge pages. Since DRM GEM uses shmem
to allocate anonymous pageable memory, it’s essential to control the huge
page allocation policy for the internal shmem mount. This control can be
achieved through the ``transparent_hugepage_shmem=`` parameter.

Beyond just setting the allocation policy, it’s crucial to have granular
control over the size of huge pages that can be allocated. The GPU may
support only specific huge page sizes, and allocating pages larger/smaller
than those sizes would be ineffective.

Signed-off-by: Maíra Canal 
---
 .../admin-guide/kernel-parameters.txt |  10 ++
 Documentation/admin-guide/mm/transhuge.rst|  17 +++
 mm/shmem.c| 105 +-
 3 files changed, 131 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index acabb04d0dd4..b48d744d99b0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6700,6 +6700,16 @@
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
 
+   thp_shmem=  [KNL]
+   Format: 
[KMG],[KMG]:;[KMG]-[KMG]:
+   Control the default policy of each hugepage size for the
+   internal shmem mount.  is one of policies 
available
+   for the shmem mount ("always", "inherit", "never", 
"within_size",
+   and "advise").
+   It can be used multiple times for multiple shmem THP 
sizes.
+   See Documentation/admin-guide/mm/transhuge.rst for more
+   details.
+
topology=   [S390,EARLY]
Format: {off | on}
Specify if the kernel should make use of the cpu
diff --git a/Documentation/admin-guide/mm/transhuge.rst 
b/Documentation/admin-guide/mm/transhuge.rst
index 9c6f6da612c4..5034915f4e8e 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -332,6 +332,23 @@ allocation policy for the internal shmem mount by using 
the kernel parameter
 seven valid policies for shmem (``always``, ``within_size``, ``advise``,
 ``never``, ``deny``, and ``force``).
 
+In the same manner as ``thp_anon`` controls each supported anonymous THP
+size, ``thp_shmem`` controls each supported shmem THP size. ``thp_shmem``
+has the same format as ``thp_anon``, but also supports the policy
+``within_size``.
+
+``thp_shmem=`` may be specified multiple times to configure all THP sizes
+as required. If ``thp_shmem=`` is specified at least once, any shmem THP
+sizes not explicitly configured on the command line are implicitly set to
+``never``.
+
+``transparent_hugepage_shmem`` setting only affects the global toggle. If
+``thp_shmem`` is not specified, PMD_ORDER hugepage will default to
+``inherit``. However, if a valid ``thp_shmem`` setting is provided by the
+user, the PMD_ORDER hugepage policy will be overridden. If the policy for
+PMD_ORDER is not defined within a valid ``thp_shmem``, its policy will
+default to ``never``.
+
 Hugepages in tmpfs/shmem
 
 
diff --git a/mm/shmem.c b/mm/shmem.c
index dfcc88ec6e34..d2bf98aece40 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -136,6 +136,7 @@ static unsigned long huge_shmem_orders_always __read_mostly;
 static unsigned long huge_shmem_orders_madvise __read_mostly;
 static unsigned long huge_shmem_orders_inherit __read_mostly;
 static unsigned long huge_shmem_orders_within_size __read_mostly;
+static bool shmem_orders_configured __initdata;
 #endif
 
 #ifdef CONFIG_TMPFS
@@ -5027,7 +5028,8 @@ void __init shmem_init(void)
 * Default to setting PMD-sized THP to inherit the global setting and
 * disable all other multi-size THPs.
 */
-   huge_shmem_orders_inherit = BIT(HPAGE_PMD_ORDER);
+   if (!shmem_orders_configured)
+   huge_shmem_orders_inherit = BIT(HPAGE_PMD_ORDER);
 #endif
return;
 
@@ -5195,6 +5197,107 @@ static int __init setup_transparent_hugepage_shmem(char 
*str)
 }
 __setup("transparent_hugepage_shmem=", setup_transparent_hugepage_shmem);
 
+static char str_dup[PAGE_SIZE] __initdata;
+static int __init setup_thp_shmem(char *str)
+{
+   char *token, *range, *policy, *subtoken;
+   unsigned long always, inherit, madvise, within_size;
+   char *start_size, *end_size;
+   int start, end, nr;
+   char *p;
+
+   if (!str || strlen(str) + 1 > PAGE_SIZE)
+

[PATCH v4 5/5] mm: huge_memory: Use strscpy() instead of strcpy()

[Maíra Canal]

Replace strcpy() with strscpy() in mm/huge_memory.c

strcpy() has been deprecated because it is generally unsafe, so help to
eliminate it from the kernel source.

Link: https://github.com/KSPP/linux/issues/88
Signed-off-by: Maíra Canal 
Reviewed-by: Lance Yang 
---
 mm/huge_memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a6edbd8c4f49..1ebe18ec4560 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -969,7 +969,7 @@ static int __init setup_thp_anon(char *str)
 
if (!str || strlen(str) + 1 > PAGE_SIZE)
goto err;
-   strcpy(str_dup, str);
+   strscpy(str_dup, str);
 
always = huge_anon_orders_always;
madvise = huge_anon_orders_madvise;
@@ -4167,7 +4167,7 @@ static ssize_t split_huge_pages_write(struct file *file, 
const char __user *buf,
 
tok = strsep(&buf, ",");
if (tok) {
-   strcpy(file_path, tok);
+   strscpy(file_path, tok);
} else {
ret = -EINVAL;
goto out;
-- 
2.46.2

[PATCH v4 3/5] mm: move ``get_order_from_str()`` to internal.h

[Maíra Canal]

From: Maíra Canal 

In order to implement a kernel parameter similar to ``thp_anon=`` for
shmem, we'll need the function ``get_order_from_str()``.

Instead of duplicating the function, move the function to a shared
header, in which both mm/shmem.c and mm/huge_memory.c will be able to
use it.

Signed-off-by: Maíra Canal 
---
 mm/huge_memory.c | 38 +++---
 mm/internal.h| 22 ++
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f92068864469..a6edbd8c4f49 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -958,26 +958,6 @@ static int __init setup_transparent_hugepage(char *str)
 }
 __setup("transparent_hugepage=", setup_transparent_hugepage);
 
-static inline int get_order_from_str(const char *size_str)
-{
-   unsigned long size;
-   char *endptr;
-   int order;
-
-   size = memparse(size_str, &endptr);
-
-   if (!is_power_of_2(size))
-   goto err;
-   order = get_order(size);
-   if (BIT(order) & ~THP_ORDERS_ALL_ANON)
-   goto err;
-
-   return order;
-err:
-   pr_err("invalid size %s in thp_anon boot parameter\n", size_str);
-   return -EINVAL;
-}
-
 static char str_dup[PAGE_SIZE] __initdata;
 static int __init setup_thp_anon(char *str)
 {
@@ -1007,10 +987,22 @@ static int __init setup_thp_anon(char *str)
start_size = strsep(&subtoken, "-");
end_size = subtoken;
 
-   start = get_order_from_str(start_size);
-   end = get_order_from_str(end_size);
+   start = get_order_from_str(start_size, 
THP_ORDERS_ALL_ANON);
+   end = get_order_from_str(end_size, 
THP_ORDERS_ALL_ANON);
} else {
-   start = end = get_order_from_str(subtoken);
+   start_size = end_size = subtoken;
+   start = end = get_order_from_str(subtoken,
+
THP_ORDERS_ALL_ANON);
+   }
+
+   if (start == -EINVAL) {
+   pr_err("invalid size %s in thp_anon boot 
parameter\n", start_size);
+   goto err;
+   }
+
+   if (end == -EINVAL) {
+   pr_err("invalid size %s in thp_anon boot 
parameter\n", end_size);
+   goto err;
}
 
if (start < 0 || end < 0 || start > end)
diff --git a/mm/internal.h b/mm/internal.h
index d5b93c5b6364..5a7302baeed7 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -1291,6 +1291,28 @@ static inline bool alloc_zeroed(void)
&init_on_alloc);
 }
 
+/*
+ * Parses a string with mem suffixes into its order. Useful to parse kernel
+ * parameters.
+ */
+static inline int get_order_from_str(const char *size_str,
+unsigned long valid_orders)
+{
+   unsigned long size;
+   char *endptr;
+   int order;
+
+   size = memparse(size_str, &endptr);
+
+   if (!is_power_of_2(size))
+   return -EINVAL;
+   order = get_order(size);
+   if (BIT(order) & ~valid_orders)
+   return -EINVAL;
+
+   return order;
+}
+
 enum {
/* mark page accessed */
FOLL_TOUCH = 1 << 16,
-- 
2.46.2

[PATCH v4 0/5] mm: add more kernel parameters to control mTHP

[Maíra Canal]

This series introduces four patches related to the kernel parameters
controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
in the file `mm/huge_memory.c`.

The first patch is a straightforward documentation update, correcting
the format of the kernel parameter ``thp_anon=``.

The second, third, and fourth patches focus on controlling THP support for
shmem via the kernel command line. The second patch introduces a parameter to
control the global default huge page allocation policy for the internal
shmem mount. The third patch moves a piece of code to a shared header to ease
the implementation of the fourth patch. Finally, the fourth patch implements
a parameter similar to ``thp_anon=``, but for shmem.

The goal of these changes is to simplify the configuration of systems that
rely on mTHP support for shmem. For instance, a platform with a GPU that
benefits from huge pages may want to enable huge pages for shmem. Having
these kernel parameters streamlines the configuration process and ensures
consistency across setups.

Let me know your thoughts.

v1 -> v2: 
https://lore.kernel.org/linux-mm/20241027175743.1056710-1-mca...@igalia.com/T/

* [1/3] s/fix the format/fix the doc in the commit's subject (Barry Song &
David Hildenbrand)
* [1/3] Add Barry's A-b to PATCH 1/3 (Barry Song)
* [1/3] s/64KB/64K (David Hildenbrand)
* [1/3] Add David's A-b to PATCH 1/3 (David Hildenbrand)
* [2/3] Create the function `shmem_valid_huge()` to reduce code-duplication
(Baolin Wang)
* [3/4] New PATCH: generalize the function `setup_thp_anon()` and add it to
common file
* [4/4] Fix typo in the documentation: s/shmem_anon/thp_shmem (Barry Song)
* [4/4] Reduce code-duplication (Barry Song)

v2 -> v3: 
https://lore.kernel.org/linux-mm/20241029002324.1062723-1-mca...@igalia.com/T/

* [2/4] Apply Wang's suggestion (Baolin Wang)
* [3/4] Delete PATCH 3/4 from v2 and implement ``thp_shmem=`` just like in v1
(Barry Song)
* [4/4] New PATCH: "mm: huge_memory: Use strscpy() instead of strcpy()"

v3 -> v4: 
https://lore.kernel.org/linux-mm/20241030130308.1066299-1-mca...@igalia.com/T/

* [2/5] Improve commit message by including details about the use of the kernel
parameter (Andrew Morton)
* [2/5] Add Baolin's R-b to PATCH 2/5 (Baolin Wang)
* [2/5] Add David's R-b to PATCH 2/5 (David Hildenbrand)
* [3/5] New PATCH: "mm: move ``get_order_from_str()`` to internal.h" (Barry Song
& David Hildenbrand)
* [4/5] Improve commit message by including details about the use of the kernel
parameter (Andrew Morton)
* [5/5] Add Lance's R-b to PATCH 5/5 (Lance Yang)

Best Regards,
- Maíra

Maíra Canal (5):
  mm: fix docs for the kernel parameter ``thp_anon=``
  mm: shmem: control THP support through the kernel command line
  mm: move ``get_order_from_str()`` to internal.h
  mm: shmem: override mTHP shmem default with a kernel parameter
  mm: huge_memory: Use strscpy() instead of strcpy()

 .../admin-guide/kernel-parameters.txt |  19 +-
 Documentation/admin-guide/mm/transhuge.rst|  25 ++-
 mm/huge_memory.c  |  42 ++---
 mm/internal.h |  22 +++
 mm/shmem.c| 177 +++---
 5 files changed, 234 insertions(+), 51 deletions(-)

-- 
2.46.2

[PATCH v4 2/5] mm: shmem: control THP support through the kernel command line

[Maíra Canal]

Add a new kernel command line to control the hugepage allocation policy
for the internal shmem mount, ``transparent_hugepage_shmem``. The
parameter is similar to ``transparent_hugepage`` and has the following
format:

transparent_hugepage_shmem=

where  is one of the seven valid policies available for
shmem.

Configuring the default huge page allocation policy for the internal
shmem mount can be beneficial for DRM GPU drivers. Just as CPU
architectures, GPUs can also take advantage of huge pages, but this is
possible only if DRM GEM objects are backed by huge pages.

Since GEM uses shmem to allocate anonymous pageable memory, having control
over the default huge page allocation policy allows for the exploration of
huge pages use on GPUs that rely on GEM objects backed by shmem.

Signed-off-by: Maíra Canal 
Reviewed-by: Baolin Wang 
Acked-by: David Hildenbrand 
---
 .../admin-guide/kernel-parameters.txt |  7 ++
 Documentation/admin-guide/mm/transhuge.rst|  6 ++
 mm/shmem.c| 72 +--
 3 files changed, 62 insertions(+), 23 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1666576acc0e..acabb04d0dd4 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6926,6 +6926,13 @@
See Documentation/admin-guide/mm/transhuge.rst
for more details.
 
+   transparent_hugepage_shmem= [KNL]
+   Format: [always|within_size|advise|never|deny|force]
+   Can be used to control the hugepage allocation policy 
for
+   the internal shmem mount.
+   See Documentation/admin-guide/mm/transhuge.rst
+   for more details.
+
trusted.source= [KEYS]
Format: 
This parameter identifies the trust source as a backend
diff --git a/Documentation/admin-guide/mm/transhuge.rst 
b/Documentation/admin-guide/mm/transhuge.rst
index abdf10a1c7db..9c6f6da612c4 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -326,6 +326,12 @@ PMD_ORDER THP policy will be overridden. If the policy for 
PMD_ORDER
 is not defined within a valid ``thp_anon``, its policy will default to
 ``never``.
 
+Similarly to ``transparent_hugepage``, you can control the hugepage
+allocation policy for the internal shmem mount by using the kernel parameter
+``transparent_hugepage_shmem=``, where  is one of the
+seven valid policies for shmem (``always``, ``within_size``, ``advise``,
+``never``, ``deny``, and ``force``).
+
 Hugepages in tmpfs/shmem
 
 
diff --git a/mm/shmem.c b/mm/shmem.c
index 275251abd596..dfcc88ec6e34 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -582,24 +582,39 @@ static bool shmem_huge_global_enabled(struct inode 
*inode, pgoff_t index,
}
 }
 
-#if defined(CONFIG_SYSFS)
 static int shmem_parse_huge(const char *str)
 {
+   int huge;
+
+   if (!str)
+   return -EINVAL;
+
if (!strcmp(str, "never"))
-   return SHMEM_HUGE_NEVER;
-   if (!strcmp(str, "always"))
-   return SHMEM_HUGE_ALWAYS;
-   if (!strcmp(str, "within_size"))
-   return SHMEM_HUGE_WITHIN_SIZE;
-   if (!strcmp(str, "advise"))
-   return SHMEM_HUGE_ADVISE;
-   if (!strcmp(str, "deny"))
-   return SHMEM_HUGE_DENY;
-   if (!strcmp(str, "force"))
-   return SHMEM_HUGE_FORCE;
-   return -EINVAL;
+   huge = SHMEM_HUGE_NEVER;
+   else if (!strcmp(str, "always"))
+   huge = SHMEM_HUGE_ALWAYS;
+   else if (!strcmp(str, "within_size"))
+   huge = SHMEM_HUGE_WITHIN_SIZE;
+   else if (!strcmp(str, "advise"))
+   huge = SHMEM_HUGE_ADVISE;
+   else if (!strcmp(str, "deny"))
+   huge = SHMEM_HUGE_DENY;
+   else if (!strcmp(str, "force"))
+   huge = SHMEM_HUGE_FORCE;
+   else
+   return -EINVAL;
+
+   if (!has_transparent_hugepage() &&
+   huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY)
+   return -EINVAL;
+
+   /* Do not override huge allocation policy with non-PMD sized mTHP */
+   if (huge == SHMEM_HUGE_FORCE &&
+   huge_shmem_orders_inherit != BIT(HPAGE_PMD_ORDER))
+   return -EINVAL;
+
+   return huge;
 }
-#endif
 
 #if defined(CONFIG_SYSFS) || defined(CONFIG_TMPFS)
 static const char *shmem_format_huge(int huge)
@@ -5066,15 +5081,7 @@ static ssize_t shmem_enabled_store(struct kobject *kobj,
 
huge = shmem_parse_huge(tmp);
if (huge == -EINVAL)
-   return -EINVAL;
-   if (!has_transparent_hugepage() &&
-   huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY)
-   retu

[PATCH v4 1/5] mm: fix docs for the kernel parameter ``thp_anon=``

[Maíra Canal]

If we add ``thp_anon=32,64K:always`` to the kernel command line, we
will see the following error:

[0.00] huge_memory: thp_anon=32,64K:always: error parsing string, 
ignoring setting

This happens because the correct format isn't 
``thp_anon=,[KMG]:```,
as [KMG] must follow each number to especify its unit. So, the correct
format is ``thp_anon=[KMG],[KMG]:```.

Therefore, adjust the documentation to reflect the correct format of the
parameter ``thp_anon=``.

Fixes: dd4d30d1cdbe ("mm: override mTHP "enabled" defaults at kernel cmdline")
Signed-off-by: Maíra Canal 
Acked-by: Barry Song 
Acked-by: David Hildenbrand 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 +-
 Documentation/admin-guide/mm/transhuge.rst  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1518343bbe22..1666576acc0e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6688,7 +6688,7 @@
0: no polling (default)
 
thp_anon=   [KNL]
-   Format: 
,[KMG]:;-[KMG]:
+   Format: 
[KMG],[KMG]:;[KMG]-[KMG]:
state is one of "always", "madvise", "never" or 
"inherit".
Control the default behavior of the system with respect
to anonymous transparent hugepages.
diff --git a/Documentation/admin-guide/mm/transhuge.rst 
b/Documentation/admin-guide/mm/transhuge.rst
index 5caa3fb2feb1..abdf10a1c7db 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -303,7 +303,7 @@ control by passing the parameter 
``transparent_hugepage=always`` or
 kernel command line.
 
 Alternatively, each supported anonymous THP size can be controlled by
-passing ``thp_anon=,[KMG]:;-[KMG]:``,
+passing 
``thp_anon=[KMG],[KMG]:;[KMG]-[KMG]:``,
 where  is the THP size (must be a power of 2 of PAGE_SIZE and
 supported anonymous THP)  and  is one of ``always``, ``madvise``,
 ``never`` or ``inherit``.
-- 
2.46.2

Re: [PATCH RFC 1/4] drm/dp: Add helper to set LTTPRs in transparent mode

[Imre Deak]

On Fri, Nov 01, 2024 at 11:22:13AM +0200, Jani Nikula wrote:
> On Thu, 31 Oct 2024, Imre Deak  wrote:
> > On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> >> According to the DisplayPort standard, LTTPRs have two operating
> >> modes:
> >>  - non-transparent - it replies to DPCD LTTPR field specific AUX
> >>requests, while passes through all other AUX requests
> >>  - transparent - it passes through all AUX requests.
> >> 
> >> Switching between this two modes is done by the DPTX by issuing
> >> an AUX write to the DPCD PHY_REPEATER_MODE register.
> >> 
> >> Add a generic helper that allows switching between these modes.
> >> 
> >> Signed-off-by: Abel Vesa 
> >> ---
> >>  drivers/gpu/drm/display/drm_dp_helper.c | 17 +
> >>  include/drm/display/drm_dp_helper.h |  1 +
> >>  2 files changed, 18 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
> >> b/drivers/gpu/drm/display/drm_dp_helper.c
> >> index 
> >> 6ee51003de3ce616c3a52653c2f1979ad7658e21..38d612345986ad54b42228902ea718a089d169c4
> >>  100644
> >> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> >> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> >> @@ -2694,6 +2694,23 @@ int drm_dp_lttpr_max_link_rate(const u8 
> >> caps[DP_LTTPR_COMMON_CAP_SIZE])
> >>  }
> >>  EXPORT_SYMBOL(drm_dp_lttpr_max_link_rate);
> >>  
> >> +/**
> >> + * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
> >> + * @aux: DisplayPort AUX channel
> >> + * @enable: Enable or disable transparent mode
> >> + *
> >> + * Returns 0 on success or a negative error code on failure.
> >
> > Should be "Returns 1 on success".
> 
> But is that a sensible return value?

It matches what the function returns, but yes, would make more sense to
fix the return value instead to be 0 in case of success.

> >
> >> + */
> >> +
> 
> Superfluous newline.
> 
> >> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool enable)
> >> +{
> >> +  u8 val = enable ? DP_PHY_REPEATER_MODE_TRANSPARENT :
> >> +DP_PHY_REPEATER_MODE_NON_TRANSPARENT;
> >> +
> >> +  return drm_dp_dpcd_writeb(aux, DP_PHY_REPEATER_MODE, val);
> >> +}
> >> +EXPORT_SYMBOL(drm_dp_lttpr_set_transparent_mode);
> >> +
> >>  /**
> >>   * drm_dp_lttpr_max_lane_count - get the maximum lane count supported by 
> >> all LTTPRs
> >>   * @caps: LTTPR common capabilities
> >> diff --git a/include/drm/display/drm_dp_helper.h 
> >> b/include/drm/display/drm_dp_helper.h
> >> index 
> >> 279624833ea9259809428162f4e845654359f8c9..8821ab2d36b0e04d38ccbdddcb703b34de7ed680
> >>  100644
> >> --- a/include/drm/display/drm_dp_helper.h
> >> +++ b/include/drm/display/drm_dp_helper.h
> >> @@ -625,6 +625,7 @@ int drm_dp_read_lttpr_phy_caps(struct drm_dp_aux *aux,
> >>   u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
> >>  int drm_dp_lttpr_count(const u8 cap[DP_LTTPR_COMMON_CAP_SIZE]);
> >>  int drm_dp_lttpr_max_link_rate(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
> >> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool 
> >> enable);
> >>  int drm_dp_lttpr_max_lane_count(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
> >>  bool drm_dp_lttpr_voltage_swing_level_3_supported(const u8 
> >> caps[DP_LTTPR_PHY_CAP_SIZE]);
> >>  bool drm_dp_lttpr_pre_emphasis_level_3_supported(const u8 
> >> caps[DP_LTTPR_PHY_CAP_SIZE]);
> >> 
> >> -- 
> >> 2.34.1
> >> 
> 
> -- 
> Jani Nikula, Intel

Re: [PATCH v5 5/6] drm/log: Implement suspend/resume

[Petr Mladek]

On Fri 2024-10-25 11:46:16, Jocelyn Falempe wrote:
> On 25/10/2024 01:11, Jocelyn Falempe wrote:
> > On 24/10/2024 16:34, Petr Mladek wrote:
> > > On Wed 2024-10-23 14:00:13, Jocelyn Falempe wrote:
> > > > The console is already suspended in printk.c.
> > > 
> > > Does this mean that drm_log_client_suspend() is called
> > > after suspend_console(), please?
> > 
> > To be honest, I wasn't able to tell which one is called first, and if
> > the order is enforced (I didn't check if drivers can be suspended in
> > parallel, or if it's all sequential)..
> > 
> > I then checked if it's possible to suspend the console, but didn't found
> > an easy API to do so, so I went with this lazy patch, just ensuring
> > we're not writing to a suspended graphic driver.
> 
> I've run some tests on my hardware, and the console is suspended before the
> graphic driver:
> 
> [   56.409604] printk: Suspending console(s) (use no_console_suspend to
> debug)
> [   56.411430] serial 00:05: disabled
> [   56.421877] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [   56.421954] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
> [   56.422545] ata1.00: Entering standby power mode
> [   56.422793] DRM log suspend
> 
> But because there is the "no_console_suspend" parameter, and we should make
> sure to not draw when the graphic driver is suspended, I think this patch is
> needed, and good enough.
> I will just rephrase the commit message, to make it clear, that some message
> won't be drawn, only if "no_console_suspend" is set.

Ah, I forgot about the "no_console_suspend" parameter. The problem
with this patch is that it would quietly drop all pending messages.

drm_log_write_thread() does not have any return value.
nbcon_emit_next_record() would assume that the message was printed.
And the kthread would continue emitting next message...

In compare, CON_SUSPENDED would cause that console_is_usable()
returns false. As a result, nbcon_kthread_func() would not try
to emit any message and go into a sleep.

If we set CON_SUSPENDED then the pending messages will get printed
after the resume. If we use this patch, the messages would get lost.


This is why I am not happy with this patch. I would prefer to
block the console. I see three better solutions:

  1. Set CON_SUSPENDED from drm_log_client_suspend even when
 "no_console_suspend" is used.

 It is a bit dirty and might cause some confusion.


  2. Add a new flag, e.g. CON_BLOCKED or CON_DRIVER_BLOCKED,
 which might be used for this purpose.


  3. Allow con->write_thread() to return an error code.

 The question is how exactly the error should be handled.
 The kthread would not know when the printing might succeed
 again.


I personally prefer the 2nd variant.


Best Regards,
Petr

PS: I am sorry for the late reply. I had vacation...

Re: [PATCH v2] drm/xe: Fix build error for XE_IOCTL_DBG macro

[Lucas De Marchi]

On Tue, Oct 29, 2024 at 05:48:58PM +0900, Gyeyoung Baek wrote:

if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement.
so in the previous code, there are the following build errors.

include/linux/dynamic_debug.h:221:58: error: expected expression before ‘do’
 221 | #define __dynamic_func_call_cls(id, cls, fmt, func, ...) do {   \
 |  ^~
include/linux/dynamic_debug.h:248:9: note: in expansion of macro 
‘__dynamic_func_call_cls’
 248 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, 
##__VA_ARGS__)
 | ^~~
include/drm/drm_print.h:425:9: note: in expansion of macro 
‘_dynamic_func_call_cls’
 425 | _dynamic_func_call_cls(cat, fmt, __drm_dev_dbg, \
 | ^~
include/drm/drm_print.h:504:9: note: in expansion of macro ‘drm_dev_dbg’
 504 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
 | ^~~
include/drm/drm_print.h:522:33: note: in expansion of macro ‘drm_dbg_driver’
 522 | #define drm_dbg(drm, fmt, ...)  drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
 | ^~
drivers/gpu/drm/xe/xe_macros.h:14:21: note: in expansion of macro ‘drm_dbg’
  14 | ((cond) && (drm_dbg(&(xe)->drm, \
 | ^~~
drivers/gpu/drm/xe/xe_bo.c:2029:13: note: in expansion of macro ‘XE_IOCTL_DBG’
2029 | if (XE_IOCTL_DBG(xe, !gem_obj))

the problem is that,
XE_IOCTL_DBG uses this function for conditional expr.

so I fix the expr to be compatible with the do while statement,
by referring to "https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html";.

v2: I modified this to print when only cond is true.

Signed-off-by: Gyeyoung Baek 
---
drivers/gpu/drm/xe/xe_macros.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_macros.h b/drivers/gpu/drm/xe/xe_macros.h
index daf56c846d03..ac2bd103bb22 100644
--- a/drivers/gpu/drm/xe/xe_macros.h
+++ b/drivers/gpu/drm/xe/xe_macros.h
@@ -11,8 +11,12 @@
#define XE_WARN_ON WARN_ON

#define XE_IOCTL_DBG(xe, cond) \
-   ((cond) && (drm_dbg(&(xe)->drm, \
-   "Ioctl argument check failed at %s:%d: %s", \
-   __FILE__, __LINE__, #cond), 1))
+({ \
+   if ((cond)) \
+   drm_dbg(&(xe)->drm, \
+   "Ioctl argument check failed at %s:%d: %s", \
+   __FILE__, __LINE__, #cond); \
+   (cond); \


there's a double cond evaluation here and given any expression can be
given to XE_IOCTL_DBG(), this doens't look very safe. I think this would
be safer as:

#define XE_IOCTL_DBG(xe, cond) ({   \
int cond__ = !!(cond);  \
if (cond__) \
drm_dbg(&(xe)->drm, \
"Ioctl argument check failed at %s:%d: %s", \
__FILE__, __LINE__, #cond); \
cond__; \
})

as it then evaluates cond just once. Also the generated code seems to be
sane compared to what we had before too.

And I also needed this to build-test:

| diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
| index 08cfea04e22bd..82585d442f017 100644
| --- a/drivers/gpu/drm/drm_print.c
| +++ b/drivers/gpu/drm/drm_print.c
| @@ -215,9 +215,8 @@ void __drm_printfn_dbg(struct drm_printer *p, struct 
va_format *vaf)
|  {
| const struct drm_device *drm = p->arg;
| const struct device *dev = drm ? drm->dev : NULL;
| -   enum drm_debug_category category = p->category;
|  
| -   if (!__drm_debug_enabled(category))

| +   if (!__drm_debug_enabled(p->category))
| return;
|  
| __drm_dev_vprintk(dev, KERN_DEBUG, p->origin, p->prefix, vaf);


as otherwise it complains category is unused.

Lucas De Marchi

[PATCH v4 3/3] ARM: dts: imx6sl: Provide a more specific lcdif compatible

[Fabio Estevam]

From: Fabio Estevam 

The LCDIF IP on i.MX6SL and i.MX6SLL is compatible with i.MX6SX.

Provide a more specific "fsl,imx6sx-lcdif" compatible and still keep
"fsl,imx28-lcdif" for DT compatibility.

Signed-off-by: Fabio Estevam 
---
Changes since v3:
- None.

 arch/arm/boot/dts/nxp/imx/imx6sl.dtsi  | 3 ++-
 arch/arm/boot/dts/nxp/imx/imx6sll.dtsi | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/nxp/imx/imx6sl.dtsi 
b/arch/arm/boot/dts/nxp/imx/imx6sl.dtsi
index 6aa61235e39e..840e19b2ca0f 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sl.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sl.dtsi
@@ -773,7 +773,8 @@ epdc: epdc@20f4000 {
};
 
lcdif: lcdif@20f8000 {
-   compatible = "fsl,imx6sl-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6sl-lcdif", 
"fsl,imx6sx-lcdif",
+"fsl,imx28-lcdif";
reg = <0x020f8000 0x4000>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_LCDIF_PIX>,
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi 
b/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
index 85fe2a4ab97a..eff83f5e5535 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
@@ -648,7 +648,8 @@ pxp: pxp@20f {
};
 
lcdif: lcd-controller@20f8000 {
-   compatible = "fsl,imx6sll-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6sll-lcdif", 
"fsl,imx6sx-lcdif",
+"fsl,imx28-lcdif";
reg = <0x020f8000 0x4000>;
interrupts = ;
clocks = <&clks IMX6SLL_CLK_LCDIF_PIX>,
-- 
2.34.1

[PATCH v4 2/3] dt-bindings: lcdif: Expand the imx6sl/imx6sll fallbacks

[Fabio Estevam]

From: Fabio Estevam 

mx6sl.dtsi and imx6sll.dtsi have the following lcdif entries:

compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";

This causes dt-schema warnings as the current binding only
allow 'fsl,imx6sx-lcdif' as fallback.

['fsl,imx6sl-lcdif', 'fsl,imx28-lcdif'] is too long
['fsl,imx6sll-lcdif', 'fsl,imx28-lcdif'] is too long

The imx6sx-lcdif programming model has more advanced features, such
as overlay plane and the CRC32 support than the imx28-lcdif IP.

Expand the imx6sl/imx6sll lcdif fallbacks to accept a less specific
fsl,imx28-lcdif fallback:

compatible = "fsl,imx6sl-lcdif", "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";

This helps keeping DT compatibility as well as using the more advanced
lcdif features found on imx6sl and imx6sll.

Signed-off-by: Fabio Estevam 
---
Changes since v3:
- None.

 Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index ad0cca562463..72e509bc975b 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -23,14 +23,18 @@ properties:
   - fsl,imx93-lcdif
   - items:
   - enum:
-  - fsl,imx6sl-lcdif
-  - fsl,imx6sll-lcdif
   - fsl,imx6ul-lcdif
   - fsl,imx7d-lcdif
   - fsl,imx8mm-lcdif
   - fsl,imx8mn-lcdif
   - fsl,imx8mq-lcdif
   - const: fsl,imx6sx-lcdif
+  - items:
+  - enum:
+  - fsl,imx6sl-lcdif
+  - fsl,imx6sll-lcdif
+  - const: fsl,imx6sx-lcdif
+  - const: fsl,imx28-lcdif
   - items:
   - enum:
   - fsl,imx6sx-lcdif
-- 
2.34.1

Re: [PATCH v2] drm/bridge: Fix assignment of the of_node of the parent to aux bridge

[Laurent Pinchart]

On Fri, Nov 01, 2024 at 12:27:15PM +0200, Dmitry Baryshkov wrote:
> On Fri, 1 Nov 2024 at 11:20, Laurent Pinchart wrote:
> > On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> > > On 2024/11/1 00:23, Johan Hovold wrote:
> > > > On Thu, Oct 31, 2024 at 11:06:38PM +0800, Sui Jingfeng wrote:
> > > >
> > > >> But I think Johan do need more times to understand what exactly
> > > >> the real problem is. We do need times to investigate new method.
> > > > No, I know perfectly well what the (immediate) problem is here (I was
> > > > the one adding support for the of_node_reused flag some years back).
> > > >
> > > > I just wanted to make sure that the commit message was correct and
> > > > complete before merging (and also to figure out whether this particular
> > > > patch needed to be backported).
> > >
> > > Well under such a design, having the child device sharing the 'OF' device
> > > node with it parent device means that one parent device can *only*
> > > create one AUX bridge child device.
> > >
> > > Since If you create two or more child AUX bridge, *all* of them will
> > > call devm_drm_of_get_bridge(&auxdev->dev, auxdev->dev.of_node, 0, 0),
> > > then we will *contend* the same next bridge resource.
> > >
> > > Because of the 'auxdev->dev.of_node' is same for all its instance.
> > > While other display bridges seems don't has such limitations.
> >
> > Brainstorming a bit, I wonder if we could create a swnode for the
> > auxiliary device, instead of reusing the parent's OF node.
> 
> This will break bridge lookup which is performed by following the OF
> graph links. So the aux bridges should use corresponding of_node or
> fwnode.

We can also expand the lookup infrastructure and handle more platform
integration and driver architecture options. I'm not sure how it would
look like, but all these are in-kernel APIs, so they can be extended and
modified if needed.

> > This would
> > require switching the DRM OF-based APIs to fwnode, but that's easy and
> > mostly a mechanical change.

-- 
Regards,

Laurent Pinchart

[PATCH] drm/msm/a6xx: Add support for Adreno 612

[Akhil P Oommen]

From: Jie Zhang 

Add support for Adreno 612 GPU found in SM6150/QCS615 chipsets.
A612 falls under ADRENO_6XX_GEN1 family and is a cut down version
of A615 GPU.

A612 has a new IP called Reduced Graphics Management Unit or RGMU
which is a small state machine which helps to toggle GX GDSC
(connected to CX rail) to implement IFPC feature. It doesn't support
any other features of a full fledged GMU like clock control, resource
voting to rpmh etc. So we need linux clock driver support like other
gmu-wrapper implementations to control gpu core clock and gpu GX gdsc.
Since there is no benefit with enabling RGMU at the moment, RGMU is
entirely skipped in this patch.

Signed-off-by: Jie Zhang 
Signed-off-by: Akhil P Oommen 
---
Mesa support is already available for A612. Verified Glmark2 with
weston.

Some dependencies for the devicetree change are not yet available
in the mailing lists. I will send it out as a separate patch later.
---
 drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 15 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 28 +---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   | 11 ---
 3 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c 
b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
index 0c560e84ad5a..234083b69844 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
@@ -704,6 +704,21 @@ static const struct adreno_info a6xx_gpus[] = {
{ 157, 3 },
{ 127, 4 },
),
+   }, {
+   .chip_ids = ADRENO_CHIP_IDS(0x06010200),
+   .family = ADRENO_6XX_GEN1,
+   .fw = {
+   [ADRENO_FW_SQE] = "a630_sqe.fw",
+   },
+   .gmem = (SZ_128K + SZ_4K),
+   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+   .init = a6xx_gpu_init,
+   .a6xx = &(const struct a6xx_info) {
+   .hwcg = a612_hwcg,
+   .protect = &a630_protect,
+   .gmu_cgc_mode = 0x0022,
+   .prim_fifo_threshold = 0x0008,
+   },
}, {
.chip_ids = ADRENO_CHIP_IDS(0x06010500),
.family = ADRENO_6XX_GEN1,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 019610341df1..f69607267262 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -504,15 +504,26 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
 
if (adreno_is_a630(adreno_gpu))
clock_cntl_on = 0x8aa8aa02;
-   else if (adreno_is_a610(adreno_gpu))
+   else if (adreno_is_a610(adreno_gpu) || adreno_is_a612(adreno_gpu))
clock_cntl_on = 0xaaa8aa82;
else if (adreno_is_a702(adreno_gpu))
clock_cntl_on = 0xaa82;
else
clock_cntl_on = 0x8aa8aa82;
 
-   cgc_delay = adreno_is_a615_family(adreno_gpu) ? 0x111 : 0x10111;
-   cgc_hyst = adreno_is_a615_family(adreno_gpu) ? 0x555 : 0x;
+   if (adreno_is_a612(adreno_gpu))
+   cgc_delay = 0x11;
+   else if (adreno_is_a615_family(adreno_gpu))
+   cgc_delay = 0x111;
+   else
+   cgc_delay = 0x10111;
+
+   if (adreno_is_a612(adreno_gpu))
+   cgc_hyst = 0x55;
+   else if (adreno_is_a615_family(adreno_gpu))
+   cgc_delay = 0x555;
+   else
+   cgc_delay = 0x;
 
gmu_write(&a6xx_gpu->gmu, REG_A6XX_GPU_GMU_AO_GMU_CGC_MODE_CNTL,
state ? adreno_gpu->info->a6xx->gmu_cgc_mode : 0);
@@ -600,6 +611,9 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
gpu->ubwc_config.ubwc_swizzle = 0x7;
}
 
+   if (adreno_is_a612(gpu))
+   gpu->ubwc_config.highest_bank_bit = 13;
+
if (adreno_is_a618(gpu))
gpu->ubwc_config.highest_bank_bit = 14;
 
@@ -1165,7 +1179,7 @@ static int hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A6XX_CP_LPAC_PROG_FIFO_SIZE, 0x0020);
 
/* Setting the mem pool size */
-   if (adreno_is_a610(adreno_gpu)) {
+   if (adreno_is_a610(adreno_gpu) || adreno_is_a612(adreno_gpu)) {
gpu_write(gpu, REG_A6XX_CP_MEM_POOL_SIZE, 48);
gpu_write(gpu, REG_A6XX_CP_MEM_POOL_DBG_ADDR, 47);
} else if (adreno_is_a702(adreno_gpu)) {
@@ -1199,7 +1213,7 @@ static int hw_init(struct msm_gpu *gpu)
 
/* Enable fault detection */
if (adreno_is_a730(adreno_gpu) ||
-   adreno_is_a740_family(adreno_gpu))
+   adreno_is_a740_family(adreno_gpu) || adreno_is_a612(adreno_gpu))
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) 
| 0xcf);
else if (adreno_is_a690(adreno_gpu))
gpu_write(gpu, REG_A6XX_RBB

Re: [PATCH v5 0/5] mm: add more kernel parameters to control mTHP

[Andrew Morton]

On Fri,  1 Nov 2024 13:54:04 -0300 Maíra Canal  wrote:

> This series introduces four patches related to the kernel parameters
> controlling mTHP and a fifth patch replacing `strcpy()` for `strscpy()`
> in the file `mm/huge_memory.c`.

Thanks.  I extracted [1/1] from the series, as the first patch is
6.12-rcX material.

Re: [PATCH v6 7/9] drm/msm/dpu: add support for virtual planes

[Dmitry Baryshkov]

On Fri, Nov 01, 2024 at 01:37:03PM -0700, Abhinav Kumar wrote:
> 
> 
> On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:
> > On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:
> > > 
> > > 
> > > On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:
> > > > Hi Abhinav,
> > > > 
> > > > On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar  
> > > > wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:
> > > > > > On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote:
> > > > > > > > Only several SSPP blocks support such features as YUV output or 
> > > > > > > > scaling,
> > > > > > > > thus different DRM planes have different features.  Properly 
> > > > > > > > utilizing
> > > > > > > > all planes requires the attention of the compositor, who should
> > > > > > > > prefer simpler planes to YUV-supporting ones. Otherwise it is 
> > > > > > > > very easy
> > > > > > > > to end up in a situation when all featureful planes are already
> > > > > > > > allocated for simple windows, leaving no spare plane for YUV 
> > > > > > > > playback.
> > > > > > > > 
> > > > > > > > To solve this problem make all planes virtual. Each plane is 
> > > > > > > > registered
> > > > > > > > as if it supports all possible features, but then at the 
> > > > > > > > runtime during
> > > > > > > > the atomic_check phase the driver selects backing SSPP block 
> > > > > > > > for each
> > > > > > > > plane.
> > > > > > > > 
> > > > > > > > As the planes are attached to the CRTC and not the encoder, the 
> > > > > > > > SSPP
> > > > > > > > blocks are also allocated per CRTC ID (all other resources are 
> > > > > > > > currently
> > > > > > > > allocated per encoder ID). This also matches the hardware 
> > > > > > > > requirement,
> > > > > > > > where both rectangles of a single SSPP can only be used with 
> > > > > > > > the LM
> > > > > > > > pair.
> > > > > > > > 
> > > > > > > > Note, this does not provide support for using two different 
> > > > > > > > SSPP blocks
> > > > > > > > for a single plane or using two rectangles of an SSPP to drive 
> > > > > > > > two
> > > > > > > > planes. Each plane still gets its own SSPP and can utilize 
> > > > > > > > either a solo
> > > > > > > > rectangle or both multirect rectangles depending on the 
> > > > > > > > resolution.
> > > > > > > > 
> > > > > > > > Note #2: By default support for virtual planes is turned off 
> > > > > > > > and the
> > > > > > > > driver still uses old code path with preallocated SSPP block 
> > > > > > > > for each
> > > > > > > > plane. To enable virtual planes, pass 
> > > > > > > > 'msm.dpu_use_virtual_planes=1'
> > > > > > > > kernel parameter.
> > > > > > > > 
> > > > > > > > Signed-off-by: Dmitry Baryshkov 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  50 +++
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  10 +-
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   4 +
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 237 
> > > > > > > > ++
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  16 ++
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c|  68 +
> > > > > > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|  27 
> > > > > > > >  7 files changed, 383 insertions(+), 29 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> > > > > > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > > > > > index 58595dcc3889..a7eea094aa14 100644
> > > > > > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > > > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > > > > > @@ -1166,6 +1166,49 @@ static bool 
> > > > > > > > dpu_crtc_needs_dirtyfb(struct drm_crtc_state *cstate)
> > > > > > > >   return false;
> > > > > > > >  }
> > > > > > > > +static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, 
> > > > > > > > struct drm_crtc_state *crtc_state)
> > > > > > > > +{
> > > > > > > > +   int total_planes = crtc->dev->mode_config.num_total_plane;
> > > > > > > > +   struct drm_atomic_state *state = crtc_state->state;
> > > > > > > > +   struct dpu_global_state *global_state;
> > > > > > > > +   struct drm_plane_state **states;
> > > > > > > > +   struct drm_plane *plane;
> > > > > > > > +   int ret;
> > > > > > > > +
> > > > > > > > +   global_state = dpu_kms_get_global_state(crtc_state->state);
> > > > > > > > +   if (IS_ERR(global_state))
> > > > > > > > +   return PTR_ERR(global_state);
> > > > > > > > +
> > > > > > > > +   dpu_rm_release_all_sspp(global_state, crtc);
> > > > > > > > +
> > > > > > > > +   if (!crtc_state->enable)
> > > > > > > > +   return 0;
> > > > > > > > +
> > > > > > > > +   states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
> > > > > > > > +   if

Re: [PATCH v6 7/9] drm/msm/dpu: add support for virtual planes

[Abhinav Kumar]

On 11/1/2024 2:27 PM, Abhinav Kumar wrote:



On 11/1/2024 1:53 PM, Dmitry Baryshkov wrote:

On Fri, Nov 01, 2024 at 01:37:03PM -0700, Abhinav Kumar wrote:



On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:

On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:



On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:

Hi Abhinav,

On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar 
 wrote:




On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:

On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:



On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote:
Only several SSPP blocks support such features as YUV output 
or scaling,
thus different DRM planes have different features.  Properly 
utilizing

all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is 
very easy

to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV 
playback.


To solve this problem make all planes virtual. Each plane is 
registered
as if it supports all possible features, but then at the 
runtime during
the atomic_check phase the driver selects backing SSPP block 
for each

plane.

As the planes are attached to the CRTC and not the encoder, 
the SSPP
blocks are also allocated per CRTC ID (all other resources are 
currently
allocated per encoder ID). This also matches the hardware 
requirement,
where both rectangles of a single SSPP can only be used with 
the LM

pair.

Note, this does not provide support for using two different 
SSPP blocks
for a single plane or using two rectangles of an SSPP to drive 
two
planes. Each plane still gets its own SSPP and can utilize 
either a solo
rectangle or both multirect rectangles depending on the 
resolution.


Note #2: By default support for virtual planes is turned off 
and the
driver still uses old code path with preallocated SSPP block 
for each
plane. To enable virtual planes, pass 
'msm.dpu_use_virtual_planes=1'

kernel parameter.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  50 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  10 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   4 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 237 
++

  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  16 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c    |  68 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h    |  27 
  7 files changed, 383 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c

index 58595dcc3889..a7eea094aa14 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1166,6 +1166,49 @@ static bool 
dpu_crtc_needs_dirtyfb(struct drm_crtc_state *cstate)

   return false;
  }
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, 
struct drm_crtc_state *crtc_state)

+{
+   int total_planes = crtc->dev->mode_config.num_total_plane;
+   struct drm_atomic_state *state = crtc_state->state;
+   struct dpu_global_state *global_state;
+   struct drm_plane_state **states;
+   struct drm_plane *plane;
+   int ret;
+
+   global_state = dpu_kms_get_global_state(crtc_state->state);
+   if (IS_ERR(global_state))
+   return PTR_ERR(global_state);
+
+   dpu_rm_release_all_sspp(global_state, crtc);
+
+   if (!crtc_state->enable)
+   return 0;
+
+   states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
+   if (!states)
+   return -ENOMEM;
+
+   drm_atomic_crtc_state_for_each_plane(plane, crtc_state) {
+   struct drm_plane_state *plane_state =
+   drm_atomic_get_plane_state(state, plane);
+
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto done;
+   }
+
+   states[plane_state->normalized_zpos] = plane_state;
+   }
+
+   ret = dpu_assign_plane_resources(global_state, state, 
crtc, states, total_planes);

+
+done:
+   kfree(states);
+   return ret;
+
+   return 0;
+}
+
  static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
  {
@@ -1181,6 +1224,13 @@ static int dpu_crtc_atomic_check(struct 
drm_crtc *crtc,

   bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+   if (dpu_use_virtual_planes &&
+   (crtc_state->planes_changed || 
crtc_state->zpos_changed)) {

+   rc = dpu_crtc_reassign_planes(crtc, crtc_state);
+   if (rc < 0)
+   return rc;
+   }


planes_changed is set only for format changes . Will it cover all
needs_modeset cases?

OR do we also need to set planes_changed when
drm_atomic_crtc_needs_modeset()?

Unless I am missing something, I think we have to otherwise sspp
reallocation wont happen in modeset cases.


I was depending on the planes being included in the state by the 
client.
I don't think we r

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

[Alejandro Colomar]

Hi Ian,

On Fri, Nov 01, 2024 at 11:19:18AM -0700, Ian Rogers wrote:
> On Fri, Nov 1, 2024 at 6:24 AM Alejandro Colomar  wrote:
> >
> > On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote:
> > > When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> > > sense. As a standalone man page the indentation doesn't need to be so
> > > far over to the right. Remove the initial tagged pragraph and move the
> > > styling to the initial summary description.
> > >
> > > Suggested-by: G. Branden Robinson 
> > > Signed-off-by: Ian Rogers 
> > > ---
> > >  man/man5/proc_pid_fdinfo.5 | 66 ++
> > >  1 file changed, 32 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
> > > index 1e23bbe02..8678caf4a 100644
> > > --- a/man/man5/proc_pid_fdinfo.5
> > > +++ b/man/man5/proc_pid_fdinfo.5
> > > @@ -6,20 +6,19 @@
> > >  .\"
> > >  .TH proc_pid_fdinfo 5 (date) "Linux man-pages (unreleased)"
> > >  .SH NAME
> > > -/proc/pid/fdinfo/ \- information about file descriptors
> > > +.IR /proc/ pid /fdinfo " \- information about file descriptors"
> >
> > I wouldn't add formatting here for now.  That's something I prefer to be
> > cautious about, and if we do it, we should do it in a separate commit.
> 
> I'll move it to a separate patch. Is the caution due to a lack of test
> infrastructure? That could be something to get resolved, perhaps
> through Google summer-of-code and the like.

That change might be controversial.  We'd first need to check that all
software that reads the NAME section would behave well for this.

Also, many other pages might need to be changed accordingly for
consistency.

For testing infrastructure I think we're good.  The makefile already
does a lot of testing.

> 
> > >  .SH DESCRIPTION
> > > -.TP
> > > -.IR /proc/ pid /fdinfo/ " (since Linux 2.6.22)"
> > > -This is a subdirectory containing one entry for each file which the
> > > -process has open, named by its file descriptor.
> > > -The files in this directory are readable only by the owner of the 
> > > process.
> > > -The contents of each file can be read to obtain information
> > > -about the corresponding file descriptor.
> > > -The content depends on the type of file referred to by the
> > > -corresponding file descriptor.
> > > -.IP
> > > +Since Linux 2.6.22,
> >
> > You could move this information to a HISTORY section.
> 
> Sure, tbh I'm not sure anybody cares about this information and it
> could be as well to delete it. Sorry people running 17 year old
> kernels. For now I'll try to leave it unchanged.

I would like to keep it in HISTORY.  You never know when it'll be useful
and it's just one line or a few; it won't hurt.

> 
> > > +this subdirectory contains one entry for each file that process
> > > +.I pid
> > > +has open, named by its file descriptor.  The files in this directory
> >
> > Please don't reflow existing text.  Please read about semantic newlines
> > in man-pages(7):
> >
> > $ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
> >Use semantic newlines
> >  In  the  source of a manual page, new sentences should be started
> >  on new lines, long sentences should be split into lines at clause
> >  breaks (commas, semicolons, colons, and so on), and long  clauses
> >  should be split at phrase boundaries.  This convention, sometimes
> >  known  as  "semantic newlines", makes it easier to see the effect
> >  of patches, which often operate at the level of  individual  sen‐
> >  tences, clauses, or phrases.
> 
> I'll update for v3 but I'm reminded of `git diff --word-diff=color` so
> perhaps this recommendation is outdated.

No, this isn't outdated, since that reduces the quality of the diff.
Also, I review a lot of patches in the mail client, without running
git(1).  And it's not just for reviewing diffs, but also for writing
them.  Semantic newlines reduce the amount of work for producing the
diffs.  And lastly, the source code reads much better if it's logically
divided in phrases.

> 
> Thanks,
> Ian

-- 



signature.asc
Description: PGP signature

Re: [PATCH] drm/msm/hdmi: mark interlace_allowed as true

[Abhinav Kumar]

On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:

The MSM HDMI driver supports interlaced modes. Set the corresponding
flag to allow interlaced modes on the corresponding connectors.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 4a5b5112227f..643c152e6380 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -336,6 +336,7 @@ int msm_hdmi_bridge_init(struct hdmi *hdmi)
bridge->funcs = &msm_hdmi_bridge_funcs;
bridge->ddc = hdmi->i2c;
bridge->type = DRM_MODE_CONNECTOR_HDMIA;
+   bridge->interlace_allowed = true;
bridge->ops = DRM_BRIDGE_OP_HPD |
DRM_BRIDGE_OP_DETECT |
DRM_BRIDGE_OP_EDID;



I had quite a bit of discussion on this internally because this spans 
quite a few generations of chipsets.


On very old hardware, even before msm8996, there was dedicated hardware 
de-interlacer. But even on msm8996 or other HDMI supported chipsets 
where the handling of if (mode->flags & DRM_MODE_FLAG_INTERLACE) is 
present, these were because its carry forward of older interface code.


The way we handle interlaced formats today, is software needs to handle 
the part of dividing height / 2 and width * 2 and adjust the source crop 
if necessary. This part has moved to userspace for recent chips.


Othwerise, we will need to add this part in the dpu driver to adjust 
this. I am not seeing this part there yet. So may I know how you 
validated this change? Something similar to :


https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/LE.UM.1.3.r3.25/drivers/gpu/drm/msm/sde/sde_plane.c#L1340

If we add this part first to dpu code, then we can mark interlace_allowed.


---
base-commit: c4f364c621d0d509190d673d80a9b23250607b4a
change-id: 20241019-msm-hdmi-interlaced-1508c1dc9bb9

Best regards,

[PATCH v3 2/4] proc_pid_fdinfo.5: Make pid clearer in the name and 1st paragraph

[Ian Rogers]

Previously the pid was highlighted through being a tagged paragraph
but not mentioned in the description. Add italics to the path
emphasizing pid and then change the first sentence to include pid in
the definition.

Suggested-by: G. Branden Robinson 
Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index 87e6dbe56..935b54b4c 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -6,11 +6,12 @@
 .\"
 .TH proc_pid_fdinfo 5 (date) "Linux man-pages (unreleased)"
 .SH NAME
-/proc/pid/fdinfo/ \- information about file descriptors
+.IR /proc/ pid /fdinfo " \- information about file descriptors"
 .SH DESCRIPTION
 Since Linux 2.6.22,
-this is a subdirectory containing one entry for each file which the
-process has open, named by its file descriptor.
+this subdirectory contains one entry for each file that process
+.IR pid
+has open, named by its file descriptor.
 The files in this directory are readable only by the owner of the process.
 The contents of each file can be read to obtain information
 about the corresponding file descriptor.
-- 
2.47.0.199.ga7371fff76-goog

[PATCH v3 4/4] proc_pid_fdinfo.5: Add DRM subsection

[Ian Rogers]

Add description of DRM fdinfo information based on the Linux kernel's
`Documentation/gpu/drm-usage-stats.rst`:
https://docs.kernel.org/gpu/drm-usage-stats.html

Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 94 ++
 1 file changed, 94 insertions(+)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index 290cae6a6..98ac12f16 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -301,5 +301,99 @@ fields contain the values that
 .BR timerfd_gettime (2)
 on this file descriptor would return.)
 .RE
+.SS Direct Rendering Manager
+.P
+DRM drivers can optionally choose to expose usage stats through
+/proc/pid/fdinfo/. For example:
+.P
+.in +4n
+.EX
+pos:0
+flags:  0212
+mnt_id: 26
+ino:284
+drm-driver: i915
+drm-client-id:  39
+drm-pdev:   :00:02.0
+drm-total-system0:  6044 KiB
+drm-shared-system0: 0
+drm-active-system0: 0
+drm-resident-system0:   6044 KiB
+drm-purgeable-system0:  1688 KiB
+drm-total-stolen-system0:   0
+drm-shared-stolen-system0:  0
+drm-active-stolen-system0:  0
+drm-resident-stolen-system0:0
+drm-purgeable-stolen-system0:   0
+drm-engine-render:  346249 ns
+drm-engine-copy:0 ns
+drm-engine-video:   0 ns
+drm-engine-capacity-video:  2
+drm-engine-video-enhance:   0 ns
+.EE
+.TP
+.IR drm-driver: " .+  (mandatory)"
+The name this driver registered.
+.TP
+.IR drm-pdev: " "
+For PCI devices this should contain the PCI slot address of the device
+in question.
+.TP
+.IR drm-client-id: " [0-9]+"
+Unique value relating to the open DRM file descriptor used to
+distinguish duplicated and shared file descriptors.
+.P
+GPUs usually contain multiple execution engines. Each shall be given a
+stable and unique name (), with possible values
+documented in the driver specific documentation.
+.TP
+.IR drm-engine-: " [0-9]+ ns"
+GPU engine utilization, time spent busy executing workloads for this client.
+.TP
+.IR drm-engine-capacity-: " [0-9]+"
+Capacity of the engine if not 1, cannot be 0.
+.TP
+.IR drm-cycles-: " [0-9]+"
+Contains the number of busy cycles for the given engine.  Values are
+not required to be constantly monotonic, but are required to catch up
+with the previously reported larger value within a reasonable
+period. Upon observing a value lower than what was previously read,
+userspace is expected to stay with that larger previous value until a
+monotonic update is seen.
+.TP
+.IR drm-total-cycles-: " [0-9]+"
+Contains the total number cycles for the given engine.  This is a
+timestamp in GPU unspecified unit that matches the update rate of
+drm-cycles-. For drivers that implement this interface,
+the engine utilization can be calculated entirely on the GPU clock
+domain, without considering the CPU sleep time between 2 samples.
+.P
+Each possible memory type which can be used to store buffer objects by
+the GPU in question shall be given a stable and unique name .
+The name "memory" is reserved to refer to normal system memory.
+.TP
+.IR drm-memory-: " [0-9]+ [KiB|MiB]"
+The amount of storage currently consumed by the buffer objects belong
+to this client, in the respective memory region.
+.IP
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
+indicating kibi- or mebi-bytes.
+.TP
+.IR drm-shared-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are shared with another file (e.g., have more
+than a single handle).
+.TP
+.IR drm-total-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that including shared and private memory.
+.TP
+.IR drm-resident-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are resident in the specified region.
+.TP
+.IR drm-purgeable-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are purgeable.
+.TP
+.IR drm-active-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are active on one or more engines.
+
 .SH SEE ALSO
 .BR proc (5)
-- 
2.47.0.199.ga7371fff76-goog

[PATCH v3 3/4] proc_pid_fdinfo.5: Add subsection headers for different fd types

[Ian Rogers]

Make the sections about eventfd, epoll, signalfd, inotify, fanotify,
timerfd better separated with a clearer subsection header.

Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index 935b54b4c..290cae6a6 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -58,6 +58,7 @@ is the ID of the mount containing this file.
 See the description of
 .IR /proc/ pid /mountinfo .
 .RE
+.SS eventfd
 .P
 For eventfd file descriptors (see
 .BR eventfd (2)),
@@ -76,6 +77,7 @@ eventfd\-count:   40
 .P
 .I eventfd\-count
 is the current value of the eventfd counter, in hexadecimal.
+.SS epoll
 .P
 For epoll file descriptors (see
 .BR epoll (7)),
@@ -109,6 +111,7 @@ descriptor.
 The
 .I data
 field is the data value associated with this file descriptor.
+.SS signalfd
 .P
 For signalfd file descriptors (see
 .BR signalfd (2)),
@@ -134,6 +137,7 @@ and
 .BR SIGQUIT ;
 see
 .BR signal (7).)
+.SS inotify
 .P
 For inotify file descriptors (see
 .BR inotify (7)),
@@ -174,6 +178,7 @@ file is exposed as a file handle, via three hexadecimal 
fields:
 .IR fhandle\-type ,
 and
 .IR f_handle .
+.SS fanotify
 .P
 For fanotify file descriptors (see
 .BR fanotify (7)),
@@ -230,6 +235,7 @@ The mask of events that are ignored for this mark
 .P
 For details on these fields, see
 .BR fanotify_mark (2).
+.SS timerfd
 .P
 For timerfd file descriptors (see
 .BR timerfd (2)),
-- 
2.47.0.199.ga7371fff76-goog

Re: [PATCH] drm/msm/hdmi: mark interlace_allowed as true

[Dmitry Baryshkov]

On Fri, 1 Nov 2024 at 23:41, Abhinav Kumar  wrote:
>
>
>
> On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:
> > The MSM HDMI driver supports interlaced modes. Set the corresponding
> > flag to allow interlaced modes on the corresponding connectors.
> >
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
> > b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > index 4a5b5112227f..643c152e6380 100644
> > --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > @@ -336,6 +336,7 @@ int msm_hdmi_bridge_init(struct hdmi *hdmi)
> >   bridge->funcs = &msm_hdmi_bridge_funcs;
> >   bridge->ddc = hdmi->i2c;
> >   bridge->type = DRM_MODE_CONNECTOR_HDMIA;
> > + bridge->interlace_allowed = true;
> >   bridge->ops = DRM_BRIDGE_OP_HPD |
> >   DRM_BRIDGE_OP_DETECT |
> >   DRM_BRIDGE_OP_EDID;
> >
>
> I had quite a bit of discussion on this internally because this spans
> quite a few generations of chipsets.
>
> On very old hardware, even before msm8996, there was dedicated hardware
> de-interlacer. But even on msm8996 or other HDMI supported chipsets
> where the handling of if (mode->flags & DRM_MODE_FLAG_INTERLACE) is
> present, these were because its carry forward of older interface code.
>
> The way we handle interlaced formats today, is software needs to handle
> the part of dividing height / 2 and width * 2 and adjust the source crop
> if necessary. This part has moved to userspace for recent chips.
>
> Othwerise, we will need to add this part in the dpu driver to adjust
> this. I am not seeing this part there yet. So may I know how you
> validated this change? Something similar to :
>
> https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/LE.UM.1.3.r3.25/drivers/gpu/drm/msm/sde/sde_plane.c#L1340
>
> If we add this part first to dpu code, then we can mark interlace_allowed.

I think you are mixing the interlaced formats and interlaced output.
The code that you have pointed to is related to hardware deinterlacing
- in other words taking the interlaced framebuffer and outputting it
to the progressive display.

The interlace_allowed flag controls a different feature - filtering of
the internalced modes (aka 576i, 1080i, etc). In this case we are
using progressive frames, but the HDMI outputs a picture as two
separate fields. I have validated this by outputting image (modetest)
to the external HDMI display on IFC6410 and on DB820c boards.

-- 
With best wishes
Dmitry

[PATCH] drm/etnaviv: Drop unused data member from the etnaviv_gem_object structure

[Sui Jingfeng]

Referencing the 'struct etnaviv_gpu *' by every etnaviv GEM BO is weird.
Drop it and drop yet another unused data field, namely 'access'.

Memory footprint of etnaviv GEM BOs reduced.

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index bf0d049d8a79..8da32fb5df16 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -50,9 +50,7 @@ struct etnaviv_gem_object {
u32 flags;
 
struct list_head gem_node;
-   struct etnaviv_gpu *gpu; /* non-null if active */
atomic_t gpu_active;
-   u32 access;
 
struct page **pages;
struct sg_table *sgt;
-- 
2.34.1

[PATCH v7] rockchip/drm: vop2: add support for gamma LUT

[Piotr Zalewski]

Add support for gamma LUT in VOP2 driver. The implementation was inspired
by one found in VOP1 driver. Blue and red channels in gamma LUT register
write were swapped with respect to how gamma LUT values are written in
VOP1. Gamma LUT port selection was added before the write of new gamma LUT
table.

If the current SoC is rk356x, check if no other CRTC has gamma LUT enabled
in atomic_check (only one video port can use gamma LUT at a time) and
disable gamma LUT before the LUT table write.

If the current SoC isn't rk356x, "seamless" gamma lut update is performed
similarly to how it was done in the case of RK3399 in VOP1[1]. In seamless
update gamma LUT disable before the write isn't necessary, check if no
other CRTC has gamma LUT enabled is also not necessary, different register
is being used to select gamma LUT port[2] and after setting DSP_LUT_EN bit,
GAMMA_UPDATE_EN bit is set[3].

Gamma size is set and drm color management is enabled for each video port's
CRTC except ones which have no associated device.

Patch was tested on RK3566 (Pinetab2). When using userspace tools
which set eg. constant color temperature no issues were noticed. When
using userspace tools which adjust eg. color temperature the slight screen
flicker is visible probably because of gamma LUT disable needed in the
case of RK356x before gamma LUT write.

Compare behaviour of eg.:
```
gammastep -O 3000
```

To eg.:
```
gammastep -l 53:23 -t 6000:3000
```

In latter case color temperature is slowly adjusted at the beginning which
causes screen to slighly flicker. Then it adjusts every few seconds which
also causes slight screen flicker.

[1] 
https://lists.infradead.org/pipermail/linux-rockchip/2021-October/028132.html
[2] 
https://lore.kernel.org/linux-rockchip/48249708-8c05-40d2-a5d8-23de960c5...@rock-chips.com/
[3] 
https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c#L3437

Helped-by: Daniel Stone 
Helped-by: Dragan Simic 
Helped-by: Diederik de Haas 
Helped-by: Andy Yan 
Signed-off-by: Piotr Zalewski 
---

Notes:
Changes in v7:
- Code styling changes only [6].

Changes in v6:
- Move gamma lut write to atomic_flush[4].
- In atomic_check if any other than the currently updated CRTC has
  gamma lut enabled, return -EINVAL [5] (perform a check only if
  device is rk356x).
- Instead of checking for rk3588 to determine seamless gamma
  update availability check for rk3566/rk3568.
- remove null check in vop2_create_crtcs
- Move some code to separate functions to increase readability.

Changes in v5:
- Do not trigger full modeset in case seamless gamma lut update
  isn't possible (eg. rk356x case). It was discovered that with
  full modeset, userspace tools which adjust color temperature with
  high frequency cause screen to go black and reduce overall
  performance. Instead, revert to previous behaviour of lut update
  happening in atomic_begin or (in case there is a modeset) in
  atomic_enable. Also, add unrelated to modeset trigger
  changes/improvements from v4 on top. Improve code readability
  too.

Changes in v4:
- rework the implementation to better utilize DRM atomic updates[2]
- handle the RK3588 case[2][3]

Changes in v3:
- v3 is patch v2 "resend", by mistake the incremental patch was
sent in v2

Changes in v2:
- Apply code styling corrections[1]
- Move gamma LUT write inside the vop2 lock

Link to v6: 
https://lore.kernel.org/linux-rockchip/20241016223558.673145-2-pz010001011...@proton.me/
Link to v5: 
https://lore.kernel.org/linux-rockchip/20241014222022.571819-4-pz010001011...@proton.me/
Link to v4: 
https://lore.kernel.org/linux-rockchip/20240815124306.189282-2-pz010001011...@proton.me/
Link to v3: 
https://lore.kernel.org/linux-rockchip/TkgKVivuaLFLILPY-n3iZo_8KF-daKdqdu-0_e0HP-5Ar_8DAL
DeNWog2suwWKjX7eomcbGET0KZe7DlzdhK2YM6CbLbeKeFZr-MJzJMtw0=@proton.me/
Link to v2: 
https://lore.kernel.org/linux-rockchip/Hk03HDb6wSSHWtEFZHUye06HR0-9YzP5nCHx9A8_kHzWSZawDr
U1o1pjEGkCOJFoRg0nTB4BWEv6V0XBOjF4-0Mj44lp2TrjaQfnytzp-Pk=@proton.me/
Link to v1: 
https://lore.kernel.org/linux-rockchip/ZVMxgcrtgHui9fJpnhbN6TSPhofHbbXElh241lImrzzTUl-8We
jGpaR8CPzYhBgoqe_xj7N6En8Ny7Z-gsCr0kaFs7apwjYV1MBJJLmLHxs=@proton.me/

[1] 
https://lore.kernel.org/linux-rockchip/d019761504b540600d9fc7a585d6f...@manjaro.org
[2] 
https://lore.kernel.org/linux-rockchip/CAPj87rOM=j0zmuWL9frGKV1xzPbJrk=Q9ip7F_HAPYnbCqPouw@mail.g
mail.com
[3] 
https://lore.kernel.org/linux-rockchip/7d998e4c-e1d3-4e8b-af76-c5bc83b43...@rock-chips.com
[4] 
https://lore.kernel.org/linux-rockchip/7b45f190.452f.1928e41b746.coremail.andys...@163.com/
[5] 
https://lore.kernel.org/linux-rockchip/CAPj87rOdQPsuH9qB_ZLfC9S=cO2noNi1mOGW0ZmQ6SHCugb9=w@mail.g
mail.com/
[6] 
https://lore.kernel.or

Re: [PATCH v6 0/9] drm/msm/dpu: support virtual wide planes

[Dmitry Baryshkov]

On Fri, 25 Oct 2024 03:20:07 +0300, Dmitry Baryshkov wrote:
> As promised in the basic wide planes support ([1]) here comes a series
> supporting 2*max_linewidth for all the planes.
> 
> Note: Unlike v1 and v2 this series finally includes support for
> additional planes - having more planes than the number of SSPP blocks.
> 
> Note: this iteration features handling of rotation and reflection of the
> wide plane. However rot90 is still not tested: it is enabled on sc7280
> and it only supports UBWC (tiled) framebuffers, it was quite low on my
> priority list.
> 
> [...]

Applied, thanks!

After additional consideration, apply only basic patches, leaving the virtual
planes enablement into the 6.14 material in order to be able to get more
testing for those patches.

[1/9] drm/msm/dpu: use drm_rect_fp_to_int()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/5002c44c
[2/9] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check
  https://gitlab.freedesktop.org/lumag/msm/-/commit/31f7148fd370
[3/9] drm/msm/dpu: drop virt_formats from SSPP subblock configuration
  https://gitlab.freedesktop.org/lumag/msm/-/commit/b96ca23fdd03
[4/9] drm/msm/dpu: move scaling limitations out of the hw_catalog
  https://gitlab.freedesktop.org/lumag/msm/-/commit/8f15005783b8
[5/9] drm/msm/dpu: split dpu_plane_atomic_check()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/dbbf57dfd04e
[6/9] drm/msm/dpu: move rot90 checking to dpu_plane_atomic_check_sspp()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/ab52d2717ac0

Best regards,
-- 
Dmitry Baryshkov 

Re: [git pull] drm fixes for 6.12-rc6

[pr-tracker-bot]

The pull request you sent on Sat, 2 Nov 2024 05:04:48 +1000:

> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-11-02

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/269ce3bd62e8ad83dadc80a2f755a799697ca4a3

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

[PATCH v2 1/2] drm/display/dsc: Refactor DRM MST DSC Determination Policy

[Fangzhi Zuo]

[why]
How we determine the dsc_aux used for dsc decompression in
drm_dp_mst_dsc_aux_for_port() today has defects:

1. The method how we determine a connected peer device is virtual or not
   in drm_dp_mst_is_virtual_dpcd() is not always correct. There are DP1.4 
products
   in the market which don't fully comply with DP spec to enumerate virtual 
peer device.
   That leads to existing logic defects. For example:

   -  Some 1.4 mst hubs with hdmi output port don't enumerate virtual dpcd/peer 
device.
  When probing the hub, its topology is constructed with a branch device 
only, with
  peer device type set as DP-to-Legacy converter for its HDMI output port.
  Under this condition, drm_dp_mst_is_virtual_dpcd() will still determine 
it's connected
  with a virtual peer device with virtual dpcd. And results in the section 
for
  analyzing DP-to-DP peer device case of drm_dp_mst_dsc_aux_for_port(). 
That's logically
  incorrect.

2. Existing routine is designed based on analyzing different connected peer 
device types, such
   as dp-dp, dp-hdmi peer device, and virtual sink. Such categorization is 
redundant and unnecessary.
   The key info of determining where to do dsc decompression relies on the dsc 
capability from dpcd
   only. No matter the mst branch device enumerates virtual dpcd or not, if 
it's supporting dsc, it
   must declare it's dsc capability at somewhere within its responded topology.

Therefore, we would like to refactor the logic how we determine the dsc aux.

[how]
1. dsc_aux should be determined by the topology connection status and dpcd 
capability info only.
   In this way, dsc aux could be determined in a more generic way,
   instead of enumerating and analyzing on different connected peer device 
types.

2. Synaptics quirk DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD analyzing is no 
longer needed
   as long as we determine dsc aux generically by dpcd info.

Signed-off-by: Fangzhi Zuo 
Signed-off-by: Wayne Lin 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 238 --
 include/drm/display/drm_dp_mst_helper.h   |   3 +
 2 files changed, 104 insertions(+), 137 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index ac90118b9e7a..a4551c17a07f 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -2258,6 +2258,8 @@ void drm_dp_mst_connector_early_unregister(struct 
drm_connector *connector,
drm_dbg_kms(port->mgr->dev, "unregistering %s remote bus for %s\n",
port->aux.name, connector->kdev->kobj.name);
drm_dp_aux_unregister_devnode(&port->aux);
+   port->dsc_aux = NULL;
+   port->passthrough_aux = NULL;
 }
 EXPORT_SYMBOL(drm_dp_mst_connector_early_unregister);
 
@@ -5994,57 +5996,6 @@ static void drm_dp_mst_unregister_i2c_bus(struct 
drm_dp_mst_port *port)
i2c_del_adapter(&port->aux.ddc);
 }
 
-/**
- * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer Device
- * @port: The port to check
- *
- * A single physical MST hub object can be represented in the topology
- * by multiple branches, with virtual ports between those branches.
- *
- * As of DP1.4, An MST hub with internal (virtual) ports must expose
- * certain DPCD registers over those ports. See sections 2.6.1.1.1
- * and 2.6.1.1.2 of Display Port specification v1.4 for details.
- *
- * May acquire mgr->lock
- *
- * Returns:
- * true if the port is a virtual DP peer device, false otherwise
- */
-static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
-{
-   struct drm_dp_mst_port *downstream_port;
-
-   if (!port || port->dpcd_rev < DP_DPCD_REV_14)
-   return false;
-
-   /* Virtual DP Sink (Internal Display Panel) */
-   if (drm_dp_mst_port_is_logical(port))
-   return true;
-
-   /* DP-to-HDMI Protocol Converter */
-   if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
-   !port->mcs &&
-   port->ldps)
-   return true;
-
-   /* DP-to-DP */
-   mutex_lock(&port->mgr->lock);
-   if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
-   port->mstb &&
-   port->mstb->num_ports == 2) {
-   list_for_each_entry(downstream_port, &port->mstb->ports, next) {
-   if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
-   !downstream_port->input) {
-   mutex_unlock(&port->mgr->lock);
-   return true;
-   }
-   }
-   }
-   mutex_unlock(&port->mgr->lock);
-
-   return false;
-}
-
 /**
  * drm_dp_mst_aux_for_parent() - Get the AUX device for an MST port's parent
  * @port: MST port whose parent's AUX device is returned
@@ -6079,115 +6030,128 @@ EXPORT_SYMBOL(drm_dp_mst_aux_for_parent);
  */
 struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp

Re: [PATCH v6 7/9] drm/msm/dpu: add support for virtual planes

[Abhinav Kumar]

On 11/1/2024 1:53 PM, Dmitry Baryshkov wrote:

On Fri, Nov 01, 2024 at 01:37:03PM -0700, Abhinav Kumar wrote:



On 10/31/2024 2:03 PM, Dmitry Baryshkov wrote:

On Thu, Oct 31, 2024 at 01:06:34PM -0700, Abhinav Kumar wrote:



On 10/31/2024 8:11 AM, Dmitry Baryshkov wrote:

Hi Abhinav,

On Wed, 30 Oct 2024 at 21:26, Abhinav Kumar  wrote:




On 10/30/2024 3:48 AM, Dmitry Baryshkov wrote:

On Tue, Oct 29, 2024 at 02:30:12PM -0700, Abhinav Kumar wrote:



On 10/24/2024 5:20 PM, Dmitry Baryshkov wrote:

Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features.  Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.

To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.

As the planes are attached to the CRTC and not the encoder, the SSPP
blocks are also allocated per CRTC ID (all other resources are currently
allocated per encoder ID). This also matches the hardware requirement,
where both rectangles of a single SSPP can only be used with the LM
pair.

Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.

Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  50 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  10 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   4 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 237 
++
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  16 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c|  68 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h|  27 
  7 files changed, 383 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 58595dcc3889..a7eea094aa14 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1166,6 +1166,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state 
*cstate)
   return false;
  }
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct 
drm_crtc_state *crtc_state)
+{
+   int total_planes = crtc->dev->mode_config.num_total_plane;
+   struct drm_atomic_state *state = crtc_state->state;
+   struct dpu_global_state *global_state;
+   struct drm_plane_state **states;
+   struct drm_plane *plane;
+   int ret;
+
+   global_state = dpu_kms_get_global_state(crtc_state->state);
+   if (IS_ERR(global_state))
+   return PTR_ERR(global_state);
+
+   dpu_rm_release_all_sspp(global_state, crtc);
+
+   if (!crtc_state->enable)
+   return 0;
+
+   states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
+   if (!states)
+   return -ENOMEM;
+
+   drm_atomic_crtc_state_for_each_plane(plane, crtc_state) {
+   struct drm_plane_state *plane_state =
+   drm_atomic_get_plane_state(state, plane);
+
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto done;
+   }
+
+   states[plane_state->normalized_zpos] = plane_state;
+   }
+
+   ret = dpu_assign_plane_resources(global_state, state, crtc, states, 
total_planes);
+
+done:
+   kfree(states);
+   return ret;
+
+   return 0;
+}
+
  static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
  {
@@ -1181,6 +1224,13 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
   bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+   if (dpu_use_virtual_planes &&
+   (crtc_state->planes_changed || crtc_state->zpos_changed)) {
+   rc = dpu_crtc_reassign_planes(crtc, crtc_state);
+   if (rc < 0)
+   return rc;
+   }


planes_changed is set only for format changes . Will it cover all
needs_modeset cases?

OR do we also need to set planes_changed when
drm_atomic_crtc_needs_modeset()?

Unless I am missing something, I think we have to otherwise sspp
reallocation wont happen in modeset cases.


I was depending on the planes being included in the state by the client.
I don't think we really care about the modeset per se. We care about
plane size changes. And changi

[PATCH v2 0/2] Refactor MST DSC Determination Policy

[Fangzhi Zuo]

The patch series is to refactor existing dsc determination policy for
dsc decompression and dsc passthrough given a mst output port.

Original routine was written based on different peer device types
which is not accurate and shows difficulty when expanding support of
products that do not fully comply with DP specs.

To make the routine more accurate and generic, the series includes below 
changes:
1. Refactor MST DSC determination policy solely based on
   topology connection status and dsc dpcd capability info.
2. Dependency changes required for each vendor due to interface change.

Fangzhi Zuo (2):
  drm/display/dsc: Refactor DRM MST DSC Determination Policy
  drm/display/dsc: MST DSC Interface Change

 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |   2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  20 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  30 +-
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 258 --
 drivers/gpu/drm/i915/display/intel_dp.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 include/drm/display/drm_dp_mst_helper.h   |   9 +-
 7 files changed, 145 insertions(+), 179 deletions(-)

-- 
2.43.0

[PATCH v2 2/2] drm/display/dsc: MST DSC Interface Change

[Fangzhi Zuo]

[why]
Starting from dp2 where dsc passthrough is introduced, it is required to 
identify
the dsc passthrough aux, apart from dsc decompression aux. Existing 
drm_dp_mst_port function
that returns dsc_aux alone is not sufficient.

[how]
1. Interface change in drm_dp_mst_dsc_aux_for_port, and dependency changes for 
each vendor.
2. Rename passthrough_aux with dsc_passthrough_aux to align with the name of 
dsc_aux.

Signed-off-by: Fangzhi Zuo 
Signed-off-by: Wayne Lin 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |  2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 20 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 30 
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 34 +--
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 include/drm/display/drm_dp_mst_helper.h   |  6 ++--
 7 files changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index db56b0aa5454..0da703f4ccac 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1370,7 +1370,7 @@ static int dp_dsc_fec_support_show(struct seq_file *m, 
void *data)
 * enable DSC on the sink device or on MST branch
 * its connected to.
 */
-   if (aconnector->dsc_aux) {
+   if (aconnector->mst_output_port->dsc_aux) {
is_fec_supported = true;
is_dsc_supported = true;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 069e0195e50a..2e5e490f9027 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -810,20 +810,20 @@ bool dm_helpers_dp_write_dsc_enable(
uint8_t ret = 0;
 
if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST) {
-   if (!aconnector->dsc_aux)
+   if (!aconnector->mst_output_port->dsc_aux)
return false;
 
// apply w/a to synaptics
if (needs_dsc_aux_workaround(aconnector->dc_link) &&
(aconnector->mst_downstream_port_present.byte & 0x7) != 0x3)
return write_dsc_enable_synaptics_non_virtual_dpcd_mst(
-   aconnector->dsc_aux, stream, enable_dsc);
+   aconnector->mst_output_port->dsc_aux, stream, 
enable_dsc);
 
port = aconnector->mst_output_port;
 
if (enable) {
-   if (port->passthrough_aux) {
-   ret = drm_dp_dpcd_write(port->passthrough_aux,
+   if (port->dsc_passthrough_aux) {
+   ret = 
drm_dp_dpcd_write(port->dsc_passthrough_aux,
DP_DSC_ENABLE,
&enable_passthrough, 1);
drm_dbg_dp(dev,
@@ -831,24 +831,24 @@ bool dm_helpers_dp_write_dsc_enable(
   ret);
}
 
-   ret = drm_dp_dpcd_write(aconnector->dsc_aux,
+   ret = 
drm_dp_dpcd_write(aconnector->mst_output_port->dsc_aux,
DP_DSC_ENABLE, &enable_dsc, 1);
drm_dbg_dp(dev,
   "MST_DSC Sent DSC decoding enable to %s 
port, ret = %u\n",
-  (port->passthrough_aux) ? "remote RX" :
+  (port->dsc_passthrough_aux) ? "remote RX" :
   "virtual dpcd",
   ret);
} else {
-   ret = drm_dp_dpcd_write(aconnector->dsc_aux,
+   ret = 
drm_dp_dpcd_write(aconnector->mst_output_port->dsc_aux,
DP_DSC_ENABLE, &enable_dsc, 1);
drm_dbg_dp(dev,
   "MST_DSC Sent DSC decoding disable to %s 
port, ret = %u\n",
-  (port->passthrough_aux) ? "remote RX" :
+  (port->dsc_passthrough_aux) ? "remote RX" :
   "virtual dpcd",
   ret);
 
-   if (port->passthrough_aux) {
-   ret = drm_dp_dpcd_write(port->passthrough_aux,
+   if (port->dsc_passthrough_aux) {
+   ret = 
drm_dp_dpcd_write(port->dsc_passthro

[PATCH v4 4/4] proc_pid_fdinfo.5: Add DRM subsection

[Ian Rogers]

Add description of DRM fdinfo information based on the Linux kernel's
`Documentation/gpu/drm-usage-stats.rst`:
https://docs.kernel.org/gpu/drm-usage-stats.html

Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 94 ++
 1 file changed, 94 insertions(+)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index b7efde8f4..bcaf33817 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -300,6 +300,100 @@ fields contain the values that
 .BR timerfd_gettime (2)
 on this file descriptor would return.)
 .RE
+.SS Direct Rendering Manager
+.P
+DRM drivers can optionally choose to expose usage stats through
+/proc/pid/fdinfo/. For example:
+.P
+.in +4n
+.EX
+pos:0
+flags:  0212
+mnt_id: 26
+ino:284
+drm-driver: i915
+drm-client-id:  39
+drm-pdev:   :00:02.0
+drm-total-system0:  6044 KiB
+drm-shared-system0: 0
+drm-active-system0: 0
+drm-resident-system0:   6044 KiB
+drm-purgeable-system0:  1688 KiB
+drm-total-stolen-system0:   0
+drm-shared-stolen-system0:  0
+drm-active-stolen-system0:  0
+drm-resident-stolen-system0:0
+drm-purgeable-stolen-system0:   0
+drm-engine-render:  346249 ns
+drm-engine-copy:0 ns
+drm-engine-video:   0 ns
+drm-engine-capacity-video:  2
+drm-engine-video-enhance:   0 ns
+.EE
+.TP
+.IR drm-driver: " .+  (mandatory)"
+The name this driver registered.
+.TP
+.IR drm-pdev: " "
+For PCI devices this should contain the PCI slot address of the device
+in question.
+.TP
+.IR drm-client-id: " [0-9]+"
+Unique value relating to the open DRM file descriptor used to
+distinguish duplicated and shared file descriptors.
+.P
+GPUs usually contain multiple execution engines. Each shall be given a
+stable and unique name (), with possible values
+documented in the driver specific documentation.
+.TP
+.IR drm-engine-: " [0-9]+ ns"
+GPU engine utilization, time spent busy executing workloads for this client.
+.TP
+.IR drm-engine-capacity-: " [0-9]+"
+Capacity of the engine if not 1, cannot be 0.
+.TP
+.IR drm-cycles-: " [0-9]+"
+Contains the number of busy cycles for the given engine.  Values are
+not required to be constantly monotonic, but are required to catch up
+with the previously reported larger value within a reasonable
+period. Upon observing a value lower than what was previously read,
+userspace is expected to stay with that larger previous value until a
+monotonic update is seen.
+.TP
+.IR drm-total-cycles-: " [0-9]+"
+Contains the total number cycles for the given engine.  This is a
+timestamp in GPU unspecified unit that matches the update rate of
+drm-cycles-. For drivers that implement this interface,
+the engine utilization can be calculated entirely on the GPU clock
+domain, without considering the CPU sleep time between 2 samples.
+.P
+Each possible memory type which can be used to store buffer objects by
+the GPU in question shall be given a stable and unique name .
+The name "memory" is reserved to refer to normal system memory.
+.TP
+.IR drm-memory-: " [0-9]+ [KiB|MiB]"
+The amount of storage currently consumed by the buffer objects belong
+to this client, in the respective memory region.
+.IP
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
+indicating kibi- or mebi-bytes.
+.TP
+.IR drm-shared-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are shared with another file (e.g., have more
+than a single handle).
+.TP
+.IR drm-total-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that including shared and private memory.
+.TP
+.IR drm-resident-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are resident in the specified region.
+.TP
+.IR drm-purgeable-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are purgeable.
+.TP
+.IR drm-active-: " [0-9]+ [KiB|MiB]"
+The total size of buffers that are active on one or more engines.
+
 .SH HISTORY
 Since Linux 2.6.22.
 .SH SEE ALSO
-- 
2.47.0.199.ga7371fff76-goog

[PATCH v4 3/4] proc_pid_fdinfo.5: Add subsection headers for different fd types

[Ian Rogers]

Make the sections about eventfd, epoll, signalfd, inotify, fanotify,
timerfd better separated with a clearer subsection header.

Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index be1675b69..b7efde8f4 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -57,6 +57,7 @@ is the ID of the mount containing this file.
 See the description of
 .IR /proc/ pid /mountinfo .
 .RE
+.SS eventfd
 .P
 For eventfd file descriptors (see
 .BR eventfd (2)),
@@ -75,6 +76,7 @@ eventfd\-count:   40
 .P
 .I eventfd\-count
 is the current value of the eventfd counter, in hexadecimal.
+.SS epoll
 .P
 For epoll file descriptors (see
 .BR epoll (7)),
@@ -108,6 +110,7 @@ descriptor.
 The
 .I data
 field is the data value associated with this file descriptor.
+.SS signalfd
 .P
 For signalfd file descriptors (see
 .BR signalfd (2)),
@@ -133,6 +136,7 @@ and
 .BR SIGQUIT ;
 see
 .BR signal (7).)
+.SS inotify
 .P
 For inotify file descriptors (see
 .BR inotify (7)),
@@ -173,6 +177,7 @@ file is exposed as a file handle, via three hexadecimal 
fields:
 .IR fhandle\-type ,
 and
 .IR f_handle .
+.SS fanotify
 .P
 For fanotify file descriptors (see
 .BR fanotify (7)),
@@ -229,6 +234,7 @@ The mask of events that are ignored for this mark
 .P
 For details on these fields, see
 .BR fanotify_mark (2).
+.SS timerfd
 .P
 For timerfd file descriptors (see
 .BR timerfd (2)),
-- 
2.47.0.199.ga7371fff76-goog

[PATCH v4 2/4] proc_pid_fdinfo.5: Make pid clearer in the name and 1st paragraph

[Ian Rogers]

Previously the pid was highlighted through being a tagged paragraph
but not mentioned in the description. Add italics to the path
emphasizing pid and then change the first sentence to include pid in
the definition.

Suggested-by: G. Branden Robinson 
Signed-off-by: Ian Rogers 
---
 man/man5/proc_pid_fdinfo.5 | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/man/man5/proc_pid_fdinfo.5 b/man/man5/proc_pid_fdinfo.5
index ad739bd84..be1675b69 100644
--- a/man/man5/proc_pid_fdinfo.5
+++ b/man/man5/proc_pid_fdinfo.5
@@ -6,10 +6,11 @@
 .\"
 .TH proc_pid_fdinfo 5 (date) "Linux man-pages (unreleased)"
 .SH NAME
-/proc/pid/fdinfo/ \- information about file descriptors
+.IR /proc/ pid /fdinfo " \- information about file descriptors"
 .SH DESCRIPTION
-This is a subdirectory containing one entry for each file which the
-process has open, named by its file descriptor.
+This subdirectory contains one entry for each file that process
+.IR pid
+has open, named by its file descriptor.
 The files in this directory are readable only by the owner of the process.
 The contents of each file can be read to obtain information
 about the corresponding file descriptor.
-- 
2.47.0.199.ga7371fff76-goog

[PATCH v4] drm/xe: Fix build error for XE_IOCTL_DBG macro

[Gyeyoung Baek]

if CONFIG_DRM_USE_DYNAMIC_DEBUG is set,
'drm_dbg' function is replaced with '__dynamic_func_call_cls',
which is replaced with a do while statement.
so in the previous code, there are the following build errors.

include/linux/dynamic_debug.h:221:58: error: expected expression before ‘do’
  221 | #define __dynamic_func_call_cls(id, cls, fmt, func, ...) do {   \
  |  ^~
include/linux/dynamic_debug.h:248:9: note: in expansion of macro 
‘__dynamic_func_call_cls’
  248 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, 
##__VA_ARGS__)
  | ^~~
include/drm/drm_print.h:425:9: note: in expansion of macro 
‘_dynamic_func_call_cls’
  425 | _dynamic_func_call_cls(cat, fmt, __drm_dev_dbg, \
  | ^~
include/drm/drm_print.h:504:9: note: in expansion of macro ‘drm_dev_dbg’
  504 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
  | ^~~
include/drm/drm_print.h:522:33: note: in expansion of macro ‘drm_dbg_driver’
  522 | #define drm_dbg(drm, fmt, ...)  drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
  | ^~
drivers/gpu/drm/xe/xe_macros.h:14:21: note: in expansion of macro ‘drm_dbg’
   14 | ((cond) && (drm_dbg(&(xe)->drm, \
  | ^~~
drivers/gpu/drm/xe/xe_bo.c:2029:13: note: in expansion of macro ‘XE_IOCTL_DBG’
 2029 | if (XE_IOCTL_DBG(xe, !gem_obj))

the problem is that,
XE_IOCTL_DBG uses this function for conditional expr.

so I fix the expr to be compatible with the do while statement,
by referring to "https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html";.

v2: I modified this to print when only cond is true.
v3: Modify to evaluate cond only once.
v4: There was a mistake in v3, send this again.

Signed-off-by: Gyeyoung Baek 
---
 drivers/gpu/drm/xe/xe_macros.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_macros.h b/drivers/gpu/drm/xe/xe_macros.h
index daf56c846d03..51ac8faa8975 100644
--- a/drivers/gpu/drm/xe/xe_macros.h
+++ b/drivers/gpu/drm/xe/xe_macros.h
@@ -10,9 +10,13 @@
 
 #define XE_WARN_ON WARN_ON
 
-#define XE_IOCTL_DBG(xe, cond) \
-   ((cond) && (drm_dbg(&(xe)->drm, \
-   "Ioctl argument check failed at %s:%d: %s", \
-   __FILE__, __LINE__, #cond), 1))
+#define XE_IOCTL_DBG(xe, cond) ({  \
+   int cond__ = !!(cond);  \
+   if (cond__) \
+   drm_dbg(&(xe)->drm, \
+   "Ioctl argument check failed at %s:%d: %s", \
+   __FILE__, __LINE__, #cond); \
+   cond__; \
+})
 
 #endif
-- 
2.34.1

[git pull] drm fixes for 6.12-rc6

[Dave Airlie]

Hi Linus,

Regular fixes pull, nothing too out of the ordinary, the mediatek
fixes came in a batch that I might have preferred a bit earlier but
all seem fine, otherwise regular xe/amdgpu and a few misc ones.

Dave.

drm-fixes-2024-11-02:
drm fixes for 6.12-rc6

xe:
- Fix missing HPD interrupt enabling, bringing one PM refactor with it
- Workaround LNL GGTT invalidation not being visible to GuC
- Avoid getting jobs stuck without a protecting timeout

ivpu:
- Fix firewall IRQ handling

panthor:
- Fix firmware initialization wrt page sizes
- Fix handling and reporting of dead job groups

sched:
- Guarantee forward progress via WC_MEM_RECLAIM

tests:
- Fix memory leak in drm_display_mode_from_cea_vic()

amdgpu:
- DCN 3.5 fix
- Vangogh SMU KASAN fix
- SMU 13 profile reporting fix

mediatek:
- Fix degradation problem of alpha blending
- Fix color format MACROs in OVL
- Fix get efuse issue for MT8188 DPTX
- Fix potential NULL dereference in mtk_crtc_destroy()
- Correct dpi power-domains property
- Add split subschema property constraints
The following changes since commit 81983758430957d9a5cbfe324fd70cf63e7e:

  Linux 6.12-rc5 (2024-10-27 12:52:02 -1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-11-02

for you to fetch changes up to f99c7cca2f712d11a67148cfbe463fdefeb82dc5:

  Merge tag 'drm-xe-fixes-2024-10-31' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
(2024-11-02 04:44:27 +1000)


drm fixes for 6.12-rc6

xe:
- Fix missing HPD interrupt enabling, bringing one PM refactor with it
- Workaround LNL GGTT invalidation not being visible to GuC
- Avoid getting jobs stuck without a protecting timeout

ivpu:
- Fix firewall IRQ handling

panthor:
- Fix firmware initialization wrt page sizes
- Fix handling and reporting of dead job groups

sched:
- Guarantee forward progress via WC_MEM_RECLAIM

tests:
- Fix memory leak in drm_display_mode_from_cea_vic()

amdgpu:
- DCN 3.5 fix
- Vangogh SMU KASAN fix
- SMU 13 profile reporting fix

mediatek:
- Fix degradation problem of alpha blending
- Fix color format MACROs in OVL
- Fix get efuse issue for MT8188 DPTX
- Fix potential NULL dereference in mtk_crtc_destroy()
- Correct dpi power-domains property
- Add split subschema property constraints


Alex Deucher (1):
  drm/amdgpu/smu13: fix profile reporting

Andrzej Kacprowski (1):
  accel/ivpu: Fix NOC firewall interrupt handling

Boris Brezillon (3):
  drm/panthor: Fix firmware initialization on systems with a page size > 4k
  drm/panthor: Fail job creation when the group is dead
  drm/panthor: Report group as timedout when we fail to properly suspend

Dan Carpenter (2):
  drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()
  drm/tegra: Fix NULL vs IS_ERR() check in probe()

Dave Airlie (4):
  Merge tag 'drm-misc-fixes-2024-10-31' of
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
  Merge tag 'amd-drm-fixes-6.12-2024-10-31' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'mediatek-drm-fixes-20241028' of
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux
into drm-fixes
  Merge tag 'drm-xe-fixes-2024-10-31' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

Hsin-Te Yuan (1):
  drm/mediatek: Fix color format MACROs in OVL

Imre Deak (2):
  drm/xe/display: Separate the d3cold and non-d3cold runtime PM handling
  drm/xe/display: Add missing HPD interrupt enabling during
non-d3cold RPM resume

Jason-JH.Lin (5):
  drm/mediatek: ovl: Fix XRGB format breakage for blend_modes
unsupported SoCs
  drm/mediatek: ovl: Refine ignore_pixel_alpha comment and placement
  drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()
  drm/mediatek: ovl: Add blend_modes to driver data
  drm/mediatek: Add blend_modes to mtk_plane_init() for different SoCs

Jinjie Ruan (3):
  drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()
  drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()
  drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()

Liankun Yang (1):
  drm/mediatek: Fix get efuse issue for MT8188 DPTX

Maarten Lankhorst (1):
  drm/xe: Remove runtime argument from display s/r functions

Macpaul Lin (1):
  dt-bindings: display: mediatek: dpi: correct power-domains property

Matthew Brost (3):
  drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM
  drm/xe: Add mmio read before GGTT invalidate
  drm/xe: Don't short circuit TDR on jobs not started

Moudy Ho (1):
  dt-bindings: display: mediatek: split: add subschema property constraints

Ovidiu Bunea (1):
  Revert "drm/amd/display: update DML2 policy
EnhancedPrefetchScheduleAccelerationFinal DCN35"

Thomas Zimmermann (1):
 

Re: [PATCH RFC v2 2/7] ASoC: hdmi-codec: move no_capture_mute to struct hdmi_codec_pdata

[Mark Brown]

On Fri, Nov 01, 2024 at 12:19:03PM +0200, Dmitry Baryshkov wrote:
> The no_capture_mute flag might differ from platform to platform,
> especially in the case of the wrapping implementations, like the
> upcoming DRM HDMI Codec framework. Move the flag next to all other flags
> in struct hdmi_codec_pdata.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

Re: [PATCH RFC 1/4] drm/dp: Add helper to set LTTPRs in transparent mode

[Dmitry Baryshkov]

On Fri, Nov 01, 2024 at 03:43:40PM +0200, Imre Deak wrote:
> On Fri, Nov 01, 2024 at 11:22:13AM +0200, Jani Nikula wrote:
> > On Thu, 31 Oct 2024, Imre Deak  wrote:
> > > On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
> > >> According to the DisplayPort standard, LTTPRs have two operating
> > >> modes:
> > >>  - non-transparent - it replies to DPCD LTTPR field specific AUX
> > >>requests, while passes through all other AUX requests
> > >>  - transparent - it passes through all AUX requests.
> > >> 
> > >> Switching between this two modes is done by the DPTX by issuing
> > >> an AUX write to the DPCD PHY_REPEATER_MODE register.
> > >> 
> > >> Add a generic helper that allows switching between these modes.
> > >> 
> > >> Signed-off-by: Abel Vesa 
> > >> ---
> > >>  drivers/gpu/drm/display/drm_dp_helper.c | 17 +
> > >>  include/drm/display/drm_dp_helper.h |  1 +
> > >>  2 files changed, 18 insertions(+)
> > >> 
> > >> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
> > >> b/drivers/gpu/drm/display/drm_dp_helper.c
> > >> index 
> > >> 6ee51003de3ce616c3a52653c2f1979ad7658e21..38d612345986ad54b42228902ea718a089d169c4
> > >>  100644
> > >> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > >> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > >> @@ -2694,6 +2694,23 @@ int drm_dp_lttpr_max_link_rate(const u8 
> > >> caps[DP_LTTPR_COMMON_CAP_SIZE])
> > >>  }
> > >>  EXPORT_SYMBOL(drm_dp_lttpr_max_link_rate);
> > >>  
> > >> +/**
> > >> + * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
> > >> + * @aux: DisplayPort AUX channel
> > >> + * @enable: Enable or disable transparent mode
> > >> + *
> > >> + * Returns 0 on success or a negative error code on failure.
> > >
> > > Should be "Returns 1 on success".
> > 
> > But is that a sensible return value?
> 
> It matches what the function returns, but yes, would make more sense to
> fix the return value instead to be 0 in case of success.

I think returning 0 is better in case of this function.

> 
> > >
> > >> + */
> > >> +
> > 
> > Superfluous newline.
> > 
> > >> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool 
> > >> enable)
> > >> +{
> > >> +u8 val = enable ? DP_PHY_REPEATER_MODE_TRANSPARENT :
> > >> +  DP_PHY_REPEATER_MODE_NON_TRANSPARENT;
> > >> +
> > >> +return drm_dp_dpcd_writeb(aux, DP_PHY_REPEATER_MODE, val);
> > >> +}
> > >> +EXPORT_SYMBOL(drm_dp_lttpr_set_transparent_mode);
> > >> +
> > >>  /**
> > >>   * drm_dp_lttpr_max_lane_count - get the maximum lane count supported 
> > >> by all LTTPRs
> > >>   * @caps: LTTPR common capabilities
> > >> diff --git a/include/drm/display/drm_dp_helper.h 
> > >> b/include/drm/display/drm_dp_helper.h
> > >> index 
> > >> 279624833ea9259809428162f4e845654359f8c9..8821ab2d36b0e04d38ccbdddcb703b34de7ed680
> > >>  100644
> > >> --- a/include/drm/display/drm_dp_helper.h
> > >> +++ b/include/drm/display/drm_dp_helper.h
> > >> @@ -625,6 +625,7 @@ int drm_dp_read_lttpr_phy_caps(struct drm_dp_aux 
> > >> *aux,
> > >> u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
> > >>  int drm_dp_lttpr_count(const u8 cap[DP_LTTPR_COMMON_CAP_SIZE]);
> > >>  int drm_dp_lttpr_max_link_rate(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
> > >> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool 
> > >> enable);
> > >>  int drm_dp_lttpr_max_lane_count(const u8 
> > >> caps[DP_LTTPR_COMMON_CAP_SIZE]);
> > >>  bool drm_dp_lttpr_voltage_swing_level_3_supported(const u8 
> > >> caps[DP_LTTPR_PHY_CAP_SIZE]);
> > >>  bool drm_dp_lttpr_pre_emphasis_level_3_supported(const u8 
> > >> caps[DP_LTTPR_PHY_CAP_SIZE]);
> > >> 
> > >> -- 
> > >> 2.34.1
> > >> 
> > 
> > -- 
> > Jani Nikula, Intel

-- 
With best wishes
Dmitry

Re: [PATCH 0/4] drm/msm/mdss: rework UBWC registers programming

[Dmitry Baryshkov]

On Sat, 21 Sep 2024 11:17:28 +0300, Dmitry Baryshkov wrote:
> Current way of programming of the UBWC-related registers has been
> inherited from vendor's drivers. The ubwc_static was supposed to contain
> raw data to be programmed to the hardware, but was later repurposed to
> define of the bits. As it can be seen by the commit 3e30296b374a
> ("drm/msm: fix the highest_bank_bit for sc7180") sometimes this data
> gets out of sync.
> 
> [...]

Applied, thanks!

[1/4] drm/msm: move MDSS registers to separate header file
  https://gitlab.freedesktop.org/lumag/msm/-/commit/92de8137d619
[2/4] drm/msm/mdss: use register definitions instead of hand-coding them
  https://gitlab.freedesktop.org/lumag/msm/-/commit/d742f7e06840

Best regards,
-- 
Dmitry Baryshkov 

Re: [PATCH] drm/msm/hdmi: mark interlace_allowed as true

[Dmitry Baryshkov]

On Fri, Nov 01, 2024 at 05:40:46PM -0700, Abhinav Kumar wrote:
> 
> 
> On 11/1/2024 3:26 PM, Dmitry Baryshkov wrote:
> > On Fri, 1 Nov 2024 at 23:41, Abhinav Kumar  
> > wrote:
> > > 
> > > 
> > > 
> > > On 10/18/2024 2:10 PM, Dmitry Baryshkov wrote:
> > > > The MSM HDMI driver supports interlaced modes. Set the corresponding
> > > > flag to allow interlaced modes on the corresponding connectors.
> > > > 
> > > > Signed-off-by: Dmitry Baryshkov 
> > > > ---
> > > >drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> > > >1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
> > > > b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > > > index 4a5b5112227f..643c152e6380 100644
> > > > --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > > > +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> > > > @@ -336,6 +336,7 @@ int msm_hdmi_bridge_init(struct hdmi *hdmi)
> > > >bridge->funcs = &msm_hdmi_bridge_funcs;
> > > >bridge->ddc = hdmi->i2c;
> > > >bridge->type = DRM_MODE_CONNECTOR_HDMIA;
> > > > + bridge->interlace_allowed = true;
> > > >bridge->ops = DRM_BRIDGE_OP_HPD |
> > > >DRM_BRIDGE_OP_DETECT |
> > > >DRM_BRIDGE_OP_EDID;
> > > > 
> > > 
> > > I had quite a bit of discussion on this internally because this spans
> > > quite a few generations of chipsets.
> > > 
> > > On very old hardware, even before msm8996, there was dedicated hardware
> > > de-interlacer. But even on msm8996 or other HDMI supported chipsets
> > > where the handling of if (mode->flags & DRM_MODE_FLAG_INTERLACE) is
> > > present, these were because its carry forward of older interface code.
> > > 
> > > The way we handle interlaced formats today, is software needs to handle
> > > the part of dividing height / 2 and width * 2 and adjust the source crop
> > > if necessary. This part has moved to userspace for recent chips.
> > > 
> > > Othwerise, we will need to add this part in the dpu driver to adjust
> > > this. I am not seeing this part there yet. So may I know how you
> > > validated this change? Something similar to :
> > > 
> > > https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/LE.UM.1.3.r3.25/drivers/gpu/drm/msm/sde/sde_plane.c#L1340
> > > 
> > > If we add this part first to dpu code, then we can mark interlace_allowed.
> > 
> > I think you are mixing the interlaced formats and interlaced output.
> > The code that you have pointed to is related to hardware deinterlacing
> > - in other words taking the interlaced framebuffer and outputting it
> > to the progressive display.
> > 
> > The interlace_allowed flag controls a different feature - filtering of
> > the internalced modes (aka 576i, 1080i, etc). In this case we are
> > using progressive frames, but the HDMI outputs a picture as two
> > separate fields. I have validated this by outputting image (modetest)
> > to the external HDMI display on IFC6410 and on DB820c boards.
> > 
> 
> Yes I did think that this was to show interlaced content but that being
> said, I traced through the HDMI code a bit, it does have support for
> changing the HDMI timing but without the support of dpu, progressive content
> really cannot be converted to interlaced. So I think the HDMI pieces there
> were supposed to go along with the rest of the dpu pipeline that is the
> entire pipeline shows out interlaced content. But dpu support for giving out
> interlaced content is not there, so this hdmi piece by itself is not
> complete enough to mark interlace_allowed as true.

I could not find corresponding bits in the original fbdev or SDE
drivers. My quick tests showed the correct context, but most likely I
need to revertify that. Unfortunately next week I won't be able to run
the tests, so this gets into the 6.14 area.

-- 
With best wishes
Dmitry

Re: [PATCH v2 3/3] drm/panel: add LXD M9189A panel driver

[kernel test robot]

Hi Rouven,

kernel test robot noticed the following build errors:

[auto build test ERROR on c2ee9f594da826bea183ed14f2cc029c719bf4da]

url:
https://github.com/intel-lab-lkp/linux/commits/Rouven-Czerwinski/dt-bindings-display-panel-add-YAML-schema-for-LXD-M9189A/20241025-221252
base:   c2ee9f594da826bea183ed14f2cc029c719bf4da
patch link:
https://lore.kernel.org/r/20241025141130.3179166-3-r.czerwinski%40pengutronix.de
patch subject: [PATCH v2 3/3] drm/panel: add LXD M9189A panel driver
config: arm-randconfig-r062-20241102 
(https://download.01.org/0day-ci/archive/20241102/202411020816.nb9aevto-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20241102/202411020816.nb9aevto-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202411020816.nb9aevto-...@intel.com/

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/panel/panel-lxd-m9189a.c:173:29: error: variable 'ret' is 
>> uninitialized when used here [-Werror,-Wuninitialized]
 173 | return dev_err_probe(dev, ret, "Failed to get 
regulator\n");
 |   ^~~
   drivers/gpu/drm/panel/panel-lxd-m9189a.c:165:9: note: initialize the 
variable 'ret' to silence this warning
 165 | int ret;
 |^
 | = 0
   1 error generated.


vim +/ret +173 drivers/gpu/drm/panel/panel-lxd-m9189a.c

   160  
   161  static int lxd_m9189_probe(struct mipi_dsi_device *dsi)
   162  {
   163  struct device *dev = &dsi->dev;
   164  struct m9189_panel *m9189;
   165  int ret;
   166  
   167  m9189 = devm_kzalloc(dev, sizeof(*m9189), GFP_KERNEL);
   168  if (!m9189)
   169  return -ENOMEM;
   170  
   171  m9189->supply = devm_regulator_get(dev, "vdd");
   172  if (IS_ERR(m9189->supply))
 > 173  return dev_err_probe(dev, ret, "Failed to get 
 > regulator\n");
   174  
   175  m9189->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
   176  if (IS_ERR(m9189->reset_gpio))
   177  return dev_err_probe(dev, PTR_ERR(m9189->reset_gpio),
   178   "Failed to get reset-gpios\n");
   179  
   180  m9189->standby_gpio = devm_gpiod_get(dev, "standby", 
GPIOD_OUT_LOW);
   181  if (IS_ERR(m9189->standby_gpio))
   182  return dev_err_probe(dev, PTR_ERR(m9189->standby_gpio),
   183   "Failed to get standby-gpios\n");
   184  
   185  m9189->dsi = dsi;
   186  mipi_dsi_set_drvdata(dsi, m9189);
   187  
   188  dsi->lanes = 4;
   189  dsi->format = MIPI_DSI_FMT_RGB888;
   190  dsi->mode_flags = MIPI_DSI_MODE_VIDEO | 
MIPI_DSI_MODE_VIDEO_BURST;
   191  
   192  drm_panel_init(&m9189->panel, dev, &m9189_panel_funcs,
   193 DRM_MODE_CONNECTOR_DSI);
   194  m9189->panel.prepare_prev_first = true;
   195  
   196  ret = drm_panel_of_backlight(&m9189->panel);
   197  if (ret)
   198  return dev_err_probe(dev, ret, "Failed to get 
backlight\n");
   199  
   200  drm_panel_add(&m9189->panel);
   201  
   202  ret = mipi_dsi_attach(dsi);
   203  if (ret < 0) {
   204  dev_err_probe(dev, ret, "Failed to attach to DSI 
host\n");
   205  drm_panel_remove(&m9189->panel);
   206  return ret;
   207  }
   208  
   209  return 0;
   210  }
   211  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v3 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

[胡俊光]

Re: [PATCH v2] drm/bridge: Fix assignment of the of_node of the parent to aux bridge

[Johan Hovold]

On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> On 2024/11/1 00:23, Johan Hovold wrote:
> > On Thu, Oct 31, 2024 at 11:06:38PM +0800, Sui Jingfeng wrote:
> >
> >> But I think Johan do need more times to understand what exactly
> >> the real problem is. We do need times to investigate new method.

> > No, I know perfectly well what the (immediate) problem is here (I was
> > the one adding support for the of_node_reused flag some years back).
> >
> > I just wanted to make sure that the commit message was correct and
> > complete before merging (and also to figure out whether this particular
> > patch needed to be backported).
> 
> Well under such a design, having the child device sharing the 'OF' device
> node with it parent device means that one parent device can *only*
> create one AUX bridge child device.
> 
> Since If you create two or more child AUX bridge, *all* of them will
> call devm_drm_of_get_bridge(&auxdev->dev, auxdev->dev.of_node, 0, 0),
> then we will *contend* the same next bridge resource.
> 
> Because of the 'auxdev->dev.of_node' is same for all its instance.
> While other display bridges seems don't has such limitations.

Oh, I'm not saying that there cannot be further issues with the design
or implementation here. And perhaps fixing those would make the
immediate issue Abel was trying to address go away.

Johan

Re: [PATCH] fbdev: udl: Make CONFIG_FB_DEVICE optional

[Thomas Zimmermann]

Hi

Am 30.10.24 um 10:30 schrieb Helge Deller:



I'm happy to get rid of the fbdev drivers, but for that DRM really 
needs
to allow some sort of native fillrect, copyarea and imageblt 
operations so
that we can get performance back on the old cards when implementing 
them

as DRM driver.


This is unrelated to udl.


No, it's not.
The udl fbdev driver implements those functions (like the other fbdev 
drivers)
and as such fbcon on top of udl is accelerated, while fbcon on drm 
drivers

is unaccelerated.


Udlfb uses the regular software implementations to draw into its shadow 
buffer. It then schedules an update to copy the update over USB to the 
adapter's internal framebuffer memory. [1] Udl uses exactly the same 
code pattern and most of the involved helpers. [2]


[1] 
https://elixir.bootlin.com/linux/v6.11.5/source/drivers/video/fbdev/udlfb.c#L1145
[2] 
https://elixir.bootlin.com/linux/v6.11.5/source/drivers/gpu/drm/drm_fbdev_shmem.c#L39


Best regards
Thomas



Helge


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH v2] amdgpu: prevent NULL pointer dereference if ATIF is not supported

[Antonio Quartulli]

On 31/10/2024 20:37, Mario Limonciello wrote:

On 10/31/2024 10:28, Antonio Quartulli wrote:

acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.

Although this case may be unrealistic for the current code, it is
still better to protect against possible bugs.

Bail out also when status is AE_NOT_FOUND.

This fixes 1 FORWARD_NULL issue reported by Coverity
Report: CID 1600951:  Null pointer dereferences  (FORWARD_NULL)

Signed-off-by: Antonio Quartulli 


Can you please dig up the right Fixes: tag?


Fixes: c9b7c809b89f ("drm/amd: Guard against bad data for ATIF ACPI method")

Your commit :)

Should I send v3 with the Fixes tag in it?

Interestingly, this pattern of checking for AE_NOT_FOUND is shared by 
other functions, however, they don't try to dereference the pointer to 
the buffer before the return statement (which caused the Coverity report).

It's the caller that checks if the return value is NULL or not.

For this function it was the same, until you added this extra check on 
obj->type, without checking if obj was NULL or not.


If we want to keep the original pattern and continue checking for 
AE_NOT_FOUND, we could rather do:


-   if (obj->type != ACPI_TYPE_BUFFER) {
+   if (obj && obj->type != ACPI_TYPE_BUFFER) {

But this feel more like "bike shed color picking" than anything else :)
Anyway, up to you Mario, I am open to change the patch again if the 
latter pattern is more preferable.


Regards,



Besides that, LGTM.

Reviewed-by: Mario Limonciello 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c b/drivers/gpu/ 
drm/amd/amdgpu/amdgpu_acpi.c

index cce85389427f..b8d4e07d2043 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -172,8 +172,8 @@ static union acpi_object *amdgpu_atif_call(struct 
amdgpu_atif *atif,

    &buffer);
  obj = (union acpi_object *)buffer.pointer;
-    /* Fail if calling the method fails and ATIF is supported */
-    if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+    /* Fail if calling the method fails */
+    if (ACPI_FAILURE(status)) {
  DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
   acpi_format_exception(status));
  kfree(obj);




--
Antonio Quartulli

CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com

Re: [PATCH] drm/mediatek: Drop dependency on ARM

[Chen-Yu Tsai]

On Tue, 29 Oct 2024 19:13:07 +0800, Chen-Yu Tsai wrote:
> The recent attempt to make the MediaTek DRM driver build for non-ARM
> compile tests made the driver unbuildable for arm64 platforms. Since
> this is used on both ARM and arm64 platforms, just drop the dependency
> on ARM.
> 
> 

Applied, thanks!

[1/1] drm/mediatek: Drop dependency on ARM
  commit: 89115aeecf38bfee3c5e79561b5c34a256e1a06a

Best regards,
-- 
Chen-Yu Tsai 

Re: [PATCH v2] drm/bridge: Fix assignment of the of_node of the parent to aux bridge

[Laurent Pinchart]

On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> 
> On 2024/11/1 00:23, Johan Hovold wrote:
> > On Thu, Oct 31, 2024 at 11:06:38PM +0800, Sui Jingfeng wrote:
> >
> >> But I think Johan do need more times to understand what exactly
> >> the real problem is. We do need times to investigate new method.
> > No, I know perfectly well what the (immediate) problem is here (I was
> > the one adding support for the of_node_reused flag some years back).
> >
> > I just wanted to make sure that the commit message was correct and
> > complete before merging (and also to figure out whether this particular
> > patch needed to be backported).
> 
> Well under such a design, having the child device sharing the 'OF' device
> node with it parent device means that one parent device can *only*
> create one AUX bridge child device.
> 
> Since If you create two or more child AUX bridge, *all* of them will
> call devm_drm_of_get_bridge(&auxdev->dev, auxdev->dev.of_node, 0, 0),
> then we will *contend* the same next bridge resource.
> 
> Because of the 'auxdev->dev.of_node' is same for all its instance.
> While other display bridges seems don't has such limitations.

Brainstorming a bit, I wonder if we could create a swnode for the
auxiliary device, instead of reusing the parent's OF node. This would
require switching the DRM OF-based APIs to fwnode, but that's easy and
mostly a mechanical change.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

[胡俊光]

Re: [PATCH RFC 1/4] drm/dp: Add helper to set LTTPRs in transparent mode

[Jani Nikula]

On Thu, 31 Oct 2024, Imre Deak  wrote:
> On Thu, Oct 31, 2024 at 05:12:45PM +0200, Abel Vesa wrote:
>> According to the DisplayPort standard, LTTPRs have two operating
>> modes:
>>  - non-transparent - it replies to DPCD LTTPR field specific AUX
>>requests, while passes through all other AUX requests
>>  - transparent - it passes through all AUX requests.
>> 
>> Switching between this two modes is done by the DPTX by issuing
>> an AUX write to the DPCD PHY_REPEATER_MODE register.
>> 
>> Add a generic helper that allows switching between these modes.
>> 
>> Signed-off-by: Abel Vesa 
>> ---
>>  drivers/gpu/drm/display/drm_dp_helper.c | 17 +
>>  include/drm/display/drm_dp_helper.h |  1 +
>>  2 files changed, 18 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
>> b/drivers/gpu/drm/display/drm_dp_helper.c
>> index 
>> 6ee51003de3ce616c3a52653c2f1979ad7658e21..38d612345986ad54b42228902ea718a089d169c4
>>  100644
>> --- a/drivers/gpu/drm/display/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
>> @@ -2694,6 +2694,23 @@ int drm_dp_lttpr_max_link_rate(const u8 
>> caps[DP_LTTPR_COMMON_CAP_SIZE])
>>  }
>>  EXPORT_SYMBOL(drm_dp_lttpr_max_link_rate);
>>  
>> +/**
>> + * drm_dp_lttpr_set_transparent_mode - set the LTTPR in transparent mode
>> + * @aux: DisplayPort AUX channel
>> + * @enable: Enable or disable transparent mode
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>
> Should be "Returns 1 on success".

But is that a sensible return value?

>
>> + */
>> +

Superfluous newline.

>> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool enable)
>> +{
>> +u8 val = enable ? DP_PHY_REPEATER_MODE_TRANSPARENT :
>> +  DP_PHY_REPEATER_MODE_NON_TRANSPARENT;
>> +
>> +return drm_dp_dpcd_writeb(aux, DP_PHY_REPEATER_MODE, val);
>> +}
>> +EXPORT_SYMBOL(drm_dp_lttpr_set_transparent_mode);
>> +
>>  /**
>>   * drm_dp_lttpr_max_lane_count - get the maximum lane count supported by 
>> all LTTPRs
>>   * @caps: LTTPR common capabilities
>> diff --git a/include/drm/display/drm_dp_helper.h 
>> b/include/drm/display/drm_dp_helper.h
>> index 
>> 279624833ea9259809428162f4e845654359f8c9..8821ab2d36b0e04d38ccbdddcb703b34de7ed680
>>  100644
>> --- a/include/drm/display/drm_dp_helper.h
>> +++ b/include/drm/display/drm_dp_helper.h
>> @@ -625,6 +625,7 @@ int drm_dp_read_lttpr_phy_caps(struct drm_dp_aux *aux,
>> u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
>>  int drm_dp_lttpr_count(const u8 cap[DP_LTTPR_COMMON_CAP_SIZE]);
>>  int drm_dp_lttpr_max_link_rate(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
>> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool enable);
>>  int drm_dp_lttpr_max_lane_count(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
>>  bool drm_dp_lttpr_voltage_swing_level_3_supported(const u8 
>> caps[DP_LTTPR_PHY_CAP_SIZE]);
>>  bool drm_dp_lttpr_pre_emphasis_level_3_supported(const u8 
>> caps[DP_LTTPR_PHY_CAP_SIZE]);
>> 
>> -- 
>> 2.34.1
>> 

-- 
Jani Nikula, Intel

Re: [PATCH] drm/vkms: Drop unnecessary call to drm_crtc_cleanup()

[Maíra Canal]

Hi José,

On 31/10/24 15:38, José Expósito wrote:

CRTC creation uses drmm_crtc_init_with_planes(), which automatically
handles cleanup. However, an unnecessary call to drm_crtc_cleanup() is
still present in the vkms_output_init() error path.

Fixes: 99cc528ebe92 ("drm/vkms: Use drmm_crtc_init_with_planes()")
Signed-off-by: José Expósito 


Reviewed-by: Maíra Canal 

Best Regards,
- Maíra


---
  drivers/gpu/drm/vkms/vkms_output.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_output.c 
b/drivers/gpu/drm/vkms/vkms_output.c
index 0a5a185aa0b0..25a99fde126c 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -92,7 +92,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
 DRM_MODE_CONNECTOR_VIRTUAL);
if (ret) {
DRM_ERROR("Failed to init connector\n");
-   goto err_connector;
+   return ret;
}
  
  	drm_connector_helper_add(connector, &vkms_conn_helper_funcs);

@@ -131,8 +131,5 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
  err_encoder:
drm_connector_cleanup(connector);
  
-err_connector:

-   drm_crtc_cleanup(crtc);
-
return ret;
  }

Re: [PATCH v2] drm/bridge: Fix assignment of the of_node of the parent to aux bridge

[Abel Vesa]

On 24-10-31 17:33:35, Johan Hovold wrote:
> On Thu, Oct 31, 2024 at 06:13:45PM +0200, Abel Vesa wrote:
> > On 24-10-31 15:05:52, Johan Hovold wrote:
> > > On Mon, Oct 21, 2024 at 09:23:24AM +0200, Johan Hovold wrote:
> > > > On Fri, Oct 18, 2024 at 03:49:34PM +0300, Abel Vesa wrote:
> 
> > > > > Cc: sta...@vger.kernel.org  # 6.8
> > 
> > > > I assume there are no existing devicetrees that need this since then we
> > > > would have heard about it sooner. Do we still need to backport it?
> > 
> > None of the DTs I managed to scan seem to have this problem.
> > 
> > Maybe backporting it is not worth it then.
> 
> Thanks for confirming. Which (new) driver and DT are you seeing this
> with?

The Parade PS8830 retimer and its DT node. The v3 of that patchset
will not trigger it unless the pinctrl properties are being added to the
retimer node.

> 
> > > > When exactly are you hitting this?
> > 
> > Here is one of the examples.
> > 
> > [5.768283] x1e80100-tlmm f10.pinctrl: error -EINVAL: pin-185 
> > (aux_bridge.aux_bridge.3)
> > [5.768289] x1e80100-tlmm f10.pinctrl: error -EINVAL: could not 
> > request pin 185 (GPIO_185) from group gpio185 on device f10.pinctrl
> > [5.768293] aux_bridge.aux_bridge aux_bridge.aux_bridge.3: Error 
> > applying setting, reverse things back
> 
> I meant with which driver and DT you hit this with.
> 
> > > Abel, even if Neil decided to give me the finger here, please answer the
> > > above so that it's recorded in the archives at least.
> 
> > Sorry for not replying in time before the patch was merge.
> 
> That's not your fault.
> 
> Johan
> 

[Bug 206225] nouveau: Screen distortion and lockup on resume

[bugzilla-daemon]

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

lukasz.wojnilow...@gmail.com changed:

   What|Removed |Added

 CC||lukasz.wojnilow...@gmail.co
   ||m

--- Comment #13 from lukasz.wojnilow...@gmail.com ---
We have 2024 and https://nouveau.freedesktop.org/KernelModuleParameters.html
(updated in 2024) still recommends using nouveau.config=PCRYPT=0 instead of
nouveau.config=cipher=0.

I believe that correct names can be taken at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine
from the directory names.

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

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

[PATCH RFC v2 5/7] drm/bridge: lt9611: switch to using the DRM HDMI codec framework

[Dmitry Baryshkov]

Make the Lontium LT9611 DSI-to-HDMI bridge driver use the DRM HDMI Codec
framework. This enables programming of Audio InfoFrames using the HDMI
Connector interface and also enables support for the missing features,
including the ELD retrieval and better hotplug support.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/bridge/lontium-lt9611.c | 171 +---
 1 file changed, 69 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 
4fa0dfc5539a5786278221f7c13b6473ab320a9a..9d8b1c8d533c79bd91ae956aa4cb74f3bab6de78
 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -45,7 +45,6 @@ struct lt9611 {
struct device_node *dsi1_node;
struct mipi_dsi_device *dsi0;
struct mipi_dsi_device *dsi1;
-   struct platform_device *audio_pdev;
 
bool ac_mode;
 
@@ -866,6 +865,10 @@ static int lt9611_hdmi_clear_infoframe(struct drm_bridge 
*bridge,
unsigned int mask;
 
switch (type) {
+   case HDMI_INFOFRAME_TYPE_AUDIO:
+   mask = LT9611_INFOFRAME_AUDIO;
+   break;
+
case HDMI_INFOFRAME_TYPE_AVI:
mask = LT9611_INFOFRAME_AVI;
break;
@@ -899,6 +902,11 @@ static int lt9611_hdmi_write_infoframe(struct drm_bridge 
*bridge,
int i;
 
switch (type) {
+   case HDMI_INFOFRAME_TYPE_AUDIO:
+   mask = LT9611_INFOFRAME_AUDIO;
+   addr = 0x84b2;
+   break;
+
case HDMI_INFOFRAME_TYPE_AVI:
mask = LT9611_INFOFRAME_AVI;
addr = 0x8440;
@@ -942,6 +950,55 @@ lt9611_hdmi_tmds_char_rate_valid(const struct drm_bridge 
*bridge,
return MODE_OK;
 }
 
+static int lt9611_hdmi_codec_audio_startup(struct drm_connector *connector,
+  struct drm_bridge *bridge)
+{
+   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
+
+   regmap_write(lt9611->regmap, 0x82d6, 0x8c);
+   regmap_write(lt9611->regmap, 0x82d7, 0x04);
+
+   regmap_write(lt9611->regmap, 0x8406, 0x08);
+   regmap_write(lt9611->regmap, 0x8407, 0x10);
+
+   regmap_write(lt9611->regmap, 0x8434, 0xd5);
+
+   return 0;
+}
+
+static int lt9611_hdmi_codec_prepare(struct drm_connector *connector,
+struct drm_bridge *bridge,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms)
+{
+   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
+
+   if (hparms->sample_rate == 48000)
+   regmap_write(lt9611->regmap, 0x840f, 0x2b);
+   else if (hparms->sample_rate == 96000)
+   regmap_write(lt9611->regmap, 0x840f, 0xab);
+   else
+   return -EINVAL;
+
+   regmap_write(lt9611->regmap, 0x8435, 0x00);
+   regmap_write(lt9611->regmap, 0x8436, 0x18);
+   regmap_write(lt9611->regmap, 0x8437, 0x00);
+
+   return 
drm_atomic_helper_connector_hdmi_update_audio_infoframe(connector,
+  
&hparms->cea);
+}
+
+static void lt9611_hdmi_codec_audio_shutdown(struct drm_connector *connector,
+struct drm_bridge *bridge)
+{
+   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
+
+   drm_atomic_helper_connector_hdmi_clear_audio_infoframe(connector);
+
+   regmap_write(lt9611->regmap, 0x8406, 0x00);
+   regmap_write(lt9611->regmap, 0x8407, 0x00);
+}
+
 static const struct drm_bridge_funcs lt9611_bridge_funcs = {
.attach = lt9611_bridge_attach,
.mode_valid = lt9611_bridge_mode_valid,
@@ -962,6 +1019,10 @@ static const struct drm_bridge_funcs lt9611_bridge_funcs 
= {
.hdmi_tmds_char_rate_valid = lt9611_hdmi_tmds_char_rate_valid,
.hdmi_write_infoframe = lt9611_hdmi_write_infoframe,
.hdmi_clear_infoframe = lt9611_hdmi_clear_infoframe,
+
+   .hdmi_codec_audio_startup = lt9611_hdmi_codec_audio_startup,
+   .hdmi_codec_prepare = lt9611_hdmi_codec_prepare,
+   .hdmi_codec_audio_shutdown = lt9611_hdmi_codec_audio_shutdown,
 };
 
 static int lt9611_parse_dt(struct device *dev,
@@ -1015,102 +1076,6 @@ static int lt9611_read_device_rev(struct lt9611 *lt9611)
return ret;
 }
 
-static int lt9611_hdmi_hw_params(struct device *dev, void *data,
-struct hdmi_codec_daifmt *fmt,
-struct hdmi_codec_params *hparms)
-{
-   struct lt9611 *lt9611 = data;
-
-   if (hparms->sample_rate == 48000)
-   regmap_write(lt9611->regmap, 0x840f, 0x2b);
-   else if (hparms->sample_rate == 96000)
-   regmap_write(lt9611->regmap, 0x840f, 0xab);
-   else
-   return -EINVAL;
-
-   regmap_write(lt9611->regmap, 0x8435, 0x00);
-   regmap_write(lt9611->re

[PATCH RFC v2 1/7] ASoC: hdmi-codec: pass data to get_dai_id too

[Dmitry Baryshkov]

The upcoming DRM connector HDMI codec implementation is going to use
codec-specific data in the .get_dai_id to get drm_connector. Pass data
to the callback, as it is done with other hdmi_codec_ops callbacks.

Acked-by: Mark Brown 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c  | 3 ++-
 drivers/gpu/drm/bridge/analogix/anx7625.c   | 3 ++-
 drivers/gpu/drm/bridge/lontium-lt9611.c | 3 ++-
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c  | 3 ++-
 drivers/gpu/drm/bridge/sii902x.c| 3 ++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
 include/sound/hdmi-codec.h  | 3 ++-
 sound/soc/codecs/hdmi-codec.c   | 2 +-
 8 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index 
61f4a38e7d2bf6905683cbc9e762b28ecc999d05..51fb9a574b4e28450b2598a92e2930ace5128b71
 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -204,7 +204,8 @@ static void audio_shutdown(struct device *dev, void *data)
 }
 
 static int adv7511_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
-   struct device_node *endpoint)
+   struct device_node *endpoint,
+   void *data)
 {
struct of_endpoint of_ep;
int ret;
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 
a2675b121fe44b96945f34215fd900f35bfde43a..926437346b6c9a651d495faf25162cac7407d30d
 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1952,7 +1952,8 @@ static void anx7625_audio_shutdown(struct device *dev, 
void *data)
 }
 
 static int anx7625_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
-  struct device_node *endpoint)
+  struct device_node *endpoint,
+  void *data)
 {
struct of_endpoint of_ep;
int ret;
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 
1b31fdebe164063e6f3972fdf8a5801ef4c35c4e..4fa0dfc5539a5786278221f7c13b6473ab320a9a
 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -1059,7 +1059,8 @@ static void lt9611_audio_shutdown(struct device *dev, 
void *data)
 }
 
 static int lt9611_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
- struct device_node *endpoint)
+ struct device_node *endpoint,
+ void *data)
 {
struct of_endpoint of_ep;
int ret;
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 
4d1d40e1f1b4d144f4aa9de7b83bedf13dfa4436..fd26aa36b15b8c0d3859f7ef488a87573eea8507
 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -522,7 +522,8 @@ static void lt9611uxc_audio_shutdown(struct device *dev, 
void *data)
 }
 
 static int lt9611uxc_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
-struct device_node *endpoint)
+struct device_node *endpoint,
+void *data)
 {
struct of_endpoint of_ep;
int ret;
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 
9be9cc5b902594ebe6e1ac29ab8684623e336796..f0be803cc2274ca2199ed7661cf752b0a91434b6
 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -815,7 +815,8 @@ static int sii902x_audio_get_eld(struct device *dev, void 
*data,
 }
 
 static int sii902x_audio_get_dai_id(struct snd_soc_component *component,
-   struct device_node *endpoint)
+   struct device_node *endpoint,
+   void *data)
 {
struct of_endpoint of_ep;
int ret;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 
26c187d20d973dc65801a3baa59ecf57d20072eb..86c412e9cbc80bb82bad5db3aa0263a7acd9c2d7
 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -148,7 +148,8 @@ static int dw_hdmi_i2s_get_eld(struct device *dev, void 
*data, uint8_t *buf,
 }
 
 static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
- struct device_node *endpoint)
+ struct device_node *endpoint,
+ void *data)
 {
   

[PATCH RFC v2 2/7] ASoC: hdmi-codec: move no_capture_mute to struct hdmi_codec_pdata

[Dmitry Baryshkov]

The no_capture_mute flag might differ from platform to platform,
especially in the case of the wrapping implementations, like the
upcoming DRM HDMI Codec framework. Move the flag next to all other flags
in struct hdmi_codec_pdata.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/bridge/ite-it66121.c   | 2 +-
 drivers/gpu/drm/bridge/sii902x.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c  | 2 +-
 drivers/gpu/drm/mediatek/mtk_dp.c  | 2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c| 2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
 drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
 include/sound/hdmi-codec.h | 4 +---
 sound/soc/codecs/hdmi-codec.c  | 2 +-
 10 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
b/drivers/gpu/drm/bridge/ite-it66121.c
index 
35ae3f0e8f51f768229e055a086b53a419ffcd9f..98669470d1e955fef36bb4592795fed6ca97139c
 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -1464,7 +1464,6 @@ static const struct hdmi_codec_ops 
it66121_audio_codec_ops = {
.audio_shutdown = it66121_audio_shutdown,
.mute_stream = it66121_audio_mute,
.get_eld = it66121_audio_get_eld,
-   .no_capture_mute = 1,
 };
 
 static int it66121_audio_codec_init(struct it66121_ctx *ctx, struct device 
*dev)
@@ -1474,6 +1473,7 @@ static int it66121_audio_codec_init(struct it66121_ctx 
*ctx, struct device *dev)
.i2s = 1, /* Only i2s support for now */
.spdif = 0,
.max_i2s_channels = 8,
+   .no_capture_mute = 1,
};
 
dev_dbg(dev, "%s\n", __func__);
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 
f0be803cc2274ca2199ed7661cf752b0a91434b6..5248676b0036a7e8f2142bd2f099c36efb529471
 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -841,7 +841,6 @@ static const struct hdmi_codec_ops sii902x_audio_codec_ops 
= {
.mute_stream = sii902x_audio_mute,
.get_eld = sii902x_audio_get_eld,
.get_dai_id = sii902x_audio_get_dai_id,
-   .no_capture_mute = 1,
 };
 
 static int sii902x_audio_codec_init(struct sii902x *sii902x,
@@ -864,6 +863,7 @@ static int sii902x_audio_codec_init(struct sii902x *sii902x,
.i2s = 1, /* Only i2s support for now. */
.spdif = 0,
.max_i2s_channels = 0,
+   .no_capture_mute = 1,
};
u8 lanes[4];
int num_lanes, i;
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 
c9d4b9146df95bb46cb6bea4849c331616c2b463..2a74396ac846dc34d87fadea700c387d597ba307
 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1658,7 +1658,6 @@ static const struct hdmi_codec_ops audio_codec_ops = {
.audio_shutdown = hdmi_audio_shutdown,
.mute_stream = hdmi_audio_mute,
.get_eld = hdmi_audio_get_eld,
-   .no_capture_mute = 1,
 };
 
 static int hdmi_register_audio_device(struct hdmi_context *hdata)
@@ -1667,6 +1666,7 @@ static int hdmi_register_audio_device(struct hdmi_context 
*hdata)
.ops = &audio_codec_ops,
.max_i2s_channels = 6,
.i2s = 1,
+   .no_capture_mute = 1,
};
 
hdata->audio.pdev = platform_device_register_data(
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 
2160f05bbd16d2346e27365e5549b75ad26fdcb9..10a4195d667ff577183788f8fc7ca806660e2b9c
 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1165,7 +1165,6 @@ static const struct hdmi_codec_ops audio_codec_ops = {
.audio_shutdown = tda998x_audio_shutdown,
.mute_stream = tda998x_audio_mute_stream,
.get_eld = tda998x_audio_get_eld,
-   .no_capture_mute = 1,
 };
 
 static int tda998x_audio_codec_init(struct tda998x_priv *priv,
@@ -1176,6 +1175,7 @@ static int tda998x_audio_codec_init(struct tda998x_priv 
*priv,
.max_i2s_channels = 2,
.no_i2s_capture = 1,
.no_spdif_capture = 1,
+   .no_capture_mute = 1,
};
 
if (priv->audio_port_enable[AUDIO_ROUTE_I2S])
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 
f0f6f402994a7be7e3faee68d66bdb25888ab768..b401246b8f884b9885ece7aaac23a4de2826fb0a
 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2532,7 +2532,6 @@ static const struct hdmi_codec_ops mtk_dp_audio_codec_ops 
= {
.audio_shutdown = mtk_dp_audio_shutdown,
.get_eld = mtk_dp_audio_get_eld,
.hook_plugged_cb = mtk_dp_audio_hook_plugged_cb,
-   .no_capture_mute = 1,
 };
 
 static int mtk_dp_register_audio_driver(struct device *dev)
@@ -2543,6 +2542,7 @@ static int m

[PATCH RFC v2 4/7] drm/bridge: connector: add support for HDMI codec framework

[Dmitry Baryshkov]

Add necessary glue code to be able to use new HDMI codec framework from
the DRM bridge drivers. The drm_bridge implements a limited set of the
hdmi_codec_ops interface, with the functions accepting both
drm_connector and drm_bridge instead of just a generic void pointer.

This framework is integrated with the DRM HDMI Connector framework, but
can also be used for DisplayPort connectors.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_bridge_connector.c | 95 +-
 include/drm/drm_bridge.h   | 23 +++
 2 files changed, 116 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c 
b/drivers/gpu/drm/display/drm_bridge_connector.c
index 
320c297008aaa8b6ef5b1f4c71928849b202e8ac..12ab9f14cc8a8672478ae2804c9a68d766d88ea5
 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include 
+
 /**
  * DOC: overview
  *
@@ -354,10 +356,80 @@ static int drm_bridge_connector_write_infoframe(struct 
drm_connector *connector,
return bridge->funcs->hdmi_write_infoframe(bridge, type, buffer, len);
 }
 
+static int drm_bridge_connector_audio_startup(struct drm_connector *connector)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+   struct drm_bridge *bridge;
+
+   bridge = bridge_connector->bridge_hdmi;
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->funcs->hdmi_codec_audio_startup)
+   return bridge->funcs->hdmi_codec_audio_startup(connector, 
bridge);
+   else
+   return 0;
+}
+
+static int drm_bridge_connector_prepare(struct drm_connector *connector,
+   struct hdmi_codec_daifmt *fmt,
+   struct hdmi_codec_params *hparms)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+   struct drm_bridge *bridge;
+
+   bridge = bridge_connector->bridge_hdmi;
+   if (!bridge)
+   return -EINVAL;
+
+   return bridge->funcs->hdmi_codec_prepare(connector, bridge, fmt, 
hparms);
+}
+
+static void drm_bridge_connector_audio_shutdown(struct drm_connector 
*connector)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+   struct drm_bridge *bridge;
+
+   bridge = bridge_connector->bridge_hdmi;
+   if (!bridge)
+   return;
+
+   bridge->funcs->hdmi_codec_audio_shutdown(connector, bridge);
+}
+
+static int drm_bridge_connector_mute_stream(struct drm_connector *connector,
+   bool enable, int direction)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+   struct drm_bridge *bridge;
+
+   bridge = bridge_connector->bridge_hdmi;
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->funcs->hdmi_codec_mute_stream)
+   return bridge->funcs->hdmi_codec_mute_stream(connector, bridge,
+enable, direction);
+   else
+   return -ENOTSUPP;
+}
+
+static const struct drm_connector_hdmi_codec_funcs 
drm_bridge_connector_hdmi_codec_funcs = {
+   .audio_startup = drm_bridge_connector_audio_startup,
+   .prepare = drm_bridge_connector_prepare,
+   .audio_shutdown = drm_bridge_connector_audio_shutdown,
+   .mute_stream = drm_bridge_connector_mute_stream,
+};
+
 static const struct drm_connector_hdmi_funcs drm_bridge_connector_hdmi_funcs = 
{
.tmds_char_rate_valid = drm_bridge_connector_tmds_char_rate_valid,
.clear_infoframe = drm_bridge_connector_clear_infoframe,
.write_infoframe = drm_bridge_connector_write_infoframe,
+   .codec_funcs = &drm_bridge_connector_hdmi_codec_funcs,
 };
 
 /* 
-
@@ -459,7 +531,25 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
if (connector_type == DRM_MODE_CONNECTOR_Unknown)
return ERR_PTR(-EINVAL);
 
-   if (bridge_connector->bridge_hdmi)
+   if (bridge_connector->bridge_hdmi) {
+   bridge = bridge_connector->bridge_hdmi;
+
+   if (bridge->hdmi_codec_i2s ||
+   bridge->hdmi_codec_spdif) {
+   if (!bridge->funcs->hdmi_codec_prepare ||
+   !bridge->funcs->hdmi_codec_audio_shutdown)
+   return ERR_PTR(-EINVAL);
+
+   bridge_connector->bridge_hdmi = bridge;
+
+   connector->hdmi_codec.dev = bridge->hdmi_codec_dev;
+   connector->hdmi_codec.i2s = bridge->hdmi_codec_i2s;
+   connector->hdm

[PATCH RFC v2 7/7] drm/bridge_connector: hook __drm_atomic_helper_connector_hdmi_update_edid()

[Dmitry Baryshkov]

Extend drm_bridge_connector code to read the EDID and use it to update
connector status if the bridge chain implements HDMI bridge. Performing
it from the generic location minimizes individual bridge's code and
enforces standard behaviour from all corresponding drivers.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_bridge_connector.c | 65 --
 1 file changed, 51 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c 
b/drivers/gpu/drm/display/drm_bridge_connector.c
index 
12ab9f14cc8a8672478ae2804c9a68d766d88ea5..4069e0f972d5fcabf7e07238583fc9ea89ab113f
 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -175,17 +176,53 @@ static void drm_bridge_connector_disable_hpd(struct 
drm_connector *connector)
  * Bridge Connector Functions
  */
 
+static const struct drm_edid *
+drm_bridge_connector_read_edid(struct drm_connector *connector,
+  enum drm_connector_status status)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+   const struct drm_edid *drm_edid;
+   struct drm_bridge *bridge;
+
+   bridge = bridge_connector->bridge_edid;
+   if (!bridge)
+   return NULL;
+
+   if (status != connector_status_connected)
+   return NULL;
+
+   drm_edid = drm_bridge_edid_read(bridge, connector);
+   if (!drm_edid_valid(drm_edid)) {
+   drm_edid_free(drm_edid);
+   return NULL;
+   }
+
+   return drm_edid;
+}
+
 static enum drm_connector_status
 drm_bridge_connector_detect(struct drm_connector *connector, bool force)
 {
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
struct drm_bridge *detect = bridge_connector->bridge_detect;
+   struct drm_bridge *hdmi = bridge_connector->bridge_hdmi;
enum drm_connector_status status;
 
if (detect) {
status = detect->funcs->detect(detect);
 
+   if (hdmi) {
+   const struct drm_edid *drm_edid = 
drm_bridge_connector_read_edid(connector,
+   
 status);
+   int ret;
+
+   ret = 
__drm_atomic_helper_connector_hdmi_update_edid(connector, drm_edid);
+   if (ret)
+   drm_warn(connector->dev, "updating EDID failed 
with %d\n", ret);
+   }
+
drm_bridge_connector_hpd_notify(connector, status);
} else {
switch (connector->connector_type) {
@@ -246,29 +283,29 @@ static const struct drm_connector_funcs 
drm_bridge_connector_funcs = {
 static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
   struct drm_bridge *bridge)
 {
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+   struct drm_bridge *hdmi = bridge_connector->bridge_hdmi;
enum drm_connector_status status;
const struct drm_edid *drm_edid;
-   int n;
 
status = drm_bridge_connector_detect(connector, false);
if (status != connector_status_connected)
-   goto no_edid;
+   return 0;
 
-   drm_edid = drm_bridge_edid_read(bridge, connector);
-   if (!drm_edid_valid(drm_edid)) {
+   /* In HDMI setup the EDID has been read and handled as a part of 
.detect() */
+   if (!hdmi) {
+   drm_edid = drm_bridge_connector_read_edid(connector, status);
+   if (!drm_edid) {
+   drm_edid_connector_update(connector, NULL);
+   return 0;
+   }
+
+   drm_edid_connector_update(connector, drm_edid);
drm_edid_free(drm_edid);
-   goto no_edid;
}
 
-   drm_edid_connector_update(connector, drm_edid);
-   n = drm_edid_connector_add_modes(connector);
-
-   drm_edid_free(drm_edid);
-   return n;
-
-no_edid:
-   drm_edid_connector_update(connector, NULL);
-   return 0;
+   return drm_edid_connector_add_modes(connector);
 }
 
 static int drm_bridge_connector_get_modes(struct drm_connector *connector)

-- 
2.39.5

[PATCH RFC v2 6/7] drm/display/hdmi: implement connector update functions

[Dmitry Baryshkov]

The HDMI Connectors need to perform a variety of tasks when the HDMI
connector state changes. Such tasks include setting or invalidating CEC
address, notifying HDMI codec driver, updating scrambler data, etc.

Implementing such tasks in a driver-specific callbacks is error prone.
Start implementing the generic helper function (currently handling only
the HDMI Codec framework) to be used by driver utilizing HDMI Connector
framework.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_hdmi_state_helper.c | 56 +
 include/drm/display/drm_hdmi_state_helper.h |  4 ++
 2 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c 
b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 
feb7a3a759811aed70c679be8704072093e2a79b..dc9d0cc162b2197dcbadda26686a9c5652e74107
 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -748,3 +748,59 @@ 
drm_atomic_helper_connector_hdmi_clear_audio_infoframe(struct drm_connector *con
return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_clear_audio_infoframe);
+
+/**
+ * __drm_atomic_helper_connector_hdmi_update_edid - Update the HDMI Connector 
basing on passed EDID
+ * @connector: A pointer to the HDMI connector
+ * @drm_edid: EDID to process
+ *
+ * This function should be called as a part of the .detect() / .detect_ctx()
+ * and .force() callbacks, updating the HDMI-specific connector's data. The
+ * function consumes passed EDID, there is no need to free it afterwards. Most
+ * of the drivers should be able to use
+ * @drm_atomic_helper_connector_hdmi_update() instead.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int
+__drm_atomic_helper_connector_hdmi_update_edid(struct drm_connector *connector,
+  const struct drm_edid *drm_edid)
+{
+   drm_edid_connector_update(connector, drm_edid);
+   drm_edid_free(drm_edid);
+
+   if (!drm_edid) {
+   drm_connector_hdmi_codec_plugged_notify(connector, false);
+
+   // TODO: also handle CEC and scramber, HDMI sink disconnected.
+
+   return 0;
+   }
+
+   drm_connector_hdmi_codec_plugged_notify(connector, true);
+
+   // TODO: also handle CEC and scramber, HDMI sink is now connected.
+
+   return 0;
+}
+EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_update_edid);
+
+/**
+ * drm_atomic_helper_connector_hdmi_update - Update the HDMI Connector after 
reading the EDID
+ * @connector: A pointer to the HDMI connector
+ *
+ * This function should be called as a part of the .detect() / .detect_ctx()
+ * and .force() callbacks, updating the HDMI-specific connector's data.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int
+drm_atomic_helper_connector_hdmi_update(struct drm_connector *connector)
+{
+   const struct drm_edid *drm_edid = drm_edid_read(connector);
+
+   return __drm_atomic_helper_connector_hdmi_update_edid(connector, 
drm_edid);
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_update);
diff --git a/include/drm/display/drm_hdmi_state_helper.h 
b/include/drm/display/drm_hdmi_state_helper.h
index 
2d45fcfa461985065a5e5ad67eddc0b1c556d526..ea0980aa25cbbfdd36f44201888c139b0ee943da
 100644
--- a/include/drm/display/drm_hdmi_state_helper.h
+++ b/include/drm/display/drm_hdmi_state_helper.h
@@ -20,4 +20,8 @@ int 
drm_atomic_helper_connector_hdmi_clear_audio_infoframe(struct drm_connector
 int drm_atomic_helper_connector_hdmi_update_infoframes(struct drm_connector 
*connector,
   struct drm_atomic_state 
*state);
 
+int __drm_atomic_helper_connector_hdmi_update_edid(struct drm_connector 
*connector,
+  const struct drm_edid 
*drm_edid);
+int drm_atomic_helper_connector_hdmi_update(struct drm_connector *connector);
+
 #endif // DRM_HDMI_STATE_HELPER_H_

-- 
2.39.5

[PATCH RFC v2 3/7] drm/connector: implement generic HDMI codec helpers

[Dmitry Baryshkov]

Several DRM drivers implement HDMI codec support (despite its name it
applies to both HDMI and DisplayPort drivers). Implement generic
framework to be used by these drivers. This removes a requirement to
implement get_eld() callback and provides default implementation for
codec's plug handling.

The framework is integrated with the DRM HDMI Connector framework, but
can be used by DisplayPort drivers.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_connector.c|  10 ++
 drivers/gpu/drm/drm_connector_hdmi_codec.c | 186 +
 drivers/gpu/drm/drm_internal.h |   5 +
 include/drm/drm_connector.h|  80 +
 5 files changed, 282 insertions(+)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 
463afad1b5ca6275e61223adc8ca036c3d4d6b03..ab5b052ad5229229ac46e3804be77dd1d1680f58
 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ drm-y := \
drm_cache.o \
drm_color_mgmt.o \
drm_connector.o \
+   drm_connector_hdmi_codec.o \
drm_crtc.o \
drm_displayid.o \
drm_drv.o \
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 
fc35f47e2849ed6786d6223ac9c69e1c359fc648..1a155a9fb401f687e5a88e72faca1e81d944b6d2
 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -279,6 +279,7 @@ static int __drm_connector_init(struct drm_device *dev,
mutex_init(&connector->mutex);
mutex_init(&connector->edid_override_mutex);
mutex_init(&connector->hdmi.infoframes.lock);
+   mutex_init(&connector->hdmi_codec.lock);
connector->edid_blob_ptr = NULL;
connector->epoch_counter = 0;
connector->tile_blob_ptr = NULL;
@@ -533,6 +534,12 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
 
connector->hdmi.funcs = hdmi_funcs;
 
+   if (connector->hdmi_codec.i2s || connector->hdmi_codec.spdif) {
+   ret = drm_connector_hdmi_codec_init(connector);
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 EXPORT_SYMBOL(drmm_connector_hdmi_init);
@@ -631,6 +638,8 @@ void drm_connector_cleanup(struct drm_connector *connector)
DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
 
+   drm_connector_hdmi_codec_cleanup(connector);
+
if (connector->privacy_screen) {
drm_privacy_screen_put(connector->privacy_screen);
connector->privacy_screen = NULL;
@@ -669,6 +678,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
connector->funcs->atomic_destroy_state(connector,
   connector->state);
 
+   mutex_destroy(&connector->hdmi_codec.lock);
mutex_destroy(&connector->hdmi.infoframes.lock);
mutex_destroy(&connector->mutex);
 
diff --git a/drivers/gpu/drm/drm_connector_hdmi_codec.c 
b/drivers/gpu/drm/drm_connector_hdmi_codec.c
new file mode 100644
index 
..cec727d3fc1493684e954195264b1a5d85a7a2ff
--- /dev/null
+++ b/drivers/gpu/drm/drm_connector_hdmi_codec.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (c) 2024 Linaro Ltd
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include "drm_internal.h"
+
+static int drm_connector_hdmi_codec_audio_startup(struct device *dev, void 
*data)
+{
+   struct drm_connector *connector = data;
+   const struct drm_connector_hdmi_codec_funcs *funcs =
+   connector->hdmi.funcs->codec_funcs;
+
+   if (funcs->audio_startup)
+   return funcs->audio_startup(connector);
+
+   return 0;
+}
+
+static int drm_connector_hdmi_codec_prepare(struct device *dev, void *data,
+   struct hdmi_codec_daifmt *fmt,
+   struct hdmi_codec_params *hparms)
+{
+   struct drm_connector *connector = data;
+   const struct drm_connector_hdmi_codec_funcs *funcs =
+   connector->hdmi.funcs->codec_funcs;
+
+   return funcs->prepare(connector, fmt, hparms);
+}
+
+static void drm_connector_hdmi_codec_audio_shutdown(struct device *dev, void 
*data)
+{
+   struct drm_connector *connector = data;
+   const struct drm_connector_hdmi_codec_funcs *funcs =
+   connector->hdmi.funcs->codec_funcs;
+
+   return funcs->audio_shutdown(connector);
+}
+
+static int drm_connector_hdmi_codec_mute_stream(struct device *dev, void *data,
+   bool enable, int direction)
+{
+   struct drm_connector *connector = data;
+   const struct drm_connector_hdmi_codec_funcs *funcs =
+   connector->hdmi.funcs->codec_funcs;
+
+   if (funcs->mute_stream)
+   return 

Re: [PATCH v2] drm/bridge: Fix assignment of the of_node of the parent to aux bridge

[Dmitry Baryshkov]

On Fri, 1 Nov 2024 at 11:20, Laurent Pinchart
 wrote:
>
> On Fri, Nov 01, 2024 at 11:49:07AM +0800, Sui Jingfeng wrote:
> >
> > On 2024/11/1 00:23, Johan Hovold wrote:
> > > On Thu, Oct 31, 2024 at 11:06:38PM +0800, Sui Jingfeng wrote:
> > >
> > >> But I think Johan do need more times to understand what exactly
> > >> the real problem is. We do need times to investigate new method.
> > > No, I know perfectly well what the (immediate) problem is here (I was
> > > the one adding support for the of_node_reused flag some years back).
> > >
> > > I just wanted to make sure that the commit message was correct and
> > > complete before merging (and also to figure out whether this particular
> > > patch needed to be backported).
> >
> > Well under such a design, having the child device sharing the 'OF' device
> > node with it parent device means that one parent device can *only*
> > create one AUX bridge child device.
> >
> > Since If you create two or more child AUX bridge, *all* of them will
> > call devm_drm_of_get_bridge(&auxdev->dev, auxdev->dev.of_node, 0, 0),
> > then we will *contend* the same next bridge resource.
> >
> > Because of the 'auxdev->dev.of_node' is same for all its instance.
> > While other display bridges seems don't has such limitations.
>
> Brainstorming a bit, I wonder if we could create a swnode for the
> auxiliary device, instead of reusing the parent's OF node.

This will break bridge lookup which is performed by following the OF
graph links. So the aux bridges should use corresponding of_node or
fwnode.

> This would
> require switching the DRM OF-based APIs to fwnode, but that's easy and
> mostly a mechanical change.

-- 
With best wishes
Dmitry

[PATCH RFC v2 0/7] drm: add DRM HDMI Codec framework

[Dmitry Baryshkov]

While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
framework, I stumbled upon an issue while handling the Audio InfoFrames.
The HDMI codec callbacks weren't receiving the drm_atomic_state, so
there was no simple way to get the drm_connector that stayed at the end
of the bridge chain. At the same point the drm_hdmi_connector functions
expected to get drm_connector instance.

While looking for a way to solve the issue, I stumbled upon several
deficiencies in existing hdmi_codec_ops implementations. Only few of the
implementations were able to handle codec's 'plugged' callback. One
third of the drivers didn't implement the get_eld() callback.

Most of the issues can be solved if drm_connector handles
hdmi-audio-codec on its own, delegating functionality to the actual
implementation, be it a driver that implements drm_connector or
drm_bridge.

Implement such high-level framework, adding proper support for Audio
InfoFrame generation to the LT9611 driver.

Several design decisions to be kept in mind:

- drm_connector_hdmi_codec is kept as simple as possible. It implements
  generic functionality (ELD, hotplug, registration).

- drm_hdmi_connector sets up HDMI codec device if the connector
  is setup correspondingly (either I2S or S/PDIF is marked as
  supported).

- drm_bridge_connector provides a way to link HDMI audio codec
  funcionality in the drm_bridge with the drm_connector_hdmi_codec
  framework.

- It might be worth reverting the no_i2s_capture / no_spdif_capture
  bits. Only TDA889x driver sets them, while it's safe to assume that
  most of HDMI / DP devices do not support ARC / capture. I think the
  drivers should opt-in capture support rather than having to opt-out of
  it.

This series is in the RFC stage, so some bits are underdocumented.

Signed-off-by: Dmitry Baryshkov 
---
Changes in v2:
- Use drm_atomic_get_old_connector_for_encoder in atomic_disable() to
  prevent it from crashing
- Reworked HDMI codec init/exit, removing drmm_ calls (Maxime)
- Drafted the helper to be called from .detect_ctx() that performs HDMI
  Connector maintenance duties (Maxime)
- Moved no_capture_mute to struct hdmi_codec_pdata
- Link to v1: 
https://lore.kernel.org/r/20240615-drm-bridge-hdmi-connector-v1-0-d59fc7865...@linaro.org

---
Dmitry Baryshkov (7):
  ASoC: hdmi-codec: pass data to get_dai_id too
  ASoC: hdmi-codec: move no_capture_mute to struct hdmi_codec_pdata
  drm/connector: implement generic HDMI codec helpers
  drm/bridge: connector: add support for HDMI codec framework
  drm/bridge: lt9611: switch to using the DRM HDMI codec framework
  drm/display/hdmi: implement connector update functions
  drm/bridge_connector: hook 
__drm_atomic_helper_connector_hdmi_update_edid()

 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c |   3 +-
 drivers/gpu/drm/bridge/analogix/anx7625.c  |   3 +-
 drivers/gpu/drm/bridge/ite-it66121.c   |   2 +-
 drivers/gpu/drm/bridge/lontium-lt9611.c| 170 ---
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c |   3 +-
 drivers/gpu/drm/bridge/sii902x.c   |   5 +-
 .../gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c|   3 +-
 drivers/gpu/drm/display/drm_bridge_connector.c | 160 --
 drivers/gpu/drm/display/drm_hdmi_state_helper.c|  56 +++
 drivers/gpu/drm/drm_connector.c|  10 ++
 drivers/gpu/drm/drm_connector_hdmi_codec.c | 186 +
 drivers/gpu/drm/drm_internal.h |   5 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c  |   2 +-
 drivers/gpu/drm/mediatek/mtk_dp.c  |   2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c|   2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c |   2 +-
 drivers/gpu/drm/sti/sti_hdmi.c |   2 +-
 include/drm/display/drm_hdmi_state_helper.h|   4 +
 include/drm/drm_bridge.h   |  23 +++
 include/drm/drm_connector.h|  80 +
 include/sound/hdmi-codec.h |   7 +-
 sound/soc/codecs/hdmi-codec.c  |   4 +-
 24 files changed, 601 insertions(+), 136 deletions(-)
---
base-commit: f9f24ca362a4d84dd8aeb4b8f3ec28cb6c43dd06
change-id: 20240530-drm-bridge-hdmi-connector-9b0f6725973e

Best regards,
-- 
Dmitry Baryshkov 

[PULL] drm-xe-fixes

[Lucas De Marchi]

Hi Dave and Simona,

drm-xe-fixes for 6.12-rc6. Two important fixes for LNL and one missing
hpd enabling. This last one brought in a refactor as dependency,
otherwise it would cause some headache with conflicts.

thanks
Lucas De Marchi

drm-xe-fixes-2024-10-31:
Driver Changes:
- Fix missing HPD interrupt enabling, bringing one PM refactor with it
  (Imre / Maarten)
- Workaround LNL GGTT invalidation not being visible to GuC
  (Matthew Brost)
- Avoid getting jobs stuck without a protecting timeout (Matthew Brost)
The following changes since commit 81983758430957d9a5cbfe324fd70cf63e7e:

  Linux 6.12-rc5 (2024-10-27 12:52:02 -1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-10-31

for you to fetch changes up to fe05cee4d9533892210e1ee90147175d87e7c053:

  drm/xe: Don't short circuit TDR on jobs not started (2024-10-31 07:03:14 
-0700)


Driver Changes:
- Fix missing HPD interrupt enabling, bringing one PM refactor with it
  (Imre / Maarten)
- Workaround LNL GGTT invalidation not being visible to GuC
  (Matthew Brost)
- Avoid getting jobs stuck without a protecting timeout (Matthew Brost)


Imre Deak (2):
  drm/xe/display: Separate the d3cold and non-d3cold runtime PM handling
  drm/xe/display: Add missing HPD interrupt enabling during non-d3cold RPM 
resume

Maarten Lankhorst (1):
  drm/xe: Remove runtime argument from display s/r functions

Matthew Brost (2):
  drm/xe: Add mmio read before GGTT invalidate
  drm/xe: Don't short circuit TDR on jobs not started

 drivers/gpu/drm/xe/display/xe_display.c | 71 +
 drivers/gpu/drm/xe/display/xe_display.h |  8 ++--
 drivers/gpu/drm/xe/xe_ggtt.c| 10 +
 drivers/gpu/drm/xe/xe_guc_submit.c  | 18 ++---
 drivers/gpu/drm/xe/xe_pm.c  |  6 +--
 5 files changed, 75 insertions(+), 38 deletions(-)

[PATCH V3 drm-dp 4/4] drm/hisilicon/hibmc: add dp module in hibmc

[Yongbang Shi]

From: baihan li 

To support DP interface displaying in hibmc driver. Add
a encoder and connector for DP modual.

Signed-off-by: baihan li 
Signed-off-by: yongbang shi 
---
ChangeLog:
v2 -> v3:
  - fix build errors reported by kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202410251136.1m7blr68-...@intel.com/
v1 -> v2:
  - deleting struct dp_mode and dp_mode_cfg function, suggested by Dmitry 
Baryshkov.
  - modifying drm_simple_encoder_init function, suggested by Dmitry Baryshkov.
  - refactoring struct hibmc_connector, suggested by Dmitry Baryshkov.
  - withdrawing the modification in hibmc_kms_init, suggested by Dmitry 
Baryshkov.
  v1:https://lore.kernel.org/all/20240930100610.782363-1-shiyongb...@huawei.com/
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile  |   2 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c| 128 ++
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  16 +++
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  21 +--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c   |  41 +++---
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c  |  20 +--
 6 files changed, 188 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 214228052ccf..95a4ed599d98 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_i2c.o 
\
-  dp/dp_aux.o dp/dp_link.o dp/dp_hw.o
+  dp/dp_aux.o dp/dp_link.o dp/dp_hw.o hibmc_drm_dp.o
 
 obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c
new file mode 100644
index ..1e0f2ef39ba6
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_dp.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (c) 2024 Hisilicon Limited.
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hibmc_drm_drv.h"
+#include "dp/dp_hw.h"
+
+static int hibmc_dp_connector_get_modes(struct drm_connector *connector)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, 
connector->dev->mode_config.max_width,
+connector->dev->mode_config.max_height);
+   drm_set_preferred_mode(connector, 1024, 768); // temporary 
implementation
+
+   return count;
+}
+
+static const struct drm_connector_helper_funcs hibmc_dp_conn_helper_funcs = {
+   .get_modes = hibmc_dp_connector_get_modes,
+};
+
+static const struct drm_connector_funcs hibmc_dp_conn_funcs = {
+   .reset = drm_atomic_helper_connector_reset,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int hibmc_dp_prepare(struct hibmc_dp *dp, struct drm_display_mode *mode)
+{
+   int ret;
+
+   hibmc_dp_display_en(dp, false);
+
+   ret = hibmc_dp_mode_set(dp, mode);
+   if (ret)
+   drm_err(dp->drm_dev, "hibmc dp mode set failed: %d\n", ret);
+
+   return ret;
+}
+
+static void hibmc_dp_encoder_enable(struct drm_encoder *drm_encoder,
+   struct drm_atomic_state *state)
+{
+   struct hibmc_dp *dp = container_of(drm_encoder, struct hibmc_dp, 
encoder);
+   struct drm_display_mode *mode = &drm_encoder->crtc->state->mode;
+
+   if (hibmc_dp_prepare(dp, mode))
+   return;
+
+   hibmc_dp_display_en(dp, true);
+}
+
+static void hibmc_dp_encoder_disable(struct drm_encoder *drm_encoder,
+struct drm_atomic_state *state)
+{
+   struct hibmc_dp *dp = container_of(drm_encoder, struct hibmc_dp, 
encoder);
+
+   hibmc_dp_display_en(dp, false);
+}
+
+static const struct drm_encoder_helper_funcs hibmc_dp_encoder_helper_funcs = {
+   .atomic_enable = hibmc_dp_encoder_enable,
+   .atomic_disable = hibmc_dp_encoder_disable,
+};
+
+void hibmc_dp_uninit(struct hibmc_drm_private *priv)
+{
+   hibmc_dp_hw_uninit(&priv->dp);
+}
+
+int hibmc_dp_init(struct hibmc_drm_private *priv)
+{
+   struct drm_device *dev = &priv->dev;
+   struct drm_crtc *crtc = &priv->crtc;
+   struct hibmc_dp *dp = &priv->dp;
+   struct drm_connector *connector = &dp->connector;
+   struct drm_encoder *encoder = &dp->encoder;
+   int ret;
+
+   dp->mmio = priv->mmio;
+   dp->drm_dev = dev;
+
+   ret = hibmc_dp_hw_init(&priv->dp);
+   if (ret) {
+   drm_err(dev, "hibmc dp hw init failed: %d\n", ret);
+   return ret;
+   }
+
+   hibmc_dp_display_en(&priv->dp, fa

[PATCH V3 drm-dp 3/4] drm/hisilicon/hibmc: add dp hw moduel in hibmc

[Yongbang Shi]

From: baihan li 

Build a dp level that hibmc driver can enable dp by
calling their functions.

Signed-off-by: baihan li 
Signed-off-by: yongbang shi 
---
ChangeLog:
v2 -> v3:
  - fix build errors reported by kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202410250931.udq9s66h-...@intel.com/
v1 -> v2:
  - changed some defines and functions to former patch, suggested by Dmitry 
Baryshkov.
  - sorting the headers including in dp_hw.h and hibmc_drm_drv.c files, 
suggested by Dmitry Baryshkov.
  - deleting struct dp_mode and dp_mode_cfg function, suggested by Dmitry 
Baryshkov.
  - fix build errors reported by kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202410040328.vevxm9yb-...@intel.com/
  v1:https://lore.kernel.org/all/20240930100610.782363-1-shiyongb...@huawei.com/
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile|   2 +-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c  | 237 
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h  |  31 +++
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h |  41 
 4 files changed, 310 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.h

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 94d77da88bbf..214228052ccf 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_i2c.o 
\
-  dp/dp_aux.o dp/dp_link.o
+  dp/dp_aux.o dp/dp_link.o dp/dp_hw.o
 
 obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
new file mode 100644
index ..214897798bdb
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_hw.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (c) 2024 Hisilicon Limited.
+
+#include 
+#include 
+#include "dp_config.h"
+#include "dp_comm.h"
+#include "dp_reg.h"
+#include "dp_hw.h"
+#include "dp_link.h"
+#include "dp_aux.h"
+
+static int hibmc_dp_link_init(struct dp_dev *dp)
+{
+   dp->link.cap.lanes = 2;
+   dp->link.train_set = devm_kzalloc(dp->dev->dev,
+ dp->link.cap.lanes * sizeof(u8), 
GFP_KERNEL);
+   if (!dp->link.train_set)
+   return -ENOMEM;
+
+   dp->link.cap.link_rate = 1;
+
+   return 0;
+}
+
+static void hibmc_dp_set_tu(struct dp_dev *dp, struct drm_display_mode *mode)
+{
+   u32 tu_symbol_frac_size;
+   u32 tu_symbol_size;
+   u32 rate_ks;
+   u8 lane_num;
+   u32 value;
+   u32 bpp;
+
+   lane_num = dp->link.cap.lanes;
+   if (lane_num == 0) {
+   drm_err(dp->dev, "set tu failed, lane num cannot be 0!\n");
+   return;
+   }
+
+   bpp = DP_BPP;
+   rate_ks = hibmc_dp_get_link_rate(dp->link.cap.link_rate) * 
DP_LINK_RATE_CAL;
+   value = (mode->clock * bpp * 5) / (61 * lane_num * rate_ks);
+
+   if (value % 10 == 9) { /* 9 carry */
+   tu_symbol_size = value / 10 + 1;
+   tu_symbol_frac_size = 0;
+   } else {
+   tu_symbol_size = value / 10;
+   tu_symbol_frac_size = value % 10 + 1;
+   }
+
+   drm_info(dp->dev, "tu value: %u.%u value: %u\n",
+tu_symbol_size, tu_symbol_frac_size, value);
+
+   dp_reg_write_field(dp->base + DP_VIDEO_PACKET,
+  DP_CFG_STREAM_TU_SYMBOL_SIZE, tu_symbol_size);
+   dp_reg_write_field(dp->base + DP_VIDEO_PACKET,
+  DP_CFG_STREAM_TU_SYMBOL_FRAC_SIZE, 
tu_symbol_frac_size);
+}
+
+static void hibmc_dp_set_sst(struct dp_dev *dp, struct drm_display_mode *mode)
+{
+   u32 hblank_size;
+   u32 htotal_size;
+   u32 htotal_int;
+   u32 hblank_int;
+   u32 fclk; /* flink_clock */
+
+   fclk = hibmc_dp_get_link_rate(dp->link.cap.link_rate) * 
DP_LINK_RATE_CAL;
+
+   /* ssc: 9947 / 1 = 0.9947 */
+   htotal_int = mode->htotal * 9947 / 1;
+   htotal_size = (u32)(htotal_int * fclk / (DP_SYMBOL_PER_FCLK * 
(mode->clock / 1000)));
+
+   /* ssc: max effect bandwidth 53 / 1 = 0.53% */
+   hblank_int = (mode->htotal - mode->hdisplay) - mode->hdisplay * 53 / 
1;
+   hblank_size = hblank_int * fclk * 9947 /
+ (mode->clock * 10 * DP_SYMBOL_PER_FCLK);
+
+   drm_info(dp->dev, "h_active %u v_active %u htotal_size %u hblank_size 
%u",
+mode->hdisplay, mode->vdisplay, htotal_size, hblank_size);
+   drm_info(dp->dev, "flink_clock %u pixel_clock %d", fclk, (mode->clock / 
1000));
+
+   dp_reg_write_field(dp->base + DP_VIDEO_HORIZONTAL_SIZE,
+  DP_CFG_STREAM_HTOTAL_SIZE, htotal_size);
+   dp_reg_write_field(dp->ba

[PATCH V3 drm-dp 2/4] drm/hisilicon/hibmc: add dp link moduel in hibmc

[Yongbang Shi]

From: baihan li 

Add link training process functions in this moduel.

Signed-off-by: baihan li 
Signed-off-by: yongbang shi 
---
Changelog:
v2 -> v3:
  - using switchcase in dp_link_reduce_lane, suggested by Dmitry Baryshkov.
  - deleting dp_link_pattern2dpcd function and using macros directly, suggested 
by Dmitry Baryshkov.
  - deleting EFAULT error codes, suggested by Dmitry Baryshkov.
v1 -> v2:
  - using drm_dp_* functions implement dp link training process, suggested by 
Jani Nikula.
  - fix build errors reported by kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202410031735.8irzzr6t-...@intel.com/
  v1:https://lore.kernel.org/all/20240930100610.782363-1-shiyongb...@huawei.com/
---
 drivers/gpu/drm/hisilicon/hibmc/Makefile |   2 +-
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c | 346 +++
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.h |  25 ++
 drivers/gpu/drm/hisilicon/hibmc/dp/dp_reg.h  |   8 +
 4 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.h

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile 
b/drivers/gpu/drm/hisilicon/hibmc/Makefile
index 8770ec6dfffd..94d77da88bbf 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
+++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_i2c.o 
\
-  dp/dp_aux.o
+  dp/dp_aux.o dp/dp_link.o
 
 obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c 
b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c
new file mode 100644
index ..7146de020c93
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/dp/dp_link.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (c) 2024 Hisilicon Limited.
+
+#include 
+#include 
+#include 
+#include "dp_comm.h"
+#include "dp_reg.h"
+#include "dp_link.h"
+#include "dp_aux.h"
+
+const u8 link_rate_map[] = {DP_LINK_BW_1_62, DP_LINK_BW_2_7,
+   DP_LINK_BW_5_4, DP_LINK_BW_8_1};
+
+static int hibmc_dp_link_training_configure(struct dp_dev *dp)
+{
+   u8 buf[2];
+   int ret;
+
+   /* DP 2 lane */
+   dp_reg_write_field(dp->base + DP_PHYIF_CTRL0, DP_CFG_LANE_DATA_EN,
+  dp->link.cap.lanes == DP_LANE_NUM_2 ? 0x3 : 0x1);
+   dp_reg_write_field(dp->base + DP_DPTX_GCTL0, DP_CFG_PHY_LANE_NUM,
+  dp->link.cap.lanes == DP_LANE_NUM_2 ? 0x1 : 0);
+
+   /* enhanced frame */
+   dp_reg_write_field(dp->base + DP_VIDEO_CTRL, DP_CFG_STREAM_FRAME_MODE, 
0x1);
+
+   /* set rate and lane count */
+   buf[0] = hibmc_dp_get_link_rate(dp->link.cap.link_rate);
+   buf[1] = DP_LANE_COUNT_ENHANCED_FRAME_EN | dp->link.cap.lanes;
+   ret = drm_dp_dpcd_write(&dp->aux, DP_LINK_BW_SET, buf, sizeof(buf));
+   if (ret != sizeof(buf)) {
+   drm_dbg_dp(dp->dev, "dp aux write link rate and lanes failed, 
ret: %d\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   /* set 8b/10b and downspread */
+   buf[0] = 0x10;
+   buf[1] = 0x1;
+   ret = drm_dp_dpcd_write(&dp->aux, DP_DOWNSPREAD_CTRL, buf, sizeof(buf));
+   if (ret != sizeof(buf)) {
+   drm_dbg_dp(dp->dev, "dp aux write 8b/10b and downspread failed, 
ret: %d\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   ret = drm_dp_read_dpcd_caps(&dp->aux, dp->dpcd);
+   if (ret)
+   drm_err(dp->dev, "dp aux read dpcd failed, ret: %d\n", ret);
+
+   return ret;
+}
+
+static int hibmc_dp_link_set_pattern(struct dp_dev *dp, int pattern)
+{
+   int ret;
+   u8 val;
+   u8 buf;
+
+   buf = (u8)pattern;
+   if (pattern != DP_TRAINING_PATTERN_DISABLE && pattern != 
DP_TRAINING_PATTERN_4) {
+   buf |= DP_LINK_SCRAMBLING_DISABLE;
+   dp_reg_write_field(dp->base + DP_PHYIF_CTRL0, 
DP_CFG_SCRAMBLE_EN, 0x1);
+   } else {
+   dp_reg_write_field(dp->base + DP_PHYIF_CTRL0, 
DP_CFG_SCRAMBLE_EN, 0);
+   }
+
+   switch (pattern) {
+   case DP_TRAINING_PATTERN_1:
+   val = 1;
+   break;
+   case DP_TRAINING_PATTERN_2:
+   val = 2;
+   break;
+   case DP_TRAINING_PATTERN_3:
+   val = 3;
+   break;
+   case DP_TRAINING_PATTERN_4:
+   val = 4;
+   break;
+   default:
+   val = 0;
+   }
+
+   dp_reg_write_field(dp->base + DP_PHYIF_CTRL0, DP_CFG_PAT_SEL, val);
+
+   ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_PATTERN_SET, &buf, 
sizeof(buf));
+   if (ret != sizeof(buf)) {
+   drm_dbg_dp(dp->dev, "dp aux write training pattern set 
failed\n");
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   return