Raspberry firmware driver expected said firmware to answer by 1 second.
That seems to work fine for most cases, but with
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE, that IIUC may need to reconfigure a
monitor, i end up reliably having timeouts:
[    2.861407] ------------[ cut here ]------------
[    2.865512] Firmware transaction 0x00030066 timeout
[    2.865549] WARNING: CPU: 3 PID: 42 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x21c/0x29c
[    2.880751] CPU: 3 UID: 0 PID: 42 Comm: kworker/u16:1 Not tainted 6.15.0-rc6 #1 PREEMPT
[    2.888944] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[    2.894848] Workqueue: events_unbound deferred_probe_work_func
[    2.900752] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    2.907801] pc : rpi_firmware_property_list+0x21c/0x29c
[    2.913089] lr : rpi_firmware_property_list+0x21c/0x29c
[    2.918376] sp : ffffffc0803139c0
[    2.921725] x29: ffffffc0803139e0 x28: ffffff8040bbef50 x27: ffffff80410c0f40
[    2.928953] x26: ffffffd7055d9e28 x25: ffffffc0801e0008 x24: 0000000000001000
[    2.936179] x23: ffffff80410c1080 x22: 000000000000000a x21: ffffff80410c0f00
[    2.943405] x20: 000000000000000c x19: ffffffc0801e0000 x18: ffffffc08030d0a0
[    2.950632] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[    2.957858] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[    2.965085] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[    2.972311] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[    2.979537] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[    2.986764] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[    2.993992] Call trace:
[    2.996458]  rpi_firmware_property_list+0x21c/0x29c (P)
[    3.001747]  rpi_firmware_property+0x70/0xd8
[    3.006064]  vc4_drm_bind+0x12c/0x378
[    3.009765]  try_to_bring_up_aggregate_device+0x22c/0x308
[    3.015230]  __component_add+0xec/0x224
[    3.019106]  component_add+0x14/0x30
[    3.022720]  vc4_hdmi_dev_probe+0x1c/0x40
[    3.026773]  platform_probe+0x68/0xf0
[    3.030474]  really_probe+0xc0/0x3ac
[    3.034088]  __driver_probe_device+0x7c/0x174
[    3.038495]  driver_probe_device+0x40/0x100
[    3.042725]  __device_attach_driver+0x10c/0x1e0
[    3.047308]  bus_for_each_drv+0x88/0x100
[    3.051273]  __device_attach+0xa0/0x1c8
[    3.055151]  device_initial_probe+0x14/0x30
[    3.059381]  bus_probe_device+0xc8/0xcc
[    3.063259]  deferred_probe_work_func+0xb8/0x12c
[    3.067930]  process_one_work+0x160/0x2d4
[    3.071983]  worker_thread+0x2d8/0x400
[    3.075773]  kthread+0x12c/0x208
[    3.079034]  ret_from_fork+0x10/0x20
[    3.082647] ---[ end trace 0000000000000000 ]---

Raising the timeout to 3 seconds (ought to be enough®) doesn't trigger
timeouts anymore for me and proceeds to the next failure.

