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-o...@mail.gmail.com/
Maxime
signature.asc
Description: PGP signature
