drm/panel/panel-simple v6.16-rc1 WARNING regression

drm/panel/panel-simple v6.16-rc1 WARNING regression

[Francesco Dolcini]

Hello all,

Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation in place of devm_kzalloc()")
from 6.16-rc1 introduced a regression with this warning during probe
with panel dpi described in the DT.

A revert solves the issue.

The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
panel_dpi_probe() that after that change is called after
devm_drm_panel_alloc().

I am not sure if there are other implication for this change in the call
ordering, apart the one that triggers this warning.


[   12.089274] ------------[ cut here ]------------
[   12.089303] WARNING: CPU: 0 PID: 96 at drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
[   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa gpu_sched panel_simple imx6_media(C) imx_media_common
(C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6 autofs4
[   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G         C          6.16.0-rc1+ #1 PREEMPT
[   12.157446] Tainted: [C]=CRAP
[   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   12.166953] Workqueue: events_unbound deferred_probe_work_func
[   12.172805] Call trace:
[   12.172815]  unwind_backtrace from show_stack+0x10/0x14
[   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
[   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
[   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
[   12.195567]  warn_slowpath_fmt from devm_drm_of_get_bridge+0xac/0xb8
[   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
[   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
[   12.213220]  platform_probe from really_probe+0xd0/0x3a4
[   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
[   12.224486]  __driver_probe_device from driver_probe_device+0x30/0xc0
[   12.230942]  driver_probe_device from __device_attach_driver+0x98/0x10c
[   12.237572]  __device_attach_driver from bus_for_each_drv+0x90/0xe4
[   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
[   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
[   12.255285]  bus_probe_device from deferred_probe_work_func+0x8c/0xcc
[   12.261739]  deferred_probe_work_func from process_one_work+0x154/0x2dc
[   12.268371]  process_one_work from worker_thread+0x250/0x3f0
[   12.274043]  worker_thread from kthread+0x12c/0x24c
[   12.278940]  kthread from ret_from_fork+0x14/0x28
[   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
[   12.288720] 9fa0:                                     00000000 00000000 00000000 00000000
[   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   12.312050] ---[ end trace 0000000000000000 ]---

#regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057

Any advise?

Francesco

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Anusha Srivatsa]

[-- Attachment #1: Type: text/plain, Size: 3988 bytes --]

On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <francesco@dolcini.it>
wrote:

> Hello all,
>
> Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation in
> place of devm_kzalloc()")
> from 6.16-rc1 introduced a regression with this warning during probe
> with panel dpi described in the DT.
>
> A revert solves the issue.
>
> The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
> panel_dpi_probe() that after that change is called after
> devm_drm_panel_alloc().
>
> I am not sure if there are other implication for this change in the call
> ordering, apart the one that triggers this warning.
>
> [   12.089274] ------------[ cut here ]------------
> [   12.089303] WARNING: CPU: 0 PID: 96 at
> drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
> [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
> gpu_sched panel_simple imx6_media(C) imx_media_common
> (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6 autofs4
> [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
>  C          6.16.0-rc1+ #1 PREEMPT
> [   12.157446] Tainted: [C]=CRAP
> [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [   12.166953] Workqueue: events_unbound deferred_probe_work_func
> [   12.172805] Call trace:
> [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> [   12.195567]  warn_slowpath_fmt from devm_drm_of_get_bridge+0xac/0xb8
> [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
> [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
> [   12.224486]  __driver_probe_device from driver_probe_device+0x30/0xc0
> [   12.230942]  driver_probe_device from __device_attach_driver+0x98/0x10c
> [   12.237572]  __device_attach_driver from bus_for_each_drv+0x90/0xe4
> [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> [   12.255285]  bus_probe_device from deferred_probe_work_func+0x8c/0xcc
> [   12.261739]  deferred_probe_work_func from process_one_work+0x154/0x2dc
> [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> [   12.274043]  worker_thread from kthread+0x12c/0x24c
> [   12.278940]  kthread from ret_from_fork+0x14/0x28
> [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> [   12.288720] 9fa0:                                     00000000 00000000
> 00000000 00000000
> [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [   12.312050] ---[ end trace 0000000000000000 ]---
>
> #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
>
> Any advise?
>
> Hey Francesco!

This mail reached my spam and I hadn't realised till today. Thanks for
bringing this to attention.

Thinking out loud here: If we called dpi_probe() before allocating the
panel using devm_drm_panel_alloc()
then we would have the connector type. But  dpi_probe() needs the panel to
be allocated....

We could actually hardcode the connector type to DRM_MODE_CONNECTOR_DPI....
Looking at panel_dpi_probe(), it guesses the connector_type:

/* We do not know the connector for the DT node, so guess it
*/	desc->connector_type
<https://elixir.bootlin.com/linux/v6.16-rc2/C/ident/connector_type> =
DRM_MODE_CONNECTOR_DPI
<https://elixir.bootlin.com/linux/v6.16-rc2/C/ident/DRM_MODE_CONNECTOR_DPI>;


Reverting will improve the end user experience but if the fix can be quick,
we can
avoid dropping the change

Thanks,
Anusha


> Francesco
>
>

[-- Attachment #2: Type: text/html, Size: 5449 bytes --]

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Francesco Dolcini]

Hello Anusha,

On Tue, Jun 17, 2025 at 11:17:20AM -0500, Anusha Srivatsa wrote:
> On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <francesco@dolcini.it>
> wrote:
> 
> > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation in
> > place of devm_kzalloc()")
> > from 6.16-rc1 introduced a regression with this warning during probe
> > with panel dpi described in the DT.
> >
> > A revert solves the issue.
> >
> > The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
> > panel_dpi_probe() that after that change is called after
> > devm_drm_panel_alloc().
> >
> > I am not sure if there are other implication for this change in the call
> > ordering, apart the one that triggers this warning.
> >
> > [   12.089274] ------------[ cut here ]------------
> > [   12.089303] WARNING: CPU: 0 PID: 96 at
> > drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
> > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
> > gpu_sched panel_simple imx6_media(C) imx_media_common
> > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6 autofs4
> > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
> >  C          6.16.0-rc1+ #1 PREEMPT
> > [   12.157446] Tainted: [C]=CRAP
> > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [   12.166953] Workqueue: events_unbound deferred_probe_work_func
> > [   12.172805] Call trace:
> > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> > [   12.195567]  warn_slowpath_fmt from devm_drm_of_get_bridge+0xac/0xb8
> > [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
> > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> > [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
> > [   12.224486]  __driver_probe_device from driver_probe_device+0x30/0xc0
> > [   12.230942]  driver_probe_device from __device_attach_driver+0x98/0x10c
> > [   12.237572]  __device_attach_driver from bus_for_each_drv+0x90/0xe4
> > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> > [   12.255285]  bus_probe_device from deferred_probe_work_func+0x8c/0xcc
> > [   12.261739]  deferred_probe_work_func from process_one_work+0x154/0x2dc
> > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> > [   12.274043]  worker_thread from kthread+0x12c/0x24c
> > [   12.278940]  kthread from ret_from_fork+0x14/0x28
> > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> > [   12.288720] 9fa0:                                     00000000 00000000
> > 00000000 00000000
> > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000
> > 00000000 00000000
> > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > [   12.312050] ---[ end trace 0000000000000000 ]---
> >
> > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
> >
> > Any advise?
> >
> > Hey Francesco!
> 
> This mail reached my spam and I hadn't realised till today. Thanks for
> bringing this to attention.
> 
> Thinking out loud here: If we called dpi_probe() before allocating the
> panel using devm_drm_panel_alloc()
> then we would have the connector type. But  dpi_probe() needs the panel to
> be allocated....
> 
> We could actually hardcode the connector type to DRM_MODE_CONNECTOR_DPI....
> Looking at panel_dpi_probe(), it guesses the connector_type:
> 
> /* We do not know the connector for the DT node, so guess it
> */	desc->connector_type
> <https://elixir.bootlin.com/linux/v6.16-rc2/C/ident/connector_type> =
> DRM_MODE_CONNECTOR_DPI
> <https://elixir.bootlin.com/linux/v6.16-rc2/C/ident/DRM_MODE_CONNECTOR_DPI>;
> 
> 
> Reverting will improve the end user experience but if the fix can be quick,
> we can avoid dropping the change

I do not have any specific suggestion myself, my short term solution would be
to just send a revert. If you have some other proposal I am happy to test any
patch.

Francesco

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Luca Ceresoli]

Hello Anusha, Francesco,

On Tue, 17 Jun 2025 11:17:20 -0500
Anusha Srivatsa <asrivats@redhat.com> wrote:

> On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <francesco@dolcini.it>
> wrote:
> 
> > Hello all,
> >
> > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation in
> > place of devm_kzalloc()")
> > from 6.16-rc1 introduced a regression with this warning during probe
> > with panel dpi described in the DT.
> >
> > A revert solves the issue.
> >
> > The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
> > panel_dpi_probe() that after that change is called after
> > devm_drm_panel_alloc().
> >
> > I am not sure if there are other implication for this change in the call
> > ordering, apart the one that triggers this warning.
> >
> > [   12.089274] ------------[ cut here ]------------
> > [   12.089303] WARNING: CPU: 0 PID: 96 at
> > drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
> > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
> > gpu_sched panel_simple imx6_media(C) imx_media_common
> > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6 autofs4
> > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
> >  C          6.16.0-rc1+ #1 PREEMPT
> > [   12.157446] Tainted: [C]=CRAP
> > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [   12.166953] Workqueue: events_unbound deferred_probe_work_func
> > [   12.172805] Call trace:
> > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> > [   12.195567]  warn_slowpath_fmt from devm_drm_of_get_bridge+0xac/0xb8
> > [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
> > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> > [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
> > [   12.224486]  __driver_probe_device from driver_probe_device+0x30/0xc0
> > [   12.230942]  driver_probe_device from __device_attach_driver+0x98/0x10c
> > [   12.237572]  __device_attach_driver from bus_for_each_drv+0x90/0xe4
> > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> > [   12.255285]  bus_probe_device from deferred_probe_work_func+0x8c/0xcc
> > [   12.261739]  deferred_probe_work_func from process_one_work+0x154/0x2dc
> > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> > [   12.274043]  worker_thread from kthread+0x12c/0x24c
> > [   12.278940]  kthread from ret_from_fork+0x14/0x28
> > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> > [   12.288720] 9fa0:                                     00000000 00000000
> > 00000000 00000000
> > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000
> > 00000000 00000000
> > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > [   12.312050] ---[ end trace 0000000000000000 ]---
> >
> > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
> >
> > Any advise?
> >
> > Hey Francesco!  
> 
> This mail reached my spam and I hadn't realised till today. Thanks for
> bringing this to attention.
>
> Thinking out loud here: If we called dpi_probe() before allocating the
> panel using devm_drm_panel_alloc()
> then we would have the connector type. But  dpi_probe() needs the panel to
> be allocated....

Reading the panel-simple.c code, the handling of the panel_dsi
descriptor feels a bit hacky, and the recent change to
devm_drm_panel_alloc() breaks it easily. Perhaps it would be cleaner to
assess the whole descriptor before ding any allocation/init.

You're right tat panel_dpi_probe() needs the panel, but it's only at the
very end, to assign the descriptor:

  panel->desc = desc;

I think a good fix would be to clean it up by having:

 * panel_dpi_probe() not take a panel pointer but rather returning a
   filled descriptor
 * panel_simple_probe() call panel_dpi_probe() early [before
   devm_drm_panel_alloc()] and get the filled descriptor
 * call devm_drm_panel_alloc() with that descriptor in the panel-dsi
   case, or with the good old descriptor otherwise

As a good side effect, it would get rid of a case where
devm_drm_panel_alloc() is called with a Unknown connector type.

Anusha, does it look like a good plan?

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 5561 bytes --]

On Wed, Jun 18, 2025 at 10:51:58AM +0200, Luca Ceresoli wrote:
> Hello Anusha, Francesco,
> 
> On Tue, 17 Jun 2025 11:17:20 -0500
> Anusha Srivatsa <asrivats@redhat.com> wrote:
> 
> > On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <francesco@dolcini.it>
> > wrote:
> > 
> > > Hello all,
> > >
> > > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation in
> > > place of devm_kzalloc()")
> > > from 6.16-rc1 introduced a regression with this warning during probe
> > > with panel dpi described in the DT.
> > >
> > > A revert solves the issue.
> > >
> > > The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
> > > panel_dpi_probe() that after that change is called after
> > > devm_drm_panel_alloc().
> > >
> > > I am not sure if there are other implication for this change in the call
> > > ordering, apart the one that triggers this warning.
> > >
> > > [   12.089274] ------------[ cut here ]------------
> > > [   12.089303] WARNING: CPU: 0 PID: 96 at
> > > drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
> > > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
> > > gpu_sched panel_simple imx6_media(C) imx_media_common
> > > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6 autofs4
> > > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
> > >  C          6.16.0-rc1+ #1 PREEMPT
> > > [   12.157446] Tainted: [C]=CRAP
> > > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > > [   12.166953] Workqueue: events_unbound deferred_probe_work_func
> > > [   12.172805] Call trace:
> > > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> > > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> > > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> > > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> > > [   12.195567]  warn_slowpath_fmt from devm_drm_of_get_bridge+0xac/0xb8
> > > [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
> > > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> > > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> > > [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
> > > [   12.224486]  __driver_probe_device from driver_probe_device+0x30/0xc0
> > > [   12.230942]  driver_probe_device from __device_attach_driver+0x98/0x10c
> > > [   12.237572]  __device_attach_driver from bus_for_each_drv+0x90/0xe4
> > > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> > > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> > > [   12.255285]  bus_probe_device from deferred_probe_work_func+0x8c/0xcc
> > > [   12.261739]  deferred_probe_work_func from process_one_work+0x154/0x2dc
> > > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> > > [   12.274043]  worker_thread from kthread+0x12c/0x24c
> > > [   12.278940]  kthread from ret_from_fork+0x14/0x28
> > > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> > > [   12.288720] 9fa0:                                     00000000 00000000
> > > 00000000 00000000
> > > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000
> > > 00000000 00000000
> > > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > > [   12.312050] ---[ end trace 0000000000000000 ]---
> > >
> > > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
> > >
> > > Any advise?
> > >
> > > Hey Francesco!  
> > 
> > This mail reached my spam and I hadn't realised till today. Thanks for
> > bringing this to attention.
> >
> > Thinking out loud here: If we called dpi_probe() before allocating the
> > panel using devm_drm_panel_alloc()
> > then we would have the connector type. But  dpi_probe() needs the panel to
> > be allocated....
> 
> Reading the panel-simple.c code, the handling of the panel_dsi
> descriptor feels a bit hacky, and the recent change to
> devm_drm_panel_alloc() breaks it easily. Perhaps it would be cleaner to
> assess the whole descriptor before ding any allocation/init.
> 
> You're right tat panel_dpi_probe() needs the panel, but it's only at the
> very end, to assign the descriptor:
> 
>   panel->desc = desc;
> 
> I think a good fix would be to clean it up by having:
> 
>  * panel_dpi_probe() not take a panel pointer but rather returning a
>    filled descriptor
>  * panel_simple_probe() call panel_dpi_probe() early [before
>    devm_drm_panel_alloc()] and get the filled descriptor
>  * call devm_drm_panel_alloc() with that descriptor in the panel-dsi
>    case, or with the good old descriptor otherwise
> 
> As a good side effect, it would get rid of a case where
> devm_drm_panel_alloc() is called with a Unknown connector type.
> 
> Anusha, does it look like a good plan?

It is, and I'd even go one step further. Like you said, panel_dpi_probe
kind of exists to allocate and initialize the panel descriptor, and is
called on the descriptor being equal to the (uninitialized) panel_dpi
global variable.

We should also get rid of that hack, so do something like creating a
function that returns the descriptor, and is indeed called first in
panel_simple_probe. It first calls of_device_get_match_data(), and if
there's no match, and if the device is compatible with panel-dpi, then
it calls panel_dpi_probe (we should probably change that name too). That
way, we can get rid of the panel_dpi variable entirely.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Anusha Srivatsa]

[-- Attachment #1: Type: text/plain, Size: 6231 bytes --]

On Wed, Jun 18, 2025 at 4:23 AM Maxime Ripard <mripard@kernel.org> wrote:

> On Wed, Jun 18, 2025 at 10:51:58AM +0200, Luca Ceresoli wrote:
> > Hello Anusha, Francesco,
> >
> > On Tue, 17 Jun 2025 11:17:20 -0500
> > Anusha Srivatsa <asrivats@redhat.com> wrote:
> >
> > > On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <
> francesco@dolcini.it>
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation
> in
> > > > place of devm_kzalloc()")
> > > > from 6.16-rc1 introduced a regression with this warning during probe
> > > > with panel dpi described in the DT.
> > > >
> > > > A revert solves the issue.
> > > >
> > > > The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
> > > > panel_dpi_probe() that after that change is called after
> > > > devm_drm_panel_alloc().
> > > >
> > > > I am not sure if there are other implication for this change in the
> call
> > > > ordering, apart the one that triggers this warning.
> > > >
> > > > [   12.089274] ------------[ cut here ]------------
> > > > [   12.089303] WARNING: CPU: 0 PID: 96 at
> > > > drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
> > > > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
> > > > gpu_sched panel_simple imx6_media(C) imx_media_common
> > > > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6
> autofs4
> > > > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
> > > >  C          6.16.0-rc1+ #1 PREEMPT
> > > > [   12.157446] Tainted: [C]=CRAP
> > > > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> Tree)
> > > > [   12.166953] Workqueue: events_unbound deferred_probe_work_func
> > > > [   12.172805] Call trace:
> > > > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> > > > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> > > > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> > > > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> > > > [   12.195567]  warn_slowpath_fmt from
> devm_drm_of_get_bridge+0xac/0xb8
> > > > [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
> > > > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> > > > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> > > > [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
> > > > [   12.224486]  __driver_probe_device from
> driver_probe_device+0x30/0xc0
> > > > [   12.230942]  driver_probe_device from
> __device_attach_driver+0x98/0x10c
> > > > [   12.237572]  __device_attach_driver from
> bus_for_each_drv+0x90/0xe4
> > > > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> > > > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> > > > [   12.255285]  bus_probe_device from
> deferred_probe_work_func+0x8c/0xcc
> > > > [   12.261739]  deferred_probe_work_func from
> process_one_work+0x154/0x2dc
> > > > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> > > > [   12.274043]  worker_thread from kthread+0x12c/0x24c
> > > > [   12.278940]  kthread from ret_from_fork+0x14/0x28
> > > > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> > > > [   12.288720] 9fa0:                                     00000000
> 00000000
> > > > 00000000 00000000
> > > > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000
> 00000000
> > > > 00000000 00000000
> > > > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013
> 00000000
> > > > [   12.312050] ---[ end trace 0000000000000000 ]---
> > > >
> > > > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
> > > >
> > > > Any advise?
> > > >
> > > > Hey Francesco!
> > >
> > > This mail reached my spam and I hadn't realised till today. Thanks for
> > > bringing this to attention.
> > >
> > > Thinking out loud here: If we called dpi_probe() before allocating the
> > > panel using devm_drm_panel_alloc()
> > > then we would have the connector type. But  dpi_probe() needs the
> panel to
> > > be allocated....
> >
> > Reading the panel-simple.c code, the handling of the panel_dsi
> > descriptor feels a bit hacky, and the recent change to
> > devm_drm_panel_alloc() breaks it easily. Perhaps it would be cleaner to
> > assess the whole descriptor before ding any allocation/init.
> >
> > You're right tat panel_dpi_probe() needs the panel, but it's only at the
> > very end, to assign the descriptor:
> >
> >   panel->desc = desc;
> >
> > I think a good fix would be to clean it up by having:
> >
> >  * panel_dpi_probe() not take a panel pointer but rather returning a
> >    filled descriptor
> >  * panel_simple_probe() call panel_dpi_probe() early [before
> >    devm_drm_panel_alloc()] and get the filled descriptor
> >  * call devm_drm_panel_alloc() with that descriptor in the panel-dsi
> >    case, or with the good old descriptor otherwise
> >
> > As a good side effect, it would get rid of a case where
> > devm_drm_panel_alloc() is called with a Unknown connector type.
> >
> > Anusha, does it look like a good plan?
>
> It is, and I'd even go one step further. Like you said, panel_dpi_probe
> kind of exists to allocate and initialize the panel descriptor, and is
> called on the descriptor being equal to the (uninitialized) panel_dpi
> global variable.
>
> We should also get rid of that hack, so do something like creating a
> function that returns the descriptor, and is indeed called first in
> panel_simple_probe. It first calls of_device_get_match_data(), and if
> there's no match, and if the device is compatible with panel-dpi, then
> it calls panel_dpi_probe (we should probably change that name too). That
> way, we can get rid of the panel_dpi variable entirely.
>
>
Thanks Luca and Maxime.
To summarize:
1. add a function like of_device_get_simple_dsi_match_data() which calls
of_device_get_match_data(). if the device is compatible with panel-dpi,
call
panel-dpi-probe()
3. Change panel_dpi_probe() to return the panel descriptor
4. call devm_drm_panel_alloc()

Thanks,
Anusha

> Maxime
>

[-- Attachment #2: Type: text/html, Size: 7976 bytes --]

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Anusha Srivatsa]

[-- Attachment #1: Type: text/plain, Size: 6889 bytes --]

On Wed, Jun 18, 2025 at 11:48 AM Anusha Srivatsa <asrivats@redhat.com>
wrote:

>
>
> On Wed, Jun 18, 2025 at 4:23 AM Maxime Ripard <mripard@kernel.org> wrote:
>
>> On Wed, Jun 18, 2025 at 10:51:58AM +0200, Luca Ceresoli wrote:
>> > Hello Anusha, Francesco,
>> >
>> > On Tue, 17 Jun 2025 11:17:20 -0500
>> > Anusha Srivatsa <asrivats@redhat.com> wrote:
>> >
>> > > On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <
>> francesco@dolcini.it>
>> > > wrote:
>> > >
>> > > > Hello all,
>> > > >
>> > > > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new
>> allocation in
>> > > > place of devm_kzalloc()")
>> > > > from 6.16-rc1 introduced a regression with this warning during probe
>> > > > with panel dpi described in the DT.
>> > > >
>> > > > A revert solves the issue.
>> > > >
>> > > > The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
>> > > > panel_dpi_probe() that after that change is called after
>> > > > devm_drm_panel_alloc().
>> > > >
>> > > > I am not sure if there are other implication for this change in the
>> call
>> > > > ordering, apart the one that triggers this warning.
>> > > >
>> > > > [   12.089274] ------------[ cut here ]------------
>> > > > [   12.089303] WARNING: CPU: 0 PID: 96 at
>> > > > drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
>> > > > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
>> > > > gpu_sched panel_simple imx6_media(C) imx_media_common
>> > > > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6
>> autofs4
>> > > > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
>> > > >  C          6.16.0-rc1+ #1 PREEMPT
>> > > > [   12.157446] Tainted: [C]=CRAP
>> > > > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device
>> Tree)
>> > > > [   12.166953] Workqueue: events_unbound deferred_probe_work_func
>> > > > [   12.172805] Call trace:
>> > > > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
>> > > > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
>> > > > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
>> > > > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
>> > > > [   12.195567]  warn_slowpath_fmt from
>> devm_drm_of_get_bridge+0xac/0xb8
>> > > > [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
>> > > > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
>> > > > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
>> > > > [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
>> > > > [   12.224486]  __driver_probe_device from
>> driver_probe_device+0x30/0xc0
>> > > > [   12.230942]  driver_probe_device from
>> __device_attach_driver+0x98/0x10c
>> > > > [   12.237572]  __device_attach_driver from
>> bus_for_each_drv+0x90/0xe4
>> > > > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
>> > > > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
>> > > > [   12.255285]  bus_probe_device from
>> deferred_probe_work_func+0x8c/0xcc
>> > > > [   12.261739]  deferred_probe_work_func from
>> process_one_work+0x154/0x2dc
>> > > > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
>> > > > [   12.274043]  worker_thread from kthread+0x12c/0x24c
>> > > > [   12.278940]  kthread from ret_from_fork+0x14/0x28
>> > > > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
>> > > > [   12.288720] 9fa0:                                     00000000
>> 00000000
>> > > > 00000000 00000000
>> > > > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> > > > 00000000 00000000
>> > > > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013
>> 00000000
>> > > > [   12.312050] ---[ end trace 0000000000000000 ]---
>> > > >
>> > > > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
>> > > >
>> > > > Any advise?
>> > > >
>> > > > Hey Francesco!
>> > >
>> > > This mail reached my spam and I hadn't realised till today. Thanks for
>> > > bringing this to attention.
>> > >
>> > > Thinking out loud here: If we called dpi_probe() before allocating the
>> > > panel using devm_drm_panel_alloc()
>> > > then we would have the connector type. But  dpi_probe() needs the
>> panel to
>> > > be allocated....
>> >
>> > Reading the panel-simple.c code, the handling of the panel_dsi
>> > descriptor feels a bit hacky, and the recent change to
>> > devm_drm_panel_alloc() breaks it easily. Perhaps it would be cleaner to
>> > assess the whole descriptor before ding any allocation/init.
>> >
>> > You're right tat panel_dpi_probe() needs the panel, but it's only at the
>> > very end, to assign the descriptor:
>> >
>> >   panel->desc = desc;
>> >
>> > I think a good fix would be to clean it up by having:
>> >
>> >  * panel_dpi_probe() not take a panel pointer but rather returning a
>> >    filled descriptor
>> >  * panel_simple_probe() call panel_dpi_probe() early [before
>> >    devm_drm_panel_alloc()] and get the filled descriptor
>> >  * call devm_drm_panel_alloc() with that descriptor in the panel-dsi
>> >    case, or with the good old descriptor otherwise
>> >
>> > As a good side effect, it would get rid of a case where
>> > devm_drm_panel_alloc() is called with a Unknown connector type.
>> >
>> > Anusha, does it look like a good plan?
>>
>> It is, and I'd even go one step further. Like you said, panel_dpi_probe
>> kind of exists to allocate and initialize the panel descriptor, and is
>> called on the descriptor being equal to the (uninitialized) panel_dpi
>> global variable.
>>
>> We should also get rid of that hack, so do something like creating a
>> function that returns the descriptor, and is indeed called first in
>> panel_simple_probe. It first calls of_device_get_match_data(), and if
>> there's no match, and if the device is compatible with panel-dpi, then
>> it calls panel_dpi_probe (we should probably change that name too). That
>> way, we can get rid of the panel_dpi variable entirely.
>>
>>
> Thanks Luca and Maxime.
> To summarize:
> 1. add a function like of_device_get_simple_dsi_match_data() which calls
> of_device_get_match_data(). if the device is compatible with panel-dpi,
> call
> panel-dpi-probe()
> 3. Change panel_dpi_probe() to return the panel descriptor
> 4. call devm_drm_panel_alloc()
>
>
Looking deeper it looks like I have some gaps in my understanding.
panel_simple_platform_probe()
already checks of_device_get_match_data() to call panel_simple_probe(). At
this point the change suggested is
to have to call it again to check if it is compatible with panel-dpi? If I
understand correctly panel_dpi is a fallback
and the only place the decision to probe panel_dpi() is with the hack.

Thanks,
> Anusha
>
>> Maxime
>>
>

[-- Attachment #2: Type: text/html, Size: 9048 bytes --]

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 7353 bytes --]

On Wed, Jun 18, 2025 at 04:45:31PM -0400, Anusha Srivatsa wrote:
> On Wed, Jun 18, 2025 at 11:48 AM Anusha Srivatsa <asrivats@redhat.com>
> wrote:
> > On Wed, Jun 18, 2025 at 4:23 AM Maxime Ripard <mripard@kernel.org> wrote:
> >
> >> On Wed, Jun 18, 2025 at 10:51:58AM +0200, Luca Ceresoli wrote:
> >> > Hello Anusha, Francesco,
> >> >
> >> > On Tue, 17 Jun 2025 11:17:20 -0500
> >> > Anusha Srivatsa <asrivats@redhat.com> wrote:
> >> >
> >> > > On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <
> >> francesco@dolcini.it>
> >> > > wrote:
> >> > >
> >> > > > Hello all,
> >> > > >
> >> > > > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new
> >> allocation in
> >> > > > place of devm_kzalloc()")
> >> > > > from 6.16-rc1 introduced a regression with this warning during probe
> >> > > > with panel dpi described in the DT.
> >> > > >
> >> > > > A revert solves the issue.
> >> > > >
> >> > > > The issue is that connector_type is set to DRM_MODE_CONNECTOR_DPI in
> >> > > > panel_dpi_probe() that after that change is called after
> >> > > > devm_drm_panel_alloc().
> >> > > >
> >> > > > I am not sure if there are other implication for this change in the
> >> call
> >> > > > ordering, apart the one that triggers this warning.
> >> > > >
> >> > > > [   12.089274] ------------[ cut here ]------------
> >> > > > [   12.089303] WARNING: CPU: 0 PID: 96 at
> >> > > > drivers/gpu/drm/bridge/panel.c:377 devm_drm_of_get_bridge+0xac/0xb8
> >> > > > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+) imx_vdoa
> >> > > > gpu_sched panel_simple imx6_media(C) imx_media_common
> >> > > > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6
> >> autofs4
> >> > > > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3 Tainted: G
> >> > > >  C          6.16.0-rc1+ #1 PREEMPT
> >> > > > [   12.157446] Tainted: [C]=CRAP
> >> > > > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> >> Tree)
> >> > > > [   12.166953] Workqueue: events_unbound deferred_probe_work_func
> >> > > > [   12.172805] Call trace:
> >> > > > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> >> > > > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> >> > > > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> >> > > > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> >> > > > [   12.195567]  warn_slowpath_fmt from
> >> devm_drm_of_get_bridge+0xac/0xb8
> >> > > > [   12.201949]  devm_drm_of_get_bridge from imx_pd_probe+0x58/0x164
> >> > > > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> >> > > > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> >> > > > [   12.218551]  really_probe from __driver_probe_device+0x8c/0x1d4
> >> > > > [   12.224486]  __driver_probe_device from
> >> driver_probe_device+0x30/0xc0
> >> > > > [   12.230942]  driver_probe_device from
> >> __device_attach_driver+0x98/0x10c
> >> > > > [   12.237572]  __device_attach_driver from
> >> bus_for_each_drv+0x90/0xe4
> >> > > > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> >> > > > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> >> > > > [   12.255285]  bus_probe_device from
> >> deferred_probe_work_func+0x8c/0xcc
> >> > > > [   12.261739]  deferred_probe_work_func from
> >> process_one_work+0x154/0x2dc
> >> > > > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> >> > > > [   12.274043]  worker_thread from kthread+0x12c/0x24c
> >> > > > [   12.278940]  kthread from ret_from_fork+0x14/0x28
> >> > > > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> >> > > > [   12.288720] 9fa0:                                     00000000
> >> 00000000
> >> > > > 00000000 00000000
> >> > > > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000 00000000
> >> 00000000
> >> > > > 00000000 00000000
> >> > > > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000 00000013
> >> 00000000
> >> > > > [   12.312050] ---[ end trace 0000000000000000 ]---
> >> > > >
> >> > > > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
> >> > > >
> >> > > > Any advise?
> >> > > >
> >> > > > Hey Francesco!
> >> > >
> >> > > This mail reached my spam and I hadn't realised till today. Thanks for
> >> > > bringing this to attention.
> >> > >
> >> > > Thinking out loud here: If we called dpi_probe() before allocating the
> >> > > panel using devm_drm_panel_alloc()
> >> > > then we would have the connector type. But  dpi_probe() needs the
> >> panel to
> >> > > be allocated....
> >> >
> >> > Reading the panel-simple.c code, the handling of the panel_dsi
> >> > descriptor feels a bit hacky, and the recent change to
> >> > devm_drm_panel_alloc() breaks it easily. Perhaps it would be cleaner to
> >> > assess the whole descriptor before ding any allocation/init.
> >> >
> >> > You're right tat panel_dpi_probe() needs the panel, but it's only at the
> >> > very end, to assign the descriptor:
> >> >
> >> >   panel->desc = desc;
> >> >
> >> > I think a good fix would be to clean it up by having:
> >> >
> >> >  * panel_dpi_probe() not take a panel pointer but rather returning a
> >> >    filled descriptor
> >> >  * panel_simple_probe() call panel_dpi_probe() early [before
> >> >    devm_drm_panel_alloc()] and get the filled descriptor
> >> >  * call devm_drm_panel_alloc() with that descriptor in the panel-dsi
> >> >    case, or with the good old descriptor otherwise
> >> >
> >> > As a good side effect, it would get rid of a case where
> >> > devm_drm_panel_alloc() is called with a Unknown connector type.
> >> >
> >> > Anusha, does it look like a good plan?
> >>
> >> It is, and I'd even go one step further. Like you said, panel_dpi_probe
> >> kind of exists to allocate and initialize the panel descriptor, and is
> >> called on the descriptor being equal to the (uninitialized) panel_dpi
> >> global variable.
> >>
> >> We should also get rid of that hack, so do something like creating a
> >> function that returns the descriptor, and is indeed called first in
> >> panel_simple_probe. It first calls of_device_get_match_data(), and if
> >> there's no match, and if the device is compatible with panel-dpi, then
> >> it calls panel_dpi_probe (we should probably change that name too). That
> >> way, we can get rid of the panel_dpi variable entirely.
> >>
> >>
> > Thanks Luca and Maxime.
> > To summarize:
> > 1. add a function like of_device_get_simple_dsi_match_data() which calls
> > of_device_get_match_data(). if the device is compatible with panel-dpi,
> > call
> > panel-dpi-probe()
> > 3. Change panel_dpi_probe() to return the panel descriptor
> > 4. call devm_drm_panel_alloc()
> >
> >
> Looking deeper it looks like I have some gaps in my understanding.
> panel_simple_platform_probe()
> already checks of_device_get_match_data() to call panel_simple_probe(). At
> this point the change suggested is
> to have to call it again to check if it is compatible with panel-dpi? If I
> understand correctly panel_dpi is a fallback
> and the only place the decision to probe panel_dpi() is with the hack.

I'm sure you can figure something out. And feel free to send me patches
for a private review if you feel more comfortable that way.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: drm/panel/panel-simple v6.16-rc1 WARNING regression

[Anusha Srivatsa]

[-- Attachment #1: Type: text/plain, Size: 7905 bytes --]

On Thu, Jun 19, 2025 at 7:08 AM Maxime Ripard <mripard@kernel.org> wrote:

> On Wed, Jun 18, 2025 at 04:45:31PM -0400, Anusha Srivatsa wrote:
> > On Wed, Jun 18, 2025 at 11:48 AM Anusha Srivatsa <asrivats@redhat.com>
> > wrote:
> > > On Wed, Jun 18, 2025 at 4:23 AM Maxime Ripard <mripard@kernel.org>
> wrote:
> > >
> > >> On Wed, Jun 18, 2025 at 10:51:58AM +0200, Luca Ceresoli wrote:
> > >> > Hello Anusha, Francesco,
> > >> >
> > >> > On Tue, 17 Jun 2025 11:17:20 -0500
> > >> > Anusha Srivatsa <asrivats@redhat.com> wrote:
> > >> >
> > >> > > On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini <
> > >> francesco@dolcini.it>
> > >> > > wrote:
> > >> > >
> > >> > > > Hello all,
> > >> > > >
> > >> > > > Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new
> > >> allocation in
> > >> > > > place of devm_kzalloc()")
> > >> > > > from 6.16-rc1 introduced a regression with this warning during
> probe
> > >> > > > with panel dpi described in the DT.
> > >> > > >
> > >> > > > A revert solves the issue.
> > >> > > >
> > >> > > > The issue is that connector_type is set to
> DRM_MODE_CONNECTOR_DPI in
> > >> > > > panel_dpi_probe() that after that change is called after
> > >> > > > devm_drm_panel_alloc().
> > >> > > >
> > >> > > > I am not sure if there are other implication for this change in
> the
> > >> call
> > >> > > > ordering, apart the one that triggers this warning.
> > >> > > >
> > >> > > > [   12.089274] ------------[ cut here ]------------
> > >> > > > [   12.089303] WARNING: CPU: 0 PID: 96 at
> > >> > > > drivers/gpu/drm/bridge/panel.c:377
> devm_drm_of_get_bridge+0xac/0xb8
> > >> > > > [   12.130808] Modules linked in: v4l2_jpeg pwm_imx27(+)
> imx_vdoa
> > >> > > > gpu_sched panel_simple imx6_media(C) imx_media_common
> > >> > > > (C) videobuf2_dma_contig pwm_bl gpio_keys v4l2_mem2mem fuse ipv6
> > >> autofs4
> > >> > > > [   12.147774] CPU: 0 UID: 0 PID: 96 Comm: kworker/u8:3
> Tainted: G
> > >> > > >  C          6.16.0-rc1+ #1 PREEMPT
> > >> > > > [   12.157446] Tainted: [C]=CRAP
> > >> > > > [   12.160418] Hardware name: Freescale i.MX6 Quad/DualLite
> (Device
> > >> Tree)
> > >> > > > [   12.166953] Workqueue: events_unbound
> deferred_probe_work_func
> > >> > > > [   12.172805] Call trace:
> > >> > > > [   12.172815]  unwind_backtrace from show_stack+0x10/0x14
> > >> > > > [   12.180598]  show_stack from dump_stack_lvl+0x68/0x74
> > >> > > > [   12.185674]  dump_stack_lvl from __warn+0x7c/0xe0
> > >> > > > [   12.190407]  __warn from warn_slowpath_fmt+0x1b8/0x1c0
> > >> > > > [   12.195567]  warn_slowpath_fmt from
> > >> devm_drm_of_get_bridge+0xac/0xb8
> > >> > > > [   12.201949]  devm_drm_of_get_bridge from
> imx_pd_probe+0x58/0x164
> > >> > > > [   12.207976]  imx_pd_probe from platform_probe+0x5c/0xb0
> > >> > > > [   12.213220]  platform_probe from really_probe+0xd0/0x3a4
> > >> > > > [   12.218551]  really_probe from
> __driver_probe_device+0x8c/0x1d4
> > >> > > > [   12.224486]  __driver_probe_device from
> > >> driver_probe_device+0x30/0xc0
> > >> > > > [   12.230942]  driver_probe_device from
> > >> __device_attach_driver+0x98/0x10c
> > >> > > > [   12.237572]  __device_attach_driver from
> > >> bus_for_each_drv+0x90/0xe4
> > >> > > > [   12.243854]  bus_for_each_drv from __device_attach+0xa8/0x1c8
> > >> > > > [   12.249614]  __device_attach from bus_probe_device+0x88/0x8c
> > >> > > > [   12.255285]  bus_probe_device from
> > >> deferred_probe_work_func+0x8c/0xcc
> > >> > > > [   12.261739]  deferred_probe_work_func from
> > >> process_one_work+0x154/0x2dc
> > >> > > > [   12.268371]  process_one_work from worker_thread+0x250/0x3f0
> > >> > > > [   12.274043]  worker_thread from kthread+0x12c/0x24c
> > >> > > > [   12.278940]  kthread from ret_from_fork+0x14/0x28
> > >> > > > [   12.283660] Exception stack(0xd0be9fb0 to 0xd0be9ff8)
> > >> > > > [   12.288720] 9fa0:
>  00000000
> > >> 00000000
> > >> > > > 00000000 00000000
> > >> > > > [   12.296906] 9fc0: 00000000 00000000 00000000 00000000
> 00000000
> > >> 00000000
> > >> > > > 00000000 00000000
> > >> > > > [   12.305089] 9fe0: 00000000 00000000 00000000 00000000
> 00000013
> > >> 00000000
> > >> > > > [   12.312050] ---[ end trace 0000000000000000 ]---
> > >> > > >
> > >> > > > #regzbot ^introduced: de04bb0089a96cc00d13b12cbf66a088befe3057
> > >> > > >
> > >> > > > Any advise?
> > >> > > >
> > >> > > > Hey Francesco!
> > >> > >
> > >> > > This mail reached my spam and I hadn't realised till today.
> Thanks for
> > >> > > bringing this to attention.
> > >> > >
> > >> > > Thinking out loud here: If we called dpi_probe() before
> allocating the
> > >> > > panel using devm_drm_panel_alloc()
> > >> > > then we would have the connector type. But  dpi_probe() needs the
> > >> panel to
> > >> > > be allocated....
> > >> >
> > >> > Reading the panel-simple.c code, the handling of the panel_dsi
> > >> > descriptor feels a bit hacky, and the recent change to
> > >> > devm_drm_panel_alloc() breaks it easily. Perhaps it would be
> cleaner to
> > >> > assess the whole descriptor before ding any allocation/init.
> > >> >
> > >> > You're right tat panel_dpi_probe() needs the panel, but it's only
> at the
> > >> > very end, to assign the descriptor:
> > >> >
> > >> >   panel->desc = desc;
> > >> >
> > >> > I think a good fix would be to clean it up by having:
> > >> >
> > >> >  * panel_dpi_probe() not take a panel pointer but rather returning a
> > >> >    filled descriptor
> > >> >  * panel_simple_probe() call panel_dpi_probe() early [before
> > >> >    devm_drm_panel_alloc()] and get the filled descriptor
> > >> >  * call devm_drm_panel_alloc() with that descriptor in the panel-dsi
> > >> >    case, or with the good old descriptor otherwise
> > >> >
> > >> > As a good side effect, it would get rid of a case where
> > >> > devm_drm_panel_alloc() is called with a Unknown connector type.
> > >> >
> > >> > Anusha, does it look like a good plan?
> > >>
> > >> It is, and I'd even go one step further. Like you said,
> panel_dpi_probe
> > >> kind of exists to allocate and initialize the panel descriptor, and is
> > >> called on the descriptor being equal to the (uninitialized) panel_dpi
> > >> global variable.
> > >>
> > >> We should also get rid of that hack, so do something like creating a
> > >> function that returns the descriptor, and is indeed called first in
> > >> panel_simple_probe. It first calls of_device_get_match_data(), and if
> > >> there's no match, and if the device is compatible with panel-dpi, then
> > >> it calls panel_dpi_probe (we should probably change that name too).
> That
> > >> way, we can get rid of the panel_dpi variable entirely.
> > >>
> > >>
> > > Thanks Luca and Maxime.
> > > To summarize:
> > > 1. add a function like of_device_get_simple_dsi_match_data() which
> calls
> > > of_device_get_match_data(). if the device is compatible with panel-dpi,
> > > call
> > > panel-dpi-probe()
> > > 3. Change panel_dpi_probe() to return the panel descriptor
> > > 4. call devm_drm_panel_alloc()
> > >
> > >
> > Looking deeper it looks like I have some gaps in my understanding.
> > panel_simple_platform_probe()
> > already checks of_device_get_match_data() to call panel_simple_probe().
> At
> > this point the change suggested is
> > to have to call it again to check if it is compatible with panel-dpi? If
> I
> > understand correctly panel_dpi is a fallback
> > and the only place the decision to probe panel_dpi() is with the hack.
>
> I'm sure you can figure something out. And feel free to send me patches
> for a private review if you feel more comfortable that way.
>
>
Sure!
@Francesco Dolcini <francesco@dolcini.it>  Sending a fix with needed code
reorder in a  day or two.

Anusha

> Maxime
>

[-- Attachment #2: Type: text/html, Size: 11148 bytes --]