dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Anusha Srivatsa <asrivats@redhat.com>
Cc: Francesco Dolcini <francesco@dolcini.it>,
	Maxime Ripard <mripard@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jessica Zhang <quic_jesszhan@quicinc.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	regressions@lists.linux.dev
Subject: Re: drm/panel/panel-simple v6.16-rc1 WARNING regression
Date: Wed, 18 Jun 2025 10:51:58 +0200	[thread overview]
Message-ID: <20250618105158.06e42668@booty> (raw)
In-Reply-To: <CAN9Xe3RFEXZuWTZB5E1tJdjXc9o_hB1ArgA5SvqbDUBkwYea8w@mail.gmail.com>

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

  parent reply	other threads:[~2025-06-18  8:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12  8:18 drm/panel/panel-simple v6.16-rc1 WARNING regression Francesco Dolcini
2025-06-17 16:17 ` Anusha Srivatsa
2025-06-18  8:50   ` Francesco Dolcini
2025-06-18  8:51   ` Luca Ceresoli [this message]
2025-06-18  9:22     ` Maxime Ripard
2025-06-18 15:48       ` Anusha Srivatsa
2025-06-18 20:45         ` Anusha Srivatsa
2025-06-19 12:07           ` Maxime Ripard
2025-06-23 16:56             ` Anusha Srivatsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250618105158.06e42668@booty \
    --to=luca.ceresoli@bootlin.com \
    --cc=airlied@gmail.com \
    --cc=asrivats@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=francesco@dolcini.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_jesszhan@quicinc.com \
    --cc=regressions@lists.linux.dev \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).