The generic wrapper for handling power off - iris_vpu_power_off() -
calls them via 'iris_platform_data->vpu_ops', so shall the cleanup code
in iris_vpu_power_on().
This makes also sense if looking at caller of iris_vpu_power_on(), which
unwinds also with the wrapper calling respective platfortm code (unwinds
with iris_vpu_power_off()).
Otherwise power off sequence on the newer VPU3.3 in error path is not
complete.
Dikshita Agarwal [Fri, 22 Aug 2025 05:53:30 +0000 (11:23 +0530)]
media: iris: vpu3x: Add MNoC low power handshake during hardware power-off
Add the missing write to AON_WRAPPER_MVP_NOC_LPI_CONTROL before
reading the LPI status register. Introduce a handshake loop to ensure
MNoC enters low power mode reliably during VPU3 hardware power-off with
timeout handling.
Fixes: 02083a1e00ae ("media: platform: qcom/iris: add support for vpu33") Cc: stable@vger.kernel.org Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
dt-bindings: media: qcom,sm8550-iris: Do not reference legacy venus properties
The Qualcomm SoC Iris video codec is an evolution of previous Venus and
it comes with its own Iris Linux drivers. These new drivers were
accepted under condition they actually improve state of afairs, instead
of duplicating old, legacy solutions.
Unfortunately binding still references common parts of Venus without
actual need and benefit. For example Iris does not use fake
"video-firmware" device node (fake because there is no actual device
underlying it and it was added only to work around some Linux issues
with IOMMU mappings).
Stop referencing venus-common schema in the new Qualcomm Iris bindings
and move all necessary properties, except unused "video-firmware" (no
driver usage, no DTS).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com> Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
[bod: Changed title order to dt-bindings: media] Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
dt-bindings: media: qcom,sm8550-iris: Add SM8750 video codec
Add binding for Qualcom SM8750 Iris video codec, which comes with
significantly different powering up sequence than previous SM8650, thus
different clocks and resets. For consistency keep existing clock and
clock-names naming, so the list shares common part.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[bod: re-ordered patch title to dt-bindings: media] Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Iris in X1E80100 is pretty much identical to SM8550. We can use the same
firmware image and the same definitions in the driver, so just add
qcom,x1e80100-iris to the existing list with qcom,sm8550-iris as fallback
compatible.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Replace my quicinc.com address with oss.qualcomm.com email in the
MAINTAINERS file for both IRIS and VENUS video accelerator drivers.
Also update mailmap to ensure proper attribution across historical
commits.
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:10 +0000 (00:46 +0300)]
media: i2c: s5k6a3: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" property has always
been specified as mandatory in the DT bindings and the "clock-frequency"
property has initially been optional. Both properties were initially set
in the upstream DT sources. The driver retrieves the clock, retrieves
the clock rate from the "clock-frequency" property if available or uses
a fixed default otherwise, and sets the clock rate. This is deprecated
behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:09 +0000 (00:46 +0300)]
media: i2c: s5k5baf: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" property has always
been specified as mandatory in the DT bindings and the "clock-frequency"
property has always been optional. Both properties were initially set in
the upstream DT sources. The driver retrieves the clock, retrieves the
clock rate from the "clock-frequency" property if available or uses a
fixed default otherwise, and sets the clock rate. This is deprecated
behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
For all meaningful purposes, devm_v4l2_sensor_clk_get_legacy() returns
-EPROBE_DEFER in situations when the driver would want to defer probing.
Replace the hardcoded -EPROBE_DEFER error with propagating the error
code from devm_v4l2_sensor_clk_get_legacy().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:08 +0000 (00:46 +0300)]
media: i2c: s5c73m3: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. No DT bindings are available.
The "clocks" and "clock-frequency" properties were initially both set in
the upstream DT sources. The driver retrieves the clock, retrieves the
clock rate from the "clock-frequency" property if available or uses a
fixed default otherwise, and sets the clock rate. This is deprecated
behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:07 +0000 (00:46 +0300)]
media: i2c: ov8856: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports ACPI and OF platforms. The "clocks" and
"clock-frequency" properties were initially specified as mandatory in
the DT bindings and were both set in the upstream DT sources. The driver
retrieves the clock rate from the "clock-frequency" property. On OF
platforms, it retrieves the clock and sets its rate. If the rate does
not match the expected rate, the driver prints a warning. This is
correct behaviour for ACPI, and deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:06 +0000 (00:46 +0300)]
media: i2c: ov8856: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov8856 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:05 +0000 (00:46 +0300)]
media: i2c: ov5695: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" property has always
been specified as mandatory in the DT bindings and the "clock-frequency"
property has never been allowed. The "clocks" property is set in the
upstream DT sources and the "clock-frequency" property isn't. The driver
retrieves the clock and sets its rate to a fixed value. It then
retrieves the rate from the clock, and fails probing if the value
doesn't match. This is deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:04 +0000 (00:46 +0300)]
media: i2c: ov5645: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" property has always
been specified as mandatory in the DT bindings and the "clock-frequency"
property has always been optional. Both the "clocks" and
"clock-frequency" properties are set in the upstream DT sources. The
driver retrieves the clock, retrieves the clock rate from the
"clock-frequency" property, and sets the clock rate to the retrieved
rate. If the rate does not match the expected rates, the driver fails
probing. This is deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:03 +0000 (00:46 +0300)]
media: i2c: ov2685: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" property has always
been specified as mandatory in the DT bindings and the "clock-frequency"
property has never been allowed. The "clocks" property has always been
set in the upstream DT sources, and the "clock-frequency" never. The
driver retrieves the clock, and sets its rate to a fixed value. This is
deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:02 +0000 (00:46 +0300)]
media: i2c: ov02a10: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" and
"clock-frequency" properties were initially mandatory in the DT
bindings. The driver retrieves the clock, retrieves the clock rate from
the "clock-frequency" property, and sets the clock rate to the retrieved
rate. If the rate does not match one of the expected rates, the driver
fails probing. This is deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:01 +0000 (00:46 +0300)]
media: i2c: ov02a10: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov02a10 and
access it from there instead, to simplify the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:46:00 +0000 (00:46 +0300)]
media: i2c: imx290: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" and
"clock-frequency" properties were initially mandatory in the DT
bindings. The driver retrieves the clock, retrieves the clock rate from
the "clock-frequency" property, and sets the clock rate to the retrieved
rate. If the rate does not match one of the expected rates, the driver
fails probing. This is deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:59 +0000 (00:45 +0300)]
media: i2c: imx258: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports ACPI and OF platforms. The "clocks" property was
not initially specified as mandatory in the DT bindings, and the
"clock-frequency" property has never been allowed. The driver retrieves
the clock and its rate if present, and falls back to retrieving the rate
from the "clock-frequency" property otherwise. If the rate does not
match the expected rate, the driver fails probing. This is correct
behaviour for ACPI, and deprecated behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:58 +0000 (00:45 +0300)]
media: i2c: imx258: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct imx258 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:57 +0000 (00:45 +0300)]
media: i2c: gc08a3: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" and
"clock-frequency" properties were initially mandatory in the DT bindings
and were both set in the upstream DT sources. The driver retrieves the
clock, retrieves and ignores the clock rate from the clock-frequency
property, and sets the clock rate to a fixed value. This is deprecated
behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:56 +0000 (00:45 +0300)]
media: i2c: gc05a2: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" and
"clock-frequency" properties were initially mandatory in the DT bindings
and were both set in the upstream DT sources. The driver retrieves the
clock, retrieves and ignores the clock rate from the clock-frequency
property, and sets the clock rate to a fixed value. This is deprecated
behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:55 +0000 (00:45 +0300)]
media: i2c: et8ek8: Use V4L2 legacy sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage copying deprecated behaviour for OF platforms in new drivers,
and lead to differences in behaviour between drivers. Instead, drivers
that need to preserve the deprecated OF behaviour should use the
devm_v4l2_sensor_clk_get_legacy() helper.
This driver supports OF platforms only. The "clocks" and
"clock-frequency" properties were initially mandatory in the DT bindings
and were both set in the upstream DT sources. The driver retrieves the
clock, retrieves and ignores the clock rate from the clock-frequency
property, and sets the clock rate to a fixed value. This is deprecated
behaviour for OF.
Switch to using the devm_v4l2_sensor_clk_get_legacy() helper. This
preserves setting the clock rate on OF platforms. Should support for OF
platforms that set the clock rate through clock-frequency be considered
unneeded in the future, the driver will only need to switch to
devm_v4l2_sensor_clk_get() without any other change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:54 +0000 (00:45 +0300)]
media: i2c: et8ek8: Drop support for per-mode external clock frequency
The et8ek8 driver supports programming different external clock
frequencies for different modes, but in practice all modes use a 9.6MHz
external clock. Drop support for this feature and use a hardcoded
frequency, in preparation for further refactoring of external clock
handling.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:53 +0000 (00:45 +0300)]
media: v4l2-common: Add legacy camera sensor clock helper
The recently introduced devm_v4l2_sensor_clk_get() helper aims at
simplifying sensor drivers by centralizing clock handling code, as well
as reducing cargo-cult and deprecated behaviour.
A set of drivers implement external clock handling in a non-standard
way. This can't be changed as there is a high risk of breaking existing
platforms, but keeping the code as-is creates a risk of new drivers
copying deprecated behaviour.
To fix this, introduce a new devm_v4l2_sensor_clk_get_legacy() helper
and use it in those driver. Compared to devm_v4l2_sensor_clk_get(), the
new helper takes the "clock-frequency" property into account and sets
the external clock rate on OF platforms, and adds the ability to specify
a fixed default or fallback clock rate in case the "clock-frequency"
property is not present.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:52 +0000 (00:45 +0300)]
media: i2c: ov9734: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:51 +0000 (00:45 +0300)]
media: i2c: ov9734: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov9734 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:50 +0000 (00:45 +0300)]
media: i2c: ov7251: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on a
subset of ACPI platforms, but are considered deprecated on OF platforms,
and do not support ACPI platforms that implement MIPI DisCo for Imaging.
Implementing them manually in drivers is deprecated, as that can
encourage cargo-cult and lead to differences in behaviour between
drivers. Instead, drivers should use the devm_v4l2_sensor_clk_get()
helper.
This driver supports ACPI and OF platforms. The "clocks" property has
always been specified as mandatory in the DT bindings and the
"clock-frequency" property has always been optional. The driver
retrieves the clock and its rate if present, and falls back to
retrieving the rate from the "clock-frequency" property otherwise. If
the rate does not match one of the supported rates, the driver fails
probing.
If a clock is available and the "clock-frequency" property is set, the
driver sets the rate of the clock to the value of the property. It does
however use the rate initially retrieved from the clock for further
calculations, which is a bug if the rates don't match, and would prevent
the sensor from functioning properly. We can therefore assume that this
case never occurs, and that the driver behaves correctly for ACPI, and
for OF platforms that comply with the documented DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:49 +0000 (00:45 +0300)]
media: i2c: ov5693: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property has
always been specified as mandatory in the DT bindings, and the
"clock-frequency" property has never been allowed. The driver retrieves
the clock and its rate if present, and falls back to retrieving the rate
from the "clock-frequency" property otherwise. If the rate does not
match the expected rate, the driver fails probing. This is correct
behaviour for ACPI, and for OF platforms that comply with the documented
DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:48 +0000 (00:45 +0300)]
media: i2c: ov5675: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property has
always been specified as mandatory in the DT bindings, and the
"clock-frequency" property has never been allowed. The driver retrieves
the clock and its rate if present, and falls back to retrieving the rate
from the "clock-frequency" property otherwise. If the rate does not
match the expected rate, the driver fails probing. This is correct
behaviour for ACPI, and for OF platforms that comply with the documented
DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:47 +0000 (00:45 +0300)]
media: i2c: ov5675: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov5675 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:46 +0000 (00:45 +0300)]
media: i2c: ov5670: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property has
always been specified as mandatory in the DT bindings, and the
"clock-frequency" property has never been allowed. The driver retrieves
the clock and its rate if present, and falls back to retrieving the rate
from the "clock-frequency" property otherwise. If the rate does not
match the expected rate, the driver fails probing. This is correct
behaviour for ACPI, and for OF platforms that comply with the documented
DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:45 +0000 (00:45 +0300)]
media: i2c: ov5670: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov5670 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:44 +0000 (00:45 +0300)]
media: i2c: ov4689: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports OF platforms only. The "clocks" property has always
been specified as mandatory in the DT bindings and the "clock-frequency"
property has never been allowed. The driver retrieves the clock and its
rate if present, and falls back to retrieving the rate from the
"clock-frequency" property otherwise. If the rate does not match the
expected rate, the driver fails probing. This is deprecated on OF
platforms, but behaves correctly on platforms that comply with the DT
bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on OF platforms that comply with the DT bindings.
Non-compliant platforms are not expected, but any regression could
easily be handled by switching to the devm_v4l2_sensor_clk_get_legacy()
helper designed to preserve non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:43 +0000 (00:45 +0300)]
media: i2c: ov2740: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock if
present, and retrieves the clock rate from the "clock-frequency"
property. If the rate does not match the expected rate, the driver fails
probing. This is correct behaviour for ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:42 +0000 (00:45 +0300)]
media: i2c: ov2740: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov2740 and access
it from there instead, to simplify the driver.
While at it, fix mistakes in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:41 +0000 (00:45 +0300)]
media: i2c: ov13b10: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock if
present, and retrieves the clock rate from the "clock-frequency"
property. If the rate does not match the expected rate, the driver fails
probing. This is correct behaviour for ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:40 +0000 (00:45 +0300)]
media: i2c: ov13b10: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov13b10 and
access it from there instead, to simplify the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:39 +0000 (00:45 +0300)]
media: i2c: ov13858: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver prints a warning. This is correct behaviour
for ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:38 +0000 (00:45 +0300)]
media: i2c: ov13858: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov13858 and
access it from there instead, to simplify the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:37 +0000 (00:45 +0300)]
media: i2c: ov08x40: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property is
specified as mandatory in the DT bindings and the "clock-frequency"
property is not allowed. The driver retrieves the clock and its rate if
present, and falls back to retrieving the rate from the
"clock-frequency" property otherwise. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI, and for OF platforms that comply with the documented DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:36 +0000 (00:45 +0300)]
media: i2c: ov08x40: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov08x40 and
access it from there instead, to simplify the driver.
While at it, fix mistakes in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:35 +0000 (00:45 +0300)]
media: i2c: ov08d10: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver prints a warning. This is correct behaviour
for ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:34 +0000 (00:45 +0300)]
media: i2c: ov08d10: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov08d10 and
access it from there instead, to simplify the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:33 +0000 (00:45 +0300)]
media: i2c: ov02e10: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property is
specified as mandatory in the DT bindings and the "clock-frequency"
property is not allowed. The driver retrieves the clock and its rate if
present, and falls back to retrieving the rate from the
"clock-frequency" property otherwise. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI, and for OF platforms that comply with the documented DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:32 +0000 (00:45 +0300)]
media: i2c: ov02e10: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov02e10 and
access it from there instead, to simplify the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:31 +0000 (00:45 +0300)]
media: i2c: ov02c10: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property is
specified as mandatory in the DT bindings and the "clock-frequency"
property is not allowed. The driver retrieves the clock and its rate if
present, and falls back to retrieving the rate from the
"clock-frequency" property otherwise. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI, and for OF platforms that comply with the documented DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:30 +0000 (00:45 +0300)]
media: i2c: ov02c10: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct ov02c10 and
access it from there instead, to simplify the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:29 +0000 (00:45 +0300)]
media: i2c: og01a1b: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI and OF platforms. The "clocks" property is
specified as mandatory in the DT bindings and the "clock-frequency"
property is not allowed. The driver retrieves the clock if present,
retrieves the clock rate from the "clock-frequency" property and falls
back to retrieving it from the clock. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI, and for OF platforms that comply with the documented DT bindings.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
The behaviour is also unchanged on OF platforms that comply with the DT
bindings. Non-compliant platforms are not expected, but any regression
could easily be handled by switching to the
devm_v4l2_sensor_clk_get_legacy() helper designed to preserve
non-compliant behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:28 +0000 (00:45 +0300)]
media: i2c: og01a1b: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct og01a1b and
access it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:27 +0000 (00:45 +0300)]
media: i2c: imx335: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:26 +0000 (00:45 +0300)]
media: i2c: imx355: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct imx355 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:25 +0000 (00:45 +0300)]
media: i2c: imx319: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:24 +0000 (00:45 +0300)]
media: i2c: imx319: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct imx319 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:23 +0000 (00:45 +0300)]
media: i2c: imx208: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:22 +0000 (00:45 +0300)]
media: i2c: imx208: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct imx208 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:21 +0000 (00:45 +0300)]
media: i2c: hi847: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock rate
from the "clock-frequency" property. If the rate does not match the
expected rate, the driver fails probing. This is correct behaviour for
ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:20 +0000 (00:45 +0300)]
media: i2c: hi847: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct hi847 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:19 +0000 (00:45 +0300)]
media: i2c: hi556: Use V4L2 sensor clock helper
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate, or modify the clock rate
of the external clock programmatically. Both behaviours are valid on
a subset of ACPI platforms, but are considered deprecated on OF
platforms, and do not support ACPI platforms that implement MIPI DisCo
for Imaging. Implementing them manually in drivers is deprecated, as
that can encourage cargo-cult and lead to differences in behaviour
between drivers. Instead, drivers should use the
devm_v4l2_sensor_clk_get() helper.
This driver supports ACPI platforms only. It retrieves the clock if
present, and retrieves the clock rate from the "clock-frequency"
property. If the rate does not match the expected rate, the driver fails
probing. This is correct behaviour for ACPI.
Switch to using the devm_v4l2_sensor_clk_get() helper. This does not
change the behaviour on ACPI platforms that specify a clock-frequency
property and don't provide a clock. On ACPI platforms that provide a
clock, the clock rate will be set to the value of the clock-frequency
property. This should not change the behaviour either as this driver
expects the clock to be set to that rate, and wouldn't operate correctly
otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:18 +0000 (00:45 +0300)]
media: i2c: hi556: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct hi556 and access
it from there instead, to simplify the driver.
While at it, fix a mistake in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:17 +0000 (00:45 +0300)]
media: i2c: ov6650: Drop unused driver
The ov6650 driver was introduced in v2.6.37 to support the OMAP1-based
Amstrad Delta video phone. The platform still has a board file in the
kernel, but support for the camera was dropped in commit ce548396a433
("media: mach-omap1: board-ams-delta.c: remove soc_camera dependencies")
in v5.9. The driver has been unused since as it has received neither
ACPI nor DT support.
The ov6650 driver is one of the last sensor drivers calling
clk_set_rate(). This is deprecated, and calls to the function are being
removed to avoid cargo-cult. As the driver is unlikely to ever be used
again, drop it instead of trying to avoid call clk_set_rate().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:16 +0000 (00:45 +0300)]
media: i2c: mt9v111: Do not set clock rate manually
The driver retrieves the rate of the external at probe time, and then
reprograms that clock with the same rate when powering on the device.
Setting the clock rate is not needed, drop it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:14 +0000 (00:45 +0300)]
media: i2c: mt9v032: Replace client->dev usage
The driver needs to access the struct device in many places, and
retrieves it from the i2c_client itself retrieved with
v4l2_get_subdevdata(). Store it as a pointer in struct mt9v032 and
access it from there instead, to simplify the driver.
While at it, fix mistakes in the sort order of include statements.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:13 +0000 (00:45 +0300)]
media: i2c: mt9v022: Drop unused mt9v022.h header
The mt9v022 driver got removed in commit e7eab49132ba ("media:
staging/media/soc_camera: remove this driver"), but its platform header
file got left behind. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:12 +0000 (00:45 +0300)]
dt-bindings: media: imx274: Make clocks property required
The sensor requires an external clock, and drivers need to access the
clock to retrieve its frequency in order to configure the sensor. This
makes usage of the clocks property mandatory for a system to work
properly. Mark the clocks and clock-names properties as required, and
update the example accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Tue, 12 Aug 2025 21:45:11 +0000 (00:45 +0300)]
dt-bindings: media: imx258: Make clocks property required
The sensor requires an external clock, and drivers need to access the
clock to retrieve its frequency in order to configure the sensor. This
makes usage of the clocks property mandatory for a system to work
properly. Mark the property as required.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Usage of the clock-frequency property for camera sensors is discouraged
in favour of using assigned-clock-rates (and assigned-clock-parents
where needed). Drop the property, and update the example accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Laurent Pinchart [Wed, 13 Aug 2025 09:49:23 +0000 (12:49 +0300)]
dt-bindings: media: Deprecate clock-frequency property for camera sensors
Usage of the clock-frequency property for camera sensors is discouraged
in favour of using assigned-clock-rates (and assigned-clock-parents
where needed). Mark the property as deprecated.
Update the examples accordingly. In DT examples where the sensor input
clock appears to come from a programmable clock generator, replace
clock-frequency by the assigned-clocks and assigned-clock-rates
properties. Otherwise, just drop clock-frequency.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add a v4l2 subdevice driver for the Omnivision OV2735 sensor.
The Omnivision OV2735 is a 1/2.7-Inch CMOS image sensor with an
active array size of 1920 x 1080.
The following features are supported:
- Manual exposure an gain control support
- vblank/hblank control support
- Test pattern support control
- Supported resolution: 1920 x 1080 @ 30fps (SGRBG10)
Co-developed-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io> Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io> Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io>
[Sakari Ailus: Use container_of_const(), fix enum_bus_code condition.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
OmniVision OG0VE1B is a monochrome image sensor, which produces frames in
8/10-bit raw output format and supports 640x480, 400x400, 200x200 and
100x100 output image resolution modes.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
dt-bindings: media: i2c: Add OmniVision OG0VE1B camera sensor
Add device tree bindings documentation for OmniVision OG0VE1B camera
sensor.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
OmniVision OV6211 is a monochrome image sensor, which produces frames in
8/10-bit raw output format and supports 400x400, 200x200 and 100x100
output image resolution modes.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add device tree bindings documentation for OmniVision OV6211 image
sensor.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Hao Yao [Fri, 25 Apr 2025 04:33:25 +0000 (12:33 +0800)]
media: ov08x40: Fix the horizontal flip control
The datasheet of ov08x40 doesn't match the hardware behavior.
0x3821[2] == 1 is the original state and 0 the horizontal flip enabled.
Signed-off-by: Hao Yao <hao.yao@intel.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Tested-by: Hans de Goede <hansg@kernel.org> # ThinkPad X1 Carbon Gen 12 & Gen 13 Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: i2c: og01a1b: Specify monochrome media bus format instead of Bayer
The OmniVision OG01A1B image sensor is a monochrome sensor, it supports
8-bit and 10-bit RAW output formats only.
That said the planar greyscale Y8/Y10 media formats are more appropriate
for the sensor instead of the originally and arbitrary selected SGRBG one,
since there is no red, green or blue color components.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Dan Carpenter [Wed, 27 Aug 2025 13:02:57 +0000 (16:02 +0300)]
media: ti: j721e-csi2rx: Fix NULL vs IS_ERR() bug in ti_csi2rx_request_max_ppc()
The media_entity_remote_source_pad_unique() function never returns NULL,
it returns error pointers. Change this check from a NULL check to an
IS_ERR() check.
Fixes: 31f91c5224cd ("media: ti: j721e-csi2rx: Support multiple pixels per clock") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Qianfeng Rong [Wed, 27 Aug 2025 12:39:12 +0000 (20:39 +0800)]
media: stm32-dcmi: use int type to store negative error codes
Change "ret" from unsigned int to int type in dcmi_framesizes_init()
and dcmi_graph_notify_bound() to store negative error codes or zero
returned by v4l2_subdev_call() and media_create_pad_link() - this
better aligns with the coding standards and maintains code consistency.
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Qianfeng Rong [Wed, 27 Aug 2025 12:39:11 +0000 (20:39 +0800)]
media: raspberrypi: use int type to store negative error codes
Use int instead of unsigned int for the 'ret' variable in csi2_init() to
store negative error codes or zero returned by media_entity_pads_init().
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Qianfeng Rong [Wed, 27 Aug 2025 12:39:10 +0000 (20:39 +0800)]
media: i2c: mt9v111: fix incorrect type for ret
Change "ret" from unsigned int to int type in mt9v111_calc_frame_rate()
to store negative error codes or zero returned by __mt9v111_hw_reset()
and other functions.
Storing the negative error codes in unsigned type, doesn't cause an issue
at runtime but it's ugly as pants.
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Fixes: aab7ed1c3927 ("media: i2c: Add driver for Aptina MT9V111") Cc: stable@vger.kernel.org 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@kernel.org>
Allen Ballway [Wed, 23 Jul 2025 19:57:35 +0000 (12:57 -0700)]
media: ov8865: move mode_configure out of state_configure
ov8865_mode_configure() only needs to be called on sensor init, but it can
be called multiple times from ov8865_state_configure(). Move
ov8865_mode_configure() to ov8865_sensor_init().
Signed-off-by: Allen Ballway <ballway@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Hans Verkuil [Thu, 24 Apr 2025 09:27:30 +0000 (11:27 +0200)]
media: i2c: mt9p031: fix mbus code initialization
The mediabus code is device dependent, but the probe() function
thought that device_get_match_data() would return the code directly,
when in fact it returned a pointer to a struct mt9p031_model_info.
As a result, the initial mbus code was garbage.
Tested with a BeagleBoard xM and a Leopard Imaging LI-5M03 sensor board.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org> Fixes: a80b1bbff88b ("media: mt9p031: Refactor format handling for different sensor models") Cc: stable@vger.kernel.org
Sakari Ailus [Mon, 11 Mar 2024 11:13:08 +0000 (13:13 +0200)]
media: mc: Clear minor number reservation at unregistration time
Clear the media device's minor number reservation at unregister time as
there's no need to keep it reserved for longer. This makes it possible to
reserve the same minor right after unregistration.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: venus: Define minimum valid firmware version
Add support for specifying the minimum firmware version required for
correct operation.
When set, the driver compares this value against the version reported by
the firmware: if the firmware is older than required, driver
initialization will fail.
The version check is performed before creating dynamic device tree
nodes, to avoid the need for reverting nodes on failure.
Stephan Gerhold [Wed, 20 Aug 2025 15:16:39 +0000 (17:16 +0200)]
media: venus: firmware: Use correct reset sequence for IRIS2
When starting venus with the "no_tz" code path, IRIS2 needs the same
boot/reset sequence as IRIS2_1. This is because most of the registers were
moved to the "wrapper_tz_base", which is already defined for both IRIS2 and
IRIS2_1 inside core.c. Add IRIS2 to the checks inside firmware.c as well to
make sure that it uses the correct reset sequence.
Both IRIS2 and IRIS2_1 are HFI v6 variants, so the correct sequence was
used before commit c38610f8981e ("media: venus: firmware: Sanitize
per-VPU-version").