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 <max...@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
signature.asc
Description: PGP signature
