[PATCH 5/6] drm/vc4: kms: Warn if we have an incompatible muxing setup

[Maxime Ripard]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220408/9a748e95/attachment.sig>