[PATCH 1/2] drm/tidss: Add some support for splash-screen

[Maxime Ripard]

Hi Tomi,

On Wed, Apr 16, 2025 at 02:06:29PM +0300, Tomi Valkeinen wrote:
> Currently when the driver's probe is called, we do a full DSS reset. If
> the bootloader has set up a splash-screen, the reset will disable the
> video output, and after that it may still take time until the display is
> usable (all the kernel modules have been loaded) and even more time
> until the userspace is able to use the display.
> 
> In a perfect case tidss would take over the fb memory set up by the
> bootloader, and use that memory for tidss's fbdev, thus retaining the
> splash-screen. However, we're not there yet.
> 
> As a partial solution, this patch changes the driver so that the driver
> will not reset (or change) the DSS registers until tidss_runtime_get()
> is called when the display is being set up (because of fbdev modesetting
> or modesetting from the userspace).
> 
> This is achieved in two parts:
> 
> 1. Probe
> 
> At probe time, in dispc_check_hw_state(), we check if the DSS is idle
> (videoports disabled). If yes, continue as before. If not, we know that
> there's a splash-screen, and we set the 'tidss->boot_enabled_vp_mask'
> field to reflect the enabled VP ports.
> 
> We then enable the corresponding VP clocks (to ensure they stay on), set
> the IRQENABLE to 0 to make sure we won't get any interrupts, and then
> exit leaving the fclk and VP clocks enabled, and the runtime PM status
> active.
> 
> 2. Runtime get
> 
> When the tidss_runtime_get() is called the first time, as indicated by
> the 'boot_enabled_vp_mask', we know that we have the splash-screen
> showing on the screen, and that the pm_runtime_resume_and_get() call in
> tidss_runtime_get() did not cause a runtime_resume callback to get
> called.
> 
> We call dispc_splash_fini() which essentially returns the DSS into the
> state where it would be in a non-splash-screen case: dispc_splash_fini()
> will do a DSS reset, manually call the runtime_resume callback, and then
> call clk_disable_unprepare() and pm_runtime_put_noidle() to counter the
> actions at probe time.
> 
> Finally 'boot_enabled_vp_mask' is set to zero to mark that we're no
> longer in the "splash-screen mode".
> 
> ===
> 
> A few notes:
> 
> If fbdev emulation is enabled in the DRM, tidss will set up an fbdev.
> This will cause a modeset, and the blank framebuffer from tidss's fbdev
> will be shown instead of the splash-screen.
> 
> I see two improvements to this: either we should memcpy the pixel data
> from the bootloader's splash-screen to the new fbdev buffer, or the
> fbdev could use the splash-screen directly as its buffer. I have done
> some hacks for the former, but I'm not sure how to implement either of
> these properly.

So, DRM kind of has support for it, but not really.

What you're trying to do is essentially what i915 fastboot is about:
booting flicker-free, and speeding up the probe process.

i915 does so using two things:

  * IIRC, the UEFI exposes its splashscreen through ACPI, and this in
    turn is exposed through sysfs. Plymouth then picks it up, and does
    its own thing with it. I think it would be fairly easy to do
    something similar for simple-drm: the memory is typically reserved,
    so it will stick around, and you just need to expose the memory
    buffer as a sysfs file. If we want to make it simpler, I guess we
    could expose it as BMP, and that would possibly require a format
    conversion. But yeah, it shouldn't be too hard.

  * Then, the i915 driver has a custom reset hook. reset() is about
    building the initial state, and most drivers actually go from a
    pristine state. However, nothing prevents a driver from building a
    custom initial state by building it from the register. Then, you'll
    only get a flicker if the compositor initial modeset actually
    requires a modeset. Otherwise, you can just do a page flip.

We discussed it with Sima in the past, and here's a more detailed
description of what it would entail:

https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9BwmvfU-O0gg@mail.gmail.com/

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250514/96943878/attachment.sig>