Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

media: dt-bindings: i2c: Add Sony IMX500 #6194

Open
wants to merge 1 commit into
base: rpi-6.6.y
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
161 changes: 161 additions & 0 deletions Documentation/devicetree/bindings/media/i2c/sony,imx500.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,161 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/sony,imx500.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Sony CMOS Digital Image Sensor and CNN

maintainers:
- Raspberry Pi <[email protected]>

description: |-
The Sony IMX500 is a stacked 1/2.3-inch CMOS digital image sensor and inbuilt
AI processor with an active array CNN (Convolutional Neural Network) inference
engine. The native sensor size is 4056H x 3040V, and the module also contains
an in-built ISP for the CNN. The module is programmable through an I2C
interface with firmware and neural network uploads being made over SPI. The
default I2C address is 0x1A, with an address of 0x10 being selectable via
SLASEL. The module also has a second I2C interface available with a fixed
address of 0x36. Image data is sent through MIPI CSI-2, which is configured
as either 2 or 4 data lanes.

properties:
compatible:
const: sony,imx500

reg:
description: I2C device address
maxItems: 1

clocks:
maxItems: 1

clock-names:
description: |-
Input clock (12 to 27 MHz)
items:
- const: inck

interrupts:
maxItems: 1

vana-supply:
description: Supply voltage (analog) - 2.7 V

vdig-supply:
description: Supply voltage (digital) - 0.84 V

vif-supply:
description: Supply voltage (interface) - 1.8 V

reset-gpios:
description: |-
Sensor reset (XCLR) GPIO

Chip clear in lieu of built-in power on reset. To be set 'High' after
power supplies are brought up and INCK supplied.

port:
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
description: |
Video output port

properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
type: object
unevaluatedProperties: false
properties:
data-lanes:
items:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your description states it supports 2 or 4 lanes, but this only allows 2.

          data-lanes:
            oneOf:
              - items:
                  - const: 1
                  - const: 2
                  - const: 3
                  - const: 4
              - items:
                  - const: 1
                  - const: 2

- const: 1
- const: 2
clock-noncontinuous: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whilst not incorrect to be in the binding, just check whether you are actually selecting non-continuous clock, or and whether it is mandatory (I'm never clear in bindings whether this "true" means supported or must be set).

I've just been looking at imx477 and found that the sensor is configured for continuous clocks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference, #6208 for adding continuous clock mode selection to imx477.

link-frequencies: true
clock-lanes:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clock-lanes is normally skipped when there is no support for lane reordering.

items:
- const: 0
required:
- link-frequencies
- clock-lanes
- data-lanes

required:
- compatible
- reg

allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
required:
- spi-max-frequency
then:
properties:
# SPI node
clocks: false
clock-names: false
vana-supply: false
vdig-supply: false
vif-supply: false
reset-gpios: false
port: false
else:
required:
- clocks
- clock-names
- vana-supply
- vdig-supply
- vif-supply
- reset-gpios
- port

unevaluatedProperties: false

examples:
- |
#include <dt-bindings/gpio/gpio.h>

i2c {
#address-cells = <1>;
#size-cells = <0>;

imx500: sensor@1a {
compatible = "sony,imx500";
reg = <0x1a>;

clocks = <&imx500_clk>;
clock-names = "inck";

vana-supply = <&imx500_vana>; /* 2.7 +/- 0.1 V */
vdig-supply = <&imx500_vdig>; /* 0.84 +/- 0.04 V */
vif-supply = <&imx500_vif>; /* 1.8 +/- 0.1 V */

reset-gpios = <&gpio_sensor 0 GPIO_ACTIVE_LOW>;

port {
imx500_0: endpoint {
clock-lanes = <0>;
remote-endpoint = <&csi1_ep>;
data-lanes = <1 2>;
clock-noncontinuous;
link-frequencies = /bits/ 64 <499500000>;
};
};
};
};

spi {
#address-cells = <1>;
#size-cells = <0>;

sensor@0 {
compatible = "sony,imx500";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You've not pushed the driver yet, but doesn't this instantiate a second instance of the driver? How do the 2 get associated, or do they deliberately not?

I'm thinking of what happens if you have 2 attached to the system. How do you control which SPI and I2C device are linked, or does it not matter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm currently refactoring the driver but I will push it soon.

I'm doing something very similar to the s5c73m3 driver:

ret = s5c73m3_register_spi_driver(state);

int s5c73m3_register_spi_driver(struct s5c73m3 *state)

I'll have to examine the consequences of having 2 devices attached to the the system more closely.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So AIUI that will gate registering the SPI driver part until the I2C bit has loaded, which is necessary as the i2c part allocates the common state structure.

However I don't see how that will work with two (it may not be applicable for that driver).
s5c73m3_register_spi_driver will get called when the first I2C device gets probed, but that will allow both SPI instances to probe, and the container_of(spi->dev.driver, ...) will point back to the one I2C instance.
When the second I2C device probes, spi_register_driver will get called for a second time, but I sort of hope it falls down the "Error: Driver '%s' is already registered, aborting" error path at https://elixir.bootlin.com/linux/latest/source/drivers/base/driver.c#L241

I don't know exactly what it would look like, but I would have expected a form not dissimilar to the lens-focus or flash DT links that you get from an image sensor to lens or flash devices. (Those get handled by the common v4l2-fwnode code, whereas this would be driver specific).

reg = <0>;
spi-max-frequency = <35000000>;
};
};

...

7 changes: 7 additions & 0 deletions MAINTAINERS
Original file line number Diff line number Diff line change
Expand Up @@ -20103,6 +20103,13 @@ F: Documentation/devicetree/bindings/media/i2c/imx378.yaml
F: Documentation/devicetree/bindings/media/i2c/imx477.yaml
F: drivers/media/i2c/imx477.c

SONY IMX500 SENSOR DRIVER
M: Raspberry Pi Kernel Maintenance <[email protected]>
L: [email protected]
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/sony,imx500.yaml

SONY IMX519 SENSOR DRIVER
M: Arducam Kernel Maintenance <[email protected]>
L: [email protected]
Expand Down