mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wenst@chromium.org>
To: Tiffany Lin <tiffany.lin@mediatek.com>,
	Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Nicolas Dufresne <nicolas.dufresne@collabora.com>,
	Chen-Yu Tsai <wenst@chromium.org>,
	linux-media@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@collabora.com>,
	Yunfei Dong <yunfei.dong@mediatek.com>
Subject: [PATCH 0/4] media: mediatek: vcodec: Fix 4K decoding support
Date: Mon, 27 Jun 2022 19:23:58 +0800	[thread overview]
Message-ID: <20220627112402.2332046-1-wenst@chromium.org> (raw)

While testing a backport of recent mtk-vcodec developments on ChromeOS
v5.10 kernel [1], it was found that 4K decoding support had regressed.
The decoder was not correctly reporting 4K frame sizes when queried,
and ChromeOS then determined that the hardware did not support it.

This turned out to be a mix of different bugs:

1. Frame size enumeration on the output side should not depend on the
   currently set format, or any other derived state. This is fixed in
   patch 1.

2. The default resolution limit was not set according to the default
   output format determined at runtime, but hard-coded to 1080p. An
   S_FMT call is needed to override this. This is fixed in patch 2.

3. TRY_FMT on the output side was incorrectly clamping the resolution
   based on the current maximum values. It should not. Fixed in patch
   3.

The last patch fixes an odd error in the bug, where the maximum
resolution restriction could be lifted to 4K, even if the output format
doesn't allow it. In practice this wouldn't cause any issues given the
other fixes in this series and other existing checks in both the driver
and V4L2 core, but it seemed easy to fix.

This series is based on next-20220627 with media-staging at

     d8e8aa866ed8 ("media: mediatek: vcodec: Report supported bitrate modes")

merged in.

This was only tested on the backport kernel [1] on MT8195, which is the
only currently supported SoC that does 4K decoding. Hopefully the folks
at Collabora can give this a test on their mainline MT8195 integration
branch.


Regards
ChenYu

[1] https://crrev.com/c/3713491

Chen-Yu Tsai (4):
  media: mediatek: vcodec: dec: Fix 4K frame size enumeration
  media: mediatek: vcodec: dec: Set default max resolution based on
    format
  media: mediatek: vcodec: dec: Fix resolution clamping in TRY_FMT
  media: mediatek: vcodec: dec: Set maximum resolution when S_FMT on
    output only

 .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 45 ++++++++++++++-----
 .../vcodec/mtk_vcodec_dec_stateless.c         |  7 +++
 2 files changed, 41 insertions(+), 11 deletions(-)

-- 
2.37.0.rc0.161.g10f37bed90-goog


             reply	other threads:[~2022-06-27 11:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 11:23 Chen-Yu Tsai [this message]
2022-06-27 11:23 ` [PATCH 1/4] media: mediatek: vcodec: dec: Fix 4K frame size enumeration Chen-Yu Tsai
2022-06-27 15:32   ` Nicolas Dufresne
2022-06-27 16:08     ` Chen-Yu Tsai
2022-06-27 19:28       ` Nicolas Dufresne
2022-06-28  7:04         ` Chen-Yu Tsai
2022-06-27 15:33   ` Nicolas Dufresne
2022-06-27 16:13     ` Chen-Yu Tsai
2022-06-27 11:24 ` [PATCH 2/4] media: mediatek: vcodec: dec: Set default max resolution based on format Chen-Yu Tsai
2022-06-27 11:24 ` [PATCH 3/4] media: mediatek: vcodec: dec: Fix resolution clamping in TRY_FMT Chen-Yu Tsai
2022-06-27 11:24 ` [PATCH 4/4] media: mediatek: vcodec: dec: Set maximum resolution when S_FMT on output only Chen-Yu Tsai

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=20220627112402.2332046-1-wenst@chromium.org \
    --to=wenst@chromium.org \
    --cc=andrew-ct.chen@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=nicolas@ndufresne.ca \
    --cc=tiffany.lin@mediatek.com \
    --cc=yunfei.dong@mediatek.com \
    /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

all inboxes | Powered by JetHome®