- 14 Aug, 2023 35 commits
-
-
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:
Rui Miguel Silva <rmfrfs@gmail.com> Reviewed-by:
Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
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:
-
Hans de Goede authored
Now that the cci_* register access helpers are used access to the i2c_client after probe() is no longer necessary. Directly store a struct device *dev pointing to &client->dev inside ov2680_dev to make the code simpler. Acked-by:
-
Hans de Goede authored
Use the new comon CCI register access helpers to replace the private register access helpers in the ov2680 driver. Acked-by:
-
Hans de Goede authored
When the ov2680_power_on() "sensor soft reset failed" path is hit during probe() the WARN() about putting an enabled regulator at drivers/regulator/core.c:2398 triggers 3 times (once for each regulator), filling dmesg with backtraces. Fix this by properly disabling the regulators on ov2680_power_on() errors. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by:
-
Hans de Goede authored
ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY was getting the try_fmt v4l2_mbus_framefmt struct from the passed in sd_state and then storing the contents of that into the return by reference format->format struct. While the right thing to do would be filling format->format based on the just looked up mode and then store the results of that in sd_state->pads[0].try_fmt . Before the previous change introducing ov2680_fill_format() this resulted in ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY always returning the zero-ed out sd_state->pads[0].try_fmt in format->format breaking callers using this. After the introduction of ov2680_fill_format() which at least initializes sd_state->pads[0].try_fmt properly, format->format is now always being filled with the default 800x600 mode set by ov2680_init_cfg() independent of the actual requested mode. Move the filling of format->format with ov2680_fill_format() to before the if (which == V4L2_SUBDEV_FORMAT_TRY) and then store the filled in format->format in sd_state->pads[0].try_fmt to fix this. Note this removes the fmt local variable because IMHO having a local variable which points to a sub-struct of one of the function arguments just leads to confusion when reading the code. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by:
-
Hans de Goede authored
Add a ov2680_fill_format() helper function and use this everywhere were a v4l2_mbus_framefmt struct needs to be filled in so that the driver always fills it consistently. This is a preparation patch for fixing ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in the passed in v4l2_mbus_framefmt struct. Note that for ov2680_init_cfg() this now simply always fills the try_fmt struct of the passed in sd_state. This is correct because ov2680_init_cfg() is never called with a NULL sd_state so the old sd_state check is not necessary. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by:
-
Hans de Goede authored
On ov2680_set_fmt() calls with format->which == V4L2_SUBDEV_FORMAT_TRY, ov2680_set_fmt() does not talk to the sensor. So in this case there is no need to lock the sensor->lock mutex or to check that the sensor is streaming. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by:
-
Hans de Goede authored
VIDEO_V4L2_SUBDEV_API is now automatically selected in Kconfig for all sensor drivers. Remove the ifdef CONFIG_VIDEO_V4L2_SUBDEV_API checks. This is a preparation patch for fixing ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in the passed in v4l2_mbus_framefmt struct. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by:
-
Hans de Goede authored
ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of 0 as value to ov2680_mod_reg(). While fixing this also: 1. Stop having separate enable/disable functions for hflip / vflip 2. Move the is_streaming check, which is unique to hflip / vflip into the ov2680_set_?flip() functions. for a nice code cleanup. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by:
-
Hans de Goede authored
The index into ov2680_hv_flip_bayer_order[] should be 0-3, but ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as max index, while the intention was to use: 0 + 1 + 2 as max index. Fix the index calculation in ov2680_bayer_order(), while at it also just use the ctrl values rather then reading them back using a slow i2c-read transaction. This also allows making the function void, since there now are no more i2c-reads to error check. Note the check for the ctrls being NULL is there to allow adding an ov2680_fill_format() helper later, which will call ov2680_set_bayer_order() during probe() before the ctrls are created. [Sakari Ailus: Change all users of ov2680_set_bayer_order() here] Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by:
-
Hans de Goede authored
Quoting the OV2680 datasheet: "3.2 exposure and gain control In the OV2680, the exposure time and gain are set manually from an external controller. The OV2680 supports manual gain and exposure control only for normal applications, no auto mode." And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that auto-exposure and auto-gain do not work. Note that the code setting the auto-exposure flag was broken, callers of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as "bool auto_exp" value, but ctrls->auto_exp is a menu control with: enum v4l2_exposure_auto_type { V4L2_EXPOSURE_AUTO = 0, V4L2_EXPOSURE_MANUAL = 1, ... So instead of passing !!ctrls->auto_exp->val they should have been passing ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was inverted of what it should have been. Also remove ov2680_g_volatile_ctrl() since without auto support the gain and exposure controls are not volatile. This also fixes the control values not being properly applied in ov2680_mode_set(). The 800x600 mode register-list also sets gain, exposure and vflip overriding the last set ctrl values. ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set() but did this before writing the mode register-list, so these values would still be overridden by the mode register-list. Add a v4l2_ctrl_handler_setup() call after writing the mode register-list to restore all ctrl values. Also remove the ctrls->gain->is_new check from ov2680_gain_set() so that the gain always gets restored properly. Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since ov2680_mode_restore() calls ov2680_mode_set(). Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: -
Tomi Valkeinen authored
Add mention that successful VIDIOC_SUBDEV_G_ROUTING call will update 'num_routes' and remove mention about non-existing streams, which is incorrect. Fixes: ea73eda5 ("media: Documentation: Add GS_ROUTING documentation") Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Marek Vasut authored
The initial state of RESETB input signal of OV5640 should be asserted, i.e. the sensor should be in reset. This is not the case, make it so. Since the subsequent assertion of RESETB signal is no longer necessary and the timing of the power sequencing could be slightly adjusted, add annotations to the delays which match OV5640 datasheet rev. 2.03, both: figure 2-3 power up timing with internal DVDD figure 2-4 power up timing with external DVDD source The 5..10ms delay between PWDN assertion and RESETB assertion is not even documented in the power sequencing diagram, and with this reset fix, it is no longer even necessary. Fixes: 19a81c14 ("[media] add Omnivision OV5640 sensor driver") Reported-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Jai Luthra <j-luthra@ti.com> Signed-off-by:
-
Ruan Jinjie authored
There is no possible for platform_get_irq() to return 0, and the return value of platform_get_irq() is more sensible to show the error reason. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Ruan Jinjie authored
It is not possible for platform_get_irq() or platform_get_irq_byname() to return 0. Use the return value from platform_get_irq() or platform_get_irq_byname(). Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by:
-
Ruan Jinjie authored
It is not possible for platform_get_irq() to return 0. Use the return value from platform_get_irq(). Signed-off-by:
-
Yang Yingliang authored
Set error return code, when get platform data failed. Fixes: b4a4547371b9 ("media: davinci: Init async notifier after registering V4L2 device") Signed-off-by:Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Marek Vasut authored
Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means MIPI CSI2 interface, while 0 means CPI parallel interface. In the ov5640_set_power_mipi() the interface should obviously be set to MIPI CSI2 since this functions is used to power up the sensor when operated in MIPI CSI2 mode. The sensor should not be in CPI mode in that case. This fixes a corner case where capturing the first frame on i.MX8MN with CSI/ISI resulted in corrupted frame. Fixes: aa4bb8b8 ("media: ov5640: Re-work MIPI startup sequence") Reviewed-by:
-
Wentong Wu authored
Previously on ACPI platforms, sensors that are intended to be connected to an IPU device for use with the ipu3-cio2 driver lacking the necessary connection information in firmware. IPU bridge driver is to connect sensors to IPU device via software nodes. Currently IVSC located between IPU device and sensors is available in existing commercial platforms from multiple OEMs. But the connection information between them in firmware is also not enough to build V4L2 connection graph. This patch parses the connection properties from the SSDB buffer in DSDT and build the connection using software nodes. IVSC driver is based on MEI framework (previously known as HECI), it has two MEI clients, MEI CSI and MEI ACE. Both clients are used to communicate messages with IVSC firmware. Linux abstracts MEI client as a device, whose bus type is MEI. And the device is addressed by a GUID/UUID which is part of the device name of MEI client. After figured out MEI CSI via the UUID composed device name, this patch setup the connection between MEI CSI and IPU, and the connection between MEI CSI and sensor via software nodes. Signed-off-by:
Wentong Wu <wentong.wu@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Wentong Wu authored
ACE is a submodule of IVSC which controls camera sensor's ownership, belonging to host or IVSC. When IVSC owns camera sensor, it is for algorithm computing. When host wants to control camera sensor, ACE module needs to be informed of ownership with defined interface. The interface is via MEI. There is a separate MEI UUID, which this driver uses to enumerate. To switch ownership of camera sensor between IVSC and host, the caller specifies the defined ownership information which will be sent to firmware by sending MEI command. Device link(device_link_add) is used to set the right camera sensor ownership before accessing the sensor via I2C. With DL_FLAG_PM_RUNTIME and DL_FLAG_RPM_ACTIVE, the supplier device will be PM runtime resumed before the consumer(camera sensor). So use runtime PM callbacks to transfer the ownership between host and IVSC. Signed-off-by:
-
Wentong Wu authored
CSI is a submodule of IVSC which can route camera sensor data to the outbound MIPI CSI-2 interface. The interface communicating with firmware is via MEI. There is a separate MEI UUID, which this driver uses to enumerate. To route camera sensor data to host, the information of link frequency and number of data lanes is sent to firmware by sending MEI command when starting stream. CSI also provides a privacy mode. When privacy mode is turned on, camera sensor can't be used. This means that both IVSC and host Image Processing Unit(IPU) can't get image data. And when this mode is turned on, user is notified via v4l2 control callback. Link: https://lore.kernel.org/linux-media/20230803115550.1601965-2-sakari.ailus@linux.intel.comSigned-off-by:
-
- 10 Aug, 2023 5 commits
-
-
Daniel Scally authored
Add a driver for the DW9719 VCM. The driver creates a v4l2 subdevice and registers a control to set the desired focus. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Daniel Scally <djrscally@gmail.com> Signed-off-by:
-
Hans de Goede authored
Fill sensor->vcm_type and call intel_cio2_bridge_instantiate_vcm() from the v4l2-async bound op so that an I2C-client will be instatiated for the VCM. Note unfortunately on atomisp the _DSM to get the VCM type sometimes returns a VCM even though there is none. Since VCMs are typically only used together with certain sensors, work around this by adding a vcm field to atomisp_sensor_config and only check for a VCM when that is set. Signed-off-by:
-
Hans de Goede authored
acpi_handle_info() uses the ACPI path to the handle as prefix for messages e.g. : "\_SB_.I2C2.CAM8". This makes it hard for users to figure out which csi2-bridge messages belong to which sensor since the actual sensor drivers uses the ACPI device name (typically "HID:00") for logging. Extend the acpi_handle_info() (and err and warn) logging to also log the device name to make it easier to match csi2-bridge messages with sensor driver log messages. Suggested-by:
-
Hans de Goede authored
Remove the duplicate IPU ACPI bridge code and use the new shared ipu_bridge_init() functionality. Note this will also use / assume v4l2-async device instantiation for ov5693 sensors on atomisp devices since ipu_supported_sensors[] already contains a match for this. This is fine since recent atomisp improvements allow the atomisp code to work with generic v4l2 sensor drivers and using an unmodified drivers/media/i2c/ov5693.c has been successfully tested on an Acer Iconia W4 820 tablet with an ISP2400 + OV5693 sensor. Reviewed-by:
-
Hans de Goede authored
In most cases when a VCM is used there is a single integrated module with the sensor + VCM + lens. This means that the sensor and VCM often share regulators and possibly also something like a powerdown pin. In the ACPI tables this is modelled as a single ACPI device with multiple I2cSerialBus resources. On atomisp devices the regulators and clks are modelled as ACPI power-resources, which are controlled by the (ACPI) power state of the sensor. So the sensor must be in D0 power state for the VCM to work. To make this work add a device-link with DL_FLAG_PM_RUNTIME flag so that the sensor will automatically be runtime-resumed whenever the VCM is runtime-resumed. This requires the probing of the VCM and thus the creation of the VCM I2C-client to be delayed till after the sensor driver has bound. Move the instantiation of the VCM I2C-client to the v4l2_async_notifier bound op, so that it is done after the sensor driver has bound; and add code to add the device-link. This fixes the problem with the shared ACPI power-resources on atomisp2 and this avoids the need for VCM related workarounds on IPU3 / IPU6. E.g. until now the dw9719 driver needed to get and control a Vsio (V sensor IO) regulator since that needs to be enabled to enable I2C pass-through on the PMIC on the sensor module. So the driver was controlling this regulator even though the actual dw9719 chip has no Vsio pin / power-plane. This also removes the need for ipu_bridge_init() to return -EPROBE_DEFER since the VCM is now instantiated later. Reviewed-by:
-
