media: hantro: Hook up RK3399 JPEG encoder output
authorChen-Yu Tsai <wenst@chromium.org>
Fri, 19 Nov 2021 07:46:54 +0000 (08:46 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 27 Jan 2022 10:03:20 +0000 (11:03 +0100)
commitb85906f919ea2eab27f87a1738cc4639d594d66f
treecea67dad30be237f869490348cfe193c9beb7705
parenta49171d86d5e8ca237a30c8443f9eda6542ddcbf
media: hantro: Hook up RK3399 JPEG encoder output

[ Upstream commit 230d683ae04894933720425c8dead9508a09ebc3 ]

The JPEG encoder found in the Hantro H1 encoder block only produces a
raw entropy-encoded scan. The driver is responsible for building a JPEG
compliant bitstream and placing the entropy-encoded scan in it. Right
now the driver uses a bounce buffer for the hardware to output the raw
scan to.

In commit e765dba11ec2 ("hantro: Move hantro_enc_buf_finish to JPEG
codec_ops.done"), the code that copies the raw scan from the bounce
buffer to the capture buffer was moved, but was only hooked up for the
Hantro H1 (then RK3288) variant. The RK3399 variant was broken,
producing a JPEG bitstream without the scan, and the capture buffer's
.bytesused field unset.

Fix this by duplicating the code that is executed when the JPEG encoder
finishes encoding a frame. As the encoded length is read back from
hardware, and the variants having different register layouts, the
code is duplicated rather than shared.

Fixes: e765dba11ec2 ("hantro: Move hantro_enc_buf_finish to JPEG codec_ops.done")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
drivers/staging/media/hantro/hantro_hw.h
drivers/staging/media/hantro/rockchip_vpu2_hw_jpeg_enc.c
drivers/staging/media/hantro/rockchip_vpu_hw.c