Re: [PATCH 0/1] Backlight driver for the Apple Studio Display

[Julius Zint]

I appreciate all of the feedback, this should be plenty for a v2.

Thanks,

Julius

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

[Marek Olšák]

On Tue, Jul 4, 2023, 03:55 Michel Dänzer  wrote:

> On 7/4/23 04:34, Marek Olšák wrote:
> > On Mon, Jul 3, 2023, 03:12 Michel Dänzer  > wrote:
> > On 6/30/23 22:32, Marek Olšák wrote:
> > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer <
> michel.daen...@mailbox.org   michel.daen...@mailbox.org >> wrote:
> > >> On 6/30/23 16:59, Alex Deucher wrote:
> > >>> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick
> > >>> mailto:sebastian.w...@redhat.com>
> >>
> wrote:
> >  On Tue, Jun 27, 2023 at 3:23 PM André Almeida <
> andrealm...@igalia.com   andrealm...@igalia.com >> wrote:
> > >
> > > +Robustness
> > > +--
> > > +
> > > +The only way to try to keep an application working after a
> reset is if it
> > > +complies with the robustness aspects of the graphical API
> that it is using.
> > > +
> > > +Graphical APIs provide ways to applications to deal with
> device resets. However,
> > > +there is no guarantee that the app will use such features
> correctly, and the
> > > +UMD can implement policies to close the app if it is a
> repeating offender,
> > > +likely in a broken loop. This is done to ensure that it does
> not keep blocking
> > > +the user interface from being correctly displayed. This
> should be done even if
> > > +the app is correct but happens to trigger some bug in the
> hardware/driver.
> > 
> >  I still don't think it's good to let the kernel arbitrarily kill
> >  processes that it thinks are not well-behaved based on some
> heuristics
> >  and policy.
> > 
> >  Can't this be outsourced to user space? Expose the information
> about
> >  processes causing a device and let e.g. systemd deal with
> coming up
> >  with a policy and with killing stuff.
> > >>>
> > >>> I don't think it's the kernel doing the killing, it would be the
> UMD.
> > >>> E.g., if the app is guilty and doesn't support robustness the
> UMD can
> > >>> just call exit().
> > >>
> > >> It would be safer to just ignore API calls[0], similarly to what
> is done until the application destroys the context with robustness. Calling
> exit() likely results in losing any unsaved work, whereas at least some
> applications might otherwise allow saving the work by other means.
> > >
> > > That's a terrible idea. Ignoring API calls would be identical to a
> freeze. You might as well disable GPU recovery because the result would be
> the same.
> >
> > No GPU recovery would affect everything using the GPU, whereas this
> affects only non-robust applications.
> >
> > which is currently the majority.
>
> Not sure where you're going with this. Applications need to use robustness
> to be able to recover from a GPU hang, and the GPU needs to be reset for
> that. So disabling GPU reset is not the same as what we're discussing here.
>
>
> > > - non-robust contexts: call exit(1) immediately, which is the best
> way to recover
> >
> > That's not the UMD's call to make.
> >
> > That's absolutely the UMD's call to make because that's mandated by the
> hw and API design
>
> Can you point us to a spec which mandates that the process must be killed
> in this case?
>
>
> > and only driver devs know this, which this thread is a proof of. The
> default behavior is to skip all command submission if a non-robust context
> is lost, which looks like a freeze. That's required to prevent infinite
> hangs from the same context and can be caused by the side effects of the
> GPU reset itself, not by the cause of the previous hang. The only way out
> of that is killing the process.
>
> The UMD killing the process is not the only way out of that, and doing so
> is overreach on its part. The UMD is but one out of many components in a
> process, not the main one or a special one. It doesn't get to decide when
> the process must die, certainly not under circumstances where it must be
> able to continue while ignoring API calls (that's required for robustness).
>

You're mixing things up. Robust apps don't any special action from a UMD.
Only non-robust apps need to be killed for proper recovery with the only
other alternative being not updating the window/screen, which is not
user-friendly because the user who's never heard of GPU hangs has no
fucking idea why it's frozen and what do with it. It doesn't matter that
you can debug it because you're not the average user. Also it's already
used and required by our customers on Android because killing a process
returns the user to the desktop screen and can generate a crash dump
instead of keeping the app output frozen, and they agree that this is the
best us

Missing AMDGPU drm-fixes-6.4 merges

[Takashi Iwai]

Hi Dave, Alex,

it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
due to the missing signed tag:
  
https://lore.kernel.org/lkml/CAHk-=wiOCgiwzVPOwORHPML9eBphnbtM2DhRcv+v=-tnrrg...@mail.gmail.com/

And more importantly, this series isn't seen on linux-next, either; so
the whole fixes are missing in the upstream.  Could you check it?

FWIW, I stumbled on this due to a recent regression report on openSUSE
Tumbleweed:
  https://bugzilla.suse.com/show_bug.cgi?id=1212848


thanks,

Takashi

[v5, PATCH] drm/mediatek: add dma buffer control for drm plane disable

[Yongqiang Niu]

dma buffer release before overlay disable, that will cause
m4u translation fault warning.

add dma buffer control flow in mediatek driver:
get dma buffer when drm plane disable
put dma buffer when overlay really disable

Fixes: 41016fe1028e ("drm: Rename plane->state variables in atomic update and 
disable")
Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 25 
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 12 
 drivers/gpu/drm/mediatek/mtk_drm_plane.h |  1 +
 4 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index d40142842f85..49d671100785 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -283,6 +284,23 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct 
drm_crtc *crtc,
return NULL;
 }
 
+static void mtk_drm_dma_buf_put(struct mtk_drm_crtc *mtk_crtc)
+{
+   unsigned int i;
+
+   for (i = 0; i < mtk_crtc->layer_nr; i++) {
+   struct drm_plane *plane = &mtk_crtc->planes[i];
+   struct mtk_plane_state *plane_state;
+
+   plane_state = to_mtk_plane_state(plane->state);
+
+   if (plane_state && plane_state->pending.dma_buf) {
+   dma_buf_put(plane_state->pending.dma_buf);
+   plane_state->pending.dma_buf = NULL;
+   }
+   }
+}
+
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
 {
@@ -323,6 +341,8 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
mtk_crtc->pending_async_planes = false;
}
 
+   mtk_drm_dma_buf_put(mtk_crtc);
+
mtk_crtc->cmdq_vblank_cnt = 0;
wake_up(&mtk_crtc->cb_blocking_queue);
 }
@@ -624,9 +644,14 @@ static void mtk_crtc_ddp_irq(void *data)
else if (mtk_crtc->cmdq_vblank_cnt > 0 && --mtk_crtc->cmdq_vblank_cnt 
== 0)
DRM_ERROR("mtk_crtc %d CMDQ execute command timeout!\n",
  drm_crtc_index(&mtk_crtc->base));
+
+   if (!mtk_crtc->cmdq_client.chan)
+   mtk_drm_dma_buf_put(mtk_crtc);
 #else
if (!priv->data->shadow_register)
mtk_crtc_ddp_config(crtc, NULL);
+
+   mtk_drm_dma_buf_put(mtk_crtc);
 #endif
mtk_drm_finish_page_flip(mtk_crtc);
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6dcb4ba2466c..812f1667e070 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -993,4 +993,5 @@ module_exit(mtk_drm_exit);
 
 MODULE_AUTHOR("YT SHEN ");
 MODULE_DESCRIPTION("Mediatek SoC DRM driver");
+MODULE_IMPORT_NS(DMA_BUF);
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 31f9420aff6f..66e6393e45ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_drm_crtc.h"
 #include "mtk_drm_ddp_comp.h"
@@ -266,6 +267,17 @@ static void mtk_plane_atomic_disable(struct drm_plane 
*plane,
struct drm_plane_state *new_state = 
drm_atomic_get_new_plane_state(state,
   
plane);
struct mtk_plane_state *mtk_plane_state = to_mtk_plane_state(new_state);
+   struct drm_plane_state *old_state = 
drm_atomic_get_old_plane_state(state,
+  
plane);
+
+   if (old_state && old_state->fb) {
+   struct drm_gem_object *gem = old_state->fb->obj[0];
+
+   if (gem && gem->dma_buf) {
+   get_dma_buf(gem->dma_buf);
+   mtk_plane_state->pending.dma_buf = gem->dma_buf;
+   }
+   }
mtk_plane_state->pending.enable = false;
wmb(); /* Make sure the above parameter is set before update */
mtk_plane_state->pending.dirty = true;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
index 99aff7da0831..3aba0b58ef3c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
@@ -33,6 +33,7 @@ struct mtk_plane_pending_state {
boolasync_dirty;
boolasync_config;
enum drm_color_encoding color_encoding;
+   struct dma_buf  *dma_buf;
 };
 
 struct mtk_plane_state {
-- 
2.25.1

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

[Jagan Teki]

On Wed, Jul 5, 2023 at 11:09 AM Dmitry Baryshkov
 wrote:
>
> [Adding freedreno@ to cc list]
>
> On Wed, 5 Jul 2023 at 08:31, Jagan Teki  wrote:
> >
> > Hi Amit,
> >
> > On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir  wrote:
> > >
> > > Hi Marek,
> > >
> > > On Wed, 5 Jul 2023 at 01:48, Marek Vasut  wrote:
> > > >
> > > > Do not generate the HS front and back porch gaps, the HSA gap and
> > > > EOT packet, as these packets are not required. This makes the bridge
> > > > work with Samsung DSIM on i.MX8MM and i.MX8MP.
> > >
> > > This patch broke display on Dragonboard 845c (SDM845) devboard running
> > > AOSP. This is what I see
> > > https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
> > > Reverting this patch fixes this regression for me.
> >
> > Might be msm dsi host require proper handling on these updated
> > mode_flags? did they?
>
> The msm DSI host supports those flags. Also, I'd like to point out
> that the patch didn't change the rest of the driver code. So even if
> drm/msm ignored some of the flags, it should not have caused the
> issue. Most likely the issue is on the lt9611 side. I's suspect that
> additional programming is required to make it work with these flags.

True, But I'm not quite sure, most of these mode_flags were handled
more on the host. Maybe Marek can comment on this.

Thanks,
Jagan.

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

[Dmitry Baryshkov]

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki  wrote:
>
> Hi Amit,
>
> On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir  wrote:
> >
> > Hi Marek,
> >
> > On Wed, 5 Jul 2023 at 01:48, Marek Vasut  wrote:
> > >
> > > Do not generate the HS front and back porch gaps, the HSA gap and
> > > EOT packet, as these packets are not required. This makes the bridge
> > > work with Samsung DSIM on i.MX8MM and i.MX8MP.
> >
> > This patch broke display on Dragonboard 845c (SDM845) devboard running
> > AOSP. This is what I see
> > https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
> > Reverting this patch fixes this regression for me.
>
> Might be msm dsi host require proper handling on these updated
> mode_flags? did they?

The msm DSI host supports those flags. Also, I'd like to point out
that the patch didn't change the rest of the driver code. So even if
drm/msm ignored some of the flags, it should not have caused the
issue. Most likely the issue is on the lt9611 side. I's suspect that
additional programming is required to make it work with these flags.

-- 
With best wishes
Dmitry

[PATCH] drm/ttm: fix one use-after-free

[Lang Yu]

[   67.399887] refcount_t: underflow; use-after-free.
[   67.399901] WARNING: CPU: 0 PID: 3172 at lib/refcount.c:28 
refcount_warn_saturate+0xc2/0x110
[   67.400124] RIP: 0010:refcount_warn_saturate+0xc2/0x110
[   67.400173] Call Trace:
[   67.400176]  
[   67.400181]  ttm_mem_evict_first+0x4fe/0x5b0 [ttm]
[   67.400216]  ttm_bo_mem_space+0x1e3/0x240 [ttm]
[   67.400239]  ttm_bo_validate+0xc7/0x190 [ttm]
[   67.400253]  ? ww_mutex_trylock+0x1b1/0x390
[   67.400266]  ttm_bo_init_reserved+0x183/0x1c0 [ttm]
[   67.400280]  ? __rwlock_init+0x3d/0x70
[   67.400292]  amdgpu_bo_create+0x1cd/0x4f0 [amdgpu]
[   67.400607]  ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu]
[   67.400980]  amdgpu_bo_create_user+0x38/0x70 [amdgpu]
[   67.401291]  amdgpu_gem_object_create+0x77/0xb0 [amdgpu]
[   67.401641]  ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu]
[   67.401958]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x228/0xa30 [amdgpu]
[   67.402433]  kfd_ioctl_alloc_memory_of_gpu+0x14e/0x390 [amdgpu]
[   67.402824]  ? lock_release+0x13f/0x290
[   67.402838]  kfd_ioctl+0x1e0/0x640 [amdgpu]
[   67.403205]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]
[   67.403579]  ? tomoyo_file_ioctl+0x19/0x20
[   67.403590]  __x64_sys_ioctl+0x95/0xd0
[   67.403601]  do_syscall_64+0x3b/0x90
[   67.403609]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Fixes: 9bff18d13473 ("drm/ttm: use per BO cleanup workers")

Signed-off-by: Lang Yu 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bd5dae4d1624..e047b191001c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -308,6 +308,9 @@ static void ttm_bo_delayed_delete(struct work_struct *work)
 
bo = container_of(work, typeof(*bo), delayed_delete);
 
+   if (!ttm_bo_get_unless_zero(bo))
+   return;
+
dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP, false,
  MAX_SCHEDULE_TIMEOUT);
dma_resv_lock(bo->base.resv, NULL);
-- 
2.25.1

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

[Jagan Teki]

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir  wrote:
>
> Hi Marek,
>
> On Wed, 5 Jul 2023 at 01:48, Marek Vasut  wrote:
> >
> > Do not generate the HS front and back porch gaps, the HSA gap and
> > EOT packet, as these packets are not required. This makes the bridge
> > work with Samsung DSIM on i.MX8MM and i.MX8MP.
>
> This patch broke display on Dragonboard 845c (SDM845) devboard running
> AOSP. This is what I see
> https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
> Reverting this patch fixes this regression for me.

Might be msm dsi host require proper handling on these updated
mode_flags? did they?

Thanks,
Jagan.

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

[Amit Pundir]

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut  wrote:
>
> Do not generate the HS front and back porch gaps, the HSA gap and
> EOT packet, as these packets are not required. This makes the bridge
> work with Samsung DSIM on i.MX8MM and i.MX8MP.

This patch broke display on Dragonboard 845c (SDM845) devboard running
AOSP. This is what I see
https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
Reverting this patch fixes this regression for me.

Regards,
Amit Pundir

