summaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/bin/stackcollapse-record
diff options
context:
space:
mode:
authorChen-Yu Tsai <wenst@chromium.org>2022-07-06 09:21:36 +0100
committerMauro Carvalho Chehab <mchehab@kernel.org>2022-07-08 18:08:40 +0100
commitd7abd054201377aa441411ca081bd903fba82ce0 (patch)
treee36cda30bf06b5b082392daa329fd2e7e2d860ea /tools/perf/scripts/python/bin/stackcollapse-record
parent3b6a81a31370539f1fd0e9bdd315503aa154285e (diff)
downloadlinux-d7abd054201377aa441411ca081bd903fba82ce0.tar.gz
linux-d7abd054201377aa441411ca081bd903fba82ce0.zip
media: mediatek: vcodec: decoder: Fix resolution clamping in TRY_FMT
In commit b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability"), TRY_FMT clamps the resolution to the maximum that was previously set either by default 1080p or the limit set by a previous S_FMT call. This does not make sense when doing TRY_FMT for the output side, which may have different capabilities. Instead, for the output side, find the maximum resolution based on the pixel format requested. For the capture side, find the maximum resolution based on the currently set output format. The maximum resolution is found from the list of per-format frame sizes, so the patch "media: mediatek: vcodec: dec: Fix 4K frame size enumeration" is needed. Fixes: b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions