- 15 Jul, 2022 7 commits
-
-
Yang Yingliang authored
After 'buf_in' change to pointer, the sizeof() is not correct buffer size, it should be MAX_PACKET. Fixes: b3f820b9 ("media: igorplugusb: respect DMA coherency") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Yunke Cao authored
Add documentation for vimc-lens. Add a lens into the vimc topology graph. Signed-off-by:
Yunke Cao <yunkec@google.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Daniel Oakley authored
Future additions to the ent_config[] could break the association between the index of the struct vimc_ent_config entries in the ent_config[] array, and the index defined by the enum proposed in the previous patch. Using designated initializers solves this by linking the 2 together clearly in code and prevents the array not reflecting the enum. There is no functional change intended. Suggested-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
Daniel Oakley <daniel.oakley@ideasonboard.com> Signed-off-by:
-
Daniel Oakley authored
The data_links array was hard to read and understand. By implementing enumerated vimc data link entities, clarity has been improved when defining data_links. This therefore should help new programmers to understand the codebase better. There is no functional change intended. Suggested-by:
-
Daniel Oakley authored
When introducing the lens controller, it became apparent that the vimc entity type names were hard to understand, e.g. vimc_len_type refers to the lens. The names of the vimc entity types have been expanded to make the code easier to understand. There is no functional change intended. Suggested-by:
-
Yunke Cao authored
Add lens to vimc driver and link them with sensors using ancillary links. Provides an example of ancillary link usage.The lens supports FOCUS_ABSOLUTE control. Test example: With default vimc topology > media-ctl -p Media controller API version 5.18.0 ... - entity 28: Lens A (0 pad, 0 link) type V4L2 subdev subtype Lens flags 0 device node name /dev/v4l-subdev6 - entity 29: Lens B (0 pad, 0 link) type V4L2 subdev subtype Lens flags 0 device node name /dev/v4l-subdev7 > v4l2-ctl -d /dev/v4l-subdev7 -C focus_absolute focus_absolute: 0 Reviewed-by: -
Sakari Ailus authored
For camera sensor devices the firmware information of which comes from non-DT (or some ACPI variants), the kernel makes the information visible to the drivers in a form similar to DT. This takes place through device's secondary fwnodes, in which case also the secondary fwnode needs to be heterogenously (endpoint vs. device) matched. Fixes: 1f391df4 ("media: v4l2-async: Use endpoints in __v4l2_async_nf_add_fwnode_remote()") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
- 08 Jul, 2022 33 commits
-
-
Ming Qian authored
For format V4L2_PIX_FMT_VC1_ANNEX_L, the amphion vpu requires driver to help insert some custom startcode before sequence and frame. but only the first sequence startcode is needed, the extra startcode will cause decoding error. So after seek, we don't need to insert the sequence startcode. In other words, for V4L2_PIX_FMT_VC1_ANNEX_L, the vpu doesn't support dynamic resolution change. Fixes: 145e9363 ("media: amphion: implement malone decoder rpc interface") Signed-off-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Ming Qian authored
1. prevent to allocate buffer to firmware during abort 2. release buffer when clear the slots Fixes: 6de8d628 ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by:
-
Ezequiel Garcia authored
Commit 1f82f2df ("media: hantro: Enable H.264 on Rockchip VDPU2") enabled H.264 on some SoCs with VDPU2 cores. This had the side-effect of exposing H.264 coded format as supported on RK3399. Fix this and clarify how the codec is explicitly disabled on RK3399 on this driver. Fixes: 1f82f2df ("media: hantro: Enable H.264 on Rockchip VDPU2") Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by:
-
Akira Yokosawa authored
The \endgroup command at the bottom of a table added in commit 5374d8fb ("media: Add P010 video format") doesn't have a corresponding \begingroup command preceding it. This imbalance causes an build error in "make pdfdocs". Fix the issue by removing it. Signed-off-by:
Akira Yokosawa <akiyks@gmail.com> Fixes: 5374d8fb ("media: Add P010 video format") Cc: Benjamin Gaignard <benjamin.gaignard@collabora.com> Cc: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung SoC JPEG codec bindings to DT schema. The original bindings were quite old and incomplete, so change during conversion: 1. Add typical (already used) properties like iommus and power domains. 2. Document samsung,exynos4212-jpeg compatible (already used in DTS and driver). 3. List clocks per each variant. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Ming Qian authored
Don't set last_buffer_dequeued during dynamic resolution change, otherwise it may be cleared in handling resolution change, as streamoff may be called in dynamic resolution change. Normally, this does not happen. But we encounter a special testcase, User issue V4L2_DEC_CMD_STOP after enqueue one buffer that only contains codec config header, but not any frame data. So VPU report the parsed resolution, then report the eos event. So driver should notify user to handle resolution change first, after it's handled, set the last_buffer_dequeued. then the user can exit decoding normally. Otherwise the user may be stalled. Fixes: 6de8d628 ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by:
-
Chen-Yu Tsai authored
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: faddaa73 ("media: mediatek: vcodec: Initialize decoder parameters after getting dec_capability") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by:
-
Chen-Yu Tsai authored
Right now the decoder maintains two separate lists for supported pixel formats and frame sizes. Getting the supported frame sizes for the current set format is a bit convoluted, requiring a search through the separate frame size list. The frame sizes are used to clamp and align requested resolutions. Instead, the frame size structure could be embedded inside the pixel format structure. Getting one also gets the other. And since the the driver already keeps pointers to the current set format, getting the frame sizes becomes straightforward. Do just that. Move v4l2_frmsize_stepwise inside mtk_video_fmt, and get rid of mtk_codec_framesizes. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Chen-Yu Tsai authored
This partially reverts commit b018be06 ("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: b018be06 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by:
-
Chen-Yu Tsai authored
In commit b018be06 ("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: b018be06 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by:
-
Chen-Yu Tsai authored
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 authored
This partially reverts commit b018be06 ("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: b018be06 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by:
-
Chen-Yu Tsai authored
stepwise_fhd is the reference framesize variable, and should not be altered. Make it constant. Fixes: ("76250b48 media: mediatek: vcodec: Getting supported decoder format types") Signed-off-by: -
Laurent Pinchart authored
None of the shared helpers are used anymore. Make this official by dropping inclusion of imx-media.h. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Rui Miguel Silva <rmfrfs@gmail.com> Tested-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
Laurent Pinchart authored
The only event that the driver allows subscribing to, V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR, is never generated. Drop events support. Signed-off-by:
-
Laurent Pinchart authored
Inline the imx7_csi_enum_pixel_formats() function in its only caller. Signed-off-by:
-
Laurent Pinchart authored
The driver won't accept unsupported pixel formats, there's thus no need to validate it in imx7_csi_pad_link_validate(). Signed-off-by:
-
Laurent Pinchart authored
The device supports 14-bit greyscale formats the same way it supports 14-bit Bayer formats. Signed-off-by:
-
Laurent Pinchart authored
The list of supported formats comes from helpers shared with the i.MX6 IPUv3 and is incorrect in multiple regards: - 10-, 12- and 14-bit Bayer formats are stored in memory as SBGGR10, SBGGR12 and SBGGR14 respectively (plus components permutations), not SBGGR16. Same thing for greyscale formats. - 16-bit RAW formats are not supported by the hardware. Fix the supported formats table. Signed-off-by:
-
Laurent Pinchart authored
When trying a format on the video node, if the requested pixel format isn't supported, fallback to the default with a simpler logic. Signed-off-by:
-
Laurent Pinchart authored
Inline the imx7_csi_init_mbus_fmt() function in its only caller. This allows simplifying the code. Signed-off-by:
-
Laurent Pinchart authored
The imx7_csi_pixfmt cycles field is never used nor set, the bayer field is never used, and the planar field is never set. Drop them. Signed-off-by:
-
Laurent Pinchart authored
All the format lookup functions are called with a ANY selector, drop selector support. Signed-off-by:
-
Laurent Pinchart authored
When trying a format on the subdev sink pad, if the requested media bus code isn't supported, fallback to the default with a simpler logic. Signed-off-by:
-
Laurent Pinchart authored
Define a macro for the default media bus code and use it through the driver to replace a hardcoded value and a dynamic query from the pixel_formats table. Signed-off-by:
-
Laurent Pinchart authored
Use the same default image width and height for both the CSI subdev and the video node to achieve a consistent default through the driver. Signed-off-by:
-
Laurent Pinchart authored
A large number of formats defined in the pixel_formats array are not supported, as shown by the switch-case check in imx7_csi_pad_link_validate(). Drop them. Signed-off-by:
-
Laurent Pinchart authored
The formats specific to the IPUv3 are not supported by the CSI bridge. Drop them, along with the related code. Signed-off-by:
-
Laurent Pinchart authored
The imx7_csi_try_colorimetry() function supports the unrelated image converter hardware as it originates from shared helpers. Drop that. Signed-off-by:
-
Laurent Pinchart authored
Replace the enum ipu_color_space cs field in struct imx7_csi_pixfmt with a bool yuv field. This decouples the driver from the unrelated IPUv3 headers. Signed-off-by:
-
Laurent Pinchart authored
To prepare for code refactoring, copy the format helpers used by this driver from imx-media-utils.c. Rename structures and functions to avoid name clashes, no functional change intended. Signed-off-by:
-
Laurent Pinchart authored
The kernel memory allocators already complain loudly to the log when allocation fails. There's no need for an additional message. Signed-off-by:
-
Laurent Pinchart authored
Decouple from the IMX7_CSI_VIDEO_DEF_PIX_WIDTH, IMX7_CSI_VIDEO_DEF_PIX_HEIGHT and IMX_MEDIA_EOF_TIMEOUT macros defined in shared helpers by duplicating them in the imx7-media-csi driver, with a rename to avoid name clashes. No functional change intended. Signed-off-by:
-
