Message-ID: <qljdrluxqi3abg7opwvp24ki7255jxrpowf47rpumzlcbnlnon@pccj5wm2kbxt>
Date: Wed, 22 Oct 2025 16:06:23 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Devarsh Thakkar <devarsht@...com>
Cc: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, 
	Jyri Sarha <jyri.sarha@....fi>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, 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

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.

Maxime

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

Powered by blists - more mailing lists