[PATCH] ARM: dts: broadcom: rpi: Switch to V3D firmware clock

Stefan Wahren wahrenst at gmx.net
Wed Oct 29 12:51:38 PDT 2025


Am 28.10.25 um 19:47 schrieb Mark Brown:
> On Tue, Oct 28, 2025 at 07:03:59PM +0100, Stefan Wahren wrote:
>> Am 27.10.25 um 17:51 schrieb Mark Brown:
>>>> Is there a HDMI cable connected?
>>> No, the boards only have ethernet, serial and power connected.
>> I switched to the same Raspberry Pi firmware 2023-10-17 and added U-Boot
>> 2024.01 as second stage bootloader, but still not able to reproduce.
>> Looking at the LAVA output, I'm seeing this as the very first issue(s):
>> [   13.480675] platform wifi-pwrseq: deferred probe pending: pwrseq_simple:
>> reset control not ready
>> [   13.489095] platform bcm2835-power: deferred probe pending:
>> bcm2835-power: Failed to get clock v3d
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.





More information about the linux-arm-kernel mailing list