aboutsummaryrefslogtreecommitdiff
path: root/drivers/media
AgeCommit message (Collapse)AuthorFilesLines
2023-04-10media: mediatek: vcodec: add core decode done eventYunfei Dong2-1/+5
Need to make sure core decode done before current instance is free. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mediatek: vcodec: move lat_buf to the top of core listYunfei Dong2-1/+22
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 <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mediatek: vcodec: using each instance lat_buf count replace core ↵Yunfei Dong1-1/+1
ready list Core Hardware decoder depends on each instance lat_buf count, calling queue_work decode again when the lat_buf count of each instance isn't zero. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mediatek: vcodec: add params to record lat and core lat_buf countYunfei Dong2-1/+28
Using lat_buf to share decoder information between lat and core work queue, adding params to record the buf count. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: amphion: support to decode RealVideo videoMing Qian3-0/+38
amphion decoder add support for the RealVideo video. RV30 and RV40 are support by amphion decoder. Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: add RealVideo format RV30 and RV40Ming Qian1-0/+2
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 <[email protected]> Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: amphion: support to decode sorenson spark videoMing Qian2-0/+25
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 <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: add Sorenson Spark video formatMing Qian1-0/+1
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 <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mediatek: vcodec: Force capture queue format to MM21Yunfei Dong1-21/+3
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 <[email protected]> Reviewed-by: Nicolas F. R. A. Prado <[email protected]> Tested-by: Nicolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mediatek: vcodec: Make MM21 the default capture formatYunfei Dong1-4/+4
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 <[email protected]> Reviewed-by: Nicolas F. R. A. Prado <[email protected]> Tested-by: Nicolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mediatek: vcodec: Use 4K frame size when supported by stateful decoderPin-yen Lin1-1/+11
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 <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: refactor hw dev initializaitonkyrie wu4-16/+11
Add a atomic_t variable for initialization of hw dev. Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: refactor some variableskyrie wu4-44/+37
Refactor some variables to reduce redundancy and optimize the initialization process. Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: Remove some unnecessary variableskyrie wu3-33/+18
remove is_jpgenc_multihw, is_jpgdec_multihw, and unnecessary initialization. Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: reconstructs the initialization mode of workerkyrie wu2-6/+5
exclude is_jpgenc_multihw or is_jpgdec_multihw for judgment, and re-initialize jpeg worker. Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: Fixes jpeg enc&dec worker sw flowkyrie wu2-11/+7
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. Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface") Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface") Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: add jpeg single core initial functionkyrie wu1-30/+44
add single core initial function to init reg_base, irq and clk. Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-10media: mtk-jpeg: Fixes jpeghw multi-core judgementkyrie wu2-1/+6
some chips have multi-hw, but others have only one, modify the condition of multi-hw judgement Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware") Signed-off-by: kyrie wu <[email protected]> Signed-off-by: irui wang <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-04-03Merge 6.3-rc5 into driver-core-nextGreg Kroah-Hartman5-12/+10
We need the fixes in here for testing, as well as the driver core changes for documentation updates to build on. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-04-02Revert "venus: firmware: Correct non-pix start and end addresses"Javier Martinez Canillas1-2/+2
This reverts commit a837e5161cff, which broke probing of the venus driver, at least on the SC7180 SoC HP X2 Chromebook: qcom-venus aa00000.video-codec: Adding to iommu group 11 qcom-venus aa00000.video-codec: non legacy binding qcom-venus aa00000.video-codec: failed to reset venus core qcom-venus: probe of aa00000.video-codec failed with error -110 Matthias Kaehlcke also reported that the same change caused a regression in SC7180 and sc7280, that prevents AOSS from entering sleep mode during system suspend. So let's revert this commit for now to fix both issues. Fixes: a837e5161cff ("venus: firmware: Correct non-pix start and end addresses") Reported-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2023-03-31media: i2c: imx290: fix conditional function defintionsArnd Bergmann1-3/+3
The runtime suspend/resume functions are only referenced from the dev_pm_ops, but they use the old SET_RUNTIME_PM_OPS() helper that requires a __maybe_unused annotation to avoid a warning: drivers/media/i2c/imx290.c:1082:12: error: unused function 'imx290_runtime_resume' [-Werror,-Wunused-function] static int imx290_runtime_resume(struct device *dev) ^ drivers/media/i2c/imx290.c:1090:12: error: unused function 'imx290_runtime_suspend' [-Werror,-Wunused-function] static int imx290_runtime_suspend(struct device *dev) ^ Convert this to the new RUNTIME_PM_OPS() helper that so this is not required. To improve this further, also use the pm_ptr() helper that lets the dev_pm_ops get dropped entirely when CONFIG_PM is disabled. A related mistake happened in the of_match_ptr() macro here, which like SET_RUNTIME_PM_OPS() requires the match table to be marked as __maybe_unused, though I could not reproduce building this without CONFIG_OF. Remove the of_match_ptr() here as there is no point in dropping the match table in configurations without CONFIG_OF. Fixes: 02852c01f654 ("media: i2c: imx290: Initialize runtime PM before subdev") Signed-off-by: Arnd Bergmann <[email protected]> Reported-by: Guenter Roeck <[email protected]> Reported-by: Sudip Mukherjee <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2023-03-31media: pvrusb2: clean up unneeded complexity in pvrusb2 class logicGreg Kroah-Hartman3-64/+29
The pvrusb2 driver struct class logic was dynamically creating a class that should have just been static as it did not do anything special and was only a wrapper around a stock "struct class" implementation. Clean this all up by making a static struct class and modifying the code to correctly reference it. By doing so, lots of unneeded lines of code were removed, and #ifdef logic was cleaned up so that the .c files are not cluttered up with extra complexity following the proper kernel coding style. Cc: Mike Isely <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: [email protected] Reviewed-by: Hans Verkuil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-03-20media: ov2685: Select VIDEO_V4L2_SUBDEV_APISakari Ailus1-0/+1
VIDEO_V4L2_SUBDEV_API is required for v4l2_subdev_get_pad_*() functions. Select it. Fixes: ("media: i2c: ov2685: Add .get_selection() support") Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx334: support lower bandwidth modeShravan Chippa1-27/+269
Some platforms may not be capable of supporting the bandwidth required for 12 bit or 3840x2160@60 resolutions. Add support for dynamically selecting 10 bit and 1920x1080@30 resolutions while leaving the existing configuration as default. Reviewed-by: Jacopo Mondi <[email protected]> CC: Conor Dooley <[email protected]> Signed-off-by: Prakash Battu <[email protected]> Signed-off-by: Shravan Chippa <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx334: add missing reset values for mode 3840x2160_regs[]Shravan Chippa1-0/+20
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[]. Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Shravan Chippa <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx334: replace __v4l2_ctrl_s_ctrl to __v4l2_ctrl_modify_rangeShravan Chippa1-1/+5
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. Reviewed-by: Jacopo Mondi <[email protected]> Suggested-by: Jacopo Mondi <[email protected]> Signed-off-by: Shravan Chippa <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: max9286: Free control handlerLaurent Pinchart1-0/+1
The control handler is leaked in some probe-time error paths, as well as in the remove path. Fix it. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx258: Parse and register propertiesRobert Mader1-1/+12
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 <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: ov13b10: remove streaming mode set from reg_listBingbu Cao1-1/+0
It is not expected that trying to set the sensor to streaming mode when trying to set initial sensor configuration. Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: ov13b10: Support device probe in non-zero ACPI D stateArec Kao1-27/+47
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Also do identification on the first access of the device, whether in probe or when starting streaming. Signed-off-by: Arec Kao <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: ov2685: Add .get_selection() supportLuca Weiss1-0/+61
Add support for the .get_selection() pad operation to the ov2685 sensor driver. Report the native sensor size (pixel array), the crop bounds (readable pixel array area) and the current and default analog crop rectangles. Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Luca Weiss <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: ov2685: Add controls from fwnodeLuca Weiss1-1/+12
Add V4L2_CID_CAMERA_ORIENTATION and V4L2_CID_CAMERA_SENSOR_ROTATION controls to the ov2685 driver by attempting to parse them from firmware. Signed-off-by: Luca Weiss <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: ov2685: Add print for power on write failedLuca Weiss1-1/+3
If the sensor doens't power up correctly, for example due to incorrect devicetree description, the power up i2c writes will fail. Add an error print for this situation. Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Luca Weiss <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx296: Use v4l2_subdev_get_fmt()Laurent Pinchart1-10/+1
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. Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: ov5670: Properly handle !CONFIG_HAVE_CLKJacopo Mondi1-1/+1
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 <[email protected]> Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: ov5670: Support single-lane operationLuca Weiss1-15/+70
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] Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: ov5670: Use dev_err_probe in probe functionLuca Weiss1-25/+12
Replace the unusual const char *err_msg usage with dev_err_probe which also handles -EPROBE_DEFER better by not printing the message to kmsg. Signed-off-by: Luca Weiss <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: samsung: exynos4-is: drop simple-bus from compatiblesKrzysztof Kozlowski1-0/+4
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 <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: samsung: exynos4-is: do not require pinctrlKrzysztof Kozlowski1-4/+2
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 <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Add support for imx327 variantAlexander Stein1-2/+42
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 <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Add the error code to logs in start_streamingDave Stevenson1-6/+6
imx290_start_streaming logs what failed, but not the error code from that function. Add it into the log message. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Add support for H & V FlipsDave Stevenson1-5/+46
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 <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Add support for 74.25MHz external clockDave Stevenson1-16/+116
The sensor supports either a 37.125 or 74.25MHz external, but the driver only supported 37.125MHz. Add the relevant register configuration for either clock frequency option. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Remove duplicated write to IMX290_CTRL_07Dave Stevenson1-1/+0
IMX290_CTRL_07 was written from both imx290_global_init_settings and imx290_1080p_settings and imx290_720p_settings. Remove it from imx290_global_init_settings as the setting varies based on the mode. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: VMAX is mode dependentDave Stevenson1-3/+6
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 <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Convert V4L2_CID_VBLANK to read/writeDave Stevenson1-10/+48
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 <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Alexander Stein <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Convert V4L2_CID_HBLANK to read/writeDave Stevenson1-14/+19
The driver exposed V4L2_CID_HBLANK 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. Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Use CSI timings as per datasheetDave Stevenson1-20/+106
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 <[email protected]> Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Support 60fps in 2 lane operationDave Stevenson1-14/+3
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 <[email protected]> Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2023-03-20media: i2c: imx290: Fix the pixel rate at 148.5Mpix/sDave Stevenson1-11/+5
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 <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.