>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Andrzej Hajda 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jagan Teki 
> Cc: Jernej Skrabec 
> Cc: Jonas Karlman 
> Cc: Laurent Pinchart 
> Cc: Michael Walle 
> Cc: Neil Armstrong 
> Cc: Robert Foss 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/bridge/lontium-lt9611.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index a25d21a7d5c19..151efe92711c4 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -774,7 +774,9 @@ static struct mipi_dsi_device *lt9611_attach_dsi(struct 
> lt9611 *lt9611,
> dsi->lanes = 4;
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO | 
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> - MIPI_DSI_MODE_VIDEO_HSE;
> + MIPI_DSI_MODE_VIDEO_HSE | 
> MIPI_DSI_MODE_VIDEO_NO_HSA |
> + MIPI_DSI_MODE_VIDEO_NO_HFP | 
> MIPI_DSI_MODE_VIDEO_NO_HBP |
> + MIPI_DSI_MODE_NO_EOT_PACKET;
>
> ret = devm_mipi_dsi_attach(dev, dsi);
> if (ret < 0) {
> --
> 2.39.2
>

[PATCH] virtio-gpu: Remove stride and layer_stride check for dGPU prime on VM

[Julia Zhang]

Remove stride and layer_stride check in virtio-gpu so that virgl can
send transfer data command with non zero stride to sync up data from
guest to host for dGPU prime on VM.

Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23896

Signed-off-by: Julia Zhang 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 5d05093014ac..4d3f8d36e3c7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -414,11 +414,6 @@ static int virtio_gpu_transfer_from_host_ioctl(struct 
drm_device *dev,
goto err_put_free;
}
 
-   if (!bo->host3d_blob && (args->stride || args->layer_stride)) {
-   ret = -EINVAL;
-   goto err_put_free;
-   }
-
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_free;
@@ -473,11 +468,6 @@ static int virtio_gpu_transfer_to_host_ioctl(struct 
drm_device *dev, void *data,
} else {
virtio_gpu_create_context(dev, file);
 
-   if (!bo->host3d_blob && (args->stride || args->layer_stride)) {
-   ret = -EINVAL;
-   goto err_put_free;
-   }
-
ret = virtio_gpu_array_lock_resv(objs);
if (ret != 0)
goto err_put_free;
-- 
2.34.1

Re: [PATCH 24/29] mm: vmscan: make global slab shrink lockless

[Qi Zheng]

On 2023/7/4 11:45, Qi Zheng wrote:



On 2023/7/4 00:39, Paul E. McKenney wrote:

On Fri, Jun 23, 2023 at 04:29:39PM +1000, Dave Chinner wrote:

On Thu, Jun 22, 2023 at 05:12:02PM +0200, Vlastimil Babka wrote:

On 6/22/23 10:53, Qi Zheng wrote:
@@ -1067,33 +1068,27 @@ static unsigned long shrink_slab(gfp_t 
gfp_mask, int nid,

  if (!mem_cgroup_disabled() && !mem_cgroup_is_root(memcg))
  return shrink_slab_memcg(gfp_mask, nid, memcg, priority);
-    if (!down_read_trylock(&shrinker_rwsem))
-    goto out;
-
-    list_for_each_entry(shrinker, &shrinker_list, list) {
+    rcu_read_lock();
+    list_for_each_entry_rcu(shrinker, &shrinker_list, list) {
  struct shrink_control sc = {
  .gfp_mask = gfp_mask,
  .nid = nid,
  .memcg = memcg,
  };
+    if (!shrinker_try_get(shrinker))
+    continue;
+    rcu_read_unlock();


I don't think you can do this unlock?


Sorry to be slow to respond here, this one fell through the cracks.
And thank you to Qi for reminding me!

If you do this unlock, you had jolly well better nail down the current
element (the one referenced by shrinker), for example, by acquiring an
explicit reference count on the object.  And presumably this is exactly
what shrinker_try_get() is doing.  And a look at your 24/29 confirms 
this,

at least assuming that shrinker->refcount is set to zero before the call
to synchronize_rcu() in free_module() *and* that synchronize_rcu() 
doesn't

start until *after* shrinker_put() calls complete().  Plus, as always,
the object must be removed from the list before the synchronize_rcu()
starts.  (On these parts of the puzzle, I defer to those more familiar
with this code path.  And I strongly suggest carefully commenting this
type of action-at-a-distance design pattern.)


Yeah, I think I've done it like above. A more detailed timing diagram is
below.



Why is this important?  Because otherwise that object might be freed
before you get to the call to rcu_read_lock() at the end of this loop.
And if that happens, list_for_each_entry_rcu() will be walking the
freelist, which is quite bad for the health and well-being of your 
kernel.


There are a few other ways to make this sort of thing work:

1.    Defer the shrinker_put() to the beginning of the loop.
You would need a flag initially set to zero, and then set to
one just before (or just after) the rcu_read_lock() above.
You would also need another shrinker_old pointer to track the
old pointer.  Then at the top of the loop, if the flag is set,
invoke shrinker_put() on shrinker_old.    This ensures that the
previous shrinker structure stays around long enough to allow
the loop to find the next shrinker structure in the list.

This approach is attractive when the removal code path
can invoke shrinker_put() after the grace period ends.

2.    Make shrinker_put() invoke call_rcu() when ->refcount reaches
zero, and have the callback function free the object.  This of
course requires adding an rcu_head structure to the shrinker
structure, which might or might not be a reasonable course of
action.  If adding that rcu_head is reasonable, this simplifies
the logic quite a bit.

3.    For the shrinker-structure-removal code path, remove the shrinker
structure, then remove the initial count from ->refcount,
and then keep doing grace periods until ->refcount is zero,
then do one more.  Of course, if the result of removing the
initial count was zero, then only a single additional grace
period is required.

This would need to be carefully commented, as it is a bit
unconventional.


Thanks for such a detailed addition!



There are probably many other ways, but just to give an idea of a few
other ways to do this.


+
  ret = do_shrink_slab(&sc, shrinker, priority);
  if (ret == SHRINK_EMPTY)
  ret = 0;
  freed += ret;
-    /*
- * Bail out if someone want to register a new shrinker to
- * prevent the registration from being stalled for long 
periods

- * by parallel ongoing shrinking.
- */
-    if (rwsem_is_contended(&shrinker_rwsem)) {
-    freed = freed ? : 1;
-    break;
-    }
-    }
-    up_read(&shrinker_rwsem);
-out:
+    rcu_read_lock();


That new rcu_read_lock() won't help AFAIK, the whole
list_for_each_entry_rcu() needs to be under the single 
rcu_read_lock() to be

safe.


Yeah, that's the pattern we've been taught and the one we can look
at and immediately say "this is safe".

This is a different pattern, as has been explained bi Qi, and I
think it *might* be safe.

*However.*

Right now I don't have time to go through a novel RCU list iteration
pattern it one step at to determine the correctness of the
algorithm. I'm mostly worried about list manipulations that can
occur outside rcu_read_lock() section bleeding into the RCU
critical section because

RE: [PATCH 05/10] drm/exynos: Use fbdev DMA helpers

[SR]

Hi,

> -Original Message-
> From: Thomas Zimmermann 
> Sent: Wednesday, July 5, 2023 12:50 AM
> To: javi...@redhat.com; maarten.lankho...@linux.intel.com;
> mrip...@kernel.org
> Cc: dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; linux-te...@vger.kernel.org; linux-
> fb...@vger.kernel.org; Thomas Zimmermann ; Inki Dae
> ; Seung-Woo Kim ; Kyungmin
> Park ; Krzysztof Kozlowski
> ; Alim Akhtar 
> Subject: [PATCH 05/10] drm/exynos: Use fbdev DMA helpers
> 
> Use fbdev's DMA helpers for fbdev emulation. They drivers previously
> used the I/O-memory helpers, while allocating DMA-able system memory.
> This could (in theory) result in bus errors from accessing the memory
> range.
> 
> This bug has been present since the exynos driver was first added.

Acked-by : Inki Dae 

Thanks,
Inki Dae

> 
> Signed-off-by: Thomas Zimmermann 
> Fixes: 1c248b7d2960 ("DRM: add DRM Driver for Samsung SoC EXYNOS4210.")
> Cc: Inki Dae 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Krzysztof Kozlowski 
> Cc: Alim Akhtar 
> ---
>  drivers/gpu/drm/exynos/Kconfig| 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig
> b/drivers/gpu/drm/exynos/Kconfig
> index 7ca7e1dab52c..661b42ad4873 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -7,7 +7,7 @@ config DRM_EXYNOS
>   select DRM_DISPLAY_HELPER if DRM_EXYNOS_DP
>   select DRM_KMS_HELPER
>   select VIDEOMODE_HELPERS
> - select FB_IO_HELPERS if DRM_FBDEV_EMULATION
> + select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
>   select SND_SOC_HDMI_CODEC if SND_SOC
>   help
> Choose this option if you have a Samsung SoC Exynos chipset.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index fdf65587f1fe..7ca3424b59ce 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -49,9 +49,9 @@ static void exynos_drm_fb_destroy(struct fb_info *info)
> 
>  static const struct fb_ops exynos_drm_fb_ops = {
>   .owner  = THIS_MODULE,
> - __FB_DEFAULT_IO_OPS_RDWR,
> + __FB_DEFAULT_DMA_OPS_RDWR,
>   DRM_FB_HELPER_DEFAULT_OPS,
> - __FB_DEFAULT_IO_OPS_DRAW,
> + __FB_DEFAULT_DMA_OPS_DRAW,
>   .fb_mmap= exynos_drm_fb_mmap,
>   .fb_destroy = exynos_drm_fb_destroy,
>  };
> --
> 2.41.0

Re: [11/12] fbdev/core: Protect edid_info with CONFIG_ARCH_HAS_EDID_INFO

[Sui Jingfeng]

Hi,


On 2023/6/29 19:45, Thomas Zimmermann wrote:

Guard usage of edid_info with CONFIG_ARCH_HAS_EDID_INFO instead
of CONFIG_X86. No functional changes.

Signed-off-by: Thomas Zimmermann 



Reviewed-by: Sui Jingfeng 



Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: Randy Dunlap 
---
  drivers/video/fbdev/core/fbmon.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 35be4431f649a..9ae063021e431 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1480,17 +1480,19 @@ int fb_validate_mode(const struct fb_var_screeninfo 
*var, struct fb_info *info)
-EINVAL : 0;
  }
  
-#if defined(CONFIG_FIRMWARE_EDID) && defined(CONFIG_X86)

+#if defined(CONFIG_FIRMWARE_EDID)
  const unsigned char *fb_firmware_edid(struct fb_info *info)
  {
unsigned char *edid = NULL;
  
+#if defined(CONFIG_ARCH_HAS_EDID_INFO)

/*
 * We need to ensure that the EDID block is only
 * returned for the primary graphics adapter.
 */
if (fb_is_primary_device(info))
edid = edid_info.dummy;
+#endif
  
  	return edid;

  }

Re: [03/12] sysfb: Do not include from sysfb header

[Sui Jingfeng]

On 2023/6/29 19:45, Thomas Zimmermann wrote:

The header file  does not need anything from
. Declare struct screen_info and remove
the include statements.

Signed-off-by: Thomas Zimmermann 
Cc: Ard Biesheuvel 
Cc: Hans de Goede 
Cc: Javier Martinez Canillas 
Reviewed-by: Javier Martinez Canillas 



Reviewed-by: Sui Jingfeng 



---
  include/linux/sysfb.h | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index c1ef5fc60a3cb..19cb803dd5ecd 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -9,7 +9,8 @@
  
  #include 

  #include 
-#include 
+
+struct screen_info;
  
  enum {

M_I17,  /* 17-Inch iMac */

Re: [01/12] efi: Do not include from EFI header

[Sui Jingfeng]

Hi, Thomas


I love your patch, LoongArch also have UEFI GOP support,

Maybe the arch/loongarch/kernel/efi.c don't include the '#include 
' explicitly.



```

diff --git a/arch/loongarch/kernel/efi.c b/arch/loongarch/kernel/efi.c
index 3d448fef3af4..04f4d217aefb 100644
--- a/arch/loongarch/kernel/efi.c
+++ b/arch/loongarch/kernel/efi.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
```


On 2023/6/29 19:45, Thomas Zimmermann wrote:

The header file  does not need anything from
. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.

Signed-off-by: Thomas Zimmermann 
Cc: Ard Biesheuvel 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Reviewed-by: Javier Martinez Canillas 


With the above issue solved, please take my R-B if you would like.


Reviewed-by: Sui Jingfeng 


---
  arch/arm/kernel/efi.c | 2 ++
  arch/arm64/kernel/efi.c   | 1 +
  drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++
  drivers/firmware/efi/libstub/screen_info.c| 2 ++
  include/linux/efi.h   | 3 ++-
  5 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
index e2b9d2618c672..e94655ef16bb3 100644
--- a/arch/arm/kernel/efi.c
+++ b/arch/arm/kernel/efi.c
@@ -5,6 +5,8 @@
  
  #include 

  #include 
+#include 
+
  #include 
  #include 
  #include 
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index baab8dd3ead3c..3afbe503b066f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -9,6 +9,7 @@
  
  #include 

  #include 
+#include 
  
  #include 

  #include 
diff --git a/drivers/firmware/efi/libstub/efi-stub-entry.c 
b/drivers/firmware/efi/libstub/efi-stub-entry.c
index cc4dcaea67fa6..2f1902e5d4075 100644
--- a/drivers/firmware/efi/libstub/efi-stub-entry.c
+++ b/drivers/firmware/efi/libstub/efi-stub-entry.c
@@ -1,6 +1,8 @@
  // SPDX-License-Identifier: GPL-2.0-only
  
  #include 

+#include 
+
  #include 
  
  #include "efistub.h"

diff --git a/drivers/firmware/efi/libstub/screen_info.c 
b/drivers/firmware/efi/libstub/screen_info.c
index 4be1c4d1f922b..a51ec201ca3cb 100644
--- a/drivers/firmware/efi/libstub/screen_info.c
+++ b/drivers/firmware/efi/libstub/screen_info.c
@@ -1,6 +1,8 @@
  // SPDX-License-Identifier: GPL-2.0
  
  #include 

+#include 
+
  #include 
  
  #include "efistub.h"

diff --git a/include/linux/efi.h b/include/linux/efi.h
index 571d1a6e1b744..360895a5572c0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -24,10 +24,11 @@
  #include 
  #include 
  #include 
-#include 
  
  #include 
  
+struct screen_info;

+
  #define EFI_SUCCESS   0
  #define EFI_LOAD_ERROR( 1 | (1UL << (BITS_PER_LONG-1)))
  #define EFI_INVALID_PARAMETER ( 2 | (1UL << (BITS_PER_LONG-1)))

Re: [08/12] drivers/firmware: Remove trailing whitespaces

[Sui Jingfeng]

Hi,

On 2023/6/29 19:45, Thomas Zimmermann wrote:

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 



Reviewed-by: Sui Jingfeng 



---
  drivers/firmware/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index b59e3041fd627..0432737bbb8b4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -99,7 +99,7 @@ config EFI_PCDP
  You must also enable the appropriate drivers (serial, VGA, etc.)
  
  	  See DIG64_HCDPv20_042804.pdf available from

- 
+ 
  
  config DMIID

  bool "Export DMI identification via sysfs to userspace"

Re: [05/12] arch: Remove trailing whitespaces

[Sui Jingfeng]

On 2023/6/29 19:45, Thomas Zimmermann wrote:

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: Andrew Morton 
Cc: Geert Uytterhoeven 
Cc: Arnd Bergmann 
Cc: "Kirill A. Shutemov" 
Cc: Anshuman Khandual 
Cc: Niklas Schnelle 
Cc: Zi Yan 
Cc: "Mike Rapoport (IBM)" 
Cc: Peter Zijlstra 
Reviewed-by: Javier Martinez Canillas 


Reviewed-by: Sui Jingfeng 


---
  arch/ia64/Kconfig | 4 ++--
  arch/sh/Kconfig   | 6 +++---
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 21fa63ce5ffc0..e79f15e32a451 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -260,7 +260,7 @@ config PERMIT_BSP_REMOVE
default n
help
Say Y here if your platform SAL will support removal of BSP with 
HOTPLUG_CPU
-   support.
+   support.
  
  config FORCE_CPEI_RETARGET

bool "Force assumption that CPEI can be re-targeted"
@@ -335,7 +335,7 @@ config IA64_PALINFO
  config IA64_MC_ERR_INJECT
tristate "MC error injection support"
help
- Adds support for MC error injection. If enabled, the kernel
+ Adds support for MC error injection. If enabled, the kernel
  will provide a sysfs interface for user applications to
  call MC error injection PAL procedures to inject various errors.
  This is a useful tool for MCA testing.
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 9652d367fc377..04b9550cf0070 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -234,7 +234,7 @@ config CPU_SUBTYPE_SH7201
select CPU_SH2A
select CPU_HAS_FPU
select SYS_SUPPORTS_SH_MTU2
-
+
  config CPU_SUBTYPE_SH7203
bool "Support SH7203 processor"
select CPU_SH2A
@@ -496,7 +496,7 @@ config CPU_SUBTYPE_SH7366
  endchoice
  
  source "arch/sh/mm/Kconfig"

-
+
  source "arch/sh/Kconfig.cpu"
  
  source "arch/sh/boards/Kconfig"

@@ -647,7 +647,7 @@ config GUSA
  This is the default implementation for both UP and non-ll/sc
  CPUs, and is used by the libc, amongst others.
  
-	  For additional information, design information can be found

+ For additional information, design information can be found
  in .
  
  	  This should only be disabled for special cases where alternate

Re: [06/12] arch: Declare screen_info in

[Sui Jingfeng]

Hi, Thomas


I love your patch, yet after applied your patch, the linux kernel fail 
to compile on my LoongArch machine.



```

  CC  arch/loongarch/kernel/efi.o
arch/loongarch/kernel/efi.c: In function ‘init_screen_info’:
arch/loongarch/kernel/efi.c:77:54: error: invalid application of 
‘sizeof’ to incomplete type ‘struct screen_info’

   77 | si = early_memremap(screen_info_table, sizeof(*si));
  |  ^
arch/loongarch/kernel/efi.c:82:9: error: ‘screen_info’ undeclared (first 
use in this function)

   82 | screen_info = *si;
  | ^~~
arch/loongarch/kernel/efi.c:82:9: note: each undeclared identifier is 
reported only once for each function it appears in
arch/loongarch/kernel/efi.c:82:23: error: invalid use of undefined type 
‘struct screen_info’

   82 | screen_info = *si;
  |   ^
arch/loongarch/kernel/efi.c:83:29: error: invalid application of 
‘sizeof’ to incomplete type ‘struct screen_info’

   83 | memset(si, 0, sizeof(*si));
  | ^
arch/loongarch/kernel/efi.c:84:34: error: invalid application of 
‘sizeof’ to incomplete type ‘struct screen_info’

   84 | early_memunmap(si, sizeof(*si));
  |  ^
make[3]: *** [scripts/Makefile.build:252: arch/loongarch/kernel/efi.o] 
Error 1

make[3]: *** Waiting for unfinished jobs
make[2]: *** [scripts/Makefile.build:494: arch/loongarch/kernel] Error 2
make[1]: *** [scripts/Makefile.build:494: arch/loongarch] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:2026: .] Error 2

```

On 2023/6/29 19:45, Thomas Zimmermann wrote:

The variable screen_info does not exist on all architectures. Declare
it in . All architectures that do declare it
will provide it via .

Add the Kconfig token ARCH_HAS_SCREEN_INFO to guard against access on
architectures that don't provide screen_info.

Signed-off-by: Thomas Zimmermann 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Guo Ren 
Cc: Brian Cain 
Cc: Huacai Chen 
Cc: WANG Xuerui 
Cc: Thomas Bogendoerfer 
Cc: Dinh Nguyen 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Helge Deller 
Cc: Arnd Bergmann 
Cc: Kees Cook 
Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Cc: Frederic Weisbecker 
Cc: Andrew Morton 
Cc: Ard Biesheuvel 
Cc: Sami Tolvanen 
Cc: Juerg Haefliger 
Cc: Geert Uytterhoeven 
Cc: Anshuman Khandual 
Cc: Niklas Schnelle 
Cc: "Russell King (Oracle)" 
Cc: Linus Walleij 
Cc: Sebastian Reichel 
Cc: "Mike Rapoport (IBM)" 
Cc: "Kirill A. Shutemov" 
Cc: Zi Yan 
Acked-by: WANG Xuerui  # loongarch
---
  arch/Kconfig  |  6 ++
  arch/alpha/Kconfig|  1 +
  arch/arm/Kconfig  |  1 +
  arch/arm64/Kconfig|  1 +
  arch/csky/Kconfig |  1 +
  arch/hexagon/Kconfig  |  1 +
  arch/ia64/Kconfig |  1 +
  arch/loongarch/Kconfig|  1 +
  arch/mips/Kconfig |  1 +
  arch/nios2/Kconfig|  1 +
  arch/powerpc/Kconfig  |  1 +
  arch/riscv/Kconfig|  1 +
  arch/sh/Kconfig   |  1 +
  arch/sparc/Kconfig|  1 +
  arch/x86/Kconfig  |  1 +
  arch/xtensa/Kconfig   |  1 +
  drivers/video/Kconfig |  3 +++
  include/asm-generic/Kbuild|  1 +
  include/asm-generic/screen_info.h | 12 
  include/linux/screen_info.h   |  2 +-
  20 files changed, 38 insertions(+), 1 deletion(-)
  create mode 100644 include/asm-generic/screen_info.h

diff --git a/arch/Kconfig b/arch/Kconfig
index 205fd23e0cada..2f58293fd7bcb 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
  address translations. Page table walkers that clear the accessed bit
  may use this capability to reduce their search space.
  
+config ARCH_HAS_SCREEN_INFO

+   bool
+   help
+ Selected by architectures that provide a global instance of
+ screen_info.
+
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index a5c2b1aa46b02..d749011d88b14 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -4,6 +4,7 @@ config ALPHA
default y
select ARCH_32BIT_USTAT_F_TINODE
select ARCH_HAS_CURRENT_STACK_POINTER
+   select ARCH_HAS_SCREEN_INFO
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select ARCH_NO

Re: [PATCH v2] drm/i915: Refactor PAT/cache handling

[Yang, Fei]

>>> From: Tvrtko Ursulin 
>>>
>>> Informal commit message for now.
>>>
>>> I got a bit impatient and curious to see if the idea we discussed would
>>> work so sketched something out. I think it is what I was describing back
>>> then..
>>>
>>> So high level idea is to teach the driver what caching modes are hidden
>>> behind PAT indices. Given you already had that in static tables, if we
>>> just turn the tables a bit around and add a driver abstraction of caching
>>> modes this is what happens:
>>>
>>>  * We can lose the ugly runtime i915_gem_get_pat_index.
>>>
>>>  * We can have a smarter i915_gem_object_has_cache_level, which now can
>>>use the above mentioned table to understand the caching modes and so
>>>does not have to pessimistically return true for _any_ input when user
>>>has set the PAT index. This may improve things even for MTL.
>>>
>>>  * We can simplify the debugfs printout to be platform agnostic.
>>>
>>>  * We are perhaps opening the door to un-regress the dodgy addition
>>>made to i915_gem_object_can_bypass_llc? See QQQ/FIXME in the patch.
>>>
>>> I hope I did not forget anything, but anyway, please have a read and see
>>> what you think. I think it has potential.
>>>
>>> Proper commit message can come later.
>>>
>>> Signed-off-by: Tvrtko Ursulin 
>>> Cc: Fei Yang 
>>> ---
>>>  drivers/gpu/drm/i915/Makefile |   1 +
>>>  drivers/gpu/drm/i915/display/intel_dpt.c  |   2 +-
>>>  drivers/gpu/drm/i915/display/intel_fb_pin.c   |   2 +-
>>>  .../drm/i915/display/intel_plane_initial.c|   4 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_domain.c|  66 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_domain.h|   7 +-
>>>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  13 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   6 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  10 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_object.c| 116 +
>>>  drivers/gpu/drm/i915/gem/i915_gem_object.h|   9 +-
>>>  .../gpu/drm/i915/gem/i915_gem_object_types.h  | 117 +++---
>>>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  10 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  13 +-
>>>  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  43 ---
>>>  drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   2 +-
>>>  .../drm/i915/gem/selftests/huge_gem_object.c  |   6 +-
>>>  .../gpu/drm/i915/gem/selftests/huge_pages.c   |   8 +-
>>>  drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   4 +-
>>>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  19 +--
>>>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
>>>  drivers/gpu/drm/i915/gt/intel_ggtt.c  |  33 ++---
>>>  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   4 +-
>>>  drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
>>>  drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +-
>>>  drivers/gpu/drm/i915/gt/intel_migrate.c   |  11 +-
>>>  drivers/gpu/drm/i915/gt/intel_ppgtt.c |   6 +-
>>>  .../gpu/drm/i915/gt/intel_ring_submission.c   |   2 +-
>>>  drivers/gpu/drm/i915/gt/intel_timeline.c  |   2 +-
>>>  drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   2 +-
>>>  drivers/gpu/drm/i915/gt/selftest_migrate.c|   9 +-
>>>  drivers/gpu/drm/i915/gt/selftest_reset.c  |  14 +--
>>>  drivers/gpu/drm/i915/gt/selftest_timeline.c   |   1 +
>>>  drivers/gpu/drm/i915/gt/selftest_tlb.c|   5 +-
>>>  .../gpu/drm/i915/gt/selftest_workarounds.c|   2 +-
>>>  drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
>>>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   8 +-
>>>  drivers/gpu/drm/i915/i915_cache.c |  72 +++
>>>  drivers/gpu/drm/i915/i915_cache.h |  49 
>>>  drivers/gpu/drm/i915/i915_debugfs.c   |  65 +++---
>>>  drivers/gpu/drm/i915/i915_driver.c|   5 +
>>>  drivers/gpu/drm/i915/i915_drv.h   |   3 +
>>>  drivers/gpu/drm/i915/i915_gem.c   |  21 +---
>>>  drivers/gpu/drm/i915/i915_gpu_error.c |   7 +-
>>>  drivers/gpu/drm/i915/i915_pci.c   |  83 +++--
>>>  drivers/gpu/drm/i915/i915_perf.c  |   2 +-
>>>  drivers/gpu/drm/i915/intel_device_info.h  |   6 +-
>>>  drivers/gpu/drm/i915/selftests/i915_gem.c |   5 +-
>>>  .../gpu/drm/i915/selftests/i915_gem_evict.c   |   8 +-
>>>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  13 +-
>>>  drivers/gpu/drm/i915/selftests/igt_spinner.c  |   2 +-
>>>  .../drm/i915/selftests/intel_memory_region.c  |   4 +-
>>>  .../gpu/drm/i915/selftests/mock_gem_device.c  |  12 +-
>>>  drivers/gpu/drm/i915/selftests/mock_region.c  |   2 +-
>>>  54 files changed, 440 insertions(+), 485 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/i915/i915_cache.c
>>>  create mode 100644 drivers/gpu/drm/i915/i915_cache.h
>>>
>>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>>> index 2be9dd960540..2c3da8f0c78e 100644
>>> --- a/drivers/gpu/drm/i915/Makefile
>>> +++ 

Re: [PATCH] drm/vmwgfx: Fix shader stage validation

[Dave Airlie]

What tree has/is this landing via, not seeing it upstream yet.

Dave.

On Sat, 17 Jun 2023 at 20:25, Martin Krastev (VMware)
 wrote:
>
> From: Martin Krastev 
>
>
> Looks good!
>
>
> Reviewed-by: Martin Krastev 
>
>
> Regards,
>
> Martin
>
>
> On 16.06.23 г. 22:09 ч., Zack Rusin wrote:
> > From: Zack Rusin 
> >
> > For multiple commands the driver was not correctly validating the shader
> > stages resulting in possible kernel oopses. The validation code was only.
> > if ever, checking the upper bound on the shader stages but never a lower
> > bound (valid shader stages start at 1 not 0).
> >
> > Fixes kernel oopses ending up in vmw_binding_add, e.g.:
> > Oops:  [#1] PREEMPT SMP PTI
> > CPU: 1 PID: 2443 Comm: testcase Not tainted 6.3.0-rc4-vmwgfx #1
> > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference 
> > Platform, BIOS 6.00 11/12/2020
> > RIP: 0010:vmw_binding_add+0x4c/0x140 [vmwgfx]
> > Code: 7e 30 49 83 ff 0e 0f 87 ea 00 00 00 4b 8d 04 7f 89 d2 89 cb 48 c1 e0 
> > 03 4c 8b b0 40 3d 93 c0 48 8b 80 48 3d 93 c0 49 0f af de <48> 03 1c d0 4c 
> > 01 e3 49 8>
> > RSP: 0018:b8014416b968 EFLAGS: 00010206
> > RAX: c0933ec0 RBX:  RCX: 
> > RDX:  RSI: b8014416b9c0 RDI: b8014316f000
> > RBP: b8014416b998 R08: 0003 R09: 746f6c735f726564
> > R10: aaf2bda0 R11: 732e676e69646e69 R12: b8014316f000
> > R13: b8014416b9c0 R14: 0040 R15: 0006
> > FS:  7fba8c0af740() GS:8a1277c8() knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2: 0007c0933eb8 CR3: 000118244001 CR4: 003706e0
> > Call Trace:
> >   
> >   vmw_view_bindings_add+0xf5/0x1b0 [vmwgfx]
> >   ? ___drm_dbg+0x8a/0xb0 [drm]
> >   vmw_cmd_dx_set_shader_res+0x8f/0xc0 [vmwgfx]
> >   vmw_execbuf_process+0x590/0x1360 [vmwgfx]
> >   vmw_execbuf_ioctl+0x173/0x370 [vmwgfx]
> >   ? __drm_dev_dbg+0xb4/0xe0 [drm]
> >   ? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
> >   drm_ioctl_kernel+0xbc/0x160 [drm]
> >   drm_ioctl+0x2d2/0x580 [drm]
> >   ? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
> >   ? do_fault+0x1a6/0x420
> >   vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
> >   vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
> >   __x64_sys_ioctl+0x96/0xd0
> >   do_syscall_64+0x5d/0x90
> >   ? handle_mm_fault+0xe4/0x2f0
> >   ? debug_smp_processor_id+0x1b/0x30
> >   ? fpregs_assert_state_consistent+0x2e/0x50
> >   ? exit_to_user_mode_prepare+0x40/0x180
> >   ? irqentry_exit_to_user_mode+0xd/0x20
> >   ? irqentry_exit+0x3f/0x50
> >   ? exc_page_fault+0x8b/0x180
> >   entry_SYSCALL_64_after_hwframe+0x72/0xdc
> >
> > Signed-off-by: Zack Rusin 
> > Cc: secur...@openanolis.org
> > Reported-by: Ziming Zhang 
> > Testcase-found-by: Niels De Graef 
> > Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
> > Cc:  # v4.3+
> > ---
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++
> >   drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 29 ++---
> >   2 files changed, 23 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index 3810a9984a7f..58bfdf203eca 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -1513,4 +1513,16 @@ static inline bool vmw_has_fences(struct vmw_private 
> > *vmw)
> >   return (vmw_fifo_caps(vmw) & SVGA_FIFO_CAP_FENCE) != 0;
> >   }
> >
> > +static inline bool vmw_shadertype_is_valid(enum vmw_sm_type shader_model,
> > +u32 shader_type)
> > +{
> > + SVGA3dShaderType max_allowed = SVGA3D_SHADERTYPE_PREDX_MAX;
> > +
> > + if (shader_model >= VMW_SM_5)
> > + max_allowed = SVGA3D_SHADERTYPE_MAX;
> > + else if (shader_model >= VMW_SM_4)
> > + max_allowed = SVGA3D_SHADERTYPE_DX10_MAX;
> > + return shader_type >= SVGA3D_SHADERTYPE_MIN && shader_type < 
> > max_allowed;
> > +}
> > +
> >   #endif
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > index 6b9aa2b4ef54..d30c0e3d3ab7 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> > @@ -1992,7 +1992,7 @@ static int vmw_cmd_set_shader(struct vmw_private 
> > *dev_priv,
> >
> >   cmd = container_of(header, typeof(*cmd), header);
> >
> > - if (cmd->body.type >= SVGA3D_SHADERTYPE_PREDX_MAX) {
> > + if (!vmw_shadertype_is_valid(VMW_SM_LEGACY, cmd->body.type)) {
> >   VMW_DEBUG_USER("Illegal shader type %u.\n",
> >  (unsigned int) cmd->body.type);
> >   return -EINVAL;
> > @@ -2115,8 +2115,6 @@ vmw_cmd_dx_set_single_constant_buffer(struct 
> > vmw_private *dev_priv,
> > SVGA3dCmdHeader *header)
> >   {
> >   VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdDXSetSingleConstantBuffer);
> > - SV

Re: [v4, PATCH] drm/mediatek: add dma buffer control for drm plane disable

[kernel test robot]

Hi Yongqiang,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.4 next-20230704]
[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/Yongqiang-Niu/drm-mediatek-add-dma-buffer-control-for-drm-plane-disable/20230704-170623
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230704090432.5844-1-yongqiang.niu%40mediatek.com
patch subject: [v4, PATCH] drm/mediatek: add dma buffer control for drm plane 
disable
config: arm64-defconfig 
(https://download.01.org/0day-ci/archive/20230705/202307050325.qzv71se7-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 12.3.0
reproduce: 
(https://download.01.org/0day-ci/archive/20230705/202307050325.qzv71se7-...@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/202307050325.qzv71se7-...@intel.com/

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

>> ERROR: modpost: module mediatek-drm uses symbol dma_buf_put from namespace 
>> DMA_BUF, but does not import it.

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

Re: [PATCH v4 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field

[Abhinav Kumar]

On 7/4/2023 10:28 AM, Dmitry Baryshkov wrote:

On Tue, 4 Jul 2023 at 19:10, Abhinav Kumar  wrote:




On 7/4/2023 4:52 AM, Dmitry Baryshkov wrote:

On Tue, 4 Jul 2023 at 13:06, Dmitry Baryshkov
 wrote:


On Tue, 4 Jul 2023 at 07:04, Abhinav Kumar  wrote:




On 7/3/2023 7:20 PM, Dmitry Baryshkov wrote:

On 03/07/2023 05:01, Abhinav Kumar wrote:



On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:

There is always a single MDP TOP block. Drop the mdp_count field and
stop declaring dpu_mdp_cfg instances as arrays.

Tested-by: Marijn Suijten 
Signed-off-by: Dmitry Baryshkov 
---


The change drops mdp_count and stops using the array which is fine and
I will support that.

But looking at the pattern I saw while using core_revision, both
DPU_MDP_VSYNC_SEL and DPU_MDP_AUDIO_SELECT can also be dropped from
the catalog in favor of using core_revision.

Hence for that, I request you not to stop passing dpu_mdss_cfg to
dpu_hw_mdptop_init as that has the necessary information of
core_revision.


Sure, I'll restore it. Please note, however, that it might be better to
pass struct dpu_caps instead of the full struct dpu_mdss_cfg.



Thanks for restoring.

Can you pls explain this better? dpu_core_rev is part of dpu_mdss_cfg,
so dpu_caps wont be enough for this one.


Oh, true. For some reason I thought that version is a part of dpu_caps.


And after additional thought. Maybe it would be better to add a
separate struct dpu_mdss_version and pass it to the hw block init
functions?



I would like to see this evolve. Today, we are assuming that only the hw
block init functions are the places we would use those.

  From what I recall, the DSC over DP series needed the core_revision in
the timing gen code somewhere.


I hope you are talking about the DPU driver here, not about the DP
driver. For the DP driver please use struct msm_dp_desc.



Yes DPU driver.



If we see that pattern is possible once that lands, why not.

Right now, I would leave it at dpu_mdss_cfg.








.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h   |  7 +---
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h   |  7 +---
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h   |  7 +---
.../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h  |  7 +---
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h|  7 +---
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h|  7 +---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 38 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h|  8 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  4 +-
19 files changed, 41 insertions(+), 115 deletions(-)






--
With best wishes
Dmitry

Re: drm/drm_gem.c: Remove surplus else after return

[Sui Jingfeng]

Hi,

On 2023/7/5 02:14, Sui Jingfeng wrote:


I have merge this patch with the dim tool, by using the following 
command, 



I have merged(pushed) this patch just now to drm-misc-next branch.

Re: drm/drm_gem.c: Remove surplus else after return

[Sui Jingfeng]

Hi,  Thomas


On 2023/6/22 18:18, Sui Jingfeng wrote:

else is not generally useful after return

Signed-off-by: Sui Jingfeng 
Reviewed-by: Thomas Zimmermann 
---
  drivers/gpu/drm/drm_gem.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1a5a2cd0d4ec..c18686f434d4 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1150,8 +1150,8 @@ int drm_gem_pin(struct drm_gem_object *obj)
  {
if (obj->funcs->pin)
return obj->funcs->pin(obj);
-   else
-   return 0;
+
+   return 0;
  }
  
  void drm_gem_unpin(struct drm_gem_object *obj)



I have merge this patch with the dim tool, by using the following command,


 ./dim push-branch drm-misc-next


Is this looks fine?

I'm so worry about the dim tool now.

I want to make sure if I do the things correctly.

[PATCH v2] backlight: led_bl: fix initial power state

[Mans Rullgard]

The condition for the initial power state based on the default
brightness value is reversed.  Fix it.

Furthermore, use the actual state of the LEDs rather than the default
brightness specified in the devicetree as the latter should not cause
the backlight to be automatically turned on.

If the backlight device is not linked to any display, set the initial
power to on unconditionally.

Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
Signed-off-by: Mans Rullgard 
---
Changes in v2:
- Use the reported LED state to set initial power state
- Always power on if no phandle in DT
---
 drivers/video/backlight/led_bl.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 3259292fda76..bbf1673b1fb0 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -176,6 +176,7 @@ static int led_bl_probe(struct platform_device *pdev)
 {
struct backlight_properties props;
struct led_bl_data *priv;
+   int init_brightness;
int ret, i;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
@@ -190,6 +191,8 @@ static int led_bl_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   init_brightness = priv->default_brightness;
+
ret = led_bl_parse_levels(&pdev->dev, priv);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to parse DT data\n");
@@ -200,8 +203,8 @@ static int led_bl_probe(struct platform_device *pdev)
props.type = BACKLIGHT_RAW;
props.max_brightness = priv->max_brightness;
props.brightness = priv->default_brightness;
-   props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
- FB_BLANK_UNBLANK;
+   props.power = (init_brightness || !pdev->dev.of_node->phandle) ?
+   FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
&pdev->dev, priv, &led_bl_ops, &props);
if (IS_ERR(priv->bl_dev)) {
-- 
2.41.0

[PATCH] backlight: led_bl: fix initial power state

[Mans Rullgard]

The condition for the initial power state based on the default
brightness value is reversed.  Fix it.

Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
Signed-off-by: Mans Rullgard 
---
 drivers/video/backlight/led_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 3259292fda76..28e83618a296 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
props.type = BACKLIGHT_RAW;
props.max_brightness = priv->max_brightness;
props.brightness = priv->default_brightness;
-   props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
- FB_BLANK_UNBLANK;
+   props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
+ FB_BLANK_POWERDOWN;
priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
&pdev->dev, priv, &led_bl_ops, &props);
if (IS_ERR(priv->bl_dev)) {
-- 
2.41.0

Re: [PATCH] dt-bindings: cleanup DTS example whitespaces

[Jonas Gorski]

On Sun, 2 Jul 2023 at 20:24, Krzysztof Kozlowski
 wrote:
>
> The DTS code coding style expects spaces around '=' sign.
>
> Signed-off-by: Krzysztof Kozlowski 
>
> ---
>
> Rob,
>
> Maybe this could go via your tree? Rebased on your for-next:
> v6.4-rc2-45-gf0ac35049606
> ---
>  .../bindings/arm/arm,coresight-cti.yaml| 18 +-
>  .../bindings/arm/keystone/ti,sci.yaml  |  8 
>  .../devicetree/bindings/display/msm/gmu.yaml   |  2 +-
>  .../display/panel/samsung,s6e8aa0.yaml |  2 +-
>  .../display/rockchip/rockchip-vop.yaml |  4 ++--
>  .../bindings/iio/adc/ti,adc108s102.yaml|  2 +-
>  .../bindings/media/renesas,rzg2l-cru.yaml  |  4 ++--
>  .../devicetree/bindings/media/renesas,vin.yaml |  4 ++--
>  .../devicetree/bindings/mtd/mtd-physmap.yaml   |  2 +-
>  .../bindings/net/mediatek-dwmac.yaml   |  2 +-
>  .../bindings/perf/amlogic,g12-ddr-pmu.yaml |  4 ++--
>  .../bindings/phy/mediatek,dsi-phy.yaml |  2 +-
>  .../remoteproc/amlogic,meson-mx-ao-arc.yaml|  2 +-
>  .../devicetree/bindings/usb/mediatek,mtu3.yaml |  2 +-
>  .../devicetree/bindings/usb/ti,am62-usb.yaml   |  2 +-
>  15 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml 
> b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
> index 0c5b875cb654..d6c84b6e7fe6 100644
> --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
> @@ -287,7 +287,7 @@ examples:
>  arm,trig-in-sigs = <0 1>;
>  arm,trig-in-types =PE_PMUIRQ>;
> -arm,trig-out-sigs=<0 1 2 >;
> +arm,trig-out-sigs = <0 1 2 >;

There's a space before the closing > you could drop as well.

Best Regards,
Jonas

[PATCH] fbdev: imxfb: Convert to devm_platform_ioremap_resource()

[Yangtao Li]

Use devm_platform_ioremap_resource() to simplify code.

Signed-off-by: Yangtao Li 
---
 drivers/video/fbdev/imxfb.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index adf36690c342..517eb65bbaa6 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -868,7 +868,6 @@ static int imxfb_probe(struct platform_device *pdev)
struct imxfb_info *fbi;
struct lcd_device *lcd;
struct fb_info *info;
-   struct resource *res;
struct imx_fb_videomode *m;
const struct of_device_id *of_id;
struct device_node *display_np;
@@ -885,10 +884,6 @@ static int imxfb_probe(struct platform_device *pdev)
if (of_id)
pdev->id_entry = of_id->data;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -ENODEV;
-
info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
if (!info)
return -ENOMEM;
@@ -970,7 +965,7 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_getclock;
}
 
-   fbi->regs = devm_ioremap_resource(&pdev->dev, res);
+   fbi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fbi->regs)) {
ret = PTR_ERR(fbi->regs);
goto failed_ioremap;
@@ -1043,7 +1038,6 @@ static int imxfb_probe(struct platform_device *pdev)
 failed_map:
 failed_ioremap:
 failed_getclock:
-   release_mem_region(res->start, resource_size(res));
 failed_of_parse:
kfree(info->pseudo_palette);
 failed_init:
-- 
2.39.0

Re: [PATCH] backlight: led_bl: fix initial power state

[Måns Rullgård]

Daniel Thompson  writes:

> On Tue, Jul 04, 2023 at 03:07:50PM +0100, Mans Rullgard wrote:
>> The condition for the initial power state based on the default
>> brightness value is reversed.  Fix it.
>>
>> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
>> Signed-off-by: Mans Rullgard 
>> ---
>>  drivers/video/backlight/led_bl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/backlight/led_bl.c 
>> b/drivers/video/backlight/led_bl.c
>> index 3259292fda76..28e83618a296 100644
>> --- a/drivers/video/backlight/led_bl.c
>> +++ b/drivers/video/backlight/led_bl.c
>> @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
>>  props.type = BACKLIGHT_RAW;
>>  props.max_brightness = priv->max_brightness;
>>  props.brightness = priv->default_brightness;
>> -props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
>> -  FB_BLANK_UNBLANK;
>> +props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
>> +  FB_BLANK_POWERDOWN;
>
> The logic was wrong before but I think will still be wrong after the
> change too (e.g. the bogus logic is probably avoiding backlight flicker
> in some use cases).
>
> The logic here needs to be similar to what pwm_bl.c implements in
> pwm_backlight_initial_power_state(). Whilst it might be better
> to implement this in led_bl_get_leds() let me show what I mean
> in code that fits in the current line:
>
>   /*
>* Activate the backlight if the LEDs are already lit *or*
>* there is no phandle link (meaning the backlight power
>* state cannot be synced with the display state).
>*/
>   props.power = (active_at_boot || !dev->node->phandle) ?
>   FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
>
> Note that active_at_boot is not the same as (priv->default_brightness > 0)
> since the value read by led_bl_get_leds() can be clobbered when we
> parse the properties.

Am I understanding correctly that the code should be using the
default_brightness value as set by led_bl_get_leds() to determine the
initial power state, not whatever default value the devicetree provides?

-- 
Måns Rullgård

Re: [PATCH v4 1/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits

[Simon Ser]

On Tuesday, July 4th, 2023 at 19:06, Sebastian Wick  
wrote:

> > + * When used with atomic uAPI, the driver will return an error if the 
> > hardware
> > + * doesn't support performing an asynchronous page-flip for this update.
> > + * User-space should handle this, e.g. by falling back to a regular 
> > page-flip.
> > + *
> > + * Note, some hardware might need to perform one last synchronous page-flip
> > + * before being able to switch to asynchronous page-flips. As an exception,
> > + * the driver will return success even though that first page-flip is not
> > + * asynchronous.
> 
> What would happen if one commits another async KMS update before the
> first page flip? Does one receive EAGAIN, does it amend the previous
> commit? What happens to the timing feedback?
> 
> This seems really risky to include tbh. I would prefer if we would not
> add such special cases for now.

This is not a new case, i915 already does this with the legacy API to
address some hw issues. Sadly I don't think we can do anything about
it.

[PATCH v4 4/4] drm/msm/mdp5: move resource allocation to the _probe function

[Dmitry Baryshkov]

To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 100 ++-
 1 file changed, 44 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 83a5b3bd09d9..52f176e08690 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -554,20 +554,16 @@ static int mdp5_kms_init(struct drm_device *dev)
struct platform_device *pdev;
struct mdp5_kms *mdp5_kms;
struct mdp5_cfg *config;
-   struct msm_kms *kms;
+   struct msm_kms *kms = priv->kms;
struct msm_gem_address_space *aspace;
-   int irq, i, ret;
+   int i, ret;
 
ret = mdp5_init(to_platform_device(dev->dev), dev);
if (ret)
return ret;
 
-   /* priv->kms would have been populated by the MDP5 driver */
-   kms = priv->kms;
-   if (!kms)
-   return -ENOMEM;
-
mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+
pdev = mdp5_kms->pdev;
 
ret = mdp_kms_init(&mdp5_kms->base, &kms_funcs);
@@ -576,15 +572,6 @@ static int mdp5_kms_init(struct drm_device *dev)
goto fail;
}
 
-   irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
-   if (!irq) {
-   ret = -EINVAL;
-   DRM_DEV_ERROR(&pdev->dev, "failed to get irq\n");
-   goto fail;
-   }
-
-   kms->irq = irq;
-
config = mdp5_cfg_get_config(mdp5_kms->cfg);
 
/* make sure things are off before attaching iommu (bootloader could
@@ -787,60 +774,23 @@ static int interface_init(struct mdp5_kms *mdp5_kms)
 static int mdp5_init(struct platform_device *pdev, struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
-   struct mdp5_kms *mdp5_kms;
+   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
struct mdp5_cfg *config;
u32 major, minor;
int ret;
 
-   mdp5_kms = devm_kzalloc(&pdev->dev, sizeof(*mdp5_kms), GFP_KERNEL);
-   if (!mdp5_kms) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   spin_lock_init(&mdp5_kms->resource_lock);
-
mdp5_kms->dev = dev;
-   mdp5_kms->pdev = pdev;
 
ret = mdp5_global_obj_init(mdp5_kms);
if (ret)
goto fail;
 
-   mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys");
-   if (IS_ERR(mdp5_kms->mmio)) {
-   ret = PTR_ERR(mdp5_kms->mmio);
-   goto fail;
-   }
-
-   /* mandatory clocks: */
-   ret = get_clk(pdev, &mdp5_kms->axi_clk, "bus", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, &mdp5_kms->ahb_clk, "iface", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, &mdp5_kms->core_clk, "core", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, &mdp5_kms->vsync_clk, "vsync", true);
-   if (ret)
-   goto fail;
-
-   /* optional clocks: */
-   get_clk(pdev, &mdp5_kms->lut_clk, "lut", false);
-   get_clk(pdev, &mdp5_kms->tbu_clk, "tbu", false);
-   get_clk(pdev, &mdp5_kms->tbu_rt_clk, "tbu_rt", false);
-
/* we need to set a default rate before enabling.  Set a safe
 * rate first, then figure out hw revision, and then set a
 * more optimal rate:
 */
clk_set_rate(mdp5_kms->core_clk, 2);
 
-   /* set uninit-ed kms */
-   priv->kms = &mdp5_kms->base.base;
-
pm_runtime_enable(&pdev->dev);
mdp5_kms->rpm_enabled = true;
 
@@ -931,15 +881,53 @@ static int mdp5_setup_interconnect(struct platform_device 
*pdev)
 
 static int mdp5_dev_probe(struct platform_device *pdev)
 {
-   int ret;
+   struct mdp5_kms *mdp5_kms;
+   int ret, irq;
 
DBG("");
 
+   mdp5_kms = devm_kzalloc(&pdev->dev, sizeof(*mdp5_kms), GFP_KERNEL);
+   if (!mdp5_kms)
+   return -ENOMEM;
+
ret = mdp5_setup_interconnect(pdev);
if (ret)
return ret;
 
-   return msm_drv_probe(&pdev->dev, mdp5_kms_init, NULL);
+   mdp5_kms->pdev = pdev;
+
+   spin_lock_init(&mdp5_kms->resource_lock);
+
+   mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys");
+   if (IS_ERR(mdp5_kms->mmio))
+   return PTR_ERR(mdp5_kms->mmio);
+
+   /* mandatory clocks: */
+   ret = get_clk(pdev, &mdp5_kms->axi_clk, "bus", true);
+   if (ret)
+   return ret;
+   ret = get_clk(pdev, &mdp5_kms->ahb_clk, "iface", true);
+   if (ret)
+   return ret;
+   ret = get_clk(pdev, &mdp5_kms->core_clk, "core", true);
+   if (ret)
+   return ret;
+   ret = get_clk(pdev, &mdp5_kms->vsync_clk, "vsync", true);
+   if (

[PATCH v4 3/4] drm/msm/mdp4: move resource allocation to the _probe function

[Dmitry Baryshkov]

To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
 1 file changed, 51 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index e57a1e5f9da0..a3f1da3382e8 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -135,8 +135,6 @@ static void mdp4_destroy(struct msm_kms *kms)
pm_runtime_disable(dev);
 
mdp_kms_destroy(&mdp4_kms->base);
-
-   kfree(mdp4_kms);
 }
 
 static const struct mdp_kms_funcs kms_funcs = {
@@ -380,57 +378,27 @@ static int mdp4_kms_init(struct drm_device *dev)
 {
struct platform_device *pdev = to_platform_device(dev->dev);
struct msm_drm_private *priv = dev->dev_private;
-   struct mdp4_kms *mdp4_kms;
+   struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
struct msm_kms *kms = NULL;
struct msm_mmu *mmu;
struct msm_gem_address_space *aspace;
-   int irq, ret;
+   int ret;
u32 major, minor;
unsigned long max_clk;
 
/* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */
max_clk = 27000;
 
-   mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
-   if (!mdp4_kms) {
-   DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
-   return -ENOMEM;
-   }
-
ret = mdp_kms_init(&mdp4_kms->base, &kms_funcs);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
goto fail;
}
 
-   priv->kms = &mdp4_kms->base.base;
kms = priv->kms;
 
mdp4_kms->dev = dev;
 
-   mdp4_kms->mmio = msm_ioremap(pdev, NULL);
-   if (IS_ERR(mdp4_kms->mmio)) {
-   ret = PTR_ERR(mdp4_kms->mmio);
-   goto fail;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   ret = irq;
-   DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
-   goto fail;
-   }
-
-   kms->irq = irq;
-
-   /* NOTE: driver for this regulator still missing upstream.. use
-* _get_exclusive() and ignore the error if it does not exist
-* (and hope that the bootloader left it on for us)
-*/
-   mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
-   if (IS_ERR(mdp4_kms->vdd))
-   mdp4_kms->vdd = NULL;
-
if (mdp4_kms->vdd) {
ret = regulator_enable(mdp4_kms->vdd);
if (ret) {
@@ -439,24 +407,6 @@ static int mdp4_kms_init(struct drm_device *dev)
}
}
 
-   mdp4_kms->clk = devm_clk_get(&pdev->dev, "core_clk");
-   if (IS_ERR(mdp4_kms->clk)) {
-   DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
-   ret = PTR_ERR(mdp4_kms->clk);
-   goto fail;
-   }
-
-   mdp4_kms->pclk = devm_clk_get(&pdev->dev, "iface_clk");
-   if (IS_ERR(mdp4_kms->pclk))
-   mdp4_kms->pclk = NULL;
-
-   mdp4_kms->axi_clk = devm_clk_get(&pdev->dev, "bus_clk");
-   if (IS_ERR(mdp4_kms->axi_clk)) {
-   DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
-   ret = PTR_ERR(mdp4_kms->axi_clk);
-   goto fail;
-   }
-
clk_set_rate(mdp4_kms->clk, max_clk);
 
read_mdp_hw_revision(mdp4_kms, &major, &minor);
@@ -471,10 +421,9 @@ static int mdp4_kms_init(struct drm_device *dev)
mdp4_kms->rev = minor;
 
if (mdp4_kms->rev >= 2) {
-   mdp4_kms->lut_clk = devm_clk_get(&pdev->dev, "lut_clk");
-   if (IS_ERR(mdp4_kms->lut_clk)) {
+   if (!mdp4_kms->lut_clk) {
DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
-   ret = PTR_ERR(mdp4_kms->lut_clk);
+   ret = -ENODEV;
goto fail;
}
clk_set_rate(mdp4_kms->lut_clk, max_clk);
@@ -558,7 +507,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
 
 static int mdp4_probe(struct platform_device *pdev)
 {
-   return msm_drv_probe(&pdev->dev, mdp4_kms_init, NULL);
+   struct device *dev = &pdev->dev;
+   struct mdp4_kms *mdp4_kms;
+   int irq;
+
+   mdp4_kms = devm_kzalloc(dev, sizeof(*mdp4_kms), GFP_KERNEL);
+   if (!mdp4_kms)
+   return dev_err_probe(dev, -ENOMEM, "failed to allocate kms\n");
+
+   mdp4_kms->mmio = msm_ioremap(pdev, NULL);
+   if (IS_ERR(mdp4_kms->mmio))
+   return PTR_ERR(mdp4_kms->mmio);
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return dev_err_probe(dev, irq, "f

[PATCH v4 1/4] drm/msm: allow passing struct msm_kms to msm_drv_probe()

[Dmitry Baryshkov]

In preparation of moving resource allocation to the probe time, allow
MSM KMS drivers to pass struct msm_kms pointer via msm_drv_probe().

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
 drivers/gpu/drm/msm/msm_drv.c| 6 --
 drivers/gpu/drm/msm/msm_drv.h| 3 ++-
 5 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 44b0daf70c4e..22e5b430770e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1244,7 +1244,7 @@ static int dpu_kms_init(struct drm_device *ddev)
 
 static int dpu_dev_probe(struct platform_device *pdev)
 {
-   return msm_drv_probe(&pdev->dev, dpu_kms_init);
+   return msm_drv_probe(&pdev->dev, dpu_kms_init, NULL);
 }
 
 static int dpu_dev_remove(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 6e37072ed302..e57a1e5f9da0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -558,7 +558,7 @@ static const struct dev_pm_ops mdp4_pm_ops = {
 
 static int mdp4_probe(struct platform_device *pdev)
 {
-   return msm_drv_probe(&pdev->dev, mdp4_kms_init);
+   return msm_drv_probe(&pdev->dev, mdp4_kms_init, NULL);
 }
 
 static int mdp4_remove(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 323079cfd698..83a5b3bd09d9 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -939,7 +939,7 @@ static int mdp5_dev_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   return msm_drv_probe(&pdev->dev, mdp5_kms_init);
+   return msm_drv_probe(&pdev->dev, mdp5_kms_init, NULL);
 }
 
 static int mdp5_dev_remove(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 891eff8433a9..f06a06ab26fa 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1233,7 +1233,8 @@ const struct component_master_ops msm_drm_ops = {
 };
 
 int msm_drv_probe(struct device *master_dev,
-   int (*kms_init)(struct drm_device *dev))
+   int (*kms_init)(struct drm_device *dev),
+   struct msm_kms *kms)
 {
struct msm_drm_private *priv;
struct component_match *match = NULL;
@@ -1243,6 +1244,7 @@ int msm_drv_probe(struct device *master_dev,
if (!priv)
return -ENOMEM;
 
+   priv->kms = kms;
priv->kms_init = kms_init;
dev_set_drvdata(master_dev, priv);
 
@@ -1278,7 +1280,7 @@ int msm_drv_probe(struct device *master_dev,
 
 static int msm_pdev_probe(struct platform_device *pdev)
 {
-   return msm_drv_probe(&pdev->dev, NULL);
+   return msm_drv_probe(&pdev->dev, NULL, NULL);
 }
 
 static int msm_pdev_remove(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e13a8cbd61c9..6787bd302dfa 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -562,7 +562,8 @@ int msm_pm_prepare(struct device *dev);
 void msm_pm_complete(struct device *dev);
 
 int msm_drv_probe(struct device *dev,
-   int (*kms_init)(struct drm_device *dev));
+   int (*kms_init)(struct drm_device *dev),
+   struct msm_kms *kms);
 void msm_drv_shutdown(struct platform_device *pdev);
 
 
-- 
2.39.2

[PATCH v4 2/4] drm/msm/dpu: move resource allocation to the _probe function

[Dmitry Baryshkov]

To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().

This also drops devm_iounmap() calls. It is too early to have them
_dpu_kms_hw_destroy() (or it will break if for some reason DPU device is
rebound into the composite device) and it doesn't make sense to have
them in dpu_dev_remove (as everything will be torn down by the devres
anyway after the device is unbound from the driver).

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 133 +++-
 1 file changed, 61 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 22e5b430770e..e819e6f47bc1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -388,8 +388,7 @@ static int dpu_kms_parse_data_bus_icc_path(struct dpu_kms 
*dpu_kms)
 {
struct icc_path *path0;
struct icc_path *path1;
-   struct drm_device *dev = dpu_kms->dev;
-   struct device *dpu_dev = dev->dev;
+   struct device *dpu_dev = &dpu_kms->pdev->dev;
 
path0 = msm_icc_get(dpu_dev, "mdp0-mem");
path1 = msm_icc_get(dpu_dev, "mdp1-mem");
@@ -830,21 +829,9 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
 
dpu_kms->catalog = NULL;
 
-   if (dpu_kms->vbif[VBIF_NRT])
-   devm_iounmap(&dpu_kms->pdev->dev, dpu_kms->vbif[VBIF_NRT]);
-   dpu_kms->vbif[VBIF_NRT] = NULL;
-
-   if (dpu_kms->vbif[VBIF_RT])
-   devm_iounmap(&dpu_kms->pdev->dev, dpu_kms->vbif[VBIF_RT]);
-   dpu_kms->vbif[VBIF_RT] = NULL;
-
if (dpu_kms->hw_mdp)
dpu_hw_mdp_destroy(dpu_kms->hw_mdp);
dpu_kms->hw_mdp = NULL;
-
-   if (dpu_kms->mmio)
-   devm_iounmap(&dpu_kms->pdev->dev, dpu_kms->mmio);
-   dpu_kms->mmio = NULL;
 }
 
 static void dpu_kms_destroy(struct msm_kms *kms)
@@ -1038,30 +1025,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
 
atomic_set(&dpu_kms->bandwidth_ref, 0);
 
-   dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp");
-   if (IS_ERR(dpu_kms->mmio)) {
-   rc = PTR_ERR(dpu_kms->mmio);
-   DPU_ERROR("mdp register memory map failed: %d\n", rc);
-   dpu_kms->mmio = NULL;
-   goto error;
-   }
-   DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio);
-
-   dpu_kms->vbif[VBIF_RT] = msm_ioremap(dpu_kms->pdev, "vbif");
-   if (IS_ERR(dpu_kms->vbif[VBIF_RT])) {
-   rc = PTR_ERR(dpu_kms->vbif[VBIF_RT]);
-   DPU_ERROR("vbif register memory map failed: %d\n", rc);
-   dpu_kms->vbif[VBIF_RT] = NULL;
-   goto error;
-   }
-   dpu_kms->vbif[VBIF_NRT] = msm_ioremap_quiet(dpu_kms->pdev, "vbif_nrt");
-   if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
-   dpu_kms->vbif[VBIF_NRT] = NULL;
-   DPU_DEBUG("VBIF NRT is not defined");
-   }
-
-   dpu_kms_parse_data_bus_icc_path(dpu_kms);
-
rc = pm_runtime_resume_and_get(&dpu_kms->pdev->dev);
if (rc < 0)
goto error;
@@ -1186,33 +1149,11 @@ static int dpu_kms_init(struct drm_device *ddev)
struct msm_drm_private *priv = ddev->dev_private;
struct device *dev = ddev->dev;
struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms;
-   int irq;
+   struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
struct dev_pm_opp *opp;
int ret = 0;
unsigned long max_freq = ULONG_MAX;
 
-   dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
-   if (!dpu_kms)
-   return -ENOMEM;
-
-   ret = devm_pm_opp_set_clkname(dev, "core");
-   if (ret)
-   return ret;
-   /* OPP table is optional */
-   ret = devm_pm_opp_of_add_table(dev);
-   if (ret && ret != -ENODEV) {
-   dev_err(dev, "invalid OPP table in device tree\n");
-   return ret;
-   }
-
-   ret = devm_clk_bulk_get_all(&pdev->dev, &dpu_kms->clocks);
-   if (ret < 0) {
-   DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
-   return ret;
-   }
-   dpu_kms->num_clocks = ret;
-
opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
if (!IS_ERR(opp))
dev_pm_opp_put(opp);
@@ -1225,26 +1166,74 @@ static int dpu_kms_init(struct drm_device *ddev)
return ret;
}
dpu_kms->dev = ddev;
-   dpu_kms->pdev = pdev;
 
pm_runtime_enable(&pdev->dev);
dpu_kms->rpm_enabled = true;
 
-   priv->kms = &dpu_kms->base;
-
-   irq = irq_of_parse_and_map(dpu_kms->pdev->dev.of_node, 0);
-   if (!irq) {
-   DPU_ERROR("failed to get irq\n");
-   return -EINVAL;
-   }
-   

[PATCH v4 0/4] drm/msm: move resource allocation to the _probe function

[Dmitry Baryshkov]

This patchset was left untouched for almost a year. Let's reiterate it
in attempt to solve the long-standing issue.

As discussed several times on IRC, move display subdriver resource
allocation from kms_init to probe time to let it bail early.

Changes since v3:
- Fixed MMIO unmaping in the DPU case.

Changes since v2:
- Move even more resource allocation in the DPU init path.

Changes since v1:
- Dropped the applied patch
- Picked in the patch to pass msm_kms pointer via msm_drv_probe()

Dmitry Baryshkov (4):
  drm/msm: allow passing struct msm_kms to msm_drv_probe()
  drm/msm/dpu: move resource allocation to the _probe function
  drm/msm/mdp4: move resource allocation to the _probe function
  drm/msm/mdp5: move resource allocation to the _probe function

 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 133 +++
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 100 -
 drivers/gpu/drm/msm/msm_drv.c|   6 +-
 drivers/gpu/drm/msm/msm_drv.h|   3 +-
 5 files changed, 162 insertions(+), 187 deletions(-)

-- 
2.39.2

Re: [PATCH v2 05/14] drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()

[Dmitry Baryshkov]

On Tue, 4 Jul 2023 at 18:55, Abhinav Kumar  wrote:
>
>
>
> On 7/4/2023 8:03 AM, Dmitry Baryshkov wrote:
> > Move perf mode handling for the bandwidth to
> > _dpu_core_perf_crtc_update_bus() rather than overriding per-CRTC data
> > and then aggregating known values.
> >
> > Note, this changes the fix_core_ab_vote. Previously it would be
> > multiplied per the CRTC number, now it will be used directly for
> > interconnect voting.
> >
> > Signed-off-by: Dmitry Baryshkov 
>
> Break this out into a separate series. This rework doesnt need to be
> part of this cleanup series.

Sure, why not.

>
> > ---
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 +--
> >   1 file changed, 18 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > index 348550ac7e51..42c03a5f1f3e 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > @@ -116,21 +116,9 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms 
> > *kms,
> >   return;
> >   }
> >
> > - memset(perf, 0, sizeof(struct dpu_core_perf_params));
> > -
> > - if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
> > - perf->bw_ctl = 0;
> > - perf->max_per_pipe_ib = 0;
> > - perf->core_clk_rate = 0;
> > - } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
> > - perf->bw_ctl = kms->perf.fix_core_ab_vote;
> > - perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
> > - perf->core_clk_rate = kms->perf.fix_core_clk_rate;
> > - } else {
> > - perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
> > - perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
> > - perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, 
> > state);
> > - }
> > + perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
> > + perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
> > + perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
> >
> >   DRM_DEBUG_ATOMIC(
> >   "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
> > @@ -236,17 +224,28 @@ static int _dpu_core_perf_crtc_update_bus(struct 
> > dpu_kms *kms,
> >   struct dpu_core_perf_params perf = { 0 };
> >   int i, ret = 0;
> >   u32 avg_bw;
> > + u32 peak_bw;
> >
> >   if (!kms->num_paths)
> >   return 0;
> >
> > - dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
> > &perf);
> > + if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
> > + avg_bw = 0;
> > + peak_bw = 0;
> > + } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
> > + avg_bw = kms->perf.fix_core_ab_vote;
> > + peak_bw = kms->perf.fix_core_ib_vote;
> > + } else {
> > + dpu_core_perf_aggregate(crtc->dev, 
> > dpu_crtc_get_client_type(crtc), &perf);
> > +
> > + avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
> > + peak_bw = perf.max_per_pipe_ib;
> > + }
> >
> > - avg_bw = perf.bw_ctl;
> > - do_div(avg_bw, (kms->num_paths * 1000)); /*Bps_to_icc*/
> > + avg_bw /= kms->num_paths;
> >
> >   for (i = 0; i < kms->num_paths; i++)
> > - icc_set_bw(kms->path[i], avg_bw, perf.max_per_pipe_ib);
> > + icc_set_bw(kms->path[i], avg_bw, peak_bw);
> >
> >   return ret;
> >   }



-- 
With best wishes
Dmitry

Re: [PATCH v4 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field

[Dmitry Baryshkov]

On Tue, 4 Jul 2023 at 19:10, Abhinav Kumar  wrote:
>
>
>
> On 7/4/2023 4:52 AM, Dmitry Baryshkov wrote:
> > On Tue, 4 Jul 2023 at 13:06, Dmitry Baryshkov
> >  wrote:
> >>
> >> On Tue, 4 Jul 2023 at 07:04, Abhinav Kumar  
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 7/3/2023 7:20 PM, Dmitry Baryshkov wrote:
>  On 03/07/2023 05:01, Abhinav Kumar wrote:
> >
> >
> > On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:
> >> There is always a single MDP TOP block. Drop the mdp_count field and
> >> stop declaring dpu_mdp_cfg instances as arrays.
> >>
> >> Tested-by: Marijn Suijten 
> >> Signed-off-by: Dmitry Baryshkov 
> >> ---
> >
> > The change drops mdp_count and stops using the array which is fine and
> > I will support that.
> >
> > But looking at the pattern I saw while using core_revision, both
> > DPU_MDP_VSYNC_SEL and DPU_MDP_AUDIO_SELECT can also be dropped from
> > the catalog in favor of using core_revision.
> >
> > Hence for that, I request you not to stop passing dpu_mdss_cfg to
> > dpu_hw_mdptop_init as that has the necessary information of
> > core_revision.
> 
>  Sure, I'll restore it. Please note, however, that it might be better to
>  pass struct dpu_caps instead of the full struct dpu_mdss_cfg.
> 
> >>>
> >>> Thanks for restoring.
> >>>
> >>> Can you pls explain this better? dpu_core_rev is part of dpu_mdss_cfg,
> >>> so dpu_caps wont be enough for this one.
> >>
> >> Oh, true. For some reason I thought that version is a part of dpu_caps.
> >
> > And after additional thought. Maybe it would be better to add a
> > separate struct dpu_mdss_version and pass it to the hw block init
> > functions?
> >
>
> I would like to see this evolve. Today, we are assuming that only the hw
> block init functions are the places we would use those.
>
>  From what I recall, the DSC over DP series needed the core_revision in
> the timing gen code somewhere.

I hope you are talking about the DPU driver here, not about the DP
driver. For the DP driver please use struct msm_dp_desc.

>
> If we see that pattern is possible once that lands, why not.
>
> Right now, I would leave it at dpu_mdss_cfg.
>
> >>
> >>>
> >
> >>.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h   |  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h   |  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h   |  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h  |  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h|  7 +---
> >>.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h|  7 +---
> >>.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  1 -
> >>drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 38 
> >> +++
> >>drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h|  8 ++--
> >>drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  4 +-
> >>19 files changed, 41 insertions(+), 115 deletions(-)
> 
> >>
> >>
> >>
> >> --
> >> With best wishes
> >> Dmitry
> >
> >
> >



-- 
With best wishes
Dmitry

Re: [PATCH 1/2] drm/msm/adreno: Fix warn splat for devices without revn

[Dmitry Baryshkov]

On Tue, 4 Jul 2023 at 19:36, Rob Clark  wrote:
>
> From: Rob Clark 
>
> Recently, a WARN_ON() was introduced to ensure that revn is filled before
> adreno_is_aXYZ is called. This however doesn't work very well when revn is
> 0 by design (such as for A635).
>
> Cc: Konrad Dybcio 
> Fixes: cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before 
> being set")
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 65379e4824d9..ef1bcb6b624e 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -149,7 +149,8 @@ bool adreno_cmp_rev(struct adreno_rev rev1, struct 
> adreno_rev rev2);
>
>  static inline bool adreno_is_revn(const struct adreno_gpu *gpu, uint32_t 
> revn)
>  {
> -   WARN_ON_ONCE(!gpu->revn);
> +   /* revn can be zero, but if not is set at same time as info */
> +   WARN_ON_ONCE(!gpu->info);
>
> return gpu->revn == revn;
>  }
> @@ -161,14 +162,16 @@ static inline bool adreno_has_gmu_wrapper(const struct 
> adreno_gpu *gpu)
>
>  static inline bool adreno_is_a2xx(const struct adreno_gpu *gpu)
>  {
> -   WARN_ON_ONCE(!gpu->revn);
> +   /* revn can be zero, but if not is set at same time as info */
> +   WARN_ON_ONCE(!gpu->info);
>
> return (gpu->revn < 300);

This is then incorrect for a635 / a690 if they have revn at 0.

>  }
>
>  static inline bool adreno_is_a20x(const struct adreno_gpu *gpu)
>  {
> -   WARN_ON_ONCE(!gpu->revn);
> +   /* revn can be zero, but if not is set at same time as info */
> +   WARN_ON_ONCE(!gpu->info);
>
> return (gpu->revn < 210);

And this too.

>  }
> --
> 2.41.0
>


-- 
With best wishes
Dmitry

Re: [PATCH] backlight: led_bl: fix initial power state

[Sam Ravnborg]

Hi Daniel,

> > @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
> > props.type = BACKLIGHT_RAW;
> > props.max_brightness = priv->max_brightness;
> > props.brightness = priv->default_brightness;
> > -   props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
> > - FB_BLANK_UNBLANK;
> > +   props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
> > + FB_BLANK_POWERDOWN;
> 
> The logic was wrong before but I think will still be wrong after the
> change too (e.g. the bogus logic is probably avoiding backlight flicker
> in some use cases).
> 
> The logic here needs to be similar to what pwm_bl.c implements in
> pwm_backlight_initial_power_state(). Whilst it might be better
> to implement this in led_bl_get_leds() let me show what I mean
> in code that fits in the current line:
> 
>   /*
>* Activate the backlight if the LEDs are already lit *or*
>* there is no phandle link (meaning the backlight power
>* state cannot be synced with the display state).
>*/
>   props.power = (active_at_boot || !dev->node->phandle) ?
>   FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
> 
The following code does the same using helpers:

if (active_at_boot || !dev->node->phandle))
backlight_enable(bd);
else
backlight_disable(bd);

The code needs to execute after backlight_device_register() so maybe not
so great an idea?!?

Sam

Re: [PATCH v4 1/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits

[Sebastian Wick]

On Sat, Jul 1, 2023 at 4:09 AM André Almeida  wrote:
>
> From: Simon Ser 
>
> If the driver supports it, allow user-space to supply the
> DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
> Set drm_crtc_state.async_flip accordingly.
>
> Document that drivers will reject atomic commits if an async
> flip isn't possible. This allows user-space to fall back to
> something else. For instance, Xorg falls back to a blit.
> Another option is to wait as close to the next vblank as
> possible before performing the page-flip to reduce latency.
>
> Signed-off-by: Simon Ser 
> Reviewed-by: Alex Deucher 
> Co-developed-by: André Almeida 
> Signed-off-by: André Almeida 
> ---
> v4: no changes
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 28 +---
>  include/uapi/drm/drm_mode.h   |  9 +
>  2 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d867e7f9f2cd..dfd4cf7169df 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1286,6 +1286,18 @@ static void complete_signaling(struct drm_device *dev,
> kfree(fence_state);
>  }
>
> +static void
> +set_async_flip(struct drm_atomic_state *state)
> +{
> +   struct drm_crtc *crtc;
> +   struct drm_crtc_state *crtc_state;
> +   int i;
> +
> +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> +   crtc_state->async_flip = true;
> +   }
> +}
> +
>  int drm_mode_atomic_ioctl(struct drm_device *dev,
>   void *data, struct drm_file *file_priv)
>  {
> @@ -1326,9 +1338,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> }
>
> if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> -   drm_dbg_atomic(dev,
> -  "commit failed: invalid flag 
> DRM_MODE_PAGE_FLIP_ASYNC\n");
> -   return -EINVAL;
> +   if (!dev->mode_config.async_page_flip) {
> +   drm_dbg_atomic(dev,
> +  "commit failed: 
> DRM_MODE_PAGE_FLIP_ASYNC not supported\n");
> +   return -EINVAL;
> +   }
> +   if (dev->mode_config.atomic_async_page_flip_not_supported) {
> +   drm_dbg_atomic(dev,
> +  "commit failed: 
> DRM_MODE_PAGE_FLIP_ASYNC not supported with atomic\n");
> +   return -EINVAL;
> +   }
> }
>
> /* can't test and expect an event at the same time. */
> @@ -1426,6 +1445,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> if (ret)
> goto out;
>
> +   if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
> +   set_async_flip(state);
> +
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> ret = drm_atomic_check_only(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 46becedf5b2f..56342ba2c11a 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -949,6 +949,15 @@ struct hdr_output_metadata {
>   * Request that the page-flip is performed as soon as possible, ie. with no
>   * delay due to waiting for vblank. This may cause tearing to be visible on
>   * the screen.
> + *
> + * When used with atomic uAPI, the driver will return an error if the 
> hardware
> + * doesn't support performing an asynchronous page-flip for this update.
> + * User-space should handle this, e.g. by falling back to a regular 
> page-flip.
> + *
> + * Note, some hardware might need to perform one last synchronous page-flip
> + * before being able to switch to asynchronous page-flips. As an exception,
> + * the driver will return success even though that first page-flip is not
> + * asynchronous.

What would happen if one commits another async KMS update before the
first page flip? Does one receive EAGAIN, does it amend the previous
commit? What happens to the timing feedback?

This seems really risky to include tbh. I would prefer if we would not
add such special cases for now.

>   */
>  #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>  #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> --
> 2.41.0
>

Re: [PATCH] drm/arm/komeda: Remove component framework and add a simple encoder

[Sam Ravnborg]

Hi Mohammed,

On Tue, Jul 04, 2023 at 07:19:04PM +0530, Mohammad Faiz Abbas Rizvi wrote:
> Hi Liviu,
> 
> On 6/29/2023 3:21 PM, Liviu Dudau wrote:
> > Hi Faiz,
> >
> > Thanks for the patch and for addressing what was at some moment on my "nice 
> > to
> > improve / cleanup" list. Sorry for the delay in responding, I had to revive
> > the bits of an old setup to be able to test this properly, with 2 encoders
> > attached.
> >
> > On Wed, Jun 21, 2023 at 02:11:16PM +0530, Faiz Abbas wrote:
> >> The Komeda driver always expects the remote connector node to initialize
> >> an encoder. It uses the component aggregator framework which consists
> >> of component->bind() calls used to initialize the remote encoder and attach
> >> it to the crtc. This is different from other drm implementations which 
> >> expect
> >> the display driver to supply a crtc and connect an encoder to it.
> > I think both approaches are valid in DRM. We don't want to remove the 
> > component
> > framework because it is doing the wrong thing, but because we cannot use it
> > with drivers that implement the drm_bridge API. Given that we usually pair 
> > with
> > a component encoder that also implements a drm_bridge, dropping support for
> > component framework should not affect the users of the driver.

Glad to see the patch - I think this is moving things in the right
direction.


While at it do you plan to support DRM_BRIDGE_ATTACH_NO_CONNECTOR?

I did not read the patch carefully but noticed this call with no flags:

> drm_bridge_attach(&kcrtc->encoder, bridge, NULL, 0);

To add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR you may need to verify
that all relevant bridge drivers supports the flag.
You will be told at runtime but only if the relevant bridge driver is
used.

It can be done later and is obviously a separate patch.

Sam

Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP

[Jocelyn Falempe]

On 04/07/2023 16:54, Jani Nikula wrote:

On Fri, 23 Jun 2023, Jocelyn Falempe  wrote:

Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
  EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480, which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.


This conflates "monitor connected" and "EDID present", which are not
necessarily the same thing.

The fallback in drm_helper_probe_single_connector_modes() is for no
modes, but connector status is connected or unknown.


When debugging the issue, I found it surprising that the status is 
"connected" when nothing is plugged in the DP port.


You could add a connector ->detect callback that returns disconnected
when there's no display, and the problem should go away. If there's no
->detect callback, it'll default to connected.


ok, I'll try that. I don't know how the hardware detect something is 
connected, but looking at the dp code, maybe checking 
"AST_IO_CRTC_PORT,0xDC, ASTDP_LINK_SUCCESS" would be good enough.





Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP")
Signed-off-by: Jocelyn Falempe 
---
  drivers/gpu/drm/ast/ast_mode.c | 26 --
  1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 36374828f6c8..8f7b7cc021c7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1589,9 +1589,31 @@ static const struct drm_connector_helper_funcs 
ast_dp501_connector_helper_funcs
.get_modes = ast_dp501_connector_helper_get_modes,
  };
  
+static int ast_dp_probe_single_connector_modes(struct drm_connector *connector,

+  uint32_t maxX, uint32_t maxY)
+{
+   int ret;
+   struct drm_display_mode *mode;
+
+   ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
+   /*
+* When no monitor are detected, DP now default to 640x480
+* As aspeed is mostly used in remote server, and DP monitors are
+* rarely attached, it's better to default to 1024x768
+*/
+   if (!connector->edid_blob_ptr) {


Please try not to use connector->edid_blob_ptr for anything in
drivers. The logic is complicated enough as it is, with the firmware and
override EDIDs and everything, and makes future refactoring of EDID
handling harder.


Ok, I will try your other suggestion, and remove this.

Thanks a lot for your comments.

--

Jocelyn



BR,
Jani.


+   list_for_each_entry(mode, &connector->modes, head) {
+   if (mode->hdisplay == 1024 && mode->vdisplay == 768)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+   drm_mode_sort(&connector->modes);
+   }
+   }
+   return ret;
+}
+
  static const struct drm_connector_funcs ast_dp501_connector_funcs = {
.reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = ast_dp_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
@@ -1678,7 +1700,7 @@ static const struct drm_connector_helper_funcs 
ast_astdp_connector_helper_funcs
  
  static const struct drm_connector_funcs ast_astdp_connector_funcs = {

.reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = ast_dp_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,

base-commit: 0adec22702d497385dbdc52abb165f379a00efba

[PATCH 1/2] drm/msm/adreno: Fix warn splat for devices without revn

[Rob Clark]

From: Rob Clark 

Recently, a WARN_ON() was introduced to ensure that revn is filled before
adreno_is_aXYZ is called. This however doesn't work very well when revn is
0 by design (such as for A635).

Cc: Konrad Dybcio 
Fixes: cc943f43ece7 ("drm/msm/adreno: warn if chip revn is verified before 
being set")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 65379e4824d9..ef1bcb6b624e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -149,7 +149,8 @@ bool adreno_cmp_rev(struct adreno_rev rev1, struct 
adreno_rev rev2);
 
 static inline bool adreno_is_revn(const struct adreno_gpu *gpu, uint32_t revn)
 {
-   WARN_ON_ONCE(!gpu->revn);
+   /* revn can be zero, but if not is set at same time as info */
+   WARN_ON_ONCE(!gpu->info);
 
return gpu->revn == revn;
 }
@@ -161,14 +162,16 @@ static inline bool adreno_has_gmu_wrapper(const struct 
adreno_gpu *gpu)
 
 static inline bool adreno_is_a2xx(const struct adreno_gpu *gpu)
 {
-   WARN_ON_ONCE(!gpu->revn);
+   /* revn can be zero, but if not is set at same time as info */
+   WARN_ON_ONCE(!gpu->info);
 
return (gpu->revn < 300);
 }
 
 static inline bool adreno_is_a20x(const struct adreno_gpu *gpu)
 {
-   WARN_ON_ONCE(!gpu->revn);
+   /* revn can be zero, but if not is set at same time as info */
+   WARN_ON_ONCE(!gpu->info);
 
return (gpu->revn < 210);
 }
-- 
2.41.0

[PATCH 2/2] drm/msm/a690: Remove revn and name

[Rob Clark]

From: Rob Clark 

These fields are deprecated.  But any userspace new enough to support
a690 also knows how to identify the GPU based on chip-id.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 2 --
 drivers/gpu/drm/msm/adreno/adreno_gpu.h| 3 ++-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index cb94cfd137a8..ce8d0b2475bf 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -369,8 +369,6 @@ static const struct adreno_info gpulist[] = {
.hwcg = a640_hwcg,
}, {
.rev = ADRENO_REV(6, 9, 0, ANY_ID),
-   .revn = 690,
-   .name = "A690",
.fw = {
[ADRENO_FW_SQE] = "a660_sqe.fw",
[ADRENO_FW_GMU] = "a690_gmu.bin",
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index ef1bcb6b624e..cf45007400c8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -310,7 +310,8 @@ static inline int adreno_is_a680(const struct adreno_gpu 
*gpu)
 
 static inline int adreno_is_a690(const struct adreno_gpu *gpu)
 {
-   return adreno_is_revn(gpu, 690);
+   /* The order of args is important here to handle ANY_ID correctly */
+   return adreno_cmp_rev(ADRENO_REV(6, 9, 0, ANY_ID), gpu->rev);
 };
 /* check for a615, a616, a618, a619 or any derivatives */
 static inline int adreno_is_a615_family(const struct adreno_gpu *gpu)
-- 
2.41.0

[PATCH v2] drm/arm/komeda: Remove component framework and add a simple encoder

[Faiz Abbas]

The Komeda driver always expects the remote connector node to initialize
an encoder. It uses the component aggregator framework which consists
of component->bind() calls used to initialize the remote encoder and attach
it to the crtc. This makes it incompatible with connector drivers which
implement drm_bridge APIs.

Remove all component framework calls from the komeda driver and declare and
attach an encoder inside komeda_crtc_add().

The remote connector driver has to implement the DRM bridge APIs which
can be used to glue the encoder to the remote connector. Since we
usually pair this with a component encoder that also implements a
drm_bridge, dropping support is not expected to affect users of this
driver.

Signed-off-by: Faiz Abbas 
---
 .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 23 +++-
 .../gpu/drm/arm/display/komeda/komeda_drv.c   | 57 ++-
 .../gpu/drm/arm/display/komeda/komeda_kms.c   | 10 +---
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |  3 +
 4 files changed, 32 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 4cc07d6bb9d82..e5a8a80b173f4 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "komeda_dev.h"
 #include "komeda_kms.h"
@@ -613,9 +615,11 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
   struct komeda_crtc *kcrtc)
 {
struct drm_crtc *crtc = &kcrtc->base;
+   struct drm_device *base = &kms->base;
+   struct drm_bridge *bridge;
int err;
 
-   err = drm_crtc_init_with_planes(&kms->base, crtc,
+   err = drm_crtc_init_with_planes(base, crtc,
get_crtc_primary(kms, kcrtc), NULL,
&komeda_crtc_funcs, NULL);
if (err)
@@ -625,6 +629,23 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
 
crtc->port = kcrtc->master->of_output_port;
 
+
+   /* Construct an encoder for each pipeline and attach it to the remote
+* bridge
+*/
+   kcrtc->encoder.possible_crtcs = drm_crtc_mask(crtc);
+   err = drm_simple_encoder_init(base, &kcrtc->encoder,
+ DRM_MODE_ENCODER_TMDS);
+   if (err)
+   return err;
+
+   bridge = devm_drm_of_get_bridge(base->dev, kcrtc->master->of_node,
+   KOMEDA_OF_PORT_OUTPUT, 0);
+   if (IS_ERR(bridge))
+   return PTR_ERR(bridge);
+
+   err = drm_bridge_attach(&kcrtc->encoder, bridge, NULL, 0);
+
drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
 
return err;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 9fce4239d4ad4..98e7ca1ad8fe7 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -27,13 +26,11 @@ struct komeda_dev *dev_to_mdev(struct device *dev)
return mdrv ? mdrv->mdev : NULL;
 }
 
-static void komeda_unbind(struct device *dev)
+static int komeda_platform_remove(struct platform_device *pdev)
 {
+   struct device *dev = &pdev->dev;
struct komeda_drv *mdrv = dev_get_drvdata(dev);
 
-   if (!mdrv)
-   return;
-
komeda_kms_detach(mdrv->kms);
 
if (pm_runtime_enabled(dev))
@@ -45,10 +42,13 @@ static void komeda_unbind(struct device *dev)
 
dev_set_drvdata(dev, NULL);
devm_kfree(dev, mdrv);
+
+   return 0;
 }
 
-static int komeda_bind(struct device *dev)
+static int komeda_platform_probe(struct platform_device *pdev)
 {
+   struct device *dev = &pdev->dev;
struct komeda_drv *mdrv;
int err;
 
@@ -88,52 +88,7 @@ static int komeda_bind(struct device *dev)
 free_mdrv:
devm_kfree(dev, mdrv);
return err;
-}
-
-static const struct component_master_ops komeda_master_ops = {
-   .bind   = komeda_bind,
-   .unbind = komeda_unbind,
-};
 
-static void komeda_add_slave(struct device *master,
-struct component_match **match,
-struct device_node *np,
-u32 port, u32 endpoint)
-{
-   struct device_node *remote;
-
-   remote = of_graph_get_remote_node(np, port, endpoint);
-   if (remote) {
-   drm_of_component_match_add(master, match, component_compare_of, 
remote);
-   of_node_put(remote);
-   }
-}
-
-static int komeda_platform_probe(struct platform_device *pdev)
-{
-   struct device *dev = &pdev->dev;
-   struct component_match *match = NULL;
-   struct device_node *child;
-
-   if (!dev->of_node)
-   re

Re: [PATCH 05/12] arch: Remove trailing whitespaces

[Javier Martinez Canillas]

Thomas Zimmermann  writes:

> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: John Paul Adrian Glaubitz 
> Cc: Andrew Morton 
> Cc: Geert Uytterhoeven 
> Cc: Arnd Bergmann 
> Cc: "Kirill A. Shutemov" 
> Cc: Anshuman Khandual 
> Cc: Niklas Schnelle 
> Cc: Zi Yan 
> Cc: "Mike Rapoport (IBM)" 
> Cc: Peter Zijlstra 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 04/12] staging/sm750fb: Do not include

[Javier Martinez Canillas]

Thomas Zimmermann  writes:

> The sm750fb driver does not need anything from .
> Remove the include statements.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Sudip Mukherjee 
> Cc: Teddy Wang 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 03/12] sysfb: Do not include from sysfb header

[Javier Martinez Canillas]

Thomas Zimmermann  writes:

> The header file  does not need anything from
> . Declare struct screen_info and remove
> the include statements.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Ard Biesheuvel 
> Cc: Hans de Goede 
> Cc: Javier Martinez Canillas 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 02/12] fbdev/sm712fb: Do not include

[Javier Martinez Canillas]

Thomas Zimmermann  writes:

> Sm712fb's dependency on  is artificial in that
> it only uses struct screen_info for its internals. Replace the use of
> struct screen_info with a custom data structure and remove the include
> of .
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Sudip Mukherjee 
> Cc: Teddy Wang 
> Cc: Helge Deller 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 01/12] efi: Do not include from EFI header

[Javier Martinez Canillas]

Thomas Zimmermann  writes:

> The header file  does not need anything from
> . Declare struct screen_info and remove
> the include statements. Update a number of source files that
> require struct screen_info's definition.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Ard Biesheuvel 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH] drm/msm/dpu: add missing flush and fetch bits for DMA4/DMA5 planes

[Abhinav Kumar]

On 7/4/2023 9:01 AM, Jonathan Marek wrote:

Note that with this, DMA4/DMA5 are still non-functional, but at least
display *something* in modetest instead of nothing or underflow.

Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Jonathan Marek 
---


Reviewed-by: Abhinav Kumar 

Will pick this up for -fixes

Re: [PATCH v4 3/5] drm/arm: Make ARM devices menu depend on DRM

[Liviu Dudau]

On Tue, Jul 04, 2023 at 01:05:27AM +0200, Javier Martinez Canillas wrote:
> Otherwise if CONFIG_DRM is disabled, menuconfig will show an empty menu.
> 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Liviu Dudau 

Best regards,
Liviu

> ---
> 
> (no changes since v1)
> 
>  drivers/gpu/drm/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index c1b89274d2a4..ddf20708370f 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  menu "ARM devices"
> + depends on DRM
>  
>  config DRM_HDLCD
>   tristate "ARM HDLCD"
> -- 
> 2.41.0
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH v4 04/19] drm/msm/dpu: drop dpu_mdss_cfg::mdp_count field

[Abhinav Kumar]

On 7/4/2023 4:52 AM, Dmitry Baryshkov wrote:

On Tue, 4 Jul 2023 at 13:06, Dmitry Baryshkov
 wrote:


On Tue, 4 Jul 2023 at 07:04, Abhinav Kumar  wrote:




On 7/3/2023 7:20 PM, Dmitry Baryshkov wrote:

On 03/07/2023 05:01, Abhinav Kumar wrote:



On 6/19/2023 2:25 PM, Dmitry Baryshkov wrote:

There is always a single MDP TOP block. Drop the mdp_count field and
stop declaring dpu_mdp_cfg instances as arrays.

Tested-by: Marijn Suijten 
Signed-off-by: Dmitry Baryshkov 
---


The change drops mdp_count and stops using the array which is fine and
I will support that.

But looking at the pattern I saw while using core_revision, both
DPU_MDP_VSYNC_SEL and DPU_MDP_AUDIO_SELECT can also be dropped from
the catalog in favor of using core_revision.

Hence for that, I request you not to stop passing dpu_mdss_cfg to
dpu_hw_mdptop_init as that has the necessary information of
core_revision.


Sure, I'll restore it. Please note, however, that it might be better to
pass struct dpu_caps instead of the full struct dpu_mdss_cfg.



Thanks for restoring.

Can you pls explain this better? dpu_core_rev is part of dpu_mdss_cfg,
so dpu_caps wont be enough for this one.


Oh, true. For some reason I thought that version is a part of dpu_caps.


And after additional thought. Maybe it would be better to add a
separate struct dpu_mdss_version and pass it to the hw block init
functions?



I would like to see this evolve. Today, we are assuming that only the hw 
block init functions are the places we would use those.


From what I recall, the DSC over DP series needed the core_revision in 
the timing gen code somewhere.


If we see that pattern is possible once that lands, why not.

Right now, I would leave it at dpu_mdss_cfg.








   .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h   |  7 +---
   .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h   |  7 +---
   .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_6_4_sm6350.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h   |  7 +---
   .../msm/disp/dpu1/catalog/dpu_6_9_sm6375.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h  |  7 +---
   .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h|  7 +---
   .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h|  7 +---
   .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|  1 -
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 38 +++
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h|  8 ++--
   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  4 +-
   19 files changed, 41 insertions(+), 115 deletions(-)






--
With best wishes
Dmitry

Re: [PATCH V2] drm/bridge: adv7533: Fix adv7533_mode_valid for adv7533 and adv7535

[Yongqin Liu]

Hi, Adam, All

On Sun, 19 Mar 2023 at 20:55, Adam Ford  wrote:
>
> When dynamically switching lanes was removed, the intent of the code
> was to check to make sure that higher speed items used 4 lanes, but
> it had the unintended consequence of removing the slower speeds for
> 4-lane users.
>
> This attempts to remedy this by doing a check to see that the
> max frequency doesn't exceed the chip limit, and a second
> check to make sure that the max bit-rate doesn't exceed the
> number of lanes * max bit rate / lane.
>
> Fixes: 9a0cdcd6649b ("drm/bridge: adv7533: remove dynamic lane switching from 
> adv7533 bridge")
> Reviewed-by: Robert Foss 
> Signed-off-by: Adam Ford 
> ---
>
> V2:  Fix whitespace in comment
>  Remove TODO comment
>  Add R-B from Robert.

With this change, the ACK android-mainline based hikey960 build failed
to show UI on the HDMI
monitor connected, but it works if I revert this change.
Here is the serial console output: http://ix.io/4zK8

Not sure if you have any idea what the problem is there,
and how to have it fixed.

Please let me know if you need any other information.

Thanks,
Yongqin Liu

> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index fdfeadcefe80..7e3e56441aed 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> @@ -103,22 +103,19 @@ void adv7533_dsi_power_off(struct adv7511 *adv)
>  enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
> const struct drm_display_mode *mode)
>  {
> -   int lanes;
> +   unsigned long max_lane_freq;
> struct mipi_dsi_device *dsi = adv->dsi;
> +   u8 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>
> -   if (mode->clock > 8)
> -   lanes = 4;
> -   else
> -   lanes = 3;
> -
> -   /*
> -* TODO: add support for dynamic switching of lanes
> -* by using the bridge pre_enable() op . Till then filter
> -* out the modes which shall need different number of lanes
> -* than what was configured in the device tree.
> -*/
> -   if (lanes != dsi->lanes)
> -   return MODE_BAD;
> +   /* Check max clock for either 7533 or 7535 */
> +   if (mode->clock > (adv->type == ADV7533 ? 8 : 148500))
> +   return MODE_CLOCK_HIGH;
> +
> +   /* Check max clock for each lane */
> +   max_lane_freq = (adv->type == ADV7533 ? 80 : 891000);
> +
> +   if (mode->clock * bpp > max_lane_freq * adv->num_dsi_lanes)
> +   return MODE_CLOCK_HIGH;
>
> return MODE_OK;
>  }
> --
> 2.34.1
>


--
Best Regards,
Yongqin Liu
---
#mailing list
linaro-andr...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android

[PATCH] drm/msm/dpu: add missing flush and fetch bits for DMA4/DMA5 planes

[Jonathan Marek]

Note that with this, DMA4/DMA5 are still non-functional, but at least
display *something* in modetest instead of nothing or underflow.

Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index bbdc95ce374a..5af5975f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -51,7 +51,7 @@
 
 static const u32 fetch_tbl[SSPP_MAX] = {CTL_INVALID_BIT, 16, 17, 18, 19,
CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, 0,
-   1, 2, 3, CTL_INVALID_BIT, CTL_INVALID_BIT};
+   1, 2, 3, 4, 5};
 
 static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
const struct dpu_mdss_cfg *m,
@@ -206,6 +206,12 @@ static void dpu_hw_ctl_update_pending_flush_sspp(struct 
dpu_hw_ctl *ctx,
case SSPP_DMA3:
ctx->pending_flush_mask |= BIT(25);
break;
+   case SSPP_DMA4:
+   ctx->pending_flush_mask |= BIT(13);
+   break;
+   case SSPP_DMA5:
+   ctx->pending_flush_mask |= BIT(14);
+   break;
case SSPP_CURSOR0:
ctx->pending_flush_mask |= BIT(22);
break;
-- 
2.26.1

[PATCH 08/10] drm/omapdrm: Use GEM mmap for fbdev emulation

[Thomas Zimmermann]

The fbdev emulation currently uses fbdev's default mmap code, which
has been written for I/O memory. Provide an mmap that uses GEM's mmap
infrastructure.

Utilize fine-grained fbdev macros to initialize struct fb_ops. The
macros set the read/write and the draw callbacks for DMA memory. Set
the fb_mmap callback to omapdrm's new mmap helper. Also select the
correct Kconfig token for fbdev's DMA helpers. Note that the DMA
helpers are the same as for system memory.

Signed-off-by: Thomas Zimmermann 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/Kconfig  |  2 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 15 +--
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
index b4ac76c9f31b..d3c4877e465c 100644
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -4,7 +4,7 @@ config DRM_OMAP
depends on DRM && OF
depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
-   select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
+   select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
select VIDEOMODE_HELPERS
select HDMI
default n
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b7ccce0704a3..b1a2d00ef52d 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -76,6 +76,15 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo 
*var,
return drm_fb_helper_pan_display(var, fbi);
 }
 
+static int omap_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *helper = info->par;
+   struct drm_framebuffer *fb = helper->fb;
+   struct drm_gem_object *bo = drm_gem_fb_get_obj(fb, 0);
+
+   return drm_gem_mmap_obj(bo, omap_gem_mmap_size(bo), vma);
+}
+
 static void omap_fbdev_fb_destroy(struct fb_info *info)
 {
struct drm_fb_helper *helper = info->par;
@@ -97,14 +106,16 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
 
 static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
-   FB_DEFAULT_SYS_OPS,
+   __FB_DEFAULT_DMA_OPS_RDWR,
.fb_check_var   = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank   = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
+   __FB_DEFAULT_DMA_OPS_DRAW,
.fb_ioctl   = drm_fb_helper_ioctl,
-   .fb_destroy = omap_fbdev_fb_destroy,
+   .fb_mmap= omap_fbdev_fb_mmap,
+   .fb_destroy = omap_fbdev_fb_destroy,
 };
 
 static int omap_fbdev_create(struct drm_fb_helper *helper,
-- 
2.41.0

[PATCH 10/10] fbdev: Remove FB_DEFAULT_SYS_OPS

[Thomas Zimmermann]

Remove the initializer macro FB_DEFAULT_SYS_OPS and its helper macro
__FB_DEFAULT_SYS_OPS_MMAP. There are no users.

Signed-off-by: Thomas Zimmermann 
Cc: Helge Deller  (maintainer:FRAMEBUFFER LAYER)
---
 include/linux/fb.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1191a78c5289..d370f84fbca9 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -586,14 +586,6 @@ extern ssize_t fb_sys_write(struct fb_info *info, const 
char __user *buf,
.fb_copyarea= sys_copyarea, \
.fb_imageblit   = sys_imageblit
 
-#define __FB_DEFAULT_SYS_OPS_MMAP \
-   .fb_mmap= NULL /* default implementation */
-
-#define FB_DEFAULT_SYS_OPS \
-   __FB_DEFAULT_SYS_OPS_RDWR, \
-   __FB_DEFAULT_SYS_OPS_DRAW, \
-   __FB_DEFAULT_SYS_OPS_MMAP
-
 /*
  * Helpers for framebuffers in DMA-able memory
  */
-- 
2.41.0

[PATCH 06/10] drm/exynos: Set fbdev flags

[Thomas Zimmermann]

Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should
be accessed with the CPU's regular memory ops.

Signed-off-by: Thomas Zimmermann 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 7ca3424b59ce..28dc398d6e10 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -72,6 +72,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
return PTR_ERR(fbi);
}
 
+   fbi->flags = FBINFO_FLAG_DEFAULT;
fbi->fbops = &exynos_drm_fb_ops;
 
drm_fb_helper_fill_info(fbi, helper, sizes);
@@ -79,6 +80,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
offset = fbi->var.xoffset * fb->format->cpp[0];
offset += fbi->var.yoffset * fb->pitches[0];
 
+   fbi->flags |= FBINFO_VIRTFB;
fbi->screen_buffer = exynos_gem->kvaddr + offset;
fbi->screen_size = size;
fbi->fix.smem_len = size;
-- 
2.41.0

[PATCH 09/10] drm/omapdrm: Set fbdev flags

[Thomas Zimmermann]

Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should
be accessed with the CPU's regular memory ops.

Signed-off-by: Thomas Zimmermann 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b1a2d00ef52d..2dd86e6f5268 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -203,10 +203,12 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
 
helper->fb = fb;
 
+   fbi->flags = FBINFO_DEFAULT;
fbi->fbops = &omap_fb_ops;
 
drm_fb_helper_fill_info(fbi, helper, sizes);
 
+   fbi->flags |= FBINFO_VIRTFB;
fbi->screen_buffer = omap_gem_vaddr(bo);
fbi->screen_size = bo->size;
fbi->fix.smem_start = dma_addr;
-- 
2.41.0

[PATCH 04/10] drm/tegra: Set fbdev flags

[Thomas Zimmermann]

Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should
be accessed with the CPU's regular memory ops.

Signed-off-by: Thomas Zimmermann 
Cc: Thierry Reding 
Cc: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/fbdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c
index 82577b7c88da..8074430c52f1 100644
--- a/drivers/gpu/drm/tegra/fbdev.c
+++ b/drivers/gpu/drm/tegra/fbdev.c
@@ -103,6 +103,8 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
return PTR_ERR(info);
}
 
+   info->flags = FBINFO_DEFAULT;
+
fb = tegra_fb_alloc(drm, &cmd, &bo, 1);
if (IS_ERR(fb)) {
err = PTR_ERR(fb);
@@ -132,6 +134,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
}
}
 
+   info->flags |= FBINFO_VIRTFB;
info->screen_base = (void __iomem *)bo->vaddr + offset;
info->screen_size = size;
info->fix.smem_start = (unsigned long)(bo->iova + offset);
-- 
2.41.0

[PATCH 07/10] drm/omapdrm: Set VM flags in GEM-object mmap function

[Thomas Zimmermann]

Use the mmap callback in struct drm_gem_object_funcs to set the
VM flags. Replace a number of mmap helpers in omapdrm with their
GEM helper counterparts. Generate DRM's file-operations instance
with GEM's DEFINE_DRM_GEM_FOPS.

Signed-off-by: Thomas Zimmermann 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c| 12 +---
 drivers/gpu/drm/omapdrm/omap_gem.c| 24 ++-
 drivers/gpu/drm/omapdrm/omap_gem.h|  3 ---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  7 +--
 4 files changed, 8 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index e2697fe80e62..afeeb7737552 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -636,17 +636,7 @@ static int dev_open(struct drm_device *dev, struct 
drm_file *file)
return 0;
 }
 
-static const struct file_operations omapdriver_fops = {
-   .owner = THIS_MODULE,
-   .open = drm_open,
-   .unlocked_ioctl = drm_ioctl,
-   .compat_ioctl = drm_compat_ioctl,
-   .release = drm_release,
-   .mmap = omap_gem_mmap,
-   .poll = drm_poll,
-   .read = drm_read,
-   .llseek = noop_llseek,
-};
+DEFINE_DRM_GEM_FOPS(omapdriver_fops);
 
 static const struct drm_driver omap_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM  |
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 6b58a5bb7b44..c9c64ad17ce6 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -524,26 +524,11 @@ static vm_fault_t omap_gem_fault(struct vm_fault *vmf)
return ret;
 }
 
-/** We override mainly to fix up some of the vm mapping flags.. */
-int omap_gem_mmap(struct file *filp, struct vm_area_struct *vma)
-{
-   int ret;
-
-   ret = drm_gem_mmap(filp, vma);
-   if (ret) {
-   DBG("mmap failed: %d", ret);
-   return ret;
-   }
-
-   return omap_gem_mmap_obj(vma->vm_private_data, vma);
-}
-
-int omap_gem_mmap_obj(struct drm_gem_object *obj,
-   struct vm_area_struct *vma)
+static int omap_gem_object_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
 {
struct omap_gem_object *omap_obj = to_omap_bo(obj);
 
-   vm_flags_mod(vma, VM_MIXEDMAP, VM_PFNMAP);
+   vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO | 
VM_MIXEDMAP);
 
if (omap_obj->flags & OMAP_BO_WC) {
vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
@@ -563,12 +548,14 @@ int omap_gem_mmap_obj(struct drm_gem_object *obj,
 * address_space (so unmap_mapping_range does what we want,
 * in particular in the case of mmap'd dmabufs)
 */
-   vma->vm_pgoff = 0;
+   vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
vma_set_file(vma, obj->filp);
 
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
 
+   vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return 0;
 }
 
@@ -1282,6 +1269,7 @@ static const struct vm_operations_struct omap_gem_vm_ops 
= {
 static const struct drm_gem_object_funcs omap_gem_object_funcs = {
.free = omap_gem_free_object,
.export = omap_gem_prime_export,
+   .mmap = omap_gem_object_mmap,
.vm_ops = &omap_gem_vm_ops,
 };
 
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.h 
b/drivers/gpu/drm/omapdrm/omap_gem.h
index 4d4488939f6b..fec3fa0e4c33 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.h
+++ b/drivers/gpu/drm/omapdrm/omap_gem.h
@@ -57,9 +57,6 @@ int omap_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
struct drm_mode_create_dumb *args);
 
 /* mmap() Interface */
-int omap_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-int omap_gem_mmap_obj(struct drm_gem_object *obj,
-   struct vm_area_struct *vma);
 u64 omap_gem_mmap_offset(struct drm_gem_object *obj);
 size_t omap_gem_mmap_size(struct drm_gem_object *obj);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 8e194dbc9506..36f9ee4baad3 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -64,13 +64,8 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct vm_area_struct *vma)
 {
struct drm_gem_object *obj = buffer->priv;
-   int ret = 0;
 
-   ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
-   if (ret < 0)
-   return ret;
-
-   return omap_gem_mmap_obj(obj, vma);
+   return drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
 }
 
 static const struct dma_buf_ops omap_dmabuf_ops = {
-- 
2.41.0

[PATCH 03/10] drm/tegra: Use fbdev DMA helpers

[Thomas Zimmermann]

Use fbdev's DMA helpers for fbdev emulation. They are equivalent to the
previously used system-memory helpers, so no functional changes here.

Signed-off-by: Thomas Zimmermann 
Cc: Thierry Reding 
Cc: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/Kconfig | 2 +-
 drivers/gpu/drm/tegra/fbdev.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 498313778175..39452c8480c1 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -12,7 +12,7 @@ config DRM_TEGRA
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
-   select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
+   select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
select TEGRA_HOST1X
select INTERCONNECT
select IOMMU_IOVA
diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c
index e74d9be981c7..82577b7c88da 100644
--- a/drivers/gpu/drm/tegra/fbdev.c
+++ b/drivers/gpu/drm/tegra/fbdev.c
@@ -59,9 +59,9 @@ static void tegra_fbdev_fb_destroy(struct fb_info *info)
 
 static const struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
-   __FB_DEFAULT_SYS_OPS_RDWR,
+   __FB_DEFAULT_DMA_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
-   __FB_DEFAULT_SYS_OPS_DRAW,
+   __FB_DEFAULT_DMA_OPS_DRAW,
.fb_mmap = tegra_fb_mmap,
.fb_destroy = tegra_fbdev_fb_destroy,
 };
-- 
2.41.0

[PATCH 05/10] drm/exynos: Use fbdev DMA helpers

[Thomas Zimmermann]

Use fbdev's DMA helpers for fbdev emulation. They drivers previously
used the I/O-memory helpers, while allocating DMA-able system memory.
This could (in theory) result in bus errors from accessing the memory
range.

This bug has been present since the exynos driver was first added.

Signed-off-by: Thomas Zimmermann 
Fixes: 1c248b7d2960 ("DRM: add DRM Driver for Samsung SoC EXYNOS4210.")
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
---
 drivers/gpu/drm/exynos/Kconfig| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7ca7e1dab52c..661b42ad4873 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -7,7 +7,7 @@ config DRM_EXYNOS
select DRM_DISPLAY_HELPER if DRM_EXYNOS_DP
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
-   select FB_IO_HELPERS if DRM_FBDEV_EMULATION
+   select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
select SND_SOC_HDMI_CODEC if SND_SOC
help
  Choose this option if you have a Samsung SoC Exynos chipset.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index fdf65587f1fe..7ca3424b59ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -49,9 +49,9 @@ static void exynos_drm_fb_destroy(struct fb_info *info)
 
 static const struct fb_ops exynos_drm_fb_ops = {
.owner  = THIS_MODULE,
-   __FB_DEFAULT_IO_OPS_RDWR,
+   __FB_DEFAULT_DMA_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
-   __FB_DEFAULT_IO_OPS_DRAW,
+   __FB_DEFAULT_DMA_OPS_DRAW,
.fb_mmap= exynos_drm_fb_mmap,
.fb_destroy = exynos_drm_fb_destroy,
 };
-- 
2.41.0

[PATCH 00/10] drm: Improve fbdev emulation for DMA-able framebuffers

[Thomas Zimmermann]

Add fbdev helpers for framebuffers in DMA-able memory and update
fbdev emulation in the respective DRM drivers. DMA memory used to
handled as system memory. Improve this and prepare for possible
future changes.

Patch 1 adds initializer macros for struct fb_ops and a Kconfig
token for framebuffers in DMA memory.

Patches 2 to 4 update fbdev-dma and tegra. No functional changes
are expected as both used system memory before.

Patches 5 and 6 update exynos to use DMA helpers. Exynos incorrectly
used fbdev's I/O-memory helpers. Fix this.

Patches 7 to 9 update omapdrm to use DMA helpers. Patch 7 first
reworks the driver's mmap to current best practices. This also makes
it suitable for use with fbdev, which patches 8 and 9 implement.

Patch 10 removes some fbdev macros for system memory that are now
unused.

The patchset would ideally go through drm-misc-next. Future patches
can build upon it and update fbdev drivers in similar ways.

Thomas Zimmermann (10):
  fbdev: Add fb_ops init macros for framebuffers in DMA-able memory
  drm/fbdev-dma: Use fbdev DMA helpers
  drm/tegra: Use fbdev DMA helpers
  drm/tegra: Set fbdev flags
  drm/exynos: Use fbdev DMA helpers
  drm/exynos: Set fbdev flags
  drm/omapdrm: Set VM flags in GEM-object mmap function
  drm/omapdrm: Use GEM mmap for fbdev emulation
  drm/omapdrm: Set fbdev flags
  fbdev: Remove FB_DEFAULT_SYS_OPS

 drivers/gpu/drm/Kconfig   |  2 +-
 drivers/gpu/drm/drm_fbdev_dma.c   |  4 ++--
 drivers/gpu/drm/exynos/Kconfig|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  6 --
 drivers/gpu/drm/omapdrm/Kconfig   |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c| 12 +---
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 17 ++--
 drivers/gpu/drm/omapdrm/omap_gem.c| 24 ++-
 drivers/gpu/drm/omapdrm/omap_gem.h|  3 ---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  7 +--
 drivers/gpu/drm/tegra/Kconfig |  2 +-
 drivers/gpu/drm/tegra/fbdev.c |  7 +--
 drivers/video/fbdev/Kconfig   |  8 
 include/linux/fb.h| 17 ++--
 14 files changed, 57 insertions(+), 56 deletions(-)

-- 
2.41.0

[PATCH 02/10] drm/fbdev-dma: Use fbdev DMA helpers

[Thomas Zimmermann]

Use fbdev's DMA helpers for fbdev-dma. They are equivalent to the
previously used system-memory helpers, so no functional changes here.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/Kconfig | 2 +-
 drivers/gpu/drm/drm_fbdev_dma.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..da3aa0625c36 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -216,7 +216,7 @@ config DRM_TTM_HELPER
 config DRM_GEM_DMA_HELPER
tristate
depends on DRM
-   select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
+   select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
help
  Choose this if you need the GEM DMA helper functions
 
diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index 8217f1ddc007..040c229a1737 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -62,9 +62,9 @@ static const struct fb_ops drm_fbdev_dma_fb_ops = {
.owner = THIS_MODULE,
.fb_open = drm_fbdev_dma_fb_open,
.fb_release = drm_fbdev_dma_fb_release,
-   __FB_DEFAULT_SYS_OPS_RDWR,
+   __FB_DEFAULT_DMA_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
-   __FB_DEFAULT_SYS_OPS_DRAW,
+   __FB_DEFAULT_DMA_OPS_DRAW,
.fb_mmap = drm_fbdev_dma_fb_mmap,
.fb_destroy = drm_fbdev_dma_fb_destroy,
 };
-- 
2.41.0

[PATCH 01/10] fbdev: Add fb_ops init macros for framebuffers in DMA-able memory

[Thomas Zimmermann]

Add initializer macros for struct fb_ops for framebuffers in DMA-able
memory areas. Also add a corresponding Kconfig token. As of now, this
is equivalent to system framebuffers and mostly useful for labeling
drivers correctly.

A later patch may add a generic DMA-specific mmap operation. Linux
offers a number of dma_mmap_*() helpers for different use cases.

Signed-off-by: Thomas Zimmermann 
Cc: Helge Deller 
---
 drivers/video/fbdev/Kconfig |  8 
 include/linux/fb.h  | 13 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cecf15418632..f14229757311 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -168,6 +168,14 @@ config FB_DEFERRED_IO
bool
depends on FB
 
+config FB_DMA_HELPERS
+   bool
+   depends on FB
+   select FB_SYS_COPYAREA
+   select FB_SYS_FILLRECT
+   select FB_SYS_FOPS
+   select FB_SYS_IMAGEBLIT
+
 config FB_IO_HELPERS
bool
depends on FB
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d5c13f34b09..1191a78c5289 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -594,6 +594,19 @@ extern ssize_t fb_sys_write(struct fb_info *info, const 
char __user *buf,
__FB_DEFAULT_SYS_OPS_DRAW, \
__FB_DEFAULT_SYS_OPS_MMAP
 
+/*
+ * Helpers for framebuffers in DMA-able memory
+ */
+
+#define __FB_DEFAULT_DMA_OPS_RDWR \
+   .fb_read= fb_sys_read, \
+   .fb_write   = fb_sys_write
+
+#define __FB_DEFAULT_DMA_OPS_DRAW \
+   .fb_fillrect= sys_fillrect, \
+   .fb_copyarea= sys_copyarea, \
+   .fb_imageblit   = sys_imageblit
+
 /* drivers/video/fbmem.c */
 extern int register_framebuffer(struct fb_info *fb_info);
 extern void unregister_framebuffer(struct fb_info *fb_info);
-- 
2.41.0

Re: [PATCH v2 14/14] drm/msm/dpu: drop dpu_core_perf_destroy()

[Abhinav Kumar]

On 7/4/2023 8:03 AM, Dmitry Baryshkov wrote:

This function does nothing, just clears several data pointers. Drop it
now.



Now, it doesnt even do that. Just resets the clk_rate to 0.


Acked-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 10 --
  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  6 --
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  1 -
  3 files changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 608c915a2cab..4b8127932e13 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -408,16 +408,6 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, 
struct dentry *parent)
  }
  #endif
  
-void dpu_core_perf_destroy(struct dpu_core_perf *perf)

-{
-   if (!perf) {
-   DPU_ERROR("invalid parameters\n");
-   return;
-   }
-
-   perf->max_core_clk_rate = 0;
-}
-
  int dpu_core_perf_init(struct dpu_core_perf *perf,
const struct dpu_perf_cfg *perf_cfg,
unsigned long max_core_clk_rate)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index df1fcf28f2a9..a5a9c3389718 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -66,12 +66,6 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
   */
  void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc);
  
-/**

- * dpu_core_perf_destroy - destroy the given core performance context
- * @perf: Pointer to core performance context
- */
-void dpu_core_perf_destroy(struct dpu_core_perf *perf);
-
  /**
   * dpu_core_perf_init - initialize the given core performance context
   * @perf: Pointer to core performance context
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index f01b2278c01a..44b0daf70c4e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1171,7 +1171,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
return 0;
  
  drm_obj_init_err:

-   dpu_core_perf_destroy(&dpu_kms->perf);
  hw_intr_init_err:
  perf_err:
  power_error:

Re: [PATCH v2 05/14] drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()

[Abhinav Kumar]

On 7/4/2023 8:03 AM, Dmitry Baryshkov wrote:

Move perf mode handling for the bandwidth to
_dpu_core_perf_crtc_update_bus() rather than overriding per-CRTC data
and then aggregating known values.

Note, this changes the fix_core_ab_vote. Previously it would be
multiplied per the CRTC number, now it will be used directly for
interconnect voting.

Signed-off-by: Dmitry Baryshkov 


Break this out into a separate series. This rework doesnt need to be 
part of this cleanup series.



---
  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 +--
  1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 348550ac7e51..42c03a5f1f3e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -116,21 +116,9 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
return;
}
  
-	memset(perf, 0, sizeof(struct dpu_core_perf_params));

-
-   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
-   perf->bw_ctl = 0;
-   perf->max_per_pipe_ib = 0;
-   perf->core_clk_rate = 0;
-   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
-   perf->bw_ctl = kms->perf.fix_core_ab_vote;
-   perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
-   perf->core_clk_rate = kms->perf.fix_core_clk_rate;
-   } else {
-   perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
-   perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
-   perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
-   }
+   perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
+   perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
+   perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
  
  	DRM_DEBUG_ATOMIC(

"crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
@@ -236,17 +224,28 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
struct dpu_core_perf_params perf = { 0 };
int i, ret = 0;
u32 avg_bw;
+   u32 peak_bw;
  
  	if (!kms->num_paths)

return 0;
  
-	dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), &perf);

+   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
+   avg_bw = 0;
+   peak_bw = 0;
+   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
+   avg_bw = kms->perf.fix_core_ab_vote;
+   peak_bw = kms->perf.fix_core_ib_vote;
+   } else {
+   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
+
+   avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
+   peak_bw = perf.max_per_pipe_ib;
+   }
  
-	avg_bw = perf.bw_ctl;

-   do_div(avg_bw, (kms->num_paths * 1000)); /*Bps_to_icc*/
+   avg_bw /= kms->num_paths;
  
  	for (i = 0; i < kms->num_paths; i++)

-   icc_set_bw(kms->path[i], avg_bw, perf.max_per_pipe_ib);
+   icc_set_bw(kms->path[i], avg_bw, peak_bw);
  
  	return ret;

  }

Re: [PATCH v2 06/14] drm/msm/dpu: rework core_perf debugfs overrides

[Abhinav Kumar]

On 7/4/2023 8:03 AM, Dmitry Baryshkov wrote:

Currently debugfs provides separate 'modes' to override calculated
MDP_CLK rate and interconnect bandwidth votes. Change that to allow
overriding individual values (e.g. one can override just clock or just
average bandwidth vote).

Signed-off-by: Dmitry Baryshkov 


Can you break this out into a separate series on its own?

I would like to spend more time on this and dont want to hold up the 
rest of the cleanup part of the series for this.



---
  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 87 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 10 ---
  2 files changed, 9 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 42c03a5f1f3e..23a29f159eff 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -17,20 +17,6 @@
  #include "dpu_crtc.h"
  #include "dpu_core_perf.h"
  
-/**

- * enum dpu_perf_mode - performance tuning mode
- * @DPU_PERF_MODE_NORMAL: performance controlled by user mode client
- * @DPU_PERF_MODE_MINIMUM: performance bounded by minimum setting
- * @DPU_PERF_MODE_FIXED: performance bounded by fixed setting
- * @DPU_PERF_MODE_MAX: maximum value, used for error checking
- */
-enum dpu_perf_mode {
-   DPU_PERF_MODE_NORMAL,
-   DPU_PERF_MODE_MINIMUM,
-   DPU_PERF_MODE_FIXED,
-   DPU_PERF_MODE_MAX
-};
-
  /**
   * _dpu_core_perf_calc_bw() - to calculate BW per crtc
   * @kms:  pointer to the dpu_kms
@@ -229,18 +215,16 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
if (!kms->num_paths)
return 0;
  
-	if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {

-   avg_bw = 0;
-   peak_bw = 0;
-   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
+   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
+
+   avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
+   peak_bw = perf.max_per_pipe_ib;
+
+   if (kms->perf.fix_core_ab_vote)
avg_bw = kms->perf.fix_core_ab_vote;
-   peak_bw = kms->perf.fix_core_ib_vote;
-   } else {
-   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
  
-		avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/

-   peak_bw = perf.max_per_pipe_ib;
-   }
+   if (kms->perf.fix_core_ib_vote)
+   peak_bw = kms->perf.fix_core_ib_vote;
  
  	avg_bw /= kms->num_paths;
  
@@ -294,12 +278,9 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)

struct drm_crtc *crtc;
struct dpu_crtc_state *dpu_cstate;
  
-	if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED)

+   if (kms->perf.fix_core_clk_rate)
return kms->perf.fix_core_clk_rate;
  
-	if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM)

-   return kms->perf.max_core_clk_rate;
-
drm_for_each_crtc(crtc, kms->dev) {
if (crtc->enabled) {
dpu_cstate = to_dpu_crtc_state(crtc->state);
@@ -416,54 +397,6 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
  
  #ifdef CONFIG_DEBUG_FS
  
-static ssize_t _dpu_core_perf_mode_write(struct file *file,

-   const char __user *user_buf, size_t count, loff_t *ppos)
-{
-   struct dpu_core_perf *perf = file->private_data;
-   u32 perf_mode = 0;
-   int ret;
-
-   ret = kstrtouint_from_user(user_buf, count, 0, &perf_mode);
-   if (ret)
-   return ret;
-
-   if (perf_mode >= DPU_PERF_MODE_MAX)
-   return -EINVAL;
-
-   if (perf_mode == DPU_PERF_MODE_FIXED) {
-   DRM_INFO("fix performance mode\n");
-   } else if (perf_mode == DPU_PERF_MODE_MINIMUM) {
-   /* run the driver with max clk and BW vote */
-   DRM_INFO("minimum performance mode\n");
-   } else if (perf_mode == DPU_PERF_MODE_NORMAL) {
-   /* reset the perf tune params to 0 */
-   DRM_INFO("normal performance mode\n");
-   }
-   perf->perf_tune.mode = perf_mode;
-
-   return count;
-}
-
-static ssize_t _dpu_core_perf_mode_read(struct file *file,
-   char __user *buff, size_t count, loff_t *ppos)
-{
-   struct dpu_core_perf *perf = file->private_data;
-   int len;
-   char buf[128];
-
-   len = scnprintf(buf, sizeof(buf),
-   "mode %d\n",
-   perf->perf_tune.mode);
-
-   return simple_read_from_buffer(buff, count, ppos, buf, len);
-}
-
-static const struct file_operations dpu_core_perf_mode_fops = {
-   .open = simple_open,
-   .read = _dpu_core_perf_mode_read,
-   .write = _dpu_core_perf_mode_write,
-};
-
  int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
  {
struct dpu_core_perf *perf = &dpu_kms->perf;

Re: [PATCH] backlight: led_bl: fix initial power state

[Daniel Thompson]

On Tue, Jul 04, 2023 at 04:31:51PM +0100, Måns Rullgård wrote:
> Daniel Thompson  writes:
>
> > On Tue, Jul 04, 2023 at 03:07:50PM +0100, Mans Rullgard wrote:
> >> The condition for the initial power state based on the default
> >> brightness value is reversed.  Fix it.
> >>
> >> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
> >> Signed-off-by: Mans Rullgard 
> >> ---
> >>  drivers/video/backlight/led_bl.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/video/backlight/led_bl.c 
> >> b/drivers/video/backlight/led_bl.c
> >> index 3259292fda76..28e83618a296 100644
> >> --- a/drivers/video/backlight/led_bl.c
> >> +++ b/drivers/video/backlight/led_bl.c
> >> @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
> >>props.type = BACKLIGHT_RAW;
> >>props.max_brightness = priv->max_brightness;
> >>props.brightness = priv->default_brightness;
> >> -  props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
> >> -FB_BLANK_UNBLANK;
> >> +  props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
> >> +FB_BLANK_POWERDOWN;
> >
> > The logic was wrong before but I think will still be wrong after the
> > change too (e.g. the bogus logic is probably avoiding backlight flicker
> > in some use cases).
> >
> > The logic here needs to be similar to what pwm_bl.c implements in
> > pwm_backlight_initial_power_state(). Whilst it might be better
> > to implement this in led_bl_get_leds() let me show what I mean
> > in code that fits in the current line:
> >
> > /*
> >  * Activate the backlight if the LEDs are already lit *or*
> >  * there is no phandle link (meaning the backlight power
> >  * state cannot be synced with the display state).
> >  */
> > props.power = (active_at_boot || !dev->node->phandle) ?
> > FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
> >
> > Note that active_at_boot is not the same as (priv->default_brightness > 0)
> > since the value read by led_bl_get_leds() can be clobbered when we
> > parse the properties.
>
> Am I understanding correctly that the code should be using the
> default_brightness value as set by led_bl_get_leds() to determine the
> initial power state, not whatever default value the devicetree provides?

Yes.

The devicetree allows us to specify a default brightness but the DT
value cannot not be used to decide if the backlight has already been
lit up.


Daniel.

Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

[Arnd Bergmann]

On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
> Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
>>>
>>> Modern AMD GPUs have 16GiB of local memory (VRAM), making those
>>> accessible to a CPU which can only handle 32bit addresses by resizing
>>> the BAR is impossible to begin with.
>>>
>>> But going a step further even without resizing it is pretty hard to get
>>> that hardware working on such an architecture.
>> I'd still like to understand this part better, as we have a lot of
>> arm64 chips with somewhat flawed PCIe implementations, often with
>> a tiny 64-bit memory space, but otherwise probably capable of
>> using a GPU.
>
> Yeah, those are unfortunately very well known to us :(
>
>> What exactly do you expect to happen here?
>>
>> a) Use only part of the VRAM but otherwise work as expected
>> b) Access all of the VRAM, but at a performance cost for
>> bank switching?
>
> We have tons of x86 systems where we can't resize the BAR (because of 
> lack of BIOS setup of the root PCIe windows). So bank switching is still 
> perfectly supported.

Ok, good.

> After investigating (which sometimes even includes involving engineers 
> from ARM) we usually find that those boards doesn't even remotely comply 
> to the PCIe specification, both regarding power as well as functional 
> things like DMA coherency.

Makes sense, the power usage is clearly going to make this
impossible on a lot of boards. I would have expected noncoherent
DMA to be a solvable problem, since that generally works with
all drivers that use the dma-mapping interfaces correctly,
but I understand that drivers/gpu/* often does its own thing
here, which may make that harder.

 Arnd

Re: [PATCH v3 02/17] dt-bindings: gpu: Add Imagination Technologies PowerVR GPU

[Frank Binns]

Hi Linus,

On Fri, 2023-06-16 at 14:48 +0200, Linus Walleij wrote:
> Hi Sarah,
> 
> thanks for your patch!
> 
> On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker  wrote:
> 
> > Add the device tree binding documentation for the Series AXE GPU used in
> > TI AM62 SoCs.
> > 
> > Signed-off-by: Sarah Walker 
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - ti,am62-gpu
> > +  - const: img,powervr-seriesaxe
> 
> I don't see why you need to restrict the bindings to just the stuff
> you happen to
> be writing Linux drivers for right now.
> 
> Add all of them!

The main thinking here was to start off with a single simple case (TI AM62) to
support the initial driver upstreaming rather than trying to cover too many
things at once. This can then be built upon for other GPUs. So, for example, we
can extend the bindings to add a second power domain for those that need it,
such as the GPU in the Mediatek MT8173. The benefit of this approach is that the
bindings, dts and code changes can all be reviewed together so that all the
context is present.

> 
> There is this out-of-tree binding:
> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/0ddd308a78926782b8a72f75c74b91417ceb9779
> 
> With these two on top:
> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/053346e1933932815066f16ebf6e6bda45d67548
> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/1cb62c4cdcad096d438ee7d1d51f6001998acee3
> 
> They are indeed out-of-tree, but H. Nikolaus is a well-known and respected
> contributor to the kernel, and I'm pretty sure he would be contributing
> these upstream if he had the time and incentive.
> 
> To me it seems much more like you should talk to Nikolaus about submitting
> these patches initially, and then add Rogue support with patches on top of it.
> It could be a nice series with just DT bindings.
> 
> I see that your binding uses a power domain rather than a regulator
> (sgx-supply) for power and that is probably a better approach but other
> than that the openpvrsgx binding looks more complete and to the point?
> 
> It will also help them to get these bindings settled so they can merge all
> of the DTS patches adding the SGX block to misc platforms in the
> kernel upstream so they can focus their work on the actual driver.
> 
> When I look at the PowerVR wikipedia page:
> https://en.wikipedia.org/wiki/PowerVR
> there is no correspondence between the product names there and
> "img,powervr-seriesaxe" as used here.
> 
> I think you need to explain if these are internal product names or what
> is going on, and what the relationship is to the marketing names, it could
> be part of the description simply, so that people know what string to use
> somewhat intuitively. Maybe all the strings in the out-of-tree documentation
> are just wrong because internal code names need to be used?

It's been quite some time since we originally wrote these bindings, so we'll
need to go back and check why we settled on "powervr-seriesaxe", but I suspect
it was just a case of us normalising the naming across different series.

Thanks
Frank

> 
> Yours,
> Linus Walleij

[PATCH v2 13/14] drm/msm/dpu: move max clock decision to dpu_kms.

[Dmitry Baryshkov]

dpu_core_perf should not make decisions on the maximum possible core
clock rate. Pass the value from dpu_kms_hw_init().

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 11 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  8 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 13 +++--
 3 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index d533b63f90f6..608c915a2cab 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -416,21 +416,14 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
}
 
perf->max_core_clk_rate = 0;
-   perf->core_clk = NULL;
 }
 
 int dpu_core_perf_init(struct dpu_core_perf *perf,
const struct dpu_perf_cfg *perf_cfg,
-   struct clk *core_clk)
+   unsigned long max_core_clk_rate)
 {
perf->perf_cfg = perf_cfg;
-   perf->core_clk = core_clk;
-
-   perf->max_core_clk_rate = clk_get_rate(core_clk);
-   if (!perf->max_core_clk_rate) {
-   DPU_DEBUG("optional max core clk rate, use default\n");
-   perf->max_core_clk_rate = DPU_PERF_DEFAULT_MAX_CORE_CLK_RATE;
-   }
+   perf->max_core_clk_rate = max_core_clk_rate;
 
return 0;
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 7c5142aca4ee..df1fcf28f2a9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -12,8 +12,6 @@
 
 #include "dpu_hw_catalog.h"
 
-#defineDPU_PERF_DEFAULT_MAX_CORE_CLK_RATE  41250
-
 /**
  * struct dpu_core_perf_params - definition of performance parameters
  * @bw_ctl: arbitrated bandwidth request
@@ -27,7 +25,6 @@ struct dpu_core_perf_params {
 /**
  * struct dpu_core_perf - definition of core performance context
  * @perf_cfg: Platform-specific performance configuration
- * @core_clk: Pointer to the core clock
  * @core_clk_rate: current core clock rate
  * @max_core_clk_rate: maximum allowable core clock rate
  * @enable_bw_release: debug control for bandwidth release
@@ -37,7 +34,6 @@ struct dpu_core_perf_params {
  */
 struct dpu_core_perf {
const struct dpu_perf_cfg *perf_cfg;
-   struct clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
u32 enable_bw_release;
@@ -80,11 +76,11 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf);
  * dpu_core_perf_init - initialize the given core performance context
  * @perf: Pointer to core performance context
  * @perf_cfg: Pointer to platform performance configuration
- * @core_clk: pointer to core clock
+ * @max_core_clk_rate: Maximum core clock rate
  */
 int dpu_core_perf_init(struct dpu_core_perf *perf,
const struct dpu_perf_cfg *perf_cfg,
-   struct clk *core_clk);
+   unsigned long max_core_clk_rate);
 
 struct dpu_kms;
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 631b6b679bae..f01b2278c01a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1011,11 +1011,14 @@ unsigned long dpu_kms_get_clk_rate(struct dpu_kms 
*dpu_kms, char *clock_name)
return clk_get_rate(clk);
 }
 
+#defineDPU_PERF_DEFAULT_MAX_CORE_CLK_RATE  41250
+
 static int dpu_kms_hw_init(struct msm_kms *kms)
 {
struct dpu_kms *dpu_kms;
struct drm_device *dev;
int i, rc = -EINVAL;
+   unsigned long max_core_clk_rate;
u32 core_rev;
 
if (!kms) {
@@ -1115,8 +1118,14 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->hw_vbif[vbif->id] = hw;
}
 
-   rc = dpu_core_perf_init(&dpu_kms->perf, dpu_kms->catalog->perf,
-   msm_clk_bulk_get_clock(dpu_kms->clocks, 
dpu_kms->num_clocks, "core"));
+   /* TODO: use the same max_freq as in dpu_kms_hw_init */
+   max_core_clk_rate = dpu_kms_get_clk_rate(dpu_kms, "core");
+   if (!max_core_clk_rate) {
+   DPU_DEBUG("max core clk rate not determined, using default\n");
+   max_core_clk_rate = DPU_PERF_DEFAULT_MAX_CORE_CLK_RATE;
+   }
+
+   rc = dpu_core_perf_init(&dpu_kms->perf, dpu_kms->catalog->perf, 
max_core_clk_rate);
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
goto perf_err;
-- 
2.39.2

[PATCH v2 10/14] drm/msm/dpu: use dpu_perf_cfg in DPU core_perf code

[Dmitry Baryshkov]

Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using
full-featured catalog data.

Acked-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 58 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  8 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  2 +-
 3 files changed, 27 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index f15efaaaf9fa..e9c7d398d9cb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -19,11 +19,11 @@
 
 /**
  * _dpu_core_perf_calc_bw() - to calculate BW per crtc
- * @kms:  pointer to the dpu_kms
+ * @perf_cfg: performance configuration
  * @crtc: pointer to a crtc
  * Return: returns aggregated BW for all planes in crtc.
  */
-static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
+static u64 _dpu_core_perf_calc_bw(const struct dpu_perf_cfg *perf_cfg,
struct drm_crtc *crtc)
 {
struct drm_plane *plane;
@@ -39,7 +39,7 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
crtc_plane_bw += pstate->plane_fetch_bw;
}
 
-   bw_factor = kms->catalog->perf->bw_inefficiency_factor;
+   bw_factor = perf_cfg->bw_inefficiency_factor;
if (bw_factor) {
crtc_plane_bw *= bw_factor;
do_div(crtc_plane_bw, 100);
@@ -50,12 +50,12 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
 
 /**
  * _dpu_core_perf_calc_clk() - to calculate clock per crtc
- * @kms:  pointer to the dpu_kms
+ * @perf_cfg: performance configuration
  * @crtc: pointer to a crtc
  * @state: pointer to a crtc state
  * Return: returns max clk for all planes in crtc.
  */
-static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
+static u64 _dpu_core_perf_calc_clk(const struct dpu_perf_cfg *perf_cfg,
struct drm_crtc *crtc, struct drm_crtc_state *state)
 {
struct drm_plane *plane;
@@ -76,7 +76,7 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
crtc_clk = max(pstate->plane_clk, crtc_clk);
}
 
-   clk_factor = kms->catalog->perf->clk_inefficiency_factor;
+   clk_factor = perf_cfg->clk_inefficiency_factor;
if (clk_factor) {
crtc_clk *= clk_factor;
do_div(crtc_clk, 100);
@@ -92,18 +92,18 @@ static struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc 
*crtc)
return to_dpu_kms(priv->kms);
 }
 
-static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
+static void _dpu_core_perf_calc_crtc(const struct dpu_perf_cfg *perf_cfg,
struct drm_crtc *crtc,
struct drm_crtc_state *state,
struct dpu_core_perf_params *perf)
 {
-   if (!kms || !kms->catalog || !crtc || !state || !perf) {
+   if (!perf_cfg || !crtc || !state || !perf) {
DPU_ERROR("invalid parameters\n");
return;
}
 
-   perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
-   perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
+   perf->bw_ctl = _dpu_core_perf_calc_bw(perf_cfg, crtc);
+   perf->core_clk_rate = _dpu_core_perf_calc_clk(perf_cfg, crtc, state);
 
DRM_DEBUG_ATOMIC(
"crtc=%d clk_rate=%llu core_ab=%llu\n",
@@ -120,6 +120,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
struct dpu_crtc_state *dpu_cstate;
struct drm_crtc *tmp_crtc;
struct dpu_kms *kms;
+   const struct dpu_perf_cfg *perf_cfg;
 
if (!crtc || !state) {
DPU_ERROR("invalid crtc\n");
@@ -127,10 +128,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
}
 
kms = _dpu_crtc_get_kms(crtc);
-   if (!kms->catalog) {
-   DPU_ERROR("invalid parameters\n");
-   return 0;
-   }
+   perf_cfg = kms->perf.perf_cfg;
 
/* we only need bandwidth check on real-time clients (interfaces) */
if (dpu_crtc_get_client_type(crtc) == NRT_CLIENT)
@@ -139,7 +137,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
dpu_cstate = to_dpu_crtc_state(state);
 
/* obtain new values */
-   _dpu_core_perf_calc_crtc(kms, crtc, state, &dpu_cstate->new_perf);
+   _dpu_core_perf_calc_crtc(perf_cfg, crtc, state, &dpu_cstate->new_perf);
 
bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl;
curr_client_type = dpu_crtc_get_client_type(crtc);
@@ -162,7 +160,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
bw = DIV_ROUND_UP_ULL(bw_sum_of_intfs, 1000);
DRM_DEBUG_ATOMIC("calculated bandwidth=%uk\n", bw);
 
-   threshold = kms->catalog->perf->max_bw_high;
+   threshold = perf_cfg->max_bw_high;
 
DRM_DEBUG_ATOMIC("final threshold bw limit = %d\n", threshold);
 
@@ -214,7 +212,7 @@ static int _dpu_core_perf_crtc_update_bus(struct d

[PATCH v2 14/14] drm/msm/dpu: drop dpu_core_perf_destroy()

[Dmitry Baryshkov]

This function does nothing, just clears several data pointers. Drop it
now.

Acked-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 10 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  6 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  1 -
 3 files changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 608c915a2cab..4b8127932e13 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -408,16 +408,6 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, 
struct dentry *parent)
 }
 #endif
 
-void dpu_core_perf_destroy(struct dpu_core_perf *perf)
-{
-   if (!perf) {
-   DPU_ERROR("invalid parameters\n");
-   return;
-   }
-
-   perf->max_core_clk_rate = 0;
-}
-
 int dpu_core_perf_init(struct dpu_core_perf *perf,
const struct dpu_perf_cfg *perf_cfg,
unsigned long max_core_clk_rate)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index df1fcf28f2a9..a5a9c3389718 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -66,12 +66,6 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
  */
 void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc);
 
-/**
- * dpu_core_perf_destroy - destroy the given core performance context
- * @perf: Pointer to core performance context
- */
-void dpu_core_perf_destroy(struct dpu_core_perf *perf);
-
 /**
  * dpu_core_perf_init - initialize the given core performance context
  * @perf: Pointer to core performance context
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index f01b2278c01a..44b0daf70c4e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1171,7 +1171,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
return 0;
 
 drm_obj_init_err:
-   dpu_core_perf_destroy(&dpu_kms->perf);
 hw_intr_init_err:
 perf_err:
 power_error:
-- 
2.39.2

[PATCH v2 12/14] drm/msm/dpu: core_perf: remove extra clk_round_rate() call

[Dmitry Baryshkov]

The dev_pm_opp_set_rate() already contains a call for clk_round_rate for
the passed value. Stop calling it manually from
_dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it
this way, as we should round the final calculated clock rate rather than
rounding all the intermediate values.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 906611f6b879..d533b63f90f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -274,8 +274,6 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
dpu_cstate = to_dpu_crtc_state(crtc->state);
clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
clk_rate);
-   clk_rate = clk_round_rate(kms->perf.core_clk,
-   clk_rate);
}
}
 
-- 
2.39.2

[PATCH v2 09/14] drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param

[Dmitry Baryshkov]

The stop_req is true only in the dpu_crtc_disable() case, when
crtc->enable has already been set to false. This renders the stop_req
argument useless. Remove it completely.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  3 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  6 +++---
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index bdd00c3af1c6..f15efaaaf9fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -291,7 +291,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
 }
 
 int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
-   int params_changed, bool stop_req)
+ int params_changed)
 {
struct dpu_core_perf_params *new, *old;
bool update_bus = false, update_clk = false;
@@ -315,13 +315,13 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
dpu_crtc = to_dpu_crtc(crtc);
dpu_cstate = to_dpu_crtc_state(crtc->state);
 
-   DRM_DEBUG_ATOMIC("crtc:%d stop_req:%d core_clk:%llu\n",
-   crtc->base.id, stop_req, kms->perf.core_clk_rate);
+   DRM_DEBUG_ATOMIC("crtc:%d enabled:%d core_clk:%llu\n",
+   crtc->base.id, crtc->enabled, kms->perf.core_clk_rate);
 
old = &dpu_crtc->cur_perf;
new = &dpu_cstate->new_perf;
 
-   if (crtc->enabled && !stop_req) {
+   if (crtc->enabled) {
/*
 * cases for bus bandwidth update.
 * 1. new bandwidth vote - "ab or ib vote" is higher
@@ -351,7 +351,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
}
 
trace_dpu_perf_crtc_update(crtc->base.id, new->bw_ctl,
-   new->core_clk_rate, stop_req, update_bus, update_clk);
+   new->core_clk_rate, !crtc->enabled, update_bus, update_clk);
 
if (update_bus) {
ret = _dpu_core_perf_crtc_update_bus(kms, crtc);
@@ -371,7 +371,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DRM_DEBUG_ATOMIC("clk:%llu\n", clk_rate);
 
-   trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
+   trace_dpu_core_perf_update_clk(kms->dev, !crtc->enabled, 
clk_rate);
 
clk_rate = min(clk_rate, kms->perf.max_core_clk_rate);
ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 4f362bb6a520..0b8c527f489e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -63,11 +63,10 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
  * dpu_core_perf_crtc_update - update performance of the given crtc
  * @crtc: Pointer to crtc
  * @params_changed: true if crtc parameters are modified
- * @stop_req: true if this is a stop request
  * return: zero if success, or error code otherwise
  */
 int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
-   int params_changed, bool stop_req);
+ int params_changed);
 
 /**
  * dpu_core_perf_crtc_release_bw - release bandwidth of the given crtc
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ff5d306b95ed..214229d11e3e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -718,7 +718,7 @@ static void dpu_crtc_frame_event_cb(void *data, u32 event)
 void dpu_crtc_complete_commit(struct drm_crtc *crtc)
 {
trace_dpu_crtc_complete_commit(DRMID(crtc));
-   dpu_core_perf_crtc_update(crtc, 0, false);
+   dpu_core_perf_crtc_update(crtc, 0);
_dpu_crtc_complete_flip(crtc);
 }
 
@@ -884,7 +884,7 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc,
return;
 
/* update performance setting before crtc kickoff */
-   dpu_core_perf_crtc_update(crtc, 1, false);
+   dpu_core_perf_crtc_update(crtc, 1);
 
/*
 * Final plane updates: Give each plane a chance to complete all
@@ -1100,7 +1100,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
atomic_set(&dpu_crtc->frame_pending, 0);
}
 
-   dpu_core_perf_crtc_update(crtc, 0, true);
+   dpu_core_perf_crtc_update(crtc, 0);
 
drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask)
dpu_encoder_register_frame_event_callback(encoder, NULL, NULL);
-- 
2.39.2

[PATCH v2 11/14] drm/msm/dpu: remove unused fields from struct dpu_core_perf

[Dmitry Baryshkov]

Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they
are not used by the code.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 6 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 2 +-
 3 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index e9c7d398d9cb..906611f6b879 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -419,15 +419,12 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
 
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
-   perf->dev = NULL;
 }
 
 int dpu_core_perf_init(struct dpu_core_perf *perf,
-   struct drm_device *dev,
const struct dpu_perf_cfg *perf_cfg,
struct clk *core_clk)
 {
-   perf->dev = dev;
perf->perf_cfg = perf_cfg;
perf->core_clk = core_clk;
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 4490120d11d4..7c5142aca4ee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -26,8 +26,6 @@ struct dpu_core_perf_params {
 
 /**
  * struct dpu_core_perf - definition of core performance context
- * @dev: Pointer to drm device
- * @debugfs_root: top level debug folder
  * @perf_cfg: Platform-specific performance configuration
  * @core_clk: Pointer to the core clock
  * @core_clk_rate: current core clock rate
@@ -38,8 +36,6 @@ struct dpu_core_perf_params {
  * @fix_core_ab_vote: fixed core ab vote in bps used in mode 2
  */
 struct dpu_core_perf {
-   struct drm_device *dev;
-   struct dentry *debugfs_root;
const struct dpu_perf_cfg *perf_cfg;
struct clk *core_clk;
u64 core_clk_rate;
@@ -83,12 +79,10 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf);
 /**
  * dpu_core_perf_init - initialize the given core performance context
  * @perf: Pointer to core performance context
- * @dev: Pointer to drm device
  * @perf_cfg: Pointer to platform performance configuration
  * @core_clk: pointer to core clock
  */
 int dpu_core_perf_init(struct dpu_core_perf *perf,
-   struct drm_device *dev,
const struct dpu_perf_cfg *perf_cfg,
struct clk *core_clk);
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 6e62606e32de..631b6b679bae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1115,7 +1115,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->hw_vbif[vbif->id] = hw;
}
 
-   rc = dpu_core_perf_init(&dpu_kms->perf, dev, dpu_kms->catalog->perf,
+   rc = dpu_core_perf_init(&dpu_kms->perf, dpu_kms->catalog->perf,
msm_clk_bulk_get_clock(dpu_kms->clocks, 
dpu_kms->num_clocks, "core"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
-- 
2.39.2

[PATCH v2 07/14] drm/msm/dpu: drop dpu_core_perf_params::max_per_pipe_ib

[Dmitry Baryshkov]

The max_per_pipe_ib is a constant across all CRTCs and is read from the
catalog. Drop corresponding calculations and read the value directly at
icc_set_bw() time.

Suggested-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  2 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  2 --
 3 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 23a29f159eff..fe4d7e08ac1d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -103,13 +103,12 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
}
 
perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
-   perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
 
DRM_DEBUG_ATOMIC(
-   "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
+   "crtc=%d clk_rate=%llu core_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
-   perf->max_per_pipe_ib, perf->bw_ctl);
+   perf->bw_ctl);
 }
 
 int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
@@ -192,9 +191,6 @@ static void dpu_core_perf_aggregate(struct drm_device *ddev,
curr_client_type == dpu_crtc_get_client_type(tmp_crtc)) {
dpu_cstate = to_dpu_crtc_state(tmp_crtc->state);
 
-   perf->max_per_pipe_ib = max(perf->max_per_pipe_ib,
-   
dpu_cstate->new_perf.max_per_pipe_ib);
-
perf->bw_ctl += dpu_cstate->new_perf.bw_ctl;
 
DRM_DEBUG_ATOMIC("crtc=%d bw=%llu\n",
@@ -218,7 +214,7 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
 
avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
-   peak_bw = perf.max_per_pipe_ib;
+   peak_bw = kms->catalog->perf->min_dram_ib;
 
if (kms->perf.fix_core_ab_vote)
avg_bw = kms->perf.fix_core_ab_vote;
@@ -333,15 +329,12 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 * 2. new bandwidth vote - "ab or ib vote" is lower
 *than current vote at end of commit or stop.
 */
-   if ((params_changed && ((new->bw_ctl > old->bw_ctl) ||
-   (new->max_per_pipe_ib > old->max_per_pipe_ib))) ||
-   (!params_changed && ((new->bw_ctl < old->bw_ctl) ||
-   (new->max_per_pipe_ib < old->max_per_pipe_ib {
+   if ((params_changed && new->bw_ctl > old->bw_ctl) ||
+   (!params_changed && new->bw_ctl < old->bw_ctl)) {
DRM_DEBUG_ATOMIC("crtc=%d p=%d 
new_bw=%llu,old_bw=%llu\n",
crtc->base.id, params_changed,
new->bw_ctl, old->bw_ctl);
old->bw_ctl = new->bw_ctl;
-   old->max_per_pipe_ib = new->max_per_pipe_ib;
update_bus = true;
}
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 1b791b170c6b..4f362bb6a520 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -16,12 +16,10 @@
 
 /**
  * struct dpu_core_perf_params - definition of performance parameters
- * @max_per_pipe_ib: maximum instantaneous bandwidth request
  * @bw_ctl: arbitrated bandwidth request
  * @core_clk_rate: core clock rate request
  */
 struct dpu_core_perf_params {
-   u64 max_per_pipe_ib;
u64 bw_ctl;
u64 core_clk_rate;
 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 1edf2b6b0a26..ff5d306b95ed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1400,8 +1400,6 @@ static int dpu_crtc_debugfs_state_show(struct seq_file 
*s, void *v)
seq_printf(s, "core_clk_rate: %llu\n",
dpu_crtc->cur_perf.core_clk_rate);
seq_printf(s, "bw_ctl: %llu\n", dpu_crtc->cur_perf.bw_ctl);
-   seq_printf(s, "max_per_pipe_ib: %llu\n",
-   dpu_crtc->cur_perf.max_per_pipe_ib);
 
return 0;
 }
-- 
2.39.2

[PATCH v2 08/14] drm/msm/dpu: rework indentation in dpu_core_perf

[Dmitry Baryshkov]

dpu_core_perf.c contains several multi-line conditions which are hard to
comprehent because of the indentation. Rework the identation of these
conditions to make it easier to understand them.

Reviewed-by: Abhinav Kumar 
Acked-by: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index fe4d7e08ac1d..bdd00c3af1c6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -146,8 +146,8 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (tmp_crtc->enabled &&
-   (dpu_crtc_get_client_type(tmp_crtc) ==
-   curr_client_type) && (tmp_crtc != crtc)) {
+   dpu_crtc_get_client_type(tmp_crtc) == curr_client_type &&
+   tmp_crtc != crtc) {
struct dpu_crtc_state *tmp_cstate =
to_dpu_crtc_state(tmp_crtc->state);
 
@@ -338,10 +338,8 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
update_bus = true;
}
 
-   if ((params_changed &&
-   (new->core_clk_rate > old->core_clk_rate)) ||
-   (!params_changed &&
-   (new->core_clk_rate < old->core_clk_rate))) {
+   if ((params_changed && new->core_clk_rate > old->core_clk_rate) 
||
+   (!params_changed && new->core_clk_rate < 
old->core_clk_rate)) {
old->core_clk_rate = new->core_clk_rate;
update_clk = true;
}
-- 
2.39.2

[PATCH v2 04/14] drm/msm/dpu: drop separate dpu_core_perf_tune overrides

[Dmitry Baryshkov]

The values in struct dpu_core_perf_tune are fixed per the core perf
mode. Drop the 'tune' values and substitute them with known values when
performing perf management.

Note: min_bus_vote was not used at all, so it is just silently dropped.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 29 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  4 ---
 2 files changed, 12 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 05d340aa18c5..348550ac7e51 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -235,7 +235,7 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 {
struct dpu_core_perf_params perf = { 0 };
int i, ret = 0;
-   u64 avg_bw;
+   u32 avg_bw;
 
if (!kms->num_paths)
return 0;
@@ -291,10 +291,16 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
 
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
 {
-   u64 clk_rate = kms->perf.perf_tune.min_core_clk;
+   u64 clk_rate;
struct drm_crtc *crtc;
struct dpu_crtc_state *dpu_cstate;
 
+   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED)
+   return kms->perf.fix_core_clk_rate;
+
+   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM)
+   return kms->perf.max_core_clk_rate;
+
drm_for_each_crtc(crtc, kms->dev) {
if (crtc->enabled) {
dpu_cstate = to_dpu_crtc_state(crtc->state);
@@ -305,11 +311,6 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
}
}
 
-   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED)
-   clk_rate = kms->perf.fix_core_clk_rate;
-
-   DRM_DEBUG_ATOMIC("clk:%llu\n", clk_rate);
-
return clk_rate;
 }
 
@@ -397,6 +398,8 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
if (update_clk) {
clk_rate = _dpu_core_perf_get_core_clk_rate(kms);
 
+   DRM_DEBUG_ATOMIC("clk:%llu\n", clk_rate);
+
trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
 
clk_rate = min(clk_rate, kms->perf.max_core_clk_rate);
@@ -418,7 +421,6 @@ static ssize_t _dpu_core_perf_mode_write(struct file *file,
const char __user *user_buf, size_t count, loff_t *ppos)
 {
struct dpu_core_perf *perf = file->private_data;
-   const struct dpu_perf_cfg *cfg = perf->catalog->perf;
u32 perf_mode = 0;
int ret;
 
@@ -433,14 +435,9 @@ static ssize_t _dpu_core_perf_mode_write(struct file *file,
DRM_INFO("fix performance mode\n");
} else if (perf_mode == DPU_PERF_MODE_MINIMUM) {
/* run the driver with max clk and BW vote */
-   perf->perf_tune.min_core_clk = perf->max_core_clk_rate;
-   perf->perf_tune.min_bus_vote =
-   (u64) cfg->max_bw_high * 1000;
DRM_INFO("minimum performance mode\n");
} else if (perf_mode == DPU_PERF_MODE_NORMAL) {
/* reset the perf tune params to 0 */
-   perf->perf_tune.min_core_clk = 0;
-   perf->perf_tune.min_bus_vote = 0;
DRM_INFO("normal performance mode\n");
}
perf->perf_tune.mode = perf_mode;
@@ -456,10 +453,8 @@ static ssize_t _dpu_core_perf_mode_read(struct file *file,
char buf[128];
 
len = scnprintf(buf, sizeof(buf),
-   "mode %d min_mdp_clk %llu min_bus_vote %llu\n",
-   perf->perf_tune.mode,
-   perf->perf_tune.min_core_clk,
-   perf->perf_tune.min_bus_vote);
+   "mode %d\n",
+   perf->perf_tune.mode);
 
return simple_read_from_buffer(buff, count, ppos, buf, len);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 29bb8ee2bc26..c965dfbc3007 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -29,13 +29,9 @@ struct dpu_core_perf_params {
 /**
  * struct dpu_core_perf_tune - definition of performance tuning control
  * @mode: performance mode
- * @min_core_clk: minimum core clock
- * @min_bus_vote: minimum bus vote
  */
 struct dpu_core_perf_tune {
u32 mode;
-   u64 min_core_clk;
-   u64 min_bus_vote;
 };
 
 /**
-- 
2.39.2

[PATCH v2 06/14] drm/msm/dpu: rework core_perf debugfs overrides

[Dmitry Baryshkov]

Currently debugfs provides separate 'modes' to override calculated
MDP_CLK rate and interconnect bandwidth votes. Change that to allow
overriding individual values (e.g. one can override just clock or just
average bandwidth vote).

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 87 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 10 ---
 2 files changed, 9 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 42c03a5f1f3e..23a29f159eff 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -17,20 +17,6 @@
 #include "dpu_crtc.h"
 #include "dpu_core_perf.h"
 
-/**
- * enum dpu_perf_mode - performance tuning mode
- * @DPU_PERF_MODE_NORMAL: performance controlled by user mode client
- * @DPU_PERF_MODE_MINIMUM: performance bounded by minimum setting
- * @DPU_PERF_MODE_FIXED: performance bounded by fixed setting
- * @DPU_PERF_MODE_MAX: maximum value, used for error checking
- */
-enum dpu_perf_mode {
-   DPU_PERF_MODE_NORMAL,
-   DPU_PERF_MODE_MINIMUM,
-   DPU_PERF_MODE_FIXED,
-   DPU_PERF_MODE_MAX
-};
-
 /**
  * _dpu_core_perf_calc_bw() - to calculate BW per crtc
  * @kms:  pointer to the dpu_kms
@@ -229,18 +215,16 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
if (!kms->num_paths)
return 0;
 
-   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
-   avg_bw = 0;
-   peak_bw = 0;
-   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
+   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
+
+   avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
+   peak_bw = perf.max_per_pipe_ib;
+
+   if (kms->perf.fix_core_ab_vote)
avg_bw = kms->perf.fix_core_ab_vote;
-   peak_bw = kms->perf.fix_core_ib_vote;
-   } else {
-   dpu_core_perf_aggregate(crtc->dev, 
dpu_crtc_get_client_type(crtc), &perf);
 
-   avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
-   peak_bw = perf.max_per_pipe_ib;
-   }
+   if (kms->perf.fix_core_ib_vote)
+   peak_bw = kms->perf.fix_core_ib_vote;
 
avg_bw /= kms->num_paths;
 
@@ -294,12 +278,9 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
struct drm_crtc *crtc;
struct dpu_crtc_state *dpu_cstate;
 
-   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED)
+   if (kms->perf.fix_core_clk_rate)
return kms->perf.fix_core_clk_rate;
 
-   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM)
-   return kms->perf.max_core_clk_rate;
-
drm_for_each_crtc(crtc, kms->dev) {
if (crtc->enabled) {
dpu_cstate = to_dpu_crtc_state(crtc->state);
@@ -416,54 +397,6 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
 #ifdef CONFIG_DEBUG_FS
 
-static ssize_t _dpu_core_perf_mode_write(struct file *file,
-   const char __user *user_buf, size_t count, loff_t *ppos)
-{
-   struct dpu_core_perf *perf = file->private_data;
-   u32 perf_mode = 0;
-   int ret;
-
-   ret = kstrtouint_from_user(user_buf, count, 0, &perf_mode);
-   if (ret)
-   return ret;
-
-   if (perf_mode >= DPU_PERF_MODE_MAX)
-   return -EINVAL;
-
-   if (perf_mode == DPU_PERF_MODE_FIXED) {
-   DRM_INFO("fix performance mode\n");
-   } else if (perf_mode == DPU_PERF_MODE_MINIMUM) {
-   /* run the driver with max clk and BW vote */
-   DRM_INFO("minimum performance mode\n");
-   } else if (perf_mode == DPU_PERF_MODE_NORMAL) {
-   /* reset the perf tune params to 0 */
-   DRM_INFO("normal performance mode\n");
-   }
-   perf->perf_tune.mode = perf_mode;
-
-   return count;
-}
-
-static ssize_t _dpu_core_perf_mode_read(struct file *file,
-   char __user *buff, size_t count, loff_t *ppos)
-{
-   struct dpu_core_perf *perf = file->private_data;
-   int len;
-   char buf[128];
-
-   len = scnprintf(buf, sizeof(buf),
-   "mode %d\n",
-   perf->perf_tune.mode);
-
-   return simple_read_from_buffer(buff, count, ppos, buf, len);
-}
-
-static const struct file_operations dpu_core_perf_mode_fops = {
-   .open = simple_open,
-   .read = _dpu_core_perf_mode_read,
-   .write = _dpu_core_perf_mode_write,
-};
-
 int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
 {
struct dpu_core_perf *perf = &dpu_kms->perf;
@@ -488,8 +421,6 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, 
struct dentry *parent)
(u32 *)&catalog->perf->min_llcc_ib);
debugfs_create_u32("min_dram_ib", 0600, entry,
   

[PATCH v2 02/14] drm/msm/dpu: core_perf: extract bandwidth aggregation function

[Dmitry Baryshkov]

In preparation to refactoring the dpu_core_perf debugfs interface,
extract the bandwidth aggregation function from
_dpu_core_perf_crtc_update_bus().

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 39 +++
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 1d9d83d7b99e..333dcfe57800 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -206,33 +206,38 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
-static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
-   struct drm_crtc *crtc)
+static void dpu_core_perf_aggregate(struct drm_device *ddev,
+   enum dpu_crtc_client_type curr_client_type,
+   struct dpu_core_perf_params *perf)
 {
-   struct dpu_core_perf_params perf = { 0 };
-   enum dpu_crtc_client_type curr_client_type
-   = dpu_crtc_get_client_type(crtc);
-   struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
-   int i, ret = 0;
-   u64 avg_bw;
+   struct drm_crtc *tmp_crtc;
 
-   drm_for_each_crtc(tmp_crtc, crtc->dev) {
+   drm_for_each_crtc(tmp_crtc, ddev) {
if (tmp_crtc->enabled &&
-   curr_client_type ==
-   dpu_crtc_get_client_type(tmp_crtc)) {
+   curr_client_type == dpu_crtc_get_client_type(tmp_crtc)) {
dpu_cstate = to_dpu_crtc_state(tmp_crtc->state);
 
-   perf.max_per_pipe_ib = max(perf.max_per_pipe_ib,
-   dpu_cstate->new_perf.max_per_pipe_ib);
+   perf->max_per_pipe_ib = max(perf->max_per_pipe_ib,
+   
dpu_cstate->new_perf.max_per_pipe_ib);
 
-   perf.bw_ctl += dpu_cstate->new_perf.bw_ctl;
+   perf->bw_ctl += dpu_cstate->new_perf.bw_ctl;
 
-   DRM_DEBUG_ATOMIC("crtc=%d bw=%llu paths:%d\n",
- tmp_crtc->base.id,
- dpu_cstate->new_perf.bw_ctl, kms->num_paths);
+   DRM_DEBUG_ATOMIC("crtc=%d bw=%llu\n",
+tmp_crtc->base.id,
+dpu_cstate->new_perf.bw_ctl);
}
}
+}
+
+static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
+   struct drm_crtc *crtc)
+{
+   struct dpu_core_perf_params perf = { 0 };
+   int i, ret = 0;
+   u64 avg_bw;
+
+   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
 
if (!kms->num_paths)
return 0;
-- 
2.39.2

[PATCH v2 05/14] drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()

[Dmitry Baryshkov]

Move perf mode handling for the bandwidth to
_dpu_core_perf_crtc_update_bus() rather than overriding per-CRTC data
and then aggregating known values.

Note, this changes the fix_core_ab_vote. Previously it would be
multiplied per the CRTC number, now it will be used directly for
interconnect voting.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 +--
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 348550ac7e51..42c03a5f1f3e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -116,21 +116,9 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
return;
}
 
-   memset(perf, 0, sizeof(struct dpu_core_perf_params));
-
-   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
-   perf->bw_ctl = 0;
-   perf->max_per_pipe_ib = 0;
-   perf->core_clk_rate = 0;
-   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
-   perf->bw_ctl = kms->perf.fix_core_ab_vote;
-   perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
-   perf->core_clk_rate = kms->perf.fix_core_clk_rate;
-   } else {
-   perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
-   perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
-   perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
-   }
+   perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
+   perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
+   perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
 
DRM_DEBUG_ATOMIC(
"crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
@@ -236,17 +224,28 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
struct dpu_core_perf_params perf = { 0 };
int i, ret = 0;
u32 avg_bw;
+   u32 peak_bw;
 
if (!kms->num_paths)
return 0;
 
-   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
+   if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
+   avg_bw = 0;
+   peak_bw = 0;
+   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
+   avg_bw = kms->perf.fix_core_ab_vote;
+   peak_bw = kms->perf.fix_core_ib_vote;
+   } else {
+   dpu_core_perf_aggregate(crtc->dev, 
dpu_crtc_get_client_type(crtc), &perf);
+
+   avg_bw = div_u64(perf.bw_ctl, 1000); /*Bps_to_icc*/
+   peak_bw = perf.max_per_pipe_ib;
+   }
 
-   avg_bw = perf.bw_ctl;
-   do_div(avg_bw, (kms->num_paths * 1000)); /*Bps_to_icc*/
+   avg_bw /= kms->num_paths;
 
for (i = 0; i < kms->num_paths; i++)
-   icc_set_bw(kms->path[i], avg_bw, perf.max_per_pipe_ib);
+   icc_set_bw(kms->path[i], avg_bw, peak_bw);
 
return ret;
 }
-- 
2.39.2

[PATCH v2 03/14] drm/msm/dpu: core_perf: bail earlier if there are no ICC paths

[Dmitry Baryshkov]

Skip bandwidth aggregation and return early if there are no interconnect
paths defined for the DPU device.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 333dcfe57800..05d340aa18c5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -237,11 +237,11 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
int i, ret = 0;
u64 avg_bw;
 
-   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
-
if (!kms->num_paths)
return 0;
 
+   dpu_core_perf_aggregate(crtc->dev, dpu_crtc_get_client_type(crtc), 
&perf);
+
avg_bw = perf.bw_ctl;
do_div(avg_bw, (kms->num_paths * 1000)); /*Bps_to_icc*/
 
-- 
2.39.2

[PATCH v2 01/14] drm/msm/dpu: drop enum dpu_core_perf_data_bus_id

[Dmitry Baryshkov]

Drop the leftover of bus-client -> interconnect conversion, the enum
dpu_core_perf_data_bus_id.

Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus 
scaling")
Reviewed-by: Konrad Dybcio 
Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index e3795995e145..29bb8ee2bc26 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -14,19 +14,6 @@
 
 #defineDPU_PERF_DEFAULT_MAX_CORE_CLK_RATE  41250
 
-/**
- * enum dpu_core_perf_data_bus_id - data bus identifier
- * @DPU_CORE_PERF_DATA_BUS_ID_MNOC: DPU/MNOC data bus
- * @DPU_CORE_PERF_DATA_BUS_ID_LLCC: MNOC/LLCC data bus
- * @DPU_CORE_PERF_DATA_BUS_ID_EBI: LLCC/EBI data bus
- */
-enum dpu_core_perf_data_bus_id {
-   DPU_CORE_PERF_DATA_BUS_ID_MNOC,
-   DPU_CORE_PERF_DATA_BUS_ID_LLCC,
-   DPU_CORE_PERF_DATA_BUS_ID_EBI,
-   DPU_CORE_PERF_DATA_BUS_ID_MAX,
-};
-
 /**
  * struct dpu_core_perf_params - definition of performance parameters
  * @max_per_pipe_ib: maximum instantaneous bandwidth request
-- 
2.39.2

[PATCH v2 00/14] drm/msm/dpu: cleanup dpu_core_perf module

[Dmitry Baryshkov]

Apply several cleanups to the DPU's core_perf module.

Changes since v1:
- Reworked overrides for the perf parameters instead of completely
  dropping them. Abhinav described why these overrides are useful.
- Moved max clock rate determination to dpu_kms.c

Dmitry Baryshkov (14):
  drm/msm/dpu: drop enum dpu_core_perf_data_bus_id
  drm/msm/dpu: core_perf: extract bandwidth aggregation function
  drm/msm/dpu: core_perf: bail earlier if there are no ICC paths
  drm/msm/dpu: drop separate dpu_core_perf_tune overrides
  drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()
  drm/msm/dpu: rework core_perf debugfs overrides
  drm/msm/dpu: drop dpu_core_perf_params::max_per_pipe_ib
  drm/msm/dpu: rework indentation in dpu_core_perf
  drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req param
  drm/msm/dpu: use dpu_perf_cfg in DPU core_perf code
  drm/msm/dpu: remove unused fields from struct dpu_core_perf
  drm/msm/dpu: core_perf: remove extra clk_round_rate() call
  drm/msm/dpu: move max clock decision to dpu_kms.
  drm/msm/dpu: drop dpu_core_perf_destroy()

 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 265 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  60 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  14 +-
 4 files changed, 96 insertions(+), 251 deletions(-)

-- 
2.39.2

Re: [PATCH] backlight: led_bl: fix initial power state

[Daniel Thompson]

On Tue, Jul 04, 2023 at 03:07:50PM +0100, Mans Rullgard wrote:
> The condition for the initial power state based on the default
> brightness value is reversed.  Fix it.
>
> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
> Signed-off-by: Mans Rullgard 
> ---
>  drivers/video/backlight/led_bl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/led_bl.c 
> b/drivers/video/backlight/led_bl.c
> index 3259292fda76..28e83618a296 100644
> --- a/drivers/video/backlight/led_bl.c
> +++ b/drivers/video/backlight/led_bl.c
> @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
>   props.type = BACKLIGHT_RAW;
>   props.max_brightness = priv->max_brightness;
>   props.brightness = priv->default_brightness;
> - props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
> -   FB_BLANK_UNBLANK;
> + props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
> +   FB_BLANK_POWERDOWN;

The logic was wrong before but I think will still be wrong after the
change too (e.g. the bogus logic is probably avoiding backlight flicker
in some use cases).

The logic here needs to be similar to what pwm_bl.c implements in
pwm_backlight_initial_power_state(). Whilst it might be better
to implement this in led_bl_get_leds() let me show what I mean
in code that fits in the current line:

/*
 * Activate the backlight if the LEDs are already lit *or*
 * there is no phandle link (meaning the backlight power
 * state cannot be synced with the display state).
 */
props.power = (active_at_boot || !dev->node->phandle) ?
FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;

Note that active_at_boot is not the same as (priv->default_brightness > 0)
since the value read by led_bl_get_leds() can be clobbered when we
parse the properties.


Daniel.

Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP

[Jani Nikula]

On Fri, 23 Jun 2023, Jocelyn Falempe  wrote:
> Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
>  EDID on DP")
> The default resolution is now 640x480 when no monitor is connected.
> But Aspeed graphics is mostly used in servers, where no monitor
> is attached. This also affects the "remote" resolution to 640x480, which is
> inconvenient, and breaks the anaconda installer.
> So when no EDID is present, set 1024x768 as preferred resolution.

This conflates "monitor connected" and "EDID present", which are not
necessarily the same thing.

The fallback in drm_helper_probe_single_connector_modes() is for no
modes, but connector status is connected or unknown.

You could add a connector ->detect callback that returns disconnected
when there's no display, and the problem should go away. If there's no
->detect callback, it'll default to connected.

> Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP")
> Signed-off-by: Jocelyn Falempe 
> ---
>  drivers/gpu/drm/ast/ast_mode.c | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 36374828f6c8..8f7b7cc021c7 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -1589,9 +1589,31 @@ static const struct drm_connector_helper_funcs 
> ast_dp501_connector_helper_funcs
>   .get_modes = ast_dp501_connector_helper_get_modes,
>  };
>  
> +static int ast_dp_probe_single_connector_modes(struct drm_connector 
> *connector,
> +uint32_t maxX, uint32_t maxY)
> +{
> + int ret;
> + struct drm_display_mode *mode;
> +
> + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> + /*
> +  * When no monitor are detected, DP now default to 640x480
> +  * As aspeed is mostly used in remote server, and DP monitors are
> +  * rarely attached, it's better to default to 1024x768
> +  */
> + if (!connector->edid_blob_ptr) {

Please try not to use connector->edid_blob_ptr for anything in
drivers. The logic is complicated enough as it is, with the firmware and
override EDIDs and everything, and makes future refactoring of EDID
handling harder.


BR,
Jani.

> + list_for_each_entry(mode, &connector->modes, head) {
> + if (mode->hdisplay == 1024 && mode->vdisplay == 768)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> + drm_mode_sort(&connector->modes);
> + }
> + }
> + return ret;
> +}
> +
>  static const struct drm_connector_funcs ast_dp501_connector_funcs = {
>   .reset = drm_atomic_helper_connector_reset,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = ast_dp_probe_single_connector_modes,
>   .destroy = drm_connector_cleanup,
>   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> @@ -1678,7 +1700,7 @@ static const struct drm_connector_helper_funcs 
> ast_astdp_connector_helper_funcs
>  
>  static const struct drm_connector_funcs ast_astdp_connector_funcs = {
>   .reset = drm_atomic_helper_connector_reset,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = ast_dp_probe_single_connector_modes,
>   .destroy = drm_connector_cleanup,
>   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>
> base-commit: 0adec22702d497385dbdc52abb165f379a00efba

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

[Christian König]

Am 04.07.23 um 16:31 schrieb Arnd Bergmann:

On Tue, Jul 4, 2023, at 14:33, Christian König wrote:

Am 04.07.23 um 14:24 schrieb Arnd Bergmann:

On Tue, Jul 4, 2023, at 08:54, Christian König wrote:

Am 03.07.23 um 14:35 schrieb Arnd Bergmann:

Not sure I understand the specific requirement. Do you mean the entire
amdgpu driver requires 64-bit BAR addressing, or just the bits that
resize the BARs?

Well a bit of both.

Modern AMD GPUs have 16GiB of local memory (VRAM), making those
accessible to a CPU which can only handle 32bit addresses by resizing
the BAR is impossible to begin with.

But going a step further even without resizing it is pretty hard to get
that hardware working on such an architecture.

I'd still like to understand this part better, as we have a lot of
arm64 chips with somewhat flawed PCIe implementations, often with
a tiny 64-bit memory space, but otherwise probably capable of
using a GPU.


Yeah, those are unfortunately very well known to us :(


What exactly do you expect to happen here?

a) Use only part of the VRAM but otherwise work as expected
b) Access all of the VRAM, but at a performance cost for
bank switching?


We have tons of x86 systems where we can't resize the BAR (because of 
lack of BIOS setup of the root PCIe windows). So bank switching is still 
perfectly supported.



c) Require kernel changes to make a) or b) work, otherwise
fail to load
d) have no chance of working even with driver changes


Yeah, that is usually what happens on those arm64 system with flawed 
PCIe implementations.


The problem is not even BAR resize, basically we already had tons of 
customers which came to us and complained that amdgpu doesn't load or 
crashes the system after a few seconds.


After investigating (which sometimes even includes involving engineers 
from ARM) we usually find that those boards doesn't even remotely comply 
to the PCIe specification, both regarding power as well as functional 
things like DMA coherency.


Regards,
Christian.




It might be cleaner to just not build the whole driver on such systems
or at least leave out this function.

How about this version? This also addresses the build failure, but
I don't know if this makes any sense:

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device 
*adev)
  u16 cmd;
  int r;
   
+   if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))

+   return 0;
+

Yes, if that suppresses the warning as well then that makes perfect
sense to me.

Ok, I'll send that as a v2 then.

 Arnd

Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

[Arnd Bergmann]

On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
> Am 04.07.23 um 14:24 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 08:54, Christian König wrote:
>>> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> Not sure I understand the specific requirement. Do you mean the entire
>> amdgpu driver requires 64-bit BAR addressing, or just the bits that
>> resize the BARs?
>
> Well a bit of both.
>
> Modern AMD GPUs have 16GiB of local memory (VRAM), making those 
> accessible to a CPU which can only handle 32bit addresses by resizing 
> the BAR is impossible to begin with.
>
> But going a step further even without resizing it is pretty hard to get 
> that hardware working on such an architecture.

I'd still like to understand this part better, as we have a lot of
arm64 chips with somewhat flawed PCIe implementations, often with
a tiny 64-bit memory space, but otherwise probably capable of
using a GPU.

What exactly do you expect to happen here?

a) Use only part of the VRAM but otherwise work as expected
b) Access all of the VRAM, but at a performance cost for
   bank switching?
c) Require kernel changes to make a) or b) work, otherwise
   fail to load
d) have no chance of working even with driver changes

>>> It might be cleaner to just not build the whole driver on such systems
>>> or at least leave out this function.
>> How about this version? This also addresses the build failure, but
>> I don't know if this makes any sense:
>>
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device 
>> *adev)
>>  u16 cmd;
>>  int r;
>>   
>> +   if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
>> +   return 0;
>> +
>
> Yes, if that suppresses the warning as well then that makes perfect 
> sense to me.

