[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