Re: drm-misc-next: WARNING: at drivers/gpu/drm/vc4/vc4_hdmi_regs.h:487

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Maxime,

Am 30.06.22 um 09:37 schrieb Maxime Ripard:
Hi Stefan,

On Wed, Jun 29, 2022 at 10:50:21PM +0200, Stefan Wahren wrote:
Hi Maxime,

i tested todays drm-misc-next 9db35bb349 with Raspberry Pi 3 B Plus
(arm/multi_v7_defconfig, mainline DTB) and get the following warning in the
kernel logs:

[   25.698459] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   25.698657] ------------[ cut here ]------------
[   25.698660] WARNING: CPU: 1 PID: 153 at
drivers/gpu/drm/vc4/vc4_hdmi_regs.h:487 vc4_hdmi_reset+0x3e0/0x4e0 [vc4]
[   25.698757] Modules linked in: brcmutil vc4(+) snd_soc_core ac97_bus
sha256_generic libsha256 snd_pcm_dmaengine sha256_arm snd_pcm cfg80211
snd_timer hci_uart btbcm snd soundcore bluetooth raspberrypi_hwmon
drm_cma_helper ecdh_generic ecc libaes bcm2835_thermal microchip lan78xx
crc32_arm_ce
[   25.698831] CPU: 1 PID: 153 Comm: systemd-udevd Not tainted
5.19.0-rc2-00085-g9db35bb349a0 #2
[   25.698839] Hardware name: BCM2835
[   25.698850]  unwind_backtrace from show_stack+0x10/0x14
[   25.698866]  show_stack from dump_stack_lvl+0x40/0x4c
[   25.698879]  dump_stack_lvl from __warn+0xcc/0x144
[   25.698890]  __warn from warn_slowpath_fmt+0x5c/0xb4
[   25.698900]  warn_slowpath_fmt from vc4_hdmi_reset+0x3e0/0x4e0 [vc4]
[   25.698996]  vc4_hdmi_reset [vc4] from vc4_hdmi_runtime_resume+0x4c/0x64
[vc4]
[   25.699165]  vc4_hdmi_runtime_resume [vc4] from vc4_hdmi_bind+0x208/0x994
[vc4]
[   25.699333]  vc4_hdmi_bind [vc4] from component_bind_all+0x100/0x230
[   25.699428]  component_bind_all from vc4_drm_bind+0x1a8/0x280 [vc4]
[   25.699518]  vc4_drm_bind [vc4] from
try_to_bring_up_aggregate_device+0x160/0x1bc
[   25.699610]  try_to_bring_up_aggregate_device from
component_master_add_with_match+0xc4/0xf8
[   25.699622]  component_master_add_with_match from
vc4_platform_drm_probe+0xa0/0xc0 [vc4]
[   25.699712]  vc4_platform_drm_probe [vc4] from platform_probe+0x5c/0xbc
[   25.699802]  platform_probe from really_probe.part.0+0x9c/0x2b0
[   25.699812]  really_probe.part.0 from __driver_probe_device+0xa8/0x13c
[   25.699823]  __driver_probe_device from driver_probe_device+0x34/0x108
[   25.699834]  driver_probe_device from __driver_attach+0xb4/0x17c
[   25.699846]  __driver_attach from bus_for_each_dev+0x70/0xb0
[   25.699856]  bus_for_each_dev from bus_add_driver+0x164/0x1f0
[   25.699867]  bus_add_driver from driver_register+0x88/0x11c
[   25.699878]  driver_register from do_one_initcall+0x40/0x1d4
[   25.699890]  do_one_initcall from do_init_module+0x44/0x1d4
[   25.699901]  do_init_module from sys_finit_module+0xbc/0xf8
[   25.699909]  sys_finit_module from __sys_trace_return+0x0/0x10
[   25.699918] Exception stack(0xf568dfa8 to 0xf568dff0)
[   25.699926] dfa0:                   6a09f700 00000000 00000016 b6dee8e0
00000000 b6def3f4
[   25.699934] dfc0: 6a09f700 00000000 00000000 0000017b 0053b9a8 0052a1dc
0053af10 00000000
[   25.699940] dfe0: be8e5160 be8e5150 b6de59d8 b6ed5ae0
[   25.699944] ---[ end trace 0000000000000000 ]---

I was able to bisect the warning to the following commit:

drm/vc4: hdmi: Move HDMI reset to pm_resume

The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.

That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.

That initialization involves calling the reset function and initializing
the CEC registers.

Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.

Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to
runtime_pm")
Signed-off-by: Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@xxxxxxxxxx
Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx>
Yeah, I noticed it yesterday

https://lore.kernel.org/dri-devel/20220629123510.1915022-1-maxime@xxxxxxxxxx/T/#m1027cef33d8c66a302b2b8a80bab8a9dc6652f04

and

https://lore.kernel.org/dri-devel/20220629123510.1915022-1-maxime@xxxxxxxxxx/T/#mc869819c66f7b3df8b31a320636a9172780a58e7

Should address it

i applied them and it fixed the issue on the Raspberry Pi 3 B Plus.

You can have

Tested-by: Stefan Wahren <stefan.wahren@xxxxxxxx>

for both of them.

Btw i noticed that the offending patch introduced a #ifdef block within the code. AFAIK this is undesirable. Should i send i patch?

Best regards


Maxime



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux