Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44 |
|
#
f9f6e9cb |
| 07-Aug-2023 |
Xiaolei Wang <xiaolei.wang@windriver.com> |
media: ov5640: Fix a memory leak when ov5640_probe fails
[ Upstream commit 20290feaaeb76cc719921aad275ccb18662a7c3a ]
sensor->ctrls.handler is initialized in ov5640_init_controls(), so when the sen
media: ov5640: Fix a memory leak when ov5640_probe fails
[ Upstream commit 20290feaaeb76cc719921aad275ccb18662a7c3a ]
sensor->ctrls.handler is initialized in ov5640_init_controls(), so when the sensor is not connected and ov5640_sensor_resume() fails, sensor->ctrls.handler should be released, otherwise a memory leak will be detected:
unreferenced object 0xc674ca80 (size 64): comm "swapper/0", pid 1, jiffies 4294938337 (age 204.880s) hex dump (first 32 bytes): 80 55 75 c6 80 54 75 c6 00 55 75 c6 80 52 75 c6 .Uu..Tu..Uu..Ru. 00 53 75 c6 00 00 00 00 00 00 00 00 00 00 00 00 .Su..........
Fixes: 85644a9b37ec ("media: ov5640: Use runtime PM") Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
cd567e63 |
| 19-Jul-2023 |
Guoniu.zhou <guoniu.zhou@nxp.com> |
media: ov5640: fix vblank unchange issue when work at dvp mode
[ Upstream commit 8fc29e3c9f682d4ad9b0764d44ecc6c19b000051 ]
The value of V4L2_CID_VBLANK control is initialized to default vblank val
media: ov5640: fix vblank unchange issue when work at dvp mode
[ Upstream commit 8fc29e3c9f682d4ad9b0764d44ecc6c19b000051 ]
The value of V4L2_CID_VBLANK control is initialized to default vblank value of 640x480 when driver probe. When OV5640 work at DVP mode, the control value won't update and lead to sensor can't output data if the resolution remain the same as last time since incorrect total vertical size. So update it when there is a new value applied.
Fixes: bce93b827de6 ("media: ov5640: Add VBLANK control") Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
a210df33 |
| 24-Jul-2023 |
Marek Vasut <marex@denx.de> |
media: ov5640: Fix initial RESETB state and annotate timings
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
media: ov5640: Fix initial RESETB state and annotate timings
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: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Reported-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Tested-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
#
98cb72d3 |
| 02-Aug-2023 |
Marek Vasut <marex@denx.de> |
media: ov5640: Enable MIPI interface in ov5640_set_power_mipi()
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 th
media: ov5640: Enable MIPI interface in ov5640_set_power_mipi()
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: aa4bb8b8838f ("media: ov5640: Re-work MIPI startup sequence") Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> # [Test on imx6q] Signed-off-by: Marek Vasut <marex@denx.de> Tested-by: Jai Luthra <j-luthra@ti.com> # [Test on bplay, sk-am62] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
#
7c7e33b7 |
| 14-Jul-2023 |
Rob Herring <robh@kernel.org> |
media: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that m
media: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34 |
|
#
a828002f |
| 11-Jun-2023 |
Guoniu.zhou <guoniu.zhou@nxp.com> |
media: ov5640: fix low resolution image abnormal issue
OV5640 will output abnormal image data when work at low resolution (320x240, 176x144 and 160x120) after switching from high resolution, such as
media: ov5640: fix low resolution image abnormal issue
OV5640 will output abnormal image data when work at low resolution (320x240, 176x144 and 160x120) after switching from high resolution, such as 1080P, the time interval between high and low switching must be less than 1000ms in order to OV5640 don't enter suspend state during the time.
The reason is by 0x3824 value don't restore to initialize value when do resolution switching. In high resolution setting array, 0x3824 is set to 0x04, but low resolution setting array remove 0x3824 in commit db15c1957a2d ("media: ov5640: Remove duplicated mode settings"). So when do resolution switching from high to low, such as 1080P to 320x240, and the time interval is less than auto suspend delay time which means global initialize setting array will not be loaded, the output image data are abnormal. Hence move 0x3824 from ov5640_init_setting[] table to ov5640_setting_low_res[] table and also move 0x4407 0x460b, 0x460c to avoid same issue.
Fixes: db15c1957a2d ("media: ov5640: Remove duplicated mode settings") Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.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>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
eeaa47d1 |
| 05-May-2023 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: ov5640: Drop dead code using frame_interval
The ov5640_update_pixel_rate() function handles the parallel and MIPI CSI-2 cases separately.
When running on a parallel setup the V4L2_CID_PIXEL_
media: ov5640: Drop dead code using frame_interval
The ov5640_update_pixel_rate() function handles the parallel and MIPI CSI-2 cases separately.
When running on a parallel setup the V4L2_CID_PIXEL_RATE value is calculated at the beginning of the function using the values configured with the frame_interval operations, and then the function immediately returns.
The remaining of the function handles the MIPI CSI-2 configuration and should not use the 'current_fr' and 'def_fps' fields as those are only relevant for parallel mode.
Drop a small section of dead code that updates vblank using frame_interval on a MIPI CSI-2 setup.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
#
25affde3 |
| 05-May-2023 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: ov5640: Remove unused 'framerate' parameter
The 'current framerate' parameter passed to ov5640_try_fmt_internal() is unsued. Drop it.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.c
media: ov5640: Remove unused 'framerate' parameter
The 'current framerate' parameter passed to ov5640_try_fmt_internal() is unsued. Drop it.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
#
afe25fbc |
| 09-May-2023 |
Guoniu.zhou <guoniu.zhou@nxp.com> |
media: ov5640: correct comments for default VGA to avoid confusion
When OV5640 work at DVP mode, the default initialization settings make it output 30 frames per second. But when it work at CSI-2 mo
media: ov5640: correct comments for default VGA to avoid confusion
When OV5640 work at DVP mode, the default initialization settings make it output 30 frames per second. But when it work at CSI-2 mode the default link frequency will make it output 60 frames per second, so correct the comments to make it more clear.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
#
aaeb31c0 |
| 14-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
media: Switch i2c drivers back to use .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f
media: Switch i2c drivers back to use .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11 |
|
#
afa48057 |
| 28-Nov-2022 |
Paul Elder <paul.elder@ideasonboard.com> |
media: ov5640: Fix analogue gain control
Gain control is badly documented in publicly available (including leaked) documentation.
There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit v
media: ov5640: Fix analogue gain control
Gain control is badly documented in publicly available (including leaked) documentation.
There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit value (plus an enable bit in bit 6). The driver hardcodes it to 0x43, which one application note states is equal to x1.047. The documentation also states that 0x40 is equel to x1.000. The pre-gain thus seems to be expressed as in 1/64 increments, and thus ranges from x1.00 to x1.984. What the pre-gain does is however unspecified.
There is then an AGC gain limit, in registers 0x3a18 and 0x3a19, expressed as a 10-bit "real gain format" value. One application note sets it to 0x00f8 and states it is equal to x15.5, so it appears to be expressed in 1/16 increments, up to x63.9375.
The manual gain is stored in registers 0x350a and 0x350b, also as a 10-bit "real gain format" value. It is documented in the application note as a Q6.4 values, up to x63.9375.
One version of the datasheet indicates that the sensor supports a digital gain:
The OV5640 supports 1/2/4 digital gain. Normally, the gain is controlled automatically by the automatic gain control (AGC) block.
It isn't clear how that would be controlled manually.
There appears to be no indication regarding whether the gain controlled through registers 0x350a and 0x350b is an analogue gain only or also includes digital gain. The words "real gain" don't necessarily mean "combined analogue and digital gains". Some OmniVision sensors (such as the OV8858) are documented as supoprting different formats for the gain values, selectable through a register bit, and they are called "real gain format" and "sensor gain format". For that sensor, we have (one of) the gain registers documented as
0x3503[2]=0, gain[7:0] is real gain format, where low 4 bits are fraction bits, for example, 0x10 is 1x gain, 0x28 is 2.5x gain
If 0x3503[2]=1, gain[7:0] is sensor gain format, gain[7:4] is coarse gain, 00000: 1x, 00001: 2x, 00011: 4x, 00111: 8x, gain[7] is 1, gain[3:0] is fine gain. For example, 0x10 is 1x gain, 0x30 is 2x gain, 0x70 is 4x gain
(The second part of the text makes little sense)
"Real gain" may thus refer to the combination of the coarse and fine analogue gains as a single value.
The OV5640 0x350a and 0x350b registers thus appear to control analogue gain. The driver incorrectly uses V4L2_CID_GAIN as V4L2 has a specific control for analogue gain, V4L2_CID_ANALOGUE_GAIN. Use it.
If registers 0x350a and 0x350b are later found to control digital gain as well, the driver could then restrict the range of the analogue gain control value to lower than x64 and add a separate digital gain control.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
#
d7ff6913 |
| 03-Jan-2023 |
Jai Luthra <j-luthra@ti.com> |
media: ov5640: Handle delays when no reset_gpio set
Some module manufacturers [1][2] don't expose the RESETB and PWDN pins of the sensor directly through the 15-pin FFC connector. Instead wiring ~PW
media: ov5640: Handle delays when no reset_gpio set
Some module manufacturers [1][2] don't expose the RESETB and PWDN pins of the sensor directly through the 15-pin FFC connector. Instead wiring ~PWDN gpio to the sensor pins with appropriate delays.
In such cases, reset_gpio will not be available to the driver, but it will still be toggled when the sensor is powered on, and thus we should still honor the wait time of >= 5ms + 1ms + 20ms (see figure 2-3 in [3]) before attempting any i/o operations over SCCB.
Also, rename the function to ov5640_powerup_sequence to better match the datasheet (section 2.7).
[1] https://digilent.com/reference/_media/reference/add-ons/pcam-5c/pcam_5c_sch.pdf [2] https://www.alinx.com/public/upload/file/AN5641_User_Manual.pdf [3] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf
Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Jai Luthra <j-luthra@ti.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>
show more ...
|
#
decea0a9 |
| 03-Jan-2023 |
Jai Luthra <j-luthra@ti.com> |
media: ov5640: Fix soft reset sequence and timings
Move the register-based reset out of the init_setting[] and into the powerup_sequence function. The sensor is power cycled and reset using the gpio
media: ov5640: Fix soft reset sequence and timings
Move the register-based reset out of the init_setting[] and into the powerup_sequence function. The sensor is power cycled and reset using the gpio pins so the soft reset is not always necessary.
This also ensures that soft reset honors the timing sequence from the datasheet [1].
[1] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf
Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Reported-by: Nishanth Menon <nm@ti.com> Suggested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jai Luthra <j-luthra@ti.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonaboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
#
e13064a3 |
| 15-Jan-2023 |
Andrey Skvortsov <andrej.skvortzov@gmail.com> |
media: ov5640: Update last busy timestamp to reset autosuspend timer
Otherwise autosuspend delay doesn't work and power is cut off immediately as device is freed.
Signed-off-by: Andrey Skvortsov <a
media: ov5640: Update last busy timestamp to reset autosuspend timer
Otherwise autosuspend delay doesn't work and power is cut off immediately as device is freed.
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
#
68453b02 |
| 11-Dec-2022 |
Guoniu.zhou <guoniu.zhou@nxp.com> |
media: ov5640: set correct default format for CSI-2 mode
In commit a89f14bbcfa5 ("media: ov5640: Split DVP and CSI-2 formats"), it splits format list for DVP and CSI-2 mode, but the default format d
media: ov5640: set correct default format for CSI-2 mode
In commit a89f14bbcfa5 ("media: ov5640: Split DVP and CSI-2 formats"), it splits format list for DVP and CSI-2 mode, but the default format defined in commit 90b0f355c5a3 ("media: ov5640: Implement init_cfg") is only supported by DVP mode, so define a new default format for CSI-2 mode.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com> Reviewed-by: Jai Luthra <j-luthra@ti.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>
show more ...
|
#
f33b56d3 |
| 02-Dec-2022 |
Guoniu.zhou <guoniu.zhou@nxp.com> |
media: ov5640: report correct frame rate to user
In commit 3145efcdb4d0 ("media: ov5640: Rework timings programming"), it defines max_fps field in ov5640_mode_info structure to store maximum frame r
media: ov5640: report correct frame rate to user
In commit 3145efcdb4d0 ("media: ov5640: Rework timings programming"), it defines max_fps field in ov5640_mode_info structure to store maximum frame rate supported by each mode. But in ov5640_try_frame_interval(), it assumes the maximum frame rate supported by all modes is 60. But actually, only VGA support it. For others, the maximum frame rate supported is 30. So correct it by taking the maximum frame rate supported by each mode as the initialization value of the local variable maxfps.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.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>
show more ...
|
Revision tags: v6.0.10, v5.15.80 |
|
#
d7b41196 |
| 25-Nov-2022 |
Guoniu.zhou <guoniu.zhou@nxp.com> |
media: ov5640: set correct default link frequency
current_link_freq field in ov5640_dev structure is link frequency, not link frequency array index, so correct it.
Fixes: 3c28588f35d3 ("media: ov56
media: ov5640: set correct default link frequency
current_link_freq field in ov5640_dev structure is link frequency, not link frequency array index, so correct it.
Fixes: 3c28588f35d3 ("media: ov5640: Update pixel_rate and link_freq") Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56 |
|
#
85644a9b |
| 21-Jul-2022 |
Paul Elder <paul.elder@ideasonboard.com> |
media: ov5640: Use runtime PM
Switch to using runtime PM for power management. Make it optional, however, to support ACPI.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laure
media: ov5640: Use runtime PM
Switch to using runtime PM for power management. Make it optional, however, to support ACPI.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-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>
show more ...
|
#
ed5c2f5f |
| 15-Aug-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
i2c: Make remove callback return void
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.)
i2c: Make remove callback return void
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.)
So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before.
Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
show more ...
|
Revision tags: v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40 |
|
#
935fbc94 |
| 13-May-2022 |
Jacopo Mondi <jacopo@jmondi.org> |
media: ov5640: Move format mux config in format
The image format produced by the sensor is controlled by two registers, whose values computation is open coded in ov5640_set_framefmt().
As we have a
media: ov5640: Move format mux config in format
The image format produced by the sensor is controlled by two registers, whose values computation is open coded in ov5640_set_framefmt().
As we have a list of formats already, move the OV5640_REG_FORMAT_CONTROL00 and OV5640_REG_ISP_FORMAT_MUX_CTRL register values to the static list of formats instead of open coding it.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-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>
show more ...
|
#
a89f14bb |
| 13-May-2022 |
Jacopo Mondi <jacopo@jmondi.org> |
media: ov5640: Split DVP and CSI-2 formats
The format enumeration list is shared between CSI-2 and DVP modes. This lead to the enumeration of unsupported format variants in both modes.
Separate the
media: ov5640: Split DVP and CSI-2 formats
The format enumeration list is shared between CSI-2 and DVP modes. This lead to the enumeration of unsupported format variants in both modes.
Separate the list of DVP and CSI-2 formats and create helpers to access the correct one.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-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>
show more ...
|
#
dd81b8ff |
| 13-May-2022 |
Jacopo Mondi <jacopo@jmondi.org> |
media: ov5640: Adjust format to bpp in s_fmt
The ov5640 driver supports different sizes for different mbus_codes. In particular:
- 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all
media: ov5640: Adjust format to bpp in s_fmt
The ov5640 driver supports different sizes for different mbus_codes. In particular:
- 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all sizes - 24bpp modes: low resolutions sizes (< 1280x720)
Adjust the image sizes according to the above constraints.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-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>
show more ...
|
#
7dcb3a2f |
| 13-May-2022 |
Jacopo Mondi <jacopo@jmondi.org> |
media: ov5640: Restrict sizes to mbus code
The ov5640 driver supports different sizes for different mbus_codes. In particular:
- 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all s
media: ov5640: Restrict sizes to mbus code
The ov5640 driver supports different sizes for different mbus_codes. In particular:
- 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all sizes - 24bpp modes: low resolutions sizes (< 1280x720)
Restrict the frame sizes enumerations to the above constraints.
While at it, make sure the fse->mbus_code parameter is valid, and return -EINVAL if it's not.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-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>
show more ...
|
#
6ac98b41 |
| 13-May-2022 |
Jacopo Mondi <jacopo@jmondi.org> |
media: ov5640: Add BGR888 format
Add support for BGR888 image format.
No existing media bus codes describe exactly the way data is transferred on the CSI-2 bus. This is not a new issue, the CSI-2 Y
media: ov5640: Add BGR888 format
Add support for BGR888 image format.
No existing media bus codes describe exactly the way data is transferred on the CSI-2 bus. This is not a new issue, the CSI-2 YUV422 8-bit format is described by MEDIA_BUS_FMT_UYVY8_1X16 which is an arbitrary convention and not an exact match. Use the MEDIA_BUS_FMT_BGR888_1X24 to follow the same convention, based on the order in which bits are transmitted over the CSI-2 bus when producing images in RGB24 format.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-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>
show more ...
|
#
0a43fcd7 |
| 13-May-2022 |
Jacopo Mondi <jacopo@jmondi.org> |
media: ov5640: Add RGB565_1X16 format
The driver already supports the 2X8_[LE|BE] variants of RGB565 formats.
As for CSI-2 the 2X8 variants do not apply, add RGB565_1X16 variant with little-endian
media: ov5640: Add RGB565_1X16 format
The driver already supports the 2X8_[LE|BE] variants of RGB565 formats.
As for CSI-2 the 2X8 variants do not apply, add RGB565_1X16 variant with little-endian ordering of components as required by the CSI-2 specifications.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-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>
show more ...
|