RPi 4 deferred probe timeout of V3D PM domain

Krzysztof Kozlowski krzk at kernel.org
Thu Oct 30 12:36:52 PDT 2025


On 30/10/2025 20:13, Stefan Wahren wrote:
> Hi Ulf,
> 
> 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

Core clock modules you should have as part of your initramfs, not rely
on rootfs to load. You can also move the domain to module, but it still
won't solve the problem of lack of initramfs population.

Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list