El lun, 10 ago 2026 a las 11:02, Maxime Ripard (<[email protected]>) 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. So I do not think they are alternatives: readout preserves what firmware put up, this series lets the kernel put something there when firmware did not. On hardware with both, readout is the better answer for the handover and I would rather not duplicate it. Max
