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
