media: i2c: Add onsemi AR0234 camera sensor driver

This series adds a driver for the onsemi AR0234 CMOS image sensor. The AR0234 is a 1/2.6-inch global-shutter sensor with a 1940x1220 pixel array, capable of 1920x1200 resolution at up to 120 fps. It supports MIPI CSI-2 output with 1 to 4 data lanes, raw Bayer (8/10-bit) and monochrome formats, as well as DPCM 10->8 compression.

The driver has been tested with 2 and 4 lanes on an ARM64 Rockchip RK3588 platform with a 27 MHz external clock. Both 8-bit and 10-bit raw Bayer modes are functional.

Notes:
- 1-lane mode is currently disabled; attempts to use it produced no valid image.

[root@diasom-evb ~]# v4l2-compliance -u 2
v4l2-compliance 1.28.1, 64 bits, 64-bit time_t

Compliance test for device /dev/v4l-subdev2:

Driver Info:
ar0234 9-0018: ================= START STATUS ================= ar0234 9-0018: ================== END STATUS ==================

        Driver version   : 7.1.0
        Capabilities     : 0x00000000
        Client Capabilities: 0x0000000000000002

interval-uses-which
Required ioctls:
test VIDIOC_SUDBEV_QUERYCAP: OK
test invalid ioctls: OK

Allow for multiple opens:
test second /dev/v4l-subdev2 open: OK
test VIDIOC_SUBDEV_QUERYCAP: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 20 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK (Not Supported)
test VIDIOC_TRY_FMT: OK (Not Supported)
test VIDIOC_S_FMT: OK (Not Supported)
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported) test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test Requests: OK (Not Supported)

Total for device /dev/v4l-subdev2: 45, Succeeded: 45, Failed: 0, Warnings: 0

V1 -> V2:
- Fixed bugs reported by sashiko-bot:
- [Low] The compatible property schema contains fatal YAML syntax errors due to missing list hyphens (-), resulting in invalid JSON schema constructs that will fail dt_binding_check.
- [Low] The data-lanes schema constraint mathematically allows 3 lanes, which contradicts the explicit 2-or-4 lane hardware requirement described in the binding.
- [Critical] Incorrect clamping order in crop selection bounds calculation causes unsigned integer underflow, bypassing bounds checks.
- [High] Incorrect validation of pm_runtime_get_if_active() allows execution to proceed on negative error codes, leading to a usage counter underflow.
- [High] Static hblank lower bounds permit dynamic line length reduction below the absolute hardware minimum.
- [High] Potential division by zero during delay calculation if the clock rate is zero.
- [Medium] Unlocked V4L2 control helpers are called during initialization without acquiring the control handler lock, triggering a lockdep splat.
- [Medium] Mixing goto-based error handling with scope-based __free() cleanup in the same function violates API guidelines.
- [Medium] Changing the crop height fails to update exposure control limits reliably.
- [Medium] The active format state is modified before verifying PLL configuration, leaving state inconsistent on error.
- [Medium] Unlocked access to shared format state in ar0234_get_frame_desc.
- [Low] Using DIV_ROUND_UP with a 64-bit numerator causes a link error on 32-bit architectures.

V2 -> V3:
- Fixed bugs reported by sashiko-bot:
- [Low] Standard properties 'orientation' and 'rotation' bypass standard type validation.
- [High] Incorrect initialization order of the V4L2 active state and control handler breaks lock sharing, causing lockdep splats, data races, and masking a self-deadlock in ar0234_set_pad_format().
- [High] Brittle and restrictive parsing of the 'link-frequencies' device tree property.
- [High] Invalid rectangle clamping logic in ar0234_set_selection() allows crop width and height to underflow their minimum limits.
- [High] Incorrect power-down sequence disables regulators before stopping the external clock.
- [Medium] Unchecked return value from v4l2_subdev_state_get_format() in ar0234_get_frame_desc() may cause a NULL pointer dereference.
- [Medium] Unconditional overwrite of the VBLANK control value upon format or crop changes.
- [Medium] Missing media_entity_cleanup() in the subdevice cleanup routine causes media graph objects to leak upon removal.

Alexander Shiyan (2):
dt-bindings: media: i2c: Add onsemi AR0234 image sensor binding
media: i2c: Add onsemi AR0234 image sensor driver

 .../bindings/media/i2c/onnn,ar0234.yaml       |  121 ++
 drivers/media/i2c/Kconfig                     |   12 +
 drivers/media/i2c/Makefile                    |    1 +
 drivers/media/i2c/ar0234.c                    | 1294 +++++++++++++++++
 4 files changed, 1428 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/onnn,ar0234.yaml
 create mode 100644 drivers/media/i2c/ar0234.c

2.52.0

Add devicetree binding for the onsemi AR0234 CMOS image sensor.

