Hi Thomas,
On Wed, Apr 06, 2022 at 11:07:53AM +0200, Thomas Zimmermann wrote:
Am 28.03.22 um 17:36 schrieb Maxime Ripard:
The documentation explicitly states we must prevent the output 2 and 3 from feeding from the same HVS channel.
Let's add a warning to make some noise if we ever find ourselves in such a case.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/gpu/drm/vc4/vc4_kms.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index 94c58ec37a27..d94f78eac936 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -286,6 +286,9 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4, switch (vc4_crtc->data->hvs_output) { case 2:
WARN_ON(VC4_GET_FIELD(HVS_READ(SCALER_DISPCTRL),SCALER_DISPCTRL_DSP3_MUX) == channel);Should be drm_WARN_ON().
Indeed, thanks
Is that something that could be detected during atomic-check steps?
Atomic_check will allocate the output and take into account these constraints. However, what was happening here was that the hardware already had a default value that caused the conflict.
Patch 1 fixed it so we should never be in that condition, but better be safe than sorry.
Maxime