Ok, I'll send that as a v2 then.

Arnd

Re: [PATCH 7/8] drm/msm/dpu: drop dpu_core_perf_destroy()

[Dmitry Baryshkov]

On Tue, 4 Jul 2023 at 03:19, Abhinav Kumar  wrote:
>
>
>
> On 7/3/2023 3:59 PM, Dmitry Baryshkov wrote:
> > On Tue, 4 Jul 2023 at 01:57, Abhinav Kumar  
> > wrote:
> >>
> >>
> >>
> >> On 6/19/2023 5:08 PM, Dmitry Baryshkov wrote:
> >>> This function does nothing, just clears several data pointers. Drop it
> >>> now.
> >>>
> >>
> >> This will undo what dpu_core_perf_init() did when an error happens.
> >>
> >> Why can we drop that?
> >
> > Because nothing will use this data in an error case. There is no need
> > to clean it.
> >
>
> Usage is one thing for sure but I am still inclined to keep it symmetric
> with dpu_core_perf_init().

Through the last several years the kernel was more and more inclined
to asymmetry here. For example, consider all the demv_ functions. We
have been removing cleanup and _remove functions all over the place.
So, I think, I will reiterate this patch.

>
> >>
> >>> Signed-off-by: Dmitry Baryshkov 
> >>> ---
> >>>drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 
> >>>drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  6 --
> >>>drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  1 -
> >>>3 files changed, 19 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> >>> index 78a7e3ea27a4..f779ad544347 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> >>> @@ -394,18 +394,6 @@ int dpu_core_perf_debugfs_init(struct dpu_kms 
> >>> *dpu_kms, struct dentry *parent)
> >>>}
> >>>#endif
> >>>
> >>> -void dpu_core_perf_destroy(struct dpu_core_perf *perf)
> >>> -{
> >>> - if (!perf) {
> >>> - DPU_ERROR("invalid parameters\n");
> >>> - return;
> >>> - }
> >>> -
> >>> - perf->max_core_clk_rate = 0;
> >>> - perf->core_clk = NULL;
> >>> - perf->dev = NULL;
> >>> -}
> >>> -
> >>>int dpu_core_perf_init(struct dpu_core_perf *perf,
> >>>struct drm_device *dev,
> >>>const struct dpu_perf_cfg *perf_cfg,
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
> >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> >>> index e8a7916b6f71..e1198c104b5e 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> >>> @@ -69,12 +69,6 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
> >>> */
> >>>void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc);
> >>>
> >>> -/**
> >>> - * dpu_core_perf_destroy - destroy the given core performance context
> >>> - * @perf: Pointer to core performance context
> >>> - */
> >>> -void dpu_core_perf_destroy(struct dpu_core_perf *perf);
> >>> -
> >>>/**
> >>> * dpu_core_perf_init - initialize the given core performance context
> >>> * @perf: Pointer to core performance context
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >>> index 6e62606e32de..4439147d2c35 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >>> @@ -1162,7 +1162,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> >>>return 0;
> >>>
> >>>drm_obj_init_err:
> >>> - dpu_core_perf_destroy(&dpu_kms->perf);
> >>>hw_intr_init_err:
> >>>perf_err:
> >>>power_error:
> >
> >
> >



-- 
With best wishes
Dmitry

Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP

[Thomas Zimmermann]

(cc: some people from commit fae7d186403e)

Am 04.07.23 um 16:19 schrieb Thomas Zimmermann:

Hi Jocelyn

Am 23.06.23 um 11:46 schrieb Jocelyn Falempe:

Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
  EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480, 
which is

inconvenient, and breaks the anaconda installer.


By "remote resolution", you mean the display mode that the BMC uses?


So when no EDID is present, set 1024x768 as preferred resolution.

Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID 
on DP")


This commit says that 640x480 is the designated failsafe mode if no EDID 
is available. Therefore, I think we should not override it 
unconditionally. The ast driver is no special in that case.


But I see why you're doing this change. I think any solution should be 
implemented in drm_helper_probe_single_connector_modes().


But before we solve this in the kernel, is it possible to delegate this 
to userspace? If no EDID has been given, userspace could try a 
non-failsafe display mode.


Best regards
Thomas


Signed-off-by: Jocelyn Falempe 
---
  drivers/gpu/drm/ast/ast_mode.c | 26 --
  1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c 
b/drivers/gpu/drm/ast/ast_mode.c

index 36374828f6c8..8f7b7cc021c7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1589,9 +1589,31 @@ static const struct drm_connector_helper_funcs 
ast_dp501_connector_helper_funcs

  .get_modes = ast_dp501_connector_helper_get_modes,
  };
+static int ast_dp_probe_single_connector_modes(struct drm_connector 
*connector,

+   uint32_t maxX, uint32_t maxY)
+{
+    int ret;
+    struct drm_display_mode *mode;
+
+    ret = drm_helper_probe_single_connector_modes(connector, maxX, 
maxY);

+    /*
+ * When no monitor are detected, DP now default to 640x480
+ * As aspeed is mostly used in remote server, and DP monitors are
+ * rarely attached, it's better to default to 1024x768
+ */
+    if (!connector->edid_blob_ptr) {
+    list_for_each_entry(mode, &connector->modes, head) {
+    if (mode->hdisplay == 1024 && mode->vdisplay == 768)
+    mode->type |= DRM_MODE_TYPE_PREFERRED;
+    drm_mode_sort(&connector->modes);
+    }
+    }
+    return ret;
+}
+
  static const struct drm_connector_funcs ast_dp501_connector_funcs = {
  .reset = drm_atomic_helper_connector_reset,
-    .fill_modes = drm_helper_probe_single_connector_modes,
+    .fill_modes = ast_dp_probe_single_connector_modes,
  .destroy = drm_connector_cleanup,
  .atomic_duplicate_state = 
drm_atomic_helper_connector_duplicate_state,

  .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
@@ -1678,7 +1700,7 @@ static const struct drm_connector_helper_funcs 
ast_astdp_connector_helper_funcs

  static const struct drm_connector_funcs ast_astdp_connector_funcs = {
  .reset = drm_atomic_helper_connector_reset,
-    .fill_modes = drm_helper_probe_single_connector_modes,
+    .fill_modes = ast_dp_probe_single_connector_modes,
  .destroy = drm_connector_cleanup,
  .atomic_duplicate_state = 
drm_atomic_helper_connector_duplicate_state,

  .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,

base-commit: 0adec22702d497385dbdc52abb165f379a00efba




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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP

[Thomas Zimmermann]

Hi Jocelyn

Am 23.06.23 um 11:46 schrieb Jocelyn Falempe:

Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
  EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480, which is
inconvenient, and breaks the anaconda installer.


By "remote resolution", you mean the display mode that the BMC uses?


So when no EDID is present, set 1024x768 as preferred resolution.

Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP")


This commit says that 640x480 is the designated failsafe mode if no EDID 
is available. Therefore, I think we should not override it 
unconditionally. The ast driver is no special in that case.


But I see why you're doing this change. I think any solution should be 
implemented in drm_helper_probe_single_connector_modes().


But before we solve this in the kernel, is it possible to delegate this 
to userspace? If no EDID has been given, userspace could try a 
non-failsafe display mode.


Best regards
Thomas


Signed-off-by: Jocelyn Falempe 
---
  drivers/gpu/drm/ast/ast_mode.c | 26 --
  1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 36374828f6c8..8f7b7cc021c7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1589,9 +1589,31 @@ static const struct drm_connector_helper_funcs 
ast_dp501_connector_helper_funcs
.get_modes = ast_dp501_connector_helper_get_modes,
  };
  
+static int ast_dp_probe_single_connector_modes(struct drm_connector *connector,

+  uint32_t maxX, uint32_t maxY)
+{
+   int ret;
+   struct drm_display_mode *mode;
+
+   ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
+   /*
+* When no monitor are detected, DP now default to 640x480
+* As aspeed is mostly used in remote server, and DP monitors are
+* rarely attached, it's better to default to 1024x768
+*/
+   if (!connector->edid_blob_ptr) {
+   list_for_each_entry(mode, &connector->modes, head) {
+   if (mode->hdisplay == 1024 && mode->vdisplay == 768)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+   drm_mode_sort(&connector->modes);
+   }
+   }
+   return ret;
+}
+
  static const struct drm_connector_funcs ast_dp501_connector_funcs = {
.reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = ast_dp_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
@@ -1678,7 +1700,7 @@ static const struct drm_connector_helper_funcs 
ast_astdp_connector_helper_funcs
  
  static const struct drm_connector_funcs ast_astdp_connector_funcs = {

.reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = ast_dp_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,

base-commit: 0adec22702d497385dbdc52abb165f379a00efba


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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm/arm/komeda: Remove component framework and add a simple encoder

[Mohammad Faiz Abbas Rizvi]

Hi Liviu,

On 6/29/2023 3:21 PM, Liviu Dudau wrote:
> Hi Faiz,
>
> Thanks for the patch and for addressing what was at some moment on my "nice to
> improve / cleanup" list. Sorry for the delay in responding, I had to revive
> the bits of an old setup to be able to test this properly, with 2 encoders
> attached.
>
> On Wed, Jun 21, 2023 at 02:11:16PM +0530, Faiz Abbas wrote:
>> The Komeda driver always expects the remote connector node to initialize
>> an encoder. It uses the component aggregator framework which consists
>> of component->bind() calls used to initialize the remote encoder and attach
>> it to the crtc. This is different from other drm implementations which expect
>> the display driver to supply a crtc and connect an encoder to it.
> I think both approaches are valid in DRM. We don't want to remove the 
> component
> framework because it is doing the wrong thing, but because we cannot use it
> with drivers that implement the drm_bridge API. Given that we usually pair 
> with
> a component encoder that also implements a drm_bridge, dropping support for
> component framework should not affect the users of the driver.

Sounds good. I will update the commit message to emphasize the bridge API.

>> Remove all component framework calls from the komeda driver and declare and
>> attach an encoder inside komeda_crtc_add().
> Unfortunately you haven't removed all component framework calls. The hint for
> that is that you have not removed the #include  line from
> any of the files. Specifically, komeda_kms_attach()/detach() still calls
> component_unbind_all() which will crash with your patch applied.

Good catch. Will remove that stuff in v2.

>> The remote connector driver has to implement the DRM bridge APIs which
>> can be used to glue the encoder to the remote connector.
>>
>> Signed-off-by: Faiz Abbas 
>> ---
>>  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 22 +++-
>>  .../gpu/drm/arm/display/komeda/komeda_drv.c   | 56 ++-
>>  .../gpu/drm/arm/display/komeda/komeda_kms.c   |  4 --
>>  .../gpu/drm/arm/display/komeda/komeda_kms.h   |  3 +
>>  4 files changed, 30 insertions(+), 55 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
>> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
>> index cea3fd5772b57..144736a69b0ee 100644
>> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
>> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
>> @@ -12,6 +12,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  
>>  #include "komeda_dev.h"
>>  #include "komeda_kms.h"
>> @@ -612,9 +614,11 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>> struct komeda_crtc *kcrtc)
>>  {
>>  struct drm_crtc *crtc = &kcrtc->base;
>> +struct drm_device *base = &kms->base;
>> +struct drm_bridge *bridge;
>>  int err;
>>  
>> -err = drm_crtc_init_with_planes(&kms->base, crtc,
>> +err = drm_crtc_init_with_planes(base, crtc,
>>  get_crtc_primary(kms, kcrtc), NULL,
>>  &komeda_crtc_funcs, NULL);
>>  if (err)
>> @@ -626,6 +630,22 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>>  
>>  drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
> I would move this line after the bridges are being initialised, just in case 
> in the future
> colour management will propagate some info down to the bridges.

Sure. I'll move it down.

.

.

.

>>  };
>>  
>>  /**
>> -- 
>> 2.25.1
>>
> Code looks good and turns out swapping drm_bridge for component framework is 
> not that painful. If you send v2
> with the comments addressed I should be able to test it now and review the 
> patch much sooner.
>
> One issue I have observed from my testing of your patch is that on `rmmod 
> komeda` we fail to disable the
> interrupts after drm_kms_helper_poll_fini() call in komeda_kms_detach(), then 
> we NULL the drm->dev_private
> before we get an interrupt which causes komeda_kms_irq_handler() to access 
> the NULL pointer. This is not
> something caused by your patch, but if you want to test module removal I 
> think you should be aware of this.

I'll keep this in mind while testing.

Thanks,
Faiz

Re: [PATCH] dt-bindings: cleanup DTS example whitespaces

[Dmitry Baryshkov]

On Sun, 2 Jul 2023 at 21:23, Krzysztof Kozlowski
 wrote:
>
> The DTS code coding style expects spaces around '=' sign.
>
> Signed-off-by: Krzysztof Kozlowski 
>
> ---
>
> Rob,
>
> Maybe this could go via your tree? Rebased on your for-next:
> v6.4-rc2-45-gf0ac35049606
> ---
>  .../bindings/arm/arm,coresight-cti.yaml| 18 +-
>  .../bindings/arm/keystone/ti,sci.yaml  |  8 
>  .../devicetree/bindings/display/msm/gmu.yaml   |  2 +-

Acked-by: Dmitry Baryshkov  #display/msm

>  .../display/panel/samsung,s6e8aa0.yaml |  2 +-
>  .../display/rockchip/rockchip-vop.yaml |  4 ++--
>  .../bindings/iio/adc/ti,adc108s102.yaml|  2 +-
>  .../bindings/media/renesas,rzg2l-cru.yaml  |  4 ++--
>  .../devicetree/bindings/media/renesas,vin.yaml |  4 ++--
>  .../devicetree/bindings/mtd/mtd-physmap.yaml   |  2 +-
>  .../bindings/net/mediatek-dwmac.yaml   |  2 +-
>  .../bindings/perf/amlogic,g12-ddr-pmu.yaml |  4 ++--
>  .../bindings/phy/mediatek,dsi-phy.yaml |  2 +-
>  .../remoteproc/amlogic,meson-mx-ao-arc.yaml|  2 +-
>  .../devicetree/bindings/usb/mediatek,mtu3.yaml |  2 +-
>  .../devicetree/bindings/usb/ti,am62-usb.yaml   |  2 +-
>  15 files changed, 30 insertions(+), 30 deletions(-)


-- 
With best wishes
Dmitry

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[Andrew Lunn]

> > What is the purpose of this stage? Why would it not be supported for this
> > device?
> This is needed for wbrf support via ACPI mechanism. If BIOS(AML code) does 
> not support the wbrf adding/removing for some device,
> it should speak that out so that the device can be aware of that.

How much overhead is this adding? How deep do you need to go to find
the BIOS does not support it? And how often is this called?

Where do we want to add complexity? In the generic API? Or maybe a
little deeper in the ACPI specific code?

   Andrew

Re: [PATCH] dt-bindings: cleanup DTS example whitespaces

[Matthias Brugger]

On 02/07/2023 20:23, Krzysztof Kozlowski wrote:

The DTS code coding style expects spaces around '=' sign.

Signed-off-by: Krzysztof Kozlowski 

---

Rob,

Maybe this could go via your tree? Rebased on your for-next:
v6.4-rc2-45-gf0ac35049606
---

[...]

  .../bindings/net/mediatek-dwmac.yaml   |  2 +-

[...]

  .../bindings/phy/mediatek,dsi-phy.yaml |  2 +-

[...]

  .../devicetree/bindings/usb/mediatek,mtu3.yaml |  2 +-
  .../devicetree/bindings/usb/ti,am62-usb.yaml   |  2 +-


For MediaTek parts:
Reviewed-by: Matthias Brugger 


  15 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml 
b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
index 0c5b875cb654..d6c84b6e7fe6 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
@@ -287,7 +287,7 @@ examples:
  arm,trig-in-sigs = <0 1>;
  arm,trig-in-types = ;
-arm,trig-out-sigs=<0 1 2 >;
+arm,trig-out-sigs = <0 1 2 >;
  arm,trig-out-types = ;
@@ -309,24 +309,24 @@ examples:
  
trig-conns@0 {

  reg = <0>;
-arm,trig-in-sigs=<0>;
-arm,trig-in-types=;
-arm,trig-out-sigs=<0>;
-arm,trig-out-types=;
+arm,trig-in-sigs = <0>;
+arm,trig-in-types = ;
+arm,trig-out-sigs = <0>;
+arm,trig-out-types = ;
  arm,trig-conn-name = "sys_profiler";
};
  
trig-conns@1 {

  reg = <1>;
-arm,trig-out-sigs=<2 3>;
-arm,trig-out-types=;
+arm,trig-out-sigs = <2 3>;
+arm,trig-out-types = ;
  arm,trig-conn-name = "watchdog";
};
  
trig-conns@2 {

  reg = <2>;
-arm,trig-in-sigs=<1 6>;
-arm,trig-in-types=;
+arm,trig-in-sigs = <1 6>;
+arm,trig-in-types = ;
  arm,trig-conn-name = "g_counter";
};
  };
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml 
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
index 91b96065f7df..86b59de7707e 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -96,8 +96,8 @@ examples:
compatible = "ti,k2g-sci";
ti,system-reboot-controller;
mbox-names = "rx", "tx";
-  mboxes= <&msgmgr 5 2>,
-  <&msgmgr 0 0>;
+  mboxes = <&msgmgr 5 2>,
+   <&msgmgr 0 0>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
  };
@@ -107,8 +107,8 @@ examples:
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
-  mboxes= <&secure_proxy_main 11>,
-  <&secure_proxy_main 13>;
+  mboxes = <&secure_proxy_main 11>,
+   <&secure_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x44083000 0x1000>;
  
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml

index 029d72822d8b..65b02c7a1211 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
@@ -225,7 +225,7 @@ examples:
  #include 
  
  gmu: gmu@506a000 {

-compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+compatible = "qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
  
  reg = <0x506a000 0x3>,

<0xb28 0x1>,
diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
index 1cdc91b3439f..200fbf1c74a0 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
@@ -74,7 +74,7 @@ examples:
  vdd3-supply = <&vcclcd_reg>;
  vci-supply = <&vlcd_reg>;
  reset-gpios = <&gpy4 5 0>;
-power-on-delay= <50>;
+power-on-delay = <50>;
  reset-delay = <100>;
  init-delay = <100>;
  panel-width-mm = <58>;
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
index 6f43d885c9b3..df61cb5f5c54 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -121,11 +121,11 @@ examples:
  #size-cells = <0>;
  vopb_out_edp: endpoint@0 {
reg = <0>;
-  remote-endpoint=<&edp_in_vopb>;
+  remote-endpoint = <&edp_in_vopb>;
  };
  vopb_out_hdmi: endpoint@1 {
reg = <1>;
-  remote-endpoint=<&hdmi_in_vopb>;
+  remote-endpoint = <&hdmi_in_vopb>;
  };

Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

[Christian König]

Am 04.07.23 um 14:24 schrieb Arnd Bergmann:

On Tue, Jul 4, 2023, at 08:54, Christian König wrote:

Am 03.07.23 um 14:35 schrieb Arnd Bergmann:

From: Arnd Bergmann 

On 32-bit architectures comparing a resource against a value larger than
U32_MAX can cause a warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison 
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned 
int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
  res->start > 0x1ull)
  ~~ ^ ~~

The compiler is right that this cannot happen in this configuration, which
is ok, so just add a cast to shut up the warning.

Well it doesn't make sense to compile that driver on systems with only
32bit phys_addr_t in the first place.

Not sure I understand the specific requirement. Do you mean the entire
amdgpu driver requires 64-bit BAR addressing, or just the bits that
resize the BARs?


Well a bit of both.

Modern AMD GPUs have 16GiB of local memory (VRAM), making those 
accessible to a CPU which can only handle 32bit addresses by resizing 
the BAR is impossible to begin with.


But going a step further even without resizing it is pretty hard to get 
that hardware working on such an architecture.



It might be cleaner to just not build the whole driver on such systems
or at least leave out this function.

How about this version? This also addresses the build failure, but
I don't know if this makes any sense:

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device 
*adev)
 u16 cmd;
 int r;
  
+   if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))

+   return 0;
+


Yes, if that suppresses the warning as well then that makes perfect 
sense to me.


Regards,
Christian.


 /* Bypass for VF */
 if (amdgpu_sriov_vf(adev))
 return 0;

  Arnd

Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

[Arnd Bergmann]

On Tue, Jul 4, 2023, at 08:54, Christian König wrote:
> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> From: Arnd Bergmann 
>>
>> On 32-bit architectures comparing a resource against a value larger than
>> U32_MAX can cause a warning:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of 
>> comparison of constant 4294967296 with expression of type 'resource_size_t' 
>> (aka 'unsigned int') is always false 
>> [-Werror,-Wtautological-constant-out-of-range-compare]
>>  res->start > 0x1ull)
>>  ~~ ^ ~~
>>
>> The compiler is right that this cannot happen in this configuration, which
>> is ok, so just add a cast to shut up the warning.
>
> Well it doesn't make sense to compile that driver on systems with only 
> 32bit phys_addr_t in the first place.

Not sure I understand the specific requirement. Do you mean the entire
amdgpu driver requires 64-bit BAR addressing, or just the bits that
resize the BARs?

> It might be cleaner to just not build the whole driver on such systems 
> or at least leave out this function.

How about this version? This also addresses the build failure, but
I don't know if this makes any sense:

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device 
*adev)
u16 cmd;
int r;
 
+   if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
+   return 0;
+
/* Bypass for VF */
if (amdgpu_sriov_vf(adev))
return 0;

 Arnd