date:20250610

On Tue, Jun 10, 2025 at 12:31:40PM +0800, Yongxing Mou wrote:
> 
> 
> On 2025/6/10 0:07, Dmitry Baryshkov wrote:
> > On Mon, Jun 09, 2025 at 08:21:19PM +0800, Yongxing Mou wrote:
> > > Add support for Multi-stream transport for MSM chipsets that allow
> > > a single instance of DP controller to send multiple streams.
> > > 
> > > This series has been validated on sa8775p ride platform using multiple
> > > MST dongles and also daisy chain method on both DP0 and DP1 upto 1080P.
> > > 
> > > With 4x4K monitors, due to lack of layer mixers that combination will not
> > > work but this can be supported as well after some rework on the DPU side.
> > > 
> > > In addition, SST was re-validated with all these changes to ensure there
> > > were no regressions.
> > > 
> > > This patch series was made on top of:
> > > 
> > > [1] : https://patchwork.freedesktop.org/seriedds/142010/ (v2 to fix up 
> > > HPD)
> > > 
> > > Bindings for the pixel clock for additional stream is available at :
> > > 
> > > [2] : https://patchwork.freedesktop.org/series/142016/
> > > 
> > > Overall, the patch series has been organized in the following way:
> > > 
> > > 1) First set are a couple of fixes made while debugging MST but applicable
> > > to SST as well so go ahead of everything else
> > > 2) Prepare the DP driver to get ready to handle multiple streams. This is 
> > > the bulk
> > > of the work as current DP driver design had to be adjusted to make this 
> > > happen.
> > > 3) Finally, new files to handle MST related operations
> > > 
> > > Validation was done on the latest linux-next on top of above changes and
> > > both FB console and weston compositors were validated with these changes.
> > 
> > I went about a halfway through the series. During that I noticed ignored
> > feedback, missing reviewer tags, invalid or strange authorship / SoB
> > tags, overgrown functions, one line wrappers, etc.
> > 
> > Please rebase on top of [3], review the patch series on your own,
> > removing / reworking all the bits that can catch my eye, implement the
> > feedback, ask questions where you don't understand it, etc. After that
> > please post v3. I'll most likely skip the rest of the patches for now.
> > 
> > [3] 
> > https://lore.kernel.org/dri-devel/20250518-fd-dp-audio-fixup-v6-0-2f0ec3ec0...@oss.qualcomm.com
> > 
> Hi, Dmitry, thanks for your reviewing very much. Actually i have reviewed
> all the comments on Patch v1. Sorry for not cleaning up everything as
> expected. I will address and discuss all the remaining items in the comments
> for Patch v2, and will follow up with Patch v3 accordingly.

Please discuss the items where they have been raised - either in v1 or
v2 thread.

>

[PATCH v4 1/6] drm/syncobj: Remove unhelpful helper

Helper which fails to consolidate the code and instead just forks into two
copies of the code based on a boolean parameter is not very helpful or
readable. Lets just remove it and proof in the pudding is the net smaller
code.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Maíra Canal 
---
v2:
 * Assign timeout to a local variable.
---
 drivers/gpu/drm/drm_syncobj.c | 100 --
 1 file changed, 46 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 636cd83ca29e..e2d97dd6e45b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1248,42 +1248,6 @@ signed long drm_timeout_abs_to_jiffies(int64_t 
timeout_nsec)
 }
 EXPORT_SYMBOL(drm_timeout_abs_to_jiffies);
 
-static int drm_syncobj_array_wait(struct drm_device *dev,
- struct drm_file *file_private,
- struct drm_syncobj_wait *wait,
- struct drm_syncobj_timeline_wait 
*timeline_wait,
- struct drm_syncobj **syncobjs, bool timeline,
- ktime_t *deadline)
-{
-   signed long timeout = 0;
-   uint32_t first = ~0;
-
-   if (!timeline) {
-   timeout = drm_timeout_abs_to_jiffies(wait->timeout_nsec);
-   timeout = drm_syncobj_array_wait_timeout(syncobjs,
-NULL,
-wait->count_handles,
-wait->flags,
-timeout, &first,
-deadline);
-   if (timeout < 0)
-   return timeout;
-   wait->first_signaled = first;
-   } else {
-   timeout = 
drm_timeout_abs_to_jiffies(timeline_wait->timeout_nsec);
-   timeout = drm_syncobj_array_wait_timeout(syncobjs,
-
u64_to_user_ptr(timeline_wait->points),
-
timeline_wait->count_handles,
-timeline_wait->flags,
-timeout, &first,
-deadline);
-   if (timeout < 0)
-   return timeout;
-   timeline_wait->first_signaled = first;
-   }
-   return 0;
-}
-
 static int drm_syncobj_array_find(struct drm_file *file_private,
  void __user *user_handles,
  uint32_t count_handles,
@@ -1346,9 +1310,12 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void 
*data,
   struct drm_file *file_private)
 {
struct drm_syncobj_wait *args = data;
+   ktime_t deadline, *pdeadline = NULL;
+   u32 count = args->count_handles;
struct drm_syncobj **syncobjs;
unsigned int possible_flags;
-   ktime_t t, *tp = NULL;
+   u32 first = ~0;
+   long timeout;
int ret = 0;
 
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
@@ -1361,27 +1328,38 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void 
*data,
if (args->flags & ~possible_flags)
return -EINVAL;
 
-   if (args->count_handles == 0)
+   if (count == 0)
return 0;
 
ret = drm_syncobj_array_find(file_private,
 u64_to_user_ptr(args->handles),
-args->count_handles,
+count,
 &syncobjs);
if (ret < 0)
return ret;
 
if (args->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE) {
-   t = ns_to_ktime(args->deadline_nsec);
-   tp = &t;
+   deadline = ns_to_ktime(args->deadline_nsec);
+   pdeadline = &deadline;
}
 
-   ret = drm_syncobj_array_wait(dev, file_private,
-args, NULL, syncobjs, false, tp);
+   timeout = drm_timeout_abs_to_jiffies(args->timeout_nsec);
+   timeout = drm_syncobj_array_wait_timeout(syncobjs,
+NULL,
+count,
+args->flags,
+timeout,
+&first,
+pdeadline);
 
-   drm_syncobj_array_free(syncobjs, args->count_handles);
+   drm_syncobj_array_free(syncobjs, count);
 
-   return ret;
+   if (timeout < 0)
+   return timeout;
+
+   args->first_signaled = first;
+
+   return

Re: [PATCH] rust: module: remove deprecated author key

2025-06-10 Thread Andreas Hindborg

"Guilherme Giacomo Simoes"  writes:

> Commit 38559da6afb2 ("rust: module: introduce `authors` key") introduced
> a new `authors` key to support multiple module authors, while keeping
> the old `author` key for backward compatibility.
>
> Now that all in-tree modules have migrated to `authors`, remove:
> 1. The deprecated `author` key support from the module macro
> 2. Legacy `author` entries from remaining modules
>
> Signed-off-by: Guilherme Giacomo Simoes 


Acked-by: Andreas Hindborg 


Best regards,
Andreas Hindborg

[PATCH v4 2/6] drm/syncobj: Do not allocate an array to store zeros when waiting

When waiting on syncobjs the current code allocates a temporary array only
to fill it up with all zeros.

We can avoid that by relying on the allocated entry array already being
zero allocated.

For the timeline mode we can fetch the timeline point values as we
populate the entries array so also do not need this additional temporary
allocation.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Maíra Canal  # v1
---
v2:
 * Change back to copy_from_user due 32-bit ARM not implementing 64-bit
   get_user.
---
 drivers/gpu/drm/drm_syncobj.c | 38 ---
 1 file changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e2d97dd6e45b..67efdd22f9bc 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1055,7 +1055,7 @@ static void syncobj_wait_syncobj_func(struct drm_syncobj 
*syncobj,
 }
 
 static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj 
**syncobjs,
- void __user *user_points,
+ u64 __user *user_points,
  uint32_t count,
  uint32_t flags,
  signed long timeout,
@@ -1063,9 +1063,8 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
  ktime_t *deadline)
 {
struct syncobj_wait_entry *entries;
-   struct dma_fence *fence;
-   uint64_t *points;
uint32_t signaled_count, i;
+   struct dma_fence *fence;
 
if (flags & (DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
 DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE)) {
@@ -1073,24 +1072,10 @@ static signed long 
drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
lockdep_assert_none_held_once();
}
 
-   points = kmalloc_array(count, sizeof(*points), GFP_KERNEL);
-   if (points == NULL)
-   return -ENOMEM;
-
-   if (!user_points) {
-   memset(points, 0, count * sizeof(uint64_t));
-
-   } else if (copy_from_user(points, user_points,
- sizeof(uint64_t) * count)) {
-   timeout = -EFAULT;
-   goto err_free_points;
-   }
-
entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
-   if (!entries) {
-   timeout = -ENOMEM;
-   goto err_free_points;
-   }
+   if (!entries)
+   return -ENOMEM;
+
/* Walk the list of sync objects and initialize entries.  We do
 * this up-front so that we can properly return -EINVAL if there is
 * a syncobj with a missing fence and then never have the chance of
@@ -1101,9 +1086,15 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
struct dma_fence *fence;
 
entries[i].task = current;
-   entries[i].point = points[i];
+   if (user_points &&
+   copy_from_user(user_points++, &entries[i].point,
+  sizeof(*user_points))) {
+   timeout = -EFAULT;
+   goto cleanup_entries;
+   }
fence = drm_syncobj_fence_get(syncobjs[i]);
-   if (!fence || dma_fence_chain_find_seqno(&fence, points[i])) {
+   if (!fence ||
+   dma_fence_chain_find_seqno(&fence, entries[i].point)) {
dma_fence_put(fence);
if (flags & (DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT |
 DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE)) {
@@ -1209,9 +1200,6 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
}
kfree(entries);
 
-err_free_points:
-   kfree(points);
-
return timeout;
 }
 
-- 
2.48.0

[PATCH v4 0/6] A few drm_syncobj optimisations

A small set of drm_syncobj optimisations which should make things a tiny bit
more efficient on the CPU side of things.

Improvement seems to be around 1.5%* more FPS if observed with "vkgears
-present-mailbox" on a Steam Deck Plasma desktop, but I am reluctant to make a
definitive claim on the numbers since there is some run to run variance. But, as
suggested by Michel Dänzer, I did do a five ~100 second runs on the each kernel
to be able to show the ministat analysis.

x before
+ after
++
|  x +   |
|   x  x +   |
|   x  xx    |
| x x  xx x  |
| x xx   x xx x+     |
|x   xx+    + +  |
|xxx xx+x   +++  |
|  x xxx*xx+* x   ++ |
|x x   **x*+*+*  +   |
|   xx x   xx*x+***+**+ ++   |
|x xxx x   x*xx***+*++**+++   +  +  +|
|   |___A__| |
| |__A___|   |
++
N   Min   MaxMedian   AvgStddev
x 135  21697.58 22809.467 22321.396 22307.707 198.75011
+ 118 22200.746  23277.09   22661.4 22671.442 192.10609
Difference at 95.0% confidence
363.735 +/- 48.3345
1.63054% +/- 0.216672%
(Student's t, pooled s = 195.681)

Or when tested on Intel Alderlake, KDE Wayland:

x base
+ syncobj
+--+
|   +  |
|   +   +  |
|   +   +  |
|   +  ++  |
|   ++ ++  |
|   x   ++ ++  |
|   x   x + ++ ++  |
|   x  xx   xx x x+++  |
|   x   x   xx xxx *xxx  + |
|x   xx x  xx  xx xx*xxxxxx  +x+ ++|
|  |__A_M___| |A_M___| |
+--+
N   Min   MaxMedian   AvgStddev
x  55  7158.232  8058.753  7803.506 7754.5195 191.69526
+  55   7801.23  8272.271  8172.435 8150.6303 105.84085
Difference at 95.0% confidence
396.111 +/- 57.8717
5.10813% +/- 0.746296%
(Student's t, pooled s = 154.838)

Scores may seem low but I had to fix to conservative CPU freq to avoid some
pretty strong thermal throttling causing wild swings within a run. Nevertheless
the improvement is clearly shown here as well.

v2:
 * Implemented review feedback - see patch change logs.

v3:
 * Moved #define DRM_SYNCOBJ_FAST_PATH_ENTRIES one patch earlier for less churn.

 v3.1:
 * Consolidated testing results.

v4:
 * Kernel test robot reports 32-bit ARM does not implement 64-bit get/put_user.
   Switch to copy_to/from_user in relevant places.

Cc: Maíra Canal 

Tvrtko Ursulin (6):
  drm/syncobj: Remove unhelpful helper
  drm/syncobj: Do not allocate an array to store zeros when waiting
  drm/syncobj: Avoid one temporary allocation in drm_syncobj_array_find
  drm/syncobj: Avoid temporary allocation in
drm_syncobj_timeline_signal_ioctl
  drm/syncobj: Add a fast path to drm_syncobj_array_wait_timeout
  drm/syncobj: Add a fast path to drm_syncobj_array_find

 drivers/gpu/drm/drm_syncobj.c | 277 ++
 1 file changed, 147 insertions(+), 130 deletions(-)

-- 
2.48.0

[PATCH v4 5/6] drm/syncobj: Add a fast path to drm_syncobj_array_wait_timeout

Running the Cyberpunk 2077 benchmark we can observe that waiting on DRM
sycobjs is relatively hot, but the 96% of the calls are for a single
object. (~4% for two points, and never more than three points. While
a more trivial workload like vkmark under Plasma is even more skewed
to single point waits.)

Therefore lets add a fast path to bypass the kcalloc/kfree and use a pre-
allocated stack array for those cases.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Maíra Canal 
---
v2:
 * Document rationale for stack array in a comment.

v3:
 * Added DRM_SYNCOBJ_FAST_PATH_ENTRIES to avoid hardcoding fast path array
   size.
---
 drivers/gpu/drm/drm_syncobj.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 53bd9b6de518..8ca5331d7b67 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -236,6 +236,14 @@ static void
 syncobj_eventfd_entry_func(struct drm_syncobj *syncobj,
   struct syncobj_eventfd_entry *entry);
 
+/*
+ * Empirically vast majority of ioctls pass in a single syncobj (96%) and never
+ * more than three points. Therefore implement a fast path with a small stack
+ * array to avoid going into the allocator sometimes several times per
+ * userspace rendered frame.
+ */
+#define DRM_SYNCOBJ_FAST_PATH_ENTRIES 4
+
 /**
  * drm_syncobj_find - lookup and reference a sync object.
  * @file_private: drm file private pointer
@@ -1062,6 +1070,7 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
  uint32_t *idx,
  ktime_t *deadline)
 {
+   struct syncobj_wait_entry stack_entries[DRM_SYNCOBJ_FAST_PATH_ENTRIES];
struct syncobj_wait_entry *entries;
uint32_t signaled_count, i;
struct dma_fence *fence;
@@ -1076,6 +1085,15 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
if (!entries)
return -ENOMEM;
 
+   if (count > ARRAY_SIZE(stack_entries)) {
+   entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
+   if (!entries)
+   return -ENOMEM;
+   } else {
+   memset(stack_entries, 0, sizeof(stack_entries));
+   entries = stack_entries;
+   }
+
/* Walk the list of sync objects and initialize entries.  We do
 * this up-front so that we can properly return -EINVAL if there is
 * a syncobj with a missing fence and then never have the chance of
@@ -1198,7 +1216,9 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
  &entries[i].fence_cb);
dma_fence_put(entries[i].fence);
}
-   kfree(entries);
+
+   if (entries != stack_entries)
+   kfree(entries);
 
return timeout;
 }
-- 
2.48.0

[PATCH v4 3/6] drm/syncobj: Avoid one temporary allocation in drm_syncobj_array_find

Drm_syncobj_array_find() helper is used from many userspace ioctl entry
points with the task of looking up userspace handles to internal objects.

We can easily avoid one temporary allocation by making it read the handles
as it is looking them up.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Maíra Canal 
---
v2:
 * Fix handle type.
 * Undo pointless unwind change.
---
 drivers/gpu/drm/drm_syncobj.c | 36 +++
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 67efdd22f9bc..3aa5edaebdf9 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1237,39 +1237,35 @@ signed long drm_timeout_abs_to_jiffies(int64_t 
timeout_nsec)
 EXPORT_SYMBOL(drm_timeout_abs_to_jiffies);
 
 static int drm_syncobj_array_find(struct drm_file *file_private,
- void __user *user_handles,
- uint32_t count_handles,
+ u32 __user *handles,
+ uint32_t count,
  struct drm_syncobj ***syncobjs_out)
 {
-   uint32_t i, *handles;
struct drm_syncobj **syncobjs;
+   uint32_t i;
int ret;
 
-   handles = kmalloc_array(count_handles, sizeof(*handles), GFP_KERNEL);
-   if (handles == NULL)
+   if (!access_ok(handles, count * sizeof(*handles)))
+   return -EFAULT;
+
+   syncobjs = kmalloc_array(count, sizeof(*syncobjs), GFP_KERNEL);
+   if (!syncobjs)
return -ENOMEM;
 
-   if (copy_from_user(handles, user_handles,
-  sizeof(uint32_t) * count_handles)) {
-   ret = -EFAULT;
-   goto err_free_handles;
-   }
+   for (i = 0; i < count; i++) {
+   u32 handle;
 
-   syncobjs = kmalloc_array(count_handles, sizeof(*syncobjs), GFP_KERNEL);
-   if (syncobjs == NULL) {
-   ret = -ENOMEM;
-   goto err_free_handles;
-   }
-
-   for (i = 0; i < count_handles; i++) {
-   syncobjs[i] = drm_syncobj_find(file_private, handles[i]);
+   if (__get_user(handle, handles++)) {
+   ret = -EFAULT;
+   goto err_put_syncobjs;
+   }
+   syncobjs[i] = drm_syncobj_find(file_private, handle);
if (!syncobjs[i]) {
ret = -ENOENT;
goto err_put_syncobjs;
}
}
 
-   kfree(handles);
*syncobjs_out = syncobjs;
return 0;
 
@@ -1277,8 +1273,6 @@ static int drm_syncobj_array_find(struct drm_file 
*file_private,
while (i-- > 0)
drm_syncobj_put(syncobjs[i]);
kfree(syncobjs);
-err_free_handles:
-   kfree(handles);
 
return ret;
 }
-- 
2.48.0

[PATCH v4 6/6] drm/syncobj: Add a fast path to drm_syncobj_array_find

Running the Cyberpunk 2077 benchmark we can observe that the lookup helper
is relatively hot, but the 97% of the calls are for a single object. (~3%
for two points, and never more than three points. While a more trivial
workload like vkmark under Plasma is even more skewed to single point
lookups.)

Therefore lets add a fast path to bypass the kmalloc_array/kfree and use a
pre-allocated stack array for those cases.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Maíra Canal 
---
v2:
 * Added comments describing how the fast path arrays were sized.
 * Make container freeing criteria clearer by using a boolean.
---
 drivers/gpu/drm/drm_syncobj.c | 56 +++
 1 file changed, 44 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 8ca5331d7b67..d8b8ca40266d 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1259,6 +1259,8 @@ EXPORT_SYMBOL(drm_timeout_abs_to_jiffies);
 static int drm_syncobj_array_find(struct drm_file *file_private,
  u32 __user *handles,
  uint32_t count,
+ struct drm_syncobj **stack_syncobjs,
+ u32 stack_count,
  struct drm_syncobj ***syncobjs_out)
 {
struct drm_syncobj **syncobjs;
@@ -1268,9 +1270,13 @@ static int drm_syncobj_array_find(struct drm_file 
*file_private,
if (!access_ok(handles, count * sizeof(*handles)))
return -EFAULT;
 
-   syncobjs = kmalloc_array(count, sizeof(*syncobjs), GFP_KERNEL);
-   if (!syncobjs)
-   return -ENOMEM;
+   if (count > stack_count) {
+   syncobjs = kmalloc_array(count, sizeof(*syncobjs), GFP_KERNEL);
+   if (!syncobjs)
+   return -ENOMEM;
+   } else {
+   syncobjs = stack_syncobjs;
+   }
 
for (i = 0; i < count; i++) {
u32 handle;
@@ -1292,25 +1298,31 @@ static int drm_syncobj_array_find(struct drm_file 
*file_private,
 err_put_syncobjs:
while (i-- > 0)
drm_syncobj_put(syncobjs[i]);
-   kfree(syncobjs);
+
+   if (syncobjs != stack_syncobjs)
+   kfree(syncobjs);
 
return ret;
 }
 
 static void drm_syncobj_array_free(struct drm_syncobj **syncobjs,
-  uint32_t count)
+  uint32_t count,
+  bool free_container)
 {
uint32_t i;
 
for (i = 0; i < count; i++)
drm_syncobj_put(syncobjs[i]);
-   kfree(syncobjs);
+
+   if (free_container)
+   kfree(syncobjs);
 }
 
 int
 drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private)
 {
+   struct drm_syncobj *stack_syncobjs[DRM_SYNCOBJ_FAST_PATH_ENTRIES];
struct drm_syncobj_wait *args = data;
ktime_t deadline, *pdeadline = NULL;
u32 count = args->count_handles;
@@ -1336,6 +1348,8 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
ret = drm_syncobj_array_find(file_private,
 u64_to_user_ptr(args->handles),
 count,
+stack_syncobjs,
+ARRAY_SIZE(stack_syncobjs),
 &syncobjs);
if (ret < 0)
return ret;
@@ -1354,7 +1368,7 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
 &first,
 pdeadline);
 
-   drm_syncobj_array_free(syncobjs, count);
+   drm_syncobj_array_free(syncobjs, count, syncobjs != stack_syncobjs);
 
if (timeout < 0)
return timeout;
@@ -1368,6 +1382,7 @@ int
 drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private)
 {
+   struct drm_syncobj *stack_syncobjs[DRM_SYNCOBJ_FAST_PATH_ENTRIES];
struct drm_syncobj_timeline_wait *args = data;
ktime_t deadline, *pdeadline = NULL;
u32 count = args->count_handles;
@@ -1394,6 +1409,8 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, 
void *data,
ret = drm_syncobj_array_find(file_private,
 u64_to_user_ptr(args->handles),
 count,
+stack_syncobjs,
+ARRAY_SIZE(stack_syncobjs),
 &syncobjs);
if (ret < 0)
return ret;
@@ -1412,7 +1429,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, 
void *data,
 &first,
 pdeadline);
 
-

RE: [PATCH 4/4] drm/i915/panel: sync panel prepared state at register

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Friday, June 6, 2025 2:35 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; Heikki
> Krogerus ; Wysocki, Rafael J
> ; Lee, Shawn C ; Yang,
> Simon1 ; Doug Anderson ;
> Maxime Ripard ; Nikula, Jani 
> Subject: [PATCH 4/4] drm/i915/panel: sync panel prepared state at register
> 
> If the panel is enabled at probe, and we take over the hardware state, the
> drm_panel prepared state will be out of sync. We'll need to notify drm_panel
> framework about the state at probe, so it can in turn notify the panel 
> followers.
> 
> Cc: Lee Shawn C 
> Signed-off-by: Jani Nikula 
> ---
Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy
---

>  drivers/gpu/drm/i915/display/intel_panel.c | 41 ++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index b1d549e6cf53..f956919dc648 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -463,6 +463,45 @@ void intel_panel_fini(struct intel_connector
> *connector)
>   }
>  }
> 
> +/*
> + * If the panel was already enabled at probe, and we took over the
> +state, the
> + * panel prepared state is out of sync, and the panel followers won't
> +be
> + * notified. We need to call drm_panel_prepare() on enabled panels.
> + *
> + * It would be natural to handle this e.g. in the connector
> +->sync_state hook at
> + * intel_modeset_readout_hw_state(), but that's unfortunately too
> +early. We
> + * don't have drm_connector::kdev at that time. For now, figure out the
> +state at
> + * ->late_register, and sync there.
> + */
> +static void intel_panel_sync_state(struct intel_connector *connector) {
> + struct intel_display *display = to_intel_display(connector);
> + struct drm_connector_state *conn_state;
> + struct intel_crtc *crtc;
> + int ret;
> +
> + ret = drm_modeset_lock(&display->drm-
> >mode_config.connection_mutex, NULL);
> + if (ret)
> + return;
> +
> + conn_state = connector->base.state;
> +
> + crtc = to_intel_crtc(conn_state->crtc);
> + if (crtc) {
> + struct intel_crtc_state *crtc_state;
> +
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> +
> + if (crtc_state->hw.active) {
> + drm_dbg_kms(display->drm, "[CONNECTOR:%d:%s]
> Panel prepare\n",
> + connector->base.base.id, connector-
> >base.name);
> + intel_panel_prepare(crtc_state, conn_state);
> + }
> + }
> +
> + drm_modeset_unlock(&display->drm-
> >mode_config.connection_mutex);
> +}
> +
>  const struct drm_panel_funcs dummy_panel_funcs = {  };
> 
> @@ -513,6 +552,8 @@ int intel_panel_register(struct intel_connector
> *connector)
>   drm_dbg_kms(display->drm, "[CONNECTOR:%d:%s] Registered
> panel device '%s', has fwnode: %s\n",
>   connector->base.base.id, connector->base.name,
>   dev_name(dev), str_yes_no(dev_fwnode(dev)));
> +
> + intel_panel_sync_state(connector);
>   }
> 
>  out:
> --
> 2.39.5

[PATCH v4 4/6] drm/syncobj: Avoid temporary allocation in drm_syncobj_timeline_signal_ioctl

We can avoid one of the two temporary allocations if we read the userspace
supplied timeline points as we go along.

The only new complication is to unwind unused fence chains on the error
path, but even that code was already present in the function.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Maíra Canal  #v1
---
v2:
 * Change back to copy_from_user due 32-bit ARM not implementing 64-bit
   get_user.
