[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPBb6MUz6q7GALpnB2caWkWdrE4D7rKC=BdhnD-0b91RQNJQ+g@mail.gmail.com>
Date: Sun, 26 Jul 2020 22:34:32 +0900
From: Alexandre Courbot <acourbot@...omium.org>
To: Ezequiel Garcia <ezequiel@...labora.com>
Cc: Linux Media Mailing List <linux-media@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Tomasz Figa <tfiga@...omium.org>, kernel@...labora.com,
Jonas Karlman <jonas@...boo.se>,
Hans Verkuil <hverkuil@...all.nl>,
Jeffrey Kardatzke <jkardatzke@...omium.org>,
Nicolas Dufresne <nicolas.dufresne@...labora.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Maxime Ripard <mripard@...nel.org>,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Subject: Re: [PATCH 09/10] media: hantro: Don't require unneeded H264_SLICE_PARAMS
On Sat, Jul 25, 2020 at 11:45 PM Alexandre Courbot
<acourbot@...omium.org> wrote:
>
> On Thu, Jul 16, 2020 at 5:23 AM Ezequiel Garcia <ezequiel@...labora.com> wrote:
> >
> > Now that slice invariant parameters have been moved,
> > the driver no longer needs this control, so drop it.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel@...labora.com>
> > ---
> > drivers/staging/media/hantro/hantro_drv.c | 5 -----
> > drivers/staging/media/hantro/hantro_h264.c | 5 -----
> > drivers/staging/media/hantro/hantro_hw.h | 2 --
> > 3 files changed, 12 deletions(-)
> >
> > diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
> > index 34797507f214..3cd00cc0a364 100644
> > --- a/drivers/staging/media/hantro/hantro_drv.c
> > +++ b/drivers/staging/media/hantro/hantro_drv.c
> > @@ -306,11 +306,6 @@ static const struct hantro_ctrl controls[] = {
> > .cfg = {
> > .id = V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS,
> > },
> > - }, {
> > - .codec = HANTRO_H264_DECODER,
> > - .cfg = {
> > - .id = V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS,
> > - },
>
> Isn't this going to make the driver reject (as opposed to just ignore)
> this control altogether? Also, even though the control is not required
> anymore, don't we want to check that it is provided in order to ensure
> user-space follows the spec (granted, this would be better done in a
> common framework shared by all drivers).
I kind of forgot about the previous discussion about frame-based vs
slice-based decoders, and since Hantro is frame-based this makes my
point above moot. Please ignore.
>
> I'd also suggest this patch (and the following one) to be merged into
> the previous one as they are just removing fields that have become
> unneeded because of it.
Powered by blists - more mailing lists