summaryrefslogtreecommitdiff
path: root/drivers/staging/media/hantro/hantro_postproc.c
AgeCommit message (Collapse)AuthorFilesLines
2022-08-31media: destage Hantro VPU driverEzequiel Garcia1-279/+0
The Hantro mainline driver has been used in production since several years and was only kept as a staging driver due the stateless CODEC controls. Now that all the stateless CODEC controls have been moved out of staging, graduate the driver as well. Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-17media: hantro: postproc: Properly calculate chroma offsetJernej Skrabec1-1/+3
Currently chroma offset calculation assumes only 1 byte per luma, with no consideration for stride. Take necessary information from destination pixel format which makes calculation completely universal. Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-17media: hantro: postproc: Fix legacy regs configurationJernej Skrabec1-0/+10
Some postproc legacy registers were set in VP9 code. Move them to postproc and fix their value. Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-17media: hantro: postproc: Fix buffer size calculationJernej Skrabec1-7/+17
When allocating aux buffers for postprocessing, it's assumed that base buffer size is the same as that of output. Coincidentally, that's true most of the time, but not always. 10-bit source also needs aux buffer size which is appropriate for 10-bit native format, even if the output format is 8-bit. Similarly, mv sizes and other extra buffer size also depends on source width/height, not destination. Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-05-13media: hantro: Use post processor scaling capacitiesBenjamin Gaignard1-2/+51
Hantro G2 post processor is able to down scale decoded frames by a factor of 2, 4 or 8. Add enum_framesizes() ops to postproc_ops structure to enumerate the possible output sizes for a given input resolution. For G2 post-processor use fsize->index (from 0 to 3) as power of 2 divisor. As described in v4l2 documentation return -EINVAL when scaling down isn't possible. fluster scores: 77/147 for HEVC 143/303 for VP9 Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2021-12-14media: hantro: Fix G2/HEVC negotiated pixelformatBenjamin Gaignard1-0/+3
G2/HEVC is broken because driver capture queue pixelformat ioctl G_FMT returns VT12 while G2/HEVC always generate NV12 frames: video1: VIDIOC_S_FMT: type=vid-out-mplane, width=2560, height=1600, format=S265 little-endian (0x35363253), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0 plane 0: bytesperline=0 sizeimage=6144000 video1: VIDIOC_S_EXT_CTRLS: which=0x0, count=1, error_idx=0, request_fd=0, name=HEVC Sequence Parameter Set, id/size=0x990cf0/32 video1: VIDIOC_G_FMT: type=vid-cap-mplane, width=2560, height=1600, format=VT12 little-endian (0x32315456), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0 plane 0: bytesperline=2560 sizeimage=6144000 video1: VIDIOC_ENUM_FMT: index=0, type=vid-cap-mplane, flags=0x0, pixelformat=NV12 little-endian (0x3231564e), mbus_code=0x0000, description='Y/CbCr 4:2:0' video1: VIDIOC_ENUM_FMT: error -22: index=1, type=vid-cap-mplane, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description='' video1: VIDIOC_G_FMT: type=vid-cap-mplane, width=2560, height=1600, format=VT12 little-endian (0x32315456), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0 Use the postprocessor functions introduced by Hantro G2/VP9 codec series to fix the issue and remove duplicated buffer management. This allow Hantro G2/HEVC to produce NV12_4L4 and NV12. Fluster scores are 77/147 for HEVC and 129/303 for VP9 (no regression). Beauty, Jockey and ShakeNDry bitstreams from UVG (http://ultravideo.fi/) set have also been tested. Fixes: 53a3e71095c5 ("media: hantro: Simplify postprocessor") Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-22media: hantro: Support NV12 on the G2 coreAndrzej Pietrasiewicz1-0/+31
The G2 decoder block produces NV12 4x4 tiled format (NV12_4L4). Enable the G2 post-processor block, in order to produce regular NV12. The logic in hantro_postproc.c is leveraged to take care of allocating the extra buffers and configure the post-processor, which is significantly simpler than the one on the G1. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-22media: hantro: Staticize a struct in postprocessor codeAndrzej Pietrasiewicz1-1/+1
The struct is not used outside this file, so it can be static. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-22media: hantro: Simplify postprocessorEzequiel Garcia1-7/+1
Add a 'postprocessed' boolean property to struct hantro_fmt to signal that a format is produced by the post-processor. This will allow to introduce the G2 post-processor in a simple way. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-22media: hantro: postproc: Introduce struct hantro_postproc_opsEzequiel Garcia1-9/+24
Turns out the post-processor block on the G2 core is substantially different from the one on the G1 core. Introduce hantro_postproc_ops with .enable and .disable methods, which will allow to support the G2 post-processor cleanly. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-22media: hantro: postproc: Fix motion vector space sizeEzequiel Garcia1-3/+4
When the post-processor hardware block is enabled, the driver allocates an internal queue of buffers for the decoder enginer, and uses the vb2 queue for the post-processor engine. For instance, on a G1 core, the decoder engine produces NV12 buffers and the post-processor engine can produce YUY2 buffers. The decoder engine expects motion vectors to be appended to the NV12 buffers, but this is only required for CODECs that need motion vectors, such as H.264. Fix the post-processor logic accordingly. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-06-08media: hantro: Only use postproc when post processed formats are definedBenjamin Gaignard1-0/+14
If the variant doesn't support postprocessed formats make sure it will be ok. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: hantro: postproc: Fix motion vector space allocationEzequiel Garcia1-1/+3
When the post-processor is enabled, the driver allocates "shadow buffers" which are used for the decoder core, and exposes the post-processed buffers to userspace. For this reason, extra motion vector space has to be allocated on the shadow buffers, which the driver wasn't doing. Fix it. This fix should address artifacts on high profile bitstreams. Fixes: 8c2d66b036c77 ("media: hantro: Support color conversion via post-processing") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-17staging: media: hantro: remove parenthesesKaaira Gupta1-6/+6
Remove unnecessary parentheses in file hantro_postproc.c. Check reported by coccinelle. Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Link: https://lore.kernel.org/r/20200313215406.2485-5-kgupta@es.iitr.ac.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-23media: hantro: fix post-processing NULL pointer dereferenceJonas Karlman1-0/+6
The RK3399 variant does not have postproc_regs declared, this can cause a NULL pointer dereference trying to decode: [ 89.331359] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 89.352804] Call trace: [ 89.353191] hantro_postproc_disable+0x20/0xe8 [hantro_vpu] [ 89.354056] hantro_start_prepare_run+0x58/0x68 [hantro_vpu] [ 89.354923] hantro_h264_dec_prepare_run+0x30/0x6f0 [hantro_vpu] [ 89.355846] rk3399_vpu_h264_dec_run+0x1c/0x14a8 [hantro_vpu] [ 89.356748] device_run+0xa4/0xb8 [hantro_vpu] Fix this by adding a NULL check in hantro_postproc_enable/disable. Fixes: 8c2d66b036c7 ("media: hantro: Support color conversion via post-processing") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-12-16media: hantro: Support color conversion via post-processingEzequiel Garcia1-0/+142
The Hantro G1 decoder is able to enable a post-processor on the decoding pipeline, which can be used to perform scaling and color conversion. The post-processor is integrated to the decoder, and it's possible to use it in a way that is completely transparent to the user. This commit enables color conversion via post-processing, which means the driver now exposes YUV packed, in addition to NV12. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-07 13:17:04 +0300