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
