- 12 Apr, 2023 12 commits
-
-
Laurent Pinchart authored
Structures passed to subdev pad operations are all zero-initialized, but not always with the same kind of code constructs. While most drivers used designated initializers, which zero all the fields that are not specified, when declaring variables, some use memset(). Those two methods lead to the same end result, and, depending on compiler optimizations, may even be completely equivalent, but they're not consistent. Improve coding style consistency by using designated initializers instead of calling memset(). Where applicable, also move the variables to inner scopes of for loops to ensure correct initialization in all iterations. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Lad Prabhakar <prabhakar.csengg@gmail.com> # For am437x Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Laurent Pinchart authored
Several drivers call subdev pad operations, passing structures that are not fully zeroed. While the drivers initialize the fields they care about explicitly, this results in reserved fields having uninitialized values. Future kernel API changes that make use of those fields thus risk breaking proper driver operation in ways that could be hard to detect. To avoid this, make the code more robust by zero-initializing all the structures passed to subdev pad operation. Maintain a consistent coding style by preferring designated initializers (which zero-initialize all the fields that are not specified) over memset() where possible, and make variable declarations local to inner scopes where applicable. One notable exception to this rule is in the ipu3 driver, where a memset() is needed as the structure is not a local variable but a function parameter provided by the caller. Not all fields of those structures can be initialized when declaring the variables, as the values for those fields are computed later in the code. Initialize the 'which' field in all cases, and other fields when the variable declaration is so close to the v4l2_subdev_call() call that it keeps all the context easily visible when reading the code, to avoid hindering readability. Signed-off-by:
-
Laurent Pinchart authored
Variable initialization code in notify_src_chg() is incorrectly indented. Fix it. Signed-off-by:
-
Laurent Pinchart authored
Commit 0d346d2a ("media: v4l2-subdev: add subdev-wide state struct") applied a large media tree-wide change produced by coccinelle. It was so large that a set of identical indentation issues went unnoticed during review. Fix them. While at it, and because it's easy to review both changes together, add a trailing comma for the last (and only) struct member initialization of the related structures, to avoid future changes should new fields need to be initialized. Fixes: 0d346d2a ("media: v4l2-subdev: add subdev-wide state struct") Signed-off-by:
-
Fritz Koenig authored
According to msm_media_info.h the correct alignment for the stride of P010 buffers is 128. Signed-off-by:
Fritz Koenig <frkoenig@chromium.org> Reviewed-by:
Vikash Garodia <quic_vgarodia@quicinc.com> Signed-off-by:
Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by:
-
Dikshita Agarwal authored
Add handling for below commands in encoder: 1. V4L2_ENC_CMD_STOP 2. V4L2_ENC_CMD_START Signed-off-by:
Dikshita Agarwal <quic_dikshita@quicinc.com> Signed-off-by:
-
Viswanath Boma authored
Currently QP range set from client is not communicated to video firmware. Add support for the QP range HFI to set the same to firmware. Signed-off-by:
Viswanath Boma <quic_vboma@quicinc.com> Signed-off-by:
-
Javier Martinez Canillas authored
Commit 9593126d ("media: venus: Add a handling of QC08C compressed format") and commit cef92b14 ("media: venus: Add a handling of QC10C compressed format") added support for the QC08C and QC10C compressed formats respectively. But these also caused a regression, because the new formats where added at the beginning of the vdec_formats[] array and the vdec_inst_init() function sets the default format output and capture using fixed indexes of that array: static void vdec_inst_init(struct venus_inst *inst) { ... inst->fmt_out = &vdec_formats[8]; inst->fmt_cap = &vdec_formats[0]; ... } Since now V4L2_PIX_FMT_NV12 is not the first entry in the array anymore, the default capture format is not set to that as it was done before. Both commits changed the first index to keep inst->fmt_out default format set to V4L2_PIX_FMT_H264, but did not update the latter to keep .fmt_out default format set to V4L2_PIX_FMT_NV12. Rather than updating the index to the current V4L2_PIX_FMT_NV12 position, let's reorder the entries so that this format is the first entry again. This would also make VIDIOC_ENUM_FMT report the V4L2_PIX_FMT_NV12 format with an index 0 as it did before the QC08C and QC10C formats were added. Fixes: 9593126d ("media: venus: Add a handling of QC08C compressed format") Fixes: cef92b14 ("media: venus: Add a handling of QC10C compressed format") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Viswanath Boma authored
Aligned the mismatch of persist1 and scratch1 buffer calculation, as per the firmware requirements. Signed-off-by:
Vikash Garodia <vgarodia@qti.qualcomm.com> Signed-off-by:
Nathan Hebert <nhebert@chromium.org> Signed-off-by:
-
Michał Krawczyk authored
The decoder driver should clear the last_buffer_dequeued flag of the capture queue upon receiving V4L2_DEC_CMD_START. The last_buffer_dequeued flag is set upon receiving EOS (which always happens upon receiving V4L2_DEC_CMD_STOP). Without this patch, after issuing the V4L2_DEC_CMD_STOP and V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if the buffers are completed by the hardware. Fixes: beac8290 ("media: venus: make decoder compliant with stateful codec API") Signed-off-by:
Michał Krawczyk <mk@semihalf.com> Signed-off-by:
-
Florian Fainelli authored
The driver was intended from the start to be a wake-up source for the system, however due to the absence of a suitable call to device_set_wakeup_capable(), the device_may_wakeup() call used to decide whether to enable the GPIO interrupt as a wake-up source would never happen. Lookup the DT standard "wakeup-source" property and call device_init_wakeup() to ensure the device is flagged as being wakeup capable. Reported-by:
Matthew Lear <matthew.lear@broadcom.com> Fixes: fd0f6851 ("[media] rc: Add support for GPIO based IR Receiver driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Florian Fainelli authored
The GPIO IR receiver can be used as a wake-up source for the system, document that. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
- 11 Apr, 2023 28 commits
-
-
Alexander Stein authored
Also dev_err_probe message require a trailing \n. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
-
Sakari Ailus authored
Document the firmware file names for CCS static data for CCS, SMIA++ and SMIA devices. Signed-off-by:
-
Sakari Ailus authored
MIPI CCS uses a 16-bit MIPI manufacturer identifier for firmware filenames compared to older 8-bit identifier used by SMIA. The requested firmware files used the MIPI manufacturer ID even for SMIA compliant devices, effectively making the manufacturer ID 0. While CCS static data is a feature of CCS 1.1, it has no hardware dependencies. Making this feature available for SMIA devices helps adding support for them and avoids requesting ill-generated CCS static data file names. The files are named as: ccs/smiapp-module-vv-mmmm-rrrr.fw, ccs/smiapp-sensor-vv-mmmm-rr.fw and ccs/smia-sensor-vv-mmmm-rr.fw where vv is the manufacturer ID, mmmm is the model ID and rr or rrrr is the revision number. Signed-off-by:
-
Sakari Ailus authored
Some modules don't have any model identification information in the register address space. The driver as a SMIA++ driver attempted to use sensor information in this case. This workaround is definitely not for CCS devices. Signed-off-by:
-
Sakari Ailus authored
Read 16-bit sensor revision number if the 8-bit register has value 0. Signed-off-by:
-
Sakari Ailus authored
Add V4L2 controls (currently CAMERA_SENSOR_ROTATION and CAMERA_SENSOR_ORIENTATION) from properties. Signed-off-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
No longer mirror flipping controls if the sensor is mounted upside down. This way the behaviour of the flipping controls and rotation of the sensor are aligned with the rest of the drivers. Signed-off-by:
-
Jacopo Mondi authored
The "rotation" fwnode device property is intended to allow specify the sensor's physical mounting rotation, so that it can be exposed through the read-only V4L2_CID_CAMERA_SENSOR_ROTATION control and applications can decide how to compensate for that. The imx258 driver has read-only VFLIP and HFLIP enabled, resulting in a 180 degrees image rotation being produced by the sensor. But this doesn't imply that the physical mounting rotation should match the driver's implementation. Now that the driver registers V4L2_CID_CAMERA_SENSOR_ROTATION and V4L2_CID_HFLIP/VFLIP correctly, userspace has all the required information to handle the rotation correctly, hence it is not necessary to require the 'rotation' property to be fixed to 180 degrees in DTS. Signed-off-by:
-
Jacopo Mondi authored
Register controls for V4L2_CID_HFLIP and V4L2_CID_VFLIP. The controls are registered as read-only and enabled by default, as the driver embeds a 180 degrees rotation in its programming sequences and only supports that mode of operations. Signed-off-by:
-
Sakari Ailus authored
Dongchun's e-mail mailbox is no longer available, assign the maintainership to myself. The following message to <dongchun.zhu@mediatek.com> was undeliverable. The reason for the problem: 5.1.0 - Unknown address error 550-'Relaying mail to dongchun.zhu@mediatek.com is not allowed' Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Sakari Ailus authored
Dongchun's e-mail address is no longer valid, assign the ov8856 driver to myself. Signed-off-by:
-
Bingbu Cao authored
Add more camera sensors into the supported camera sensors list to make cio2-bridge to support more camera sensors. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Reviewed-by:
Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by:
-
Jim Lai authored
Adding additional cropped 2592x1444 resolution for QHD output from Hi556 sensor Also implement the get_selection pad operation for the Hi556 sensor driver. The supported targets report the sensor's native size, the crop default rectangle and the crop rectangle. Signed-off-by:
Jim Lai <jim.lai@intel.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The struct venus_format does not have a "opp_table" field. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Wolfram Sang authored
R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support and disable booting for this SoC. Public users only have ES2 onwards. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
Wolfram Sang authored
R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support and disable booting for this SoC. Public users only have ES2 onwards. Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Wolfram Sang authored
R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support and disable booting for this SoC. Public users only have ES2 onwards. Reviewed-by:
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Bingbu Cao authored
In current cio2-bridge, it is using the hid name to register software node and software node will create kobject and sysfs entry according to the node name, if there are multiple sensors and VCMs which are sharing same HID name, it will cause the software nodes registration failure: sysfs: cannot create duplicate filename '/kernel/software_nodes/dw9714' ... Call Trace: software_node_register_nodes cio2_bridge_init ... kobject_add_internal failed for dw9714 with -EEXIST, don't try to register things with the same name in the same directory. One solution is appending the sensor link(Mipi Port) in SSDB as suffix of the node name to fix this problem. Signed-off-by:
-
Laurent Pinchart authored
The v4l2_create_fwnode_links_to_pad() helper requires the sink pad passed to it to belong to a subdev. This requirement can be lifted easily. Make the function usable for non-subdev sinks, which allows using it with video_device sinks. Signed-off-by:
-
Laurent Pinchart authored
The ADV7604, ADV7611 and ADV7612 software manuals document the CP_HUE value differently: - For ADV7604 and ADV7611, the hue is specified as an unsigned 8-bit value, and calculated as (CP_HUE[7:0] * 180) / 256 - 90 with the range set to [-90°, 90°]. Additionally, the values 0x00, 0x0f and 0xff are documented as corresponding to -90°, 0° and 90° respectively. - For ADV7612, the hue is specified as a signed 8-bit value in the range [0°, 360°[ without any formula. Additionally, the value 0x00 is documented as corresponding to 0°. The ADV7604 and ADV7611 documentation is clearly wrong as the example values don't correspond to the formula. Furthermore, the [-90°, 90°] range seems incorrect as it would cover only half of the hue space. The ADV7612 documentation is better, although the range should likely be [-180°, 180°[ if the value is signed. Given that the values wrap around, this makes no difference in practice. The hue values have been verified on ADV7612 to follow the documentation. There is a high chance they do as well on ADV7604 and ADV7611. In any case, all software manuals document the register as 8-bit, so the current range of the V4L2 hue control [0, 128] is not correct. Expand it to cover the full 8-bit space, using unsigned values to avoid breaking any application that may rely on 128 being a valid value. Signed-off-by:
-
Laurent Pinchart authored
The video adjustments (contrast, brightness, saturation and hue) are ignored by default by the device when the VID_ADJ_EN bit is clear. The corresponding V4L2 controls exposed by the drivers have thus no effect. Fix this by setting the VID_ADJ_EN bit. Signed-off-by:
-
Luca Weiss authored
In some setups XSHUTDOWN is connected to DOVDD when it's unused, therefore treat the reset gpio as optional. Reviewed-by:
Luca Weiss <luca@z3ntu.xyz> Signed-off-by:
-
Luca Weiss authored
Convert the text-based dt-bindings to yaml. Changes from original txt: * Take wording for various properties from other yaml bindings, this removes e.g. volt amount from schema since it isn't really relevant and the datasheet is a better source. * Don't make reset-gpios a required property since it can be tied to DOVDD instead. Reviewed-by:
-
Luca Weiss authored
With the upcoming conversion of ov2685 to dt-schema let's complete the example so validation succeeds. At the same time fix the indentation of the port node in this example. Acked-by:
-
Jason Kim authored
In the file mc-device.c, the function media_device_register_entity_notify() does not need to have the __must_check attribute since it returns only a value of 0. Therefore, we can remove this attribute and change the function's return type. Signed-off-by:
Jason Kim <sukbeom.kim@gmail.com> Signed-off-by:
-
Wei Chen authored
hi846_init_controls doesn't clean the allocated ctrl_hdlr in case there is a failure, which causes memleak. Add v4l2_ctrl_handler_free to free the resource properly. Fixes: e8c08826 ("media: i2c: add driver for the SK Hynix Hi-846 8M pixel camera") Signed-off-by:
Wei Chen <harperchen1110@gmail.com> Reviewed-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by:
-
Ricardo Ribalda authored
It the device is probed in non-zero ACPI D state, the module identification is delayed until the first streamon. The module identification has two parts: deviceID and version. To rea the version we have to enable OTP read. This cannot be done during streamon, becase it modifies REG_MODE_SELECT. Since the driver has the same behaviour for all the module versions, do not read the module version from the sensor's OTP. Cc: stable@vger.kernel.org Fixes: 0e014f1a ("media: ov8856: support device probe in non-zero ACPI D state") Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
-
