RPi 4 deferred probe timeout of V3D PM domain

Thu Oct 30 13:12:57 PDT 2025

On 30.10.2025 20:13, Stefan Wahren wrote:
>
> Am 30.10.25 um 13:59 schrieb Mark Brown:
>> On Wed, Oct 29, 2025 at 08:51:38PM +0100, Stefan Wahren wrote:
>>> Am 28.10.25 um 19:47 schrieb Mark Brown:
>>> Okay, here is my theory. The difference is about (boot) time. In my 
>>> setup
>>> the whole device boot from SD card and in your case the kernel 
>>> modules are
>>> stored via NFS.
>>> V3D requires two resources, a clock and a PM domain. Additionally 
>>> the PM
>>> domain itself depends on the very same clock. In arm64/defconfig the
>>> relevant clock driver is build as module, but the PM domain driver is
>>> builtin.
>>> During boot "driver_deferred_probe_timeout" (10 s) expires before 
>>> the clock
>>> driver could be loaded via NFS. So the PM domain core gave up:
>>> [   16.936547] v3d fec00000.gpu: deferred probe timeout, ignoring 
>>> dependency
>>> So this breaks probing of V3D driver in this case.
>> That seems buggy on the part of the core, particularly since userspace
>> isn't there yet so we might be missing some filesystems - I would have
>> expected the device to probe once the supply becomes available. But I
>> do agree with your analysis, it doesn't look like an issue with this
>> driver.
> recent changes to the Raspberry Pi 4 device tree revealed the issue 
> for the following corner case:
> V3D requires two resources, a clock and a PM domain. Additionally the 
> PM domain itself depends on the very same clock. In arm64/defconfig 
> the relevant clock driver clk-raspberrypi is build as module, but the 
> PM domain driver bcm2835-pmdomain is builtin.
>
> During boot "driver_deferred_probe_timeout" (10 s) expires before the 
> clock driver could be loaded via NFS. So the PM domain core gave up:
> [   16.936547] v3d fec00000.gpu: deferred probe timeout, ignoring 
> dependency
>
> Expected behavior would be that the pmdomain defers probing until the 
> clk-driver is loaded from NFS.
>
> I simulated Marks setup and replaced the dev_warn above with a 
> dev_WARN and got the following result:
>
> [   22.516225] v3d fec00000.gpu: __genpd_dev_pm_attach() failed to 
> find PM domain: -2
> [   22.516260] ------------[ cut here ]------------
> [   22.516268] v3d fec00000.gpu: deferred probe timeout, ignoring 
> dependency
> [   22.516355] WARNING: CPU: 0 PID: 75 at drivers/base/dd.c:297 
> driver_deferred_probe_check_state+0x64/0x80
> [   22.516401] Modules linked in: aes_neon_blk af_alg brcmfmac_wcc 
> qrtr vc4 brcmfmac snd_soc_hdmi_codec snd_soc_core brcmutil 
> snd_compress snd_pcm_dmaengine sha256 snd_bcm2835(C) cfg80211 drm_exec 
> hci_uart snd_pcm btqca snd_timer btbcm snd bluetooth soundcore 
> drm_display_helper ecdh_generic broadcom v3d ecc bcm_phy_lib cec 
> drm_shmem_helper drm_client_lib pcie_brcmstb gpu_sched drm_dma_helper 
> genet raspberrypi_hwmon rfkill bcm2711_thermal drm_kms_helper 
> irq_bcm2712_mip pwrseq_core i2c_bcm2835 nvmem_rmem vchiq(C) 
> pwm_bcm2835 i2c_mux_pinctrl reset_gpio drm fuse backlight dm_mod ipv6
> [   22.516721] CPU: 0 UID: 0 PID: 75 Comm: kworker/u16:3 Tainted: G   
>      C          6.18.0-rc3-dirty #7 PREEMPT
> [   22.516743] Tainted: [C]=CRAP
> [   22.516751] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
> [   22.516763] Workqueue: events_unbound deferred_probe_work_func
> [   22.516792] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS 
> BTYPE=--)
> [   22.516806] pc : driver_deferred_probe_check_state+0x64/0x80
> [   22.516828] lr : driver_deferred_probe_check_state+0x64/0x80
> [   22.516847] sp : ffff800080c7ba90
> [   22.516856] x29: ffff800080c7ba90 x28: 0000000000000000 x27: 
> 0000000000000000
> [   22.516884] x26: ffff00010001c028 x25: 0000000000000001 x24: 
> ffff000100136c10
> [   22.516910] x23: 0000000000000001 x22: fffffffffffffffe x21: 
> 0000000000000000
> [   22.516935] x20: ffff000100136c10 x19: ffff000100136c10 x18: 
> fffffffffffe71c8
> [   22.516958] x17: 616d6f64204d5020 x16: 646e6966206f7420 x15: 
> ffffb4b9255d6c70
> [   22.516982] x14: 0000000000000000 x13: ffffb4b9255d6cf8 x12: 
> 00000000000004c5
> [   22.517005] x11: 0000000000000197 x10: ffffb4b92562ecf8 x9 : 
> ffffb4b9255d6cf8
> [   22.517029] x8 : 00000000ffffefff x7 : ffffb4b92562ecf8 x6 : 
> 80000000fffff000
> [   22.517053] x5 : ffff0001fef97408 x4 : 0000000000000000 x3 : 
> 0000000000000027
> [   22.517076] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 
> ffff000100806900
> [   22.517100] Call trace:
> [   22.517111]  driver_deferred_probe_check_state+0x64/0x80 (P)
> [   22.517135]  __genpd_dev_pm_attach+0x270/0x2c4
> [   22.517159]  genpd_dev_pm_attach+0x64/0x74
> [   22.517178]  dev_pm_domain_attach+0x78/0x7c
> [   22.517200]  platform_probe+0x48/0x98
> [   22.517215]  really_probe+0xbc/0x29c
> [   22.517228]  __driver_probe_device+0x78/0x12c
> [   22.517241]  driver_probe_device+0xd8/0x15c
> [   22.517254]  __device_attach_driver+0xb8/0x134
> [   22.517267]  bus_for_each_drv+0x88/0xe8
> [   22.517286]  __device_attach+0xa0/0x190
> [   22.517299]  device_initial_probe+0x14/0x20
> [   22.517312]  bus_probe_device+0xac/0xb0
> [   22.517331]  deferred_probe_work_func+0x88/0xc0
> [   22.517351]  process_one_work+0x148/0x28c
> [   22.517375]  worker_thread+0x2d0/0x3d8
> [   22.517394]  kthread+0x12c/0x204
> [   22.517413]  ret_from_fork+0x10/0x20
> [   22.517433] ---[ end trace 0000000000000000 ]---
> [   22.517450] v3d fec00000.gpu: probe with driver v3d failed with 
> error -110
> [   22.523164] platform fef05700.hdmi: deferred probe pending: (reason 
> unknown)
> [   22.523197] platform bcm2835-power: deferred probe pending: 
> bcm2835-power: Failed to get clock v3d
>
> Do you think issue is in bcm2835-pmdomain or in the pmdomain core?
> Any ideas how to solve this?

As I mentioned in the other thread, this is imho a configuration issue. 
If core modules are distributed on NFS rootfs, then one should increase 
deferred probe timeout by adding deferred_probe_timeout=60 to cmdline. 
On the other hand drivers built into the kernel should not depend on the 
resources provided by the drivers built as modules, so maybe it would 
make sense to change CONFIG_CLK_RASPBERRYPI from 'm' to 'y' in 
arch/arm64/configs/defconfig.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland