drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing
authorMaxime Ripard <maxime@cerno.tech>
Thu, 17 Sep 2020 12:16:23 +0000 (14:16 +0200)
committerMaxime Ripard <maxime@cerno.tech>
Mon, 21 Sep 2020 14:43:11 +0000 (16:43 +0200)
commit089d83418914abd4d908db117d9a3eca7f51a68c
treeae503f4ef24e77330acb31211e68359b8ff0afa5
parent92fdb97d648a0120bc342342d199f5be119cfd67
drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing

The vc4 display engine has a first controller called the HVS that will
perform the composition of the planes. That HVS has 3 FIFOs and can
therefore compose planes for up to three outputs. The timings part is
generated through a component called the Pixel Valve, and the BCM2711 has 6
of them.

Thus, the HVS has some bits to control which FIFO gets output to which
Pixel Valve. The current code supports that muxing by looking at all the
CRTCs in a new DRM atomic state in atomic_check, and given the set of
constraints that we have, assigns FIFOs to CRTCs or reject the mode
entirely. The actual muxing will occur during atomic_commit.

However, that doesn't work if only a fraction of the CRTCs' state is
updated in that state, since it will ignore the CRTCs that are kept running
unmodified, and will thus unassign its associated FIFO, and later disable
it.

In order to make the code work as expected, let's pull the CRTC state of
all the enabled CRTC in our atomic_check so that we can operate on all the
running CRTCs, no matter whether they are affected by the new state or not.

Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200917121623.42023-1-maxime@cerno.tech
drivers/gpu/drm/vc4/vc4_kms.c