- 14 Aug, 2023 40 commits
-
-
Deborah Brouwer authored
Break bttv_set_dma() into several smaller, separate functions so it is easier to read the risc and dma code. Replace numeric values with descriptive macros. Also remove the unused field btv->cap_ctl. Signed-off-by:
Deborah Brouwer <deborah.brouwer@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Deborah Brouwer authored
Instead of storing vbi_skip and vbi_count in each bttv buffer separately, move them to the main bttv struct as they won't change per buffer. Signed-off-by:
-
Deborah Brouwer authored
Instead of storing the cropping parameters in each bttv buffer separately, just use the global bttv crop because it won't change per buffer. Signed-off-by:
-
Deborah Brouwer authored
Instead of storing the tvnorm in each bttv buffer separately, just use the global bttv tvnorm because the tvnorm does not change per buffer. Signed-off-by:
-
Deborah Brouwer authored
Instead of storing the format (video or vbi) in each bttv buffer separately, just use the global bttv format because the format does not change per buffer. Signed-off-by:
-
Deborah Brouwer authored
The do_crop flag indicates whether a cropping rectangle has been set. Instead of storing this flag separately in each file handle, move do_crop to struct bttv in preparation for vb2 conversion which stops using separate bttv file handles. Signed-off-by:
-
Deborah Brouwer authored
In preparation for the vb2 conversion, copy the vbi format from struct bttv_fh and add it to the main struct bttv. Use vbi format from struct bttv wherever it will be needed after the vb2 conversion which stops using separate bttv file handles altogether. To avoid changing more code than necessary, just leave the vbi format in separate file handles wherever it will be subsequently removed by vb2. Signed-off-by:
-
Deborah Brouwer authored
In preparation for the vb2 conversion, copy the video format, width and height fields from struct bttv_fh and add them to the main struct bttv. Use these fields from struct bttv wherever they will be needed after the vb2 conversion which stops using separate bttv file handles altogether. To avoid changing more code than necessary, just leave the video format, width and height fields in separate file handles wherever the code will be subsequently removed by vb2. Signed-off-by:
-
Deborah Brouwer authored
Use a v4l2_fh when opening a radio device instead of a bttv_fh and manage it with v4l2_fh_open() and v4l2_fh_release() and v4l2_ctrl_poll(). This eliminates bttv_fh from the radio in preparation for vb2 conversion which stops using separate bttv file handles altogether. Signed-off-by:
-
Deborah Brouwer authored
Both BUG and BUG_ON are replaced with WARN_ON wherever they would still be present after the vb2 conversion. WARN_ON is sufficient in these cases. Signed-off-by:
-
Deborah Brouwer authored
Use video_drvdata(file) instead of fh->btv to get the bttv pointer wherever the bttv pointer will still be needed after the vb2 conversion. Signed-off-by:
-
Jacopo Mondi authored
Fix the following smatch warning: drivers/media/i2c/rdacm21.c:373 ov10640_check_id() error: uninitialized symbol 'val'. Initialize 'val' to 0 in the ov10640_check_id() function. Fixes: 2b821698 ("media: i2c: rdacm21: Power up OV10640 before OV490") Reported-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
-
GUO Zihua authored
Remove duplicated include of linux/of.h. Resolves checkincludes message. Signed-off-by:
GUO Zihua <guozihua@huawei.com> Signed-off-by:
-
Sishuai Gong authored
There is a race over dev->radio_tx_rds_owner between the two functions mentioned below: Thread-1 Thread-2 vivid_fop_release() vivid_radio_rx_read() mutex_unlock(&dev->mutex) mutex_lock_interruptible(&dev->mutex) ... dev->radio_rx_rds_owner = file->private_data; ... if (file->private_data == dev->radio_rx_rds_owner) { dev->radio_tx_rds_last_block = 0; dev->radio_tx_rds_owner = NULL; } This race can be fixed by only releasing the lock after vivid_fop_release() finishes the checks. Signed-off-by:Sishuai Gong <sishuai.system@gmail.com> Signed-off-by:
-
Sakari Ailus authored
Fix the following smatch warning: drivers/media/i2c/ccs/ccs-data.c:524 ccs_data_parse_rules() warn: address of NULL pointer 'rules' The CCS static data rule parser does not check an if rule has been obtained before checking for other rule types (which depend on the if rule). In practice this means parsing invalid CCS static data could lead to dereferencing a NULL pointer. Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Fixes: a6b396f4 ("media: ccs: Add CCS static data parser library") Cc: stable@vger.kernel.org # for 5.11 and up Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Tomi Valkeinen authored
smatch reports: drivers/media/i2c/ds90ub960.c:1788 ub960_init_tx_ports() error: uninitialized symbol 'pll_div'. This is caused by 'pll_div' not being set for 1200 MHz CSI rate. Set the 'pll_div' correctly. Closes: https://lore.kernel.org/all/8d6daeb1-b62a-bbb2-b840-8759c84f2085@xs4all.nl/ Fixes: afe267f2 ("media: i2c: add DS90UB960 driver") Reported-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Tomi Valkeinen authored
smatch reports some uninitialized variables: drivers/media/i2c/ds90ub953.c:655 ub953_log_status() error: uninitialized symbol 'gpio_local_data'. drivers/media/i2c/ds90ub953.c:655 ub953_log_status() error: uninitialized symbol 'gpio_input_ctrl'. drivers/media/i2c/ds90ub953.c:655 ub953_log_status() error: uninitialized symbol 'gpio_pin_sts'. These are used only for printing debug information, and the use of an uninitialized variable only happens if an i2c transaction has failed, which will print an error. Thus, fix the errors just by initializing the variables to 0. Closes: https://lore.kernel.org/all/8d6daeb1-b62a-bbb2-b840-8759c84f2085@xs4all.nl/ Fixes: 6363db1c ("media: i2c: add DS90UB953 driver") Reported-by:
-
Tomi Valkeinen authored
smatch reports some uninitialized variables: drivers/media/i2c/ds90ub913.c:481 ub913_log_status() error: uninitialized symbol 'v1'. drivers/media/i2c/ds90ub913.c:481 ub913_log_status() error: uninitialized symbol 'v2'. These are used only for printing debug information, and the use of an uninitialized variable only happens if an i2c transaction has failed, which will print an error. Thus, fix the errors just by initializing the variables to 0. Closes: https://lore.kernel.org/all/8d6daeb1-b62a-bbb2-b840-8759c84f2085@xs4all.nl/ Fixes: c158d0d4 ("media: i2c: add DS90UB913 driver") Reported-by:
-
Hans de Goede authored
After recent improvements to atomisp and the standard ov2680 sensor driver, the atomisp driver now works fine with the standard ov2680 driver. Drop the no longer necessary atomisp specific atomisp-ov2680 sensor driver. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Now that the ov2680 driver verifies the bus-cfg from the endpoint fwnode the link-frequency must be set for things to work. Signed-off-by:
-
Hans de Goede authored
Add myself as OV2680 sensor driver maintainer. Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Reviewed-by:
Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by:
-
Hans de Goede authored
Verify that the number of CSI lanes and link-frequency specified in the endpoint fwnode are correct. Signed-off-by:
-
Hans de Goede authored
Add read-only link-freq and pixel-rate controls. This is necessary for the sensor to work with the ipu3-cio2 driver and for libcamera. Acked-by:
-
Hans de Goede authored
Read and log sensor revision during probe. Since this means that the driver will now already log a message on successful probe drop the "ov2680 init correctly" log message. Acked-by:
-
Hans de Goede authored
Drop unnecessary pad checks in enum_mbus_code, get_fmt, set_fmt this is already checked by check_pad() from drivers/media/v4l2-core/v4l2-subdev.c. Acked-by:
-
Hans de Goede authored
Usually when developing a sensor driver with help from the vendor the vendor will provide a bunch of register tweaks for optimal performance of the sensor. The atomisp-ov2680.c driver was (presumably) developed by Intel with help from OmniVision and indeed contains a bunch of register tweaks. Add these register tweaks to the "main" ov2680.c driver. Acked-by:
-
Hans de Goede authored
The exposure control's max effective value is VTS - 8, set the control range to match this. Thas means that if/when a future commit makes VTS configurable as a control itself the exposure range needs to be updated dynamically to match the VTS value. The gain control goes from 0 - 1023, higher values wrap around to the lowest gain setting. The gain control, controls an analog gain so use V4L2_CID_ANALOGUE_GAIN for it instead of V4L2_CID_GAIN. Also stop setting 0 as default for both controls this leads to a totally black picture which is no good. This is esp. important for tests of the sensor driver without (userspace driven) auto exposure / gain. Acked-by:
-
Hans de Goede authored
Implement selection support. Modelled after ov5693 selection support, but allow setting sizes smaller than crop-size through set_fmt() since that was already allowed. Acked-by:
-
Hans de Goede authored
Add an __ov2680_get_pad_format() helper function. This is a preparation patch for adding selections support. Acked-by:
-
Hans de Goede authored
Instead of using a long fixed register settings list for each resolution, calculate the register settings based on the requested width + height. This is based on atomisp-ov2680 commit 06118885 ("media: atomisp: ov2680: Make setting the modes algorithm based"). This will allow future enhancements like adding hblank and vblank controls and adding selection support. This also adds properly programming the ISP window and setting the manual ISP window control bit in register 0x5708, this is necessary for the hflip and vflip conrols to work properly. Acked-by:
-
Hans de Goede authored
Add an ov2680_mode struct to group together mode related state. For now this only contains the v4l2_mbus_framefmt and the frame_interval. This is a preparation patch for moving to calculating the per mode settings, which will store more info in the new ov2680_mode struct. Acked-by:
-
Hans de Goede authored
Annotate the per mode register setting lists. This is a preparation patch for moving to calculating the per mode settings, allowing to set any mode through cropping. The annotations make it easier to see which registers are mode dependent and which are fixed. Acked-by:
-
Hans de Goede authored
Fix and simplify ov2680_enum_frame_interval(), the index is not an index into ov2680_mode_data[], so using OV2680_MODE_MAX is wrong. Instead it is an index indexing the different framerates for the resolution specified in fie->width, fie->height. Note validating fie->which is not necessary this is already done by the v4l2-core. Acked-by:
-
Hans de Goede authored
Add an acpi_match_table now that all the other bits necessary for ACPI support are in place. The OVTI prefix used for the ACPI-HID is used for various OmniVision sensors on many generations x86 tablets and laptops. The OVTI2680 HID specifically is used on multiple models spanning at least 4 different Intel CPU models (2 ISP2, 2 IPU3). Acked-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
-
Hans de Goede authored
Defer probe() until the endpoint fwnode is available. This is necessary on ACPI platforms where the bridge code creating the fwnodes may also e.g. set the "clock-frequency" device property and add GPIO mappings. Acked-by:
-
Hans de Goede authored
Most x86/ACPI boards use the ov2680 with a 19.2 MHz xvclk, rather then the expected 24MHz, add support for this. Compensate for the lower clk by setting a higher PLL multiplier of 69 when using 19.2 MHz vs the default multiplier of 55 for a 24MHz xvclk. Acked-by:
-
Hans de Goede authored
On ACPI systems the following 2 scenarios are possible: 1. The xvclk is fully controlled by ACPI powermanagement, so there is no "xvclk" for the driver to get (since it is abstracted away). In this case there will be a "clock-frequency" device property to tell the driver the xvclk rate. 2. There is a xvclk modelled in the clk framework for the driver, but the clk-generator may not be set to the right frequency yet. In this case there will also be a "clock-frequency" device property and the driver is expected to set the rate of the xvclk through this frequency through the clk framework. Handle both these scenarios by switching to devm_clk_get_optional() and checking for a "clock-frequency" device property. This is modelled after how the same issue was fixed for the ov8865 in commit 73dcffeb ("media: i2c: Support 19.2MHz input clock in ov8865"). Acked-by:
Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by:
-
Hans de Goede authored
With runtime-pm it is guaranteed that ov2680_power_on() and ov2680_power_off() will always be called in a balanced way; and the is_enabled check in ov2680_s_ctrl() can be replaced by checking the runtime-suspend state. So there is no more need for the is_enabled flag, remove it. While at it also make sure that flip control changes while suspended still lead to the bayer-order getting updated so that get_fmt returns the correct bayer-order. Acked-by:
-
Hans de Goede authored
The datasheet of the OV2680 labels the single GPIO to put the sensor in powersaving mode as XSHUTDN aka shutdown, _not_ reset. This is important because some boards have standardized sensor connectors which allow connecting various sensor modules. These connectors have both reset and powerdown signals and the powerdown signal is routed to the OV2680's XSHUTDN pin. On x86/ACPI multiple Bay Trail, Cherry Trail, Sky Lake and Kaby Lake models have an OV2680 connected to the ISP2 / IPU3. On these devices the GPIOS are not described in DT instead the GPIOs are described with an Intel specific DSM which labels them as either powerdown or reset. Often this DSM returns both reset and powerdown pins even though the OV2680 has only 1 such pin. For the ov2680 driver to work on these devices it must use the GPIO with "powerdown" as con-id, matching the XSHUTDN name from the datasheet. As for why "powerdown" vs say "shutdown" the ACPI DSM -> con-id mapping code is shared, so we must use standardized names and currently all of the following sensor drivers already use "powerdown": adv7180, gc0310, isl7998x, ov02a10, ov2659, ov5640, ov5648, ov5670, ov5693, ov7670, ov772x, ov7740, ov8858, ov8865 and ov9650 . Where as the hi846 driver is the lonely standout using "shutdown". Try the "powerdown" con-id first to make things work, falling back to "reset" to keep existing DT setups working. Acked-by:
-
Hans de Goede authored
Remove the obsolete s_power() callback and instead use runtime-pm + autosuspend, powering-on the sensor on s_stream(1) and releasing the runtime-pm reference on s_stream(0). This also removes the need for ov2680_mode_restore() instead ov2680_stream_enable() now takes care of all sensor initalization after power-on. This is a preparation patch for adding ACPI support. Note this also removes putting the clock lane into LP-11 state from ov2680_power_on() since now streaming will start immediately after powering on the sensor there is no need to put the clock lane in a low power state. Acked-by:
-