Signed-off-by: Etienne Buira <etienne.buira@free.fr>
---
 drivers/firmware/raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 7ecde6921a0a..e3c998def0e1 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -58,7 +58,7 @@ rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
 	reinit_completion(&fw->c);
 	ret = mbox_send_message(fw->chan, &message);
 	if (ret >= 0) {
-		if (wait_for_completion_timeout(&fw->c, HZ)) {
+		if (wait_for_completion_timeout(&fw->c, 3*HZ)) {
 			ret = 0;
 		} else {
 			ret = -ETIMEDOUT;
-- 
2.48.1

Hi Etienne,

Am 12.05.25 um 18:30 schrieb Etienne Buira:
> Raspberry firmware driver expected said firmware to answer by 1 second.
> That seems to work fine for most cases, but with
> RPI_FIRMWARE_NOTIFY_DISPLAY_DONE, that IIUC may need to reconfigure a
> monitor, i end up reliably having timeouts:
> [    2.861407] ------------[ cut here ]------------
> [    2.865512] Firmware transaction 0x00030066 timeout
> [    2.865549] WARNING: CPU: 3 PID: 42 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x21c/0x29c
> [    2.880751] CPU: 3 UID: 0 PID: 42 Comm: kworker/u16:1 Not tainted 6.15.0-rc6 #1 PREEMPT
> [    2.888944] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
> [    2.894848] Workqueue: events_unbound deferred_probe_work_func
> [    2.900752] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    2.907801] pc : rpi_firmware_property_list+0x21c/0x29c
> [    2.913089] lr : rpi_firmware_property_list+0x21c/0x29c
> [    2.918376] sp : ffffffc0803139c0
> [    2.921725] x29: ffffffc0803139e0 x28: ffffff8040bbef50 x27: ffffff80410c0f40
> [    2.928953] x26: ffffffd7055d9e28 x25: ffffffc0801e0008 x24: 0000000000001000
> [    2.936179] x23: ffffff80410c1080 x22: 000000000000000a x21: ffffff80410c0f00
> [    2.943405] x20: 000000000000000c x19: ffffffc0801e0000 x18: ffffffc08030d0a0
> [    2.950632] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [    2.957858] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [    2.965085] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
> [    2.972311] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
> [    2.979537] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [    2.986764] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
> [    2.993992] Call trace:
> [    2.996458]  rpi_firmware_property_list+0x21c/0x29c (P)
> [    3.001747]  rpi_firmware_property+0x70/0xd8
> [    3.006064]  vc4_drm_bind+0x12c/0x378
> [    3.009765]  try_to_bring_up_aggregate_device+0x22c/0x308
> [    3.015230]  __component_add+0xec/0x224
> [    3.019106]  component_add+0x14/0x30
> [    3.022720]  vc4_hdmi_dev_probe+0x1c/0x40
> [    3.026773]  platform_probe+0x68/0xf0
> [    3.030474]  really_probe+0xc0/0x3ac
> [    3.034088]  __driver_probe_device+0x7c/0x174
> [    3.038495]  driver_probe_device+0x40/0x100
> [    3.042725]  __device_attach_driver+0x10c/0x1e0
> [    3.047308]  bus_for_each_drv+0x88/0x100
> [    3.051273]  __device_attach+0xa0/0x1c8
> [    3.055151]  device_initial_probe+0x14/0x30
> [    3.059381]  bus_probe_device+0xc8/0xcc
> [    3.063259]  deferred_probe_work_func+0xb8/0x12c
> [    3.067930]  process_one_work+0x160/0x2d4
> [    3.071983]  worker_thread+0x2d8/0x400
> [    3.075773]  kthread+0x12c/0x208
> [    3.079034]  ret_from_fork+0x10/0x20
> [    3.082647] ---[ end trace 0000000000000000 ]---
>
> Raising the timeout to 3 seconds (ought to be enough®) doesn't trigger
> timeouts anymore for me and proceeds to the next failure.
>
> Signed-off-by: Etienne Buira <etienne.buira@free.fr>
> ---
>   drivers/firmware/raspberrypi.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 7ecde6921a0a..e3c998def0e1 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -58,7 +58,7 @@ rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
>   	reinit_completion(&fw->c);
>   	ret = mbox_send_message(fw->chan, &message);
>   	if (ret >= 0) {
> -		if (wait_for_completion_timeout(&fw->c, HZ)) {
> +		if (wait_for_completion_timeout(&fw->c, 3*HZ)) {
generally i'm fine with this change, but could you please add spaces 
around the operator? This should better align to the coding style.

Out of curiosity and because i never saw this issue, could you please 
provide more details?
There is nothing connected to HDMI 0 & 1 ?
Which firmware version are you running?
Do you use a special configuration?

Best regards
>   			ret = 0;
>   		} else {
>   			ret = -ETIMEDOUT;

On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
> Hi Etienne,
> 
> Am 12.05.25 um 18:30 schrieb Etienne Buira:
../..
> Out of curiosity and because i never saw this issue, could you please 
> provide more details?
> There is nothing connected to HDMI 0 & 1 ?
> Which firmware version are you running?
> Do you use a special configuration?

Hi Stefan

There is nothing very special, hdmi0 is connected to a monitor, there's
a (independantly powered) hdd on usb3, keyboard/mouse on usb2 ports, a
Gb network wire, UART, and nothing else.

The afore-mentioned next failure is also about graphic stack (hdmi
signal is lost as soon as VC4 driver loads), i seeked for help here:
https://lists.freedesktop.org/archives/dri-devel/2025-May/505475.html
(btw, if you have a hint...).

Regards.

Hi Etienne,

Am 15.05.25 um 08:41 schrieb Etienne Buira:
> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
>> Hi Etienne,
>>
>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
> ../..
>> Out of curiosity and because i never saw this issue, could you please
>> provide more details?
>> There is nothing connected to HDMI 0 & 1 ?
>> Which firmware version are you running?
Please provide the dmesg output, so we can extract the firmware version.
>> Do you use a special configuration?
In this case, i meant the kernel configuration. Do you use 
arm64/defconfig or arm/multi_v7_lpae_defconfig or a custom one?

Do you use U-Boot or not?
> Hi Stefan
>
> There is nothing very special, hdmi0 is connected to a monitor, there's
Did you tried to connect a different monitor? Does the timeout still occurs?

Best regards
> a (independantly powered) hdd on usb3, keyboard/mouse on usb2 ports, a
> Gb network wire, UART, and nothing else.
>
> The afore-mentioned next failure is also about graphic stack (hdmi
> signal is lost as soon as VC4 driver loads), i seeked for help here:
> https://lists.freedesktop.org/archives/dri-devel/2025-May/505475.html
> (btw, if you have a hint...).
>
> Regards.
>

Hi Stefan, and thank you for your interest.

On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
> Hi Etienne,
> 
> Am 15.05.25 um 08:41 schrieb Etienne Buira:
> > On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
> >> Hi Etienne,
> >>
> >> Am 12.05.25 um 18:30 schrieb Etienne Buira:
> > ../..
> >> Out of curiosity and because i never saw this issue, could you please
> >> provide more details?
> >> There is nothing connected to HDMI 0 & 1 ?
> >> Which firmware version are you running?
> Please provide the dmesg output, so we can extract the firmware version.

Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
dmesg, as long as a patch of extra traces used.
I did not specifically test other firmware versions for the timeout
issue (but i did for video output).

> >> Do you use a special configuration?
> In this case, i meant the kernel configuration. Do you use 
> arm64/defconfig or arm/multi_v7_lpae_defconfig or a custom one?

I use a custom one, attached.

> Do you use U-Boot or not?

No, i only use raspberry firmware/loader.

> > Hi Stefan
> >
> > There is nothing very special, hdmi0 is connected to a monitor, there's
> Did you tried to connect a different monitor? Does the timeout still occurs?

Just tried another monitor, and yes, timeout occurs without the patch.
Both monitors showed something when driven by firmware and
simple-framebuffer.

Regards.

> 
> Best regards
> > a (independantly powered) hdd on usb3, keyboard/mouse on usb2 ports, a
> > Gb network wire, UART, and nothing else.
> >
> > The afore-mentioned next failure is also about graphic stack (hdmi
> > signal is lost as soon as VC4 driver loads), i seeked for help here:
> > https://lists.freedesktop.org/archives/dri-devel/2025-May/505475.html
> > (btw, if you have a hint...).
> >
> > Regards.
> >
> 
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 36a54d456630..f9eb851f72bc 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -6,3 +6,6 @@ obj-y			+= host1x/ drm/ vga/
 obj-$(CONFIG_IMX_IPUV3_CORE)	+= ipu-v3/
 obj-$(CONFIG_TRACE_GPU_MEM)		+= trace/
 obj-$(CONFIG_NOVA_CORE)		+= nova-core/
+
+subdir-ccflags-y += -DDEBUG
+
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 13bc4c290b17..cc3bc4b78770 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1906,8 +1906,12 @@ static void edid_block_status_print(enum edid_block_status status,
 				    const struct edid *block,
 				    int block_num)
 {
+	pr_info("EDID: block_status_print, backtrace:");
+	dump_stack();
+
 	switch (status) {
 	case EDID_BLOCK_OK:
+		pr_debug("EDID block %d read ok\n", block_num);
 		break;
 	case EDID_BLOCK_READ_FAIL:
 		pr_debug("EDID block %d read failed\n", block_num);
@@ -3576,6 +3580,7 @@ static struct drm_display_mode *drm_mode_detailed(struct drm_connector *connecto
 
 	mode->type = DRM_MODE_TYPE_DRIVER;
 	drm_mode_set_name(mode);
+	drm_dbg_kms(dev, "EDID: added mode %s\n", mode->name);
 
 	return mode;
 }
@@ -3931,6 +3936,8 @@ static int add_established_modes(struct drm_connector *connector,
 		drm_for_each_detailed_block(drm_edid, do_established_modes,
 					    &closure);
 
+	drm_dbg_kms(dev, "EDID: established %d modes\n", modes + closure.modes);
+
 	return modes + closure.modes;
 }
 
@@ -3987,6 +3994,7 @@ static int add_standard_modes(struct drm_connector *connector,
 					    &closure);
 
 	/* XXX should also look for standard codes in VTB blocks */
+	drm_dbg_kms(connector->dev, "EDID: added %d standard modes\n", modes + closure.modes);
 
 	return modes + closure.modes;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index c7cb1e3a6434..804660d05146 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -361,8 +361,10 @@ static int vc4_drm_bind(struct device *dev)
 	}
 
 	ret = aperture_remove_all_conflicting_devices(driver->name);
-	if (ret)
+	if (ret) {
+		drm_warn(drm, "Error during aperture_remove_all_conflicting_devices\n");
 		goto err;
+	}
 
 	if (firmware) {
 		ret = rpi_firmware_property(firmware,
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f5642b3038e4..5f2d30a349ae 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3771,6 +3771,9 @@ static int do_bind_con_driver(const struct consw *csw, int first, int last,
 	struct con_driver *con_driver;
 	int i, j = -1, k = -1, retval = -ENODEV;
 
+	pr_info("Console: do_bind_con_driver, backtrace:");
+	dump_stack();
+
 	if (!try_module_get(owner))
 		return -ENODEV;
 

Am 15.05.25 um 11:44 schrieb Etienne Buira:
> Hi Stefan, and thank you for your interest.
>
> On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
>> Hi Etienne,
>>
>> Am 15.05.25 um 08:41 schrieb Etienne Buira:
>>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
>>>> Hi Etienne,
>>>>
>>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
>>> ../..
>>>> Out of curiosity and because i never saw this issue, could you please
>>>> provide more details?
>>>> There is nothing connected to HDMI 0 & 1 ?
>>>> Which firmware version are you running?
>> Please provide the dmesg output, so we can extract the firmware version.
> Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
> dmesg, as long as a patch of extra traces used.
> I did not specifically test other firmware versions for the timeout
> issue (but i did for video output).
Thanks, i'll try to reproduce.

Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?

On Thu, May 15, 2025 at 12:31:38PM +0200, Stefan Wahren wrote:
> Am 15.05.25 um 11:44 schrieb Etienne Buira:
> > Hi Stefan, and thank you for your interest.
> >
> > On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
> >> Hi Etienne,
> >>
> >> Am 15.05.25 um 08:41 schrieb Etienne Buira:
> >>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
> >>>> Hi Etienne,
> >>>>
> >>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
> >>> ../..
> >>>> Out of curiosity and because i never saw this issue, could you please
> >>>> provide more details?
> >>>> There is nothing connected to HDMI 0 & 1 ?
> >>>> Which firmware version are you running?
> >> Please provide the dmesg output, so we can extract the firmware version.
> > Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
> > dmesg, as long as a patch of extra traces used.
> > I did not specifically test other firmware versions for the timeout
> > issue (but i did for video output).
> Thanks, i'll try to reproduce.
> 
> Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?

Just reproduced with pristine 6.12.28.

Hi Etienne,

Am 15.05.25 um 13:48 schrieb Etienne Buira:
> On Thu, May 15, 2025 at 12:31:38PM +0200, Stefan Wahren wrote:
>> Am 15.05.25 um 11:44 schrieb Etienne Buira:
>>> Hi Stefan, and thank you for your interest.
>>>
>>> On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
>>>> Hi Etienne,
>>>>
>>>> Am 15.05.25 um 08:41 schrieb Etienne Buira:
>>>>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
>>>>>> Hi Etienne,
>>>>>>
>>>>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
>>>>> ../..
>>>>>> Out of curiosity and because i never saw this issue, could you please
>>>>>> provide more details?
>>>>>> There is nothing connected to HDMI 0 & 1 ?
>>>>>> Which firmware version are you running?
>>>> Please provide the dmesg output, so we can extract the firmware version.
>>> Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
>>> dmesg, as long as a patch of extra traces used.
>>> I did not specifically test other firmware versions for the timeout
>>> issue (but i did for video output).
>> Thanks, i'll try to reproduce.
>>
>> Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?
> Just reproduced with pristine 6.12.28.
>
okay, i've update the firmware on my older Raspberry Pi 4 to the same 
version as yours. But even with your configuration i don't see this kind 
of fallout. So I think we shouldn't apply this patch until we really 
know what's going on.

You don't have another Raspberry Pi 4 by any chance?
Another cause might be the toolchain. Currently I use a not so fresh gcc 
11.3.1 from Linaro.

Except of this, I noticed that your configuration doesn't enable 
DWC2_DUAL_ROLE and the LEDS_TRIGGER.

Best regards

Hi Stefan

On Thu, May 15, 2025 at 07:48:04PM +0200, Stefan Wahren wrote:
> Hi Etienne,
> 
> Am 15.05.25 um 13:48 schrieb Etienne Buira:
> > On Thu, May 15, 2025 at 12:31:38PM +0200, Stefan Wahren wrote:
> >> Am 15.05.25 um 11:44 schrieb Etienne Buira:
> >>> Hi Stefan, and thank you for your interest.
> >>>
> >>> On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
> >>>> Hi Etienne,
> >>>>
> >>>> Am 15.05.25 um 08:41 schrieb Etienne Buira:
> >>>>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
> >>>>>> Hi Etienne,
> >>>>>>
> >>>>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
> >>>>> ../..
> >>>>>> Out of curiosity and because i never saw this issue, could you please
> >>>>>> provide more details?
> >>>>>> There is nothing connected to HDMI 0 & 1 ?
> >>>>>> Which firmware version are you running?
> >>>> Please provide the dmesg output, so we can extract the firmware version.
> >>> Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
> >>> dmesg, as long as a patch of extra traces used.
> >>> I did not specifically test other firmware versions for the timeout
> >>> issue (but i did for video output).
> >> Thanks, i'll try to reproduce.
> >>
> >> Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?
> > Just reproduced with pristine 6.12.28.
> >
> okay, i've update the firmware on my older Raspberry Pi 4 to the same 
> version as yours. But even with your configuration i don't see this kind 
> of fallout. So I think we shouldn't apply this patch until we really 
> know what's going on.

Ok, thank you, did you make sure a powered hdmi sink were connected? I
noticed there is no timeout if no hdmi is plugged (but there were when
monitor were powered off, maybe specific to my monitor).

> You don't have another Raspberry Pi 4 by any chance?

No, i don't.

> Another cause might be the toolchain. Currently I use a not so fresh gcc 
> 11.3.1 from Linaro.

Previous tries were cross built. I tried a native build with (Gentoo
packages) gcc 14.2.1_p20241221, binutils 2.44, and glibc 2.40-r8; but
got same result.
Will do a software upgrade overnight to try with more up to date build
system.

> Except of this, I noticed that your configuration doesn't enable 
> DWC2_DUAL_ROLE and the LEDS_TRIGGER.

I have no use of them (and i have a lot of things to disable, but i
prefer to do that starting with a working system).

Regards.

Am 16.05.25 um 00:27 schrieb Etienne Buira:
> Hi Stefan
>
> On Thu, May 15, 2025 at 07:48:04PM +0200, Stefan Wahren wrote:
>> Hi Etienne,
>>
>> Am 15.05.25 um 13:48 schrieb Etienne Buira:
>>> On Thu, May 15, 2025 at 12:31:38PM +0200, Stefan Wahren wrote:
>>>> Am 15.05.25 um 11:44 schrieb Etienne Buira:
>>>>> Hi Stefan, and thank you for your interest.
>>>>>
>>>>> On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
>>>>>> Hi Etienne,
>>>>>>
>>>>>> Am 15.05.25 um 08:41 schrieb Etienne Buira:
>>>>>>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
>>>>>>>> Hi Etienne,
>>>>>>>>
>>>>>>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
>>>>>>> ../..
>>>>>>>> Out of curiosity and because i never saw this issue, could you please
>>>>>>>> provide more details?
>>>>>>>> There is nothing connected to HDMI 0 & 1 ?
>>>>>>>> Which firmware version are you running?
>>>>>> Please provide the dmesg output, so we can extract the firmware version.
>>>>> Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
>>>>> dmesg, as long as a patch of extra traces used.
>>>>> I did not specifically test other firmware versions for the timeout
>>>>> issue (but i did for video output).
>>>> Thanks, i'll try to reproduce.
>>>>
>>>> Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?
>>> Just reproduced with pristine 6.12.28.
>>>
>> okay, i've update the firmware on my older Raspberry Pi 4 to the same
>> version as yours. But even with your configuration i don't see this kind
>> of fallout. So I think we shouldn't apply this patch until we really
>> know what's going on.
> Ok, thank you, did you make sure a powered hdmi sink were connected? I
> noticed there is no timeout if no hdmi is plugged (but there were when
> monitor were powered off, maybe specific to my monitor).
Yes, HDMI monitor was connected to HDMI 0 and powered on. Raspberry Pi 
OS started as expected.

The fact that your SDIO interface triggers a warning, which I also don't 
get let me think this is not just related to HDMI interface.

[    3.603736] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[    3.603739] mmc0: sdhci: Sys addr:  0x00000000 | Version: 0x00009902
[    3.646852] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt: 0x00000000
[    3.646856] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
[    3.646859] mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x00000000
[    3.665697] mmc0: sdhci: Power:     0x0000000f | Blk gap: 0x00000000
[    3.672214] mmc0: sdhci: Wake-up:   0x00000000 | Clock: 0x00003947
[    3.678736] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[    3.685254] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
[    3.685257] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[    3.685260] mmc0: sdhci: Caps:      0x00000000 | Caps_1: 0x00000000
[    3.712672] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000001
[    3.719186] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]: 0x00000000
[    3.725708] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]: 0x00000000
[    3.732230] mmc0: sdhci: Host ctl2: 0x00000000
[    3.736724] mmc0: sdhci: ============================================
[    3.819205] mmc0: new high speed SDIO card at address 0001
>
>> You don't have another Raspberry Pi 4 by any chance?
> No, i don't.
>
>> Another cause might be the toolchain. Currently I use a not so fresh gcc
>> 11.3.1 from Linaro.
> Previous tries were cross built. I tried a native build with (Gentoo
> packages) gcc 14.2.1_p20241221, binutils 2.44, and glibc 2.40-r8; but
> got same result.
> Will do a software upgrade overnight to try with more up to date build
> system.
I will try to update my toolchain, but this will take some time.
>
>> Except of this, I noticed that your configuration doesn't enable
>> DWC2_DUAL_ROLE and the LEDS_TRIGGER.
> I have no use of them (and i have a lot of things to disable, but i
> prefer to do that starting with a working system).
I this case you can disable DWC2 completely, because USB host is 
provided by xhci driver. LEDS_TRIGGER is used for the ACT LED as heartbeat.
>
> Regards.
>

On Fri, May 16, 2025 at 01:17:41PM +0200, Stefan Wahren wrote:
> Am 16.05.25 um 00:27 schrieb Etienne Buira:
> > Hi Stefan
> >
> > On Thu, May 15, 2025 at 07:48:04PM +0200, Stefan Wahren wrote:
> >> Hi Etienne,
> >>
> >> Am 15.05.25 um 13:48 schrieb Etienne Buira:
> >>> On Thu, May 15, 2025 at 12:31:38PM +0200, Stefan Wahren wrote:
> >>>> Am 15.05.25 um 11:44 schrieb Etienne Buira:
> >>>>> Hi Stefan, and thank you for your interest.
> >>>>>
> >>>>> On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
> >>>>>> Hi Etienne,
> >>>>>>
> >>>>>> Am 15.05.25 um 08:41 schrieb Etienne Buira:
> >>>>>>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
> >>>>>>>> Hi Etienne,
> >>>>>>>>
> >>>>>>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
> >>>>>>> ../..
> >>>>>>>> Out of curiosity and because i never saw this issue, could you please
> >>>>>>>> provide more details?
> >>>>>>>> There is nothing connected to HDMI 0 & 1 ?
> >>>>>>>> Which firmware version are you running?
> >>>>>> Please provide the dmesg output, so we can extract the firmware version.
> >>>>> Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
> >>>>> dmesg, as long as a patch of extra traces used.
> >>>>> I did not specifically test other firmware versions for the timeout
> >>>>> issue (but i did for video output).
> >>>> Thanks, i'll try to reproduce.
> >>>>
> >>>> Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?
> >>> Just reproduced with pristine 6.12.28.
> >>>
> >> okay, i've update the firmware on my older Raspberry Pi 4 to the same
> >> version as yours. But even with your configuration i don't see this kind
> >> of fallout. So I think we shouldn't apply this patch until we really
> >> know what's going on.
> > Ok, thank you, did you make sure a powered hdmi sink were connected? I
> > noticed there is no timeout if no hdmi is plugged (but there were when
> > monitor were powered off, maybe specific to my monitor).
> Yes, HDMI monitor was connected to HDMI 0 and powered on. Raspberry Pi 
> OS started as expected.
> 
> The fact that your SDIO interface triggers a warning, which I also don't 
> get let me think this is not just related to HDMI interface.
> 
> [    3.603736] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [    3.603739] mmc0: sdhci: Sys addr:  0x00000000 | Version: 0x00009902
> [    3.646852] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt: 0x00000000
> [    3.646856] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
> [    3.646859] mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x00000000
> [    3.665697] mmc0: sdhci: Power:     0x0000000f | Blk gap: 0x00000000
> [    3.672214] mmc0: sdhci: Wake-up:   0x00000000 | Clock: 0x00003947
> [    3.678736] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
> [    3.685254] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
> [    3.685257] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
> [    3.685260] mmc0: sdhci: Caps:      0x00000000 | Caps_1: 0x00000000
> [    3.712672] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000001
> [    3.719186] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]: 0x00000000
> [    3.725708] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]: 0x00000000
> [    3.732230] mmc0: sdhci: Host ctl2: 0x00000000
> [    3.736724] mmc0: sdhci: ============================================
> [    3.819205] mmc0: new high speed SDIO card at address 0001
Hi Stefan

I think this warning is because there is nothing in SD slot (i boot from
usb).
> >
> >> You don't have another Raspberry Pi 4 by any chance?
> > No, i don't.
> >
> >> Another cause might be the toolchain. Currently I use a not so fresh gcc
> >> 11.3.1 from Linaro.
> > Previous tries were cross built. I tried a native build with (Gentoo
> > packages) gcc 14.2.1_p20241221, binutils 2.44, and glibc 2.40-r8; but
> > got same result.
> > Will do a software upgrade overnight to try with more up to date build
> > system.
> I will try to update my toolchain, but this will take some time.
Ok, thank you.
I updated the whole thing, but no change in toolchain versions. I'm
trying to get a gcc11 based one.
> >
> >> Except of this, I noticed that your configuration doesn't enable
> >> DWC2_DUAL_ROLE and the LEDS_TRIGGER.
> > I have no use of them (and i have a lot of things to disable, but i
> > prefer to do that starting with a working system).
> I this case you can disable DWC2 completely, because USB host is 
> provided by xhci driver. LEDS_TRIGGER is used for the ACT LED as heartbeat.
Ok, thank you.

Regards.

Raspberry firmware driver expected said firmware to answer by 1 second.
That seems to work fine for most cases, but with
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE, that IIUC may need to reconfigure a
monitor, i end up reliably having timeouts:
[    2.861407] ------------[ cut here ]------------
[    2.865512] Firmware transaction 0x00030066 timeout
[    2.865549] WARNING: CPU: 3 PID: 42 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x21c/0x29c
[    2.880751] CPU: 3 UID: 0 PID: 42 Comm: kworker/u16:1 Not tainted 6.15.0-rc6 #1 PREEMPT
[    2.888944] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[    2.894848] Workqueue: events_unbound deferred_probe_work_func
[    2.900752] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    2.907801] pc : rpi_firmware_property_list+0x21c/0x29c
[    2.913089] lr : rpi_firmware_property_list+0x21c/0x29c
[    2.918376] sp : ffffffc0803139c0
[    2.921725] x29: ffffffc0803139e0 x28: ffffff8040bbef50 x27: ffffff80410c0f40
[    2.928953] x26: ffffffd7055d9e28 x25: ffffffc0801e0008 x24: 0000000000001000
[    2.936179] x23: ffffff80410c1080 x22: 000000000000000a x21: ffffff80410c0f00
[    2.943405] x20: 000000000000000c x19: ffffffc0801e0000 x18: ffffffc08030d0a0
[    2.950632] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[    2.957858] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[    2.965085] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[    2.972311] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[    2.979537] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[    2.986764] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[    2.993992] Call trace:
[    2.996458]  rpi_firmware_property_list+0x21c/0x29c (P)
[    3.001747]  rpi_firmware_property+0x70/0xd8
[    3.006064]  vc4_drm_bind+0x12c/0x378
[    3.009765]  try_to_bring_up_aggregate_device+0x22c/0x308
[    3.015230]  __component_add+0xec/0x224
[    3.019106]  component_add+0x14/0x30
[    3.022720]  vc4_hdmi_dev_probe+0x1c/0x40
[    3.026773]  platform_probe+0x68/0xf0
[    3.030474]  really_probe+0xc0/0x3ac
[    3.034088]  __driver_probe_device+0x7c/0x174
[    3.038495]  driver_probe_device+0x40/0x100
[    3.042725]  __device_attach_driver+0x10c/0x1e0
[    3.047308]  bus_for_each_drv+0x88/0x100
[    3.051273]  __device_attach+0xa0/0x1c8
[    3.055151]  device_initial_probe+0x14/0x30
[    3.059381]  bus_probe_device+0xc8/0xcc
[    3.063259]  deferred_probe_work_func+0xb8/0x12c
[    3.067930]  process_one_work+0x160/0x2d4
[    3.071983]  worker_thread+0x2d8/0x400
[    3.075773]  kthread+0x12c/0x208
[    3.079034]  ret_from_fork+0x10/0x20
[    3.082647] ---[ end trace 0000000000000000 ]---

Raising the timeout to 3 seconds (ought to be enough®) doesn't trigger
timeouts anymore for me and proceeds to the next failure.

Signed-off-by: Etienne Buira <etienne.buira@free.fr>
---
 drivers/firmware/raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 7ecde6921a0a..8c45a152e3ba 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -58,7 +58,7 @@ rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
 	reinit_completion(&fw->c);
 	ret = mbox_send_message(fw->chan, &message);
 	if (ret >= 0) {
-		if (wait_for_completion_timeout(&fw->c, HZ)) {
+		if (wait_for_completion_timeout(&fw->c, 3 * HZ)) {
 			ret = 0;
 		} else {
 			ret = -ETIMEDOUT;
-- 
2.48.1

Hi Etienne,

please always increase the version of your patch, in case you change 
something.

Am 15.05.25 um 08:34 schrieb Etienne Buira:
> Raspberry firmware driver expected said firmware to answer by 1 second.
> That seems to work fine for most cases, but with
> RPI_FIRMWARE_NOTIFY_DISPLAY_DONE, that IIUC may need to reconfigure a
> monitor, i end up reliably having timeouts:
> [    2.861407] ------------[ cut here ]------------
> [    2.865512] Firmware transaction 0x00030066 timeout
I think we can strip down the trace to this line.
> [    2.865549] WARNING: CPU: 3 PID: 42 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x21c/0x29c
> [    2.880751] CPU: 3 UID: 0 PID: 42 Comm: kworker/u16:1 Not tainted 6.15.0-rc6 #1 PREEMPT
> [    2.888944] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
> [    2.894848] Workqueue: events_unbound deferred_probe_work_func
> [    2.900752] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    2.907801] pc : rpi_firmware_property_list+0x21c/0x29c
> [    2.913089] lr : rpi_firmware_property_list+0x21c/0x29c
> [    2.918376] sp : ffffffc0803139c0
> [    2.921725] x29: ffffffc0803139e0 x28: ffffff8040bbef50 x27: ffffff80410c0f40
> [    2.928953] x26: ffffffd7055d9e28 x25: ffffffc0801e0008 x24: 0000000000001000
> [    2.936179] x23: ffffff80410c1080 x22: 000000000000000a x21: ffffff80410c0f00
> [    2.943405] x20: 000000000000000c x19: ffffffc0801e0000 x18: ffffffc08030d0a0
> [    2.950632] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [    2.957858] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [    2.965085] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
> [    2.972311] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
> [    2.979537] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [    2.986764] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
> [    2.993992] Call trace:
> [    2.996458]  rpi_firmware_property_list+0x21c/0x29c (P)
> [    3.001747]  rpi_firmware_property+0x70/0xd8
> [    3.006064]  vc4_drm_bind+0x12c/0x378
> [    3.009765]  try_to_bring_up_aggregate_device+0x22c/0x308
> [    3.015230]  __component_add+0xec/0x224
> [    3.019106]  component_add+0x14/0x30
> [    3.022720]  vc4_hdmi_dev_probe+0x1c/0x40
> [    3.026773]  platform_probe+0x68/0xf0
> [    3.030474]  really_probe+0xc0/0x3ac
> [    3.034088]  __driver_probe_device+0x7c/0x174
> [    3.038495]  driver_probe_device+0x40/0x100
> [    3.042725]  __device_attach_driver+0x10c/0x1e0
> [    3.047308]  bus_for_each_drv+0x88/0x100
> [    3.051273]  __device_attach+0xa0/0x1c8
> [    3.055151]  device_initial_probe+0x14/0x30
> [    3.059381]  bus_probe_device+0xc8/0xcc
> [    3.063259]  deferred_probe_work_func+0xb8/0x12c
> [    3.067930]  process_one_work+0x160/0x2d4
> [    3.071983]  worker_thread+0x2d8/0x400
> [    3.075773]  kthread+0x12c/0x208
> [    3.079034]  ret_from_fork+0x10/0x20
> [    3.082647] ---[ end trace 0000000000000000 ]---
>
> Raising the timeout to 3 seconds (ought to be enough®) doesn't trigger
> timeouts anymore for me and proceeds to the next failure.
Based on the recent findings, please provide more context in the commit 
message and add a link to the firmware issue:

Link: https://github.com/raspberrypi/firmware/issues/1970
> Signed-off-by: Etienne Buira <etienne.buira@free.fr>
> ---
Please add the patch change log here as documented in

https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>   drivers/firmware/raspberrypi.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 7ecde6921a0a..8c45a152e3ba 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -58,7 +58,7 @@ rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
>   	reinit_completion(&fw->c);
>   	ret = mbox_send_message(fw->chan, &message);
>   	if (ret >= 0) {
> -		if (wait_for_completion_timeout(&fw->c, HZ)) {
> +		if (wait_for_completion_timeout(&fw->c, 3 * HZ)) {
>   			ret = 0;
>   		} else {
>   			ret = -ETIMEDOUT;

Raspberry firmware driver expected said firmware to answer by 1 second.
However, some firmware versions are buggy and can take longer with
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE.
[    2.861407] ------------[ cut here ]------------
[    2.865512] Firmware transaction 0x00030066 timeout

Raising the timeout to 3 seconds (ought to be enough®) doesn't trigger
timeouts anymore for me and proceeds to the next failure.

Some details about firmware debugging are available here:
Link: https://github.com/raspberrypi/firmware/issues/1970

Signed-off-by: Etienne Buira <etienne.buira@free.fr>

---
v2: coding style
v3: commit message

Stefan, feel free to edit to your liking if needed, or even take
ownership of such one-liner, that would not be stealing.

 drivers/firmware/raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 7ecde6921a0a..8c45a152e3ba 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -58,7 +58,7 @@ rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
 	reinit_completion(&fw->c);
 	ret = mbox_send_message(fw->chan, &message);
 	if (ret >= 0) {
-		if (wait_for_completion_timeout(&fw->c, HZ)) {
+		if (wait_for_completion_timeout(&fw->c, 3 * HZ)) {
 			ret = 0;
 		} else {
 			ret = -ETIMEDOUT;
-- 
2.48.1

Am 21.05.25 um 12:04 schrieb Etienne Buira:
> Raspberry firmware driver expected said firmware to answer by 1 second.
> However, some firmware versions are buggy and can take longer with
> RPI_FIRMWARE_NOTIFY_DISPLAY_DONE.
> [    2.861407] ------------[ cut here ]------------
> [    2.865512] Firmware transaction 0x00030066 timeout
>
> Raising the timeout to 3 seconds (ought to be enough®) doesn't trigger
> timeouts anymore for me and proceeds to the next failure.
>
> Some details about firmware debugging are available here:
> Link: https://github.com/raspberrypi/firmware/issues/1970
>
> Signed-off-by: Etienne Buira <etienne.buira@free.fr>
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>

Thanks
>
> ---
> v2: coding style
> v3: commit message
>
> Stefan, feel free to edit to your liking if needed, or even take
> ownership of such one-liner, that would not be stealing.
>
>   drivers/firmware/raspberrypi.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 7ecde6921a0a..8c45a152e3ba 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -58,7 +58,7 @@ rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
>   	reinit_completion(&fw->c);
>   	ret = mbox_send_message(fw->chan, &message);
>   	if (ret >= 0) {
> -		if (wait_for_completion_timeout(&fw->c, HZ)) {
> +		if (wait_for_completion_timeout(&fw->c, 3 * HZ)) {
>   			ret = 0;
>   		} else {
>   			ret = -ETIMEDOUT;