Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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