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

Marek Szyprowski m.szyprowski at samsung.com
Thu Oct 30 12:09:47 PDT 2025


On 30.10.2025 13:59, Mark Brown wrote:
> 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.

Well, I see this partially as a configuration issue. Probably in case of 
NFS root and modules distributed there it would be good to add 
deferred_probe_timeout=60 or something like that. I'm not sure if there 
can be any generic solution for this kind of issues.

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




More information about the linux-arm-kernel mailing list