From: Philipp Zabel <p.zabel@pengutronix.de>
To: Ezequiel Garcia <ezequiel@collabora.com>, linux-media@vger.kernel.org
Cc: kernel@collabora.com, Tomasz Figa <tfiga@chromium.org>,
linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>, Jonas Karlman <jonas@kwiboo.se>,
Boris Brezillon <boris.brezillon@collabora.com>,
Chris Healy <cphealy@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] media: hantro: Support color conversion via post-processing
Date: Thu, 05 Dec 2019 15:46:26 +0100 [thread overview]
Message-ID: <2d2524129c6287c13e9d83d1d885046483e75117.camel@pengutronix.de> (raw)
In-Reply-To: <88a48cb78843458b55896eeb3af2f46488d42744.camel@collabora.com>
On Thu, 2019-12-05 at 11:33 -0300, Ezequiel Garcia wrote:
> Hello Philipp,
>
> On Fri, 2019-11-15 at 12:44 -0300, Ezequiel Garcia wrote:
> > Hello Philipp,
> >
> > Thanks for reviewing.
> >
> > On Thu, 2019-11-14 at 10:48 +0100, Philipp Zabel wrote:
> > > Hi Ezequiel,
> > >
> > > On Wed, 2019-11-13 at 14:56 -0300, Ezequiel Garcia wrote:
> > > > The Hantro G1 decoder is able to enable a post-processor
> > > > on the decoding pipeline, which can be used to perform
> > > > scaling and color conversion.
> > > >
> > > > The post-processor is integrated to the decoder, and it's
> > > > possible to use it in a way that is completely transparent
> > > > to the user.
> > > >
> > > > This commit enables color conversion via post-processing,
> > > > which means the driver now exposes YUV packed, in addition to NV12.
> > > >
> > > > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> > > > ---
> > > > drivers/staging/media/hantro/Makefile | 1 +
> > > > drivers/staging/media/hantro/hantro.h | 64 +++++++-
> > > > drivers/staging/media/hantro/hantro_drv.c | 8 +-
> > > > .../staging/media/hantro/hantro_g1_h264_dec.c | 2 +-
> > > > .../media/hantro/hantro_g1_mpeg2_dec.c | 2 +-
> > > > drivers/staging/media/hantro/hantro_g1_regs.h | 53 +++++++
> > > > .../staging/media/hantro/hantro_g1_vp8_dec.c | 2 +-
> > > > drivers/staging/media/hantro/hantro_h264.c | 6 +-
> > > > drivers/staging/media/hantro/hantro_hw.h | 13 ++
> > > > .../staging/media/hantro/hantro_postproc.c | 141 ++++++++++++++++++
> > > > drivers/staging/media/hantro/hantro_v4l2.c | 52 ++++++-
> > > > drivers/staging/media/hantro/rk3288_vpu_hw.c | 10 ++
> > > > 12 files changed, 343 insertions(+), 11 deletions(-)
> > > > create mode 100644 drivers/staging/media/hantro/hantro_postproc.c
> > > >
> > > >
> [..]
> > > > pix_mp->plane_fmt[0].sizeimage +=
> > > > 128 * DIV_ROUND_UP(pix_mp->width, 16) *
> > > > DIV_ROUND_UP(pix_mp->height, 16);
> > > > @@ -611,10 +643,23 @@ static int hantro_start_streaming(struct vb2_queue *q, unsigned int count)
> > > >
> > > > vpu_debug(4, "Codec mode = %d\n", codec_mode);
> > > > ctx->codec_ops = &ctx->dev->variant->codec_ops[codec_mode];
> > > > - if (ctx->codec_ops->init)
> > > > + if (ctx->codec_ops->init) {
> > > > ret = ctx->codec_ops->init(ctx);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +
> > > > + if (hantro_needs_postproc(ctx)) {
> > > > + ret = hantro_postproc_alloc(ctx);
> > >
> > > Why is this done in start_streaming? Wouldn't capture side REQBUFS be a
> > > better place for this?
> > >
> >
> > Yes, makes sense as well.
> >
>
> This didn't work so well, so I have decided to leave it as-is in the
> just submitted v4 series.
>
> The vb2 framework provides two mechanism for drivers to allocate
> buffers, REQBUFS and CREATEBUFS, so the bounce buffer allocation
> has to be hooked on both of them.
That is a good point, now that we don't allocate VB2_MAX_FRAME bounce
buffers at start_streaming time anymore, what happens if additional
capture buffers are created with CREATEBUFS while streaming?
> Also, REQBUFS and CREATEBUFS can be called multiple times
> to grow/shrink the vb2_queue, so the driver has to check
> if the bounce buffers were already created or not.
>
> Not a big deal, but I felt the implementation ended up being
> too nasty for my taste.
>
> If fragmentation turns out to be an issue and we want to avoid
> allocating and destroying in start and stop (STREAMOFF, STREAMON),
> we can revisit this.
regards
Philipp
next prev parent reply other threads:[~2019-12-05 14:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 17:56 [PATCH v3 0/3] Enable Hantro G1 post-processor Ezequiel Garcia
2019-11-13 17:56 ` [PATCH v3 1/3] media: hantro: Cleanup format negotiation helpers Ezequiel Garcia
2019-11-14 9:26 ` Philipp Zabel
2019-11-14 9:32 ` Boris Brezillon
2019-11-13 17:56 ` [PATCH v3 2/3] media: hantro: Support color conversion via post-processing Ezequiel Garcia
2019-11-14 9:46 ` Boris Brezillon
2019-11-14 9:48 ` Philipp Zabel
2019-11-15 15:44 ` Ezequiel Garcia
2019-11-15 16:10 ` Philipp Zabel
2019-12-05 14:33 ` Ezequiel Garcia
2019-12-05 14:46 ` Philipp Zabel [this message]
2019-12-05 16:02 ` Ezequiel Garcia
2019-11-13 17:56 ` [PATCH v3 3/3] media: vidioc-enum-fmt.rst: clarify format preference Ezequiel Garcia
2019-11-14 9:32 ` Boris Brezillon
2020-02-09 19:52 ` [PATCH v3 0/3] Enable Hantro G1 post-processor Nicolas Dufresne
2020-02-10 2:45 ` Tomasz Figa
2020-02-11 4:16 ` Nicolas Dufresne
2020-02-11 16:22 ` Nicolas Dufresne
2020-02-12 7:06 ` Tomasz Figa
2020-02-19 21:06 ` Nicolas Dufresne
2020-03-09 11:11 ` 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=2d2524129c6287c13e9d83d1d885046483e75117.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=boris.brezillon@collabora.com \
--cc=cphealy@gmail.com \
--cc=ezequiel@collabora.com \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=tfiga@chromium.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).