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