---
 drivers/gpu/drm/drm_syncobj.c | 43 ++-
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3aa5edaebdf9..53bd9b6de518 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1579,10 +1579,10 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device 
*dev, void *data,
  struct drm_file *file_private)
 {
struct drm_syncobj_timeline_array *args = data;
+   uint64_t __user *points = u64_to_user_ptr(args->points);
+   uint32_t i, j, count = args->count_handles;
struct drm_syncobj **syncobjs;
struct dma_fence_chain **chains;
-   uint64_t *points;
-   uint32_t i, j;
int ret;
 
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
@@ -1596,31 +1596,17 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device 
*dev, void *data,
 
ret = drm_syncobj_array_find(file_private,
 u64_to_user_ptr(args->handles),
-args->count_handles,
+count,
 &syncobjs);
if (ret < 0)
return ret;
 
-   points = kmalloc_array(args->count_handles, sizeof(*points),
-  GFP_KERNEL);
-   if (!points) {
-   ret = -ENOMEM;
-   goto out;
-   }
-   if (!u64_to_user_ptr(args->points)) {
-   memset(points, 0, args->count_handles * sizeof(uint64_t));
-   } else if (copy_from_user(points, u64_to_user_ptr(args->points),
- sizeof(uint64_t) * args->count_handles)) {
-   ret = -EFAULT;
-   goto err_points;
-   }
-
-   chains = kmalloc_array(args->count_handles, sizeof(void *), GFP_KERNEL);
+   chains = kmalloc_array(count, sizeof(void *), GFP_KERNEL);
if (!chains) {
ret = -ENOMEM;
-   goto err_points;
+   goto out;
}
-   for (i = 0; i < args->count_handles; i++) {
+   for (i = 0; i < count; i++) {
chains[i] = dma_fence_chain_alloc();
if (!chains[i]) {
for (j = 0; j < i; j++)
@@ -1630,19 +1616,24 @@ drm_syncobj_timeline_signal_ioctl(struct drm_device 
*dev, void *data,
}
}
 
-   for (i = 0; i < args->count_handles; i++) {
+   for (i = 0; i < count; i++) {
struct dma_fence *fence = dma_fence_get_stub();
+   u64 point = 0;
 
-   drm_syncobj_add_point(syncobjs[i], chains[i],
- fence, points[i]);
+   if (points && copy_from_user(points++, &point, sizeof(point))) {
+   ret =  -EFAULT;
+   for (j = i; j < count; j++)
+   dma_fence_chain_free(chains[j]);
+   goto err_chains;
+   }
+
+   drm_syncobj_add_point(syncobjs[i], chains[i], fence, point);
dma_fence_put(fence);
}
 err_chains:
kfree(chains);
-err_points:
-   kfree(points);
 out:
-   drm_syncobj_array_free(syncobjs, args->count_handles);
+   drm_syncobj_array_free(syncobjs, count);
 
return ret;
 }
-- 
2.48.0

Re: [PATCH 3/3] drm/panel: ilitek-ili9881c: Add configuration for 7" Raspberry Pi 720x1280

2025-06-10 Thread Neil Armstrong


On 08/06/2025 16:28, Marek Vasut wrote:

Add configuration for the 7" Raspberry Pi 720x1280 DSI panel
based on ili9881.

Signed-off-by: Marek Vasut 
---
Based on https://github.com/raspberrypi/linux 0d7ac78a3dd9 ("Extending ili9881c 
driver support for nwe080 panel")
by Dave Stevenson  and others
---
Cc: Conor Dooley 
Cc: Dave Stevenson 
Cc: David Airlie 
Cc: Jessica Zhang 
Cc: Krzysztof Kozlowski 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Rob Herring 
Cc: Simona Vetter 
Cc: Thomas Zimmermann 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
---
  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 219 ++
  1 file changed, 219 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 2f5ae69148cc..06c5ef9a4946 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -1224,6 +1224,199 @@ static const struct ili9881c_instr am8001280g_init[] = {
ILI9881C_COMMAND_INSTR(MIPI_DCS_WRITE_POWER_SAVE, 0x00),
  };
  
+static const struct ili9881c_instr rpi_7inch_init[] = {

+   ILI9881C_SWITCH_PAGE_INSTR(3),
+   ILI9881C_COMMAND_INSTR(0x01, 0x00),
+   ILI9881C_COMMAND_INSTR(0x02, 0x00),
+   ILI9881C_COMMAND_INSTR(0x03, 0x73),
+   ILI9881C_COMMAND_INSTR(0x04, 0x00),
+   ILI9881C_COMMAND_INSTR(0x05, 0x00),
+   ILI9881C_COMMAND_INSTR(0x06, 0x0a),
+   ILI9881C_COMMAND_INSTR(0x07, 0x00),
+   ILI9881C_COMMAND_INSTR(0x08, 0x00),
+   ILI9881C_COMMAND_INSTR(0x09, 0x61),
+   ILI9881C_COMMAND_INSTR(0x0a, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0c, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0f, 0x61),
+   ILI9881C_COMMAND_INSTR(0x10, 0x61),
+   ILI9881C_COMMAND_INSTR(0x11, 0x00),
+   ILI9881C_COMMAND_INSTR(0x12, 0x00),
+   ILI9881C_COMMAND_INSTR(0x13, 0x00),
+   ILI9881C_COMMAND_INSTR(0x14, 0x00),
+   ILI9881C_COMMAND_INSTR(0x15, 0x00),
+   ILI9881C_COMMAND_INSTR(0x16, 0x00),
+   ILI9881C_COMMAND_INSTR(0x17, 0x00),
+   ILI9881C_COMMAND_INSTR(0x18, 0x00),
+   ILI9881C_COMMAND_INSTR(0x19, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1a, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1c, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1e, 0x40),
+   ILI9881C_COMMAND_INSTR(0x1f, 0x80),
+   ILI9881C_COMMAND_INSTR(0x20, 0x06),
+   ILI9881C_COMMAND_INSTR(0x21, 0x01),
+   ILI9881C_COMMAND_INSTR(0x22, 0x00),
+   ILI9881C_COMMAND_INSTR(0x23, 0x00),
+   ILI9881C_COMMAND_INSTR(0x24, 0x00),
+   ILI9881C_COMMAND_INSTR(0x25, 0x00),
+   ILI9881C_COMMAND_INSTR(0x26, 0x00),
+   ILI9881C_COMMAND_INSTR(0x27, 0x00),
+   ILI9881C_COMMAND_INSTR(0x28, 0x33),
+   ILI9881C_COMMAND_INSTR(0x29, 0x03),
+   ILI9881C_COMMAND_INSTR(0x2a, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2c, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2f, 0x00),
+   ILI9881C_COMMAND_INSTR(0x30, 0x00),
+   ILI9881C_COMMAND_INSTR(0x31, 0x00),
+   ILI9881C_COMMAND_INSTR(0x32, 0x00),
+   ILI9881C_COMMAND_INSTR(0x33, 0x00),
+   ILI9881C_COMMAND_INSTR(0x34, 0x04),
+   ILI9881C_COMMAND_INSTR(0x35, 0x00),
+   ILI9881C_COMMAND_INSTR(0x36, 0x00),
+   ILI9881C_COMMAND_INSTR(0x37, 0x00),
+   ILI9881C_COMMAND_INSTR(0x38, 0x3c),
+   ILI9881C_COMMAND_INSTR(0x39, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3a, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3c, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3f, 0x00),
+   ILI9881C_COMMAND_INSTR(0x40, 0x00),
+   ILI9881C_COMMAND_INSTR(0x41, 0x00),
+   ILI9881C_COMMAND_INSTR(0x42, 0x00),
+   ILI9881C_COMMAND_INSTR(0x43, 0x00),
+   ILI9881C_COMMAND_INSTR(0x44, 0x00),
+   ILI9881C_COMMAND_INSTR(0x50, 0x10),
+   ILI9881C_COMMAND_INSTR(0x51, 0x32),
+   ILI9881C_COMMAND_INSTR(0x52, 0x54),
+   ILI9881C_COMMAND_INSTR(0x53, 0x76),
+   ILI9881C_COMMAND_INSTR(0x54, 0x98),
+   ILI9881C_COMMAND_INSTR(0x55, 0xba),
+   ILI9881C_COMMAND_INSTR(0x56, 0x10),
+   ILI9881C_COMMAND_INSTR(0x57, 0x32),
+   ILI9881C_COMMAND_INSTR(0x58, 0x54),
+   ILI9881C_COMMAND_INSTR(0x59, 0x76),
+   ILI9881C_COMMAND_INSTR(0x5a, 0x98),
+   ILI9881C_COMMAND_INSTR(0x5b, 0xba),
+   ILI9881C_COMMAND_INSTR(0x5c, 0xdc),
+   ILI9881C_COMMAND_INSTR(0x5d, 0xfe),
+   ILI9881C_COMMAND_INSTR(0x5e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x5f, 0x0e),
+   ILI9881C_COMMAND_INSTR(0x60, 0x0f),
+   ILI98

RE: [PATCH 2/4] drm/i915/panel: add panel register/unregister

On Tue, 10 Jun 2025, "Murthy, Arun R"  wrote:
>> -Original Message-
>> From: Intel-gfx  On Behalf Of Jani
>> Nikula
>> Sent: Friday, June 6, 2025 2:35 PM
>> To: dri-devel@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; Heikki
>> Krogerus ; Wysocki, Rafael J
>> ; Lee, Shawn C ; Yang,
>> Simon1 ; Doug Anderson ;
>> Maxime Ripard ; Nikula, Jani 
>> Subject: [PATCH 2/4] drm/i915/panel: add panel register/unregister
>> 
>> Add panel register/unregister functions, and handle backlight
>> register/unregister from there. This is in preparation for adding more panel
>> specific register/unregister functionality.
>> 
>> Cc: Lee Shawn C 
>> Signed-off-by: Jani Nikula 
>> ---
>>  .../gpu/drm/i915/display/intel_connector.c| 23 +--
>>  drivers/gpu/drm/i915/display/intel_panel.c| 10 
>>  drivers/gpu/drm/i915/display/intel_panel.h|  2 ++
>>  3 files changed, 23 insertions(+), 12 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
>> b/drivers/gpu/drm/i915/display/intel_connector.c
>> index 9a61c972dce9..2867d76d1a5e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
>> @@ -32,7 +32,6 @@
>> 
>>  #include "i915_drv.h"
>>  #include "i915_utils.h"
>> -#include "intel_backlight.h"
>>  #include "intel_connector.h"
>>  #include "intel_display_core.h"
>>  #include "intel_display_debugfs.h"
>> @@ -153,36 +152,36 @@ void intel_connector_destroy(struct drm_connector
>> *connector)
>>  kfree(connector);
>>  }
>> 
>> -int intel_connector_register(struct drm_connector *connector)
>> +int intel_connector_register(struct drm_connector *_connector)
>>  {
>> -struct intel_connector *intel_connector =
>> to_intel_connector(connector);
>> -struct drm_i915_private *i915 = to_i915(connector->dev);
>> +struct intel_connector *connector = to_intel_connector(_connector);
>> +struct drm_i915_private *i915 = to_i915(_connector->dev);
> Can intel_display be used over here?

i915 is passed to i915_inject_probe_failure() below, so no.

BR,
Jani.

>
> Apart from the above one, patch looks good to me.
> Reviewed-by: Arun R Murthy 
>
> Thanks and Regards,
> Arun R Murthy
> 
>
>>  int ret;
>> 
>> -ret = intel_backlight_device_register(intel_connector);
>> +ret = intel_panel_register(connector);
>>  if (ret)
>>  goto err;
>> 
>>  if (i915_inject_probe_failure(i915)) {
>>  ret = -EFAULT;
>> -goto err_backlight;
>> +goto err_panel;
>>  }
>> 
>> -intel_connector_debugfs_add(intel_connector);
>> +intel_connector_debugfs_add(connector);
>> 
>>  return 0;
>> 
>> -err_backlight:
>> -intel_backlight_device_unregister(intel_connector);
>> +err_panel:
>> +intel_panel_unregister(connector);
>>  err:
>>  return ret;
>>  }
>> 
>> -void intel_connector_unregister(struct drm_connector *connector)
>> +void intel_connector_unregister(struct drm_connector *_connector)
>>  {
>> -struct intel_connector *intel_connector =
>> to_intel_connector(connector);
>> +struct intel_connector *connector = to_intel_connector(_connector);
>> 
>> -intel_backlight_device_unregister(intel_connector);
>> +intel_panel_unregister(connector);
>>  }
>> 
>>  void intel_connector_attach_encoder(struct intel_connector *connector, diff 
>> --
>> git a/drivers/gpu/drm/i915/display/intel_panel.c
>> b/drivers/gpu/drm/i915/display/intel_panel.c
>> index f5c972880391..5ae302bee191 100644
>> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>> @@ -462,3 +462,13 @@ void intel_panel_fini(struct intel_connector
>> *connector)
>>  drm_mode_destroy(connector->base.dev, fixed_mode);
>>  }
>>  }
>> +
>> +int intel_panel_register(struct intel_connector *connector) {
>> +return intel_backlight_device_register(connector);
>> +}
>> +
>> +void intel_panel_unregister(struct intel_connector *connector) {
>> +intel_backlight_device_unregister(connector);
>> +}
>> diff --git a/drivers/gpu/drm/i915/display/intel_panel.h
>> b/drivers/gpu/drm/i915/display/intel_panel.h
>> index b60d12322e5d..3d592a4404f3 100644
>> --- a/drivers/gpu/drm/i915/display/intel_panel.h
>> +++ b/drivers/gpu/drm/i915/display/intel_panel.h
>> @@ -23,6 +23,8 @@ void intel_panel_init_alloc(struct intel_connector
>> *connector);  int intel_panel_init(struct intel_connector *connector,
>>   const struct drm_edid *fixed_edid);  void
>> intel_panel_fini(struct intel_connector *connector);
>> +int intel_panel_register(struct intel_connector *connector); void
>> +intel_panel_unregister(struct intel_connector *connector);
>>  enum drm_connector_status
>>  intel_panel_detect(struct drm_connector *connector, bool force);  bool
>> intel_panel_use_ssc(struct intel_display *display);
>> --
>> 2.39.5
>

-- 
Jani Nikula, Intel

[PATCH v2] drm/arm/hdlcd: Replace struct simplefb_format with custom type

2025-06-10 Thread Thomas Zimmermann

Map DRM FourCC codes to pixel descriptions with an internal struct
type. Avoid simplefb's struct simplefb_format, which is for parsing
"simple-framebuffer" DT nodes. Drop the unsupported formats with
alpha channel from the list.

The HDLCD drivers uses struct simplefb_format and its default
initializer SIMPLEFB_FORMATS to map DRM_FORMAT_ constants to pixel
descriptions. The simplefb helpers are for parsing "simple-framebuffer"
DT nodes and should be avoided in other context. Therefore replace it
in hdlcd with a custom struct type and pixel descriptions from
PIXEL_FORMAT_ constants.

This change also removes including ,
which includes several unrelated headers, such as .

v2:
- drop unsupported alpha formats (Liviu)
- keep original sorting of formats (Javier)
- use anonymous type for supported_formats

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 3cfefadc7c9d..806da0aaedf7 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -11,8 +11,8 @@
 
 #include 
 #include 
-#include 
 
+#include 
 #include 
 
 #include 
@@ -73,7 +73,17 @@ static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
.disable_vblank = hdlcd_crtc_disable_vblank,
 };
 
-static struct simplefb_format supported_formats[] = SIMPLEFB_FORMATS;
+static const struct {
+   u32 fourcc;
+   struct pixel_format pixel;
+} supported_formats[] = {
+   { DRM_FORMAT_RGB565, PIXEL_FORMAT_RGB565 },
+   { DRM_FORMAT_XRGB1555, PIXEL_FORMAT_XRGB1555 },
+   { DRM_FORMAT_RGB888, PIXEL_FORMAT_RGB888 },
+   { DRM_FORMAT_XRGB, PIXEL_FORMAT_XRGB },
+   { DRM_FORMAT_XBGR, PIXEL_FORMAT_XBGR },
+   { DRM_FORMAT_XRGB2101010, PIXEL_FORMAT_XRGB2101010},
+};
 
 /*
  * Setup the HDLCD registers for decoding the pixels out of the framebuffer
@@ -83,15 +93,12 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
unsigned int btpp;
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
const struct drm_framebuffer *fb = crtc->primary->state->fb;
-   uint32_t pixel_format;
-   struct simplefb_format *format = NULL;
+   const struct pixel_format *format = NULL;
int i;
 
-   pixel_format = fb->format->format;
-
for (i = 0; i < ARRAY_SIZE(supported_formats); i++) {
-   if (supported_formats[i].fourcc == pixel_format)
-   format = &supported_formats[i];
+   if (supported_formats[i].fourcc == fb->format->format)
+   format = &supported_formats[i].pixel;
}
 
if (WARN_ON(!format))
-- 
2.49.0

Re: [PATCH] rust: module: remove deprecated author key

2025-06-10 Thread Benno Lossin

On Mon Jun 9, 2025 at 2:22 PM CEST, Guilherme Giacomo Simoes wrote:
> diff --git a/drivers/gpu/nova-core/nova_core.rs 
> b/drivers/gpu/nova-core/nova_core.rs
> index 618632f0abcc..f405d7a99c28 100644
> --- a/drivers/gpu/nova-core/nova_core.rs
> +++ b/drivers/gpu/nova-core/nova_core.rs
> @@ -13,7 +13,7 @@
>  kernel::module_pci_driver! {
>  type: driver::NovaCore,
>  name: "NovaCore",
> -author: "Danilo Krummrich",
> +authors: ["Danilo Krummrich"],

Unrelated to this change, I think we should add email addresses to
people in authors. Possibly enforce it by scanning each author element
and checking if there is an email address.

>  description: "Nova Core GPU driver",
>  license: "GPL v2",
>  firmware: [],
> diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs
> index 2494c96e105f..ed2fc20cba9b 100644
> --- a/rust/kernel/firmware.rs
> +++ b/rust/kernel/firmware.rs
> @@ -181,7 +181,7 @@ unsafe impl Sync for Firmware {}
>  /// module! {
>  ///type: MyModule,
>  ///name: "module_firmware_test",
> -///author: "Rust for Linux",
> +///authors: ["Rust for Linux"],

We would need to special case "Rust for Linux Developers" or something
similar. But in several cases -- such as this one, we should just name
the actual authors.

What do you guys think?

---
Cheers,
Benno

Re: [PATCH 0/3] NVIDIA Tegra210 NVJPG support

2025-06-10 Thread Thierry Reding

On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
> Hello,
> 
> This series adds support for the NVJPG hardware accelerator found in the
> Tegra210 SoC.
> 
> The kernel driver is essentially a copy of the NVDEC driver as both
> engines are Falcon-based.
> 
> For the userspace part I have written a Mesa Gallium backend [1] that,
> while still very much experimental, works in decoding images with VA-API.

Nice. It's good to see that there's some use in this after all. I
haven't taken an in-depth look yet, but from a high-level point of view
this looks like what I had imagined back when I started out with this
driver.

This made my day, thank you!

Thierry

signature.asc
Description: PGP signature

Re: [PATCH] rust: module: remove deprecated author key

2025-06-10 Thread Benno Lossin

On Mon Jun 9, 2025 at 2:22 PM CEST, Guilherme Giacomo Simoes wrote:
> Commit 38559da6afb2 ("rust: module: introduce `authors` key") introduced
> a new `authors` key to support multiple module authors, while keeping
> the old `author` key for backward compatibility.
>
> Now that all in-tree modules have migrated to `authors`, remove:
> 1. The deprecated `author` key support from the module macro
> 2. Legacy `author` entries from remaining modules
>
> Signed-off-by: Guilherme Giacomo Simoes 
> ---
>  drivers/cpufreq/rcpufreq_dt.rs| 2 +-
>  drivers/gpu/drm/nova/nova.rs  | 2 +-
>  drivers/gpu/nova-core/nova_core.rs| 2 +-
>  rust/kernel/firmware.rs   | 2 +-
>  rust/macros/module.rs | 6 --
>  samples/rust/rust_configfs.rs | 2 +-
>  samples/rust/rust_driver_auxiliary.rs | 2 +-
>  7 files changed, 6 insertions(+), 12 deletions(-)

Reviewed-by: Benno Lossin 

---
Cheers,
Benno

Re: [PATCH 0/3] NVIDIA Tegra210 NVJPG support

2025-06-10 Thread Thierry Reding

On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
> Hello,
> 
> This series adds support for the NVJPG hardware accelerator found in the
> Tegra210 SoC.
> 
> The kernel driver is essentially a copy of the NVDEC driver as both
> engines are Falcon-based.
> 
> For the userspace part I have written a Mesa Gallium backend [1] that,
> while still very much experimental, works in decoding images with VA-API.
> 
> I have been using ffmpeg to call VA-API with the following command:
> 
> ffmpeg -v verbose -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 -i 
>  -pix_fmt bgra -f fbdev /dev/fb0
> 
> which decodes  and shows the result in the framebuffer.
> 
> The firmware for the engine can be obtained from a Linux for Tegra
> distribution.

By the way, have you tried running this on anything newer than Tegra210?
Given your progress on this, we can probably start thinking about
submitting the binaries to linux-firmware.

> Due to the way the Gallium implementation works for Tegra
> the GPU also needs to be enabled.

I wonder if maybe we can get rid of this requirement. While it's
certainly nice to have the GPU enabled, there may be cases where using
only the other engines may be advantageous. Originally when I had worked
on VIC, I was looking at how it could be used for compositing without
getting the GPU involved. That's something that Android devices tend(ed)
to do because of the power savings that come with it.

Anyway, not a big deal, depending on the GPU for now is fine.

Thierry

signature.asc
Description: PGP signature

Re: [PATCH v3] drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type

2025-06-10 Thread Jayesh Choudhary


Hello Doug,

On 10/06/25 03:39, Doug Anderson wrote:

Hi,

On Mon, Jun 2, 2025 at 4:05 AM Jayesh Choudhary  wrote:


Hello Geert, Krzysztof,

(continuing discussion from both patches on this thread...)

On 30/05/25 13:25, Geert Uytterhoeven wrote:

Hi Jayesh,

CC devicetree

On Fri, 30 May 2025 at 04:54, Jayesh Choudhary  wrote:

On 29/05/25 16:34, Jayesh Choudhary wrote:

By default, HPD was disabled on SN65DSI86 bridge. When the driver was
added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
call which was moved to other function calls subsequently.
Later on, commit "c312b0df3b13" added detect utility for DP mode. But with
HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced
state always return 1 (always connected state).

Set HPD_DISABLE bit conditionally based on "no-hpd" property.
Since the HPD_STATE is reflected correctly only after waiting for debounce
time (~100-400ms) and adding this delay in detect() is not feasible
owing to the performace impact (glitches and frame drop), remove runtime
calls in detect() and add hpd_enable()/disable() bridge hooks with runtime
calls, to detect hpd properly without any delay.

[0]:  (Pg. 32)

Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge connector 
operations for DP")
Cc: Max Krummenacher 
Signed-off-by: Jayesh Choudhary 
---

Changelog v2->v3:
- Change conditional based on no-hpd property to address [1]
- Remove runtime calls in detect() with appropriate comments
- Add hpd_enable() and hpd_disable() in drm_bridge_funcs
- Not picking up "Tested-by" tag as there are new changes

v2 patch link:


[1]: 



Thanks for your patch!


This would also require dts changes in all the nodes of sn65dsi86
to ensure that they have no-hpd property.


DTS patch is posted now:



On all Renesas platforms handled by that patch, the DP bridge's HPD pin
is wired to the HPD pin on the mini-DP connector.  What am I missing?


If the bridge's HPD is connected to that of the connector, then I am
pretty certain HPD will not work for renesas platform. The detect hook
always gives "connected" state in the driver (even if it is unplugged).
Do you have different observation on your end?
If not, then we do need something like this patch while addressing the
backwards-compatibility concerns.

During v1 RFC[2], I did observe that renesas also have DisplayPort
connector type and might require hpd, but since the support was
already there and no issue was raised, I assumed it does not require
HPD.

[2]:
https://lore.kernel.org/all/01b43a16-cffa-457f-a2e1-87dd27869...@ti.com/




Regardless, breaking backwards-compatibility with existing DTBs is
definitely a no-go.


FWIW, we are in a little bit of a sticky situation here. We were in a
bit of a bad place from the start because the Linux driver ignored HPD
from the beginning but we didn't actually document that people should
be setting the "no-hpd" property until a little bit later. You can see
some discussion about this in commit 1dbc979172af ("dt-bindings:
drm/bridge: ti-sn65dsi86: Document no-hpd") where I noted "this is
somewhat of a backward-incompatible change." ...but, at the time, it
wasn't really a big deal because there were very few users (the one in
tree at the time was cheza, which was a dev board used internally at
Google).

...so, as of that change in May of 2020, it was documented that eDP
users were _supposed_ to be setting NO_HPD. I even remember Bjorn
requesting the "or is otherwise unusable" phrasing because we pretty
much wanted to set this property on everyone using sn65dsi86 as eDP
(even if they have HPD hooked up) because the debouncing time is so
long that it was better to hardcode the max delay instead of reading
the HPD line. Of course, even though we documented that they were
supposed to have the "no-hpd" property didn't necessarily mean that
everyone did. The code has never enforced it. I don't believe it even
checks the property...

So if there are dts files out there that don't set the property and
they were submitted after the bindings change in 2020, _technically_
they've been wrong the whole time. We're not changing history by
adding a new requirement so much as fixing broken DTS files. Although
the Linux driver always allowed them to get away with being broken,
technically DTS is separate from Linux so if they've been violating
the bindings then they've been wrong. :-P That being said, they've
been working and it would be nice to keep them working if we can, but
one could make an argument that maybe it would be OK to require them
to change...



Got it.
Let me try to figure out a way to fix it without messing it up.


While a bit on the ugly side, it seems like perhaps you could ju

Re: [PATCH v2 0/1] MAINTAINERS: .mailmap: Update Hans de Goede's email address

2025-06-10 Thread Ilpo Järvinen

On Mon, 09 Jun 2025 16:35:56 +0200, Hans de Goede wrote:

> I'm moving all my kernel work over to using my kernel.org email address.
> 
> The single patch in this series updates .mailmap and all MAINTAINERS
> entries still using hdego...@redhat.com.
> 
> Since most of my work is pdx86 related I believe it would be best for Ilpo
> to merge this through the pdx86 tree (preferable through the fixes branch).
> 
> [...]


Thank you for your contribution, it has been applied to my local
review-ilpo-fixes branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-fixes branch only once I've pushed my
local branch there, which might take a while.

The list of commits applied:
[1/1] MAINTAINERS: .mailmap: Update Hans de Goede's email address
  commit: 3fbf25ecf8b7b524b4774b427657d30a24e696ef

--
 i.

Re: [PATCH] drm/bridge: ti-sn65dsi86: fix REFCLK setting

2025-06-10 Thread Michael Walle


Hi Jayesh,


+   /*
+* After EN is deasserted and an external clock is detected, 
the bridge
+* will sample GPIO3:1 to determine its frequency. The driver 
will
+* overwrite this setting. But this is racy. Thus we have to 
wait a
+* couple of us. According to the datasheet the GPIO lines 
has to be
+* stable at least 5 us (td5) but it seems that is not enough 
and the
+* refclk frequency value is lost/overwritten by the bridge 
itself.

+* Waiting for 20us seems to work.
+*/
+   usleep_range(20, 30);


It might be worth pointing at _where_ the driver overwrites this
setting, or maybe at least pointing to something that makes it easy to
find which exact bits you're talking about.


Yeah, Jayesh just pointed that out below. I'll add add it to the 
comment.



This looks reasonable to me, though.


I think we are talking about SN_DPPLL_SRC_REG[3:1] bits?


Yes.


What exact mismatch are you observing in register value?


The one set by the chip itself vs the one from the driver, see below.


I am assuming that you have a clock at REFCLK pin. For that:


Yes, I'm using an external clock.


If refclk is described in devicetree node, then I see that
the driver modifies it in every resume call based solely on the
clock value in dts.


Exactly. But that is racy with what the chip itself is doing. I.e.
if you don't have that usleep() above, the chip will win the race
and the refclk frequency setting will be set according to the
external GPIOs (which is poorly described in the datasheet, btw),
regardless what the linux driver is setting (because that I2C write
happens too early).

If refclk is not described in dts, then this register is modified by 
the

driver only when pre_enable() calls enable_comms(). Here also, the
value depends on crtc_mode and the refclk_rate often would not be equal
to the values in "ti_sn_bridge_dsiclk_lut" (supported frequencies), and
you would fallback to "001" register value.



Rest of time, I guess it depends on reading the status from GPIO and
changing the register.


Not "rest of the time", the reading of the strapping option from the
GPIO always happens if an external refclk is detected. It's part of
the chip after all. It will just sometimes be overwritten by the
linux driver.


Is the latter one your usecase?


My use case is that the GPIO setting is wrong on my board (it's really
non-existent) and I'm relying on the linux driver to set the correct
frequency.

HTH,
-michael

Re: [PATCH 2/3] drm/panel: ilitek-ili9881c: Allow configuration of the number of lanes

2025-06-10 Thread Neil Armstrong


On 08/06/2025 16:28, Marek Vasut wrote:

Not all panels use all 4 data lanes, so allow configuration based
on the compatible string.

Signed-off-by: Marek Vasut 
---
Based on https://github.com/raspberrypi/linux 0d7ac78a3dd9 ("Extending ili9881c 
driver support for nwe080 panel")
by Dave Stevenson  and others
---
Cc: Conor Dooley 
Cc: Dave Stevenson 
Cc: David Airlie 
Cc: Jessica Zhang 
Cc: Krzysztof Kozlowski 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Rob Herring 
Cc: Simona Vetter 
Cc: Thomas Zimmermann 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
---
  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 28cd7560e5db..2f5ae69148cc 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -43,6 +43,7 @@ struct ili9881c_desc {
const struct drm_display_mode *mode;
const unsigned long mode_flags;
u8 default_address_mode;
+   unsigned int lanes;
  };
  
  struct ili9881c {

@@ -1549,7 +1550,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
  
  	dsi->mode_flags = ctx->desc->mode_flags;

dsi->format = MIPI_DSI_FMT_RGB888;
-   dsi->lanes = 4;
+   dsi->lanes = ctx->desc->lanes;
  
  	return mipi_dsi_attach(dsi);

  }
@@ -1567,6 +1568,7 @@ static const struct ili9881c_desc lhr050h41_desc = {
.init_length = ARRAY_SIZE(lhr050h41_init),
.mode = &lhr050h41_default_mode,
.mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+   .lanes = 4,
  };
  
  static const struct ili9881c_desc k101_im2byl02_desc = {

@@ -1574,6 +1576,7 @@ static const struct ili9881c_desc k101_im2byl02_desc = {
.init_length = ARRAY_SIZE(k101_im2byl02_init),
.mode = &k101_im2byl02_default_mode,
.mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+   .lanes = 4,
  };
  
  static const struct ili9881c_desc kd050hdfia020_desc = {

@@ -1599,6 +1602,7 @@ static const struct ili9881c_desc w552946aba_desc = {
.mode = &w552946aba_default_mode,
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+   .lanes = 4,
  };
  
  static const struct ili9881c_desc am8001280g_desc = {


Reviewed-by: Neil Armstrong

RE: [PATCH 1/4] drm/panel: use fwnode based lookups for panel followers

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Friday, June 6, 2025 2:35 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; Heikki
> Krogerus ; Wysocki, Rafael J
> ; Lee, Shawn C ; Yang,
> Simon1 ; Doug Anderson ;
> Maxime Ripard ; Nikula, Jani ;
> Neil Armstrong ; Jessica Zhang
> 
> Subject: [PATCH 1/4] drm/panel: use fwnode based lookups for panel followers
> 
> Use firmware node based lookups for panel followers, to make the code
> independent of OF and device tree, and make it work also for ACPI with an
> appropriate _DSD.
> 
> ASL example:
> 
>   Package (0x02)
>   {
>   "panel", \_SB.PCI0.GFX0.LCD0
>   }
> 
> Suggested-by: Heikki Krogerus 
> Cc: Neil Armstrong 
> Cc: Jessica Zhang 
> Cc: Maxime Ripard 
> Cc: Doug Anderson 
> Cc: Lee Shawn C 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_panel.c | 39 +
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index
> fee65dc65979..3eb0a615f7a9 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -473,17 +473,40 @@ int of_drm_get_panel_orientation(const struct
> device_node *np,  EXPORT_SYMBOL(of_drm_get_panel_orientation);
>  #endif
> 
> -static struct drm_panel *of_find_panel(struct device *follower_dev)
> +/* Find panel by fwnode */
> +static struct drm_panel *find_panel_by_fwnode(const struct
> +fwnode_handle *fwnode)
>  {
> - struct device_node *panel_np;
>   struct drm_panel *panel;
> 
> - panel_np = of_parse_phandle(follower_dev->of_node, "panel", 0);
> - if (!panel_np)
> + if (!fwnode_device_is_available(fwnode))
>   return ERR_PTR(-ENODEV);
> 
> - panel = of_drm_find_panel(panel_np);
> - of_node_put(panel_np);
> + mutex_lock(&panel_lock);
> +
> + list_for_each_entry(panel, &panel_list, list) {
> + if (dev_fwnode(panel->dev) == fwnode) {
> + mutex_unlock(&panel_lock);
> + return panel;
> + }
> + }
> +
> + mutex_unlock(&panel_lock);
> +
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +/* Find panel by follower device */
> +static struct drm_panel *find_panel_by_dev(struct device *follower_dev)
> +{
> + struct fwnode_handle *fwnode;
> + struct drm_panel *panel;
> +
> + fwnode = fwnode_find_reference(dev_fwnode(follower_dev), "panel",
> 0);
> + if (IS_ERR_OR_NULL(fwnode))
> + return ERR_PTR(-ENODEV);
> +
> + panel = find_panel_by_fwnode(fwnode);
> + fwnode_handle_put(fwnode);
> 
>   return panel;
>  }
> @@ -506,7 +529,7 @@ bool drm_is_panel_follower(struct device *dev)

Does the kdoc for this function need updates?
The doc says its supported on only device tree supported systems.

Apart from the above mentioned update,  from ACPI perspective looks good to me.

Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy


>* don't bother trying to parse it here. We just need to know if the
>* property is there.
>*/
> - return of_property_present(dev->of_node, "panel");
> + return device_property_present(dev, "panel");
>  }
>  EXPORT_SYMBOL(drm_is_panel_follower);
> 
> @@ -536,7 +559,7 @@ int drm_panel_add_follower(struct device
> *follower_dev,
>   struct drm_panel *panel;
>   int ret;
> 
> - panel = of_find_panel(follower_dev);
> + panel = find_panel_by_dev(follower_dev);
>   if (IS_ERR(panel))
>   return PTR_ERR(panel);
> 
> --
> 2.39.5

RE: [PATCH 3/4] drm/i915/panel: register drm_panel and call prepare/unprepare for ICL+ DSI

On Tue, 10 Jun 2025, "Murthy, Arun R"  wrote:
>> -Original Message-
>> From: Intel-gfx  On Behalf Of Jani
>> Nikula
>> Sent: Friday, June 6, 2025 2:35 PM
>> To: dri-devel@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; Heikki
>> Krogerus ; Wysocki, Rafael J
>> ; Lee, Shawn C ; Yang,
>> Simon1 ; Doug Anderson ;
>> Maxime Ripard ; Nikula, Jani 
>> Subject: [PATCH 3/4] drm/i915/panel: register drm_panel and call
>> prepare/unprepare for ICL+ DSI
>> 
>> Allocate and register a drm_panel so that drm_panel_followers can find the
>> panel. Pass the drm_connector::kdev device to drm_panel allocation for
>> matching. That's only available after drm_sysfs_connector_add(), so we need 
>> to
>> postpone the drm_panel allocation until .late_register() hook.
>> 
>> The drm_panel framework is moving towards devm_drm_panel_alloc(). It
>> requires a wrapper struct, and struct intel_panel would be the natural
>> candidate. However, we can't postpone its allocation until .late_register(), 
>> so we
>> have to use __devm_drm_panel_alloc() directly for now.
>> 
>> Call the drm_panel_prepare() and drm_panel_unprepare() functions for
>> ICL+ DSI, so that followers get notified of the panel power state
>> changes. This can later be expanded to VLV+ DSI and eDP.
>> 
>> Cc: Maxime Ripard 
>> Cc: Heikki Krogerus 
>> Cc: Lee Shawn C 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/display/icl_dsi.c|  4 +
>>  .../drm/i915/display/intel_display_types.h|  4 +
>>  drivers/gpu/drm/i915/display/intel_panel.c| 82 ++-
>>  drivers/gpu/drm/i915/display/intel_panel.h|  4 +
>>  4 files changed, 93 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
>> b/drivers/gpu/drm/i915/display/icl_dsi.c
>> index 026361354e6f..81410b3aed51 100644
>> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
>> @@ -1276,6 +1276,8 @@ static void gen11_dsi_enable(struct
>> intel_atomic_state *state,
>>  intel_backlight_enable(crtc_state, conn_state);
>>  intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>> 
>> +intel_panel_prepare(crtc_state, conn_state);
>> +
> Should this be done before the intel_backlight_enable() ?

I'm just playing it safe and ensuring the panel is fully powered
including backlight before letting followers know we're powered.

>
>>  intel_crtc_vblank_on(crtc_state);
>>  }
>> 
>> @@ -1409,6 +1411,8 @@ static void gen11_dsi_disable(struct
>> intel_atomic_state *state,  {
>>  struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>> 
>> +intel_panel_unprepare(old_conn_state);
>> +
>>  /* step1: turn off backlight */
>>  intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>>  intel_backlight_disable(old_conn_state);
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
>> b/drivers/gpu/drm/i915/display/intel_display_types.h
>> index ed4d743fc7c5..30c7315fc25e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
>> @@ -37,6 +37,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include  @@ -384,6 +385,9 @@ struct
>> intel_vbt_panel_data {  };
>> 
>>  struct intel_panel {
>> +/* Simple drm_panel */
>> +struct drm_panel *base;
>> +
>>  /* Fixed EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
>>  const struct drm_edid *fixed_edid;
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
>> b/drivers/gpu/drm/i915/display/intel_panel.c
>> index 5ae302bee191..b1d549e6cf53 100644
>> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>> @@ -463,12 +463,92 @@ void intel_panel_fini(struct intel_connector
>> *connector)
>>  }
>>  }
>> 
>> +const struct drm_panel_funcs dummy_panel_funcs = { };
>> +
>>  int intel_panel_register(struct intel_connector *connector)  {
>> -return intel_backlight_device_register(connector);
>> +struct intel_display *display = to_intel_display(connector);
>> +struct intel_panel *panel = &connector->panel;
>> +int ret;
>> +
>> +ret = intel_backlight_device_register(connector);
>> +if (ret)
>> +return ret;
>> +
> Do we need to assign the backlight_device created in 
> intel_backlight_device_register() to the element backlight in struct 
> drm_panel, so as to use the drm_panel framework for panel backlight control?

For now, we only use drm_panel framework for prepare/unprepare
notifications to followers. Plugging in enable/disable with backlight
doesn't seem trivial, and needs careful thought and refactoring. So
better not mix the two for the time being.

BR,
Jani.

>
> Thanks and Regards,
> Arun R Murthy
> ---
>
>> +if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI)
>> {
>> +struct device *dev = connector

Re: [PATCH v2 00/38] drm/msm/dp: Add MST support for MSM chipsets

On Tue, Jun 10, 2025 at 12:47:00PM +0800, Yongxing Mou wrote:
> 
> 
> On 2025/6/9 20:36, Dmitry Baryshkov wrote:
> > On Mon, Jun 09, 2025 at 08:21:19PM +0800, Yongxing Mou wrote:
> > > Add support for Multi-stream transport for MSM chipsets that allow
> > > a single instance of DP controller to send multiple streams.
> > > 
> > > This series has been validated on sa8775p ride platform using multiple
> > > MST dongles and also daisy chain method on both DP0 and DP1 upto 1080P.
> > 
> > Which means that you didn't validate the MST interaction with the USB-C
> > stack (there is a significant difference in the way HPD event is handled
> > in the Linux kernel).
> > 
> Yes. this patch series not test with USB-DP. Actually, our initial plan was
> 2x2 MST on SA8775P and 4 MST on ACS8300. All of them are native DP
> interface, not USB-DP. So can we only support SA8775P/QCS8300 in this
> series. We don't plan to support other platform in this patch series.

I'm sorry, it doesn't work this way. This is not a product kernel,
limited to a selected set of platforms. So, you have to hook MST support
in both paths. The series is not going to be merged tomorrow, so you
have enough time to validate MST on the platforms providing DP over
USB-C.

> > > With 4x4K monitors, due to lack of layer mixers that combination will not
> > > work but this can be supported as well after some rework on the DPU side.
> > > 
> > > In addition, SST was re-validated with all these changes to ensure there
> > > were no regressions.
> > > 
> > > This patch series was made on top of:
> > > 
> > > [1] : https://patchwork.freedesktop.org/seriedds/142010/ (v2 to fix up 
> > > HPD)
> > 
> > This series has serious concerns and most likely will not be merged. Not
> > to mention that the URL is invalid.
> > 
> Got it. Sorry for the typo in the URL. So should we drop this patch series
> or wait the state machine rework from Jessica zhang ?

Please work with Jessica. As I wrote, I do not intend to land the
mentioned series.

> > > 
> > > Bindings for the pixel clock for additional stream is available at :
> > > 
> > > [2] : https://patchwork.freedesktop.org/series/142016/
> > 
> > This series needs another revision.
> > 
> Got it.
> > Not to mention that I plan to land [3] this cycle
> > 
> > [3] 
> > http://lore.kernel.org/dri-devel/20250518-fd-dp-audio-fixup-v6-0-2f0ec3ec0...@oss.qualcomm.com
> > 
> > 
> Got it. will rebase on this patch series.
> > > Overall, the patch series has been organized in the following way:
> > > 
> > > 1) First set are a couple of fixes made while debugging MST but applicable
> > > to SST as well so go ahead of everything else
> > > 2) Prepare the DP driver to get ready to handle multiple streams. This is 
> > > the bulk
> > > of the work as current DP driver design had to be adjusted to make this 
> > > happen.
> > > 3) Finally, new files to handle MST related operations
> > > 
> > > Validation was done on the latest linux-next on top of above changes and
> > > both FB console and weston compositors were validated with these changes.
> > 
> > Validation should be using IGT for testing. Please ensure that there are
> > no regressions.
> > 
> > > 
> > > To: Rob Clark 
> > > To: Dmitry Baryshkov 
> > > To: Abhinav Kumar 
> > > To: Jessica Zhang 
> > > To: Sean Paul 
> > > To: Marijn Suijten 
> > > To: David Airlie 
> > > To: Simona Vetter 
> > > Cc: linux-arm-...@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: freedr...@lists.freedesktop.org
> > > Cc: linux-ker...@vger.kernel.org
> > > 
> > > Signed-off-by: Yongxing Mou 
> > > ---
> > > Changes in v2: Fixed review comments from Dmitry
> > > - Rebase on top of next-20250606
> > > - Add all 4 streams pixel clks support and MST2/MST3 Link clk support
> > > - Address the formatting issues mentioned in the review comments
> > > - Drop the cache of msm_dp_panel->drm_edid cached
> > > - Remove the one-line wrapper funtion and redundant conditional check
> > > - Fixed the commit messgae descriptions of some patches
> > > - Reordered the patches and renamed some functions and variables
> > > - Link to v1: https://lore.kernel.org/all/20241205-dp_mst-v1-0-f
> > > 8618d42a...@quicinc.com/
> > > 
> > > ---
> > > Abhinav Kumar (35):
> > >drm/msm/dp: split msm_dp_panel_read_sink_caps() into two parts and 
> > > drop panel drm_edid
> > >drm/msm/dp: remove dp_display's dp_mode and use dp_panel's instead
> > >drm/msm/dp: break up dp_display_enable into two parts
> > >drm/msm/dp: re-arrange dp_display_disable() into functional parts
> > >drm/msm/dp: allow dp_ctrl stream APIs to use any panel passed to it
> > >drm/msm/dp: move the pixel clock control to its own API
> > >drm/msm/dp: split dp_ctrl_off() into stream and link parts
> > >drm/msm/dp: make bridge helpers use dp_display to allow re-use
> > >drm/msm/dp: separate dp_display_prepare() into its own API
> > >drm/msm/dp: introduce the max_strea

Re: [RFC PATCH 00/12] Private MMIO support for private assigned dev

2025-06-10 Thread Xu Yilun

On Tue, Jun 10, 2025 at 02:20:03PM +1000, Alexey Kardashevskiy wrote:
> 
> 
> On 31/5/25 02:23, Xu Yilun wrote:
> > On Fri, May 30, 2025 at 12:29:30PM +1000, Alexey Kardashevskiy wrote:
> > > 
> > > 
> > > On 30/5/25 00:41, Xu Yilun wrote:
> > > > > > > > 
> > > > > > > > FLR to a bound device is absolutely fine, just break the CC 
> > > > > > > > state.
> > > > > > > > Sometimes it is exactly what host need to stop CC immediately.
> > > > > > > > The problem is in VFIO's pre-FLR handling so we need to patch 
> > > > > > > > VFIO, not
> > > > > > > > PCI core.
> > > > > > > 
> > > > > > > What is a problem here exactly?
> > > > > > > FLR by the host which equals to any other PCI error? The guest 
> > > > > > > may or may not be able to handle it, afaik it does not handle any 
> > > > > > > errors now, QEMU just stops the guest.
> > > > > > 
> > > > > > It is about TDX Connect.
> > > > > > 
> > > > > > According to the dmabuf patchset, the dmabuf needs to be revoked 
> > > > > > before
> > > > > > FLR. That means KVM unmaps MMIOs when the device is in LOCKED/RUN 
> > > > > > state.
> > > > > > That is forbidden by TDX Module and will crash KVM.
> > > > > 
> > > > > 
> > > > > FLR is something you tell the device to do, how/why would TDX know 
> > > > > about it?
> > > > 
> > > > I'm talking about FLR in VFIO driver. The VFIO driver would zap bar
> > > > before FLR. The zapping would trigger KVM unmap MMIOs. See
> > > > vfio_pci_zap_bars() for legacy case, and see [1] for dmabuf case.
> > > 
> > > oh I did not know that we do this zapping, thanks for the pointer.
> > > > [1] 
> > > > https://lore.kernel.org/kvm/20250307052248.405803-4-vivek.kasire...@intel.com/
> > > > 
> > > > A pure FLR without zapping bar is absolutely OK.
> > > > 
> > > > > Or it check the TDI state on every map/unmap (unlikely)?
> > > > 
> > > > Yeah, TDX Module would check TDI state on every unmapping.
> > > 
> > > _every_? Reading the state from DOE mailbox is not cheap enough (imho) to 
> > > do on every unmap.
> > 
> > Sorry for confusing. TDX firmware just checks if STOP TDI firmware call
> > is executed, will not check the real device state via DOE. That means
> > even if device has physically exited to UNLOCKED, TDX host should still
> > call STOP TDI fwcall first, then MMIO unmap.
> > 
> > > 
> > > > > 
> > > > > > So the safer way is
> > > > > > to unbind the TDI first, then revoke MMIOs, then do FLR.
> > > > > > 
> > > > > > I'm not sure when p2p dma is involved AMD will have the same issue.
> > > > > 
> > > > > On AMD, the host can "revoke" at any time, at worst it'll see RMP 
> > > > > events from IOMMU. Thanks,
> > > > 
> > > > Is the RMP event firstly detected by host or guest? If by host,
> > > 
> > > Host.
> > > 
> > > > host could fool guest by just suppress the event. Guest thought the
> > > > DMA writting is successful but it is not and may cause security issue.
> > > 
> > > An RMP event on the host is an indication that RMP check has failed and 
> > > DMA to the guest did not complete so the guest won't see new data. Same 
> > > as other PCI errors really. RMP acts like a firewall, things behind it do 
> > > not need to know if something was dropped. Thanks,
> > 
> > Not really, guest thought the data is changed but it actually doesn't.
> > I.e. data integrity is broken.
> 
> I am not following, sorry. Integrity is broken when something untrusted (== 
> other than the SNP guest and the trusted device) manages to write to the 
> guest encrypted memory successfully.

Integrity is also broken when guest thought the content in some addr was
written to A but it actually stays B.

> If nothing is written - the guest can easily see this and do... nothing?

The guest may not see this only by RMP event, or IOMMU fault, malicious
host could surpress these events.  Yes, guest may later read the addr
and see the trick, but this cannot be ensured. There is no general
contract saying SW must read the addr to ensure DMA write successful.

And DMA to MMIO is the worse case than DMA to memory. SW even cannot
read back the content since MMIO registers may be Write Only.

So you need ASID fence to make guest easily see the DMA Silent Drop.
Intel & ARM also have there own way.

The purpose here is to have a consensus that benigh VMM should avoid
triggering these DMA Silent Drop protections, by "unbind TDI first,
then invalidate MMIO".

Thanks,
Yilun

> Devices have bugs or spurious interrupts happen, the guest driver should be 
> able to cope with that.
> > Also please help check if the following relates to this issue:
> > 
> > SEV-TIO Firmware Interface SPEC, Section 2.11
> > 
> > If a bound TDI sends a request to the root complex, and the IOMMU detects a 
> > fault caused by host
> > configuration, the root complex fences the ASID from all further I/O to or 
> > from that guest. A host
> > fault is either a host page table fault or an RMP check violation. ASID 
> > fencing means that the
> > IOMMU blocks all further I/O from the root

[PATCH v2 2/5] drm/xe: Start using ggtt->start in preparation of balloon removal

Instead of having ggtt->size point to the end of ggtt, have ggtt->size
be the actual size of the GGTT, and introduce ggtt->start to point to
the beginning of GGTT.

This will allow a massive cleanup of GGTT in case of SRIOV-VF.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/xe/tests/xe_guc_buf_kunit.c |  2 +-
 drivers/gpu/drm/xe/xe_ggtt.c| 60 ++---
 drivers/gpu/drm/xe/xe_ggtt_types.h  |  4 +-
 3 files changed, 34 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/xe/tests/xe_guc_buf_kunit.c 
b/drivers/gpu/drm/xe/tests/xe_guc_buf_kunit.c
index 537766cdd882e..12a8970a5ca1c 100644
--- a/drivers/gpu/drm/xe/tests/xe_guc_buf_kunit.c
+++ b/drivers/gpu/drm/xe/tests/xe_guc_buf_kunit.c
@@ -67,7 +67,7 @@ static int guc_buf_test_init(struct kunit *test)
 
KUNIT_ASSERT_EQ(test, 0,
xe_ggtt_init_kunit(ggtt, DUT_GGTT_START,
-  DUT_GGTT_START + DUT_GGTT_SIZE));
+  DUT_GGTT_SIZE));
 
kunit_activate_static_stub(test, xe_managed_bo_create_pin_map,
   replacement_xe_managed_bo_create_pin_map);
diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c
index 7b11fa1356f0b..937cff3d44811 100644
--- a/drivers/gpu/drm/xe/xe_ggtt.c
+++ b/drivers/gpu/drm/xe/xe_ggtt.c
@@ -126,7 +126,7 @@ static void ggtt_update_access_counter(struct xe_ggtt *ggtt)
 static void xe_ggtt_set_pte(struct xe_ggtt *ggtt, u64 addr, u64 pte)
 {
xe_tile_assert(ggtt->tile, !(addr & XE_PTE_MASK));
-   xe_tile_assert(ggtt->tile, addr < ggtt->size);
+   xe_tile_assert(ggtt->tile, addr < ggtt->start + ggtt->size);
 
writeq(pte, &ggtt->gsm[addr >> XE_PTE_SHIFT]);
 }
@@ -222,18 +222,18 @@ static const struct xe_ggtt_pt_ops xelpg_pt_wa_ops = {
.ggtt_set_pte = xe_ggtt_set_pte_and_flush,
 };
 
-static void __xe_ggtt_init_early(struct xe_ggtt *ggtt, u32 reserved)
+static void __xe_ggtt_init_early(struct xe_ggtt *ggtt, u64 start, u64 size)
 {
-   drm_mm_init(&ggtt->mm, reserved,
-   ggtt->size - reserved);
+   ggtt->start = start;
+   ggtt->size = size;
+   drm_mm_init(&ggtt->mm, start, ggtt->size);
mutex_init(&ggtt->lock);
primelockdep(ggtt);
 }
 
-int xe_ggtt_init_kunit(struct xe_ggtt *ggtt, u32 reserved, u32 size)
+int xe_ggtt_init_kunit(struct xe_ggtt *ggtt, u32 start, u32 size)
 {
-   ggtt->size = size;
-   __xe_ggtt_init_early(ggtt, reserved);
+   __xe_ggtt_init_early(ggtt, start, size);
return 0;
 }
 EXPORT_SYMBOL_IF_KUNIT(xe_ggtt_init_kunit);
@@ -254,26 +254,32 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
struct xe_device *xe = tile_to_xe(ggtt->tile);
struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
unsigned int gsm_size;
+   u64 ggtt_start, wopcm = xe_wopcm_size(xe), ggtt_size;
int err;
 
-   if (IS_SRIOV_VF(xe) || GRAPHICS_VERx100(xe) >= 1250)
-   gsm_size = SZ_8M; /* GGTT is expected to be 4GiB */
-   else
-   gsm_size = probe_gsm_size(pdev);
-
-   if (gsm_size == 0) {
-   drm_err(&xe->drm, "Hardware reported no preallocated GSM\n");
-   return -ENOMEM;
+   if (!IS_SRIOV_VF(xe)) {
+   if (GRAPHICS_VERx100(xe) >= 1250)
+   gsm_size = SZ_8M; /* GGTT is expected to be 4GiB */
+   else
+   gsm_size = probe_gsm_size(pdev);
+   if (gsm_size == 0) {
+   drm_err(&xe->drm, "Hardware reported no preallocated 
GSM\n");
+   return -ENOMEM;
+   }
+   ggtt_start = wopcm;
+   ggtt_size = (gsm_size / 8) * (u64) XE_PAGE_SIZE - ggtt_start;
+   } else {
+   /* GGTT is expected to be 4GiB */
+   ggtt_start = wopcm;
+   ggtt_size = SZ_4G - ggtt_start;
}
 
ggtt->gsm = ggtt->tile->mmio.regs + SZ_8M;
-   ggtt->size = (gsm_size / 8) * (u64) XE_PAGE_SIZE;
-
if (IS_DGFX(xe) && xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K)
ggtt->flags |= XE_GGTT_FLAGS_64K;
 
-   if (ggtt->size > GUC_GGTT_TOP)
-   ggtt->size = GUC_GGTT_TOP;
+   if (ggtt_size + ggtt_start > GUC_GGTT_TOP)
+   ggtt_size = GUC_GGTT_TOP - ggtt_start;
 
if (GRAPHICS_VERx100(xe) >= 1270)
ggtt->pt_ops = (ggtt->tile->media_gt &&
@@ -284,7 +290,7 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
ggtt->pt_ops = &xelp_pt_ops;
 
ggtt->wq = alloc_workqueue("xe-ggtt-wq", 0, WQ_MEM_RECLAIM);
-   __xe_ggtt_init_early(ggtt, xe_wopcm_size(xe));
+   __xe_ggtt_init_early(ggtt, ggtt_start, ggtt_size);
 
err = drmm_add_action_or_reset(&xe->drm, ggtt_fini_early, ggtt);
if (err)
@@ -520,11 +526,9 @@ void xe_ggtt_node_remove_balloon_locked(struct 
xe_ggtt_node *node)
 static void xe_ggtt_assert_fit(

Re: [PATCH 3/3] arm64: tegra: Add NVJPG node

2025-06-10 Thread Mikko Perttunen


On 6/6/25 7:45 PM, Diogo Ivo wrote:

The Tegra X1 chip contains a NVJPG accelerator capable of
encoding/decoding JPEG files in hardware, so add its DT node.

Signed-off-by: Diogo Ivo 
---
  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 
6f8cdf012f0f12a16716e9d479c46b330bbb7dda..087f38256fd40f57c4685e907f9682eb49ee31db
 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -253,7 +253,13 @@ vic@5434 {
nvjpg@5438 {
compatible = "nvidia,tegra210-nvjpg";
reg = <0x0 0x5438 0x0 0x0004>;
-   status = "disabled";
+   clocks = <&tegra_car TEGRA210_CLK_NVJPG>;
+   clock-names = "nvjpg";
+   resets = <&tegra_car 195>;
+   reset-names = "nvjpg";
+
+   iommus = <&mc TEGRA_SWGROUP_NVJPG>;
+   power-domains = <&pd_nvjpg>;
};
  
  		dsib: dsi@5440 {




Please mention Tegra210 in the commit subject, and perhaps adjust the 
commit message to say that you're updating and enabling the device tree 
node (rather than adding, since it's already there).


With that,

Reviewed-by: Mikko Perttunen

Re: [PATCH] Documentation: nouveau: Update GSP message queue kernel-doc reference

2025-06-10 Thread Randy Dunlap




On 6/9/25 11:52 PM, Bagas Sanjaya wrote:
> Commit c472d828348caf ("drm/nouveau/gsp: move subdev/engine impls to
> subdev/gsp/rm/r535/") moves GSP-RM message queue implementation in
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c to versioned path in
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c, but forgets to
> update kernel-doc reference in nouveau docs, hence triggers htmldocs
> warnings:
> 
> ERROR: Cannot find file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> WARNING: No kernel-doc for file 
> ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> 
> Update the reference.
> 
> Fixes: c472d828348c ("drm/nouveau/gsp: move subdev/engine impls to 
> subdev/gsp/rm/r535/")
> Signed-off-by: Bagas Sanjaya 
> ---
>  Documentation/gpu/nouveau.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/nouveau.rst b/Documentation/gpu/nouveau.rst
> index b8c801e0068cb0..878fb1ade31e4c 100644
> --- a/Documentation/gpu/nouveau.rst
> +++ b/Documentation/gpu/nouveau.rst
> @@ -25,7 +25,7 @@ providing a consistent API to upper layers of the driver 
> stack.
>  GSP Support
>  
>  
> -.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> +.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c

Are you sure?  Did that work for you?

I see
/**
 * DOC: GSP message queue element

in drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c but not in the
file that you referenced.  Maybe it just keeps moving around...


This works for me. Please send a v2 if you see the need to.


> :doc: GSP message queue element
>  
>  .. kernel-doc:: drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> 
> base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494

-- 
~Randy

[PATCH v2 1/5] drm/mm: Introduce address space shifting

From: Tomasz Lis 

Due to resource reprovisioning, sometimes a need arises to move
a living address space to a new area, preserving all the nodes
and holes stored within.

It is possible to do that by removing all nodes to a temporary list,
reiniting the drm_mm instance and re-adding everything while applying
a shift to each node. But that is a lot of extra work for a task
which could be done internally without any node shuffle operations.

This change introduces an interface which allows to shift the range
without pruning the whole drm_mm instance.

Having a drm_mm interface for such shift significantly simplifies
the code required to adjust a KMD for a change in base address
of a space managed by drm_mm instance.

Signed-off-by: Tomasz Lis 
Link: https://lore.kernel.org/r/20250204224136.3183710-2-tomasz@intel.com
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_mm.c | 24 
 include/drm/drm_mm.h |  1 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index ca254611b3823..ce3bd8b5e41f0 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -917,6 +917,30 @@ struct drm_mm_node *drm_mm_scan_color_evict(struct 
drm_mm_scan *scan)
 }
 EXPORT_SYMBOL(drm_mm_scan_color_evict);
 
+/**
+ * drm_mm_shift - move the range of addresses managed by this @mm
+ * @mm: the drm_mm structure instance to shift
+ * @shift: the shift value to be added to addresses of all nodes
+ *
+ * The function shifts all nodes by given offset, moving the address space
+ * range managed by this @mm.
+ */
+void drm_mm_shift(struct drm_mm *mm, s64 shift)
+{
+   struct drm_mm_node *node;
+
+   /*
+* Head node represents a hole, with negative size and start at the end
+* of addressable area. This means it is never present within nodes
+* list - needs to be shifted separately.
+*/
+   mm->head_node.start += shift;
+
+   drm_mm_for_each_node(node, mm)
+   node->start += shift;
+}
+EXPORT_SYMBOL(drm_mm_shift);
+
 /**
  * drm_mm_init - initialize a drm-mm allocator
  * @mm: the drm_mm structure to initialize
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index f654874c4ce67..798e5a4f07add 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -465,6 +465,7 @@ static inline int drm_mm_insert_node(struct drm_mm *mm,
 void drm_mm_remove_node(struct drm_mm_node *node);
 void drm_mm_init(struct drm_mm *mm, u64 start, u64 size);
 void drm_mm_takedown(struct drm_mm *mm);
+void drm_mm_shift(struct drm_mm *mm, s64 shift);
 
 /**
  * drm_mm_clean - checks whether an allocator is clean
-- 
2.45.2

Re: [PATCH] fbdev: pm3fb: Fix potential divide by zero

2025-06-10 Thread Geert Uytterhoeven

Hi Alex,

On Sat, 7 Jun 2025 at 22:14, Alex Guo  wrote:
> variable var->pixclock can be set by user. In case it equals to
>  zero, divide by zero would occur in pm3fb_check_var. Similar
> crashes have happened in other fbdev drivers. There is no check
> and modification on var->pixclock along the call chain to
> pm3fb_check_var. So we fix this by checking whether 'pixclock'
> is zero.
>
> Similar commit: commit 16844e58704 ("video: fbdev: tridentfb:
> Error out if 'pixclock' equals zero")
>
> Signed-off-by: Alex Guo 

Thanks for your patch, which is now commit 59d1fc7b3e1ae9d4
("fbdev: pm3fb: fix potential divide by zero") in fbdev/for-next.

> --- a/drivers/video/fbdev/pm3fb.c
> +++ b/drivers/video/fbdev/pm3fb.c
> @@ -998,6 +998,9 @@ static int pm3fb_check_var(struct fb_var_screeninfo *var, 
> struct fb_info *info)
> return -EINVAL;
> }
>
> +   if (!var->pixclock)
> +   return -EINVAL;

While this fixes the crash, this is correct behavior for an fbdev driver.
When a value is invalid, it should be rounded up to a valid value instead,
if possible.

> +
> if (PICOS2KHZ(var->pixclock) > PM3_MAX_PIXCLOCK) {
> DPRINTK("pixclock too high (%ldKHz)\n",
> PICOS2KHZ(var->pixclock));

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v3 2/7] drm/syncobj: Do not allocate an array to store zeros when waiting

2025-06-10 Thread kernel test robot

Hi Tvrtko,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master drm/drm-next drm-misc/drm-misc-next 
v6.16-rc1 next-20250606]
[cannot apply to v3.1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Tvrtko-Ursulin/drm-syncobj-Remove-unhelpful-helper/20250609-194350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next
patch link:
https://lore.kernel.org/r/20250609113313.75395-3-tvrtko.ursulin%40igalia.com
patch subject: [PATCH v3 2/7] drm/syncobj: Do not allocate an array to store 
zeros when waiting
config: arm-davinci_all_defconfig 
(https://download.01.org/0day-ci/archive/20250610/202506101443.xwvcz2hc-...@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project 
cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20250610/202506101443.xwvcz2hc-...@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/202506101443.xwvcz2hc-...@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!

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

[PATCH v2 0/5] drm/xe: Make struct xe_ggtt private.

SRIOV-VF node shifting code uses a complicated system with balloons
to limit allocation and size. Since size never changes after init,
shifting can simply be done by taking the the GGTT lock.

First introduce a function to shift an entire GGTT, this removes the
need for the balloons, then also perform the display code pinning
through a callback, and finally privatize the struct.

No other users outside of xe_ggtt remain.

Maarten Lankhorst (4):
  drm/xe: Start using ggtt->start in preparation of balloon removal
  drm/xe: Rewrite GGTT VF initialisation
  drm/xe: Convert xe_fb_pin to use a callback for insertion into GGTT
  drm/xe: Move struct xe_ggtt to xe_ggtt.c

Tomasz Lis (1):
  drm/mm: Introduce address space shifting

 drivers/gpu/drm/drm_mm.c|  24 ++
 drivers/gpu/drm/xe/Makefile |   3 +-
 drivers/gpu/drm/xe/display/xe_fb_pin.c  | 111 +++
 drivers/gpu/drm/xe/tests/xe_guc_buf_kunit.c |   2 +-
 drivers/gpu/drm/xe/xe_ggtt.c| 336 ++--
 drivers/gpu/drm/xe/xe_ggtt.h|  14 +-
 drivers/gpu/drm/xe/xe_ggtt_types.h  |  53 +--
 drivers/gpu/drm/xe/xe_sriov_vf.c|   4 +-
 drivers/gpu/drm/xe/xe_tile_sriov_vf.c   | 254 ---
 drivers/gpu/drm/xe/xe_tile_sriov_vf.h   |  18 --
 include/drm/drm_mm.h|   1 +
 11 files changed, 261 insertions(+), 559 deletions(-)
 delete mode 100644 drivers/gpu/drm/xe/xe_tile_sriov_vf.c
 delete mode 100644 drivers/gpu/drm/xe/xe_tile_sriov_vf.h

-- 
2.45.2

[PATCH v2 3/5] drm/xe: Rewrite GGTT VF initialisation

The previous code was using a complicated system with 2 balloons to
set GGTT size and adjust GGTT offset. While it works, it's overly
complicated.

A better approach is to set the offset and size when initialising GGTT,
this removes the need for adding balloons. The resize function only
needs to re-initialise GGTT at the new offset.

We use the newly created drm_mm_shift to shift the nodes.

This removes the need to manipulate the internals of xe_ggtt outside
of xe_ggtt, and cleans up a lot of now unneeded code.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/xe/Makefile   |   3 +-
 drivers/gpu/drm/xe/xe_ggtt.c  | 144 +++
 drivers/gpu/drm/xe/xe_ggtt.h  |   5 +-
 drivers/gpu/drm/xe/xe_sriov_vf.c  |   4 +-
 drivers/gpu/drm/xe/xe_tile_sriov_vf.c | 254 --
 drivers/gpu/drm/xe/xe_tile_sriov_vf.h |  18 --
 6 files changed, 29 insertions(+), 399 deletions(-)
 delete mode 100644 drivers/gpu/drm/xe/xe_tile_sriov_vf.c
 delete mode 100644 drivers/gpu/drm/xe/xe_tile_sriov_vf.h

diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index f5f5775acdc00..e4bf484d41216 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -139,8 +139,7 @@ xe-y += \
xe_guc_relay.o \
xe_memirq.o \
xe_sriov.o \
-   xe_sriov_vf.o \
-   xe_tile_sriov_vf.o
+   xe_sriov_vf.o
 
 xe-$(CONFIG_PCI_IOV) += \
xe_gt_sriov_pf.o \
diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c
index 937cff3d44811..4c58626f002f9 100644
--- a/drivers/gpu/drm/xe/xe_ggtt.c
+++ b/drivers/gpu/drm/xe/xe_ggtt.c
@@ -29,7 +29,7 @@
 #include "xe_pm.h"
 #include "xe_res_cursor.h"
 #include "xe_sriov.h"
-#include "xe_tile_sriov_vf.h"
+#include "xe_gt_sriov_vf.h"
 #include "xe_wa.h"
 #include "xe_wopcm.h"
 
@@ -255,7 +255,6 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
unsigned int gsm_size;
u64 ggtt_start, wopcm = xe_wopcm_size(xe), ggtt_size;
-   int err;
 
if (!IS_SRIOV_VF(xe)) {
if (GRAPHICS_VERx100(xe) >= 1250)
@@ -269,9 +268,15 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
ggtt_start = wopcm;
ggtt_size = (gsm_size / 8) * (u64) XE_PAGE_SIZE - ggtt_start;
} else {
-   /* GGTT is expected to be 4GiB */
-   ggtt_start = wopcm;
-   ggtt_size = SZ_4G - ggtt_start;
+   ggtt_start = xe_gt_sriov_vf_ggtt_base(ggtt->tile->primary_gt);
+   ggtt_size = xe_gt_sriov_vf_ggtt(ggtt->tile->primary_gt);
+
+   if (ggtt_start < wopcm || ggtt_start > GUC_GGTT_TOP ||
+   ggtt_size > GUC_GGTT_TOP - ggtt_start) {
+   drm_err(&xe->drm, "tile%u: Invalid GGTT configuration: 
%#llx-%#llx\n",
+ggtt->tile->id, ggtt_start, ggtt_start + 
ggtt_size - 1);
+   return -ERANGE;
+   }
}
 
ggtt->gsm = ggtt->tile->mmio.regs + SZ_8M;
@@ -292,17 +297,7 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
ggtt->wq = alloc_workqueue("xe-ggtt-wq", 0, WQ_MEM_RECLAIM);
__xe_ggtt_init_early(ggtt, ggtt_start, ggtt_size);
 
-   err = drmm_add_action_or_reset(&xe->drm, ggtt_fini_early, ggtt);
-   if (err)
-   return err;
-
-   if (IS_SRIOV_VF(xe)) {
-   err = xe_tile_sriov_vf_prepare_ggtt(ggtt->tile);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return drmm_add_action_or_reset(&xe->drm, ggtt_fini_early, ggtt);
 }
 ALLOW_ERROR_INJECTION(xe_ggtt_init_early, ERRNO); /* See xe_pci_probe() */
 
@@ -455,84 +450,8 @@ static void xe_ggtt_invalidate(struct xe_ggtt *ggtt)
ggtt_invalidate_gt_tlb(ggtt->tile->media_gt);
 }
 
-static void xe_ggtt_dump_node(struct xe_ggtt *ggtt,
- const struct drm_mm_node *node, const char 
*description)
-{
-   char buf[10];
-
-   if (IS_ENABLED(CONFIG_DRM_XE_DEBUG)) {
-   string_get_size(node->size, 1, STRING_UNITS_2, buf, 
sizeof(buf));
-   xe_gt_dbg(ggtt->tile->primary_gt, "GGTT %#llx-%#llx (%s) %s\n",
- node->start, node->start + node->size, buf, 
description);
-   }
-}
-
-/**
- * xe_ggtt_node_insert_balloon_locked - prevent allocation of specified GGTT 
addresses
- * @node: the &xe_ggtt_node to hold reserved GGTT node
- * @start: the starting GGTT address of the reserved region
- * @end: then end GGTT address of the reserved region
- *
- * To be used in cases where ggtt->lock is already taken.
- * Use xe_ggtt_node_remove_balloon_locked() to release a reserved GGTT node.
- *
- * Return: 0 on success or a negative error code on failure.
- */
-int xe_ggtt_node_insert_balloon_locked(struct xe_ggtt_node *node, u64 start, 
u64 end)
-{
-   struct xe_ggtt *ggtt = node->ggtt;
-   int err;
-
-   xe_tile_

[PATCH v2 4/5] drm/xe: Convert xe_fb_pin to use a callback for insertion into GGTT

From: Maarten Lankhorst 

The rotation details belong in xe_fb_pin.c, while the operations involving
GGTT belong to xe_ggtt.c. As directly locking xe_ggtt etc results in
exposing all of xe_ggtt details anyway, create a special function that
allocates a ggtt_node, and allow display to populate it using a callback
as a compromise.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/xe/display/xe_fb_pin.c | 111 -
 drivers/gpu/drm/xe/xe_ggtt.c   |  92 ++--
 drivers/gpu/drm/xe/xe_ggtt.h   |   9 +-
 drivers/gpu/drm/xe/xe_ggtt_types.h |   8 +-
 4 files changed, 132 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c 
b/drivers/gpu/drm/xe/display/xe_fb_pin.c
index 6b362695d6b61..99f2863daebb5 100644
--- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
+++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
@@ -167,12 +167,13 @@ static int __xe_pin_fb_vma_dpt(const struct 
intel_framebuffer *fb,
 }
 
 static void
-write_ggtt_rotated(struct xe_bo *bo, struct xe_ggtt *ggtt, u32 *ggtt_ofs, u32 
bo_ofs,
+write_ggtt_rotated(struct xe_ggtt *ggtt, u32 *ggtt_ofs,
+  u64 pte_flags,
+  xe_ggtt_set_pte_fn write_pte,
+  struct xe_bo *bo, u32 bo_ofs,
   u32 width, u32 height, u32 src_stride, u32 dst_stride)
 {
-   struct xe_device *xe = xe_bo_device(bo);
u32 column, row;
-   u64 pte = ggtt->pt_ops->pte_encode_flags(bo, 
xe->pat.idx[XE_CACHE_NONE]);
 
for (column = 0; column < width; column++) {
u32 src_idx = src_stride * (height - 1) + column + bo_ofs;
@@ -180,7 +181,7 @@ write_ggtt_rotated(struct xe_bo *bo, struct xe_ggtt *ggtt, 
u32 *ggtt_ofs, u32 bo
for (row = 0; row < height; row++) {
u64 addr = xe_bo_addr(bo, src_idx * XE_PAGE_SIZE, 
XE_PAGE_SIZE);
 
-   ggtt->pt_ops->ggtt_set_pte(ggtt, *ggtt_ofs, pte | addr);
+   write_pte(ggtt, *ggtt_ofs, pte_flags | addr);
*ggtt_ofs += XE_PAGE_SIZE;
src_idx -= src_stride;
}
@@ -190,6 +191,28 @@ write_ggtt_rotated(struct xe_bo *bo, struct xe_ggtt *ggtt, 
u32 *ggtt_ofs, u32 bo
}
 }
 
+struct fb_rotate_args {
+   const struct i915_gtt_view *view;
+   struct xe_bo *bo;
+};
+
+static void write_ggtt_rotated_node(struct xe_ggtt *ggtt, struct xe_ggtt_node 
*node,
+   u64 pte_flags, xe_ggtt_set_pte_fn 
write_pte, void *data)
+{
+   struct fb_rotate_args *args = data;
+   struct xe_bo *bo = args->bo;
+   const struct intel_rotation_info *rot_info = &args->view->rotated;
+   u32 ggtt_ofs = node->base.start;
+
+   for (u32 i = 0; i < ARRAY_SIZE(rot_info->plane); i++)
+   write_ggtt_rotated(ggtt, &ggtt_ofs, pte_flags, write_pte,
+  bo, rot_info->plane[i].offset,
+  rot_info->plane[i].width,
+  rot_info->plane[i].height,
+  rot_info->plane[i].src_stride,
+  rot_info->plane[i].dst_stride);
+}
+
 static int __xe_pin_fb_vma_ggtt(const struct intel_framebuffer *fb,
const struct i915_gtt_view *view,
struct i915_vma *vma,
@@ -200,70 +223,40 @@ static int __xe_pin_fb_vma_ggtt(const struct 
intel_framebuffer *fb,
struct xe_device *xe = to_xe_device(fb->base.dev);
struct xe_tile *tile0 = xe_device_get_root_tile(xe);
struct xe_ggtt *ggtt = tile0->mem.ggtt;
+   u64 pte, size;
u32 align;
-   int ret;
-
-   /* TODO: Consider sharing framebuffer mapping?
-* embed i915_vma inside intel_framebuffer
-*/
-   xe_pm_runtime_get_noresume(xe);
-   ret = mutex_lock_interruptible(&ggtt->lock);
-   if (ret)
-   goto out;
+   int ret = 0;
 
align = XE_PAGE_SIZE;
-   if (xe_bo_is_vram(bo) && ggtt->flags & XE_GGTT_FLAGS_64K)
-   align = max_t(u32, align, SZ_64K);
+   if (xe_bo_is_vram(bo) && xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K)
+   align = max(align, SZ_64K);
 
+   /* Fast case, preallocated GGTT view? */
if (bo->ggtt_node[tile0->id] && view->type == I915_GTT_VIEW_NORMAL) {
vma->node = bo->ggtt_node[tile0->id];
-   } else if (view->type == I915_GTT_VIEW_NORMAL) {
-   vma->node = xe_ggtt_node_init(ggtt);
-   if (IS_ERR(vma->node)) {
-   ret = PTR_ERR(vma->node);
-   goto out_unlock;
-   }
-
-   ret = xe_ggtt_node_insert_locked(vma->node, bo->size, align, 0);
-   if (ret) {
-   xe_ggtt_node_fini(vma->node);
-   goto out_unlock;
-   }
-
-   xe_ggtt_map_bo(ggtt

Re: [PATCH] drm/bridge: ti-sn65dsi86: fix REFCLK setting

2025-06-10 Thread Jayesh Choudhary


Hello Michael, Doug,

On 10/06/25 03:59, Doug Anderson wrote:

Hi,

On Wed, May 28, 2025 at 6:21 AM Michael Walle  wrote:


The bridge has three bootstrap pins which are sampled to determine the
frequency of the external reference clock. The driver will also
(over)write that setting. But it seems this is racy after the bridge is
enabled. It was observed that although the driver write the correct
value (by sniffing on the I2C bus), the register has the wrong value.
The datasheet states that the GPIO lines have to be stable for at least
5us after asserting the EN signal. Thus, there seems to be some logic
which samples the GPIO lines and this logic appears to overwrite the
register value which was set by the driver. Waiting 20us after
asserting the EN line resolves this issue.


+Jayesh might have some insight?




Signed-off-by: Michael Walle 
---
I couldn't find a good commit for a Fixes: tag and I'm not sure how
fixes are handled in drm.

  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 60224f476e1d..fcef43154558 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -386,6 +386,17 @@ static int __maybe_unused ti_sn65dsi86_resume(struct 
device *dev)

 gpiod_set_value_cansleep(pdata->enable_gpio, 1);

+   /*
+* After EN is deasserted and an external clock is detected, the bridge
+* will sample GPIO3:1 to determine its frequency. The driver will
+* overwrite this setting. But this is racy. Thus we have to wait a
+* couple of us. According to the datasheet the GPIO lines has to be
+* stable at least 5 us (td5) but it seems that is not enough and the
+* refclk frequency value is lost/overwritten by the bridge itself.
+* Waiting for 20us seems to work.
+*/
+   usleep_range(20, 30);


It might be worth pointing at _where_ the driver overwrites this
setting, or maybe at least pointing to something that makes it easy to
find which exact bits you're talking about.

This looks reasonable to me, though.


I think we are talking about SN_DPPLL_SRC_REG[3:1] bits?
What exact mismatch are you observing in register value?

I am assuming that you have a clock at REFCLK pin. For that:

If refclk is described in devicetree node, then I see that
the driver modifies it in every resume call based solely on the
clock value in dts.

If refclk is not described in dts, then this register is modified by the
driver only when pre_enable() calls enable_comms(). Here also, the
value depends on crtc_mode and the refclk_rate often would not be equal
to the values in "ti_sn_bridge_dsiclk_lut" (supported frequencies), and
you would fallback to "001" register value.
Rest of time, I guess it depends on reading the status from GPIO and
changing the register.

Is the latter one your usecase?



- Jayesh



Reviewed-by: Douglas Anderson

Re: [PATCH] drm/arm/hdlcd: Replace struct simplefb_format with custom type

2025-06-10 Thread Thomas Zimmermann


Hi

Am 09.06.25 um 12:17 schrieb Liviu Dudau:

On Tue, May 27, 2025 at 11:42:57AM +0200, Thomas Zimmermann wrote:

Map DRM FourCC codes to pixel descriptions with internal type struct
hdlcd_format. Reorder formats by preference. Avoid simplefb's struct
simplefb_format, which is for parsing "simple-framebuffer" DT nodes.

The HDLCD drivers uses struct simplefb_format and its default
initializer SIMPLEFB_FORMATS to map DRM_FORMAT_ constants to pixel
descriptions. The simplefb helpers are for parsing "simple-framebuffer"
DT nodes and should be avoided in other context. Therefore replace
it in hdlcd with the custom type struct hdlcd_format and the pixel
descriptions from PIXEL_FORMAT_ constants.

Plane formats exported to userspace are roughly sorted as preferred
by hardware and/or driver. SIMPLEFB_FORMATS currently puts 16-bit
formats to the top of the list. Changing to struct hdlcd_format
allows for reordering the format list. 32-bit formats are now the
preferred ones.

This change also removes including ,
which includes several unrelated headers, such as .

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/arm/hdlcd_crtc.c | 32 +++-
  include/video/pixel_format.h | 15 +++
  2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 3cfefadc7c9d..6fabe65ec0a2 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -11,8 +11,8 @@
  
  #include 

  #include 
-#include 
  
+#include 

  #include 
  
  #include 

@@ -28,6 +28,25 @@
  #include "hdlcd_drv.h"
  #include "hdlcd_regs.h"
  
+struct hdlcd_format {

+   u32 fourcc;
+   struct pixel_format pixel;
+};
+
+static const struct hdlcd_format supported_formats[] = {
+   { DRM_FORMAT_XRGB, PIXEL_FORMAT_XRGB },
+   { DRM_FORMAT_ARGB, PIXEL_FORMAT_ARGB },
+   { DRM_FORMAT_XBGR, PIXEL_FORMAT_XBGR },
+   { DRM_FORMAT_ABGR, PIXEL_FORMAT_ABGR },
+   { DRM_FORMAT_XRGB2101010, PIXEL_FORMAT_XRGB2101010},
+   { DRM_FORMAT_ARGB2101010, PIXEL_FORMAT_ARGB2101010},
+   { DRM_FORMAT_RGB565, PIXEL_FORMAT_RGB565 },
+   { DRM_FORMAT_RGBA5551, PIXEL_FORMAT_RGBA5551 },
+   { DRM_FORMAT_XRGB1555, PIXEL_FORMAT_XRGB1555 },
+   { DRM_FORMAT_ARGB1555, PIXEL_FORMAT_ARGB1555 },
+   { DRM_FORMAT_RGB888, PIXEL_FORMAT_RGB888 },
+};
+
  /*
   * The HDLCD controller is a dumb RGB streamer that gets connected to
   * a single HDMI transmitter or in the case of the ARM Models it gets
@@ -73,8 +92,6 @@ static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
.disable_vblank = hdlcd_crtc_disable_vblank,
  };
  
-static struct simplefb_format supported_formats[] = SIMPLEFB_FORMATS;

Sorry, I was on holiday when you've sent the patch and it fell to the bottom of 
the pile.


No worries.




When I did the initial patch for HDLCD using the SIMPLEFB_FORMATS was 
convenient as I
didn't had to type all the "supported" formats, even if the one carrying the 
alpha
channel were ignored (HDLCD only has one plane). If we're going to move the 
supported
formats in this file I would suggest trimming it down to remove all the 
alpha-channel
formats as they are pointless to list as supported. If there is no other user 
of the
formats added in pixel_format.h then that should slim down the patch 
considerably.


That's even better. I suspected that not all formats would be supported 
by hdlcd. I'll prepare an update then.


Best regards
Thomas



Best regards,
Liviu


-
  /*
   * Setup the HDLCD registers for decoding the pixels out of the framebuffer
   */
@@ -83,15 +100,12 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
unsigned int btpp;
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
const struct drm_framebuffer *fb = crtc->primary->state->fb;
-   uint32_t pixel_format;
-   struct simplefb_format *format = NULL;
+   const struct pixel_format *format = NULL;
int i;
  
-	pixel_format = fb->format->format;

-
for (i = 0; i < ARRAY_SIZE(supported_formats); i++) {
-   if (supported_formats[i].fourcc == pixel_format)
-   format = &supported_formats[i];
+   if (supported_formats[i].fourcc == fb->format->format)
+   format = &supported_formats[i].pixel;
}
  
  	if (WARN_ON(!format))

diff --git a/include/video/pixel_format.h b/include/video/pixel_format.h
index b5104b2a3a13..5ad2386e2014 100644
--- a/include/video/pixel_format.h
+++ b/include/video/pixel_format.h
@@ -23,6 +23,12 @@ struct pixel_format {
  #define PIXEL_FORMAT_XRGB1555 \
{ 16, false, { .alpha = {0, 0}, .red = {10, 5}, .green = {5, 5}, .blue 
= {0, 5} } }
  
+#define PIXEL_FORMAT_ARGB1555 \

+   { 16, false, { .alpha = {15, 1}, .red = {10, 5}, .green = {5, 5}, .blue 
= {0, 5} } }
+
+#define PIXEL_FORMAT_RGBA5551 \
+   { 16, false, { .alpha = {0, 1},

[PATCH v2 5/5] drm/xe: Move struct xe_ggtt to xe_ggtt.c

From: Maarten Lankhorst 

No users left outside of xe_ggtt.c, so we can make the struct private.

This prevents us from accidentally touching it before init.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Brost 
---
 drivers/gpu/drm/xe/xe_ggtt.c   | 52 ++
 drivers/gpu/drm/xe/xe_ggtt_types.h | 51 -
 2 files changed, 52 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c
index c9ee2a4ff8ab9..b8e1b44452e4d 100644
--- a/drivers/gpu/drm/xe/xe_ggtt.c
+++ b/drivers/gpu/drm/xe/xe_ggtt.c
@@ -66,6 +66,58 @@
  * give us the correct placement for free.
  */
 
+/**
+ * struct xe_ggtt_pt_ops - GGTT Page table operations
+ * Which can vary from platform to platform.
+ */
+struct xe_ggtt_pt_ops {
+   /** @pte_encode_flags: Encode PTE flags for a given BO */
+   u64 (*pte_encode_flags)(struct xe_bo *bo, u16 pat_index);
+
+   /** @ggtt_set_pte: Directly write into GGTT's PTE */
+   xe_ggtt_set_pte_fn ggtt_set_pte;
+};
+
+/**
+ * struct xe_ggtt - Main GGTT struct
+ *
+ * In general, each tile can contains its own Global Graphics Translation Table
+ * (GGTT) instance.
+ */
+struct xe_ggtt {
+   /** @tile: Back pointer to tile where this GGTT belongs */
+   struct xe_tile *tile;
+/** @start: Start offset of GGTT */
+   u64 start;
+   /** @size: Total usable size of this GGTT */
+   u64 size;
+
+#define XE_GGTT_FLAGS_64K BIT(0)
+   /**
+* @flags: Flags for this GGTT
+* Acceptable flags:
+* - %XE_GGTT_FLAGS_64K - if PTE size is 64K. Otherwise, regular is 4K.
+*/
+   unsigned int flags;
+   /** @scratch: Internal object allocation used as a scratch page */
+   struct xe_bo *scratch;
+   /** @lock: Mutex lock to protect GGTT data */
+   struct mutex lock;
+   /**
+*  @gsm: The iomem pointer to the actual location of the translation
+* table located in the GSM for easy PTE manipulation
+*/
+   u64 __iomem *gsm;
+   /** @pt_ops: Page Table operations per platform */
+   const struct xe_ggtt_pt_ops *pt_ops;
+   /** @mm: The memory manager used to manage individual GGTT allocations 
*/
+   struct drm_mm mm;
+   /** @access_count: counts GGTT writes */
+   unsigned int access_count;
+   /** @wq: Dedicated unordered work queue to process node removals */
+   struct workqueue_struct *wq;
+};
+
 static u64 xelp_ggtt_pte_flags(struct xe_bo *bo, u16 pat_index)
 {
u64 pte = XE_PAGE_PRESENT;
diff --git a/drivers/gpu/drm/xe/xe_ggtt_types.h 
b/drivers/gpu/drm/xe/xe_ggtt_types.h
index f4aa5671cb3e3..4f1fd3c456a3b 100644
--- a/drivers/gpu/drm/xe/xe_ggtt_types.h
+++ b/drivers/gpu/drm/xe/xe_ggtt_types.h
@@ -13,46 +13,6 @@
 struct xe_bo;
 struct xe_gt;
 
-/**
- * struct xe_ggtt - Main GGTT struct
- *
- * In general, each tile can contains its own Global Graphics Translation Table
- * (GGTT) instance.
- */
-struct xe_ggtt {
-   /** @tile: Back pointer to tile where this GGTT belongs */
-   struct xe_tile *tile;
-   /** @start: Start offset of GGTT */
-   u64 start;
-   /** @size: Total usable size of this GGTT */
-   u64 size;
-
-#define XE_GGTT_FLAGS_64K BIT(0)
-   /**
-* @flags: Flags for this GGTT
-* Acceptable flags:
-* - %XE_GGTT_FLAGS_64K - if PTE size is 64K. Otherwise, regular is 4K.
-*/
-   unsigned int flags;
-   /** @scratch: Internal object allocation used as a scratch page */
-   struct xe_bo *scratch;
-   /** @lock: Mutex lock to protect GGTT data */
-   struct mutex lock;
-   /**
-*  @gsm: The iomem pointer to the actual location of the translation
-* table located in the GSM for easy PTE manipulation
-*/
-   u64 __iomem *gsm;
-   /** @pt_ops: Page Table operations per platform */
-   const struct xe_ggtt_pt_ops *pt_ops;
-   /** @mm: The memory manager used to manage individual GGTT allocations 
*/
-   struct drm_mm mm;
-   /** @access_count: counts GGTT writes */
-   unsigned int access_count;
-   /** @wq: Dedicated unordered work queue to process node removals */
-   struct workqueue_struct *wq;
-};
-
 /**
  * struct xe_ggtt_node - A node in GGTT.
  *
@@ -76,16 +36,5 @@ typedef void (*xe_ggtt_transform_cb)(struct xe_ggtt *ggtt,
 struct xe_ggtt_node *node,
 u64 pte_flags,
 xe_ggtt_set_pte_fn set_pte, void *arg);
-/**
- * struct xe_ggtt_pt_ops - GGTT Page table operations
- * Which can vary from platform to platform.
- */
-struct xe_ggtt_pt_ops {
-   /** @pte_encode_flags: Encode PTE flags for a given BO */
-   u64 (*pte_encode_flags)(struct xe_bo *bo, u16 pat_index);
-
-   /** @ggtt_set_pte: Directly write into GGTT's PTE */
-   xe_ggtt_set_pte_fn ggtt_set_pte;
-};
 
 #endif
-- 
2.45

Re: [PATCH v1 1/2] drm/panel: st7701: Add Winstar wf40eswaa6mnn0 panel support

2025-06-10 Thread neil . armstrong


On 06/06/2025 13:45, Stefan Eichenberger wrote:

The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a
resolution of 480x480 pixels.

This panel is driven by the Sitronix ST7701 controller and uses a MIPI
DSI interface. The settings are based on the panel's datasheet and the
init sequence provided by Winstar.

It was tested on a Verdin iMX8MP from Toradex with a Carrier Board
providing a MIPI DSI interface.

Signed-off-by: Stefan Eichenberger 
---
  drivers/gpu/drm/panel/panel-sitronix-st7701.c | 124 ++
  1 file changed, 124 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c 
b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
index 1f72ef7ca74c9..cf42281393dd9 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7701.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
@@ -520,6 +520,28 @@ static void rg28xx_gip_sequence(struct st7701 *st7701)
st7701_switch_cmd_bkx(st7701, false, 0);
  }
  
+static void wf40eswaa6mnn0_gip_sequence(struct st7701 *st7701)

+{
+   ST7701_WRITE(st7701, 0xE0, 0x00, 0x28, 0x02);
+   ST7701_WRITE(st7701, 0xE1, 0x08, 0xA0, 0x00, 0x00, 0x07, 0xA0, 0x00,
+  0x00, 0x00, 0x44, 0x44);
+   ST7701_WRITE(st7701, 0xE2, 0x11, 0x11, 0x44, 0x44, 0xED, 0xA0, 0x00,
+  0x00, 0xEC, 0xA0, 0x00, 0x00);
+   ST7701_WRITE(st7701, 0xE3, 0x00, 0x00, 0x11, 0x11);
+   ST7701_WRITE(st7701, 0xE4, 0x44, 0x44);
+   ST7701_WRITE(st7701, 0xE5, 0x0A, 0xE9, 0xD8, 0xA0, 0x0C, 0xEB, 0xD8,
+  0xA0, 0x0E, 0xED, 0xD8, 0xA0, 0x10, 0xEF, 0xD8, 0xA0);
+   ST7701_WRITE(st7701, 0xE6, 0x00, 0x00, 0x11, 0x11);
+   ST7701_WRITE(st7701, 0xE7, 0x44, 0x44);
+   ST7701_WRITE(st7701, 0xE8, 0x09, 0xE8, 0xD8, 0xA0, 0x0B, 0xEA, 0xD8,
+  0xA0, 0x0D, 0xEC, 0xD8, 0xA0, 0x0F, 0xEE, 0xD8, 0xA0);
+   ST7701_WRITE(st7701, 0xEB, 0x00, 0x00, 0xE4, 0xE4, 0x88, 0x00, 0x40);
+   ST7701_WRITE(st7701, 0xEC, 0x3C, 0x00);
+   ST7701_WRITE(st7701, 0xED, 0xAB, 0x89, 0x76, 0x54, 0x02, 0xFF, 0xFF,
+  0xFF, 0xFF, 0xFF, 0xFF, 0x20, 0x45, 0x67, 0x98, 0xBA);
+   ST7701_WRITE(st7701, MIPI_DCS_SET_ADDRESS_MODE, 0);
+}
+
  static int st7701_prepare(struct drm_panel *panel)
  {
struct st7701 *st7701 = panel_to_st7701(panel);
@@ -1135,6 +1157,107 @@ static const struct st7701_panel_desc rg28xx_desc = {
.gip_sequence = rg28xx_gip_sequence,
  };
  
+static const struct drm_display_mode wf40eswaa6mnn0_mode = {

+   .clock  = 18306,
+
+   .hdisplay   = 480,
+   .hsync_start= 480 + 2,
+   .hsync_end  = 480 + 2 + 45,
+   .htotal = 480 + 2 + 45  + 13,
+
+   .vdisplay   = 480,
+   .vsync_start= 480 + 2,
+   .vsync_end  = 480 + 2 + 70,
+   .vtotal = 480 + 2 + 70 + 13,
+
+   .width_mm   = 72,
+   .height_mm  = 70,
+
+   .flags  = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+
+   .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct st7701_panel_desc wf40eswaa6mnn0_desc = {
+   .mode = &wf40eswaa6mnn0_mode,
+   .lanes = 2,
+   .format = MIPI_DSI_FMT_RGB888,
+   .panel_sleep_delay = 0,
+
+   .pv_gamma = {
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC0_MASK, 0x1),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC4_MASK, 0x08),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC8_MASK, 0x10),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC16_MASK, 0x0c),
+
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC24_MASK, 0x10),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC52_MASK, 0x08),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC80_MASK, 0x10),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC108_MASK, 0x0c),
+
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC147_MASK, 0x08),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC175_MASK, 0x22),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC203_MASK, 0x04),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC231_MASK, 0x14),
+
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC239_MASK, 0x12),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC247_MASK, 0xb3),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC251_MASK, 0x3a),
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMCTRL_VC255_MASK, 0x1f)
+   },
+   .nv_gamma = {
+   CFIELD_PREP(ST7701_CMD2_BK0_GAMC

RE: [PATCH 2/4] drm/i915/panel: add panel register/unregister

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Friday, June 6, 2025 2:35 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; Heikki
> Krogerus ; Wysocki, Rafael J
> ; Lee, Shawn C ; Yang,
> Simon1 ; Doug Anderson ;
> Maxime Ripard ; Nikula, Jani 
> Subject: [PATCH 2/4] drm/i915/panel: add panel register/unregister
> 
> Add panel register/unregister functions, and handle backlight
> register/unregister from there. This is in preparation for adding more panel
> specific register/unregister functionality.
> 
> Cc: Lee Shawn C 
> Signed-off-by: Jani Nikula 
> ---
>  .../gpu/drm/i915/display/intel_connector.c| 23 +--
>  drivers/gpu/drm/i915/display/intel_panel.c| 10 
>  drivers/gpu/drm/i915/display/intel_panel.h|  2 ++
>  3 files changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 9a61c972dce9..2867d76d1a5e 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -32,7 +32,6 @@
> 
>  #include "i915_drv.h"
>  #include "i915_utils.h"
> -#include "intel_backlight.h"
>  #include "intel_connector.h"
>  #include "intel_display_core.h"
>  #include "intel_display_debugfs.h"
> @@ -153,36 +152,36 @@ void intel_connector_destroy(struct drm_connector
> *connector)
>   kfree(connector);
>  }
> 
> -int intel_connector_register(struct drm_connector *connector)
> +int intel_connector_register(struct drm_connector *_connector)
>  {
> - struct intel_connector *intel_connector =
> to_intel_connector(connector);
> - struct drm_i915_private *i915 = to_i915(connector->dev);
> + struct intel_connector *connector = to_intel_connector(_connector);
> + struct drm_i915_private *i915 = to_i915(_connector->dev);
Can intel_display be used over here?

Apart from the above one, patch looks good to me.
Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy


>   int ret;
> 
> - ret = intel_backlight_device_register(intel_connector);
> + ret = intel_panel_register(connector);
>   if (ret)
>   goto err;
> 
>   if (i915_inject_probe_failure(i915)) {
>   ret = -EFAULT;
> - goto err_backlight;
> + goto err_panel;
>   }
> 
> - intel_connector_debugfs_add(intel_connector);
> + intel_connector_debugfs_add(connector);
> 
>   return 0;
> 
> -err_backlight:
> - intel_backlight_device_unregister(intel_connector);
> +err_panel:
> + intel_panel_unregister(connector);
>  err:
>   return ret;
>  }
> 
> -void intel_connector_unregister(struct drm_connector *connector)
> +void intel_connector_unregister(struct drm_connector *_connector)
>  {
> - struct intel_connector *intel_connector =
> to_intel_connector(connector);
> + struct intel_connector *connector = to_intel_connector(_connector);
> 
> - intel_backlight_device_unregister(intel_connector);
> + intel_panel_unregister(connector);
>  }
> 
>  void intel_connector_attach_encoder(struct intel_connector *connector, diff 
> --
> git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index f5c972880391..5ae302bee191 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -462,3 +462,13 @@ void intel_panel_fini(struct intel_connector
> *connector)
>   drm_mode_destroy(connector->base.dev, fixed_mode);
>   }
>  }
> +
> +int intel_panel_register(struct intel_connector *connector) {
> + return intel_backlight_device_register(connector);
> +}
> +
> +void intel_panel_unregister(struct intel_connector *connector) {
> + intel_backlight_device_unregister(connector);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.h
> b/drivers/gpu/drm/i915/display/intel_panel.h
> index b60d12322e5d..3d592a4404f3 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.h
> +++ b/drivers/gpu/drm/i915/display/intel_panel.h
> @@ -23,6 +23,8 @@ void intel_panel_init_alloc(struct intel_connector
> *connector);  int intel_panel_init(struct intel_connector *connector,
>const struct drm_edid *fixed_edid);  void
> intel_panel_fini(struct intel_connector *connector);
> +int intel_panel_register(struct intel_connector *connector); void
> +intel_panel_unregister(struct intel_connector *connector);
>  enum drm_connector_status
>  intel_panel_detect(struct drm_connector *connector, bool force);  bool
> intel_panel_use_ssc(struct intel_display *display);
> --
> 2.39.5

RE: [PATCH 3/4] drm/i915/panel: register drm_panel and call prepare/unprepare for ICL+ DSI

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Friday, June 6, 2025 2:35 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; Heikki
> Krogerus ; Wysocki, Rafael J
> ; Lee, Shawn C ; Yang,
> Simon1 ; Doug Anderson ;
> Maxime Ripard ; Nikula, Jani 
> Subject: [PATCH 3/4] drm/i915/panel: register drm_panel and call
> prepare/unprepare for ICL+ DSI
> 
> Allocate and register a drm_panel so that drm_panel_followers can find the
> panel. Pass the drm_connector::kdev device to drm_panel allocation for
> matching. That's only available after drm_sysfs_connector_add(), so we need to
> postpone the drm_panel allocation until .late_register() hook.
> 
> The drm_panel framework is moving towards devm_drm_panel_alloc(). It
> requires a wrapper struct, and struct intel_panel would be the natural
> candidate. However, we can't postpone its allocation until .late_register(), 
> so we
> have to use __devm_drm_panel_alloc() directly for now.
> 
> Call the drm_panel_prepare() and drm_panel_unprepare() functions for
> ICL+ DSI, so that followers get notified of the panel power state
> changes. This can later be expanded to VLV+ DSI and eDP.
> 
> Cc: Maxime Ripard 
> Cc: Heikki Krogerus 
> Cc: Lee Shawn C 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c|  4 +
>  .../drm/i915/display/intel_display_types.h|  4 +
>  drivers/gpu/drm/i915/display/intel_panel.c| 82 ++-
>  drivers/gpu/drm/i915/display/intel_panel.h|  4 +
>  4 files changed, 93 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 026361354e6f..81410b3aed51 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1276,6 +1276,8 @@ static void gen11_dsi_enable(struct
> intel_atomic_state *state,
>   intel_backlight_enable(crtc_state, conn_state);
>   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
> 
> + intel_panel_prepare(crtc_state, conn_state);
> +
Should this be done before the intel_backlight_enable() ?

>   intel_crtc_vblank_on(crtc_state);
>  }
> 
> @@ -1409,6 +1411,8 @@ static void gen11_dsi_disable(struct
> intel_atomic_state *state,  {
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> 
> + intel_panel_unprepare(old_conn_state);
> +
>   /* step1: turn off backlight */
>   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>   intel_backlight_disable(old_conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ed4d743fc7c5..30c7315fc25e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include  @@ -384,6 +385,9 @@ struct
> intel_vbt_panel_data {  };
> 
>  struct intel_panel {
> + /* Simple drm_panel */
> + struct drm_panel *base;
> +
>   /* Fixed EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
>   const struct drm_edid *fixed_edid;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 5ae302bee191..b1d549e6cf53 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -463,12 +463,92 @@ void intel_panel_fini(struct intel_connector
> *connector)
>   }
>  }
> 
> +const struct drm_panel_funcs dummy_panel_funcs = { };
> +
>  int intel_panel_register(struct intel_connector *connector)  {
> - return intel_backlight_device_register(connector);
> + struct intel_display *display = to_intel_display(connector);
> + struct intel_panel *panel = &connector->panel;
> + int ret;
> +
> + ret = intel_backlight_device_register(connector);
> + if (ret)
> + return ret;
> +
Do we need to assign the backlight_device created in 
intel_backlight_device_register() to the element backlight in struct drm_panel, 
so as to use the drm_panel framework for panel backlight control?

Thanks and Regards,
Arun R Murthy
---

> + if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI)
> {
> + struct device *dev = connector->base.kdev;
> + struct drm_panel *base;
> +
> + /* Sanity check. */
> + if (drm_WARN_ON(display->drm, !dev))
> + goto out;
> +
> + /*
> +  * We need drm_connector::kdev for allocating the panel, to
> make
> +  * drm_panel_add_follower() lookups work. The kdev is
> +  * initialized in drm_sysfs_connector_add(), just before the
> +  * connector .late_register() hooks. So we can't allocate the
> +  * panel at conn

[PATCH] drm: omapdrm: reduce clang stack usage

From: Arnd Bergmann 

The thread sanitizer makes the stack usage explode from extra variable
spills in dispc_runtime_resume:

drivers/gpu/drm/omapdrm/dss/dispc.c:4735:27: error: stack frame size (1824) 
exceeds limit (1280) in 'dispc_runtime_resume' [-Werror,-Wframe-larger-than]

I could not figure out what exactly is going on here, but I see that
whenever dispc_restore_context() is not inlined, that function
and its caller shrink below 900 bytes combined of stack usage.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 533f70e8a4a6..cf055815077c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -524,7 +524,7 @@ static void dispc_save_context(struct dispc_device *dispc)
DSSDBG("context saved\n");
 }
 
-static void dispc_restore_context(struct dispc_device *dispc)
+static noinline_for_stack void dispc_restore_context(struct dispc_device 
*dispc)
 {
int i, j;
 
-- 
2.39.5

[PATCH v2] drm/panel: use fwnode based lookups for panel followers

Use firmware node based lookups for panel followers, to make the code
independent of OF and device tree, and make it work also for ACPI with
an appropriate _DSD.

ASL example:

Package (0x02)
{
"panel", \_SB.PCI0.GFX0.LCD0
}

v2:
- Update comments (Doug, Arun)
- s/IS_ERR_OR_NULL/IS_ERR/ (Doug)

Suggested-by: Heikki Krogerus 
Cc: Neil Armstrong 
Cc: Jessica Zhang 
Cc: Maxime Ripard 
Cc: Doug Anderson 
Cc: Lee Shawn C 
Tested-by: Lee Shawn C 
Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 
Reviewed-by: Arun R Murthy 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_panel.c | 42 -
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index fee65dc65979..805b4151ccef 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -473,17 +473,40 @@ int of_drm_get_panel_orientation(const struct device_node 
*np,
 EXPORT_SYMBOL(of_drm_get_panel_orientation);
 #endif
 
-static struct drm_panel *of_find_panel(struct device *follower_dev)
+/* Find panel by fwnode. This should be identical to of_drm_find_panel(). */
+static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle 
*fwnode)
 {
-   struct device_node *panel_np;
struct drm_panel *panel;
 
-   panel_np = of_parse_phandle(follower_dev->of_node, "panel", 0);
-   if (!panel_np)
+   if (!fwnode_device_is_available(fwnode))
return ERR_PTR(-ENODEV);
 
-   panel = of_drm_find_panel(panel_np);
-   of_node_put(panel_np);
+   mutex_lock(&panel_lock);
+
+   list_for_each_entry(panel, &panel_list, list) {
+   if (dev_fwnode(panel->dev) == fwnode) {
+   mutex_unlock(&panel_lock);
+   return panel;
+   }
+   }
+
+   mutex_unlock(&panel_lock);
+
+   return ERR_PTR(-EPROBE_DEFER);
+}
+
+/* Find panel by follower device */
+static struct drm_panel *find_panel_by_dev(struct device *follower_dev)
+{
+   struct fwnode_handle *fwnode;
+   struct drm_panel *panel;
+
+   fwnode = fwnode_find_reference(dev_fwnode(follower_dev), "panel", 0);
+   if (IS_ERR(fwnode))
+   return ERR_PTR(-ENODEV);
+
+   panel = find_panel_by_fwnode(fwnode);
+   fwnode_handle_put(fwnode);
 
return panel;
 }
@@ -494,7 +517,7 @@ static struct drm_panel *of_find_panel(struct device 
*follower_dev)
  *
  * This checks to see if a device needs to be power sequenced together with
  * a panel using the panel follower API.
- * At the moment panels can only be followed on device tree enabled systems.
+ *
  * The "panel" property of the follower points to the panel to be followed.
  *
  * Return: true if we should be power sequenced with a panel; false otherwise.
@@ -506,7 +529,7 @@ bool drm_is_panel_follower(struct device *dev)
 * don't bother trying to parse it here. We just need to know if the
 * property is there.
 */
-   return of_property_present(dev->of_node, "panel");
+   return device_property_present(dev, "panel");
 }
 EXPORT_SYMBOL(drm_is_panel_follower);
 
@@ -523,7 +546,6 @@ EXPORT_SYMBOL(drm_is_panel_follower);
  * If a follower is added to a panel that's already been turned on, the
  * follower's prepare callback is called right away.
  *
- * At the moment panels can only be followed on device tree enabled systems.
  * The "panel" property of the follower points to the panel to be followed.
  *
  * Return: 0 or an error code. Note that -ENODEV means that we detected that
@@ -536,7 +558,7 @@ int drm_panel_add_follower(struct device *follower_dev,
struct drm_panel *panel;
int ret;
 
-   panel = of_find_panel(follower_dev);
+   panel = find_panel_by_dev(follower_dev);
if (IS_ERR(panel))
return PTR_ERR(panel);
 
-- 
2.39.5

Re: [PATCH 1/4] drm/panel: use fwnode based lookups for panel followers

On Mon, 09 Jun 2025, Doug Anderson  wrote:
> Hi,
>
> On Fri, Jun 6, 2025 at 2:06 AM Jani Nikula  wrote:
>>
>> Use firmware node based lookups for panel followers, to make the code
>> independent of OF and device tree, and make it work also for ACPI with
>> an appropriate _DSD.
>>
>> ASL example:
>>
>> Package (0x02)
>> {
>> "panel", \_SB.PCI0.GFX0.LCD0
>> }
>>
>> Suggested-by: Heikki Krogerus 
>> Cc: Neil Armstrong 
>> Cc: Jessica Zhang 
>> Cc: Maxime Ripard 
>> Cc: Doug Anderson 
>> Cc: Lee Shawn C 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_panel.c | 39 +
>>  1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
>> index fee65dc65979..3eb0a615f7a9 100644
>> --- a/drivers/gpu/drm/drm_panel.c
>> +++ b/drivers/gpu/drm/drm_panel.c
>> @@ -473,17 +473,40 @@ int of_drm_get_panel_orientation(const struct 
>> device_node *np,
>>  EXPORT_SYMBOL(of_drm_get_panel_orientation);
>>  #endif
>>
>> -static struct drm_panel *of_find_panel(struct device *follower_dev)
>> +/* Find panel by fwnode */
>> +static struct drm_panel *find_panel_by_fwnode(const struct fwnode_handle 
>> *fwnode)
>
> nit: It might be worth adding a comment that says it should be
> identical to of_drm_find_panel() since that has a much richer
> kerneldoc that talks about the corner cases.

Agreed.

I'm actually wondering if it would be possible to implement
of_drm_find_panel() like this (as a follow-up change):

struct drm_panel *of_drm_find_panel(const struct device_node *np)
{
const struct fwnode_handle *fwnode = of_fwnode_handle(np);

return find_panel_by_fwnode(fwnode);
}

But I'd rather leave that out for now.

>
>>  {
>> -   struct device_node *panel_np;
>> struct drm_panel *panel;
>>
>> -   panel_np = of_parse_phandle(follower_dev->of_node, "panel", 0);
>> -   if (!panel_np)
>> +   if (!fwnode_device_is_available(fwnode))
>> return ERR_PTR(-ENODEV);
>>
>> -   panel = of_drm_find_panel(panel_np);
>> -   of_node_put(panel_np);
>> +   mutex_lock(&panel_lock);
>> +
>> +   list_for_each_entry(panel, &panel_list, list) {
>> +   if (dev_fwnode(panel->dev) == fwnode) {
>> +   mutex_unlock(&panel_lock);
>> +   return panel;
>> +   }
>> +   }
>> +
>> +   mutex_unlock(&panel_lock);
>> +
>> +   return ERR_PTR(-EPROBE_DEFER);
>> +}
>> +
>> +/* Find panel by follower device */
>> +static struct drm_panel *find_panel_by_dev(struct device *follower_dev)
>> +{
>> +   struct fwnode_handle *fwnode;
>> +   struct drm_panel *panel;
>> +
>> +   fwnode = fwnode_find_reference(dev_fwnode(follower_dev), "panel", 0);
>> +   if (IS_ERR_OR_NULL(fwnode))
>
> nit: why IS_ERR_OR_NULL() instead of IS_ERR()? The kerneldoc for
> fwnode_find_reference() doesn't mention anything about it returning a
> NULL value in any cases...

Will fix.

> Other than the nits, this looks reasonable to me.
>
> Reviewed-by: Douglas Anderson 
>
> I no longer have any easy access to hardware where panel-follower is
> truly necessary, but I can at least see the panel-follower calls
> getting made on sc7180-trogdor-lazor, so the of->fwnode conversion
> stuff must be working.
>
> Tested-by: Douglas Anderson 

Thanks for the review and testing, much appreciated!

BR,
Jani.


-- 
Jani Nikula, Intel

[PATCH] fbtft: reduce stack usage

From: Arnd Bergmann 

The use of vararg function pointers combined with a huge number of
arguments causes some configurations to exceed the stack size warning
limit:

drivers/staging/fbtft/fbtft-core.c:863:12: error: stack frame size (1512) 
exceeds limit (1280) in 'fbtft_init_display_from_property' 
[-Werror,-Wframe-larger-than]

drivers/staging/fbtft/fb_ssd1331.c:131:30: error: stack frame size (1392) 
exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
  ^
drivers/staging/fbtft/fb_ssd1351.c:120:30: error: stack frame size (1392) 
exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]

Move the varargs handling into a separate noinline function so each
individual function stays below the limit. A better approach might be to
replace the varargs function with one that takes an array of arguments,
but that would be a much larger rework of the other callers.

Signed-off-by: Arnd Bergmann 
---
 drivers/staging/fbtft/fb_ssd1331.c | 36 --
 drivers/staging/fbtft/fb_ssd1351.c | 42 -
 drivers/staging/fbtft/fbtft-core.c | 59 +-
 3 files changed, 73 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/fbtft/fb_ssd1331.c 
b/drivers/staging/fbtft/fb_ssd1331.c
index 06b7056d6c71..f43ee3249175 100644
--- a/drivers/staging/fbtft/fb_ssd1331.c
+++ b/drivers/staging/fbtft/fb_ssd1331.c
@@ -107,6 +107,28 @@ static void write_reg8_bus8(struct fbtft_par *par, int 
len, ...)
va_end(args);
 }
 
+static noinline_for_stack void write_gamma_reg(struct fbtft_par *par,
+  u32 gamma[63])
+{
+   write_reg(par, 0xB8,
+ gamma[0],  gamma[1],  gamma[2],  gamma[3],
+ gamma[4],  gamma[5],  gamma[6],  gamma[7],
+ gamma[8],  gamma[9],  gamma[10], gamma[11],
+ gamma[12], gamma[13], gamma[14], gamma[15],
+ gamma[16], gamma[17], gamma[18], gamma[19],
+ gamma[20], gamma[21], gamma[22], gamma[23],
+ gamma[24], gamma[25], gamma[26], gamma[27],
+ gamma[28], gamma[29], gamma[30], gamma[31],
+ gamma[32], gamma[33], gamma[34], gamma[35],
+ gamma[36], gamma[37], gamma[38], gamma[39],
+ gamma[40], gamma[41], gamma[42], gamma[43],
+ gamma[44], gamma[45], gamma[46], gamma[47],
+ gamma[48], gamma[49], gamma[50], gamma[51],
+ gamma[52], gamma[53], gamma[54], gamma[55],
+ gamma[56], gamma[57], gamma[58], gamma[59],
+ gamma[60], gamma[61], gamma[62]);
+}
+
 /*
  * Grayscale Lookup Table
  * GS1 - GS63
@@ -130,7 +152,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
  */
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
-   unsigned long tmp[GAMMA_NUM * GAMMA_LEN];
+   u32 tmp[GAMMA_NUM * GAMMA_LEN];
int i, acc = 0;
 
for (i = 0; i < 63; i++) {
@@ -150,17 +172,7 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
}
}
 
-   write_reg(par, 0xB8,
- tmp[0], tmp[1], tmp[2], tmp[3], tmp[4], tmp[5], tmp[6],
- tmp[7], tmp[8], tmp[9], tmp[10], tmp[11], tmp[12], tmp[13],
- tmp[14], tmp[15], tmp[16], tmp[17], tmp[18], tmp[19], tmp[20],
- tmp[21], tmp[22], tmp[23], tmp[24], tmp[25], tmp[26], tmp[27],
- tmp[28], tmp[29], tmp[30], tmp[31], tmp[32], tmp[33], tmp[34],
- tmp[35], tmp[36], tmp[37], tmp[38], tmp[39], tmp[40], tmp[41],
- tmp[42], tmp[43], tmp[44], tmp[45], tmp[46], tmp[47], tmp[48],
- tmp[49], tmp[50], tmp[51], tmp[52], tmp[53], tmp[54], tmp[55],
- tmp[56], tmp[57], tmp[58], tmp[59], tmp[60], tmp[61],
- tmp[62]);
+   write_gamma_reg(par, tmp);
 
return 0;
 }
diff --git a/drivers/staging/fbtft/fb_ssd1351.c 
b/drivers/staging/fbtft/fb_ssd1351.c
index 6736b09b2f45..eb8bee6993c3 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -96,6 +96,28 @@ static int set_var(struct fbtft_par *par)
return 0;
 }
 
+static noinline_for_stack void write_gamma_reg(struct fbtft_par *par,
+  u32 gamma[63])
+{
+   write_reg(par, 0xB8,
+ gamma[0],  gamma[1],  gamma[2],  gamma[3],
+ gamma[4],  gamma[5],  gamma[6],  gamma[7],
+ gamma[8],  gamma[9],  gamma[10], gamma[11],
+ gamma[12], gamma[13], gamma[14], gamma[15],
+ gamma[16], gamma[17], gamma[18], gamma[19],
+ gamma[20], gamma[21], gamma[22], gamma[23],
+ gamma[24], gamma[25], gamma[26], gamma[27],
+ gamma[28], gamma[29], gamma[30], gamma[31],
+ gamma[32], gamma[33], gamma[34], gamma[35],
+ gamma[36], gamma[37],

[PATCH] drm/radeon: reduce stack frame size for radeon_cs_ioctl

From: Arnd Bergmann 

Clang inlines radeon_cs_parser_relocs() into radeon_cs_ioctl(), and
since both of these use a lot of stack space, the sum of them can
make it exceed a limit of 1280 bytes:

drivers/gpu/drm/radeon/radeon_cs.c:669:5: error: stack frame size (1328) 
exceeds limit (1280) in 'radeon_cs_ioctl' [-Werror,-Wframe-larger-than]
  669 | int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp)
  | ^

Mark radeon_cs_parser_relocs as noinline_for_stack, so clang and gcc
both behave in a consistent way. Calling into radeon_cs_parser_relocs()
still uses a lot of stack space here, but this is not any worse than it
already was, and the other code paths are better now.

Fixes: c9b76548899c ("drm/radeon: validate relocations in the order determined 
by userspace v3")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index b8e6202f1d5b..220a9b107b15 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -78,7 +78,7 @@ static void radeon_cs_buckets_get_list(struct 
radeon_cs_buckets *b,
}
 }
 
-static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
+static noinline_for_stack int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)
 {
struct radeon_cs_chunk *chunk;
struct radeon_cs_buckets buckets;
-- 
2.39.5

[PATCH] drm/test: reduce stack size in drm_exec_test

From: Arnd Bergmann 

test_prepare_array() is one of the functions that uses more than
a kilobyte of stack on 64-bit machines, though it stays under
the usual warning limit of 2KB:

drivers/gpu/drm/tests/drm_exec_test.c: In function 'test_prepare_array':
drivers/gpu/drm/tests/drm_exec_test.c:171:1: error: the frame size of 1304 
bytes is larger than 1280 bytes [-Werror=frame-larger-than=]

In order to eventually lower that limit, change the two large
drm_gem_object objects to be statically allocated. This works here
because the tests are always called sequentially, and it is simpler than
using kzalloc().

Fixes: 9710631cc8f3 ("drm: add drm_exec selftests v4")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tests/drm_exec_test.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tests/drm_exec_test.c 
b/drivers/gpu/drm/tests/drm_exec_test.c
index d6c4dd1194a0..f2ac06a07707 100644
--- a/drivers/gpu/drm/tests/drm_exec_test.c
+++ b/drivers/gpu/drm/tests/drm_exec_test.c
@@ -18,6 +18,8 @@
 
 #include "../lib/drm_random.h"
 
+static struct drm_gem_object gobj, gobj2;
+
 struct drm_exec_priv {
struct device *dev;
struct drm_device *drm;
@@ -54,7 +56,6 @@ static void sanitycheck(struct kunit *test)
 static void test_lock(struct kunit *test)
 {
struct drm_exec_priv *priv = test->priv;
-   struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
 
@@ -74,7 +75,6 @@ static void test_lock(struct kunit *test)
 static void test_lock_unlock(struct kunit *test)
 {
struct drm_exec_priv *priv = test->priv;
-   struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
 
@@ -101,7 +101,6 @@ static void test_lock_unlock(struct kunit *test)
 static void test_duplicates(struct kunit *test)
 {
struct drm_exec_priv *priv = test->priv;
-   struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
 
@@ -128,7 +127,6 @@ static void test_duplicates(struct kunit *test)
 static void test_prepare(struct kunit *test)
 {
struct drm_exec_priv *priv = test->priv;
-   struct drm_gem_object gobj = { };
struct drm_exec exec;
int ret;
 
@@ -150,13 +148,11 @@ static void test_prepare(struct kunit *test)
 static void test_prepare_array(struct kunit *test)
 {
struct drm_exec_priv *priv = test->priv;
-   struct drm_gem_object gobj1 = { };
-   struct drm_gem_object gobj2 = { };
-   struct drm_gem_object *array[] = { &gobj1, &gobj2 };
+   struct drm_gem_object *array[] = { &gobj, &gobj2 };
struct drm_exec exec;
int ret;
 
-   drm_gem_private_object_init(priv->drm, &gobj1, PAGE_SIZE);
+   drm_gem_private_object_init(priv->drm, &gobj, PAGE_SIZE);
drm_gem_private_object_init(priv->drm, &gobj2, PAGE_SIZE);
 
drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
@@ -166,7 +162,7 @@ static void test_prepare_array(struct kunit *test)
KUNIT_EXPECT_EQ(test, ret, 0);
drm_exec_fini(&exec);
 
-   drm_gem_private_object_fini(&gobj1);
+   drm_gem_private_object_fini(&gobj);
drm_gem_private_object_fini(&gobj2);
 }
 
-- 
2.39.5

Re: [PATCH 0/3] NVIDIA Tegra210 NVJPG support

2025-06-10 Thread Mikko Perttunen


On 6/10/25 6:05 PM, Thierry Reding wrote:

On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:

Hello,

This series adds support for the NVJPG hardware accelerator found in the
Tegra210 SoC.

The kernel driver is essentially a copy of the NVDEC driver as both
engines are Falcon-based.

For the userspace part I have written a Mesa Gallium backend [1] that,
while still very much experimental, works in decoding images with VA-API.

I have been using ffmpeg to call VA-API with the following command:

ffmpeg -v verbose -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 -i 
 -pix_fmt bgra -f fbdev /dev/fb0

which decodes  and shows the result in the framebuffer.

The firmware for the engine can be obtained from a Linux for Tegra
distribution.


By the way, have you tried running this on anything newer than Tegra210?
Given your progress on this, we can probably start thinking about
submitting the binaries to linux-firmware.


FWIW, the impression I have is that NVJPG is basically unchanged all the 
way to Tegra234. So if we add stream ID support and the firmwares, it'll 
probably just work. Tegra234 has the quirk that it has two instances of 
NVJPG -- these have to be distinguished by their different class IDs. 
But we should go ahead with the T210 support first.





Due to the way the Gallium implementation works for Tegra
the GPU also needs to be enabled.


I wonder if maybe we can get rid of this requirement. While it's
certainly nice to have the GPU enabled, there may be cases where using
only the other engines may be advantageous. Originally when I had worked
on VIC, I was looking at how it could be used for compositing without
getting the GPU involved. That's something that Android devices tend(ed)
to do because of the power savings that come with it.

Anyway, not a big deal, depending on the GPU for now is fine.

Thierry

Re: [PATCH] rust: module: remove deprecated author key

2025-06-10 Thread Greg KH

On Mon, Jun 09, 2025 at 07:47:55PM +0200, Danilo Krummrich wrote:
> On 09.06.2025 19:39, Miguel Ojeda wrote:
> > On Mon, Jun 9, 2025 at 2:22 PM Guilherme Giacomo Simoes
> >  wrote:
> >>
> >> Now that all in-tree modules have migrated to `authors`, remove:
> > 
> > Nit: I would have said "most modules", since we have new/remaining
> > ones (no need for a new version for this).
> > 
> > I think this patch is OK -- we could wait to do this more cycles, but
> > if we are doing it, then probably the sooner we do it, the simpler.
> > 
> >>  drivers/cpufreq/rcpufreq_dt.rs| 2 +-
> >>  drivers/gpu/drm/nova/nova.rs  | 2 +-
> >>  drivers/gpu/nova-core/nova_core.rs| 2 +-
> >>  rust/kernel/firmware.rs   | 2 +-
> >>  samples/rust/rust_configfs.rs | 2 +-
> >>  samples/rust/rust_driver_auxiliary.rs | 2 +-
> > 
> > Andreas, Danilo, Greg, Viresh: if nobody is against it, I will apply
> > it this cycle. Acked-by's for your bits appreciated, of course.
> 
> Acked-by: Danilo Krummrich 

Acked-by: Greg Kroah-Hartman

Re: [PATCH] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/V2N SoC

2025-06-10 Thread Laurent Pinchart

Hi Prabhakar,

Thank you for the patch.

On Tue, Jun 10, 2025 at 12:19:05AM +0100, Prabhakar wrote:
> From: Lad Prabhakar 
> 
> Document support for the DU IP found on the Renesas RZ/V2N (R9A09G056) SoC.
> The DU IP is functionally identical to that on the RZ/V2H(P) SoC, so no
> driver changes are needed. The existing `renesas,r9a09g057-du` compatible
> will be used as a fallback for the RZ/V2N SoC.
> 
> Signed-off-by: Lad Prabhakar 

Assuming this gets merged after
https://lore.kernel.org/r/20250530165906.411144-2-prabhakar.mahadev-lad...@bp.renesas.com
("[PATCH v6 01/12] dt-bindings: display: renesas, rzg2l-du: Add support
for RZ/V2H(P) SoC"),

Reviewed-by: Laurent Pinchart 

> ---
>  .../devicetree/bindings/display/renesas,rzg2l-du.yaml  | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml 
> b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> index 1e32d14b6edb..2cc66dcef870 100644
> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -25,6 +25,9 @@ properties:
>- enum:
>- renesas,r9a07g054-du# RZ/V2L
>- const: renesas,r9a07g044-du # RZ/G2L fallback
> +  - items:
> +  - const: renesas,r9a09g056-du # RZ/V2N
> +  - const: renesas,r9a09g057-du # RZ/V2H(P) fallback
>  
>reg:
>  maxItems: 1

-- 
Regards,

Laurent Pinchart

Re: [PATCH] rust: module: remove deprecated author key

2025-06-10 Thread Miguel Ojeda

On Tue, Jun 10, 2025 at 10:58 AM Benno Lossin  wrote:
>
> Unrelated to this change, I think we should add email addresses to
> people in authors. Possibly enforce it by scanning each author element
> and checking if there is an email address.

Sounds good to me, but I am not sure if it is possible in all cases.

At least looking at C, there are company names too.

I even saw a URL...

Cheers,
Miguel

Re: [PATCH] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/V2N SoC

2025-06-10 Thread Lad, Prabhakar

Hi Laurent,

Thank you for the review.

On Tue, Jun 10, 2025 at 10:58 AM Laurent Pinchart
 wrote:
>
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Tue, Jun 10, 2025 at 12:19:05AM +0100, Prabhakar wrote:
> > From: Lad Prabhakar 
> >
> > Document support for the DU IP found on the Renesas RZ/V2N (R9A09G056) SoC.
> > The DU IP is functionally identical to that on the RZ/V2H(P) SoC, so no
> > driver changes are needed. The existing `renesas,r9a09g057-du` compatible
> > will be used as a fallback for the RZ/V2N SoC.
> >
> > Signed-off-by: Lad Prabhakar 
>
> Assuming this gets merged after
> https://lore.kernel.org/r/20250530165906.411144-2-prabhakar.mahadev-lad...@bp.renesas.com
> ("[PATCH v6 01/12] dt-bindings: display: renesas, rzg2l-du: Add support
> for RZ/V2H(P) SoC"),
>
Above patch is already merged into drm-misc.

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ed6a6d63513ee5199841c0a0dc2772ad944e63ee

Cheers,
Prabhakar

Re: [PATCH] rust: module: remove deprecated author key

2025-06-10 Thread Benno Lossin

On Tue Jun 10, 2025 at 12:03 PM CEST, Miguel Ojeda wrote:
> On Tue, Jun 10, 2025 at 10:58 AM Benno Lossin  wrote:
>>
>> Unrelated to this change, I think we should add email addresses to
>> people in authors. Possibly enforce it by scanning each author element
>> and checking if there is an email address.
>
> Sounds good to me, but I am not sure if it is possible in all cases.
>
> At least looking at C, there are company names too.
>
> I even saw a URL...

Hmm, I guess a checkpatch lint fits better then?

---
Cheers,
Benno

Re: [PATCH v4 7/7] drm/panthor: Add support for Mali-Gx20 and Mali-Gx25 GPUs

2025-06-10 Thread Chia-I Wu

On Mon, Jun 2, 2025 at 7:34 AM Karunika Choo  wrote:
>
> Mali-Gx20 and Mali-Gx25 deprecates the use of FLUSH_MEM and FLUSH_PT
> MMU_AS commands in favour of cache maintenance via
> GPU_COMMAND's FLUSH_CACHES and FLUSH_PA_RANGE.
>
> They also introduce the following registers:
> - GPU_COMMAND_ARG0~1
> - SHADER_PWRFEATURES
> - AMBA_FEATURES
> - AMBA_ENABLE
>
> This patch enables FLUSH_CACHES for both families of GPUs via the
> PANTHOR_HW_FEATURE_GPU_CTRL_CACHE_FLUSH bit until FLUSH_PA_RANGE support
> is added. It also adds the aforementioned register definitions and
> firmware binary support for arch 12.8 and 13.8.

> diff --git a/drivers/gpu/drm/panthor/panthor_regs.h 
> b/drivers/gpu/drm/panthor/panthor_regs.h
> index 4eaa2b612756..8e01440f8743 100644
> --- a/drivers/gpu/drm/panthor/panthor_regs.h
> +++ b/drivers/gpu/drm/panthor/panthor_regs.h
> @@ -89,6 +89,8 @@
>
>  #define GPU_DOORBELL_FEATURES  0xC0
>
> +#define GPU_COMMAND_ARG(n) (0xD0 + ((n) * 8))
> +
>  #define GPU_SHADER_PRESENT 0x100
>  #define GPU_TILER_PRESENT  0x110
>  #define GPU_L2_PRESENT 0x120
> @@ -98,6 +100,8 @@
>  #define L2_READY   0x160
>
>  #define SHADER_PWRON   0x180
> +#define SHADER_PWRFEATURES 0x188
> +#define   SHADER_PWRFEATURES_RAY_TRACING_UNIT  BIT(0)
>  #define TILER_PWRON0x190
>  #define L2_PWRON   0x1A0
>
> @@ -125,6 +129,13 @@
>  #define   GPU_COHERENCY_ACE1
>  #define   GPU_COHERENCY_NONE   31
>
> +#define AMBA_FEATURES  0x300
> +#define   AMBA_FEATURES_ACE_LITE   BIT(0)
> +#define   AMBA_FEATURES_ACEBIT(1)
> +#define   AMBA_FEATURES_SHAREABLE_CACHE_SUPPORTBIT(5)
> +
> +#define AMBA_ENABLE0x304
We still use GPU_COHERENCY_FEATURES / GPU_COHERENCY_PROTOCOL even on
v12 and v13.  I suppose they are compatible with AMBA_FEATURES /
AMBA_ENABLE to some degree?  We should unify them.

[PATCH] drm/bridge: it6505: select REGMAP_I2C

2025-06-10 Thread Chia-I Wu

Fix

  aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/ite-it6505.o: in function 
`it6505_i2c_probe':
  ite-it6505.c:(.text+0x754): undefined reference to `__devm_regmap_init_i2c'

Signed-off-by: Chia-I Wu 
---
 drivers/gpu/drm/bridge/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b9e0ca85226a6..a6d6e62071a0e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -122,6 +122,7 @@ config DRM_ITE_IT6505
select EXTCON
select CRYPTO
select CRYPTO_HASH
+   select REGMAP_I2C
help
  ITE IT6505 DisplayPort bridge chip driver.
 
-- 
2.50.0.rc0.642.g800a2b-goog

Re: [PATCH v4 6/7] drm/panthor: Support GPU_CONTROL cache flush based on feature bit

2025-06-10 Thread Chia-I Wu

On Mon, Jun 2, 2025 at 7:42 AM Karunika Choo  wrote:
>
> As the FLUSH_MEM and FLUSH_PT commands are deprecated in GPUs from
> Mali-Gx20 onwards, this patch adds support for performing cache
> maintenance via the FLUSH_CACHES command in GPU_CONTROL, in place of
> FLUSH_MEM and FLUSH_PT based on PANTHOR_HW_FEATURE_GPU_CTRL_CACHE_FLUSH
> feature bit.
>
> This patch also enables cache maintenance via GPU_CONTROL for Mali-Gx10
> and Mali-Gx15 GPUs for consistency.
>
> Signed-off-by: Karunika Choo 
> ---
>  drivers/gpu/drm/panthor/panthor_hw.c  |  6 +
>  drivers/gpu/drm/panthor/panthor_hw.h  |  6 +
>  drivers/gpu/drm/panthor/panthor_mmu.c | 35 +++
>  3 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_hw.c 
> b/drivers/gpu/drm/panthor/panthor_hw.c
> index f5127a4b02dc..5ec9d7f28368 100644
> --- a/drivers/gpu/drm/panthor/panthor_hw.c
> +++ b/drivers/gpu/drm/panthor/panthor_hw.c
> @@ -99,9 +99,15 @@ static void panthor_hw_info_init(struct panthor_device 
> *ptdev)
>  static struct panthor_hw panthor_hw_devices[] = {
> {
> .arch_major = 10,
> +   .features = {
> +   BIT(PANTHOR_HW_FEATURE_GPU_CTRL_CACHE_FLUSH)
> +   },
> },
> {
> .arch_major = 11,
> +   .features = {
> +   BIT(PANTHOR_HW_FEATURE_GPU_CTRL_CACHE_FLUSH)
> +   },
> },
>  };
Are there going to be major archs which do not support
PANTHOR_HW_FEATURE_GPU_CTRL_CACHE_FLUSH?  If not, we don't need the
feature bit.

Re: [PATCH v2 04/10] drm/xe/xe_late_bind_fw: Initialize late binding firmware

2025-06-10 Thread Daniele Ceraolo Spurio





On 6/6/2025 10:57 AM, Badal Nilawar wrote:

Search for late binding firmware binaries and populate the meta data of
firmware structures.

v2:
  - drm_err if firmware size is more than max pay load size (Daniele)
  - s/request_firmware/firmware_request_nowarn/ as firmware will
not be available for all possible cards (Daniele)

Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/xe/xe_device.c |  2 +
  drivers/gpu/drm/xe/xe_late_bind_fw.c   | 86 +-
  drivers/gpu/drm/xe/xe_late_bind_fw.h   |  1 +
  drivers/gpu/drm/xe/xe_late_bind_fw_types.h | 37 ++
  4 files changed, 124 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index e062ddaa83bb..df4b0e038a6d 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -891,6 +891,8 @@ int xe_device_probe(struct xe_device *xe)
  
  	xe_late_bind_init(&xe->late_bind);
  
+	xe_late_bind_fw_init(&xe->late_bind);


I still think this should be called from xe_late_bind_init(). You also 
need to check the return code.



+
err = xe_oa_init(xe);
if (err)
return err;
diff --git a/drivers/gpu/drm/xe/xe_late_bind_fw.c 
b/drivers/gpu/drm/xe/xe_late_bind_fw.c
index 22eb9b51b4ee..0231f3dcfc18 100644
--- a/drivers/gpu/drm/xe/xe_late_bind_fw.c
+++ b/drivers/gpu/drm/xe/xe_late_bind_fw.c
@@ -5,6 +5,7 @@
  
  #include 

  #include 
+#include 
  
  #include 

  #include 
@@ -13,13 +14,94 @@
  
  #include "xe_device.h"

  #include "xe_late_bind_fw.h"
+#include "xe_pcode.h"
+#include "xe_pcode_api.h"
  
-static struct xe_device *

-late_bind_to_xe(struct xe_late_bind *late_bind)


nit: might be worth modifying the previous patch to have this introduced 
in 1 line instead of modifying it here, to keep the diff cleaner.



+static const char * const fw_type_to_name[] = {
+   [CSC_LATE_BINDING_TYPE_FAN_CONTROL] = "fan_control",
+   };
+
+static struct xe_device *late_bind_to_xe(struct xe_late_bind *late_bind)
  {
return container_of(late_bind, struct xe_device, late_bind);
  }
  
+static int late_bind_fw_num_fans(struct xe_late_bind *late_bind)

+{
+   struct xe_device *xe = late_bind_to_xe(late_bind);
+   struct xe_tile *root_tile = xe_device_get_root_tile(xe);
+   u32 uval;
+
+   if (!xe_pcode_read(root_tile,
+  PCODE_MBOX(FAN_SPEED_CONTROL, FSC_READ_NUM_FANS, 0), 
&uval, NULL))
+   return uval;
+   else
+   return 0;
+}
+
+static int late_bind_fw_init(struct xe_late_bind *late_bind, u32 type)
+{
+   struct xe_device *xe = late_bind_to_xe(late_bind);
+   struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
+   struct xe_late_bind_fw *lb_fw;
+   const struct firmware *fw;
+   u32 num_fans;
+   int ret;
+
+   if (!late_bind->component_added)
+   return 0;
+
+   lb_fw = &late_bind->late_bind_fw;
+
+   lb_fw->type = type;


Should we validate that "type" is sane?


+   lb_fw->valid = false;
+
+   if (lb_fw->type == CSC_LATE_BINDING_TYPE_FAN_CONTROL) {
+   num_fans = late_bind_fw_num_fans(late_bind);
+   drm_dbg(&xe->drm, "Number of Fans: %d\n", num_fans);
+   if (!num_fans)
+   return 0;
+   }
+
+   lb_fw->flags = CSC_LATE_BINDING_FLAGS_IS_PERSISTENT;
+
+   snprintf(lb_fw->blob_path, sizeof(lb_fw->blob_path), 
"xe/%s_8086_%04x_%04x_%04x.bin",
+fw_type_to_name[type], pdev->device,
+pdev->subsystem_vendor, pdev->subsystem_device);
+
+   drm_dbg(&xe->drm, "Request late binding firmware %s\n", 
lb_fw->blob_path);
+   ret = firmware_request_nowarn(&fw, lb_fw->blob_path, xe->drm.dev);
+   if (ret) {
+   drm_dbg(&xe->drm, "Failed to request %s\n", lb_fw->blob_path);


This log still seems like an error when it's actually an ok outcome. 
Maybe change it to something like:


drm_dbg("%s late binding fw not available for current device", 
fw_type_to_name[type])



+   return 0;
+   }
+
+   if (fw->size > MAX_PAYLOAD_SIZE) {
+   lb_fw->payload_size = MAX_PAYLOAD_SIZE;


Why are we even setting payload_size here?


+   drm_err(&xe->drm, "Firmware %s size %zu is larger than max pay load 
size %u\n",
+   lb_fw->blob_path, fw->size, MAX_PAYLOAD_SIZE);
+   return 0;


Maybe add a comment to explain why we don't return an error here (if 
this was indeed on purpose).

Also, you're not calling release_firmware() when exiting from here.


+   }
+
+   lb_fw->payload_size = fw->size;
+
+   memcpy(lb_fw->payload, fw->data, lb_fw->payload_size);
+   release_firmware(fw);
+   lb_fw->valid = true;
+
+   return 0;


This function seems to return 0 from all return calls. Is that 
intentional? if so, just switch to void.



+}
+
+/**
+ * xe_mei_late_bind_fw_init() - Initialize late bind firmwar

Re: [PATCH v2 05/10] drm/xe/xe_late_bind_fw: Load late binding firmware

2025-06-10 Thread Daniele Ceraolo Spurio





On 6/6/2025 10:57 AM, Badal Nilawar wrote:

Load late binding firmware

v2:
  - s/EAGAIN/EBUSY/
  - Flush worker in suspend and driver unload (Daniele)

Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/xe/xe_late_bind_fw.c   | 121 -
  drivers/gpu/drm/xe/xe_late_bind_fw.h   |   1 +
  drivers/gpu/drm/xe/xe_late_bind_fw_types.h |   5 +
  3 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_late_bind_fw.c 
b/drivers/gpu/drm/xe/xe_late_bind_fw.c
index 0231f3dcfc18..7fe304c54374 100644
--- a/drivers/gpu/drm/xe/xe_late_bind_fw.c
+++ b/drivers/gpu/drm/xe/xe_late_bind_fw.c
@@ -16,6 +16,16 @@
  #include "xe_late_bind_fw.h"
  #include "xe_pcode.h"
  #include "xe_pcode_api.h"
+#include "xe_pm.h"
+
+/*
+ * The component should load quite quickly in most cases, but it could take
+ * a bit. Using a very big timeout just to cover the worst case scenario
+ */
+#define LB_INIT_TIMEOUT_MS 2
+
+#define LB_FW_LOAD_RETRY_MAXCOUNT 40
+#define LB_FW_LOAD_RETRY_PAUSE_MS 50


Are those retry values spec'd anywhere? For GSC we use those because the 
GSC specs say to retry in 50ms intervals for up to 2 secs to give time 
for the GSC to do proxy handling. Does it make sense to do the same in 
this case, given that there is no proxy involved?


  
  static const char * const fw_type_to_name[] = {

[CSC_LATE_BINDING_TYPE_FAN_CONTROL] = "fan_control",
@@ -39,6 +49,95 @@ static int late_bind_fw_num_fans(struct xe_late_bind 
*late_bind)
return 0;
  }
  
+static void xe_late_bind_wait_for_worker_completion(struct xe_late_bind *late_bind)

+{
+   struct xe_device *xe = late_bind_to_xe(late_bind);
+   struct xe_late_bind_fw *lbfw;
+
+   lbfw = &late_bind->late_bind_fw;
+   if (lbfw->valid && late_bind->wq) {
+   drm_dbg(&xe->drm, "Flush work: load %s firmware\n",
+   fw_type_to_name[lbfw->type]);
+   flush_work(&lbfw->work);
+   }
+}
+
+static void late_bind_work(struct work_struct *work)
+{
+   struct xe_late_bind_fw *lbfw = container_of(work, struct 
xe_late_bind_fw, work);
+   struct xe_late_bind *late_bind = container_of(lbfw, struct xe_late_bind,
+ late_bind_fw);
+   struct xe_device *xe = late_bind_to_xe(late_bind);
+   int retry = LB_FW_LOAD_RETRY_MAXCOUNT;
+   int ret;
+   int slept;
+
+   if (!late_bind->component_added)
+   return;
+
+   if (!lbfw->valid)
+   return;


The first check is redundant because lbfw->valid can't be true if 
late_bind->component_added is false with the current code.



+
+   /* we can queue this before the component is bound */
+   for (slept = 0; slept < LB_INIT_TIMEOUT_MS; slept += 100) {
+   if (late_bind->component.ops)
+   break;
+   msleep(100);
+   }
+
+   xe_pm_runtime_get(xe);
+   mutex_lock(&late_bind->mutex);
+
+   if (!late_bind->component.ops) {
+   drm_err(&xe->drm, "Late bind component not bound\n");
+   goto out;
+   }
+
+   drm_dbg(&xe->drm, "Load %s firmware\n", fw_type_to_name[lbfw->type]);
+
+   do {
+   ret = 
late_bind->component.ops->push_config(late_bind->component.mei_dev,
+   lbfw->type, 
lbfw->flags,
+   lbfw->payload, 
lbfw->payload_size);
+   if (!ret)
+   break;
+   msleep(LB_FW_LOAD_RETRY_PAUSE_MS);
+   } while (--retry && ret == -EBUSY);
+
+   if (ret)
+   drm_err(&xe->drm, "Load %s firmware failed with err %d\n",
+   fw_type_to_name[lbfw->type], ret);
+   else
+   drm_dbg(&xe->drm, "Load %s firmware successful\n",
+   fw_type_to_name[lbfw->type]);
+out:
+   mutex_unlock(&late_bind->mutex);
+   xe_pm_runtime_put(xe);
+}
+
+int xe_late_bind_fw_load(struct xe_late_bind *late_bind)
+{
+   struct xe_device *xe = late_bind_to_xe(late_bind);
+   struct xe_late_bind_fw *lbfw;
+
+   if (!late_bind->component_added)
+   return -EINVAL;
+
+   lbfw = &late_bind->late_bind_fw;
+   if (lbfw->valid) {
+   drm_dbg(&xe->drm, "Queue work: to load %s firmware\n",
+   fw_type_to_name[lbfw->type]);


This log seems a bit too specific, also given that you also have logs 
inside the work


Daniele


+   queue_work(late_bind->wq, &lbfw->work);
+   }
+
+   return 0;
+}
+
+/**
+ * late_bind_fw_init() - initialize late bind firmware
+ *
+ * Return: 0 if the initialization was successful, a negative errno otherwise.
+ */
  static int late_bind_fw_init(struct xe_late_bind *late_bind, u32 type)
  {
struct xe_device *xe = late_bind_to_xe(late_bind);
@@ -87,6 +186,7 @@ static int

Re: [PATCH v3 1/2] gpu/trace: make TRACE_GPU_MEM configurable

2025-06-10 Thread Juston Li

On Mon, 2025-06-09 at 13:36 +0100, Tvrtko Ursulin wrote:
> 
> On 03/06/2025 23:50, Juston Li wrote:
> > v3:
> >   - Patch introduced to replace per-driver config (Lucas)
> > 
> > Signed-off-by: Juston Li 
> > ---
> >   drivers/gpu/trace/Kconfig | 11 ++-
> >   1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig
> > index c24e9edd022e6..cd3d19c4a201c 100644
> > --- a/drivers/gpu/trace/Kconfig
> > +++ b/drivers/gpu/trace/Kconfig
> > @@ -1,4 +1,13 @@
> >   # SPDX-License-Identifier: GPL-2.0-only
> >   
> >   config TRACE_GPU_MEM
> > -   bool
> > +   bool "Enable GPU memory usage tracepoints"
> > +   default n
> > +   help
> > +     Choose this option to enable tracepoints for tracking
> > +     global and per-process GPU memory usage. Intended for
> > +     performance profiling and required for Android.
> > +
> > +     Tracepoint availability varies by GPU driver.
> > +
> > +     If in doubt, say "N".
> 
> Maybe it is a bit sub-optimal that the item shows up under the top
> level 
> drivers group. Which is already pretty busy. Maybe on top something
> like:
> 
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 7c556c5ac4fd..c5edbd2288a1 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -209,8 +209,6 @@ source "drivers/thunderbolt/Kconfig"
> 
>   source "drivers/android/Kconfig"
> 
> -source "drivers/gpu/trace/Kconfig"
> -
>   source "drivers/nvdimm/Kconfig"
> 
>   source "drivers/dax/Kconfig"
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 5df981920a94..96adceab2df0 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -70,5 +70,6 @@ if FB_CORE || SGI_NEWPORT_CONSOLE
> 
>   endif
> 
> +source "drivers/gpu/trace/Kconfig"
> 
>   endmenu
> 
> 
> To move it under Device Drivers -> Graphics support? Give or take the
> exact positioning.

SGTM, thanks!

Juston

> Regards,
> 
> Tvrtko

Re: [PATCH v2 2/2] rust: drm: Add GPUVM abstraction

2025-06-10 Thread Daniel Almeida

Hi Danilo,

> The lock might be held already by the driver or by TTM when things are called
> from TTM callbacks.
> 
> This is why GPUVM never takes locks by itself, but asserts that the correct 
> lock
> is held.
> 
> I think we really want to get proof by the driver by providing lock guard
> references.

Can’t we add a lock to our Rust GpuVmBo type?

This is already supported by the C code, since it asks driver to either provide
a custom lock _or_ use the bo's resv. So what I am suggesting here is the
former, except that said lock would be transparently managed by our Rust GPUVM
abstraction.

By using our own lock, we forbid drivers from introducing races.

Another option is to also require a(nother) Guard when mutating the BO's VA
list, but I find this a bit cumbersome for a couple of reasons:

a) It's proving a bit difficult to provide said Guard for the interval tree
itself,

b) This will appear in all functions where the lock should be taken, which
pollutes the API quite a bit.

c) Having "either a custom lock or the resv lock" sounds a bit confusing.
Handling this transparently in Rust makes the API easier to use (and harder to
misuse)

— Daniel

[PATCH] drm/amd/pm: Avoid more large frame warnings

2025-06-10 Thread Palmer Dabbelt

From: Palmer Dabbelt 

9KiB frames seem pretty big, but without this I'm getting some warnings
as of 6.16-rc1

  CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.o
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c: In function 
'smu_v13_0_6_get_gpu_metrics':
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:2885:1: 
error: the frame size of 8304 bytes is larger than 2048 bytes 
[-Werror=frame-larger-than=]
 2885 | }
  | ^
cc1: all warnings being treated as errors

Signed-off-by: Palmer Dabbelt 
---
 drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile
index 51f1fa9789ab..9824b7f4827f 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile
@@ -23,9 +23,19 @@
 # Makefile for the 'smu manager' sub-component of powerplay.
 # It provides the smu management services for the driver.
 
+ifneq ($(CONFIG_FRAME_WARN),0)
+frame_warn_limit := 9216
+ifeq ($(call test-lt, $(CONFIG_FRAME_WARN), $(frame_warn_limit)),y)
+frame_warn_flag := -Wframe-larger-than=$(frame_warn_limit)
+endif
+endif
+
 SMU13_MGR = smu_v13_0.o aldebaran_ppt.o yellow_carp_ppt.o smu_v13_0_0_ppt.o 
smu_v13_0_4_ppt.o \
smu_v13_0_5_ppt.o smu_v13_0_7_ppt.o smu_v13_0_6_ppt.o 
smu_v13_0_12_ppt.o
 
 AMD_SWSMU_SMU13MGR = $(addprefix $(AMD_SWSMU_PATH)/smu13/,$(SMU13_MGR))
 
 AMD_POWERPLAY_FILES += $(AMD_SWSMU_SMU13MGR)
+
+CFLAGS_$(AMD_SWSMU_PATH)/smu13/smu_v13_0_12_ppt.o := $(frame_warn_flag)
+CFLAGS_$(AMD_SWSMU_PATH)/smu13/smu_v13_0_6_ppt.o := $(frame_warn_flag)
-- 
2.39.5 (Apple Git-154)

[PATCH] drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port

2025-06-10 Thread Heiko Stuebner

Each window of a vop2 is usable by a specific set of video ports, so while
binding the vop2, we look through the list of available windows trying to
find one designated as primary-plane and usable by that specific port.

The code later wants to use drm_crtc_init_with_planes with that found
primary plane, but nothing has checked so far if a primary plane was
actually found.

For whatever reason, the rk3576 vp2 does not have a usable primary window
(if vp0 is also in use) which brought the issue to light and ended in a
null-pointer dereference further down.

As we expect a primary-plane to exist for a video-port, add a check at
the end of the window-iteration and fail probing if none was found.

Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 7ddf311b38c6..a8dc2e55812a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2425,6 +2425,10 @@ static int vop2_create_crtcs(struct vop2 *vop2)
break;
}
}
+
+   if (!vp->primary_plane)
+   return dev_err_probe(drm->dev, -ENOENT,
+"no primary plane for vp %d\n", i);
}
 
/* Register all unused window as overlay plane */
-- 
2.47.2

[PATCH v2] drm/nouveau/bl: increase buffer size to avoid truncate warning

2025-06-10 Thread Jacob Keller

The nouveau_get_backlight_name() function generates a unique name for the
backlight interface, appending an id from 1 to 99 for all backlight devices
after the first.

GCC 15 (and likely other compilers) produce the following
-Wformat-truncation warning:

nouveau_backlight.c: In function ‘nouveau_backlight_init’:
nouveau_backlight.c:56:69: error: ‘%d’ directive output may be truncated 
writing between 1 and 10 bytes into a region of size 3 
[-Werror=format-truncation=]
   56 | snprintf(backlight_name, BL_NAME_SIZE, 
"nv_backlight%d", nb);
  | ^~
In function ‘nouveau_get_backlight_name’,
inlined from ‘nouveau_backlight_init’ at nouveau_backlight.c:351:7:
nouveau_backlight.c:56:56: note: directive argument in the range [1, 2147483647]
   56 | snprintf(backlight_name, BL_NAME_SIZE, 
"nv_backlight%d", nb);
  |^~~~
nouveau_backlight.c:56:17: note: ‘snprintf’ output between 14 and 23 bytes into 
a destination of size 15
   56 | snprintf(backlight_name, BL_NAME_SIZE, 
"nv_backlight%d", nb);
  | 
^~~~

The warning started appearing after commit ab244be47a8f ("drm/nouveau:
Fix a potential theorical leak in nouveau_get_backlight_name()") This fix
for the ida usage removed the explicit value check for ids larger than 99.
The compiler is unable to intuit that the ida_alloc_max() limits the
returned value range between 0 and 99.

Because the compiler can no longer infer that the number ranges from 0 to
99, it thinks that it could use as many as 11 digits (10 + the potential -
sign for negative numbers).

The warning has gone unfixed for some time, with at least one kernel test
robot report. The code breaks W=1 builds, which is especially frustrating
with the introduction of CONFIG_WERROR.

The string is stored temporarily on the stack and then copied into the
device name. Its not a big deal to use 11 more bytes of stack rounding out
to an even 24 bytes. Increase BL_NAME_SIZE to 24 to avoid the truncation
warning. This fixes the W=1 builds that include this driver.

Compile tested only.

Fixes: ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in 
nouveau_get_backlight_name()")
Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202312050324.0kv4pnfz-...@intel.com/
Suggested-by: Timur Tabi 
Signed-off-by: Jacob Keller 
---
Changes in v2:
- Just increase the buffer size
- Link to v1: 
https://lore.kernel.org/r/20250604-jk-nouveua-drm-bl-snprintf-fix-v1-1-79b1593ad...@intel.com
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 
d47442125fa183146135f3725eae161c68e2a900..9aae26eb7d8fba54c8a989bfe7ecc2b10ccf7f61
 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -42,7 +42,7 @@
 #include "nouveau_acpi.h"
 
 static struct ida bl_ida;
-#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
+#define BL_NAME_SIZE 24 // 12 for name + 11 for digits + 1 for '\0'
 
 static bool
 nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE],

---
base-commit: 90b83efa6701656e02c86e7df2cb1765ea602d07
change-id: 20250604-jk-nouveua-drm-bl-snprintf-fix-c2ca525a3d2f

Best regards,
-- 
Jacob Keller

Re: [PATCH v2] Documentation: nouveau: Update GSP message queue kernel-doc reference

2025-06-10 Thread Randy Dunlap




On 6/10/25 7:08 PM, Bagas Sanjaya wrote:
> GSP message queue docs has been moved following RPC handling split in
> 8a8b1ec5261f20 ("drm/nouveau/gsp: split rpc handling out on its own"),
> before GSP-RM implementation is versioned in c472d828348caf
> ("drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/").
> However, the kernel-doc reference in nouveau docs is left behind, which
> triggers htmldocs warnings:
> 
> ERROR: Cannot find file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> WARNING: No kernel-doc for file 
> ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> 
> Update the reference.
> 
> Fixes: c472d828348c ("drm/nouveau/gsp: move subdev/engine impls to 
> subdev/gsp/rm/r535/")
> Fixes: 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own")
> Signed-off-by: Bagas Sanjaya 

Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 

Thanks.

> ---
> Changes since v1 [1]:
> 
>   - Correct GSP kernel-doc reference file (Randy)
> 
> [1]: 
> https://lore.kernel.org/linux-doc/20250610065258.41467-1-bagasdo...@gmail.com/
> 
>  Documentation/gpu/nouveau.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/nouveau.rst b/Documentation/gpu/nouveau.rst
> index b8c801e0068cb0..cab2e81013bc5f 100644
> --- a/Documentation/gpu/nouveau.rst
> +++ b/Documentation/gpu/nouveau.rst
> @@ -25,7 +25,7 @@ providing a consistent API to upper layers of the driver 
> stack.
>  GSP Support
>  
>  
> -.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> +.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
> :doc: GSP message queue element
>  
>  .. kernel-doc:: drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> 
> base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494

-- 
~Randy

Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

2025-06-10 Thread Stephen Rothwell

Hi all,

On Wed, 11 Jun 2025 12:08:01 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/vc4/vc4_hdmi.c
> 
> between commit:
> 
>   c0317ad44f45 ("drm/vc4: fix infinite EPROBE_DEFER loop")
> 
> from the drm-misc-fixes tree and commit:
> 
>   d9f9bae6752f ("drm/bridge: allow limiting I2S formats")
> 
> from the drm-misc tree.
> 
> I fixed it up (the former removes code updated by the latter, so I just
> removed the code) and can carry the fix as necessary. This is now fixed
> as far as linux-next is concerned, but any non trivial conflicts should
> be mentioned to your upstream maintainer when your tree is submitted for
> merging.  You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.

Actually, the code was moved, not removed, so it needs the below merge
fix up.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/vc4/vc4_hdmi.c
index 163d092bd973,4797ed1c21f4..
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@@ -2285,12 -2291,6 +2285,12 @@@ static int vc4_hdmi_audio_init(struct v
return ret;
}
  
 +  ret = drm_connector_hdmi_audio_init(&vc4_hdmi->connector, dev,
-   &vc4_hdmi_audio_funcs, 8, false,
++  &vc4_hdmi_audio_funcs, 8, 0, false,
 +  -1);
 +  if (ret)
 +  return ret;
 +
dai_link->cpus  = &vc4_hdmi->audio.cpu;
dai_link->codecs= &vc4_hdmi->audio.codec;
dai_link->platforms = &vc4_hdmi->audio.platform;


pgpuCE0CeFSox.pgp
Description: OpenPGP digital signature

[PATCH v3 3/4] drm/panel: Add driver for DJN HX83112B LCD panel

Add support for the 2160x1080 LCD panel from DJN (98-03057-6598B-I)
bundled with a HX83112B driver IC, as found on the Fairphone 3
smartphone.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Luca Weiss 
---
 drivers/gpu/drm/panel/Kconfig|  10 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-himax-hx83112b.c | 430 +++
 3 files changed, 441 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 
cfebb08e8a62680a14a500d28decfafc2daf743a..deee941ffa707f0795f5edd9349eddebc33e0958
 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -193,6 +193,16 @@ config DRM_PANEL_HIMAX_HX83112A
  Say Y here if you want to enable support for Himax HX83112A-based
  display panels, such as the one found in the Fairphone 4 smartphone.
 
+config DRM_PANEL_HIMAX_HX83112B
+   tristate "Himax HX83112B-based DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select DRM_KMS_HELPER
+   help
+ Say Y here if you want to enable support for Himax HX83112B-based
+ display panels, such as the one found in the Fairphone 3 smartphone.
+
 config DRM_PANEL_HIMAX_HX8394
tristate "HIMAX HX8394 MIPI-DSI LCD panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 
714cbac830e3f0be3659f1907c5dbacef863bbd8..5f61b4542b28d013b6475d1a6b84bfe912551e9c
 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX8279) += panel-himax-hx8279.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112B) += panel-himax-hx83112b.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx83112b.c 
b/drivers/gpu/drm/panel/panel-himax-hx83112b.c
new file mode 100644
index 
..d9b37416a30a221fd956c7754e00108166f364ab
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx83112b.c
@@ -0,0 +1,430 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device 
tree.
+ * Copyright (c) 2025 Luca Weiss 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Manufacturer specific DSI commands */
+#define HX83112B_SETPOWER1 0xb1
+#define HX83112B_SETDISP   0xb2
+#define HX83112B_SETDRV0xb4
+#define HX83112B_SETEXTC   0xb9
+#define HX83112B_SETBANK   0xbd
+#define HX83112B_SETDGCLUT 0xc1
+#define HX83112B_SETDISMO  0xc2
+#define HX83112B_UNKNOWN1  0xc6
+#define HX83112B_SETPANEL  0xcc
+#define HX83112B_UNKNOWN2  0xd1
+#define HX83112B_SETPOWER2 0xd2
+#define HX83112B_SETGIP0   0xd3
+#define HX83112B_SETGIP1   0xd5
+#define HX83112B_SETGIP2   0xd6
+#define HX83112B_SETGIP3   0xd8
+#define HX83112B_SETIDLE   0xdd
+#define HX83112B_UNKNOWN3  0xe7
+#define HX83112B_UNKNOWN4  0xe9
+
+struct hx83112b_panel {
+   struct drm_panel panel;
+   struct mipi_dsi_device *dsi;
+   struct regulator_bulk_data *supplies;
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct regulator_bulk_data hx83112b_supplies[] = {
+   { .supply = "iovcc" },
+   { .supply = "vsn" },
+   { .supply = "vsp" },
+};
+
+static inline struct hx83112b_panel *to_hx83112b_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct hx83112b_panel, panel);
+}
+
+static void hx83112b_reset(struct hx83112b_panel *ctx)
+{
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   usleep_range(1, 11000);
+   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+   usleep_range(1, 11000);
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   usleep_range(1, 11000);
+}
+
+static int hx83112b_on(struct hx83112b_panel *ctx)
+{
+   struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETEXTC, 0x83, 0x11, 
0x2b);
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETBANK, 0x01);
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETDISMO, 0x08, 0x70);
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETBANK, 0x03);
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETDISP, 0x04, 0x38, 
0x08, 0x70);
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETBANK, 0x00);
+   mipi_dsi_dcs_write_seq_multi(&dsi_ctx, HX83112B_SETPOWER1,
+

[PATCH v3 1/4] dt-bindings: vendor-prefixes: document Shenzhen DJN Optronics Technology

Add the vendor prefix for DJN (http://en.djnlcd.com/).

Acked-by: Krzysztof Kozlowski 
Signed-off-by: Luca Weiss 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 
5d2a7a8d3ac6c666c8b557c2ef385918e5e97bf9..76db551ebfa1266d869f40cccbccd1a288c50c02
 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -398,6 +398,8 @@ patternProperties:
 description: Diodes, Inc.
   "^dioo,.*":
 description: Dioo Microcircuit Co., Ltd
+  "^djn,.*":
+description: Shenzhen DJN Optronics Technology Co., Ltd
   "^dlc,.*":
 description: DLC Display Co., Ltd.
   "^dlg,.*":

-- 
2.49.0

[PATCH v3 4/4] arm64: dts: qcom: sdm632-fairphone-fp3: Enable display and GPU

Add the description for the display panel found on this phone.
Unfortunately the LCDB module on PMI632 isn't yet supported upstream so
we need to use a dummy regulator-fixed in the meantime.

And with this done we can also enable the GPU and set the zap shader
firmware path.

Reviewed-by: Konrad Dybcio 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Luca Weiss 
---
 arch/arm64/boot/dts/qcom/msm8953.dtsi |  2 +-
 arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts | 62 +++
 2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi 
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 
273e79fb75695af1fd7a6f77273b95fe3b913fac..c5205d09c442e45e4a0cc3e6d8ff7d9d7bda0034
 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -1147,7 +1147,7 @@ &bimc SLV_EBI RPM_ALWAYS_TAG>,
 
status = "disabled";
 
-   zap-shader {
+   gpu_zap_shader: zap-shader {
memory-region = <&zap_shader_region>;
};
 
diff --git a/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts 
b/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
index 
31ed26c31e6ea381a8942ccf569513df3300cdeb..55a45b528bd3f1bf9b6fe7882753338b43c62271
 100644
--- a/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
+++ b/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
@@ -36,6 +36,14 @@ key-volume-up {
};
};
 
+   /* Dummy regulator until PMI632 has LCDB VSP/VSN support */
+   lcdb_dummy: regulator-lcdb-dummy {
+   compatible = "regulator-fixed";
+   regulator-name = "lcdb_dummy";
+   regulator-min-microvolt = <550>;
+   regulator-max-microvolt = <550>;
+   };
+
vph_pwr: vph-pwr-regulator {
compatible = "regulator-fixed";
regulator-name = "vph_pwr";
@@ -44,6 +52,14 @@ vph_pwr: vph-pwr-regulator {
};
 };
 
+&gpu {
+   status = "okay";
+};
+
+&gpu_zap_shader {
+   firmware-name = "qcom/msm8953/fairphone/fp3/a506_zap.mbn";
+};
+
 &hsusb_phy {
vdd-supply = <&pm8953_l3>;
vdda-pll-supply = <&pm8953_l7>;
@@ -87,6 +103,45 @@ &lpass {
status = "okay";
 };
 
+&mdss {
+   status = "okay";
+};
+
+&mdss_dsi0 {
+   vdda-supply = <&pm8953_s3>;
+   status = "okay";
+
+   panel@0 {
+   compatible = "djn,98-03057-6598b-i";
+   reg = <0>;
+
+   reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
+
+   iovcc-supply = <&pm8953_l6>;
+   vsn-supply = <&lcdb_dummy>;
+   vsp-supply = <&lcdb_dummy>;
+
+   pinctrl-0 = <&mdss_te_default>;
+   pinctrl-names = "default";
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <&mdss_dsi0_out>;
+   };
+   };
+   };
+};
+
+&mdss_dsi0_out {
+   data-lanes = <0 1 2 3>;
+   remote-endpoint = <&panel_in>;
+};
+
+&mdss_dsi0_phy {
+   vcca-supply = <&pm8953_l3>;
+   status = "okay";
+};
+
 &mpss {
firmware-name = "qcom/msm8953/fairphone/fp3/mba.mbn",
"qcom/msm8953/fairphone/fp3/modem.mbn";
@@ -292,6 +347,13 @@ &tlmm {
 * 135-138: fingerprint reader (SPI)
 */
gpio-reserved-ranges = <0 4>, <135 4>;
+
+   mdss_te_default: mdss-te-default-state {
+   pins = "gpio24";
+   function = "mdp_vsync";
+   drive-strength = <2>;
+   bias-pull-down;
+   };
 };
 
 &uart_0 {

-- 
2.49.0

[PATCH v3 2/4] dt-bindings: display: panel: Add Himax HX83112B

Himax HX83112B is a display driver IC used to drive LCD DSI panels.
Describe it and the Fairphone 3 panel (98-03057-6598B-I) from DJN using
it.

Signed-off-by: Luca Weiss 
---
 .../bindings/display/panel/himax,hx83112b.yaml | 75 ++
 1 file changed, 75 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml
new file mode 100644
index 
..54c555c18bbe7656ec625b20e28a53fde5fe578b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83112b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83112B-based DSI display panels
+
+maintainers:
+  - Luca Weiss 
+
+description:
+  The Himax HX83112B is a generic DSI Panel IC used to control
+  LCD panels.
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+contains:
+  const: djn,98-03057-6598b-i
+
+  reg:
+maxItems: 1
+
+  iovcc-supply:
+description: I/O voltage rail
+
+  vsn-supply:
+description: Positive source voltage rail
+
+  vsp-supply:
+description: Negative source voltage rail
+
+  port: true
+
+required:
+  - compatible
+  - reg
+  - reset-gpios
+  - iovcc-supply
+  - vsn-supply
+  - vsp-supply
+  - port
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "djn,98-03057-6598b-i";
+reg = <0>;
+
+reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
+
+iovcc-supply = <&pm8953_l6>;
+vsn-supply = <&pmi632_lcdb_ncp>;
+vsp-supply = <&pmi632_lcdb_ldo>;
+
+port {
+panel_in_0: endpoint {
+remote-endpoint = <&dsi0_out>;
+};
+};
+};
+};
+
+...

-- 
2.49.0

Re: [PATCH v2 03/10] drm/xe/xe_late_bind_fw: Introducing xe_late_bind_fw

2025-06-10 Thread Daniele Ceraolo Spurio





On 6/6/2025 10:57 AM, Badal Nilawar wrote:

Introducing xe_late_bind_fw to enable firmware loading for the devices,
such as the fan controller, during the driver probe. Typically,
firmware for such devices are part of IFWI flash image but can be
replaced at probe after OEM tuning.
This patch binds late binding component to enable firmware loading
through CSE.

v2:
  - Add devm_add_action_or_reset to remove the component (Daniele)
  - Add INTEL_MEI_GSC check in xe_late_bind_init() (Daniele)

Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/xe/Makefile|  1 +
  drivers/gpu/drm/xe/xe_device.c |  3 +
  drivers/gpu/drm/xe/xe_device_types.h   |  4 +
  drivers/gpu/drm/xe/xe_late_bind_fw.c   | 96 ++
  drivers/gpu/drm/xe/xe_late_bind_fw.h   | 15 
  drivers/gpu/drm/xe/xe_late_bind_fw_types.h | 39 +
  6 files changed, 158 insertions(+)
  create mode 100644 drivers/gpu/drm/xe/xe_late_bind_fw.c
  create mode 100644 drivers/gpu/drm/xe/xe_late_bind_fw.h
  create mode 100644 drivers/gpu/drm/xe/xe_late_bind_fw_types.h

diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 01d231777901..134eee21c75e 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -76,6 +76,7 @@ xe-y += xe_bb.o \
xe_hw_fence.o \
xe_irq.o \
xe_lrc.o \
+   xe_late_bind_fw.o \
xe_migrate.o \
xe_mmio.o \
xe_mocs.o \
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index d4b6e623aa48..e062ddaa83bb 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -43,6 +43,7 @@
  #include "xe_hw_engine_group.h"
  #include "xe_hwmon.h"
  #include "xe_irq.h"
+#include "xe_late_bind_fw.h"
  #include "xe_memirq.h"
  #include "xe_mmio.h"
  #include "xe_module.h"
@@ -888,6 +889,8 @@ int xe_device_probe(struct xe_device *xe)
if (err)
return err;
  
+	xe_late_bind_init(&xe->late_bind);


I believe that the xe approach is to always fail the probe if something 
goes wrong, even if it is not fatal,s oyou should check the error here. 
However, make sure that the probe is not aborted in the missing mei 
component case (e.g., only fail if "err && err != -ENODEV")



+
err = xe_oa_init(xe);
if (err)
return err;
diff --git a/drivers/gpu/drm/xe/xe_device_types.h 
b/drivers/gpu/drm/xe/xe_device_types.h
index 043515f8c068..3fda450a0774 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -16,6 +16,7 @@
  #include "xe_devcoredump_types.h"
  #include "xe_heci_gsc.h"
  #include "xe_lmtt_types.h"
+#include "xe_late_bind_fw_types.h"
  #include "xe_memirq_types.h"
  #include "xe_oa_types.h"
  #include "xe_platform_types.h"
@@ -549,6 +550,9 @@ struct xe_device {
/** @heci_gsc: graphics security controller */
struct xe_heci_gsc heci_gsc;
  
+	/** @late_bind: xe mei late bind interface */

+   struct xe_late_bind late_bind;
+
/** @oa: oa observation subsystem */
struct xe_oa oa;
  
diff --git a/drivers/gpu/drm/xe/xe_late_bind_fw.c b/drivers/gpu/drm/xe/xe_late_bind_fw.c

new file mode 100644
index ..22eb9b51b4ee
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_late_bind_fw.c
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "xe_device.h"
+#include "xe_late_bind_fw.h"
+
+static struct xe_device *
+late_bind_to_xe(struct xe_late_bind *late_bind)
+{
+   return container_of(late_bind, struct xe_device, late_bind);
+}
+
+static int xe_late_bind_component_bind(struct device *xe_kdev,
+  struct device *mei_kdev, void *data)
+{
+   struct xe_device *xe = kdev_to_xe_device(xe_kdev);
+   struct xe_late_bind *late_bind = &xe->late_bind;
+
+   mutex_lock(&late_bind->mutex);
+   late_bind->component.ops = data;
+   late_bind->component.mei_dev = mei_kdev;
+   mutex_unlock(&late_bind->mutex);
+
+   return 0;
+}
+
+static void xe_late_bind_component_unbind(struct device *xe_kdev,
+ struct device *mei_kdev, void *data)
+{
+   struct xe_device *xe = kdev_to_xe_device(xe_kdev);
+   struct xe_late_bind *late_bind = &xe->late_bind;
+
+   mutex_lock(&late_bind->mutex);
+   late_bind->component.ops = NULL;
+   mutex_unlock(&late_bind->mutex);
+}
+
+static const struct component_ops xe_late_bind_component_ops = {
+   .bind   = xe_late_bind_component_bind,
+   .unbind = xe_late_bind_component_unbind,
+};
+
+static void xe_late_bind_remove(void *arg)


nit: no need for the xe_* prefix for static functions


+{
+   struct xe_late_bind *late_bind = arg;
+   struct xe_device *xe = late_bind_to_xe(late_bind);
+
+   if (!late_bind->component_added)
+   return;


This check ag

Re: [PATCH v6 07/17] drm/msm/dsi/phy: Define PHY_CMN_CTRL_0 bitfields

On Tue, Jun 10, 2025 at 04:05:45PM +0200, Krzysztof Kozlowski wrote:
> Add bitfields for PHY_CMN_CTRL_0 registers to avoid hard-coding bit
> masks and shifts and make the code a bit more readable.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes in v6:
> 1. Add new line between declarations and actual code (Dmitry)
> 
> Changes in v5:
> 1. New patch
> ---
>  drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 16 +++-
>  drivers/gpu/drm/msm/registers/display/dsi_phy_7nm.xml | 11 ++-
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov 


-- 
With best wishes
Dmitry

Re: [PATCH v6 11/17] drm/msm/dsi: Add support for SM8750

On Tue, Jun 10, 2025 at 04:05:49PM +0200, Krzysztof Kozlowski wrote:
> Add support for DSI on Qualcomm SM8750 SoC with notable difference:
> 
> DSI PHY PLLs, the parents of pixel and byte clocks, cannot be used as
> parents before DSI PHY is configured, the PLLs are prepared and their
> initial rate is set.  Therefore assigned-clock-parents are not working
> here and driver is responsible for reparenting clocks with proper
> procedure: see dsi_clk_init_6g_v2_9().
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 

Reviewed-by: Dmitry Baryshkov 


-- 
With best wishes
Dmitry

Re: [PATCH v6 13/17] drm/msm/dpu: Consistently use u32 instead of uint32_t

On Tue, Jun 10, 2025 at 04:05:51PM +0200, Krzysztof Kozlowski wrote:
> Linux coding style asks to use kernel types like u32 instead of uint32_t
> and code already has it in other places, so unify the remaining pieces.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
> 
> Changes in v6:
> 1. New patch
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov 


-- 
With best wishes
Dmitry

Re: [PATCH] accel/qaic: Use dev_printk() in RAS

2025-06-10 Thread Stephen Rothwell

Hi Jeff,

On Tue, 10 Jun 2025 11:59:12 -0600 Jeff Hugo  wrote:
>
> pci_printk() was removed with commit 1c8a0ed2043c ("PCI: Remove unused 
> pci_printk()")
> so change to using dev_printk().
> 
> Fixes: c11a50b170e7 ("accel/qaic: Add Reliability, Accessibility, 
> Serviceability (RAS)")
> Reported-by: Stephen Rothwell 
> Closes: https://lore.kernel.org/all/20250610124809.1e1ff...@canb.auug.org.au/
> Signed-off-by: Jeff Hugo 
> ---
>  drivers/accel/qaic/qaic_ras.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Thanks.  I will apply that to the drm-misc tree merge until it is
applied to the drm-misc tree itself.

-- 
Cheers,
Stephen Rothwell


pgp58JPuyCWfF.pgp
Description: OpenPGP digital signature

[PATCH v3 0/4] Add display support for Fairphone 3 smartphone

Add a driver for the HX83112B-based panel, and enable it on Fairphone 3
to enable display output, and enable GPU as well.

Signed-off-by: Luca Weiss 
---
Changes in v3:
- Pick up tags
- Rebase on v6.16-rc1
- Link to v2: 
https://lore.kernel.org/r/20250225-fp3-display-v2-0-0b1f05915...@lucaweiss.eu

Changes in v2:
- Change compatible to "djn,98-03057-6598b-i" based on other docs I
  found
- Pick up tags
- Link to v1: 
https://lore.kernel.org/r/20250222-fp3-display-v1-0-ccd812e16...@lucaweiss.eu

---
Luca Weiss (4):
  dt-bindings: vendor-prefixes: document Shenzhen DJN Optronics Technology
  dt-bindings: display: panel: Add Himax HX83112B
  drm/panel: Add driver for DJN HX83112B LCD panel
  arm64: dts: qcom: sdm632-fairphone-fp3: Enable display and GPU

 .../bindings/display/panel/himax,hx83112b.yaml |  75 
 .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
 arch/arm64/boot/dts/qcom/msm8953.dtsi  |   2 +-
 arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts  |  62 +++
 drivers/gpu/drm/panel/Kconfig  |  10 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-himax-hx83112b.c   | 430 +
 7 files changed, 581 insertions(+), 1 deletion(-)
---
base-commit: c8a9a1ae369c60953b27c01162eb72b0422b9532
change-id: 20250222-fp3-display-b79cb339e65b

Best regards,
-- 
Luca Weiss

Re: [PATCH v3 3/4] drm/panel: Add driver for DJN HX83112B LCD panel

On Tue, Jun 10, 2025 at 09:09:21PM +0200, Luca Weiss wrote:
> Add support for the 2160x1080 LCD panel from DJN (98-03057-6598B-I)
> bundled with a HX83112B driver IC, as found on the Fairphone 3
> smartphone.
> 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Luca Weiss 
> ---
>  drivers/gpu/drm/panel/Kconfig|  10 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-himax-hx83112b.c | 430 
> +++
>  3 files changed, 441 insertions(+)

> +static int hx83112b_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + struct hx83112b_panel *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ret = devm_regulator_bulk_get_const(dev,
> + ARRAY_SIZE(hx83112b_supplies),
> + hx83112b_supplies,
> + &ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ctx->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
> +  "Failed to get reset-gpios\n");
> +
> + ctx->dsi = dsi;
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
> +   MIPI_DSI_CLOCK_NON_CONTINUOUS |
> +   MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_LPM;
> +
> + drm_panel_init(&ctx->panel, dev, &hx83112b_panel_funcs,
> +DRM_MODE_CONNECTOR_DSI);

Please switch to devm_drm_panel_alloc(). LGTM otherwise.

> + ctx->panel.prepare_prev_first = true;
> +
> + ctx->panel.backlight = hx83112b_create_backlight(dsi);
> + if (IS_ERR(ctx->panel.backlight))
> + return dev_err_probe(dev, PTR_ERR(ctx->panel.backlight),
> +  "Failed to create backlight\n");
> +
> + drm_panel_add(&ctx->panel);
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + drm_panel_remove(&ctx->panel);
> + return dev_err_probe(dev, ret, "Failed to attach to DSI 
> host\n");
> + }
> +
> + return 0;
> +}
> +

-- 
With best wishes
Dmitry

Re: [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM

2025-06-10 Thread Alexey Kardashevskiy


Hi,

Is there a QEMU tree using this somewhere?
Also it would be nice to have this tree pushed somewhere, saves time. Thanks,



On 29/5/25 15:34, Xu Yilun wrote:

This series is the generic host side (KVM/VFIO/IOMMUFD) support for the
whole life cycle of private device assignment. It follows the
previously discussed flow chart [1], aim to better illustrate the
overall flow of private device assignment, find out and narrow down the
gaps of different vendors, and reach some common directions.

This series is based on Dan's Core TSM infrastructure series [2].  To
give a clear overview of what components are needed, it also includes
some existing WIP patchsets in community.

This series has 3 sections:

Patch 1 - 11 deal with the private MMIO mapping in KVM MMU via DMABUF.
Leverage Jason & Vivek's latest VFIO dmabuf series [3], see Patch 2 - 4.
The concern for get_pfn() kAPI [4] is not addressed so are marked as
HACK, will investigate later.

Patch 12 - 22 is about TSM Bind/Unbind/Guest request management in VFIO
& IOMMUFD. Picks some of Shameer's patch in [5], see Patch 12 & 14.

Patch 23 - 30 is a solution to meet the TDX specific sequence
enforcement on various device Unbind cases, including converting device
back to shared, hot unplug, TD destroy. Start with a tdx_tsm driver
prototype and finally implement the Unbind enforcement inside the
driver. To be honest it is still awkward to me, but I need help.

This series don't include the VMEXIT handle for GHCI/GHCB calls for
Bind/Unbind/Guest request, cause it involves vendor specific code. The
general idea is KVM should just pass these calls to QEMU, QEMU parses
out the command and call the newly introduced VFIO/IOMMUFD IOCTLs.

With additional TDX Connect specific patches (not published), passed
engineering test for trusted DMA in TD.

[1]: https://lore.kernel.org/all/aCYsNSFQJZzHVOFI@yilunxu-OptiPlex-7050/
[2]: 
https://lore.kernel.org/all/20250516054732.2055093-1-dan.j.willi...@intel.com/
[3]: 
https://lore.kernel.org/kvm/20250307052248.405803-1-vivek.kasire...@intel.com/
[4]: 
https://lore.kernel.org/all/20250107142719.179636-1-yilun...@linux.intel.com/
[5]: 
https://lore.kernel.org/all/20250319173202.78988-3-shameerali.kolothum.th...@huawei.com/
> 
Alexey Kardashevskiy (1):

   iommufd/vdevice: Add TSM Guest request uAPI

Dan Williams (2):
   coco/tdx_tsm: Introduce a "tdx" subsystem and "tsm" device
   coco/tdx_tsm: TEE Security Manager driver for TDX

Shameer Kolothum (2):
   iommufd/device: Associate a kvm pointer to iommufd_device
   iommu/arm-smmu-v3-iommufd: Pass in kvm pointer to viommu_alloc

Vivek Kasireddy (3):
   vfio: Export vfio device get and put registration helpers
   vfio/pci: Share the core device pointer while invoking feature
 functions
   vfio/pci: Allow MMIO regions to be exported through dma-buf

Wu Hao (1):
   coco/tdx_tsm: Add connect()/disconnect() handlers prototype

Xu Yilun (21):
   HACK: dma-buf: Introduce dma_buf_get_pfn_unlocked() kAPI
   fixup! vfio/pci: fix dma-buf revoke typo on reset
   HACK: vfio/pci: Support get_pfn() callback for dma-buf
   KVM: Support vfio_dmabuf backed MMIO region
   KVM: x86/mmu: Handle page fault for vfio_dmabuf backed MMIO
   KVM: x86/mmu: Handle page fault for private MMIO
   vfio/pci: Export vfio dma-buf specific info for importers
   KVM: vfio_dmabuf: Fetch VFIO specific dma-buf data for sanity check
   fixup! iommufd/selftest: Sync iommufd_device_bind() change to selftest
   fixup: iommu/selftest: Sync .viommu_alloc() change to selftest
   iommufd/viommu: track the kvm pointer & its refcount in viommu core
   iommufd/device: Add TSM Bind/Unbind for TIO support
   iommufd/viommu: Add trusted IOMMU configuration handlers for vdev
   vfio/pci: Add TSM TDI bind/unbind IOCTLs for TEE-IO support
   vfio/pci: Do TSM Unbind before zapping bars
   fixup! PCI/TSM: Change the guest request type definition
   coco/tdx_tsm: Add bind()/unbind()/guest_req() handlers prototype
   PCI/TSM: Add PCI driver callbacks to handle TSM requirements
   vfio/pci: Implement TSM handlers for MMIO
   iommufd/vdevice: Implement TSM handlers for trusted DMA
   coco/tdx_tsm: Manage TDX Module enforced operation sequences for
 Unbind

  Documentation/virt/kvm/api.rst|   7 +
  arch/x86/Kconfig  |   1 +
  arch/x86/kvm/mmu/mmu.c|  25 +-
  drivers/dma-buf/dma-buf.c |  87 +++-
  .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c |   1 +
  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |   1 +
  drivers/iommu/iommufd/device.c|  89 +++-
  drivers/iommu/iommufd/iommufd_private.h   |  10 +
  drivers/iommu/iommufd/main.c  |   3 +
  drivers/iommu/iommufd/selftest.c  |   3 +-
  drivers/iommu/iommufd/viommu.c| 202 -
  drivers/vfio/iommufd.c|  24 +-
  drivers/vfio/pci/Makefile |   1 +
  drivers/vfio/pci/vfio_pci.c

linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

2025-06-10 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/vc4/vc4_hdmi.c

between commit:

  c0317ad44f45 ("drm/vc4: fix infinite EPROBE_DEFER loop")

from the drm-misc-fixes tree and commit:

  d9f9bae6752f ("drm/bridge: allow limiting I2S formats")

from the drm-misc tree.

I fixed it up (the former removes code updated by the latter, so I just
removed the code) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpo4y_xRABRo.pgp
Description: OpenPGP digital signature

[PATCH v2] Documentation: nouveau: Update GSP message queue kernel-doc reference

2025-06-10 Thread Bagas Sanjaya

GSP message queue docs has been moved following RPC handling split in
8a8b1ec5261f20 ("drm/nouveau/gsp: split rpc handling out on its own"),
before GSP-RM implementation is versioned in c472d828348caf
("drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/").
However, the kernel-doc reference in nouveau docs is left behind, which
triggers htmldocs warnings:

ERROR: Cannot find file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
WARNING: No kernel-doc for file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c

Update the reference.

Fixes: c472d828348c ("drm/nouveau/gsp: move subdev/engine impls to 
subdev/gsp/rm/r535/")
Fixes: 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own")
Signed-off-by: Bagas Sanjaya 
---
Changes since v1 [1]:

  - Correct GSP kernel-doc reference file (Randy)

[1]: 
https://lore.kernel.org/linux-doc/20250610065258.41467-1-bagasdo...@gmail.com/

 Documentation/gpu/nouveau.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/gpu/nouveau.rst b/Documentation/gpu/nouveau.rst
index b8c801e0068cb0..cab2e81013bc5f 100644
--- a/Documentation/gpu/nouveau.rst
+++ b/Documentation/gpu/nouveau.rst
@@ -25,7 +25,7 @@ providing a consistent API to upper layers of the driver 
stack.
 GSP Support
 
 
-.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
:doc: GSP message queue element
 
 .. kernel-doc:: drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h

base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH] drm/amd/pm: Avoid more large frame warnings

2025-06-10 Thread Lazar, Lijo




On 6/11/2025 2:51 AM, Palmer Dabbelt wrote:
> From: Palmer Dabbelt 
> 
> 9KiB frames seem pretty big, but without this I'm getting some warnings
> as of 6.16-rc1
> 
>   CC [M]  drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.o
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c: In 
> function 'smu_v13_0_6_get_gpu_metrics':
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:2885:1: 
> error: the frame size of 8304 bytes is larger than 2048 bytes 
> [-Werror=frame-larger-than=]
>  2885 | }
>   | ^
> cc1: all warnings being treated as errors
>

Could you also provide your build environment details?

With below in Makefile + gcc 11.4.0, stack frame size is 168 bytes.

ccflags-y += -fstack-usage

smu_v13_0_6_ppt.c:2667:16:smu_v13_0_6_get_gpu_metrics   168 static

Thanks,
Lijo

> Signed-off-by: Palmer Dabbelt 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile 
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile
> index 51f1fa9789ab..9824b7f4827f 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile
> @@ -23,9 +23,19 @@
>  # Makefile for the 'smu manager' sub-component of powerplay.
>  # It provides the smu management services for the driver.
>  
> +ifneq ($(CONFIG_FRAME_WARN),0)
> +frame_warn_limit := 9216
> +ifeq ($(call test-lt, $(CONFIG_FRAME_WARN), $(frame_warn_limit)),y)
> +frame_warn_flag := -Wframe-larger-than=$(frame_warn_limit)
> +endif
> +endif
> +
>  SMU13_MGR = smu_v13_0.o aldebaran_ppt.o yellow_carp_ppt.o smu_v13_0_0_ppt.o 
> smu_v13_0_4_ppt.o \
>   smu_v13_0_5_ppt.o smu_v13_0_7_ppt.o smu_v13_0_6_ppt.o 
> smu_v13_0_12_ppt.o
>  
>  AMD_SWSMU_SMU13MGR = $(addprefix $(AMD_SWSMU_PATH)/smu13/,$(SMU13_MGR))
>  
>  AMD_POWERPLAY_FILES += $(AMD_SWSMU_SMU13MGR)
> +
> +CFLAGS_$(AMD_SWSMU_PATH)/smu13/smu_v13_0_12_ppt.o := $(frame_warn_flag)
> +CFLAGS_$(AMD_SWSMU_PATH)/smu13/smu_v13_0_6_ppt.o := $(frame_warn_flag)

RE: [PATCH v3 1/3] mm/hugetlb: Make hugetlb_reserve_pages() return nr of entries updated

2025-06-10 Thread Kasireddy, Vivek

Hi Andrew,

> Subject: Re: [PATCH v3 1/3] mm/hugetlb: Make hugetlb_reserve_pages()
> return nr of entries updated
> 
> On Fri, 6 Jun 2025 06:14:06 + "Kasireddy, Vivek"
>  wrote:
> 
> > > Also, patch [2/3] addresses a BUG which was introduced into 6.12.
> > > Presumably we want to backport the fix into -stable?  If so, it's
> > > better to present this as a standalone patch, including the cc:stable
> > > tag.  This is because I'd be looking to fast-track the fix into the
> > > 6.16-rcX cycle whereas less urgent things would be routed into
> > > 6.17-rc1.
> > Unless I merge patches #1 and #2, I don't think I can come up with a
> > standalone fix to address the BUG. So, I don't mind having this short
> > series deferred until 6.17-rc1.
> 
> If I understand correctly, we have a way in which unprivileged
> userspace can trigger a BUG.  Unless we're very lucky, this wrecks the
> running kernel.  So fixing this in shipped kernels is very important.
> 
> So if I indeed understand correctly, please try to find a minimal fix
> which is suitable for backporting and then, as a separate series,
> propose any changes which you think would improve things going forward.
Ok, I'll try to come up with a standalone patch to fix the reported BUG 
and separate out other changes into different patches.

Thanks,
Vivek

> 
> Thanks.

[PATCH v4] drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type

2025-06-10 Thread Jayesh Choudhary

By default, HPD was disabled on SN65DSI86 bridge. When the driver was
added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
call which was moved to other function calls subsequently.
Later on, commit "c312b0df3b13" added detect utility for DP mode. But with
HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced
state always return 1 (always connected state).

Set HPD_DISABLE bit conditionally based on connector type.
Since the HPD_STATE is reflected correctly only after waiting for debounce
time (~100-400ms) and adding this delay in detect() is not feasible
owing to the performace impact (glitches and frame drop), remove runtime
calls in detect() and add hpd_enable()/disable() bridge hooks with runtime
calls, to detect hpd properly without any delay.

[0]:  (Pg. 32)

Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge connector 
operations for DP")
Cc: Max Krummenacher 
Signed-off-by: Jayesh Choudhary 
---

Changelog v3->v4:
- Remove "no-hpd" support due to backward compatibility issues
- Change the conditional from "no-hpd" back to connector type
  but still address [1]

v3 patch link:


Changelog v2->v3:
- Change conditional based on no-hpd property to address [1]
- Remove runtime calls in detect() with appropriate comments
- Add hpd_enable() and hpd_disable() in drm_bridge_funcs

v2 patch link:


Changelog v1->v2:
- Drop additional property in bindings and use conditional.
- Instead of register read for HPD state, use dpcd read which returns 0
  for success and error codes for no connection
- Add relevant history for the required change in commit message
- Drop RFC subject-prefix in v2
- Add "Cc:" tag

v1 patch link:


[1]: 


 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 49 ++-
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 60224f476e1d..b674a1aa1a37 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -348,12 +348,20 @@ static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86 
*pdata,
 * 200 ms.  We'll assume that the panel driver will have the hardcoded
 * delay in its prepare and always disable HPD.
 *
-* If HPD somehow makes sense on some future panel we'll have to
-* change this to be conditional on someone specifying that HPD should
-* be used.
+* For DisplayPort connector type, now that HPD makes sense and is
+* required, use the connector type to conditionally disable HPD.
+*
+* NOTE: The bridge type is set in auxiliary_bridge probe but
+* enable_comms() can be called before. So for DisplayPort,
+* HPD will be enabled once bridge type is set.
+* "no-hpd" property is not used properly in devicetree description
+* and hence is unreliable. Therefore HPD is being enabled using
+* this conditional.
 */
-   regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE,
-  HPD_DISABLE);
+
+   if (pdata->bridge.type != DRM_MODE_CONNECTOR_DisplayPort)
+   regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, 
HPD_DISABLE,
+  HPD_DISABLE);
 
pdata->comms_enabled = true;
 
@@ -1195,9 +1203,17 @@ static enum drm_connector_status 
ti_sn_bridge_detect(struct drm_bridge *bridge)
struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
int val = 0;
 
-   pm_runtime_get_sync(pdata->dev);
+   /*
+* The chip won't report HPD right after being powered on as
+* HPD_DEBOUNCED_STATE reflects correct state only after the
+* debounce time (~100-400 ms).
+* So having pm_runtime_get_sync() and immediately reading
+* the register in detect() won't work, and adding delay()
+* in detect will have performace impact in display.
+* So remove runtime calls here.
+*/
+
regmap_read(pdata->regmap, SN_HPD_DISABLE_REG, &val);
-   pm_runtime_put_autosuspend(pdata->dev);
 
return val & HPD_DEBOUNCED_STATE ? connector_status_connected
 : connector_status_disconnected;
@@ -1220,6 +1236,20 @@ static void ti_sn65dsi86_debugfs_init(struct drm_bridge 
*bridge, struct dentry *
debugfs_create_file("status", 0600, debugfs, pdata, &status_fops);
 }
 
+static void ti_sn_bridge_hpd_enable(struct drm_bridge *bridge)
+{
+   struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
+
+   pm_runtime_get_sync(pda

[PATCH] drm/xe: replace kmem_cache_create() with KMEM_CACHE()

2025-06-10 Thread Salah Triki

Use KMEM_CACHE() instead of kmem_cache_create() to simplify the creation
of SLAB cache.

Signed-off-by: Salah Triki 
---
 drivers/gpu/drm/xe/xe_hw_fence.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_hw_fence.c b/drivers/gpu/drm/xe/xe_hw_fence.c
index 0b4f12be3692..b54f758a905e 100644
--- a/drivers/gpu/drm/xe/xe_hw_fence.c
+++ b/drivers/gpu/drm/xe/xe_hw_fence.c
@@ -20,9 +20,8 @@ static struct kmem_cache *xe_hw_fence_slab;
 
 int __init xe_hw_fence_module_init(void)
 {
-   xe_hw_fence_slab = kmem_cache_create("xe_hw_fence",
-sizeof(struct xe_hw_fence), 0,
-SLAB_HWCACHE_ALIGN, NULL);
+   xe_hw_fence_slab = KMEM_CACHE(xe_hw_fence, SLAB_HWCACHE_ALIGN);
+
if (!xe_hw_fence_slab)
return -ENOMEM;
 
-- 
2.43.0

Re: [PATCH v6 14/17] drm/msm/dpu: Implement 10-bit color alpha for v12.0 DPU

2025-06-10 Thread Krzysztof Kozlowski

On 10/06/2025 16:10, Neil Armstrong wrote:
> On 10/06/2025 16:05, Krzysztof Kozlowski wrote:
>> v12.0 DPU on SM8750 comes with 10-bit color alpha.  Add register
>> differences and new implementations of setup_alpha_out(),
>> setup_border_color() and setup_blend_config().
>>
>> Notable changes in v6:
>> Correct fg_alpha shift on new DPU, pointed out by Abel Vesas.
> 
>  Vesa
> 
> Not sure this should be in the commit message.

DRM, at least multiple DRM-subsystems, adds full changelogs to the
commit msg, so I think adding notable part is worth.

Best regards,
Krzysztof

Re: [PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable

2025-06-10 Thread Diederik de Haas

Hi Piotr,

On Tue Jun 10, 2025 at 12:37 AM CEST, Piotr Zalewski wrote:
> Hi Diederik, sorry for late response

No need to be sorry :-)

(late? Less then 2 days vs my ~4 months before the git bisect ...)

>> Interesting that it also happened with drm=y.
>
> I actually checked now and i don't have the issue with drm=y, sorry for 
> misinforming you all, hopefully no one's time was wasted.

Good to know, thanks :-)

>> > happened twice and at short interval and since this patch allows for gamma
>> > LUT update regardless of color_mgmt_changed state this makes DSP CTRL GAMMA
>> > LUT EN bit to be unset twice too. It seems that VOP does not like it. I
>> 
>> Happy to see you found the cause :-)
>> Do you happen to know why it was unset twice? That sounds suboptimal.
>
> It is due to DRM modeset which can happens when CRTC (display) config changes 
> "significantly". AFAIK modeset happens def. when you go out of suspend or
> display timings change. I might have been fooled by serial console last time
> as it does not appear to happen twice in short interval when i review the 
> journal entries.
>
>> But (IIUC) setting a bit to a value it already has causing issues,
>> sounds surprising as well.
>
> Depends on what hardware does, when you write to a register it might cause
> many other things to happen and seems like for vop2 it messes something up.

I didn't know that, thanks.

> I made a second patch so that the first write is not permitted but all 
> subsequent are permitted (regardless of lut en state) - issue disappeared 
> too. So it might be that very first write to dsp lut disable happens too 
> fast (in relation to something else)?. It is not intuitive because when drm is
> a module it happens usually like ~second later.
>
> part of the log with drm=y
> ```
> [6.543099] rockchip-drm display-subsystem: [drm] GAMMA LUT DISABLE
> ```
>
> part of the log with drm=m
> ```
> [7.944120] rockchip-drm display-subsystem: [drm] GAMMA LUT DISABLE
> ```

My first (uneducated) hunch was a timing issue and ``=m`` can reveal
issues which you wouldn't see with ``=y``.
Andy already found an issue "that shouldn't happen" and my latest test
also had an unexpected result. So (eventually) we'll figure it out :-)

>> Sounds like a plan. It could be that this issue surfaced an underlaying
>> issue and if so, fixing that would be even better.
>
> When i have time this week I will check on what version of the kernel i 
> tested gamma lut when i sent the patches and test there.

I think it would be beneficial if you'd do the tests that Andy asked
'me' to do too, so we can compare results.
FWIW: I have the 4GB RAM version.

Cheers,
  Diederik


signature.asc
Description: PGP signature

[PATCH 08/14] fbdev/omap2: Include

2025-06-10 Thread Thomas Zimmermann

Fix the compile-time warnings

  drivers/video/fbdev/omap2/omapfb/dss/apply.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/core.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c: warning: EXPORT_SYMBOL() 
is used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/display.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/dss-of.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/dss_features.c: warning: EXPORT_SYMBOL() 
is used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/manager.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/output.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/overlay.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/dss/venc.c: warning: EXPORT_SYMBOL() is 
used, but #include  is missing
  drivers/video/fbdev/omap2/omapfb/vrfb.c: warning: EXPORT_SYMBOL() is used, 
but #include  is missing

Signed-off-by: Thomas Zimmermann 
---
 drivers/video/fbdev/omap2/omapfb/dss/apply.c| 1 +
 drivers/video/fbdev/omap2/omapfb/dss/core.c | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/display.c  | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c   | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/dss_features.c | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/manager.c  | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/output.c   | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/overlay.c  | 1 +
 drivers/video/fbdev/omap2/omapfb/dss/venc.c | 1 +
 drivers/video/fbdev/omap2/omapfb/vrfb.c | 1 +
 11 files changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/apply.c 
b/drivers/video/fbdev/omap2/omapfb/dss/apply.c
index acca991c7540..39947e569a54 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/apply.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/apply.c
@@ -6,6 +6,7 @@
 
 #define DSS_SUBSYS_NAME "APPLY"
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/core.c 
b/drivers/video/fbdev/omap2/omapfb/dss/core.c
index 55b640f2f245..02ea41f6c8f4 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
index cc2ad787d493..7831c6a2eedb 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c
@@ -6,6 +6,7 @@
 
 #define DSS_SUBSYS_NAME "APPLY"
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/display.c 
b/drivers/video/fbdev/omap2/omapfb/dss/display.c
index f91db94c9905..16543425bd84 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/display.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/display.c
@@ -11,6 +11,7 @@
 
 #define DSS_SUBSYS_NAME "DISPLAY"
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index 7c636db79882..f90a8eff7259 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
index 62c2d48d9e09..38be57ba8c28 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
@@ -6,6 +6,7 @@
  * Author: Archit Taneja 
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/manager.c 
b/drivers/video/fbdev/omap2/omapfb/dss/manager.c
index 2c2da35345d0..c59e5689d6cc 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/manager.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/manager.c
@@ -11,6 +11,7 @@
 
 #define DSS_SUBSYS_NAME "MANAGER"
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/output.c 
b/drivers/video/fbdev/omap2/omapfb/dss/output.c
index 4e2992a0ce50..48cbfb75443f 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/output.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/output.c
@@ -4,6 +4,7 @@
  * Author: Archit Taneja 
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/overlay.c 
b/drivers/video/fbdev/omap2/omapfb/dss/overlay.c
index 8c8e627da13d..bbbdc233ee61 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/overlay.c
+++ b/drivers/

Re: [PATCH] [v2] staging: fbtft: reduce stack usage

On Tue, Jun 10, 2025, at 13:23, Arnd Bergmann wrote:

>  {
>   struct device *dev = par->info->device;
> - int buf[64], count, index, i, j, ret;
> + u32 buf[64], count, index, i, j, ret;
>   u32 *values;
>   u32 val;
> 

I was too quick to update this one, please ignore v2 and
wait for v3 after I've tested it some more with the (hopefully)
correct version:

@@ -842,7 +864,8 @@ EXPORT_SYMBOL(fbtft_unregister_framebuffer);
 static int fbtft_init_display_from_property(struct fbtft_par *par)
 {
struct device *dev = par->info->device;
-   int buf[64], count, index, i, j, ret;
+   int count, index, i, j, ret;
+   u32 buf[64];
u32 *values;
u32 val;


 Arnd

Re: [PATCH] drm/test: reduce stack size in drm_exec_test

2025-06-10 Thread Christian König

On 6/10/25 11:33, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> test_prepare_array() is one of the functions that uses more than
> a kilobyte of stack on 64-bit machines, though it stays under
> the usual warning limit of 2KB:
> 
> drivers/gpu/drm/tests/drm_exec_test.c: In function 'test_prepare_array':
> drivers/gpu/drm/tests/drm_exec_test.c:171:1: error: the frame size of 1304 
> bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
> 
> In order to eventually lower that limit, change the two large
> drm_gem_object objects to be statically allocated. This works here
> because the tests are always called sequentially, and it is simpler than
> using kzalloc().
> 
> Fixes: 9710631cc8f3 ("drm: add drm_exec selftests v4")
> Signed-off-by: Arnd Bergmann 

Maybe kzalloc() would be cleaner, but it certainly isn't a must have.

Acked-by: Christian König 

> ---
>  drivers/gpu/drm/tests/drm_exec_test.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tests/drm_exec_test.c 
> b/drivers/gpu/drm/tests/drm_exec_test.c
> index d6c4dd1194a0..f2ac06a07707 100644
> --- a/drivers/gpu/drm/tests/drm_exec_test.c
> +++ b/drivers/gpu/drm/tests/drm_exec_test.c
> @@ -18,6 +18,8 @@
>  
>  #include "../lib/drm_random.h"
>  
> +static struct drm_gem_object gobj, gobj2;
> +
>  struct drm_exec_priv {
>   struct device *dev;
>   struct drm_device *drm;
> @@ -54,7 +56,6 @@ static void sanitycheck(struct kunit *test)
>  static void test_lock(struct kunit *test)
>  {
>   struct drm_exec_priv *priv = test->priv;
> - struct drm_gem_object gobj = { };
>   struct drm_exec exec;
>   int ret;
>  
> @@ -74,7 +75,6 @@ static void test_lock(struct kunit *test)
>  static void test_lock_unlock(struct kunit *test)
>  {
>   struct drm_exec_priv *priv = test->priv;
> - struct drm_gem_object gobj = { };
>   struct drm_exec exec;
>   int ret;
>  
> @@ -101,7 +101,6 @@ static void test_lock_unlock(struct kunit *test)
>  static void test_duplicates(struct kunit *test)
>  {
>   struct drm_exec_priv *priv = test->priv;
> - struct drm_gem_object gobj = { };
>   struct drm_exec exec;
>   int ret;
>  
> @@ -128,7 +127,6 @@ static void test_duplicates(struct kunit *test)
>  static void test_prepare(struct kunit *test)
>  {
>   struct drm_exec_priv *priv = test->priv;
> - struct drm_gem_object gobj = { };
>   struct drm_exec exec;
>   int ret;
>  
> @@ -150,13 +148,11 @@ static void test_prepare(struct kunit *test)
>  static void test_prepare_array(struct kunit *test)
>  {
>   struct drm_exec_priv *priv = test->priv;
> - struct drm_gem_object gobj1 = { };
> - struct drm_gem_object gobj2 = { };
> - struct drm_gem_object *array[] = { &gobj1, &gobj2 };
> + struct drm_gem_object *array[] = { &gobj, &gobj2 };
>   struct drm_exec exec;
>   int ret;
>  
> - drm_gem_private_object_init(priv->drm, &gobj1, PAGE_SIZE);
> + drm_gem_private_object_init(priv->drm, &gobj, PAGE_SIZE);
>   drm_gem_private_object_init(priv->drm, &gobj2, PAGE_SIZE);
>  
>   drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
> @@ -166,7 +162,7 @@ static void test_prepare_array(struct kunit *test)
>   KUNIT_EXPECT_EQ(test, ret, 0);
>   drm_exec_fini(&exec);
>  
> - drm_gem_private_object_fini(&gobj1);
> + drm_gem_private_object_fini(&gobj);
>   drm_gem_private_object_fini(&gobj2);
>  }
>

Re: [PATCH] drm/mediatek: only announce AFBC if really supported

2025-06-10 Thread Icenowy Zheng

在 2025-05-31星期六的 20:11 +0800，Icenowy Zheng写道：
> Currently even the SoC's OVL does not declare the support of AFBC,
> AFBC
> is still announced to the userspace within the IN_FORMATS blob, which
> breaks modern Wayland compositors like KWin Wayland and others.
> 
> Gate passing modifiers to drm_universal_plane_init() behind querying
> the
> driver of the hardware block for AFBC support.
> 
> Fixes: c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM
> driver")
> Signed-off-by: Icenowy Zheng 
> ---

Ping.

This patch at least fixes running regular Wayland desktops on
postmarketOS (I posted this patch there).

> Patch tested on MT8183, on which KWin Wayland 5.27.12 is fixed.
> 
> In addition, I tried to fake supports_afbc in mt8183_ovl_driver_data
> and
> mt8183_ovl_2l_driver_data, then KWin Wayland gets broken again and
> modetest also shows the AFBC modifier in IN_FORMATS.
> 
>  drivers/gpu/drm/mediatek/mtk_crtc.c | 3 ++-
>  drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 1 +
>  drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 9 +
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++
>  drivers/gpu/drm/mediatek/mtk_plane.c    | 7 +--
>  drivers/gpu/drm/mediatek/mtk_plane.h    | 3 ++-
>  7 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_crtc.c
> index 8f6fba4217ece..53359c2465b65 100644
> --- a/drivers/gpu/drm/mediatek/mtk_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
> @@ -930,7 +930,8 @@ static int mtk_crtc_init_comp_planes(struct
> drm_device *drm_dev,
> mtk_ddp_comp_supported_rotations(comp
> ),
> mtk_ddp_comp_get_blend_modes(comp),
> mtk_ddp_comp_get_formats(comp),
> -   mtk_ddp_comp_get_num_formats(comp),
> i);
> +   mtk_ddp_comp_get_num_formats(comp),
> +   mtk_ddp_comp_is_afbc_supported(comp),
> i);
> if (ret)
> return ret;
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> index edc6417639e64..ac6620e10262e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
> @@ -366,6 +366,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl =
> {
> .get_blend_modes = mtk_ovl_get_blend_modes,
> .get_formats = mtk_ovl_get_formats,
> .get_num_formats = mtk_ovl_get_num_formats,
> +   .is_afbc_supported = mtk_ovl_is_afbc_supported,
>  };
>  
>  static const struct mtk_ddp_comp_funcs ddp_postmask = {
> diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> index 39720b27f4e9e..7289b3dcf22f2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> @@ -83,6 +83,7 @@ struct mtk_ddp_comp_funcs {
> u32 (*get_blend_modes)(struct device *dev);
> const u32 *(*get_formats)(struct device *dev);
> size_t (*get_num_formats)(struct device *dev);
> +   bool (*is_afbc_supported)(struct device *dev);
> void (*connect)(struct device *dev, struct device *mmsys_dev,
> unsigned int next);
> void (*disconnect)(struct device *dev, struct device
> *mmsys_dev, unsigned int next);
> void (*add)(struct device *dev, struct mtk_mutex *mutex);
> @@ -294,6 +295,14 @@ size_t mtk_ddp_comp_get_num_formats(struct
> mtk_ddp_comp *comp)
> return 0;
>  }
>  
> +static inline bool mtk_ddp_comp_is_afbc_supported(struct
> mtk_ddp_comp *comp)
> +{
> +   if (comp->funcs && comp->funcs->is_afbc_supported)
> +   return comp->funcs->is_afbc_supported(comp->dev);
> +
> +   return false;
> +}
> +
>  static inline bool mtk_ddp_comp_add(struct mtk_ddp_comp *comp,
> struct mtk_mutex *mutex)
>  {
> if (comp->funcs && comp->funcs->add) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 04217a36939cd..679d413bf10be 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -106,6 +106,7 @@ void mtk_ovl_disable_vblank(struct device *dev);
>  u32 mtk_ovl_get_blend_modes(struct device *dev);
>  const u32 *mtk_ovl_get_formats(struct device *dev);
>  size_t mtk_ovl_get_num_formats(struct device *dev);
> +bool mtk_ovl_is_afbc_supported(struct device *dev);
>  
>  void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex
> *mutex);
>  void mtk_ovl_adaptor_remove_comp(struct device *dev, struct
> mtk_mutex *mutex);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index d0581c4e3c999..e0236353d4997 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -236,6 +236,13 @@ size_t mtk_ovl_get_

[PATCH v14 2/9] ref_tracker: add a top level debugfs directory for ref_tracker

2025-06-10 Thread Jeff Layton

Add a new "ref_tracker" directory in debugfs. Each individual refcount
tracker can register files under there to display info about
currently-held references.

Reviewed-by: Andrew Lunn 
Reviewed-by: Krzysztof Karas 
Signed-off-by: Jeff Layton 
---
 lib/ref_tracker.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index 
de71439e12a3bab6456910986fa611dfbdd97980..d374e5273e1497cac0d70c02c282baa2c3ab63fe
 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -273,3 +273,16 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
return 0;
 }
 EXPORT_SYMBOL_GPL(ref_tracker_free);
+
+#ifdef CONFIG_DEBUG_FS
+#include 
+
+static struct dentry *ref_tracker_debug_dir = (struct dentry *)-ENOENT;
+
+static int __init ref_tracker_debugfs_init(void)
+{
+   ref_tracker_debug_dir = debugfs_create_dir("ref_tracker", NULL);
+   return 0;
+}
+late_initcall(ref_tracker_debugfs_init);
+#endif /* CONFIG_DEBUG_FS */

-- 
2.49.0

[PATCH v4 0/3] dma-buf: heaps: Use constant name for CMA heap

2025-06-10 Thread Jared Kangas

Hi all,

This patch series is based on a previous discussion around CMA heap
naming. [1] The heap's name depends on the device name, which is
generally "reserved", "linux,cma", or "default-pool", but could be any
arbitrary name given to the default CMA area in the devicetree. For a
consistent userspace interface, the series introduces a constant name
for the CMA heap, and for backwards compatibility, an additional Kconfig
that controls the creation of a legacy-named heap with the same CMA
backing.

The ideas to handle backwards compatibility in [1] are to either use a
symlink or add a heap node with a duplicate minor. However, I assume
that we don't want to create symlinks in /dev from module initcalls, and
attempting to duplicate minors would cause device_create() to fail.
Because of these drawbacks, after brainstorming with Maxime Ripard, I
went with creating a new node in devtmpfs with its own minor. This
admittedly makes it a little unclear that the old and new nodes are
backed by the same heap when both are present. The only approach that I
think would provide total clarity on this in userspace is symlinking,
which seemed like a fairly involved solution for devtmpfs, but if I'm
wrong on this, please let me know.

Changelog:

v4:
- Fix ERR_PTR() usage for negative return value.

v3:
- Extract documentation markup fix to separate patch.
- Adjust DEFAULT_CMA_NAME per discussion in [2].
- Warn if the legacy heap name and the default heap name are the same.
- Fix DMABUF_HEAPS_CMA_LEGACY prompt.
- Touch up commit log wording.

v2:
- Use tabs instead of spaces for large vertical alignment.

[1]: https://lore.kernel.org/all/f6412229-4606-41ad-8c05-7bbba2eb6...@ti.com/
[2]:
https://lore.kernel.org/all/CANDhNCroe6ZBtN_o=c71kzffawk-ff5rcdnr9p5h1sgpows...@mail.gmail.com/

Jared Kangas (3):
Documentation: dma-buf: heaps: Fix code markup
dma-buf: heaps: Parameterize heap name in __add_cma_heap()
dma-buf: heaps: Give default CMA heap a fixed name

Documentation/userspace-api/dma-buf-heaps.rst | 11 +++---
drivers/dma-buf/heaps/Kconfig | 10 ++
drivers/dma-buf/heaps/cma_heap.c | 36 +++
3 files changed, 46 insertions(+), 11 deletions(-)

--
2.49.0

[PATCH v4 1/3] Documentation: dma-buf: heaps: Fix code markup

2025-06-10 Thread Jared Kangas

Code snippets should be wrapped in double backticks to follow
reStructuredText semantics; the use of single backticks uses the
:title-reference: role by default, which isn't quite what we want.
Add double backticks to code snippets to fix this.

Reviewed-by: Maxime Ripard 
Signed-off-by: Jared Kangas 
---
 Documentation/userspace-api/dma-buf-heaps.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/userspace-api/dma-buf-heaps.rst 
b/Documentation/userspace-api/dma-buf-heaps.rst
index 535f49047ce64..23bd0bd7b0654 100644
--- a/Documentation/userspace-api/dma-buf-heaps.rst
+++ b/Documentation/userspace-api/dma-buf-heaps.rst
@@ -19,7 +19,7 @@ following heaps:
  - The ``cma`` heap allocates physically contiguous, cacheable,
buffers. Only present if a CMA region is present. Such a region is
usually created either through the kernel commandline through the
-   `cma` parameter, a memory region Device-Tree node with the
-   `linux,cma-default` property set, or through the `CMA_SIZE_MBYTES` or
-   `CMA_SIZE_PERCENTAGE` Kconfig options. Depending on the platform, it
+   ``cma`` parameter, a memory region Device-Tree node with the
+   ``linux,cma-default`` property set, or through the ``CMA_SIZE_MBYTES`` or
+   ``CMA_SIZE_PERCENTAGE`` Kconfig options. Depending on the platform, it
might be called ``reserved``, ``linux,cma``, or ``default-pool``.
-- 
2.49.0

[PATCH v4 3/3] dma-buf: heaps: Give default CMA heap a fixed name

2025-06-10 Thread Jared Kangas

The CMA heap's name in devtmpfs can vary depending on how the heap is
defined. Its name defaults to "reserved", but if a CMA area is defined
in the devicetree, the heap takes on the devicetree node's name, such as
"default-pool" or "linux,cma". To simplify naming, unconditionally name
it "default_cma_region", but keep a legacy node in place backed by the
same underlying allocator for backwards compatibility.

Reviewed-by: Maxime Ripard 
Signed-off-by: Jared Kangas 
---
 Documentation/userspace-api/dma-buf-heaps.rst |  7 +--
 drivers/dma-buf/heaps/Kconfig | 10 ++
 drivers/dma-buf/heaps/cma_heap.c  | 20 ++-
 3 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/Documentation/userspace-api/dma-buf-heaps.rst 
b/Documentation/userspace-api/dma-buf-heaps.rst
index 23bd0bd7b0654..1dfe5e7acd5a3 100644
--- a/Documentation/userspace-api/dma-buf-heaps.rst
+++ b/Documentation/userspace-api/dma-buf-heaps.rst
@@ -21,5 +21,8 @@ following heaps:
usually created either through the kernel commandline through the
``cma`` parameter, a memory region Device-Tree node with the
``linux,cma-default`` property set, or through the ``CMA_SIZE_MBYTES`` or
-   ``CMA_SIZE_PERCENTAGE`` Kconfig options. Depending on the platform, it
-   might be called ``reserved``, ``linux,cma``, or ``default-pool``.
+   ``CMA_SIZE_PERCENTAGE`` Kconfig options. The heap's name in devtmpfs is
+   ``default_cma_region``. For backwards compatibility, when the
+   ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option is set, a duplicate node is
+   created following legacy naming conventions; the legacy name might be
+   ``reserved``, ``linux,cma``, or ``default-pool``.
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c42264..bb369b38b001a 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -12,3 +12,13 @@ config DMABUF_HEAPS_CMA
  Choose this option to enable dma-buf CMA heap. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
  regions, you should say Y here.
+
+config DMABUF_HEAPS_CMA_LEGACY
+   bool "Legacy DMA-BUF CMA Heap"
+   default y
+   depends on DMABUF_HEAPS_CMA
+   help
+ Add a duplicate CMA-backed dma-buf heap with legacy naming derived
+ from the CMA area's devicetree node, or "reserved" if the area is not
+ defined in the devicetree. This uses the same underlying allocator as
+ CONFIG_DMABUF_HEAPS_CMA.
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index e998d8ccd1dc6..0df0071119754 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -9,6 +9,9 @@
  * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
  * Andrew F. Davis 
  */
+
+#define pr_fmt(fmt) "cma_heap: " fmt
+
 #include 
 #include 
 #include 
@@ -22,6 +25,7 @@
 #include 
 #include 
 
+#define DEFAULT_CMA_NAME "default_cma_region"
 
 struct cma_heap {
struct dma_heap *heap;
@@ -394,15 +398,29 @@ static int __init __add_cma_heap(struct cma *cma, const 
char *name)
 static int __init add_default_cma_heap(void)
 {
struct cma *default_cma = dev_get_cma_area(NULL);
+   const char *legacy_cma_name;
int ret;
 
if (!default_cma)
return 0;
 
-   ret = __add_cma_heap(default_cma, cma_get_name(default_cma));
+   ret = __add_cma_heap(default_cma, DEFAULT_CMA_NAME);
if (ret)
return ret;
 
+   if (IS_ENABLED(CONFIG_DMABUF_HEAPS_CMA_LEGACY)) {
+   legacy_cma_name = cma_get_name(default_cma);
+   if (!strcmp(legacy_cma_name, DEFAULT_CMA_NAME)) {
+   pr_warn("legacy name and default name are the same, 
skipping legacy heap\n");
+   return 0;
+   }
+
+   ret = __add_cma_heap(default_cma, legacy_cma_name);
+   if (ret)
+   pr_warn("failed to add legacy heap: %pe\n",
+   ERR_PTR(ret));
+   }
+
return 0;
 }
 module_init(add_default_cma_heap);
-- 
2.49.0

Re: [PATCH] dma-buf: fix compare in WARN_ON_ONCE