On Thu, Aug 13, 2026 at 01:50:47AM +0200, Màxim Pedraza Padilla wrote: > El mié, 12 ago 2026 a las 9:42, Maxime Ripard (<[email protected]>) escribió: > > In such a case, you can (and really should) use KMS, and you should use > > an initramfs and setup the splash screen there. > > Agreed that readout is the right answer where it applies, and I am not > looking to duplicate it. Three cases where it does not: > > - Hardware whose only in-tree display driver is fbdev. There is no KMS > state to read at all, and there are still around a hundred of those > drivers.
Which are entirely deprecated, and kept mostly for historical reason. It's kind of irrelevant to this discussion. > - DRM drivers without readout implemented, which today is all of them > but tidss. The obvious answer to that being "just implement readout then". We won't merge a core feature to accomodate a driver not implementing an existing feature. > - Falcon mode, where U-Boot proper never runs, so there is no image and > no programmed CRTC to inherit. In this case, the first modeset is fine, and whoever does it doesn't matter, so it might as well be userspace. > On the initramfs: it moves the splash earlier, it does not close the gap. Which gap are you talking about? > Measured on our 4.19 product kernel: > > 1.09 s tilcdc registers fb0, the logo can be drawn > 2.68 s ubi0 starts attaching <- 1.59 s of built-in driver probes > 3.39 s Run /sbin/init <- 0.70 s of UBI attach + UBIFS mount > > An initramfs removes the 0.70 s of storage. It cannot remove the 1.59 s, > because PID 1 does not exist until the initcalls have run. I mean, sure it can. Move built-in drivers to modules, and load them in the initramfs. It will reduce the kernel image size (so load and decompression time) and the kernel boot time itself. I personally did a subsecond boot to userspace with Falcon Boot, UBI and a similar platform (and no initramfs). 3.4s to run init seems subobtimal to me. > So the gap goes from 2.3 s to roughly 1.6 s, before the splash binary > has loaded and drawn anything. That figure is an estimate; the > breakdown it comes from is not. > > It is also worth saying what this series is and is not. The kernel has > drawn a boot logo for decades; this does not add that. It changes where the > image comes from, so that one kernel binary can serve products that differ > only in branding. If the position is that the kernel should not draw a logo > at all, that is an argument about CONFIG_LOGO rather than about these > patches -- and drm_panic already calls fb_find_logo(), so the logo is not > purely an fbdev concern either. I understand where you're coming from. On the flip-side, why should we add an interface we'll have to maintain forever, while making a compromise because the fact that it should be in the DT to begin with is arguable, on a deprecated subsystem, for something where we have alternatives. Maxime
signature.asc
Description: PGP signature
