Re: [PATCH v2] drm/tidss: Add some support for splash-screen

[Thomas Zimmermann <tzimmermann@suse.de>]

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)