---
 .../bindings/media/i2c/onnn,ar0234.yaml       | 121 ++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/onnn,ar0234.yaml

new file mode 100644
index 000000000000..ee321acf22b5
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/onnn,ar0234.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor AR0234 1/2.6-inch CMOS Digital Image Sensor
+
+maintainers:
+  - Alexander Shiyan <[email protected]>
+
+description:
+  The AR0234 is a 1/2.6-inch CMOS digital image sensor with a pixel
+  array of 1940x1220 pixels, capable of 1920x1200 resolution at up
+  to 120 fps. It supports MIPI CSI-2 output with 2 or 4 data lanes,
+  color raw Bayer (8/10-bit) or monochrome output.
+
+allOf:
+- $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+  compatible:
+    enum:
+      - onnn,ar0234cssc
+      - onnn,ar0234cssm
+      - onnn,ar0234cs
+    description:
+      The AR0234 sensor exists in two different models, a colour variant
+      (AR0234CSSC) and a monochrome variant (AR0234CSSM). The device exposes
+      the model through registers, allowing for auto-detection with a common
+      "onnn,ar0234cs" compatible string.
+
+  reg:
+    description: I2C device address
+    maxItems: 1
+
+  clocks:
+    description: Reference clock (external clock) input
+    maxItems: 1
+
+  reset-gpios:
+    description: Reset pin, usually active low (if needed)
+    maxItems: 1
+
+  vaa-supply:
+    description: Analog (2.8V) supply regulator
+
+  vdd-supply:
+    description: Digital Core (1.2V) supply regulator
+
+  vddio-supply:
+    description: I/O (1.8V-2.8V) supply regulator
+
+  port:
+    $ref: /schemas/graph.yaml#/$defs/port-base
+    description: CSI-2 transmitter port
+    additionalProperties: false
+
+    properties:
+      endpoint:
+        $ref: /schemas/media/video-interfaces.yaml#
+        unevaluatedProperties: false
+
+        properties:
+          data-lanes:
+            oneOf:
+              - items:
+                  - const: 1
+                  - const: 2
+              - items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+
+          link-frequencies: true
+
+        required:
+          - data-lanes
+          - link-frequencies
+
+    required:
+      - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        camera@18 {
+            compatible = "onnn,ar0234cs";
+            reg = <0x18>;
+            pinctrl-names = "default";
+            pinctrl-0 = <&pinctrl_cam>;
+            clocks = <&clk27m>;
+            vaa-supply = <&reg_cam_vaa>;
+            vdd-supply = <&reg_cam_vdd>;
+            vddio-supply = <&reg_cam_vddio>;
+            reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
+
+            port {
+                ar0234_out: endpoint {
+                    data-lanes = <1 2 3 4>;
+                    link-frequencies = /bits/ 64 <360000000 450000000>;
+                    remote-endpoint = <&ar0234_in>;
+                };
+            };
+        };
+    };
+...

2.52.0

Unanswered Sashiko comments.

Hello.

I do not understand this remark.
The corrections based on sashiko-bot's feedback are included in the cover letter.
Is something wrong?

...

