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

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

Hi,

On 22/10/2025 17:59, Thomas Zimmermann wrote:
> 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.

I like the sound of it. What does a bootsplash DRM client do? Would this
give us the ability for the userspace to do some small modifications to
the fb (e.g. progress bar), and would it work with a built-in dummy
driver (simpledrm), and the main DRM driver as a module?

 Tomi