- 01 Sep, 2020 40 commits
-
-
Stanimir Varbanov authored
Use the standard menu control for frame skip mode in the MFC driver. The legacy private menu control is kept for backward compatibility. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Stanimir Varbanov authored
This adds support for frame-skip-mode standard v4l2 control in encoder driver. The control is implemented based on the combination of client selected bitrate-mode and frame-skip-mode. Once The client selected bitrate-mode (constant or variable) and the frame-skip-mode is not disabled we set variable framerate for rate controller. Signed-off-by:
-
Stanimir Varbanov authored
Adds encoders standard v4l2 control for frame-skip. The control is a copy of a custom encoder control so that other v4l2 encoder drivers can use it. Signed-off-by:
-
Stanimir Varbanov authored
Adds implementation of V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY v4l control when the bitrate mode is CQ. Signed-off-by:
-
Maheshwar Ajja authored
When V4L2_CID_MPEG_VIDEO_BITRATE_MODE value is V4L2_MPEG_VIDEO_BITRATE_MODE_CQ, encoder will produce constant quality output indicated by V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY control value. Encoder will choose appropriate quantization parameter and bitrate to produce requested frame quality level. Signed-off-by:
Maheshwar Ajja <majja@codeaurora.org> Reviewed-by:
-
Stanimir Varbanov authored
Presently the recovery mechanism is using two hfi functions to destroy and create interface queues. For the purpose of recovery we don't need to free and allocate the memory used for interface message queues, that's why we introduce new function which just reinit the queues. Also this will give to the recovery procedure one less reason to fail (if for some reason we couldn't allocate memory). Signed-off-by:
Fritz Koenig <frkoenig@chromium.org> Signed-off-by:
-
Stanimir Varbanov authored
After power domains and clock restructuring the recovery for sdm845 and v4 did not work properly. Fix that by reworking the recovery function and the sequence. Signed-off-by:
-
Stanimir Varbanov authored
Presently the hfi_parser has been called only once during driver probe. To prepare the parser function to be called multiple times from recovery we need to initialize few variables which are used during parsing time. Signed-off-by:
-
Loic Poulain authored
On dragonboard-410c (apq8016) with HFI_VERSION_1XX, the reported framerate is in unit of 1/65535 fps (for fine grained control). So the current reported supported frame intervals is wrong (max is 1/65535 fps), leading to encoding issues or format negotiation failures with gstreamer. Fix that by setting the framerate denominator to coherent value based on the the framerate factor. The factor is not always the same, e.g. with db820c (apq8096) HFI reports framerate in fps unit. So only apply that for HFI_VERSION_1XX. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Vikash Garodia authored
There are few list handling issues while adding and deleting node in the registered buf list in the driver. 1. list addition - buffer added into the list during buf_init while not deleted during cleanup. 2. list deletion - In capture streamoff, the list was reinitialized. As a result, if any node was present in the list, it would lead to issue while cleaning up that node during buf_cleanup. Corresponding call traces below: [ 165.751014] Call trace: [ 165.753541] __list_add_valid+0x58/0x88 [ 165.757532] venus_helper_vb2_buf_init+0x74/0xa8 [venus_core] [ 165.763450] vdec_buf_init+0x34/0xb4 [venus_dec] [ 165.768271] __buf_prepare+0x598/0x8a0 [videobuf2_common] [ 165.773820] vb2_core_qbuf+0xb4/0x334 [videobuf2_common] [ 165.779298] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2] [ 165.784053] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem] [ 165.789067] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem] [ 165.794624] v4l_qbuf+0x48/0x58 [ 1797.556001] Call trace: [ 1797.558516] __list_del_entry_valid+0x88/0x9c [ 1797.562989] vdec_buf_cleanup+0x54/0x228 [venus_dec] [ 1797.568088] __buf_prepare+0x270/0x8a0 [videobuf2_common] [ 1797.573625] vb2_core_qbuf+0xb4/0x338 [videobuf2_common] [ 1797.579082] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2] [ 1797.583830] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem] [ 1797.588843] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem] [ 1797.594389] v4l_qbuf+0x48/0x58 Signed-off-by:
Vikash Garodia <vgarodia@codeaurora.org> Reviewed-by:
-
Ezequiel Garcia authored
Baseline, Main and Extended profiles are specified to not support a scaling matrix. Also, High profiles can optionally specify a scaling matrix, using SPS and PPS NAL units. To meet this expectation, applications are required to set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT flag only when a scaling matrix is specified for a picture. Implement this on cedrus, which has hardware support for this case. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
Baseline, Main and Extended profiles are specified to not support a scaling matrix. Also, High profiles can optionally specify a scaling matrix, using SPS and PPS NAL units. To meet this expectation, applications are required to set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT flag only when a scaling matrix is specified for a picture. Implement this on hantro, which has hardware support for this case. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Ezequiel Garcia authored
Baseline, Main and Extended profiles are specified to not support a scaling matrix. Also, High profiles can optionally specify a scaling matrix, using SPS and PPS NAL units. To meet this expectation, applications are required to set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT flag only when a scaling matrix is specified for a picture. Implement this on rkvdec, which has hardware support for this case. Signed-off-by:
-
Ezequiel Garcia authored
Currently, the drivers makes no distinction between per_request and mandatory, as both are used in the same request validate check. The driver only cares to know if a given control is required to be part of a request, so only one flag is needed. Signed-off-by:
-
Jernej Skrabec authored
Current frame list construction algorithm assumes that decoded image will be output into its own buffer. That is true for progressive content but not for interlaced where each field is decoded separately into same buffer. Fix that by checking if capture buffer is listed in DPB. If it is, reuse it. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Jernej Skrabec authored
When interlaced H264 content is being decoded, references must indicate which field is being referenced. Currently this was done by checking capture buffer flags. However, that is not correct because capture buffer may hold both fields. Fix this by checking newly introduced flags in reference lists. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
Now that slice invariant parameters have been moved, the driver no longer needs this control, so drop it. Signed-off-by:
-
Ezequiel Garcia authored
Now that slice invariant parameters have been moved, the driver no longer needs this control, so drop it. Signed-off-by:
-
Ezequiel Garcia authored
Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX if a non-flat scaling matrix applies to the picture. This is the case if SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag are set, and should be handled by applications. On one hand, the PPS bitstream syntax element signals the presence of a Picture scaling matrix modifying the Sequence (SPS) scaling matrix. On the other hand, our flag should indicate if the scaling matrix V4L2 control is applicable to this request. Rename the flag from PPS_FLAG_PIC_SCALING_MATRIX_PRESENT to PPS_FLAG_SCALING_MATRIX_PRESENT, to avoid mixing this flag with bitstream syntax element pic_scaling_matrix_present_flag, and clarify the meaning of our flag. Signed-off-by:
-
Ezequiel Garcia authored
The H.264 specification requires in section 7.4.3 "Slice header semantics", that the following values shall be the same in all slice headers: pic_parameter_set_id frame_num field_pic_flag bottom_field_flag idr_pic_id pic_order_cnt_lsb delta_pic_order_cnt_bottom delta_pic_order_cnt[ 0 ] delta_pic_order_cnt[ 1 ] sp_for_switch_flag slice_group_change_cycle These bitstream fields are part of the slice header, and therefore passed redundantly on each slice. The purpose of the redundancy is to make the codec fault-tolerant in network scenarios. This is of course not needed to be reflected in the V4L2 controls, given the bitstream has already been parsed by applications. Therefore, move the redundant fields to the per-frame decode parameters control (DECODE_PARAMS). Field 'pic_parameter_set_id' is simply removed in this case, because the PPS control must currently contain the active PPS. Syntax elements dec_ref_pic_marking() and those related to pic order count, remain invariant as well, and therefore, the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size are also common to all slices. Signed-off-by:
-
Ezequiel Garcia authored
Currently, the SLICE_BASED and FRAME_BASED modes documentation is misleading and not matching the intended use-cases. Drop non-required fields SLICE_PARAMS 'start_byte_offset' and DECODE_PARAMS 'num_slices' and clarify the decoding modes in the documentation. On SLICE_BASED mode, a single slice is expected per OUTPUT buffer, and therefore 'start_byte_offset' is not needed (since the offset to the slice is the start of the buffer). This mode requires the use of CAPTURE buffer holding, and so the number of slices shall not be required. On FRAME_BASED mode, the devices are expected to take care of slice parsing. Neither SLICE_PARAMS are required (and shouldn't be exposed by frame-based drivers), nor the number of slices. Signed-off-by:
-
Ezequiel Garcia authored
The SLICE_PARAMS control is intended for slice-based devices. In this mode, the OUTPUT buffer contains a single slice, and so the buffer's plane payload size can be used to query the slice size. To reduce the API surface drop the size from the SLICE_PARAMS control. A follow-up change will remove other members in SLICE_PARAMS so we don't need to add padding fields here. Signed-off-by:
-
Ezequiel Garcia authored
DPB entry PicNum maximum value is 2*MaxFrameNum for interlaced content (field_pic_flag=1). As specified, MaxFrameNum is 2^(log2_max_frame_num_minus4 + 4) and log2_max_frame_num_minus4 is in the range of 0 to 12, which means pic_num should be a 32-bit field. The v4l2_h264_dpb_entry struct needs to be padded to avoid a hole, which might be also useful to allow future uAPI extensions. Signed-off-by:
-
Ezequiel Garcia authored
As discussed recently, the current interface for the Decoded Picture Buffer is not enough to properly support field coding. This commit introduces enough semantics to support frame and field coding, and to signal how DPB entries are "used for reference". Reserved fields will be added by a follow-up commit. Signed-off-by:
-
Ezequiel Garcia authored
Slice header syntax element 'first_mb_in_slice' can point to the last macroblock, currently the field can only reference 65536 macroblocks which is insufficient for 8K videos. Although unlikely, a 8192x4320 video (where macroblocks are 16x16), would contain 138240 macroblocks on a frame. As per the H264 specification, 'first_mb_in_slice' can be up to PicSizeInMbs - 1, so increase the size of the field to 32-bits. Note that v4l2_ctrl_h264_slice_params struct will be modified in a follow-up commit, and so we defer its 64-bit padding. Signed-off-by:
-
Philipp Zabel authored
Since pic_order_cnt_bit_size is not a syntax element itself, explicitly state that it is the total size in bits of the pic_order_cnt_lsb, delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and delta_pic_order_cnt[1] syntax elements contained in the slice. [Ezequiel: rebase] Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Ezequiel Garcia authored
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 authored
Commit 0b0393d5 ("media: uapi: h264: clarify expected scaling_list_4x4/8x8 order") improved the documentation on H264 scaling lists order. This commit improves the documentation by clarifying that the lists themselves are expected in raster scan order. Signed-off-by:
-
Jernej Skrabec authored
When dealing with interlaced frames, reference lists must tell if each particular reference is meant for top or bottom field. This info is currently not provided at all in the H264 related controls. Change reference lists to hold a structure, which specifies an index into the DPB array and the field/frame specification for the picture. Currently the only user of these lists is Cedrus which is just compile fixed here. Actual usage of will come in a following commit. Signed-off-by:
-
Bingbu Cao authored
The unit of exposure value is different from other OmniVision sensors, driver will divide by 2 before set register, the exposure range exposed by v4l2 ctrl to user should be same as others, so the calculation for the maximum exposure value in current driver need be fixed. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Sakari Ailus authored
While we have had some example drivers, there has been up to date no formal documentation on how camera sensor drivers should be written; what are the practices, why, and where they apply. Signed-off-by:
-
Raag Jadav authored
Make use of SCCB APIs for regmap operations. Remove i2c_check_functionality as devm_regmap_init_sccb does it for us. Signed-off-by:
Raag Jadav <raagjadav@gmail.com> Signed-off-by:
-
Hans Verkuil authored
1) the numerator and/or denominator might be 0, in that case fall back to the default frame interval. This is per the spec and this caused a v4l2-compliance failure. 2) the updated frame interval wasn't returned in the s_frame_interval subdev op. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by:
-
Tom Rix authored
clang static analysis reports this error m5mols_core.c:767:4: warning: Called function pointer is null (null dereference) [core.CallAndMessage] info->set_power(&client->dev, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In other places, the set_power ptr is checked. So add a check. Fixes: bc125106 ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
Colin Ian King authored
Currently the error return from the call to max9286_read is masked with 0xf0 so the following check for a negative error return is never true. Fix this by checking for an error first, then masking the return value for subsequent conflink_mask checking. Addresses-Coverity: ("Logically dead code") Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by:Alexander A. Klimov <grandmaster@al2klimov.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Paul Kocialkowski authored
Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: aa288248 ("media: ov5640: Adjust the clock based on the expected rate") Acked-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Jordan Hand authored
Fix improper line breaks and format all example yavta and media-ctl commands as code blocks to improve readability. Signed-off-by:
Jordan Hand <jorhand@linux.microsoft.com> Signed-off-by:
-
Jacopo Mondi authored
Since the current maintainer email address bounces back, replace the entry and make myself and Dave Stevenson maintainers of the driver. Reviewed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Acked-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
Jacopo Mondi authored
Document the optional clock-noncontinuous endpoint property that allows enabling MIPI CSI-2 non-continuous clock operations. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
