Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Jernej =?utf-8?B?xaBrcmFiZWM=?= <jernej.skrabec@gmail.com>
To:     mripard@kernel.org, paul.kocialkowski@bootlin.com,
        Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc:     mchehab@kernel.org, gregkh@linuxfoundation.org, wens@csie.org,
        samuel@sholland.org, hverkuil-cisco@xs4all.nl,
        ezequiel@vanguardiasur.com.ar, linux-media@vger.kernel.org,
        linux-staging@lists.linux.dev,
        linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: cedrus: hevc: Add check for invalid timestamp
Date:   Mon, 18 Jul 2022 22:34:37 +0200
Message-ID: <1795344.atdPhlSkOF@jernej-laptop>
In-Reply-To: <b588b53fcfe539692a0a55b9fd0e97528def1d96.camel@collabora.com>
References: <20220718165649.16407-1-jernej.skrabec@gmail.com> <4725382.GXAFRqVoOG@kista> <b588b53fcfe539692a0a55b9fd0e97528def1d96.camel@collabora.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Dne ponedeljek, 18. julij 2022 ob 21:37:31 CEST je Nicolas Dufresne=20
napisal(a):
> Le lundi 18 juillet 2022 =C3=A0 19:57 +0200, Jernej =C5=A0krabec a =C3=A9=
crit :
> > Dne ponedeljek, 18. julij 2022 ob 19:41:48 CEST je Nicolas Dufresne
> >=20
> > napisal(a):
> > > Le lundi 18 juillet 2022 =C3=A0 18:56 +0200, Jernej Skrabec a =C3=A9c=
rit :
> > > > Not all DPB entries will be used most of the time. Unused entries w=
ill
> > > > thus have invalid timestamps. They will produce negative buffer ind=
ex
> > > > which is not specifically handled. This works just by chance in
> > > > current
> > > > code. It will even produce bogus pointer, but since it's not used, =
it
> > > > won't do any harm.
> > > >=20
> > > > Let's fix that brittle design by skipping writing DPB entry altoget=
her
> > > > if timestamp is invalid.
> > > >=20
> > > > Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding suppor=
t")
> > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > > > ---
> > > >=20
> > > >  drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >=20
> > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > > > b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index
> > > > 1afc6797d806..687f87598f78 100644
> > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > > > @@ -147,6 +147,9 @@ static void
> > > > cedrus_h265_frame_info_write_dpb(struct
> > > > cedrus_ctx *ctx,>
> > > >=20
> > > >  			dpb[i].pic_order_cnt_val
> > > >  	=09
> > > >  		};
> > > >=20
> > > > +		if (buffer_index < 0)
> > > > +			continue;
> > >=20
> > > When I compare to other codecs, when the buffer_index does not exist,
> > > the
> > > addr 0 is being programmed into the HW. With this implementation is is
> > > left
> > > to whatever it was set for the previous decode operation. I think its=
 is
> > > nicer done the other way.
> >=20
> > It's done the same way as it's done in vendor lib. As I stated in commit
> > message, actual values don't matter for unused entries. If it is used by
> > accident, HW reaction on all zero pointers can only be worse than using
> > old, but valid entry.
> >=20
> > Due to no real documentation and Allwinner unwillingness to share detai=
ls,
> > we'll probably never know what's best response for each error. Some thi=
ngs
> > can be deduced from vendor code, but not all.
> >=20
> > I would rather not complicate this fix, especially since it's candidate
> > for
> > backporting.
>=20
> I am simply trying to highlight that this is not consistant with how the
> H264 part is done. Why do we reset the register for one codec and not the
> other ?

While H264 and HEVC are similar in many ways, Cedrus uses two different cor=
es=20
or in Cedrus slang, engines, for them. They have their own quirks. One of t=
he=20
most apparent is handling of DPB array. H264 requires that same entry is=20
always at the same position in HW DPB. That's not required by HEVC.

Additional reasons for differences come from the fact that it's from two=20
different authors (Maxime and Paul). Those differences were created at the=
=20
beginning and it is what it is.

>=20
> Perhaps you should sync to your preference the driver as a whole. It also
> seems that before your patch, some bits would be 0 and some other would be
> very large values. Between this and leaving random value, I don't really
> see any gain or reason for a backport. It neither break or fix anything as
> far as I understand.

Maybe there is no need to backport, but the change is nevertheless useful. =
As=20
I explained, current code works only by chance, as we noticed with Ezequiel=
's=20
rework. It's certainly worthwhile to make code less brittle. As far as I'm=
=20
concerned, fixes tag can be dropped or even Ezequiel can squash this change=
=20
into his commit, with appropriate adjustments, of course.

I'm not completely sure what do you mean by syncing driver preference. Code=
=20
changes always need a good reason to be accepted. Moving code around and=20
renaming things just to be similar with something else is not.

Best regards,
Jernej

>=20
> My general opinion, is that we fixe the unused address (like to 0) then w=
hen
> something goes wrong, as least it will go wrong consistently.
>=20
> > Best regards,
> > Jernej
> >=20
> > > > +
> > > >=20
> > > >  		cedrus_h265_frame_info_write_single(ctx, i,
> >=20
> > dpb[i].field_pic,
> >=20
> >=20
> > pic_order_cnt,
> >=20
> > buffer_index);