From: Etienne Buira <etienne.buira@free.fr>
To: Stefan Wahren <wahrenst@gmx.net>
Cc: "Florian Fainelli" <florian.fainelli@broadcom.com>,
bcm-kernel-feedback-list@broadcom.com,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
"Etienne Buira" <etienne.buira@free.fr>,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] firmware/raspberrypi: raise timeout to 3s
Date: Thu, 15 May 2025 09:44:23 +0000 [thread overview]
Message-ID: <aCW3d7tc27Awj62K@Z926fQmE5jqhFMgp6> (raw)
In-Reply-To: <ffeb860f-5522-4130-ae47-45a6068b17ea@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
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.
> >
>
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 36657 bytes --]
[-- Attachment #3: extra_traces.patch --]
[-- Type: text/plain, Size: 2708 bytes --]
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;
[-- Attachment #4: dmesg.gz --]
[-- Type: application/gzip, Size: 10383 bytes --]
next prev parent reply other threads:[~2025-05-15 10:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 16:30 [PATCH] firmware/raspberrypi: raise timeout to 3s Etienne Buira
2025-05-14 16:20 ` Stefan Wahren
2025-05-15 6:34 ` Etienne Buira
2025-05-21 8:55 ` Stefan Wahren
2025-05-21 10:04 ` [PATCH v3] " Etienne Buira
2025-05-21 13:05 ` Stefan Wahren
2025-05-15 6:41 ` [PATCH] " Etienne Buira
2025-05-15 7:42 ` Stefan Wahren
2025-05-15 9:44 ` Etienne Buira [this message]
2025-05-15 10:31 ` Stefan Wahren
2025-05-15 11:48 ` Etienne Buira
2025-05-15 17:48 ` Stefan Wahren
2025-05-15 22:27 ` Etienne Buira
2025-05-16 11:17 ` Stefan Wahren
2025-05-16 14:41 ` Searching for firmware timeout cause (was: [PATCH] firmware/raspberrypi: raise timeout to 3s) Etienne Buira
2025-05-16 15:20 ` Searching for firmware timeout cause Stefan Wahren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aCW3d7tc27Awj62K@Z926fQmE5jqhFMgp6 \
--to=etienne.buira@free.fr \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=florian.fainelli@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=u.kleine-koenig@baylibre.com \
--cc=wahrenst@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox