Implement ioctrl FBIO_WAITFORVSYNC which allows user space to wait for
next VSYNC. The ioctrl waits until the next vertical synchronization
phase has begun.

This reintroduces interrupt handling which has been removed in a
earlier commit 85f663301364 ("video: fsl-dcu-fb: remove underrun
interrupt handling")

The DCU provides two register update methods: Manual using READREG
and automatic using MODE. Tests showed that the manual mode leads
to significant flickers on displays. This is especially disturbing
when using double buffering and panning (FBIOPAN_DISPLAY ioctrl).

Use the READREG mode only on initial mode setting and switch to
automatic mode for any further register changes.

Initial Y-offset has not been considered, which could lead to
unexpected behavior when initializing with a yoffset other than 0.

The current buffer underrun interrupt handling seems bogus in
multiple ways: Disabling and reenabling the controller seems a
questionable procedure and is also not documented. Furthermore,
to apply a DCU mode, a register transfer would be necessary
(UPDATE_MODE).

The current implementation probably even introduce races: If
a underrun happens just when enabling the controller (which has
been observed to happen quite often during initialization), the
register could still be in transfer mode. A write to a register
could still be transferred in this situation, which might lead
that the DCU off mode is transferred. Since the interrupt handler
does not initiate another register transfer, the controller would
stay off in this situation...

Rare conditions have been observed in which the controller ends
up in test mode. The race condition outlined above describes a
sequence in which the controller ends up beeing disabled. However,
before cd586e4cf9dc ("video: fsl-dcu-fb: fix operating mode off)
the DCU state off and test have been mixed up, hence this patch
could in fact fix that issue.

Fix layer initialization by also resetting the first Layer index 0.
Do not transfer the registers just yet, since this would probably
put the controller in test mode.

Powerdown mode has not been applied since disable_controller does
not initiate a register transfer by itself. Also disable the panel
in this case. We can safely nable the controller unconditionally
on FB blank normal.

Operating mode off seems to be documented wrong. Adjust the defines
to the observed values/behavior (swap TEST and OFF mode) and apply
the values correctly.

Currently the tx_empty callback only considers the Transmit Complete
Flag (TC). The reference manual is not quite clear if the TC flag
covers the TX FIFO too. Debug prints on real hardware have shown that
from time to time the TC flag is asserted (indicating Transmitter
idle) while there are still data in the TX FIFO. Hence, in this case
the serial core will call the shutdown callback even though there are
data remaining in the TX FIFO buffers.

Avoid early shutdowns by considering the TX FIFO empty flag too. Also
avoid theoretical race conditions between DMA and the driver by
checking whether the TX DMA is in progress too.

In some rare cases, the TX DMA gets started while there are still
data in the TX FIFO and the Transmit Data Register Empty Flag
(TDRE) is asserted. In this case, the DMA writes data and overflows
the TX FIFO. It is not quite clear why the TDRE is asserted in this
case, reading the status register which should clear the flag did
not alleviate the problem. It seems that the switching between
DMA and interrupt mode leads to this glitches.

Avoid TX FIFO overrun by using a burst size of 1, which allows to
transfer all data using DMA and avoid switching between DMA and
interrupt mode entirely.

This is the 4.0.5 stable release