Hi
Am 22.10.25 um 16:06 schrieb Maxime Ripard:
Hi,
On Wed, Oct 22, 2025 at 07:25:10PM +0530, Devarsh Thakkar wrote:
On 08/09/25 14:43, 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.
If fbdev is enabled, 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_init_hw(), we check if the DSS is idle
(videoports disabled). If yes, do a reset and 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 VPs.
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
Later, when the tidss_runtime_get() is called the first time, we check
the 'boot_enabled_vp_mask'. If set, we know that we have the
splash-screen showing on the screen, and thus the clocks are enabled and
runtime PM status is active. This indicates that
pm_runtime_resume_and_get() call just before in tidss_runtime_get() did
not cause a runtime_resume callback to get called, so we need to do that
manually.
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 note about fbdev emulation:
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.
I still think it's not the kind of driver-specific driver behaviour we
want to have.
Even more so when we have a generic solution to this problem in the
works.
I agree with that sentiment. We want atomic-state readout plus a
bootsplash DRM client. This would give us flicker-free booting with
smooth transitions across drivers and user space.
Best regards
Thomas
Maxime
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
