kernel.git/drivers/media/platform/mediatek/vcodec, branch linux-5.19.y

media: mediatek: vcodec: Drop platform_get_resource(IORESOURCE_IRQ)

2022-10-05T08:40:48Z

commit a2d2e593d39bc2f29a1cd5e3779af457fd26490c upstream. Commit a1a2b7125e10 ("of/platform: Drop static setup of IRQ resource from DT core") removed support for calling platform_get_resource(..., IORESOURCE_IRQ, ...) on DT-based drivers, but the probe() function of mtk-vcodec's encoder was still making use of it. This caused the encoder driver to fail probe. Since the platform_get_resource() call was only being used to check for the presence of the interrupt (its returned resource wasn't even used) and platform_get_irq() was already being used to get the IRQ, simply drop the use of platform_get_resource(IORESOURCE_IRQ) and handle the failure of platform_get_irq(), to get the driver probing again. [hverkuil: drop unused struct resource *res] Fixes: a1a2b7125e10 ("of/platform: Drop static setup of IRQ resource from DT core") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: mediatek: vcodec: Initialize decoder parameters for each instance

2022-08-17T13:14:44Z

[ Upstream commit fe3d651627d61210c6905339e5281d3b9db75033 ] The decoder parameters are stored in each instance's context data. This needs to be initialized per-instance, but a previous fix incorrectly changed it to only be initialized for the first opened instance. This resulted in subsequent instances not correctly signaling the requirement for the Requests API. Fix this by calling the initializing function outside of the v4l2_fh_is_singular() conditional block. Fixes: faddaa735c20 ("media: mediatek: vcodec: Initialize decoder parameters after getting dec_capability") Signed-off-by: Chen-Yu Tsai Reviewed-by: Yunfei Dong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: decoder: Drop max_{width,height} from mtk_vcodec_ctx

2022-08-17T13:14:43Z

[ Upstream commit e8d266d533b171387945f8a0bad1944a5609f63b ] This partially reverts commit b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability"). After the previous patches: - media: mediatek: vcodec: decoder: Fix 4K frame size enumeration - media: mediatek: vcodec: decoder: Skip alignment for default resolution - media: mediatek: vcodec: decoder: Fix resolution clamping in TRY_FMT the max_{width,height} fields in |struct mtk_vcodec_ctx| no longer have any real users. Remove them. Fixes: b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by: Chen-Yu Tsai Tested-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: decoder: Skip alignment for default resolution

2022-08-17T13:14:43Z

[ Upstream commit 3b6a81a31370539f1fd0e9bdd315503aa154285e ] The default resolution of 64x64 is already aligned, according to the call to v4l_bound_align_image() in mtk_vcodec_dec_set_default_params(). Drop the redundant v4l_bound_align_image() call. This also removes one usage of ctx->max_{width,height}. Signed-off-by: Chen-Yu Tsai Tested-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: decoder: Fix resolution clamping in TRY_FMT

2022-08-17T13:14:43Z

[ Upstream commit d7abd054201377aa441411ca081bd903fba82ce0 ] 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 Tested-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: decoder: Fix 4K frame size enumeration

2022-08-17T13:14:43Z

[ Upstream commit f1748f8f8174a65a885a8e6c0dc11658a6705ac2 ] This partially reverts commit b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability"). In this commit, the maximum resolution ended up being a function of both the firmware capability and the current set format. However, frame size enumeration for output (coded) formats should not depend on the format set, but should return supported resolutions for the format requested by userspace. Fix this so that the driver returns the supported resolutions correctly, even if the instance only has default settings, or if the output format is currently set to VP8F, which does not support 4K. This adds an copy of special casing for !VP8 and 4K support. The other existing copy will be removed when .max_{width,height} are removed from |struct mtk_vcodec_ctx| in a subsequent patch. Fixes: b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by: Chen-Yu Tsai Tested-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: Fix non subdev architecture open power fail

2022-08-17T13:14:35Z

[ Upstream commit 083f54a7c9c66496b9d9f3c50dfdca24e6aa7012 ] According to subdev_bitmap bit value to open hardware power, need to set subdev_bitmap value for non subdev architecture. Fixes: c05bada35f01 ("media: mtk-vcodec: Add to support multi hardware decode") Signed-off-by: Yunfei Dong Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: Skip SOURCE_CHANGE & EOS events for stateless

2022-08-17T13:14:35Z

[ Upstream commit e13ca460e20ed42fe57a3845b0bb9a82f81f05cd ] The stateless decoder API does not specify the usage of SOURCE_CHANGE and EOF events. These events are used by stateful decoders to signal changes in the bitstream. They do not make sense for stateless decoders. Do not handle subscription for these two types of events for stateless decoder instances. This fixes the last v4l2-compliance error: Control ioctls: fail: v4l2-test-controls.cpp(946): have_source_change || have_eos test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL Fixes: 8cdc3794b2e3 ("media: mtk-vcodec: vdec: support stateless API") Signed-off-by: Chen-Yu Tsai Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mediatek: vcodec: Initialize decoder parameters after getting dec_capability

2022-08-17T13:14:35Z

[ Upstream commit faddaa735c208560a3f419038e8d154a01b584e3 ] Need to get dec_capability from scp first, then initialize decoder supported format and other parameters according to dec_capability value. Fixes: fd00d90330d1 ("media: mtk-vcodec: vdec: move stateful ops into their own file") Signed-off-by: Yunfei Dong Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: h264: Use v4l2_h264_reference for reflist

2022-05-17T07:58:42Z

In preparation for adding field decoding support, convert the byte arrays for reflist into array of struct v4l2_h264_reference. That struct will allow us to mark which field of the reference picture is being referenced. [hverkuil: top_field_order_cnt -> pic_order_count] Signed-off-by: Nicolas Dufresne Reviewed-by: Ezequiel Garcia Tested-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab