From: Ezequiel Garcia <ezequiel@collabora.com>
To: linux-media@vger.kernel.org
Cc: kernel@collabora.com,
Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Tomasz Figa <tfiga@chromium.org>,
linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>, Jonas Karlman <jonas@kwiboo.se>,
Philipp Zabel <p.zabel@pengutronix.de>,
Boris Brezillon <boris.brezillon@collabora.com>,
Alexandre Courbot <acourbot@chromium.org>,
fbuergisser@chromium.org, linux-kernel@vger.kernel.org,
Douglas Anderson <dianders@chromium.org>,
Ezequiel Garcia <ezequiel@collabora.com>
Subject: [PATCH v2 for 5.4 1/4] media: hantro: Fix s_fmt for dynamic resolution changes
Date: Mon, 7 Oct 2019 14:45:02 -0300 [thread overview]
Message-ID: <20191007174505.10681-2-ezequiel@collabora.com> (raw)
In-Reply-To: <20191007174505.10681-1-ezequiel@collabora.com>
Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
changed the conditions under S_FMT was allowed for OUTPUT
CAPTURE buffers.
However, and according to the mem-to-mem stateless decoder specification,
in order to support dynamic resolution changes, S_FMT should be allowed
even if OUTPUT buffers have been allocated.
Relax decoder S_FMT restrictions on OUTPUT buffers, allowing a resolution
modification, provided the pixel format stays the same.
Tested on RK3288 platforms using ChromiumOS Video Decode/Encode Accelerator Unittests.
Fixes: 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
--
v2:
* Call try_fmt_out before using the format,
pointed out by Philipp.
drivers/staging/media/hantro/hantro_v4l2.c | 28 +++++++++++++++-------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 3dae52abb96c..586d243cc3cc 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -367,19 +367,26 @@ vidioc_s_fmt_out_mplane(struct file *file, void *priv, struct v4l2_format *f)
{
struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
struct hantro_ctx *ctx = fh_to_ctx(priv);
+ struct vb2_queue *vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
const struct hantro_fmt *formats;
unsigned int num_fmts;
- struct vb2_queue *vq;
int ret;
- /* Change not allowed if queue is busy. */
- vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
- if (vb2_is_busy(vq))
- return -EBUSY;
+ ret = vidioc_try_fmt_out_mplane(file, priv, f);
+ if (ret)
+ return ret;
if (!hantro_is_encoder_ctx(ctx)) {
struct vb2_queue *peer_vq;
+ /*
+ * In other to support dynamic resolution change,
+ * the decoder admits a resolution change, as long
+ * as the pixelformat remains. Can't be done if streaming.
+ */
+ if (vb2_is_streaming(vq) || (vb2_is_busy(vq) &&
+ pix_mp->pixelformat != ctx->src_fmt.pixelformat))
+ return -EBUSY;
/*
* Since format change on the OUTPUT queue will reset
* the CAPTURE queue, we can't allow doing so
@@ -389,12 +396,15 @@ vidioc_s_fmt_out_mplane(struct file *file, void *priv, struct v4l2_format *f)
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
if (vb2_is_busy(peer_vq))
return -EBUSY;
+ } else {
+ /*
+ * The encoder doesn't admit a format change if
+ * there are OUTPUT buffers allocated.
+ */
+ if (vb2_is_busy(vq))
+ return -EBUSY;
}
- ret = vidioc_try_fmt_out_mplane(file, priv, f);
- if (ret)
- return ret;
-
formats = hantro_get_formats(ctx, &num_fmts);
ctx->vpu_src_fmt = hantro_find_format(formats, num_fmts,
pix_mp->pixelformat);
--
2.22.0
next prev parent reply other threads:[~2019-10-07 17:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 17:45 [PATCH v2 for 5.4 0/4] media: hantro: Collected fixes for v5.4 Ezequiel Garcia
2019-10-07 17:45 ` Ezequiel Garcia [this message]
2019-11-08 10:19 ` [PATCH v2 for 5.4 1/4] media: hantro: Fix s_fmt for dynamic resolution changes Boris Brezillon
2019-11-08 11:52 ` Tomasz Figa
2019-11-09 12:17 ` Hans Verkuil
2019-11-09 12:25 ` Hans Verkuil
2019-11-09 16:01 ` Ezequiel Garcia
2019-11-09 19:13 ` Boris Brezillon
2019-10-07 17:45 ` [PATCH v2 for 5.4 2/4] media: hantro: Fix H264 max frmsize supported on RK3288 Ezequiel Garcia
[not found] ` <20191007174505.10681-3-ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2019-10-08 5:27 ` Tomasz Figa
2019-10-08 5:27 ` Tomasz Figa
[not found] ` <CAAFQd5BNu2ea3ei_imHmEwmdna0+iiSbQSv_SBsdHfP4Uh1h4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-10-08 6:31 ` Jonas Karlman
2019-10-08 6:31 ` Jonas Karlman
2019-10-08 10:42 ` Tomasz Figa
2019-10-08 13:35 ` Tomasz Figa
[not found] ` <CAAFQd5AYCiKcA9pGc44L3gGHLPx6iMSb7KywkO8OqVv4gS8KvQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-10-08 13:53 ` Tomasz Figa
2019-10-08 13:53 ` Tomasz Figa
2019-10-08 14:12 ` Jonas Karlman
2019-10-08 20:39 ` Jonas Karlman
[not found] ` <HE1PR06MB4011D0189027292BD1107CAFAC9A0-yb6jErQ+GTm7n+Tc7eNcVa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-10-10 7:27 ` Tomasz Figa
2019-10-10 7:27 ` Tomasz Figa
[not found] ` <HE1PR06MB4011B897EA5497659A19BCC6AC9A0-yb6jErQ+GTm7n+Tc7eNcVa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-10-10 7:23 ` Tomasz Figa
2019-10-10 7:23 ` Tomasz Figa
2019-10-13 22:10 ` Nicolas Dufresne
2019-10-15 3:27 ` Tomasz Figa
2019-10-07 17:45 ` [PATCH v2 for 5.4 3/4] media: hantro: Fix motion vectors usage condition Ezequiel Garcia
2019-10-07 18:33 ` Jonas Karlman
2019-10-08 3:29 ` Tomasz Figa
2019-10-08 6:23 ` Jonas Karlman
2019-10-08 10:26 ` Tomasz Figa
2019-10-08 13:57 ` Jonas Karlman
[not found] ` <HE1PR06MB40112032B360DE217C939FB3AC9A0-yb6jErQ+GTm7n+Tc7eNcVa71xdIjGZSdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-10-10 7:36 ` Tomasz Figa
2019-10-10 7:36 ` Tomasz Figa
[not found] ` <20191007174505.10681-1-ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2019-10-07 17:45 ` [PATCH v2 for 5.4 4/4] media: hantro: Fix picture order count table enable Ezequiel Garcia
2019-10-07 17:45 ` Ezequiel Garcia
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=20191007174505.10681-2-ezequiel@collabora.com \
--to=ezequiel@collabora.com \
--cc=acourbot@chromium.org \
--cc=boris.brezillon@collabora.com \
--cc=dianders@chromium.org \
--cc=fbuergisser@chromium.org \
--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=nicolas.dufresne@collabora.com \
--cc=p.zabel@pengutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.