From: Maxime Ripard <mripard@kernel.org>
To: "Màxim Pedraza Padilla" <maximpedraza@gmail.com>
Cc: "Helge Deller" <deller@gmx.de>,
"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de
Subject: Re: [RFC PATCH 0/6] Boot logo supplied by the device tree
Date: Wed, 12 Aug 2026 09:42:35 +0200 [thread overview]
Message-ID: <20260812-neon-asp-of-completion-e9349e@houat> (raw)
In-Reply-To: <CAEUXW=GuHypVE5Xre8AQBmkrcUbPQxh03Lq8os=kjcLeGahOgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]
On Wed, Aug 12, 2026 at 02:31:52AM +0200, Màxim Pedraza Padilla wrote:
> El lun, 10 ago 2026 a las 11:02, Maxime Ripard (<mripard@kernel.org>) escribió:
> > If the sole reason for this series is to keep having something on the
> > display while the kernel boots until DRM catches up, then you probably
> > want to check [drm state readout]
>
> Thanks, I had missed it. I read it and then measured, having earlier
> claimed in this thread that our hardware kept no state worth reading. That
> was wrong.
>
> Dumping the LCDC registers at the top of tilcdc's probe, before the driver
> touches anything:
>
> RASTER_CTRL=00280081 FB=9df13cc0..9dfcf4bc
>
> LCD_EN is set and the scanout address is exactly the framebuffer U-Boot
> reported, still holding the image. So readout would have something real to
> adopt here. tilcdc is not one of the drivers you implement, but that is
> work rather than a disagreement.
>
> One observation that may be worth your time. Pointing a simple-framebuffer
> node at that same memory, same device tree, only the driver differing:
>
> simplefb the image is still there afterwards
> simpledrm the buffer reads back as all zeros
>
> So where the CRTC is still scanning the bootloader's buffer, simpledrm
> wipes the image it was meant to carry over. I have not chased down the call
> that clears it.
>
> What readout cannot cover is having no firmware splash to read. U-Boot's
> Falcon mode boots the kernel from SPL and skips U-Boot proper, where
> display init lives, so there is no image and no programmed CRTC to inherit
> -- and Falcon mode exists to shorten boot time, which is the same reason
> one cares about the logo appearing early.
In such a case, you can (and really should) use KMS, and you should use
an initramfs and setup the splash screen there. There's no need for the
kernel to do that work.
It's still significantly different from your earlier claim, since there
would be no gap between uboot and DRM, and no blanking either.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
next prev parent reply other threads:[~2026-08-12 7:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 21:50 [RFC PATCH 0/6] Boot logo supplied by the device tree Max Pedraza
2026-07-31 21:50 ` [RFC PATCH 1/6] dt-bindings: display: add a device tree supplied boot logo Max Pedraza
2026-07-31 21:50 ` [RFC PATCH 2/6] video: logo: allow the boot logo to come from the device tree Max Pedraza
2026-07-31 21:50 ` [RFC PATCH 3/6] fbdev: honour the device tree boot logo placement properties Max Pedraza
2026-07-31 21:50 ` [RFC PATCH 4/6] dt-bindings: display: allow the boot logo in a reserved memory region Max Pedraza
2026-07-31 21:50 ` [RFC PATCH 5/6] video: logo: allow the boot logo to come from " Max Pedraza
2026-07-31 21:50 ` [RFC PATCH 6/6] video: logo: add ppmtodtlogo host tool Max Pedraza
2026-08-01 8:08 ` [RFC PATCH 0/6] Boot logo supplied by the device tree Uwe Kleine-König
2026-08-01 20:44 ` Helge Deller
2026-08-01 22:01 ` Màxim Pedraza Padilla
2026-08-02 13:35 ` Uwe Kleine-König
2026-08-02 22:56 ` Màxim Pedraza Padilla
2026-08-10 9:02 ` Maxime Ripard
2026-08-12 0:31 ` Màxim Pedraza Padilla
2026-08-12 7:42 ` Maxime Ripard [this message]
2026-08-03 12:39 ` Ulrich Ölmann
2026-08-03 22:04 ` Màxim Pedraza Padilla
2026-08-04 5:25 ` Ulrich Ölmann
2026-08-04 15:59 ` Màxim Pedraza Padilla
2026-08-04 13:58 ` Geert Uytterhoeven
2026-08-04 22:37 ` Màxim Pedraza Padilla
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=20260812-neon-asp-of-completion-e9349e@houat \
--to=mripard@kernel.org \
--cc=conor+dt@kernel.org \
--cc=deller@gmx.de \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximpedraza@gmail.com \
--cc=robh@kernel.org \
--cc=tzimmermann@suse.de \
--cc=u.kleine-koenig@baylibre.com \
/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