aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
AgeCommit message (Collapse)AuthorFilesLines
2020-09-01media: uapi: h264: Split prediction weight parametersEzequiel Garcia1-0/+2
The prediction weight parameters are only required under certain conditions, which depend on slice header parameters. As specified in section 7.3.3 Slice header syntax, the prediction weight table is present if: ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ (weighted_bipred_idc == 1 && slice_type == B)) Given its size, it makes sense to move this table to its control, so applications can avoid passing it if the slice doesn't specify it. Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes. With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight is 772 bytes. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-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>
2020-06-11media: cedrus: Program output format during each runSamuel Holland1-0/+2
Previously, the output format was programmed as part of the ioctl() handler. However, this has two problems: 1) If there are multiple active streams with different output formats, the hardware will use whichever format was set last for both streams. Similarly, an ioctl() done in an inactive context will wrongly affect other active contexts. 2) The registers are written while the device is not actively streaming. To enable runtime PM tied to the streaming state, all hardware access needs to be moved inside cedrus_device_run(). The call to cedrus_dst_format_set() is now placed just before the codec-specific callback that programs the hardware. Cc: <stable@vger.kernel.org> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Suggested-by: Jernej Skrabec <jernej.skrabec@siol.net> Suggested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> 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>
2019-10-24media: cedrus: Add HEVC/H.265 decoding supportPaul Kocialkowski1-0/+9
This introduces support for HEVC/H.265 to the Cedrus VPU driver, with both uni-directional and bi-directional prediction modes supported. Field-coded (interlaced) pictures, custom quantization matrices and 10-bit output are not supported at this point. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-19media: uapi: h264: Rename pixel formatEzequiel Garcia1-1/+1
The V4L2_PIX_FMT_H264_SLICE_RAW name was originally suggested because the pixel format would represent H264 slices without any start code. However, as we will now introduce a start code menu control, give the pixel format a more meaningful name, while it's still early enough to do so. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-05-29media: cedrus: Add H264 decoding supportMaxime Ripard1-0/+13
Introduce some basic H264 decoding support in cedrus. So far, only the baseline profile videos have been tested, and some more advanced features used in higher profiles are not even implemented. Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-02-07media: v4l2-mem2mem: Rename v4l2_m2m_buf_copy_data to v4l2_m2m_buf_copy_metadataEzequiel Garcia1-1/+1
The v4l2_m2m_buf_copy_data helper is used to copy the buffer metadata, such as its timestamp and its flags. Therefore, the v4l2_m2m_buf_copy_metadata name is more clear and avoids confusion with a payload data copy. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: also fix cedrus_dec.c] Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-01-31media: Revert "media: cedrus: Allow using the current dst buffer as reference"Paul Kocialkowski1-13/+0
This reverts commit cf20ae1535eb690a87c29b9cc7af51881384e967. The vb2_find_timestamp helper was modified to allow finding buffers regardless of their current state in the queue. This means that we no longer have to take particular care of references to the current capture buffer. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-01-21media: cedrus: Allow using the current dst buffer as referencePaul Kocialkowski1-0/+13
It was reported that some cases of interleaved video decoding require using the current destination buffer as a reference. However, this is no longer possible after the move to vb2_find_timestamp because only dequeued and done buffers are considered. Add a helper in our driver that also considers the current destination buffer before resorting to vb2_find_timestamp and use it in MPEG-2. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-01-07media: cedrus: identify buffers by timestampHans Verkuil1-0/+2
Use the new v4l2_m2m_buf_copy_data helper function and use timestamps to refer to reference frames instead of using buffer indices. Also remove the padding fields in the structs, that's a bad idea. Just use the right types to keep everything aligned. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-12-07media: cedrus: don't initialize pointers with zeroMauro Carvalho Chehab1-1/+1
A common mistake is to assume that initializing a var with: struct foo f = { 0 }; Would initialize a zeroed struct. Actually, what this does is to initialize the first element of the struct to zero. According to C99 Standard 6.7.8.21: "If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration." So, in practice, it could zero the entire struct, but, if the first element is not an integer, it will produce warnings: drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer As the right initialization would be, instead: struct foo f = { NULL }; Another way to initialize it with gcc is to use: struct foo f = {}; That seems to be a gcc extension, but clang also does the right thing, and that's a clean way for doing it. Anyway, I decided to check upstream what's the most commonly pattern. The "= {}" pattern has about 2000 entries: $ git grep -E "=\s*\{\s*\}"|wc -l 1951 The standard-C compliant pattern has about 2500 entries: $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l 137 $ git grep -E "=\s*\{\s*0\s*\}"|wc -l 2323 Meaning that developers have split options on that. So, let's opt to the simpler form. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-12-07media: cedrus: Remove global IRQ spin lock from the driverPaul Kocialkowski1-9/+0
We initially introduced a spin lock to ensure that the VPU registers are not accessed concurrently between our setup function and IRQ handler. The V4L2 M2M API ensures that only one decoding job runs at a time, so the interrupt signaling the end of decoding will not occur while the next picture is being configured. Spurious interrupts are taken care of in the handler, by checking that we have a valid M2M context and a decoding status available before marking the buffers as done. In addition, holding a spin lock could be problematic if non-atomic operations are required in the setup process for future codec support. As a result, remove the global IRQ spin lock. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-09-24media: platform: Add Cedrus VPU decoder driverPaul Kocialkowski1-0/+70
This introduces the Cedrus VPU driver that supports the VPU found in Allwinner SoCs, also known as Video Engine. It is implemented through a V4L2 M2M decoder device and a media device (used for media requests). So far, it only supports MPEG-2 decoding. Since this VPU is stateless, synchronization with media requests is required in order to ensure consistency between frame headers that contain metadata about the frame to process and the raw slice data that is used to generate the frame. This driver was made possible thanks to the long-standing effort carried out by the linux-sunxi community in the interest of reverse engineering, documenting and implementing support for the Allwinner VPU. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> [hans.verkuil@cisco.com: dropped obsolete MEDIA_REQUEST_API from Kconfig] Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

Privacy Policy