- 27 Jan, 2021 40 commits
-
-
Dikshita Agarwal authored
Add support to dump video FW region during FW crash using devcoredump helpers. Signed-off-by:
Dikshita Agarwal <dikshita@codeaurora.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Zou Wei authored
Fix the following sparse warning: hfi_plat_bufs_v6.c:1242:5: warning: symbol 'bufreq_enc' was not declared. Should it be static? Signed-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
-
Colin Ian King authored
In the case where plat->codecs is NULL the variable count is uninitialized but is being checked to see if it is 0. Fix this by initializing count to 0. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: e2992926 ("media: venus: Get codecs and capabilities from hfi platform") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Michael Tretter authored
The Allegro Codec supports HEVC encoding. The messages to the MCU are the same for H.264 and HEVC, but some options have to be changed. These are actually only a few options. The driver, however, must add the HEVC VPS/SPS/PPS NAL Units to the coded stream and must properly provide the HEVC format and controls to user space. [hverkuil: fix warning for wrong enum type (h264 instead of hevc)] Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Michael Tretter authored
These controls are specific to H.264 and shall only be activated, if the coded format is H.264. Signed-off-by:
-
Michael Tretter authored
The HEVC Non-VCL NAL units require more space than the H.264 Non-VCL NAL units. Therefore, the driver needs to reserve more space in front of the actual coded data that is written by the hardware codec. Increase the offset that shall be used by the hardware codec from 64 bytes to 128 bytes which is as arbitrary as before. Signed-off-by:
-
Michael Tretter authored
The maximum bitrate and the size of the CPB are dependent on the level. As the levels differ between the different codecs, the functions to get the maximum bitrate and CPB must be codec specific, too. Rename the functions to make it obvious that the function are only valid for H.264. Signed-off-by:
-
Michael Tretter authored
The driver only supports CAVLC for H.264, but HEVC only uses CABAC. As the driver has to explicitly tell the MCU to use CABAC for HEVC, add a helper function to get the entropy mode. Signed-off-by:
-
Michael Tretter authored
V4L2 specifies different controls for the QP values of different codecs. Simplify users that just care for the QP values by providing accessor function that return the correct control based on the currently set codec. Signed-off-by:
-
Michael Tretter authored
The profile and level are straight copies from the v4l2-ctrls. Avoid duplication and directly read the value of the v4l2-ctrl. Signed-off-by:
-
Michael Tretter authored
The cpb_size and the gop_size are straight copies of the values in the v4l2-ctrls. To avoid this duplication, directly get the values from the v4l2-ctrls and remove the copies. Signed-off-by:
-
Michael Tretter authored
The cbp_size_value_minus1 in the SPS can scaled using cpb_size_scale to reduce the number of bits necessary to encode the value. For simplicity, the scaling was set to 1. Restructure to the code to make it easier to drop the cbp_size from the channel and as we are at it, also properly implement the scaling. Signed-off-by:
-
Michael Tretter authored
As the driver now uses the v4l2-ctrls to setup the channel, there is no need to explicitly set the bitrate. The initial bitrate is now set via the same path as if it is set from userspace using the v4l2-ctrl. Signed-off-by:
-
Michael Tretter authored
v4l2_ctrl_handler_setup() calls s_ctrl for all controls of the handler. This ensures that the channel is initialized using the default values of the v4l2-ctrls. Signed-off-by:
-
Michael Tretter authored
The log2_max_poc field is used to set log2_max_pic_order_cnt_lsb_minus4 for the coded stream. It has an allowed range of 0 to 12. param contains the value without the minus4, but since firmware version 2019.1, the value has to be log2_max_pic_order_cnt_lsb - 1, presumably to fit the maximum value of 16 into a 4 bit field. The driver does not support firmware version 2019.1. Thus, change the behaviour starting from firmware version 2019.2. Signed-off-by:
-
Michael Tretter authored
There are several encoding options that are hard coded in the parameter that is used to configure the hardware codec. However, some of the options must be written to the SPS/PPS by the driver. Furthermore, some of the options depend on the codec that is used (i.e. H.264 or HEVC). Therefore, move options that depend on the codec to the channel and add constants for options that are independent of the codec but must be written to the SPS/PPS. Signed-off-by:
-
Michael Tretter authored
A format change (i.e. the frame size or the codec) has multiple effects on a channel: - The available controls - The limits of the available controls - The default encoding options To avoid scattering the changes all over the driver, add a new function that goes over the channel and does all required adjustments. Signed-off-by:
-
Michael Tretter authored
In order to support different codecs, the driver must support changing the format on CAPTURE. Therefore, the driver needs to handle S_FMT on CAPTURE. As the driver will have a different number of formats for OUTPUT and CAPTURE, split the check for the format index in ENUM_FMT into CAPTURE and OUTPUT. Signed-off-by:
-
Michael Tretter authored
When encoding a video as HEVC, the allegro driver needs to generate the Non-VCL NAL units for HEVC. Do the same as for H.264 and add a module that takes C structs for the VPS/SPS/PPS and encodes the fields as RBPS as specified by "ITU-T Rec. H.265 (02/2018) high efficiency video coding". [hverkuil: add missing static for nal_hevc_write/read_start_code_prefix] [hverkuil: fix typo: pps -> vps in nal_hevc_write_vps] Signed-off-by:
-
Michael Tretter authored
Allow generators to explicitly signal an error if the C structs contain unsupported or invalid fields. Signed-off-by:
-
Michael Tretter authored
The RBSP structure is the same for HEVC and H.264. In order to be able to reuse the RBSP handler for generating HEVC NAL units, extract the functions from the H.264 generator. Signed-off-by:
-
Jacopo Mondi authored
Commit 1b5071af ("media: dt-bindings: media: i2c: Rename ov5647.yaml") renamed the bindings file but did not update the Id: field there. Fix it by using the new filename. Fixes: 1b5071af ("media: dt-bindings: media: i2c: Rename ov5647.yaml") Signed-off-by:
Jacopo Mondi <jacopo@jmondi.org> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Laurent Pinchart authored
Make the V4L2 async framework a bit more robust by allowing to unregister a non-registered async subdev. Otherwise the v4l2_async_cleanup() will attempt to delete the async subdev from the subdev_list with the corresponding list_head not initialized. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Lad Prabhakar authored
Fix OV772x build breakage by selecting V4L2_FWNODE config: ia64-linux-ld: drivers/media/i2c/ov772x.o: in function `ov772x_probe': ov772x.c:(.text+0x1ee2): undefined reference to `v4l2_fwnode_endpoint_alloc_parse' ia64-linux-ld: ov772x.c:(.text+0x1f12): undefined reference to `v4l2_fwnode_endpoint_free' ia64-linux-ld: ov772x.c:(.text+0x2212): undefined reference to `v4l2_fwnode_endpoint_alloc_parse' Fixes: 8a10b4e3 ("media: i2c: ov772x: Parse endpoint properties") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by:
-
Ezequiel Garcia authored
There is currently little to no information available about the reasons why a v4l2-async device hasn't probed completely. Inspired by the "devices_deferred" debugfs file, add a file to list information about the subdevices that are on waiting lists, for each notifier. This is useful to debug v4l2-async subdevices and notifiers, for instance when doing device bring-up. For instance, a typical output would be: $ cat /sys/kernel/debug/video4linux/pending_async_subdevices ipu1_csi1: [fwnode] dev=20e0000.iomuxc-gpr:ipu1_csi1_mux, node=/soc/bus@2000000/iomuxc-gpr@20e0000/ipu1_csi1_mux ipu1_csi0: [fwnode] dev=20e0000.iomuxc-gpr:ipu1_csi0_mux, node=/soc/bus@2000000/iomuxc-gpr@20e0000/ipu1_csi0_mux imx6-mipi-csi2: [fwnode] dev=1-003c, node=/soc/bus@2100000/i2c@21a4000/camera@3c imx-media: Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
-
Ezequiel Garcia authored
Custom/driver-specific v4l2-async match support was introduced in 2013, as V4L2_ASYNC_BUS_CUSTOM. This type of match never had any user, so it's fair to conclude it's not required and that safe for removal. If the support is ever needed, it can always be restored. Suggested-by:
-
Joe Perches authored
trace isn't a good name as it's not a trace mechanism, it is a typical debug mechanism. Rename uvc_trace/uvc_trace_cont macros to uvc_dbg/uvc_dbg_cont. Rename uvc_trace_param to uvc_dbg_param Rename UVC_TRACE_<FOO> defines to UVC_DBG_<FOO> Use ## concatenation in uvc_dbg macros to avoid overly long and repetitive UVC_DBG uses Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Ricardo Ribalda authored
Instead of calling prink() inside uvc_trace, use dev_printk(), which adds context to the output. Now that we are at it, regroup the strings so the messages can be easily "grepable". Suggested-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
-
Ricardo Ribalda authored
Remove all the duplicated code around printk(KERN_CONT, with a new macro. Suggested-by:
-
Ricardo Ribalda authored
Replace all the uses of printk() and uvc_printk() with its equivalent dev_ alias macros. Modify uvc_warn_once() macro to use dev_info instead printk(). They are more standard across the kernel tree and provide more context about the error. Suggested-by:
-
Ricardo Ribalda authored
Add a new control and mapping for Privacy controls connected to UVC_GUID_EXT_GPIO_CONTROLLERs. Signed-off-by:
-
Ricardo Ribalda authored
Some devices can implement a physical switch to disable the input of the camera on demand. Think of it like an elegant privacy sticker. The system can read the status of the privacy switch via a GPIO. It is important to know the status of the switch, e.g. to notify the user when the camera will produce black frames and a videochat application is used. In some systems, the GPIO is connected to the main SoC instead of the camera controller, with the connection reported by the system firmware (ACPI or DT). In that case, the UVC device isn't aware of the GPIO. We need to implement a virtual entity to handle the GPIO fully on the driver side. For example, for ACPI-based systems, the GPIO is reported in the USB device object: Scope (\_SB.PCI0.XHCI.RHUB.HS07) { /.../ Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0064 } }) Name (_DSD, Package (0x02) // _DSD: Device-Specific Data { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, Package (0x01) { Package (0x02) { "privacy-gpio", Package (0x04) { \_SB.PCI0.XHCI.RHUB.HS07, Zero, Zero, One } } } }) } Signed-off-by: -
Ricardo Ribalda authored
Allows controls to get their properties and current value from an entity-defined function instead of via a query to the USB device. Signed-off-by:
-
Ricardo Ribalda authored
Split the functionality of void uvc_ctrl_status_event_work in two, so it can be called by functions outside interrupt context and not part of an URB. Signed-off-by:
-
Ricardo Ribalda authored
Avoid an underflow while calculating the number of inputs for entities with zero pads. Signed-off-by:
-
Ricardo Ribalda authored
Increase the size of the id, to avoid collisions with entities implemented by the driver that are not part of the UVC device. Entities exposed by the UVC device use IDs 0-255, extra entities implemented by the driver (such as the GPIO entity) use IDs 256 and up. Signed-off-by:
-
Ricardo Ribalda authored
Instead of having multiple copies of the entity guid on the code, move it to the entity structure. Signed-off-by:
-
Laurent Pinchart authored
The Renkforce RF AC4K 300 Action Cam 4K reports invalid bFormatIndex and bFrameIndex values when negotiating the video probe and commit controls. The UVC descriptors report a single supported format and frame size, with bFormatIndex and bFrameIndex both equal to 2, but the video probe and commit controls report bFormatIndex and bFrameIndex set to 1. The device otherwise operates correctly, but the driver rejects the values and fails the format try operation. Fix it by ignoring the invalid indices, and assuming that the format and frame requested by the driver are accepted by the device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=210767 Fixes: 8a652a17 ("media: uvcvideo: Ensure all probed info is returned to v4l2") Reported-by:
Till Dörges <doerges@pre-sense.de> Signed-off-by:
-
Laurent Pinchart authored
The Shenzhen Aoni Electronic Co.,Ltd 2K FHD camera reports a UVC 1.10 version, but implements UVC 1.0a as shown by the UVC probe control being 26 bytes long. Force the UVC version for that device. Signed-off-by:
Doncho Minkov <donchominkov@gmail.com> Tested-by:
-
Dan Carpenter authored
Syzbot discovered that the probe error handling doesn't clean up the resources allocated in zr364xx_board_init(). There are several related bugs in this code so I have re-written the error handling. 1) Introduce a new function zr364xx_board_uninit() which cleans up the resources in zr364xx_board_init(). 2) In zr364xx_board_init() if the call to zr364xx_start_readpipe() fails then release the "cam->buffer.frame[i].lpvbits" memory before returning. This way every function either allocates everything successfully or it cleans up after itself. 3) Re-write the probe function so that each failure path goto frees the most recent allocation. That way we don't free anything before it has been allocated and we can also verify that everything is freed. 4) Originally, in the probe function the "cam->v4l2_dev.release" pointer was set to "zr364xx_release" near the start but I moved that assignment to the end, after everything had succeeded. The release function was never actually called during the probe cleanup process, but with this change I wanted to make it clear that we don't want to call zr364xx_release() until everything is allocated successfully. Next I re-wrote the zr364xx_release() function. Ideally this would have been a simple matter of copy and pasting the cleanup code from probe and adding an additional call to video_unregister_device(). But there are a couple quirks to note. 1) The probe function does not call videobuf_mmap_free() and I don't know where the videobuf_mmap is allocated. I left the code as-is to avoid introducing a bug in code I don't understand. 2) The zr364xx_board_uninit() has a call to zr364xx_stop_readpipe() which is a change from the original behavior with regards to unloading the driver. Calling zr364xx_stop_readpipe() on a stopped pipe is not a problem so this is safe and is potentially a bugfix. Reported-by: syzbot+b4d54814b339b5c6bbd4@syzkaller.appspotmail.com Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
