- 24 Apr, 2022 40 commits
-
-
Dikshita Agarwal authored
Add support for intra-refresh type v4l2 control. Signed-off-by:
Dikshita Agarwal <quic_dikshita@quicinc.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Dikshita Agarwal authored
Add a control to set intra-refresh type. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Acked-by:
-
Stanimir Varbanov authored
When recalculate output buffer size we have to take into account the output resolution from the firmware received during event change notification. Signed-off-by:
-
Stanimir Varbanov authored
This adds QC10C compressed pixel format in the Venus driver, and make it possible to discover from v4l2 clients. Note: The QC10C format will be enumerable via VIDIOC_ENUM_FMT when the bitstream is 10-bits and the headers are parsed. Signed-off-by:
-
Stanimir Varbanov authored
In multistream mode HFI supports TP10_UBWC on output2. Correct this in supported formats capabilities list. Signed-off-by:
-
Stanimir Varbanov authored
This adds QC08C compressed pixel format in the Venus driver, and make it possible to discover from v4l2 clients. Signed-off-by:
-
Stanimir Varbanov authored
Add a helper to check supported pixel format per codec and session type. Signed-off-by:
-
Stanimir Varbanov authored
Add custom Qualcomm raw compressed pixel formats. They are used in Qualcomm SoCs to optimize the interconnect bandwidth. Signed-off-by:
-
Vikash Garodia authored
Video decoder driver auto-suspends the hardware if there is no exchange of command or response for certain amount of time. In auto suspended state, it becomes mandatory to power on the hardware before requesting it to process a command. The fix ensures the hardware is powered on during stop streaming. Signed-off-by:
Vikash Garodia <quic_vgarodia@quicinc.com> Signed-off-by:
-
Vikash Garodia authored
During reconfig (DRC) event from firmware, it is not guaranteed that all the DPB(internal) buffers would be released by the firmware. Some buffers might be released gradually while processing frames from the new sequence. These buffers now stay idle in the dpblist. In subsequent call to queue the DPBs to firmware, these idle buffers should not be queued. The fix identifies those buffers and free them. Signed-off-by:
Fritz Koenig <frkoenig@chromium.org> Signed-off-by:
-
Luca Weiss authored
If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Signed-off-by:
-
Luca Weiss authored
This error can appear with wrong configuration and is difficult to find as it just returns -ETIMEDOUT with no further message. Signed-off-by:
-
Philipp Zabel authored
Simplify the mux error path a bit by using dev_err_probe(). Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Kate Hsuan authored
An not calibrated x_start setting would result in an incorrect AWB grid configuration on a sensor when only the rightmost stripe is used. If the AWB grid coordinate is set to the rightmost stripe, for example, x_start is greater than 640, the AWB grid will be at the rightmost edge of the sensor. The AWB statistic will be fetched from the wrong place of the sensor and results in an incorrect AWB estimation result. Therefore, stripe offset should subtract from x_start to have a correct grid configuration for the rightmost stripe. Signed-off-by:
Kate Hsuan <hpa@redhat.com> Signed-off-by:
-
Ian Jamison authored
The documentation comment was inserted between the return type and the function name. Reunite the lines. Signed-off-by:
Ian Jamison <ian.dev@arkver.com> Fixes: db7ee32a ("[media] media-device.h: Improve documentation and update it") Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Masahiro Yamada authored
Commit b3b7a9f1 ("[media] media-device: Use u64 ints for pointers") added this #include <stdint.h>, presumably in order to use uintptr_t. Now that it is gone, we can compile this for userspace without <stdint.h>. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
-
Uwe Kleine-König authored
The only effect of returning an error code in an i2c remove callback is that the i2c core emits a generic warning and still removes the device. So even if disabling the regulator fails it's sensible to further cleanup and then return zero to only emit a single error message. This patch is a preparation for making i2c remove callbacks return void. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Zheyu Ma authored
When the driver fails to probe, we will get the following splat: [ 59.305988] ------------[ cut here ]------------ [ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 59.318362] Call Trace: [ 59.318582] <TASK> [ 59.318765] regulator_put+0x1f/0x30 [ 59.319058] devres_release_group+0x319/0x3d0 [ 59.319420] i2c_device_probe+0x766/0x940 Fix this by disabling the regulator in error handling. Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
-
Tom Rix authored
For spdx, remove leading space Replacements parametrize to parameterize Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Moses Christopher Bollavarapu authored
Currently, the driver ends the reg-val list with a 0xFF as a check to stop the loop. Instead an array of reg-vals can be used to avoid this check, by using the ARRAY_SIZE(arr) macro to obtain the length of the array and iterate over it. Signed-off-by:
Moses Christopher Bollavarapu <mosescb.dev@gmail.com> Signed-off-by:
-
Sakari Ailus authored
This reverts commit c09d776e. Revert the commit as it breaks runtime PM support on OF based systems. More fixes to the driver are needed. Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Reviewed-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Tomi Valkeinen authored
Add documentation about centrally managed subdev state. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by:
-
Tomi Valkeinen authored
Add v4l2_subdev_get_fmt() helper function which implements v4l2_subdev_pad_ops.get_fmt using active state. Subdev drivers that support active state and do not need to do anything special in their get_fmt op can use this helper directly for v4l2_subdev_pad_ops.get_fmt. Signed-off-by:
-
Tomi Valkeinen authored
It is common that media drivers call subdev ops in source subdevs, and pass NULL as the state. This was the way to indicate that the callee should use the callee's private active state. E.g.: v4l2_subdev_call(priv->source_sd, pad, get_fmt, NULL, &sd_fmt); Now that we have a real subdev active state in the v4l2_subdev struct, we want the caller to pass a proper state (when available). And furthermore, the state should be locked. This would mean changing all the callers, which is the long term goal. To fix this issue in the short term, let's add an extra wrapper layer to all v4l2_subdev_call_pad_wrappers which deal with states. These wrappers handle the state == NULL case by using the locked active state instead (when available). Signed-off-by:
-
Tomi Valkeinen authored
The V4L2 subdevs have managed without centralized locking for the state (previously pad_config), as the try-state is supposedly safe (although I believe two TRY ioctls for the same fd would race), and the active-state, and its locking, is managed by the drivers internally. We now have active-state in a centralized position, and need locking. Strictly speaking the locking is only needed for new drivers that use the new state, as the current drivers continue behaving as they used to. However, active-state locking is complicated by the fact that currently the real active-state of a subdev is split into multiple parts: the new v4l2_subdev_state, subdev control state, and subdev's internal state. In the future all these three states should be combined into one state (the v4l2_subdev_state), and then a single lock for the state should be sufficient. But to solve the current split-state situation we need to share locks between the three states. This is accomplished by using the same lock management as the control handler does: we use a pointer to a mutex, allowing the driver to override the default mutex. Thus the driver can do e.g.: sd->state_lock = sd->ctrl_handler->lock; before calling v4l2_subdev_init_finalize(), resulting in sharing the same lock between the states and the controls. The locking model for active-state is such that any subdev op that gets the state as a parameter expects the state to be already locked by the caller, and expects the caller to release the lock. Signed-off-by:
-
Tomi Valkeinen authored
At the moment when a subdev op is called, the TRY subdev state (subdev_fh->state) is passed as a parameter even for the ACTIVE case, or alternatively a NULL can be passed for ACTIVE case. This used to make sense, as the ACTIVE state was handled internally by the subdev drivers. We now have a state for the ACTIVE case in a standard place, and can pass that also to the drivers. This patch changes the subdev ioctls to either pass the TRY or ACTIVE state to the subdev. Unfortunately many drivers call ops from other subdevs, and implicitly pass NULL as the state, so this is just a partial solution. A coccinelle spatch could perhaps be created which fixes the drivers' subdev calls. For all current upstream drivers this doesn't matter, as they do not expect to get a valid state for ACTIVE case. But future drivers which support multiplexed streaming and routing will depend on getting a state for both active and try cases. For new drivers we can mandate that the pipelines where the drivers are used need to pass the state properly, or preferably, not call such subdev ops at all. However, if an existing subdev driver is changed to support multiplexed streams, the driver has to consider cases where its ops will be called with NULL state. The problem can easily be solved by using the v4l2_subdev_lock_and_get_active_state() helper, introduced in a follow up patch. Another follow up patch adds wrappers for pad ops dealing with subdev state, which automate the use of v4l2_subdev_lock_and_get_active_state() for cases where the state is NULL. Signed-off-by:
-
Tomi Valkeinen authored
The subdev state is now used for both try and active cases. Rename rename v4l2_subdev_get_try_* helpers to v4l2_subdev_get_pad_*. Temporary wapper helper macros are added to keep the drivers using v4l2_subdev_get_try_* compiling. The next step is to change the uses in th drivers, and then drop the helpers. Signed-off-by:
-
Tomi Valkeinen authored
Add a new 'active_state' field to struct v4l2_subdev to which we can store the active state of a subdev. This will place the subdev configuration into a known place, allowing us to use the state directly from the v4l2 framework, thus simplifying the drivers. Also add functions v4l2_subdev_init_finalize() and v4l2_subdev_cleanup(), which will allocate and free the active state. The functions are named in a generic way so that they can be also used for other subdev initialization work. Signed-off-by:
-
Tomi Valkeinen authored
v4l2_subdev_alloc_state() and v4l2_subdev_free_state() are not supposed to be used by the drivers. However, we do have a few drivers that use those at the moment, so we need to expose these functions for the time being. Prefix the functions with __ to mark the functions as internal. At the same time, rename them to v4l2_subdev_state_alloc and v4l2_subdev_state_free to match the style used for other functions like video_device_alloc() and media_request_alloc(). Signed-off-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Tomi Valkeinen authored
subdev_open() is inside #ifdef CONFIG_VIDEO_V4L2_SUBDEV_API, which depends on CONFIG_MEDIA_CONTROLLER, so there's no need for an extra Signed-off-by:
-
Tomi Valkeinen authored
Add comments after #endifs to clarify their scope. Signed-off-by:
-
Jacopo Mondi authored
The ov5645 driver reports as its unique supported format MEDIA_BUS_FMT_UYVY8_2X8, which is not correct as the sensor uses the MIPI CSI-2 serial bus. Fix that by using MEDIA_BUS_FMT_UYVY8_1X16 instead. Signed-off-by:
-
Hangyu Hua authored
media_gobj_destroy has already set graph_obj.mdev to NULL. There is no need to set it again. [Sakari Ailus: Remove extra newline, rewrap commit msg] Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Reviewed-by:
-
Umang Jain authored
Use an existing helper imgu_video_nodes_exit() on imgu-video-node initialization failure path to cleanup dummy buffers. Signed-off-by:
Umang Jain <umang.jain@ideasonboard.com> Reviewed-by:
-
Umang Jain authored
Reset the sequence number of imgu_video_device on stream start. Failing to do so results in sequence number getting incremented for consecutive stream on/off cycles. Signed-off-by:
-
Laurent Pinchart authored
Matching on device fwnode handles is deprecated in favour of endpoint fwnode handles. Switch the __v4l2_async_nf_add_fwnode_remote() function to use the latter. The match code handles backward compatibility by falling by to the device fwnode handle, so this shouldn't introduce any regression. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
Primarily request a specific revision of the IPU3 firmware that the driver is known to work with, irci_irci_ecr-master_20161208_0213_20170112_1500.bin. Some distros only ship this while others provide a symlink called ipu3-fw.bin, which the driver only requested previously. Signed-off-by:
-
Kate Hsuan authored
For the AF configuration, if the rightmost stripe is used, the AF scene will be at the incorrect location of the sensor. The AF coordinate may be set to the right part of the sensor. This configuration would lead to x_start being greater than the down_scaled_stripes offset and the leftmost stripe would be disabled and only the rightmost stripe is used to control the AF coordinate. If the x_start doesn't perform any adjustments, the AF coordinate will be at the wrong place of the sensor since down_scaled_stripes offset would be the new zero of the coordinate system. In this patch, if only the rightmost stripe is used, x_start should minus down_scaled_stripes offset to maintain its correctness of AF scene coordinate. Signed-off-by:
-
Laurentiu Palcu authored
When removing the max9286 module we get a kernel oops: Unable to handle kernel paging request at virtual address 000000aa00000094 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : i2c_mux_del_adapters+0x24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000 x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8 x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000 Call trace: i2c_mux_del_adapters+0x24/0xf0 max9286_remove+0x28/0xd0 [max9286] i2c_device_remove+0x40/0x110 __device_release_driver+0x188/0x234 driver_detach+0xc4/0x150 bus_remove_driver+0x60/0xe0 driver_unregister+0x34/0x64 i2c_del_driver+0x58/0xa0 max9286_i2c_driver_exit+0x1c/0x490 [max9286] __arm64_sys_delete_module+0x194/0x260 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x2c/0x94 el0_svc+0x28/0x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point to max9286_priv anymore but to v4l2_subdev. The change happened in max9286_init() which calls v4l2_i2c_subdev_init() later on... Besides fixing the max9286_remove() function, remove the call to i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make the necessary changes to max9286_init() so that it doesn't have to use i2c_get_clientdata() in order to fetch the pointer to priv. Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver") Signed-off-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Reviewed-by:
-
