Message-ID: <pe7wirzduogz45gtmycy4sfuklnj2c6fim4memnv7ukrpz3x66@65emaoco2cjw>
Date: Thu, 23 Oct 2025 13:50:18 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc: Thomas Zimmermann <tzimmermann@...e.de>, 
	Devarsh Thakkar <devarsht@...com>, Jyri Sarha <jyri.sarha@....fi>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, dri-devel@...ts.freedesktop.org, 
	Laurent Pinchart <laurent.pinchart@...asonboard.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] drm/tidss: Add some support for splash-screen

On Wed, Oct 22, 2025 at 07:37:27PM +0300, Tomi Valkeinen wrote:
> 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?

As far as I'm concerned, put a BMP on the screen, and that's it.

> 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?

Plymouth does all that already.

The only thing (once the state readout lands) we would lack is some way
for plymouth to access the firmware splash screen.

It works on UEFI platforms because it's exposed through UEFI (and then
sysfs) as a bmp, but we could implement something similar when the
simple-framebuffer node is there where we just allocate and copy the
buffer (and maybe convert the format?) for userspace to read it.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists