Currently, interrogating the controls, before they're set for the first
time, will return all-zero values. To fix this, use the init() callback
in the v4l2_ctrl_type_ops structure to populate the initial control
values.
Also, when running the sensor initialization sequence, make sure we
don't cache the settings for the embedded data because they do not
contain register values. They contain ranges. Otherwise we'll end up
with wrong register values in the regmap cache.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Tested-by: Celine Laurencin <celine.laurencin@nxp.com>
Reviewed-by: Celine Laurencin <celine.laurencin@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
Currently, the registers returned in the embedded data contain RW
registers for gains and exposure. That affects the way the registers are
updated which does not follow the specifications. Using the RO registers
fixes the problem. Also, move the embedded data initialization sequence
to the end and add a comment to be easier to find it out in the future.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <Mirela.rabulea@nxp.com>
Tested-by: Celine Laurencin <celine.laurencin@nxp.com>
Reviewed-by: Celine Laurencin <celine.laurencin@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
Keep subdev name as v4l2 core set since libcamera camera module
model identification heuristic does not work properly, it will
identify camera modules by parsing the default name.
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Add V4L2_CID_CAMERA_ORIENTATION and V4L2_CID_CAMERA_SENSOR_ROTATION
support for AP1302 device by adding "orientation" and "rotation" two
fwnode properityes to fix libcamera warning since they are recommended
V4L2 control in libcamera.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
The mx95mbcam_ctrl_type_ops structure is not used anywhere. Remove it.
Also, remove the mx95mbcam_ctrl_type_op_validate() which was only
referenced in the structure.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
The issue can happen with csi2_video_pipe_mask array accesses if
csi_of_ep.port < MAX96724_SRC_PAD or higher than MAX96724_N_PADS. Add a
check to make sure we don't get there. Since the function can now return
-EINVAL, add also a check in the caller function to handle this
situation.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
The v4l2_subdev_state_get_opposite_stream_format() function can return
NULL. Add a check before continuing.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
There is a valid issue inside the function where ret is assigned the
returned value of max96724_xlate_streams() in case of error and then we
jump to 'unlock' only to return 0. So, let's use that ret value this
time. Also, initialize ret to 0 to avoid returning wrong value if
pos == -1 in the while loop.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
This patch covers multiple Coverity "uninitialized scalar variable"
issues, all of them false positives since they'll get written in
subsequent function calls when their address is passed on as arguments
to those functions. However, I don't see any issues with initializing
those variables first and Coverity will be happy about it.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
This is a false positive Coverity issue as reg_val will be written when
calling regmap_read(). However, there's nothing inherently wrong with
initializing the variable to 0 and this will also make Coverity happy.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
The error revealed a hidden bug with setting the WB registers for LCG,
SPD and VS. They all replicated the HCG values because of incorrect
pointer arithmetic in the for loop initialization.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
The issue reported in ox03c10_streaming_start() is genuine. Variable
'ret' was not initialized which could lead to reporting that starting
streaming failed.
The issue reported in ox03c10_otp_correction_get() is a false positive.
Even though the regmap_bulk_read() will overwrite all the array values
with the ones read from the sensor, let's initialize the array to 0 to
silence Coverity.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
Remove format member from sensor structure, the sensor subdevice will
not track the state internally, instead it will use the managed
subdev active state, in ox05b1s_set_fmt for example.
Remove ox05b1s_get_fmt and use v4l2_subdev_get_fmt instead.
Use v4l2_subdev_init_finalize to opt-in for managed state, use the same
sensor lock, and initialize it sooner.
Do not lock in set_fmt and get_selection, as these ioctls, among others,
are called from a wrapper that already takes the lock if the subdev
uses active state, see DEFINE_STATE_WRAPPER.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
The current setting of the hdr_mode control is not working properly.
Cannot count on ox05b1s_update_controls() to actually write the
sensor registers, as the sensor may be suspended. Remove the
setting of hdr_mode from ox05b1s_update_controls(), as it is not
useful here, and it was wrong anyway, it should not be set to
the default value, that will overwrite what was set by user.
Instead, use __v4l2_ctrl_handler_setup in ox05b1s_apply_current_mode(),
to ensure control values are written in sensor registers
before streaming starts.
Also, update some comments.
Fixes: 17597cc375 ("LF-12210-2: media: ox05b1s: Add omnivision OX05B1S raw sensor driver")
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
The first run with libcamera does not work because the pixel rate
control value is not updated after set_fmt, it is only updated during
the first streamon. This is causing libcamerasrc negotiation failure
with the downstream caps filter on the fps.
So, update control values to reflect the current format upon
set_fmt.
Signed-off-by: Mirela Rabulea <mirela.rabulea@oss.nxp.com>
Reviewed-by: Alexi Birlinger <alexi.birlinger@nxp.com>
Tested-by: Alexi Birlinger <alexi.birlinger@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
[ Upstream commit 3cdc776e0a ]
It was reported to me that the imx219 didn't work on one of our
development kits partly because the access sequence is incorrect.
The datasheet I could find [1] for this camera has the access sequence:
Seq. No. Address (Hex) data
1 30EB 05
2 30EB 0C
3 300A FF
4 300B FF
5 30EB 05
6 30EB 09
but the driver swaps the first two elements. Laurent pointed out on IRC
that the original code used the correct sequence for 1920x1080 but the
current sequence for 3280x2464 and 1640x1232. During refactoring of the
init sequence the current order was used for all formats.
Switch to using the documented sequence.
Link: https://www.opensourceinstruments.com/Electronics/Data/IMX219PQ.pdf [1]
Fixes: 8508455961 ("media: i2c: imx219: Split common registers from mode tables")
Fixes: 1283b3b8f8 ("media: i2c: Add driver for Sony IMX219 sensor")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon-kit
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>
[ Upstream commit a1956bf53a ]
Currently we have the following algorithm to calculate what value should be
written to the exposure control of imx412.
lpfr = imx412->vblank + imx412->cur_mode->height;
shutter = lpfr - exposure;
The 'shutter' value is given to IMX412_REG_EXPOSURE_CIT however, the above
algorithm will result in the value given to IMX412_REG_EXPOSURE_CIT
decreasing as the requested exposure value from user-space goes up.
e.g.
[ 2255.713989] imx412 20-001a: Received exp 1608, analog gain 0
[ 2255.714002] imx412 20-001a: Set exp 1608, analog gain 0, shutter 1938, lpfr 3546
[ 2256.302770] imx412 20-001a: Received exp 2586, analog gain 100
[ 2256.302800] imx412 20-001a: Set exp 2586, analog gain 100, shutter 960, lpfr 3546
[ 2256.753755] imx412 20-001a: Received exp 3524, analog gain 110
[ 2256.753772] imx412 20-001a: Set exp 3524, analog gain 110, shutter 22, lpfr 3546
This behaviour results in the image having less exposure as the requested
exposure value from user-space increases.
Other sensor drivers such as ov5675, imx218, hid556 and others take the
requested exposure value and use the value directly.
Take the example of the above cited sensor drivers and directly apply the
requested exposure value from user-space. The 'lpfr' variable still
functions as before but the 'shutter' variable can be dispensed with as a
result.
Once done a similar run of the test application requesting higher exposure
looks like this, with 'exp' written directly to the sensor.
[ 133.207884] imx412 20-001a: Received exp 1608, analog gain 0
[ 133.207899] imx412 20-001a: Set exp 1608, analog gain 0, lpfr 3546
[ 133.905309] imx412 20-001a: Received exp 2844, analog gain 100
[ 133.905344] imx412 20-001a: Set exp 2844, analog gain 100, lpfr 3546
[ 134.241705] imx412 20-001a: Received exp 3524, analog gain 110
[ 134.241775] imx412 20-001a: Set exp 3524, analog gain 110, lpfr 3546
The result is then setting the sensor exposure to lower values results in
darker, less exposure images and vice versa with higher exposure values.
Fixes: 9214e86c0c ("media: i2c: Add imx412 camera sensor driver")
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # qrb5165-rb5/imx577
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Gjorgji Rosikopulos <quic_grosikop@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
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>
Using delayed launch mode for the group hold registers produces an
undesired effect: the group hold register sections are applied
sequentially, one section per frame. That leads to some sensor
parameters being applied too late.
Changing the launch mode to 1 ("quick manual launch"), produces the
desired effect: all parameters become available in frame N+2 embedded
data.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Add V4L2_CID_CAMERA_ORIENTATION and V4L2_CID_CAMERA_SENSOR_ROTATION
controls via v4l2_ctrl_new_fwnode_properties() helper. These controls
are optional requirements for libcamera, but there are warnings if
they are missing, so add them.
Signed-off-by: Mirela Rabulea <mirela.rabulea@oss.nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Tested-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Inform about the usage of oscillator from sensor module, when the clock
from SOC side is missing.
Signed-off-by: Mirela Rabulea <mirela.rabulea@oss.nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Set subdev name to i2c client device name in order to align with
libcamera required.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Correct code index when enum mbus code since it only support one
bus format so far.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
When use the IO expander to control the regulators for mt9m114, there will
be an issue that can be 10% probability reproduced, the mt9m114 camera
probed fail. From the waveform can be found the sequence of the power
and clock for mt9m114 is not correct.
From the mt9m114 reference manual can get the correct order should be:
DOVDD->AVDD->DVDD->EXTCLK
┌──────────────────────────//───────────────────────┐
│ │
DOVDD │ │
────────┘ t1 ┌─────────────────────//─────────────────────┐ └──
|◄──►│ │
AVDD | │ │
────────|────┘ └────
| t2 ┌───────────────────//───────────────────┐
◄────►│ │
DVDD | │ │
──────────────┘ └───────
| t3 ┌───┐ ┌────┐ ┌─//─┐ ┌────┐
◄──────►│ │ │ │ │ │ │ │
EXTCLK | │ │ │ │ │ │ │ │
────────────────┘ └────┘ └─────┘ └────┘ └───────────
1. The P5 is the pin of the IO expander pca9538, it's for mt9m114 EXTCLK
regulator control, so it should be controlled in mt9m114 driver to
keep the correct order of power and clocks.
2. Use "regulator_enable" and "regulator_disable" to replace
"regulator_bulk_enable" and "regulator_bulk_disable". The reason is that
"regulator_bulk_enable" and "regulator_bulk_disable" handle the async
regulators sequence, that can't keep the correct sequence of mt9m114
powers and clocks. So use regulator_enable and regulator_disable to
avoid the issue.
Signed-off-by: Alice Yuan <alice.yuan@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
The os08a20 is now supported in the ox05b1s driver.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Alice Yuan <alice.yuan@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Currently, if less than 4 cameras are needed, one has to modify the DTB
in order to have the new topology work. That's because we enabled all
configured GMSL links by default. This fix simply disables the links
that didn't lock and we can connect sensors in various configurations.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
It may happen when booting the system up that GMSL links do not lock.
However, a simple chip reset can fix it easily. So, this patch modifies
the init sequence by implementing a retry mechanism that checks the GMSL
links, resetting the chip in case no link has locked. The checks will be
done at the beginning of the init sequence, instead of the end. Also,
remove the links reset call from max96724_reset_gmsl_links() and rename
the function to max96724_check_gmsl_links().
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Since the MX95MBCAM sensor module has the PWDNB pin, that should reset
the serializer, hard-wired to HIGH, we need to make sure we leave the
serializer in the default state when we remove the module or we perform
a warm reboot. This would avoid issues with GMSL links not locking when
rebooting the board.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
We'll need this in order to reset the chip before warm reboot or module
removal, as the PWDNB pin is always HIGH.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
This is an 8MP raw10/raw12 sensor with HDR capabilities.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
This is a v4l2 driver for Omnivision OX05B1S RGB-IR sensor.
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
The os08a20_set_gain() function was inherited from imx8mp,
and it is specific to the VSI ISP, which is expecting a total
gain of 1024 for 1x gain, with the analogue and digital gain
being combined.
For imx95, add a new function and let the control update only
the analog gain registers with the gain code in sensor format.
This covers linear mode (gain for long exposure).
Fixes: 4892da9340 ("MLK-26186-5: media: os08a20: Add analog gain and exposure controls")
Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Allow userspace to flip the image horizontally.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
Currently, the image is horizontally flipped. Change the ox03c10 default
initialization sequence so that the image is correct.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
Instead of writing registers one by one, we can quite some time by using
bulk writes.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
Currently, any exposure or gain changes are applied immediately to the
sensor. That may lead to unexpected behavior if the sensor is streaming.
In order to avoid that, use group hold registers to store new settings
and use VBlank delay launch mode to apply them during vertical blanking.
As we have 4 group holds that we can use for operations unrelated to
embedded-data or statistics, we can use one group hold for each control:
exposure, analog_gain, digital_gain and white balance gain.
Also, forbid changing PWL related settings while streaming.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
Allow for a higher speed between the deserializer and the serializer.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
This will improve times taken to send commands to the sensor.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
This patch adds support for changing I2C communication channel speed
rate of the serializer to other values.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Robert Chiras <robert.chiras@nxp.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZu0U0ACgkQONu9yGCS
aT4c2Q//SGn9+yEUml1/7nQUTND434ly4JPMdrR1jjJSKwxAsgzOYKCoUpzpXim8
7mdKz7q1cXx/l+tfJgEDdJ8JzVS6ipJWAwF4vE+18zWZjEax/M3dgluZUUswXKYg
Da76wSaNkfGiIewu8HV90LKAKaQoCR4ypyWG8CqDZkCnGJORUJA09GNDrKFhOodT
f0TzjIvPw8E3rU2+HZfPmxUI0XQEzfVPWb5DK+0F7hcHw4ETcij7y0AInBkQ5bNt
tFRCc462nT23e3jXJECWMbSXdRF57LlT8G9626Om0iS+TY7YD6PPNa7/bdqVHzcw
hDmKE+xONslwvuzkYn2R9u+nc/dw/hJ8QI5j9QohbJCcXjcv8N3QeXoiLPjiDxxv
1JVVi6emyKvKx26kjY/m0ZTZ/QWWwQlj/+R8Or/yIMMYZvPwyBUX3I8cZIQhyAg4
n/fc2tFqmax0K6e9YOXj3sa+OlXx02DAC8oVToNrSS7HT5uhtoKT4vU1d+et2alo
dFJAhklt27k+eV+Ayxo+RUaxUVggM0MAB67S7XUR0kylP2BeL2l9wMKVzZz2V5T4
O9PHY1RpD8OGk7aZvlbZYIis7LBqVTXcaEB4l5QtSYM4RMON4BYb5QLEc0jYywzV
U7GMNiKhhuwEHjiPD0cIXyeWeQzTlH9os5lhW8moVY9mtthGlr0=
=zdH0
-----END PGP SIGNATURE-----
Merge tag 'v6.6.34' into lf-6.6.y
This is the 6.6.34 stable release
* tag 'v6.6.34': (2530 commits)
Linux 6.6.34
smp: Provide 'setup_max_cpus' definition on UP too
selftests: net: more strict check in net_helper
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
drivers/net/ethernet/freescale/fec_ptp.c
drivers/pmdomain/imx/imx8mp-blk-ctrl.c
drivers/usb/dwc3/host.c
tools/perf/util/pmu.c
[ Upstream commit 24034af644 ]
Since commit 63b0cd30b7 ("media: ov2680: Add bus-cfg / endpoint
property verification") the ov2680 driver no longer probes when the
'data-lanes' property is absent.
The OV2680 sensor has only one data lane, so there is no need for
describing it the devicetree.
Remove the unnecessary data-lanes property check.
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Fixes: 63b0cd30b7 ("media: ov2680: Add bus-cfg / endpoint property verification")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.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>
[ Upstream commit fd2e66abd7 ]
Since commit 63b0cd30b7 ("media: ov2680: Add bus-cfg / endpoint
property verification") the ov2680 no longer probes on a imx7s-warp7:
ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found
ov2680 1-0036: probe with driver ov2680 failed with error -22
As the 'link-frequencies' property is not mandatory, allow the probe
to succeed by skipping the link-frequency verification when the
property is absent.
Cc: stable@vger.kernel.org
Fixes: 63b0cd30b7 ("media: ov2680: Add bus-cfg / endpoint property verification")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Stable-dep-of: 24034af644 ("media: ov2680: Do not fail if data-lanes property is absent")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 49a9bad83b ]
Since commit 63b0cd30b7 ("media: ov2680: Add bus-cfg / endpoint
property verification") even when the correct 'link-frequencies'
property is passed in the devicetree, the driver fails to probe:
ov2680 1-0036: probe with driver ov2680 failed with error -22
The reason is that the variable 'ret' may contain the -EINVAL value
from a previous assignment:
ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
&rate);
Fix the problem by clearing 'ret' on the successful path.
Tested on imx7s-warp board with the following devicetree:
port {
ov2680_to_mipi: endpoint {
remote-endpoint = <&mipi_from_sensor>;
clock-lanes = <0>;
data-lanes = <1>;
link-frequencies = /bits/ 64 <330000000>;
};
};
Cc: stable@vger.kernel.org
Fixes: 63b0cd30b7 ("media: ov2680: Add bus-cfg / endpoint property verification")
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Stable-dep-of: 24034af644 ("media: ov2680: Do not fail if data-lanes property is absent")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 545b215736 ]
Using __exit for the remove function results in the remove callback
being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
unbound (e.g. using sysfs or hotplug), the driver is just removed
without the cleanup being performed. This results in resource leaks. Fix
it by compiling in the remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
Fixes: c5254e72b8 ("[media] media: Driver for Toshiba et8ek8 5MP sensor")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
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>
Add back channel GPIO select support to send a frame synchronization
signal in multiple camera case.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
When enabled as an output, each DS90UB953 GPIO pin can be
programed to output remote data coming from the compatible
deserializer. User can also change the output value using
LOCAL_GPIO_DATA(0x0D) register.
Enable remote deserializer GPIO data on local GPIO by default
since no API in GPIO framework can select this mode. User can
change it to output the value in LOCAL_GPIO_DATA(0x0D[3:0]) by
calling gpio_set_value().
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
