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
signature.asc
Description: PGP signature
