drm/tidss: Add some support for splash-screen

commit 09b723e88d25371d188a6a817bbe7b29891e942e from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git



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.

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_check_hw_state(), we check if the DSS is idle
(videoports disabled). If yes, 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 VP ports.

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

When the tidss_runtime_get() is called the first time, as indicated by
the 'boot_enabled_vp_mask', we know that we have the splash-screen
showing on the screen, and that the pm_runtime_resume_and_get() call in
tidss_runtime_get() did not cause a runtime_resume callback to get
called.

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 few notes:

While using simplefb is not mandatory, I think it's correct to use it if
tidss is a module. Otherwise the DSS clocks and PD would, from Linux's
point of view, be unused between the core kernel start and the time the
tidss module is loaded. Thus Linux would be free to disable those,
causing the splash-screen to disappear.

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. Even in this case there's a
small benefit to this patch: Without this patch tidss will reset
immediately in its probe(). With this patch tidss will reset only when
all the display drivers have probed, we have a working display and we're
about to set up the fbdev on the screen. However, for the time being,
disabling fbdev emulation will make the splash-screen visible on the
screen for a longer period.

And finally, when tidss probes, it calls
drm_aperture_remove_framebuffers(), which causes simplefb to be removed
(if simplefb is enabled). In theory, at this point the framebuffer
memory, "owned" by the simplefb, being shown by the DSS hardware, might
be released as no driver is keeping it reserved. However, as the
boot-time framebuffer memory is reserved in the 'reserved-memory' DT
node, this should not be a problem.  In fact, if this was a problem, it
would also be a problem without simplefb.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Xulin Sun <xulin.sun@windriver.com>