On Thu, Jun 19, 2025 at 7:08 AM Maxime Ripard <[email protected]> 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 <[email protected]> > > wrote: > > > On Wed, Jun 18, 2025 at 4:23 AM Maxime Ripard <[email protected]> > 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 <[email protected]> wrote: > > >> > > > >> > > On Thu, Jun 12, 2025 at 3:24 AM Francesco Dolcini < > > >> [email protected]> > > >> > > 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 <[email protected]> Sending a fix with needed code reorder in a day or two. Anusha > Maxime >
