linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Courbot <acourbot@chromium.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org,
	Vikash Garodia <vgarodia@codeaurora.org>,
	Tomasz Figa <tfiga@chromium.org>,
	Malathi Gottam <mgottam@codeaurora.org>
Subject: Re: [PATCH 09/10] venus: vdec: allow bigger sizeimage set by clients
Date: Fri, 25 Jan 2019 14:36:43 +0900	[thread overview]
Message-ID: <CAPBb6MXLJnoT5=WkJQb7fmT8wznnth65_Gia04QuG_1-hKAmbg@mail.gmail.com> (raw)
In-Reply-To: <580839ce-c98b-8b88-8868-e5df8171923b@linaro.org>

On Thu, Jan 24, 2019 at 7:05 PM Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
>
> Hi Alex,
>
> Thanks for the comments!
>
> On 1/24/19 10:43 AM, Alexandre Courbot wrote:
> > On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> > <stanimir.varbanov@linaro.org> wrote:
> >>
> >> In most of the cases the client will know better what could be
> >> the maximum size for compressed data buffers. Change the driver
> >> to permit the user to set bigger size for the compressed buffer
> >> but make reasonable sanitation.
> >>
> >> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> >> ---
> >>  drivers/media/platform/qcom/venus/vdec.c | 18 +++++++++++++-----
> >>  1 file changed, 13 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> >> index 282de21cf2e1..7a9370df7515 100644
> >> --- a/drivers/media/platform/qcom/venus/vdec.c
> >> +++ b/drivers/media/platform/qcom/venus/vdec.c
> >> @@ -142,6 +142,7 @@ vdec_try_fmt_common(struct venus_inst *inst, struct v4l2_format *f)
> >>         struct v4l2_pix_format_mplane *pixmp = &f->fmt.pix_mp;
> >>         struct v4l2_plane_pix_format *pfmt = pixmp->plane_fmt;
> >>         const struct venus_format *fmt;
> >> +       u32 szimage;
> >>
> >>         memset(pfmt[0].reserved, 0, sizeof(pfmt[0].reserved));
> >>         memset(pixmp->reserved, 0, sizeof(pixmp->reserved));
> >> @@ -170,14 +171,18 @@ vdec_try_fmt_common(struct venus_inst *inst, struct v4l2_format *f)
> >>         pixmp->num_planes = fmt->num_planes;
> >>         pixmp->flags = 0;
> >>
> >> -       pfmt[0].sizeimage = venus_helper_get_framesz(pixmp->pixelformat,
> >> -                                                    pixmp->width,
> >> -                                                    pixmp->height);
> >> +       szimage = venus_helper_get_framesz(pixmp->pixelformat, pixmp->width,
> >> +                                          pixmp->height);
> >>
> >> -       if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
> >> +       if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> >> +               pfmt[0].sizeimage = szimage;
> >>                 pfmt[0].bytesperline = ALIGN(pixmp->width, 128);
> >> -       else
> >> +       } else {
> >> +               pfmt[0].sizeimage = clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M);
> >> +               if (szimage > pfmt[0].sizeimage)
> >> +                       pfmt[0].sizeimage = szimage;
> >
> > pfmt[0].sizeimage = max(clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M),
> >                                         szimage)?
>
> I'm not a big fan to that calling of macro from macro :)
>
> What about this:
>
>         pfmt[0].sizeimage = clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M);
>         pfmt[0].sizeimage = max(pfmt[0].sizeimage, szimage);

Looks fine, I just wanted to make sure that we use the more expressive
"max" instead of an if statement.

>
> >
> >>                 pfmt[0].bytesperline = 0;
> >> +       }
> >>
> >>         return fmt;
> >>  }
> >> @@ -275,6 +280,7 @@ static int vdec_s_fmt(struct file *file, void *fh, struct v4l2_format *f)
> >>                 inst->ycbcr_enc = pixmp->ycbcr_enc;
> >>                 inst->quantization = pixmp->quantization;
> >>                 inst->xfer_func = pixmp->xfer_func;
> >> +               inst->input_buf_size = pixmp->plane_fmt[0].sizeimage;
> >>         }
> >>
> >>         memset(&format, 0, sizeof(format));
> >> @@ -737,6 +743,8 @@ static int vdec_queue_setup(struct vb2_queue *q,
> >>                 sizes[0] = venus_helper_get_framesz(inst->fmt_out->pixfmt,
> >>                                                     inst->out_width,
> >>                                                     inst->out_height);
> >> +               if (inst->input_buf_size > sizes[0])
> >> +                       sizes[0] = inst->input_buf_size;
> >
> >                sizes[0] = max(venus_helper_get_framesz(inst->fmt_out->pixfmt,
> >                                                    inst->out_width,
> >                                                  inst->out_height),
> >                                       inst->input_buf_size)?
>
> I think it'd be more readable that way:
>
>                 sizes[0] = max(sizes[0], inst->input_buf_size);

Ditto.

  reply	other threads:[~2019-01-25  5:37 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 16:19 [PATCH 00/10] Venus stateful Codec API Stanimir Varbanov
2019-01-17 16:19 ` [PATCH 01/10] venus: hfi_cmds: add more not-implemented properties Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 02/10] venus: helpers: fix dynamic buffer mode for v4 Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 03/10] venus: helpers: export few helper functions Stanimir Varbanov
2019-01-24  8:43   ` Alexandre Courbot
2019-01-24  8:48     ` Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 04/10] venus: hfi: add type argument to hfi flush function Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 05/10] venus: hfi: export few HFI functions Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 06/10] venus: hfi: return an error if session_init is already called Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 07/10] venus: helpers: add three more helper functions Stanimir Varbanov
2019-01-24  8:43   ` Alexandre Courbot
2019-01-24  8:54     ` Stanimir Varbanov
2019-01-25  5:47       ` Alexandre Courbot
2019-01-17 16:20 ` [PATCH 08/10] venus: vdec_ctrls: get real minimum buffers for capture Stanimir Varbanov
2019-01-24  8:43   ` Alexandre Courbot
2019-01-24  9:59     ` Stanimir Varbanov
2019-01-17 16:20 ` [PATCH 09/10] venus: vdec: allow bigger sizeimage set by clients Stanimir Varbanov
2019-01-24  8:43   ` Alexandre Courbot
2019-01-24 10:05     ` Stanimir Varbanov
2019-01-25  5:36       ` Alexandre Courbot [this message]
2019-01-17 16:20 ` [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API Stanimir Varbanov
2019-01-21 11:20   ` mgottam
2019-01-21 11:29     ` mgottam
2019-01-24 10:24     ` Stanimir Varbanov
2019-01-24  8:44   ` Alexandre Courbot
2019-01-24 12:34     ` Stanimir Varbanov
2019-01-25  5:44       ` Alexandre Courbot
2019-01-25  7:59   ` Tomasz Figa
2019-01-25 10:25     ` Stanimir Varbanov
2019-01-28  7:38       ` Tomasz Figa
2019-01-28 16:28         ` Stanimir Varbanov
2019-01-29  8:24           ` Tomasz Figa
2019-01-30  3:18         ` Nicolas Dufresne
2019-01-30  3:38           ` Tomasz Figa
2019-01-30  4:21             ` Nicolas Dufresne
2019-01-30  6:17               ` Tomasz Figa
2019-01-30 15:32                 ` Nicolas Dufresne
2019-01-31 12:42                   ` Philipp Zabel
2019-01-31 13:34                     ` Tomasz Figa
2019-01-31 15:18                       ` Nicolas Dufresne
2019-02-05  6:26                         ` Tomasz Figa
2019-02-05  9:00                           ` Hans Verkuil
2019-02-05  9:31                             ` Tomasz Figa
2019-02-05 10:35                               ` Hans Verkuil
2019-02-07  7:33                                 ` Tomasz Figa
2019-02-14  2:43                                   ` Tomasz Figa
2019-02-14 16:19                                     ` Nicolas Dufresne
2019-04-09  9:59                                   ` Tomasz Figa
2019-04-09 16:30                                     ` Nicolas Dufresne
2019-04-10  2:32                                       ` Tomasz Figa
2019-02-15 13:44   ` Hans Verkuil
2019-02-15 16:27     ` Nicolas Dufresne
2019-02-15 16:40       ` Hans Verkuil
2019-04-24 12:15     ` Stanimir Varbanov
2019-04-24 12:39       ` Tomasz Figa
2019-05-20 14:47         ` Stanimir Varbanov
2019-05-21  9:09           ` Tomasz Figa
2019-05-21 12:27             ` Hans Verkuil
2019-05-27  3:51               ` Tomasz Figa
2019-05-27  7:39                 ` Hans Verkuil
2019-05-27  8:18                   ` Tomasz Figa
2019-05-31  8:01                     ` Stanimir Varbanov
2019-05-31 13:53                       ` Nicolas Dufresne
2019-06-03  7:25                       ` Hans Verkuil
2019-06-03  7:30                         ` Tomasz Figa
2019-01-24  8:43 ` [PATCH 00/10] Venus stateful Codec API Alexandre Courbot
2019-01-24 10:12   ` Stanimir Varbanov
2019-01-25  5:34     ` Alexandre Courbot
2019-01-25 10:35       ` Stanimir Varbanov
2019-01-28  4:16         ` Alexandre Courbot
2019-01-28  4:30           ` Tomasz Figa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPBb6MXLJnoT5=WkJQb7fmT8wznnth65_Gia04QuG_1-hKAmbg@mail.gmail.com' \
    --to=acourbot@chromium.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mgottam@codeaurora.org \
    --cc=stanimir.varbanov@linaro.org \
    --cc=tfiga@chromium.org \
    --cc=vgarodia@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).