Perhaps I need to revert to the compatibility strings that were used in version 2
(https://patchwork.kernel.org/project/linux-media/patch/[email protected]/).

From a programming standpoint, it makes almost no difference which sensor is used
- the only differences are in the output format and the format count. Either way, the driver always uses the sensor model determined via register reads.
If the specified type does not match the detected one, only a warning will be printed.

Thanks!

You received here Sashiko report which looks reasonable and you did not answer it. At least I could not find such answer.

Devices should be made compatible with the fallback or even the color and mono variants could be dropped. That depends on the difference between color/mono.

Best regards,
Krzysztof

Hello.

...

Removing the separation would result in a regression.
The addition of the color and mono variants was proposed by Dave Stevenson following
the first RFC version of the patch.
Subsequently, Laurent Pinchart suggested an implementation approach, which was indeed adopted, though it has evolved somewhat into its current form.

Thanks!

What regression? You just proposed these compatibles, they are not accepted, so how and what possible could ever regress?

Best regards,
Krzysztof

Hi,

Three things that may help: the concrete colour/mono difference, a close precedent in-tree, and a piece of earlier review that has not come up.

There are two hardware models; the third string is not one of them. From patch 2/2: the models have distinct chip ids, 0x0a56 and 0x1a56, read from CHIP_VERSION (0x3000), and an unrecognised id fails probe. The only register write conditioned on the model is DIGITAL_TEST bit 7, MONO_CHROME_OPERATION. The model also selects the advertised bus codes, Y8/Y10 versus SGRBG8/SGRBG10, and the mode table exposes the 10-to-8-bit DPCM code for colour only - though that last one is arguably a media-bus-format gap, as there is no mono DPCM code, rather than a sensor difference.

The suffix-less "onnn,ar0234cs" entry carries no match data, so the model read from the chip is kept. The cssc/cssm entries do carry match data, and on a mismatch the driver warns and uses the DT-selected one.

sony,imx678.yaml went through this exact question in May. It was posted as a flat enum of three strings, with a description noting the variants could be detected at runtime:

compatible:
enum:
- sony,imx678
- sony,imx678-aamr
- sony,imx678-aaqr

Conor's objection was that a DT naming both the specific and the generic string would then fail validation:

https://lore.kernel.org/all/20260520-crusher-species-cf707a9a8b46@spud/

and v4 changed it to the form now in tree, with the changelog entry "Follow Conor's suggestion of mandating both the specific and generic device name in the compatible property":

compatible:
items:
- enum:
- sony,imx678-aamr
- sony,imx678-aaqr
- const: sony,imx678

Note that is the mandatory form rather than the oneOf v2 used - there the generic string alone is not valid.

The other colour/mono bindings in that directory use a flat enum:
sony,imx296, st,vd55g1 and st,vd56g3 all describe the split in the binding text, and aptina,mt9p031 does not. sony,imx290 uses a oneOf, but of five model strings plus a deprecated standalone generic.

The v2 fallback form did go through dt-bindings review. Rob quoted it down to the enum line:

compatible:
oneOf:
- const: onnn,ar0234cs
- items:
- enum: ["onnn,ar0234cssc", "onnn,ar0234cssm"]

replied inline with

- enum:
- onnn,ar0234cssc
- onnn,ar0234cssm

Please explain somewhere what the differences between the 3 cases are.

and the quotation then resumes with "- const: onnn,ar0234cs":

https://lore.kernel.org/all/[email protected]/

So that replaced the flow-style enum with a block one and left the oneOf/items structure standing. Reverting to the v2 shape would not be going against that review.

That leaves the question the thread has not settled: whether a bare generic compatible is meant to be valid. Laurent listed the use cases the model-specific strings serve, on the RFC -

https://lore.kernel.org/linux-media/[email protected]/

avoiding a sensor power-up at boot when the module is known at build time, and a runtime sanity check. Of those only the sanity check is delivered today, since probe powers the sensor up and reads the id before it looks at the match data, so a model-specific compatible does not currently save anything at boot. He proposed both forms in that message, and concluded "I don't think we've decided on a recommended practice."

If one DT is meant to serve interchangeable colour and mono modules, the v2 oneOf expresses that. If conforming DTs are expected to name the model, the mandatory imx678 form fits, and the driver can still tolerate generic-only DTs. Either way it seems worth saying which one in the binding.

Thanks,
Aleksandr Chubuchnyi

Plus, there was already v3 here:
<[email protected]>

so how are we supposed to compare this?
Did you address v3 feedback in this v3+1 version?

Drop second/last, redundant "bindings". The "dt-bindings" prefix is already stating that these are bindings. See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23

Best regards,
Krzysztof

Hello.

Version v3, which was introduced about six months ago, was labeled with the 'RFC' prefix.

You're right - this will need to be fixed.

Thanks!

Label does not matter, it was still v3 and this is v3. Again - try comparing them yourself:

b4 diff '<[email protected]>'

Which version is used for comparing?

Best regards,
Krzysztof

Add driver for the onsemi AR0234 CMOS image sensor.

---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |    1 +
 drivers/media/i2c/ar0234.c | 1294 ++++++++++++++++++++++++++++++++++++
 3 files changed, 1307 insertions(+)
 create mode 100644 drivers/media/i2c/ar0234.c

index 5c52007f9cbe..febab9857cd5 100644
@@ -51,6 +51,18 @@ config VIDEO_ALVIUM_CSI2
 	  To compile this driver as a module, choose M here: the
 	  module will be called alvium-csi2.
 
+config VIDEO_AR0234
+	tristate "onsemi AR0234 sensor support"
+	depends on ACPI || OF || COMPILE_TEST
+	select V4L2_CCI_I2C
+	select VIDEO_CCS_PLL
+	help
+	  This is a Video4Linux2 sensor driver for the onsemi
+	  AR0234 camera.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called ar0234.
+
 config VIDEO_AR0521
 	tristate "ON Semiconductor AR0521 sensor support"
 	help

index d04bd5724552..8310db5c63b5 100644
@@ -19,6 +19,7 @@ obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
 obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
 obj-$(CONFIG_VIDEO_ALVIUM_CSI2) += alvium-csi2.o
 obj-$(CONFIG_VIDEO_APTINA_PLL) += aptina-pll.o
+obj-$(CONFIG_VIDEO_AR0234) += ar0234.o
 obj-$(CONFIG_VIDEO_AR0521) += ar0521.o
 obj-$(CONFIG_VIDEO_BT819) += bt819.o
 obj-$(CONFIG_VIDEO_BT856) += bt856.o

2.52.0