media: verisilicon: Do not set context src/dst formats in reset functions
Setting context source and destination formats should only be done
in hantro_set_fmt_out() and hantro_set_fmt_cap() after check that
the targeted queue is not busy.
Remove these calls from hantro_reset_encoded_fmt() and
hantro_reset_raw_fmt() to clean the driver.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Yunfei Dong [Wed, 1 Feb 2023 07:33:16 +0000 (07:33 +0000)]
media: mediatek: vcodec: change lat thread decode error condition
If lat thread can't get lat buffer, it should be that current instance
don't be schedulded, the driver can't free the src buffer directly.
Fixes: 7b182b8d9c85 ("media: mediatek: vcodec: Refactor get and put capture buffer flow") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Yunfei Dong [Wed, 1 Feb 2023 07:33:15 +0000 (07:33 +0000)]
media: mediatek: vcodec: making sure queue_work successfully
Putting core work to work queue using queue_work maybe fail, call
queue_work again when the count of core work in work queue is less
than core_list_cnt, making sure all the buffer in core list can be
scheduled.
Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Yunfei Dong [Wed, 1 Feb 2023 07:33:12 +0000 (07:33 +0000)]
media: mediatek: vcodec: move lat_buf to the top of core list
Current instance will decode done when begin to wait lat buf full,
move the lat_buf of current instance to the top of core list to make
sure current instance's lat_buf will be used firstly.
Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Tue, 17 Jan 2023 02:31:54 +0000 (02:31 +0000)]
media: add RealVideo format RV30 and RV40
RealVideo, or also spelled as Real Video, is a suite of proprietary
video compression formats developed by RealNetworks -
the specific format changes with the version.
RealVideo codecs are identified by four-character codes.
RV30 and RV40 are RealNetworks' proprietary H.264-based codecs.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Thu, 12 Jan 2023 09:04:48 +0000 (09:04 +0000)]
media: amphion: support to decode sorenson spark video
Sorenson Spark is an implementation of H.263 for use
in Flash Video and Adobe Flash files.
amphion decoder can support it by insert some startcode
before sequence and picture.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Thu, 12 Jan 2023 09:04:47 +0000 (09:04 +0000)]
media: add Sorenson Spark video format
Sorenson Spark is an implementation of H.263 for use
in Flash Video and Adobe Flash files.
Sorenson Spark is an incomplete implementation of H.263.
It differs mostly in header structure and ranges of the coefficients.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Yunfei Dong [Sat, 18 Mar 2023 03:56:51 +0000 (03:56 +0000)]
media: mediatek: vcodec: Force capture queue format to MM21
While the decoder can produce frames in both MM21 and MT21C formats, only
MM21 is currently supported by userspace tools (like gstreamer and libyuv).
In order to ensure userspace keeps working after the SCP firmware is
updated to support both MM21 and MT21C formats, force the MM21 format for
the capture queue.
This is meant as a stopgap solution while dynamic format switching between
MM21 and MT21C isn't implemented in the driver.
Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Yunfei Dong [Sat, 18 Mar 2023 03:56:50 +0000 (03:56 +0000)]
media: mediatek: vcodec: Make MM21 the default capture format
Given that only the MM21 capture format is supported by userspace tools
(like gstreamer and libyuv), make it the default capture format.
This allows us to force the MM21 format even when a MM21 and MT21C capable
firmware is available (which is needed while dynamic format switching isn't
implemented in the driver), without causing the following regressions on
v4l2-compliance:
fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT
test VIDIOC_G_FMT: FAIL
fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT
test VIDIOC_TRY_FMT: FAIL
fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT
test VIDIOC_S_FMT: FAIL
Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Pin-yen Lin [Tue, 14 Mar 2023 10:22:41 +0000 (10:22 +0000)]
media: mediatek: vcodec: Use 4K frame size when supported by stateful decoder
After commit b018be06f3c7 ("media: mediatek: vcodec: Read max resolution
from dec_capability"), the stateful video decoder driver never really
sets its output frame size to 4K.
Parse the decoder capability reported by the firmware, and update the
output frame size in mtk_init_vdec_params to enable 4K frame size when
available.
Fixes: b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Allen-KH Cheng [Fri, 3 Mar 2023 01:38:38 +0000 (01:38 +0000)]
media: dt-bindings: media: mediatek: Remove "dma-ranges" property for decoder
Because the decoder nodes already make use of the iommus property to
configure the IOMMU for address translations, having a dma-ranges
property makes no sense.
In fact, after commit f1ad5338a4d5 ("of: Fix "dma-ranges" handling for
bus controllers"), having a dma-ranges property causes IOMMU faults.
Remove the dma-ranges property and update the example.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Allen-KH Cheng [Fri, 3 Mar 2023 01:38:37 +0000 (01:38 +0000)]
media: dt-bindings: media: mediatek: Rename child node names for decoder
In order to make the names of the child nodes more generic, we rename
"vcodec-lat" and "vcodec-core" to "video-codec" for decoder in
patternProperties and example.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
1. Move removing buffer after sw setting and before hw setting
in enc&dec worker to prevents the operation of removing
the buffer twice if the sw setting fails.
2. Remove the redundant operation of queue work in the
jpegenc irq handler because the jpegenc worker has called
v4l2_m2m_job_finish to do it.
Shravan Chippa [Wed, 1 Mar 2023 07:34:09 +0000 (08:34 +0100)]
media: i2c: imx334: add missing reset values for mode 3840x2160_regs[]
There are some missing reset reg_mode values for the 3840x2160@60
resolution. The camera sensor still works in 3840x2160@60 resolution mode
because of the register reset values. This is an issue when we change the
modes dynamically. As an example, when we change the mode from 1920x1080@30
resolution to 3840x2160@60 resoultion then the mode values will be written
to the registers from the array mode_3840x2160_regs[] which gives the wrong
output which is incorrect resolution.
So add the missing reset values to the mode_3840x2160_regs[].
Shravan Chippa [Wed, 1 Mar 2023 07:34:08 +0000 (08:34 +0100)]
media: i2c: imx334: replace __v4l2_ctrl_s_ctrl to __v4l2_ctrl_modify_range
For every mode we will get new set of values for hbalnk so use
__v4l2_ctrl_modify_range() to support multi modes for hblank.
The hblank value is readonly in the driver. because of this the function
returns error if we try to change. so added dumy return case in
imx334_set_ctrl function.
Venus Linux driver loads firmware based on firmware-name property and
some DTS already have it:
msm8996-oneplus3.dtb: video-codec@c00000: Unevaluated properties are not allowed ('firmware-name', 'interconnect-names', 'interconnects' were unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: dt-bindings: qcom,venus: split common properties
All Qualcomm SoC Venus bindings share a lot of properties, so split
common part to re-usable schema to reduce the duplication and promote
unified style.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Cleanup the Qualcomm SoC Venus bindings:
- Drop unneeded blank lines and quotes,
- Fix indentation in example to 4-space (to match DT schema bindings
style),
- Add SoC name in each title.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Robert Mader [Wed, 4 Jan 2023 12:23:37 +0000 (13:23 +0100)]
media: i2c: imx258: Parse and register properties
Analogous to e.g. the imx219. This enables propagating
V4L2_CID_CAMERA_ORIENTATION and V4L2_CID_CAMERA_SENSOR_ROTATION values.
The motivation is to allow libcamera detect these values from the device
tree and propagate them further to e.g. Pipewire.
While at it, reserve space for 3 additional controls even if
v4l2_ctrl_new_fwnode_properties() can only register 2 of them, to fix the
existing implementation which reserve space for 8 controls but actually
registers 9.
[Sakari Ailus: Rewrapped the commit message and removed changelog]
Signed-off-by: Robert Mader <robert.mader@collabora.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The imx296 driver uses the subdev active state, there's no need to
implement the .get_fmt() operation manually. Use the
v4l2_subdev_get_fmt() helper instead.
The ov5670 driver tries to get a reference to the xvclk provider by using
the common cock framework and deflects to parsing the "clock-frequency"
property in case the clock provider is not specified in the firmware
interface, detected by checking if ov5670->xvclk == PTR_ERR(-ENOENT).
However, as reported by the Smatch static checker, if CONFIG_HAVE_CLK is
not enabled, devm_clk_get() returns 0 which when passed to PTR_ERR()
means success causing the driver to fail without propagating any error
code up.
Explicitly handle the case where ov5670->xvclk it set to NULL, forcing
the code to parse the "clock-frequency" property in case CONFIG_HAVE_CLK
is not enabled, as suggested by Dan Carpenter.
Reported-by: Dan Carpenter <error27@gmail.com> Suggested-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Luca Weiss [Fri, 10 Feb 2023 20:33:18 +0000 (21:33 +0100)]
media: i2c: ov5670: Support single-lane operation
Currently the driver always configures the sensor for dual-lane MIPI
output, but it also supports single-lane output. Add support for that by
checking the data-lanes fwnode property how many lanes are used and
configure the necessary registers based on that.
To achieve this we move setting register 0x3018 out of the general reg
sequence so we set it to the correct value. The pixel_rate value also
needs to be adjusted.
[Sakari Ailus: Use div_s64 to divide a 64-bit number]
media: dt-bindings: samsung,fimc: convert to dtschema
Convert the Samsung S5P/Exynos Camera Subsystem (FIMC) bindings to DT
schema. Changes during conversion - adjust to existing DTS and Linux
driver: add iommus and power-domains.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: dt-bindings: samsung,exynos4212-is: convert to dtschema
Convert the Samsung Exynos4212/4412 SoC Imaging Subsystem (FIMC-IS)
bindings to DT schema. Changes during conversion - adjust to existing
DTS and Linux driver: add iommus and power-domains.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: dt-bindings: samsung,exynos4212-fimc-lite: convert to dtschema
Convert the Samsung Exynos SoC series camera host interface (FIMC-LITE)
bindings to DT schema. Changes during conversion - adjust to existing
DTS and Linux driver: add iommus and power-domains.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: dt-bindings: samsung,exynos4210-csis: convert to dtschema
Convert the Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI
CSIS) bindings to DT schema. Changes during conversion - adjust to
existing DTS and Linux driver:
1. Add phys and power-domains.
2. Move samsung,csis-wclk property to the endpoint node.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: samsung: exynos4-is: drop simple-bus from compatibles
The FIMC camera node wrapper is not a bus, so using simple-bus fallback
compatible just to instantiate its children nodes was never correct.
Driver should explicitly populate all its children devices.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: samsung: exynos4-is: do not require pinctrl
Driver does not handle pin configuration switching and several DTS
provide empty pinctrl property, just to satisfy the driver's requirement
for it. Drop requirement for pinctrl property as it is really optional.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The FIMC camera node wrapper is not a bus, so using simple-bus fallback
compatible just to instantiate its children nodes was never correct.
Drop the simple-bus compatible and expect driver to explicitly populate
children devices.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
This clarifies which side of the calls is responsible for doing what to
which parts of the struct. It also expands the terse description of the
access algorithm into more prose-like, active voice description, which
trades conciseness for ease of comprehension.
Fixed: typo "format" -> "frame size" in enum-frame-size
Added: no holes in the enumeration
Added: enumerations per what?
Added: who fills in what in calls
Changed: "given" -> "specified"
[Sakari Ailus: Rewrap text]
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: doc/media api: Try to make enum usage clearer
This clarifies which side of the calls is responsible for doing what to
which parts of the struct. This also explicitly states that repeating
values are disallowed. It also expands the terse description of the access
algorithm into more prose-like, active voice description, which trades
conciseness for ease of comprehension.
Added: mbus codes must not repeat
Added: no holes in the enumeration
Added: enumerations per what?
Added: who fills in what in calls
Changed: "zero" -> "0"
Changed: "given" -> "specified"
Still unclear how it works so didn't describe: "which". What is a "try
format" vs "active format"?
[Sakari Ailus: Rewrap lines, fix build issue]
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Alexander Stein [Fri, 17 Feb 2023 09:52:21 +0000 (10:52 +0100)]
media: i2c: imx290: Add support for imx327 variant
Both sensors are quite similar. Their specs only differ regarding LVDS
and parallel output but are identical regarding MIPI-CSI-2 interface.
But they use a different init setting of hard-coded values, taken from
the datasheet.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Alexander Stein [Fri, 17 Feb 2023 09:52:20 +0000 (10:52 +0100)]
media: dt-bindings: media: i2c: Add imx327 version to IMX327 bindings
The imx290 driver can be used for both imx290 and imx327 as they have a
similar register set and configuration. imx327 lacks 8 lanes LVDS and
120 FPS support.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:30:02 +0000 (23:30 +0100)]
media: i2c: imx290: Add support for H & V Flips
The sensor supports H & V flips, so add the relevant hooks for
V4L2_CID_HFLIP and V4L2_CID_VFLIP to configure them.
Note that the Bayer order is maintained as the readout area
shifts by 1 pixel in the appropriate direction (note the
comment about the top margin being 8 pixels whilst the bottom
margin is 9). The V4L2_SEL_TGT_CROP region is therefore
adjusted appropriately.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:59 +0000 (23:29 +0100)]
media: i2c: imx290: VMAX is mode dependent
The default VMAX for 60fps in 720p mode is 750 according to the
datasheet, however the driver always left it at 1125 thereby stopping
60fps being achieved.
Make VMAX (and therefore V4L2_CID_VBLANK) mode dependent so that 720p60
can be achieved.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:58 +0000 (23:29 +0100)]
media: i2c: imx290: Convert V4L2_CID_VBLANK to read/write
The driver exposed V4L2_CID_VBLANK as a read only control to allow
for exposure calculations and determination of the frame rate.
Convert to a read/write control so that the frame rate can be
controlled.
V4L2_CID_VBLANK also sets the limits for the exposure control,
therefore exposure ranges have to be updated when vblank changes
(either via s_ctrl, or via changing mode).
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:56 +0000 (23:29 +0100)]
media: i2c: imx290: Use CSI timings as per datasheet
Commit "98e0500eadb7 media: i2c: imx290: Add configurable link frequency
and pixel rate" added support for the increased link frequencies
on 2 data lanes, but didn't update the CSI timing registers in
accordance with the datasheet.
Use the specified settings.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:55 +0000 (23:29 +0100)]
media: i2c: imx290: Support 60fps in 2 lane operation
Commit "97589ad61c73 media: i2c: imx290: Add support for 2 data lanes"
added support for running in two lane mode (instead of 4), but
without changing the link frequency that resulted in a max of 30fps.
Commit "98e0500eadb7 media: i2c: imx290: Add configurable link frequency
and pixel rate" then doubled the link frequency when in 2 lane mode,
but didn't undo the correction for running at only 30fps, just extending
horizontal blanking instead.
Remove the 30fps limit on 2 lane by correcting the register config
in accordance with the datasheet for 60fps operation over 2 lanes.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:54 +0000 (23:29 +0100)]
media: i2c: imx290: Fix the pixel rate at 148.5Mpix/s
The datasheet lists the link frequency changes between
1080p and 720p modes. This is correct that the link frequency
changes as measured on an oscilloscope.
Link frequency is not necessarily the same as pixel rate.
The datasheet gives standard configurations for 1080p and 720p
modes at a number of frame rates.
Looking at the 1080p mode it gives:
HMAX = 0x898 = 2200
VMAX = 0x465 = 1125
2200 * 1125 * 60fps = 148.5MPix/s
Looking at the 720p mode it gives:
HMAX = 0xce4 = 3300
VMAX = 0x2ee = 750
3300 * 750 * 60fps = 148.5Mpix/s
This driver currently scales the pixel rate proportionally to the
link frequency, however the above shows that this is not the
correct thing to do, and currently all frame rate and exposure
calculations give incorrect results.
Correctly report the pixel rate as being 148.5MPix/s under any
mode.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:53 +0000 (23:29 +0100)]
media: i2c: imx290: Add V4L2_SUBDEV_FL_HAS_EVENTS and subscribe hooks
Any V4L2 subdevice that implements controls and declares
V4L2_SUBDEV_FL_HAS_DEVNODE should also declare V4L2_SUBDEV_FL_HAS_EVENTS
and implement subscribe_event and unsubscribe_event hooks.
This driver didn't and would therefore fail v4l2-compliance
testing.
Add the relevant hooks.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Dave Stevenson [Wed, 15 Feb 2023 22:29:49 +0000 (23:29 +0100)]
media: dt-bindings: media: i2c: Add mono version to IMX290 bindings
The IMX290 module is available as either monochrome or colour and
the variant is not detectable at runtime.
Add a new compatible string for the monochrome version, based on the
full device name IMX290LLR. For consistency, add a new compatible string
for the colour version based on the IMX290LQR full device name, and
deprecate the current ambiguous compatible string.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Jacopo Mondi [Tue, 21 Feb 2023 17:10:48 +0000 (18:10 +0100)]
media: i2c: ov5647: Use bus-locked i2c_transfer()
The ov5647_read() functions calls i2c_master_send() and
i2c_master_read() in sequence. However this leaves space for other
clients to contend the bus and insert an unrelated transaction in between
the two calls.
Replace the two calls with a single i2c_transfer() one, that locks the
bus in between the transactions.
A common case with subdev routing is that on the subdevice just before
the DMA engines (video nodes), no multiplexing is allowed on the source
pads, as the DMA engine can only handle a single stream.
In some other situations one might also want to do the same check on the
sink side.
Add new routing validation flags to check these:
V4L2_SUBDEV_ROUTING_NO_SINK_MULTIPLEXING and
V4L2_SUBDEV_ROUTING_NO_SOURCE_MULTIPLEXING.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
V4L2_SUBDEV_ROUTING_NO_STREAM_MIX routing validation flag means that all
routes from a sink pad must go to the same source pad and all routes
going to the same source pad must originate from the same sink pad.
This does not cover all use cases. For example, if a device routes
all streams from a single sink pad to any of the source pads, but
streams from multiple sink pads can go to the same source pad, the
current flag is too restrictive.
Split the flag into two parts, V4L2_SUBDEV_ROUTING_NO_SINK_STREAM_MIX
and V4L2_SUBDEV_ROUTING_NO_SOURCE_STREAM_MIX, which add the restriction
only on one side of the device. Together they mean the same as
V4L2_SUBDEV_ROUTING_NO_STREAM_MIX.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: i2c: st-vgxy61: Move 'detect' call to 'power_on'
Previously the device detection was performed after patching.
Move it right after the reset to make sure we have the correct sensor
before trying to patch it.
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans Verkuil [Thu, 2 Mar 2023 12:57:27 +0000 (13:57 +0100)]
media: vivid: drop bitmap and clipping output overlay support
This test driver is the only remaining driver still using
the clipping and bitmap method. Drop support for this so
we can remove this in the V4L2 API as well.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans Verkuil [Thu, 2 Mar 2023 12:57:26 +0000 (13:57 +0100)]
media: vivid: drop overlay support
Destructive overlay support (i.e. where the video frame is DMA-ed
straight into a framebuffer) is effectively dead. It was a
necessary evil in the early days when computers were not fast enough
to copy SDTV video frames around, but today that's no longer a problem.
It requires access to the framebuffer memory, which is a bad idea and
very hard to do safely. In addition, in drm it is today almost
impossible to get hold of the framebuffer address.
So drop support for this.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
projects / thirdparty / kernel / linux.git / log
