* [V7, 0/2] media: i2c: Add support for OV02A10 sensor
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang, dongchun.zhu
Hello,
This series adds DT bindings in YAML and V4L2 sub-device driver for Omnivision's
OV02A10 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface
and output format of 10-bit RAW.
The driver is implemented with V4L2 framework.
- Async registered as a V4L2 sub-device.
- As the first component of camera system including Seninf, ISP pipeline.
- A media entity that provides one source pad in common and two for dual-cam.
Changes of v7 mainly address comments from Rob, Tomasz, Andy, Sakari.
- Rebase onto 5.7-rc1
- Use DT bindings in YAML to replace of old text documentation
- Document optional property "ovti,mipi-tx-speed" and "rotation"
- Refine driver more simply
Previous versions of this patch-set can be found here:
v6: https://lore.kernel.org/linux-media/20191211112849.16705-1-dongchun.zhu@mediatek.com/
v5: https://lore.kernel.org/linux-media/20191104105713.24311-1-dongchun.zhu@mediatek.com/
v4: https://lore.kernel.org/linux-media/20190907092728.23897-1-dongchun.zhu@mediatek.com/
v3: https://lore.kernel.org/linux-media/20190819034331.13098-1-dongchun.zhu@mediatek.com/
v2: https://lore.kernel.org/linux-media/20190704084651.3105-1-dongchun.zhu@mediatek.com/
v1: https://lore.kernel.org/linux-media/20190523102204.24112-1-dongchun.zhu@mediatek.com/
Changes of v7 mainly address comments from Rob, Tomasz, Andy, Sakari.
- Rebase onto 5.7-rc1
- Use DT bindings in YAML to replace of old text documentation
- Document optional property "ovti,mipi-tx-speed" and "rotation"
- Refine driver more simply
Please review.
Thanks.
Dongchun Zhu (2):
media: dt-bindings: media: i2c: Document OV02A10 bindings
media: i2c: ov02a10: Add OV02A10 image sensor driver
.../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov02a10.c | 1090 ++++++++++++++++++++
5 files changed, 1258 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
create mode 100644 drivers/media/i2c/ov02a10.c
--
2.9.2
^ permalink raw reply [flat|nested] 57+ messages in thread
* [V7, 0/2] media: i2c: Add support for OV02A10 sensor
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Hello,
This series adds DT bindings in YAML and V4L2 sub-device driver for Omnivision's
OV02A10 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface
and output format of 10-bit RAW.
The driver is implemented with V4L2 framework.
- Async registered as a V4L2 sub-device.
- As the first component of camera system including Seninf, ISP pipeline.
- A media entity that provides one source pad in common and two for dual-cam.
Changes of v7 mainly address comments from Rob, Tomasz, Andy, Sakari.
- Rebase onto 5.7-rc1
- Use DT bindings in YAML to replace of old text documentation
- Document optional property "ovti,mipi-tx-speed" and "rotation"
- Refine driver more simply
Previous versions of this patch-set can be found here:
v6: https://lore.kernel.org/linux-media/20191211112849.16705-1-dongchun.zhu@mediatek.com/
v5: https://lore.kernel.org/linux-media/20191104105713.24311-1-dongchun.zhu@mediatek.com/
v4: https://lore.kernel.org/linux-media/20190907092728.23897-1-dongchun.zhu@mediatek.com/
v3: https://lore.kernel.org/linux-media/20190819034331.13098-1-dongchun.zhu@mediatek.com/
v2: https://lore.kernel.org/linux-media/20190704084651.3105-1-dongchun.zhu@mediatek.com/
v1: https://lore.kernel.org/linux-media/20190523102204.24112-1-dongchun.zhu@mediatek.com/
Changes of v7 mainly address comments from Rob, Tomasz, Andy, Sakari.
- Rebase onto 5.7-rc1
- Use DT bindings in YAML to replace of old text documentation
- Document optional property "ovti,mipi-tx-speed" and "rotation"
- Refine driver more simply
Please review.
Thanks.
Dongchun Zhu (2):
media: dt-bindings: media: i2c: Document OV02A10 bindings
media: i2c: ov02a10: Add OV02A10 image sensor driver
.../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov02a10.c | 1090 ++++++++++++++++++++
5 files changed, 1258 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
create mode 100644 drivers/media/i2c/ov02a10.c
--
2.9.2
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* [V7, 0/2] media: i2c: Add support for OV02A10 sensor
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Hello,
This series adds DT bindings in YAML and V4L2 sub-device driver for Omnivision's
OV02A10 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface
and output format of 10-bit RAW.
The driver is implemented with V4L2 framework.
- Async registered as a V4L2 sub-device.
- As the first component of camera system including Seninf, ISP pipeline.
- A media entity that provides one source pad in common and two for dual-cam.
Changes of v7 mainly address comments from Rob, Tomasz, Andy, Sakari.
- Rebase onto 5.7-rc1
- Use DT bindings in YAML to replace of old text documentation
- Document optional property "ovti,mipi-tx-speed" and "rotation"
- Refine driver more simply
Previous versions of this patch-set can be found here:
v6: https://lore.kernel.org/linux-media/20191211112849.16705-1-dongchun.zhu@mediatek.com/
v5: https://lore.kernel.org/linux-media/20191104105713.24311-1-dongchun.zhu@mediatek.com/
v4: https://lore.kernel.org/linux-media/20190907092728.23897-1-dongchun.zhu@mediatek.com/
v3: https://lore.kernel.org/linux-media/20190819034331.13098-1-dongchun.zhu@mediatek.com/
v2: https://lore.kernel.org/linux-media/20190704084651.3105-1-dongchun.zhu@mediatek.com/
v1: https://lore.kernel.org/linux-media/20190523102204.24112-1-dongchun.zhu@mediatek.com/
Changes of v7 mainly address comments from Rob, Tomasz, Andy, Sakari.
- Rebase onto 5.7-rc1
- Use DT bindings in YAML to replace of old text documentation
- Document optional property "ovti,mipi-tx-speed" and "rotation"
- Refine driver more simply
Please review.
Thanks.
Dongchun Zhu (2):
media: dt-bindings: media: i2c: Document OV02A10 bindings
media: i2c: ov02a10: Add OV02A10 image sensor driver
.../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov02a10.c | 1090 ++++++++++++++++++++
5 files changed, 1258 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
create mode 100644 drivers/media/i2c/ov02a10.c
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-04-30 8:09 ` Dongchun Zhu
(?)
@ 2020-04-30 8:09 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang, dongchun.zhu
Add DT bindings documentation for Omnivision OV02A10 image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
.../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
new file mode 100644
index 0000000..2be4bd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
+
+maintainers:
+ - Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+description: |-
+ The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
+ image sensor, which is the latest production derived from Omnivision's CMOS
+ image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
+ @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
+ sensor output is available via CSI-2 serial data output.
+
+properties:
+ compatible:
+ const: ovti,ov02a10
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: top mux camtg clock
+ - description: devider clock
+
+ clock-names:
+ items:
+ - const: eclk
+ - const: freq_mux
+
+ clock-frequency:
+ description:
+ Frequency of the eclk clock in Hertz.
+
+ dovdd-supply:
+ description:
+ Definition of the regulator used as interface power supply.
+
+ avdd-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+ dvdd-supply:
+ description:
+ Definition of the regulator used as digital power supply.
+
+ powerdown-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor powerdown.
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+
+ rotation:
+ description:
+ Definition of the sensor's placement, valid values are 0 and 180.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ - 0 # Sensor Mounted Upright
+ - 180 # Sensor Mounted Upside Down
+
+ ovti,mipi-tx-speed:
+ description:
+ Indication of MIPI transmission speed select.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum: [ 3, 4 ]
+
+ # See ../video-interfaces.txt for details
+ port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ remote-endpoint: true
+ link-frequencies: true
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-frequency
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - powerdown-gpios
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov02a10: camera-sensor@3d {
+ compatible = "ovti,ov02a10";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk_24m_cam>;
+
+ clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
+ <&topckgen CLK_TOP_UNIVP_192M_D8>;
+ clock-names = "eclk", "freq_mux";
+ clock-frequency = <24000000>;
+
+ rotation = <180>;
+ ovti,mipi-tx-speed = <3>;
+
+ dovdd-supply = <&mt6358_vcamio_reg>;
+ avdd-supply = <&mt6358_vcama1_reg>;
+ dvdd-supply = <&mt6358_vcn18_reg>;
+ powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
+
+ port {
+ wcam_out: endpoint {
+ remote-endpoint = <&mipi_in_wcam>;
+ link-frequencies = /bits/ 64 <390000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..63a2335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
S: Maintained
F: drivers/char/pcmcia/cm4040_cs.*
+OMNIVISION OV02A10 SENSOR DRIVER
+M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
--
2.9.2
^ permalink raw reply related [flat|nested] 57+ messages in thread
* [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Add DT bindings documentation for Omnivision OV02A10 image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
.../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
new file mode 100644
index 0000000..2be4bd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
+
+maintainers:
+ - Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+description: |-
+ The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
+ image sensor, which is the latest production derived from Omnivision's CMOS
+ image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
+ @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
+ sensor output is available via CSI-2 serial data output.
+
+properties:
+ compatible:
+ const: ovti,ov02a10
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: top mux camtg clock
+ - description: devider clock
+
+ clock-names:
+ items:
+ - const: eclk
+ - const: freq_mux
+
+ clock-frequency:
+ description:
+ Frequency of the eclk clock in Hertz.
+
+ dovdd-supply:
+ description:
+ Definition of the regulator used as interface power supply.
+
+ avdd-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+ dvdd-supply:
+ description:
+ Definition of the regulator used as digital power supply.
+
+ powerdown-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor powerdown.
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+
+ rotation:
+ description:
+ Definition of the sensor's placement, valid values are 0 and 180.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ - 0 # Sensor Mounted Upright
+ - 180 # Sensor Mounted Upside Down
+
+ ovti,mipi-tx-speed:
+ description:
+ Indication of MIPI transmission speed select.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum: [ 3, 4 ]
+
+ # See ../video-interfaces.txt for details
+ port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ remote-endpoint: true
+ link-frequencies: true
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-frequency
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - powerdown-gpios
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov02a10: camera-sensor@3d {
+ compatible = "ovti,ov02a10";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk_24m_cam>;
+
+ clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
+ <&topckgen CLK_TOP_UNIVP_192M_D8>;
+ clock-names = "eclk", "freq_mux";
+ clock-frequency = <24000000>;
+
+ rotation = <180>;
+ ovti,mipi-tx-speed = <3>;
+
+ dovdd-supply = <&mt6358_vcamio_reg>;
+ avdd-supply = <&mt6358_vcama1_reg>;
+ dvdd-supply = <&mt6358_vcn18_reg>;
+ powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
+
+ port {
+ wcam_out: endpoint {
+ remote-endpoint = <&mipi_in_wcam>;
+ link-frequencies = /bits/ 64 <390000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..63a2335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
S: Maintained
F: drivers/char/pcmcia/cm4040_cs.*
+OMNIVISION OV02A10 SENSOR DRIVER
+M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
--
2.9.2
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 57+ messages in thread
* [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Add DT bindings documentation for Omnivision OV02A10 image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
.../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
new file mode 100644
index 0000000..2be4bd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
+
+maintainers:
+ - Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+description: |-
+ The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
+ image sensor, which is the latest production derived from Omnivision's CMOS
+ image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
+ @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
+ sensor output is available via CSI-2 serial data output.
+
+properties:
+ compatible:
+ const: ovti,ov02a10
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: top mux camtg clock
+ - description: devider clock
+
+ clock-names:
+ items:
+ - const: eclk
+ - const: freq_mux
+
+ clock-frequency:
+ description:
+ Frequency of the eclk clock in Hertz.
+
+ dovdd-supply:
+ description:
+ Definition of the regulator used as interface power supply.
+
+ avdd-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+ dvdd-supply:
+ description:
+ Definition of the regulator used as digital power supply.
+
+ powerdown-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor powerdown.
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+
+ rotation:
+ description:
+ Definition of the sensor's placement, valid values are 0 and 180.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ - 0 # Sensor Mounted Upright
+ - 180 # Sensor Mounted Upside Down
+
+ ovti,mipi-tx-speed:
+ description:
+ Indication of MIPI transmission speed select.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum: [ 3, 4 ]
+
+ # See ../video-interfaces.txt for details
+ port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ remote-endpoint: true
+ link-frequencies: true
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-frequency
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - powerdown-gpios
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov02a10: camera-sensor@3d {
+ compatible = "ovti,ov02a10";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk_24m_cam>;
+
+ clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
+ <&topckgen CLK_TOP_UNIVP_192M_D8>;
+ clock-names = "eclk", "freq_mux";
+ clock-frequency = <24000000>;
+
+ rotation = <180>;
+ ovti,mipi-tx-speed = <3>;
+
+ dovdd-supply = <&mt6358_vcamio_reg>;
+ avdd-supply = <&mt6358_vcama1_reg>;
+ dvdd-supply = <&mt6358_vcn18_reg>;
+ powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
+
+ port {
+ wcam_out: endpoint {
+ remote-endpoint = <&mipi_in_wcam>;
+ link-frequencies = /bits/ 64 <390000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..63a2335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
S: Maintained
F: drivers/char/pcmcia/cm4040_cs.*
+OMNIVISION OV02A10 SENSOR DRIVER
+M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 57+ messages in thread
* [V7, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
2020-04-30 8:09 ` Dongchun Zhu
(?)
@ 2020-04-30 8:09 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang, dongchun.zhu
Add a V4L2 sub-device driver for OV02A10 image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
MAINTAINERS | 1 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov02a10.c | 1090 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 1103 insertions(+)
create mode 100644 drivers/media/i2c/ov02a10.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 63a2335..e7677c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12395,6 +12395,7 @@ L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+F: drivers/media/i2c/ov02a10.c
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596..fff92c3 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -655,6 +655,17 @@ config VIDEO_IMX355
To compile this driver as a module, choose M here: the
module will be called imx355.
+config VIDEO_OV02A10
+ tristate "OmniVision OV02A10 sensor support"
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+ help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV02A10 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov02a10.
+
config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 77bf7d0..6566dd9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV02A10) += ov02a10.o
obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
new file mode 100644
index 0000000..6a30cf3
--- /dev/null
+++ b/drivers/media/i2c/ov02a10.c
@@ -0,0 +1,1090 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 MediaTek Inc.
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <media/media-entity.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-fwnode.h>
+
+#define CHIP_ID 0x2509
+#define OV02A10_REG_CHIP_ID_H 0x02
+#define OV02A10_REG_CHIP_ID_L 0x03
+#define OV02A10_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
+
+/* Bit[1] vertical upside down */
+/* Bit[0] horizontal mirror */
+#define REG_MIRROR_FLIP_CONTROL 0x3f
+
+/* Orientation */
+#define REG_MIRROR_FLIP_ENABLE 0x03
+
+/* Bit[7] clock HS mode enable
+ * 0: Clock continue
+ * 1: Clock HS
+ * Bit[6:2] HS VOD adjust
+ * Bit[1:0] P VHI adjust
+ */
+#define REG_HS_MODE_BLC 0x9d
+
+#define CLOCK_HS_MODE_ENABLE BIT(7)
+
+/* Bit[2:0] MIPI transmission speed select */
+#define TX_SPEED_AREA_SEL 0xa1
+
+#define REG_PAGE_SWITCH 0xfd
+#define REG_GLOBAL_EFFECTIVE 0x01
+#define REG_ENABLE BIT(0)
+
+#define REG_SC_CTRL_MODE 0xac
+#define SC_CTRL_MODE_STANDBY 0x00
+#define SC_CTRL_MODE_STREAMING 0x01
+
+#define OV02A10_EXP_SHIFT 8
+#define OV02A10_REG_EXPOSURE_H 0x03
+#define OV02A10_REG_EXPOSURE_L 0x04
+#define OV02A10_EXPOSURE_MIN 4
+#define OV02A10_EXPOSURE_MAX_MARGIN 4
+#define OV02A10_EXPOSURE_STEP 1
+
+#define OV02A10_VTS_SHIFT 8
+#define OV02A10_REG_VTS_H 0x05
+#define OV02A10_REG_VTS_L 0x06
+#define OV02A10_VTS_MAX 0x209f
+#define OV02A10_VTS_MIN 0x04cf
+#define OV02A10_BASIC_LINE 1224
+
+#define OV02A10_REG_GAIN 0x24
+#define OV02A10_GAIN_MIN 0x10
+#define OV02A10_GAIN_MAX 0xf8
+#define OV02A10_GAIN_STEP 0x01
+#define OV02A10_GAIN_DEFAULT 0x40
+
+/* Test pattern control */
+#define OV02A10_REG_TEST_PATTERN 0xb6
+#define OV02A10_TEST_PATTERN_ENABLE BIT(0)
+
+#define HZ_PER_MHZ 1000000L
+#define OV02A10_LINK_FREQ_390MHZ (390 * HZ_PER_MHZ)
+#define OV02A10_ECLK_FREQ (24 * HZ_PER_MHZ)
+#define OV02A10_DATA_LANES 1
+#define OV02A10_BITS_PER_SAMPLE 10
+
+static const char * const ov02a10_supply_names[] = {
+ "dovdd", /* Digital I/O power */
+ "avdd", /* Analog power */
+ "dvdd", /* Digital core power */
+};
+
+#define OV02A10_NUM_SUPPLIES ARRAY_SIZE(ov02a10_supply_names)
+
+struct ov02a10_reg {
+ u8 addr;
+ u8 val;
+};
+
+struct ov02a10_reg_list {
+ u32 num_of_regs;
+ const struct ov02a10_reg *regs;
+};
+
+struct ov02a10_mode {
+ u32 width;
+ u32 height;
+ u32 exp_def;
+ u32 hts_def;
+ u32 vts_def;
+ const struct ov02a10_reg_list reg_list;
+};
+
+struct ov02a10 {
+ u32 eclk_freq;
+ u32 mipi_clock_tx_speed;
+
+ struct clk *eclk;
+ struct gpio_desc *pd_gpio;
+ struct gpio_desc *n_rst_gpio;
+ struct regulator_bulk_data supplies[OV02A10_NUM_SUPPLIES];
+
+ bool streaming;
+ bool upside_down;
+ bool mipi_clock_hs_mode_enable;
+
+ /*
+ * Serialize control access, get/set format, get selection
+ * and start streaming.
+ */
+ struct mutex mutex;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_ctrl *anal_gain;
+ struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vblank;
+ struct v4l2_ctrl *test_pattern;
+ struct v4l2_mbus_framefmt fmt;
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov02a10_mode *cur_mode;
+};
+
+static inline struct ov02a10 *to_ov02a10(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov02a10, subdev);
+}
+
+/*
+ * eclk 24Mhz
+ * pclk 39Mhz
+ * linelength 934(0x3a6)
+ * framelength 1390(0x56E)
+ * grabwindow_width 1600
+ * grabwindow_height 1200
+ * max_framerate 30fps
+ * mipi_datarate per lane 780Mbps
+ */
+static const struct ov02a10_reg ov02a10_1600x1200_regs[] = {
+ {0xfd, 0x01},
+ {0xac, 0x00},
+ {0xfd, 0x00},
+ {0x2f, 0x29},
+ {0x34, 0x00},
+ {0x35, 0x21},
+ {0x30, 0x15},
+ {0x33, 0x01},
+ {0xfd, 0x01},
+ {0x44, 0x00},
+ {0x2a, 0x4c},
+ {0x2b, 0x1e},
+ {0x2c, 0x60},
+ {0x25, 0x11},
+ {0x03, 0x01},
+ {0x04, 0xae},
+ {0x09, 0x00},
+ {0x0a, 0x02},
+ {0x06, 0xa6},
+ {0x31, 0x00},
+ {0x24, 0x40},
+ {0x01, 0x01},
+ {0xfb, 0x73},
+ {0xfd, 0x01},
+ {0x16, 0x04},
+ {0x1c, 0x09},
+ {0x21, 0x42},
+ {0x12, 0x04},
+ {0x13, 0x10},
+ {0x11, 0x40},
+ {0x33, 0x81},
+ {0xd0, 0x00},
+ {0xd1, 0x01},
+ {0xd2, 0x00},
+ {0x50, 0x10},
+ {0x51, 0x23},
+ {0x52, 0x20},
+ {0x53, 0x10},
+ {0x54, 0x02},
+ {0x55, 0x20},
+ {0x56, 0x02},
+ {0x58, 0x48},
+ {0x5d, 0x15},
+ {0x5e, 0x05},
+ {0x66, 0x66},
+ {0x68, 0x68},
+ {0x6b, 0x00},
+ {0x6c, 0x00},
+ {0x6f, 0x40},
+ {0x70, 0x40},
+ {0x71, 0x0a},
+ {0x72, 0xf0},
+ {0x73, 0x10},
+ {0x75, 0x80},
+ {0x76, 0x10},
+ {0x84, 0x00},
+ {0x85, 0x10},
+ {0x86, 0x10},
+ {0x87, 0x00},
+ {0x8a, 0x22},
+ {0x8b, 0x22},
+ {0x19, 0xf1},
+ {0x29, 0x01},
+ {0xfd, 0x01},
+ {0x9d, 0x16},
+ {0xa0, 0x29},
+ {0xa1, 0x03},
+ {0xad, 0x62},
+ {0xae, 0x00},
+ {0xaf, 0x85},
+ {0xb1, 0x01},
+ {0x8e, 0x06},
+ {0x8f, 0x40},
+ {0x90, 0x04},
+ {0x91, 0xb0},
+ {0x45, 0x01},
+ {0x46, 0x00},
+ {0x47, 0x6c},
+ {0x48, 0x03},
+ {0x49, 0x8b},
+ {0x4a, 0x00},
+ {0x4b, 0x07},
+ {0x4c, 0x04},
+ {0x4d, 0xb7},
+ {0xf0, 0x40},
+ {0xf1, 0x40},
+ {0xf2, 0x40},
+ {0xf3, 0x40},
+ {0x3f, 0x00},
+ {0xfd, 0x01},
+ {0x05, 0x00},
+ {0x06, 0xa6},
+ {0xfd, 0x01},
+};
+
+static const char * const ov02a10_test_pattern_menu[] = {
+ "Disabled",
+ "Color Bar",
+};
+
+static const s64 link_freq_menu_items[] = {
+ OV02A10_LINK_FREQ_390MHZ,
+};
+
+static u64 to_pixel_rate(u32 f_index)
+{
+ u64 pixel_rate = link_freq_menu_items[f_index] * 2 * OV02A10_DATA_LANES;
+
+ do_div(pixel_rate, OV02A10_BITS_PER_SAMPLE);
+
+ return pixel_rate;
+}
+
+static const struct ov02a10_mode supported_modes[] = {
+ {
+ .width = 1600,
+ .height = 1200,
+ .exp_def = 0x01ae,
+ .hts_def = 0x03a6,
+ .vts_def = 0x056e,
+ .reg_list = {
+ .num_of_regs = ARRAY_SIZE(ov02a10_1600x1200_regs),
+ .regs = ov02a10_1600x1200_regs,
+ },
+ },
+};
+
+static int ov02a10_write_array(struct ov02a10 *ov02a10,
+ const struct ov02a10_reg_list *r_list)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < r_list->num_of_regs; i++) {
+ ret = i2c_smbus_write_byte_data(client, r_list->regs[i].addr,
+ r_list->regs[i].val);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ov02a10_read_smbus(struct ov02a10 *ov02a10, unsigned char reg,
+ unsigned char *val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(client, reg);
+
+ if (ret < 0)
+ return ret;
+
+ *val = (unsigned char)ret;
+
+ return 0;
+}
+
+static int ov02a10_mod_reg(struct ov02a10 *ov02a10, u8 reg, u8 mask, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u8 readval;
+ int ret;
+
+ ret = ov02a10_read_smbus(ov02a10, reg, &readval);
+ if (ret)
+ return ret;
+
+ val = (readval & ~mask) | (val & mask);
+
+ return i2c_smbus_write_byte_data(client, reg, val);
+}
+
+static void ov02a10_fill_fmt(const struct ov02a10_mode *mode,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ fmt->width = mode->width;
+ fmt->height = mode->height;
+ fmt->field = V4L2_FIELD_NONE;
+}
+
+static int ov02a10_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
+
+ mutex_lock(&ov02a10->mutex);
+
+ if (ov02a10->streaming) {
+ mutex_unlock(&ov02a10->mutex);
+ return -EBUSY;
+ }
+
+ /* Only one sensor mode supported */
+ mbus_fmt->code = ov02a10->fmt.code;
+ ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
+ ov02a10->fmt = fmt->format;
+
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+}
+
+static int ov02a10_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
+
+ mutex_lock(&ov02a10->mutex);
+
+ fmt->format = ov02a10->fmt;
+ mbus_fmt->code = ov02a10->fmt.code;
+ ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
+
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+}
+
+static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ if (code->index >= ARRAY_SIZE(supported_modes))
+ return -EINVAL;
+
+ code->code = ov02a10->fmt.code;
+
+ return 0;
+}
+
+static int ov02a10_enum_frame_sizes(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ if (fse->index >= ARRAY_SIZE(supported_modes))
+ return -EINVAL;
+
+ fse->min_width = supported_modes[fse->index].width;
+ fse->max_width = supported_modes[fse->index].width;
+ fse->max_height = supported_modes[fse->index].height;
+ fse->min_height = supported_modes[fse->index].height;
+
+ return 0;
+}
+
+static int ov02a10_check_sensor_id(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u16 id;
+ u8 chip_id_h;
+ u8 chip_id_l;
+ int ret;
+
+ /* Check sensor revision */
+ ret = ov02a10_read_smbus(ov02a10, OV02A10_REG_CHIP_ID_H, &chip_id_h);
+ if (ret)
+ return ret;
+
+ ret = ov02a10_read_smbus(ov02a10, OV02A10_REG_CHIP_ID_L, &chip_id_l);
+ if (ret)
+ return ret;
+
+ id = OV02A10_ID(chip_id_h, chip_id_l);
+ if (id != CHIP_ID) {
+ dev_err(&client->dev, "Unexpected sensor id(%04x)\n", id);
+ return -EINVAL;
+ }
+
+ dev_dbg(&client->dev, "Detected OV%04X sensor\n", id);
+
+ return 0;
+}
+
+static int __maybe_unused ov02a10_power_on(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ int ret;
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
+
+ ret = clk_prepare_enable(ov02a10->eclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable eclk\n");
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable regulators\n");
+ goto disable_clk;
+ }
+ usleep_range(5000, 6000);
+
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 1);
+ usleep_range(5000, 6000);
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 1);
+ usleep_range(5000, 6000);
+
+ ret = ov02a10_check_sensor_id(ov02a10);
+ if (ret)
+ goto disable_regulator;
+
+ return 0;
+
+disable_regulator:
+ regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+disable_clk:
+ clk_disable_unprepare(ov02a10->eclk);
+
+ return ret;
+}
+
+static int __maybe_unused ov02a10_power_off(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
+ clk_disable_unprepare(ov02a10->eclk);
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
+ regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+
+ return 0;
+}
+
+static int __ov02a10_start_stream(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ const struct ov02a10_reg_list *reg_list;
+ int ret;
+
+ /* Apply default values of current mode */
+ reg_list = &ov02a10->cur_mode->reg_list;
+ ret = ov02a10_write_array(ov02a10, reg_list);
+ if (ret)
+ return ret;
+
+ /* Apply customized values from user */
+ ret = __v4l2_ctrl_handler_setup(ov02a10->subdev.ctrl_handler);
+ if (ret)
+ return ret;
+
+ /* Set orientation to 180 degree */
+ if (ov02a10->upside_down) {
+ ret = i2c_smbus_write_byte_data(client, REG_MIRROR_FLIP_CONTROL,
+ REG_MIRROR_FLIP_ENABLE);
+ if (ret) {
+ dev_err(&client->dev, "failed to set orientation\n");
+ return ret;
+ }
+ ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Set clock lane transmission mode according to DT property */
+ ret = ov02a10_mod_reg(ov02a10, REG_HS_MODE_BLC, CLOCK_HS_MODE_ENABLE,
+ ov02a10->mipi_clock_hs_mode_enable ?
+ CLOCK_HS_MODE_ENABLE : 0);
+ if (ret < 0)
+ return ret;
+
+ /* Set mipi TX speed according to DT property */
+ ret = i2c_smbus_write_byte_data(client, TX_SPEED_AREA_SEL,
+ ov02a10->mipi_clock_tx_speed);
+ if (ret < 0)
+ return ret;
+
+ /* Set stream on register */
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STREAMING);
+}
+
+static int __ov02a10_stop_stream(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STANDBY);
+}
+
+static int ov02a10_entity_init_cfg(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg)
+{
+ struct v4l2_subdev_format fmt = {
+ .which = cfg ? V4L2_SUBDEV_FORMAT_TRY
+ : V4L2_SUBDEV_FORMAT_ACTIVE,
+ .format = {
+ .width = 1600,
+ .height = 1200,
+ }
+ };
+
+ ov02a10_set_fmt(sd, cfg, &fmt);
+
+ return 0;
+}
+
+static int ov02a10_s_stream(struct v4l2_subdev *sd, int on)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ dev_dbg(&client->dev, "ov02a10 s_stream (%d)\n", on);
+ mutex_lock(&ov02a10->mutex);
+
+ if (ov02a10->streaming == on)
+ goto unlock_and_return;
+
+ if (on) {
+ ret = pm_runtime_get_sync(&client->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&client->dev);
+ goto unlock_and_return;
+ }
+
+ ret = __ov02a10_start_stream(ov02a10);
+ if (ret) {
+ __ov02a10_stop_stream(ov02a10);
+ ov02a10->streaming = !on;
+ goto err_rpm_put;
+ }
+ } else {
+ __ov02a10_stop_stream(ov02a10);
+ pm_runtime_put(&client->dev);
+ }
+
+ ov02a10->streaming = on;
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+
+err_rpm_put:
+ pm_runtime_put(&client->dev);
+unlock_and_return:
+ mutex_unlock(&ov02a10->mutex);
+
+ return ret;
+}
+
+static const struct dev_pm_ops ov02a10_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(ov02a10_power_off, ov02a10_power_on, NULL)
+};
+
+/*
+ * ov02a10_set_exposure - Function called when setting exposure time
+ * @priv: Pointer to device structure
+ * @val: Variable for exposure time, in the unit of micro-second
+ *
+ * Set exposure time based on input value.
+ *
+ * Return: 0 on success
+ */
+static int ov02a10_set_exposure(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_H,
+ val >> OV02A10_EXP_SHIFT);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_L, val);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_gain(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_GAIN, val);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_vblank(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u32 vts = val + ov02a10->cur_mode->height - OV02A10_BASIC_LINE;
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_H,
+ vts >> OV02A10_VTS_SHIFT);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_L, vts);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ if (pattern)
+ pattern = OV02A10_TEST_PATTERN_ENABLE;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_TEST_PATTERN,
+ pattern);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STREAMING);
+}
+
+static int ov02a10_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ov02a10 *ov02a10 = container_of(ctrl->handler,
+ struct ov02a10, ctrl_handler);
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ s64 max_expo;
+ int ret;
+
+ /* Propagate change of current control to all related controls */
+ if (ctrl->id == V4L2_CID_VBLANK) {
+ /* Update max exposure while meeting expected vblanking */
+ max_expo = ov02a10->cur_mode->height + ctrl->val -
+ OV02A10_EXPOSURE_MAX_MARGIN;
+ __v4l2_ctrl_modify_range(ov02a10->exposure,
+ ov02a10->exposure->minimum, max_expo,
+ ov02a10->exposure->step,
+ ov02a10->exposure->default_value);
+ }
+
+ /* V4L2 controls values will be applied only when power is already up */
+ if (!pm_runtime_get_if_in_use(&client->dev))
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_EXPOSURE:
+ ret = ov02a10_set_exposure(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_ANALOGUE_GAIN:
+ ret = ov02a10_set_gain(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_VBLANK:
+ ret = ov02a10_set_vblank(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_TEST_PATTERN:
+ ret = ov02a10_set_test_pattern(ov02a10, ctrl->val);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ };
+
+ pm_runtime_put(&client->dev);
+
+ return ret;
+}
+
+static const struct v4l2_subdev_video_ops ov02a10_video_ops = {
+ .s_stream = ov02a10_s_stream,
+};
+
+static const struct v4l2_subdev_pad_ops ov02a10_pad_ops = {
+ .init_cfg = ov02a10_entity_init_cfg,
+ .enum_mbus_code = ov02a10_enum_mbus_code,
+ .enum_frame_size = ov02a10_enum_frame_sizes,
+ .get_fmt = ov02a10_get_fmt,
+ .set_fmt = ov02a10_set_fmt,
+};
+
+static const struct v4l2_subdev_ops ov02a10_subdev_ops = {
+ .video = &ov02a10_video_ops,
+ .pad = &ov02a10_pad_ops,
+};
+
+static const struct media_entity_operations ov02a10_subdev_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static const struct v4l2_ctrl_ops ov02a10_ctrl_ops = {
+ .s_ctrl = ov02a10_set_ctrl,
+};
+
+static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ const struct ov02a10_mode *mode;
+ struct v4l2_ctrl_handler *handler;
+ struct v4l2_ctrl *ctrl;
+ u64 exposure_max;
+ u32 pixel_rate, h_blank;
+ int ret;
+
+ handler = &ov02a10->ctrl_handler;
+ mode = ov02a10->cur_mode;
+ ret = v4l2_ctrl_handler_init(handler, 7);
+ if (ret)
+ return ret;
+
+ handler->lock = &ov02a10->mutex;
+
+ ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
+ link_freq_menu_items);
+ if (ctrl)
+ ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ pixel_rate = to_pixel_rate(0);
+ v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
+ pixel_rate);
+
+ h_blank = mode->hts_def - mode->width;
+ ov02a10->hblank = v4l2_ctrl_new_std(handler, NULL, V4L2_CID_HBLANK,
+ h_blank, h_blank, 1, h_blank);
+ if (ov02a10->hblank)
+ ov02a10->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ ov02a10->vblank = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_VBLANK, mode->vts_def -
+ mode->height,
+ OV02A10_VTS_MAX - mode->height, 1,
+ mode->vts_def - mode->height);
+
+ exposure_max = mode->vts_def - 4;
+ ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_EXPOSURE,
+ OV02A10_EXPOSURE_MIN,
+ exposure_max,
+ OV02A10_EXPOSURE_STEP,
+ mode->exp_def);
+
+ ov02a10->anal_gain = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_ANALOGUE_GAIN,
+ OV02A10_GAIN_MIN,
+ OV02A10_GAIN_MAX,
+ OV02A10_GAIN_STEP,
+ OV02A10_GAIN_DEFAULT);
+
+ ov02a10->test_pattern =
+ v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(ov02a10_test_pattern_menu) -
+ 1, 0, 0,
+ ov02a10_test_pattern_menu);
+
+ if (handler->error) {
+ ret = handler->error;
+ dev_err(&client->dev, "failed to init controls(%d)\n", ret);
+ goto err_free_handler;
+ }
+
+ ov02a10->subdev.ctrl_handler = handler;
+
+ return 0;
+
+err_free_handler:
+ v4l2_ctrl_handler_free(handler);
+
+ return ret;
+}
+
+static int ov02a10_check_hwcfg(struct device *dev, struct ov02a10 *ov02a10)
+{
+ struct fwnode_handle *ep;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
+ struct v4l2_fwnode_endpoint bus_cfg = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY,
+ };
+ unsigned int i, j;
+ int ret;
+
+ if (!fwnode)
+ return -EINVAL;
+
+ ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
+ if (!ep)
+ return -ENXIO;
+
+ ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+ fwnode_handle_put(ep);
+ if (ret)
+ return ret;
+
+ /* Optional indication of mipi clock lane mode */
+ if (bus_cfg.bus.mipi_csi2.flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK)
+ ov02a10->mipi_clock_hs_mode_enable = true;
+
+ if (!bus_cfg.nr_of_link_frequencies) {
+ dev_err(dev, "no link frequencies defined");
+ ret = -EINVAL;
+ goto check_hwcfg_error;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(link_freq_menu_items); i++) {
+ for (j = 0; j < bus_cfg.nr_of_link_frequencies; j++) {
+ if (link_freq_menu_items[i] ==
+ bus_cfg.link_frequencies[j])
+ break;
+ }
+
+ if (j == bus_cfg.nr_of_link_frequencies) {
+ dev_err(dev, "no link frequency %lld supported",
+ link_freq_menu_items[i]);
+ ret = -EINVAL;
+ goto check_hwcfg_error;
+ }
+ }
+
+check_hwcfg_error:
+ v4l2_fwnode_endpoint_free(&bus_cfg);
+
+ return ret;
+}
+
+static int ov02a10_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct ov02a10 *ov02a10;
+ unsigned int rotation;
+ unsigned int clock_lane_tx_speed;
+ unsigned int i;
+ int ret;
+
+ ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
+ if (!ov02a10)
+ return -ENOMEM;
+
+ ret = ov02a10_check_hwcfg(dev, ov02a10);
+ if (ret) {
+ dev_err(dev, "failed to check HW configuration: %d", ret);
+ return ret;
+ }
+
+ v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
+ ov02a10->upside_down = false;
+ ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
+
+ /* Optional indication of physical rotation of sensor */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation", &rotation);
+ if (!ret) {
+ ov02a10->upside_down = rotation == 180;
+
+ if (rotation == 180) {
+ ov02a10->upside_down = true;
+ ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
+ }
+ }
+
+ /* Optional indication of mipi TX speed */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "ovti,mipi-tx-speed",
+ &clock_lane_tx_speed);
+
+ if (!ret)
+ ov02a10->mipi_clock_tx_speed = clock_lane_tx_speed;
+
+ /* Get system clock (eclk) */
+ ov02a10->eclk = devm_clk_get(dev, "eclk");
+ if (IS_ERR(ov02a10->eclk)) {
+ ret = PTR_ERR(ov02a10->eclk);
+ dev_err(dev, "failed to get eclk %d\n", ret);
+ return ret;
+ }
+
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
+ &ov02a10->eclk_freq);
+ if (ret) {
+ dev_err(dev, "failed to get eclk frequency\n");
+ return ret;
+ }
+
+ ret = clk_set_rate(ov02a10->eclk, ov02a10->eclk_freq);
+ if (ret) {
+ dev_err(dev, "failed to set eclk frequency (24MHz)\n");
+ return ret;
+ }
+
+ if (clk_get_rate(ov02a10->eclk) != OV02A10_ECLK_FREQ) {
+ dev_warn(dev, "wrong eclk frequency %d Hz, expected: %d Hz\n",
+ ov02a10->eclk_freq, OV02A10_ECLK_FREQ);
+ return -EINVAL;
+ }
+
+ ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
+ if (IS_ERR(ov02a10->pd_gpio)) {
+ ret = PTR_ERR(ov02a10->pd_gpio);
+ dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
+ return ret;
+ }
+
+ ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ov02a10->n_rst_gpio)) {
+ ret = PTR_ERR(ov02a10->n_rst_gpio);
+ dev_err(dev, "failed to get reset-gpios %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < OV02A10_NUM_SUPPLIES; i++)
+ ov02a10->supplies[i].supply = ov02a10_supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, OV02A10_NUM_SUPPLIES,
+ ov02a10->supplies);
+ if (ret) {
+ dev_err(dev, "failed to get regulators\n");
+ return ret;
+ }
+
+ mutex_init(&ov02a10->mutex);
+ ov02a10->cur_mode = &supported_modes[0];
+ ret = ov02a10_initialize_controls(ov02a10);
+ if (ret) {
+ dev_err(dev, "failed to initialize controls\n");
+ goto err_destroy_mutex;
+ }
+
+ ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
+ ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+ ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
+ if (ret < 0) {
+ dev_err(dev, "failed to init entity pads: %d", ret);
+ goto err_free_handler;
+ }
+
+ ret = v4l2_async_register_subdev(&ov02a10->subdev);
+ if (ret) {
+ dev_err(dev, "failed to register V4L2 subdev: %d", ret);
+ goto err_clean_entity;
+ }
+
+ pm_runtime_enable(dev);
+ if (!pm_runtime_enabled(dev)) {
+ ret = ov02a10_power_on(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to power on: %d\n", ret);
+ goto err_clean_entity;
+ }
+ }
+
+ return 0;
+
+err_clean_entity:
+ media_entity_cleanup(&ov02a10->subdev.entity);
+err_free_handler:
+ v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
+err_destroy_mutex:
+ mutex_destroy(&ov02a10->mutex);
+
+ return ret;
+}
+
+static int ov02a10_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
+ pm_runtime_disable(&client->dev);
+ if (!pm_runtime_status_suspended(&client->dev))
+ ov02a10_power_off(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+ mutex_destroy(&ov02a10->mutex);
+
+ return 0;
+}
+
+static const struct of_device_id ov02a10_of_match[] = {
+ { .compatible = "ovti,ov02a10" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ov02a10_of_match);
+
+static struct i2c_driver ov02a10_i2c_driver = {
+ .driver = {
+ .name = "ov02a10",
+ .pm = &ov02a10_pm_ops,
+ .of_match_table = ov02a10_of_match,
+ },
+ .probe_new = &ov02a10_probe,
+ .remove = &ov02a10_remove,
+};
+
+module_i2c_driver(ov02a10_i2c_driver);
+
+MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
+MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
+MODULE_LICENSE("GPL v2");
+
--
2.9.2
^ permalink raw reply related [flat|nested] 57+ messages in thread
* [V7, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Add a V4L2 sub-device driver for OV02A10 image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
MAINTAINERS | 1 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov02a10.c | 1090 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 1103 insertions(+)
create mode 100644 drivers/media/i2c/ov02a10.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 63a2335..e7677c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12395,6 +12395,7 @@ L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+F: drivers/media/i2c/ov02a10.c
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596..fff92c3 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -655,6 +655,17 @@ config VIDEO_IMX355
To compile this driver as a module, choose M here: the
module will be called imx355.
+config VIDEO_OV02A10
+ tristate "OmniVision OV02A10 sensor support"
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+ help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV02A10 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov02a10.
+
config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 77bf7d0..6566dd9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV02A10) += ov02a10.o
obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
new file mode 100644
index 0000000..6a30cf3
--- /dev/null
+++ b/drivers/media/i2c/ov02a10.c
@@ -0,0 +1,1090 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 MediaTek Inc.
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <media/media-entity.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-fwnode.h>
+
+#define CHIP_ID 0x2509
+#define OV02A10_REG_CHIP_ID_H 0x02
+#define OV02A10_REG_CHIP_ID_L 0x03
+#define OV02A10_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
+
+/* Bit[1] vertical upside down */
+/* Bit[0] horizontal mirror */
+#define REG_MIRROR_FLIP_CONTROL 0x3f
+
+/* Orientation */
+#define REG_MIRROR_FLIP_ENABLE 0x03
+
+/* Bit[7] clock HS mode enable
+ * 0: Clock continue
+ * 1: Clock HS
+ * Bit[6:2] HS VOD adjust
+ * Bit[1:0] P VHI adjust
+ */
+#define REG_HS_MODE_BLC 0x9d
+
+#define CLOCK_HS_MODE_ENABLE BIT(7)
+
+/* Bit[2:0] MIPI transmission speed select */
+#define TX_SPEED_AREA_SEL 0xa1
+
+#define REG_PAGE_SWITCH 0xfd
+#define REG_GLOBAL_EFFECTIVE 0x01
+#define REG_ENABLE BIT(0)
+
+#define REG_SC_CTRL_MODE 0xac
+#define SC_CTRL_MODE_STANDBY 0x00
+#define SC_CTRL_MODE_STREAMING 0x01
+
+#define OV02A10_EXP_SHIFT 8
+#define OV02A10_REG_EXPOSURE_H 0x03
+#define OV02A10_REG_EXPOSURE_L 0x04
+#define OV02A10_EXPOSURE_MIN 4
+#define OV02A10_EXPOSURE_MAX_MARGIN 4
+#define OV02A10_EXPOSURE_STEP 1
+
+#define OV02A10_VTS_SHIFT 8
+#define OV02A10_REG_VTS_H 0x05
+#define OV02A10_REG_VTS_L 0x06
+#define OV02A10_VTS_MAX 0x209f
+#define OV02A10_VTS_MIN 0x04cf
+#define OV02A10_BASIC_LINE 1224
+
+#define OV02A10_REG_GAIN 0x24
+#define OV02A10_GAIN_MIN 0x10
+#define OV02A10_GAIN_MAX 0xf8
+#define OV02A10_GAIN_STEP 0x01
+#define OV02A10_GAIN_DEFAULT 0x40
+
+/* Test pattern control */
+#define OV02A10_REG_TEST_PATTERN 0xb6
+#define OV02A10_TEST_PATTERN_ENABLE BIT(0)
+
+#define HZ_PER_MHZ 1000000L
+#define OV02A10_LINK_FREQ_390MHZ (390 * HZ_PER_MHZ)
+#define OV02A10_ECLK_FREQ (24 * HZ_PER_MHZ)
+#define OV02A10_DATA_LANES 1
+#define OV02A10_BITS_PER_SAMPLE 10
+
+static const char * const ov02a10_supply_names[] = {
+ "dovdd", /* Digital I/O power */
+ "avdd", /* Analog power */
+ "dvdd", /* Digital core power */
+};
+
+#define OV02A10_NUM_SUPPLIES ARRAY_SIZE(ov02a10_supply_names)
+
+struct ov02a10_reg {
+ u8 addr;
+ u8 val;
+};
+
+struct ov02a10_reg_list {
+ u32 num_of_regs;
+ const struct ov02a10_reg *regs;
+};
+
+struct ov02a10_mode {
+ u32 width;
+ u32 height;
+ u32 exp_def;
+ u32 hts_def;
+ u32 vts_def;
+ const struct ov02a10_reg_list reg_list;
+};
+
+struct ov02a10 {
+ u32 eclk_freq;
+ u32 mipi_clock_tx_speed;
+
+ struct clk *eclk;
+ struct gpio_desc *pd_gpio;
+ struct gpio_desc *n_rst_gpio;
+ struct regulator_bulk_data supplies[OV02A10_NUM_SUPPLIES];
+
+ bool streaming;
+ bool upside_down;
+ bool mipi_clock_hs_mode_enable;
+
+ /*
+ * Serialize control access, get/set format, get selection
+ * and start streaming.
+ */
+ struct mutex mutex;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_ctrl *anal_gain;
+ struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vblank;
+ struct v4l2_ctrl *test_pattern;
+ struct v4l2_mbus_framefmt fmt;
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov02a10_mode *cur_mode;
+};
+
+static inline struct ov02a10 *to_ov02a10(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov02a10, subdev);
+}
+
+/*
+ * eclk 24Mhz
+ * pclk 39Mhz
+ * linelength 934(0x3a6)
+ * framelength 1390(0x56E)
+ * grabwindow_width 1600
+ * grabwindow_height 1200
+ * max_framerate 30fps
+ * mipi_datarate per lane 780Mbps
+ */
+static const struct ov02a10_reg ov02a10_1600x1200_regs[] = {
+ {0xfd, 0x01},
+ {0xac, 0x00},
+ {0xfd, 0x00},
+ {0x2f, 0x29},
+ {0x34, 0x00},
+ {0x35, 0x21},
+ {0x30, 0x15},
+ {0x33, 0x01},
+ {0xfd, 0x01},
+ {0x44, 0x00},
+ {0x2a, 0x4c},
+ {0x2b, 0x1e},
+ {0x2c, 0x60},
+ {0x25, 0x11},
+ {0x03, 0x01},
+ {0x04, 0xae},
+ {0x09, 0x00},
+ {0x0a, 0x02},
+ {0x06, 0xa6},
+ {0x31, 0x00},
+ {0x24, 0x40},
+ {0x01, 0x01},
+ {0xfb, 0x73},
+ {0xfd, 0x01},
+ {0x16, 0x04},
+ {0x1c, 0x09},
+ {0x21, 0x42},
+ {0x12, 0x04},
+ {0x13, 0x10},
+ {0x11, 0x40},
+ {0x33, 0x81},
+ {0xd0, 0x00},
+ {0xd1, 0x01},
+ {0xd2, 0x00},
+ {0x50, 0x10},
+ {0x51, 0x23},
+ {0x52, 0x20},
+ {0x53, 0x10},
+ {0x54, 0x02},
+ {0x55, 0x20},
+ {0x56, 0x02},
+ {0x58, 0x48},
+ {0x5d, 0x15},
+ {0x5e, 0x05},
+ {0x66, 0x66},
+ {0x68, 0x68},
+ {0x6b, 0x00},
+ {0x6c, 0x00},
+ {0x6f, 0x40},
+ {0x70, 0x40},
+ {0x71, 0x0a},
+ {0x72, 0xf0},
+ {0x73, 0x10},
+ {0x75, 0x80},
+ {0x76, 0x10},
+ {0x84, 0x00},
+ {0x85, 0x10},
+ {0x86, 0x10},
+ {0x87, 0x00},
+ {0x8a, 0x22},
+ {0x8b, 0x22},
+ {0x19, 0xf1},
+ {0x29, 0x01},
+ {0xfd, 0x01},
+ {0x9d, 0x16},
+ {0xa0, 0x29},
+ {0xa1, 0x03},
+ {0xad, 0x62},
+ {0xae, 0x00},
+ {0xaf, 0x85},
+ {0xb1, 0x01},
+ {0x8e, 0x06},
+ {0x8f, 0x40},
+ {0x90, 0x04},
+ {0x91, 0xb0},
+ {0x45, 0x01},
+ {0x46, 0x00},
+ {0x47, 0x6c},
+ {0x48, 0x03},
+ {0x49, 0x8b},
+ {0x4a, 0x00},
+ {0x4b, 0x07},
+ {0x4c, 0x04},
+ {0x4d, 0xb7},
+ {0xf0, 0x40},
+ {0xf1, 0x40},
+ {0xf2, 0x40},
+ {0xf3, 0x40},
+ {0x3f, 0x00},
+ {0xfd, 0x01},
+ {0x05, 0x00},
+ {0x06, 0xa6},
+ {0xfd, 0x01},
+};
+
+static const char * const ov02a10_test_pattern_menu[] = {
+ "Disabled",
+ "Color Bar",
+};
+
+static const s64 link_freq_menu_items[] = {
+ OV02A10_LINK_FREQ_390MHZ,
+};
+
+static u64 to_pixel_rate(u32 f_index)
+{
+ u64 pixel_rate = link_freq_menu_items[f_index] * 2 * OV02A10_DATA_LANES;
+
+ do_div(pixel_rate, OV02A10_BITS_PER_SAMPLE);
+
+ return pixel_rate;
+}
+
+static const struct ov02a10_mode supported_modes[] = {
+ {
+ .width = 1600,
+ .height = 1200,
+ .exp_def = 0x01ae,
+ .hts_def = 0x03a6,
+ .vts_def = 0x056e,
+ .reg_list = {
+ .num_of_regs = ARRAY_SIZE(ov02a10_1600x1200_regs),
+ .regs = ov02a10_1600x1200_regs,
+ },
+ },
+};
+
+static int ov02a10_write_array(struct ov02a10 *ov02a10,
+ const struct ov02a10_reg_list *r_list)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < r_list->num_of_regs; i++) {
+ ret = i2c_smbus_write_byte_data(client, r_list->regs[i].addr,
+ r_list->regs[i].val);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ov02a10_read_smbus(struct ov02a10 *ov02a10, unsigned char reg,
+ unsigned char *val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(client, reg);
+
+ if (ret < 0)
+ return ret;
+
+ *val = (unsigned char)ret;
+
+ return 0;
+}
+
+static int ov02a10_mod_reg(struct ov02a10 *ov02a10, u8 reg, u8 mask, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u8 readval;
+ int ret;
+
+ ret = ov02a10_read_smbus(ov02a10, reg, &readval);
+ if (ret)
+ return ret;
+
+ val = (readval & ~mask) | (val & mask);
+
+ return i2c_smbus_write_byte_data(client, reg, val);
+}
+
+static void ov02a10_fill_fmt(const struct ov02a10_mode *mode,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ fmt->width = mode->width;
+ fmt->height = mode->height;
+ fmt->field = V4L2_FIELD_NONE;
+}
+
+static int ov02a10_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
+
+ mutex_lock(&ov02a10->mutex);
+
+ if (ov02a10->streaming) {
+ mutex_unlock(&ov02a10->mutex);
+ return -EBUSY;
+ }
+
+ /* Only one sensor mode supported */
+ mbus_fmt->code = ov02a10->fmt.code;
+ ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
+ ov02a10->fmt = fmt->format;
+
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+}
+
+static int ov02a10_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
+
+ mutex_lock(&ov02a10->mutex);
+
+ fmt->format = ov02a10->fmt;
+ mbus_fmt->code = ov02a10->fmt.code;
+ ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
+
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+}
+
+static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ if (code->index >= ARRAY_SIZE(supported_modes))
+ return -EINVAL;
+
+ code->code = ov02a10->fmt.code;
+
+ return 0;
+}
+
+static int ov02a10_enum_frame_sizes(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ if (fse->index >= ARRAY_SIZE(supported_modes))
+ return -EINVAL;
+
+ fse->min_width = supported_modes[fse->index].width;
+ fse->max_width = supported_modes[fse->index].width;
+ fse->max_height = supported_modes[fse->index].height;
+ fse->min_height = supported_modes[fse->index].height;
+
+ return 0;
+}
+
+static int ov02a10_check_sensor_id(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u16 id;
+ u8 chip_id_h;
+ u8 chip_id_l;
+ int ret;
+
+ /* Check sensor revision */
+ ret = ov02a10_read_smbus(ov02a10, OV02A10_REG_CHIP_ID_H, &chip_id_h);
+ if (ret)
+ return ret;
+
+ ret = ov02a10_read_smbus(ov02a10, OV02A10_REG_CHIP_ID_L, &chip_id_l);
+ if (ret)
+ return ret;
+
+ id = OV02A10_ID(chip_id_h, chip_id_l);
+ if (id != CHIP_ID) {
+ dev_err(&client->dev, "Unexpected sensor id(%04x)\n", id);
+ return -EINVAL;
+ }
+
+ dev_dbg(&client->dev, "Detected OV%04X sensor\n", id);
+
+ return 0;
+}
+
+static int __maybe_unused ov02a10_power_on(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ int ret;
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
+
+ ret = clk_prepare_enable(ov02a10->eclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable eclk\n");
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable regulators\n");
+ goto disable_clk;
+ }
+ usleep_range(5000, 6000);
+
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 1);
+ usleep_range(5000, 6000);
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 1);
+ usleep_range(5000, 6000);
+
+ ret = ov02a10_check_sensor_id(ov02a10);
+ if (ret)
+ goto disable_regulator;
+
+ return 0;
+
+disable_regulator:
+ regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+disable_clk:
+ clk_disable_unprepare(ov02a10->eclk);
+
+ return ret;
+}
+
+static int __maybe_unused ov02a10_power_off(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
+ clk_disable_unprepare(ov02a10->eclk);
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
+ regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+
+ return 0;
+}
+
+static int __ov02a10_start_stream(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ const struct ov02a10_reg_list *reg_list;
+ int ret;
+
+ /* Apply default values of current mode */
+ reg_list = &ov02a10->cur_mode->reg_list;
+ ret = ov02a10_write_array(ov02a10, reg_list);
+ if (ret)
+ return ret;
+
+ /* Apply customized values from user */
+ ret = __v4l2_ctrl_handler_setup(ov02a10->subdev.ctrl_handler);
+ if (ret)
+ return ret;
+
+ /* Set orientation to 180 degree */
+ if (ov02a10->upside_down) {
+ ret = i2c_smbus_write_byte_data(client, REG_MIRROR_FLIP_CONTROL,
+ REG_MIRROR_FLIP_ENABLE);
+ if (ret) {
+ dev_err(&client->dev, "failed to set orientation\n");
+ return ret;
+ }
+ ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Set clock lane transmission mode according to DT property */
+ ret = ov02a10_mod_reg(ov02a10, REG_HS_MODE_BLC, CLOCK_HS_MODE_ENABLE,
+ ov02a10->mipi_clock_hs_mode_enable ?
+ CLOCK_HS_MODE_ENABLE : 0);
+ if (ret < 0)
+ return ret;
+
+ /* Set mipi TX speed according to DT property */
+ ret = i2c_smbus_write_byte_data(client, TX_SPEED_AREA_SEL,
+ ov02a10->mipi_clock_tx_speed);
+ if (ret < 0)
+ return ret;
+
+ /* Set stream on register */
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STREAMING);
+}
+
+static int __ov02a10_stop_stream(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STANDBY);
+}
+
+static int ov02a10_entity_init_cfg(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg)
+{
+ struct v4l2_subdev_format fmt = {
+ .which = cfg ? V4L2_SUBDEV_FORMAT_TRY
+ : V4L2_SUBDEV_FORMAT_ACTIVE,
+ .format = {
+ .width = 1600,
+ .height = 1200,
+ }
+ };
+
+ ov02a10_set_fmt(sd, cfg, &fmt);
+
+ return 0;
+}
+
+static int ov02a10_s_stream(struct v4l2_subdev *sd, int on)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ dev_dbg(&client->dev, "ov02a10 s_stream (%d)\n", on);
+ mutex_lock(&ov02a10->mutex);
+
+ if (ov02a10->streaming == on)
+ goto unlock_and_return;
+
+ if (on) {
+ ret = pm_runtime_get_sync(&client->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&client->dev);
+ goto unlock_and_return;
+ }
+
+ ret = __ov02a10_start_stream(ov02a10);
+ if (ret) {
+ __ov02a10_stop_stream(ov02a10);
+ ov02a10->streaming = !on;
+ goto err_rpm_put;
+ }
+ } else {
+ __ov02a10_stop_stream(ov02a10);
+ pm_runtime_put(&client->dev);
+ }
+
+ ov02a10->streaming = on;
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+
+err_rpm_put:
+ pm_runtime_put(&client->dev);
+unlock_and_return:
+ mutex_unlock(&ov02a10->mutex);
+
+ return ret;
+}
+
+static const struct dev_pm_ops ov02a10_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(ov02a10_power_off, ov02a10_power_on, NULL)
+};
+
+/*
+ * ov02a10_set_exposure - Function called when setting exposure time
+ * @priv: Pointer to device structure
+ * @val: Variable for exposure time, in the unit of micro-second
+ *
+ * Set exposure time based on input value.
+ *
+ * Return: 0 on success
+ */
+static int ov02a10_set_exposure(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_H,
+ val >> OV02A10_EXP_SHIFT);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_L, val);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_gain(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_GAIN, val);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_vblank(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u32 vts = val + ov02a10->cur_mode->height - OV02A10_BASIC_LINE;
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_H,
+ vts >> OV02A10_VTS_SHIFT);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_L, vts);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ if (pattern)
+ pattern = OV02A10_TEST_PATTERN_ENABLE;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_TEST_PATTERN,
+ pattern);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STREAMING);
+}
+
+static int ov02a10_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ov02a10 *ov02a10 = container_of(ctrl->handler,
+ struct ov02a10, ctrl_handler);
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ s64 max_expo;
+ int ret;
+
+ /* Propagate change of current control to all related controls */
+ if (ctrl->id == V4L2_CID_VBLANK) {
+ /* Update max exposure while meeting expected vblanking */
+ max_expo = ov02a10->cur_mode->height + ctrl->val -
+ OV02A10_EXPOSURE_MAX_MARGIN;
+ __v4l2_ctrl_modify_range(ov02a10->exposure,
+ ov02a10->exposure->minimum, max_expo,
+ ov02a10->exposure->step,
+ ov02a10->exposure->default_value);
+ }
+
+ /* V4L2 controls values will be applied only when power is already up */
+ if (!pm_runtime_get_if_in_use(&client->dev))
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_EXPOSURE:
+ ret = ov02a10_set_exposure(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_ANALOGUE_GAIN:
+ ret = ov02a10_set_gain(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_VBLANK:
+ ret = ov02a10_set_vblank(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_TEST_PATTERN:
+ ret = ov02a10_set_test_pattern(ov02a10, ctrl->val);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ };
+
+ pm_runtime_put(&client->dev);
+
+ return ret;
+}
+
+static const struct v4l2_subdev_video_ops ov02a10_video_ops = {
+ .s_stream = ov02a10_s_stream,
+};
+
+static const struct v4l2_subdev_pad_ops ov02a10_pad_ops = {
+ .init_cfg = ov02a10_entity_init_cfg,
+ .enum_mbus_code = ov02a10_enum_mbus_code,
+ .enum_frame_size = ov02a10_enum_frame_sizes,
+ .get_fmt = ov02a10_get_fmt,
+ .set_fmt = ov02a10_set_fmt,
+};
+
+static const struct v4l2_subdev_ops ov02a10_subdev_ops = {
+ .video = &ov02a10_video_ops,
+ .pad = &ov02a10_pad_ops,
+};
+
+static const struct media_entity_operations ov02a10_subdev_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static const struct v4l2_ctrl_ops ov02a10_ctrl_ops = {
+ .s_ctrl = ov02a10_set_ctrl,
+};
+
+static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ const struct ov02a10_mode *mode;
+ struct v4l2_ctrl_handler *handler;
+ struct v4l2_ctrl *ctrl;
+ u64 exposure_max;
+ u32 pixel_rate, h_blank;
+ int ret;
+
+ handler = &ov02a10->ctrl_handler;
+ mode = ov02a10->cur_mode;
+ ret = v4l2_ctrl_handler_init(handler, 7);
+ if (ret)
+ return ret;
+
+ handler->lock = &ov02a10->mutex;
+
+ ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
+ link_freq_menu_items);
+ if (ctrl)
+ ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ pixel_rate = to_pixel_rate(0);
+ v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
+ pixel_rate);
+
+ h_blank = mode->hts_def - mode->width;
+ ov02a10->hblank = v4l2_ctrl_new_std(handler, NULL, V4L2_CID_HBLANK,
+ h_blank, h_blank, 1, h_blank);
+ if (ov02a10->hblank)
+ ov02a10->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ ov02a10->vblank = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_VBLANK, mode->vts_def -
+ mode->height,
+ OV02A10_VTS_MAX - mode->height, 1,
+ mode->vts_def - mode->height);
+
+ exposure_max = mode->vts_def - 4;
+ ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_EXPOSURE,
+ OV02A10_EXPOSURE_MIN,
+ exposure_max,
+ OV02A10_EXPOSURE_STEP,
+ mode->exp_def);
+
+ ov02a10->anal_gain = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_ANALOGUE_GAIN,
+ OV02A10_GAIN_MIN,
+ OV02A10_GAIN_MAX,
+ OV02A10_GAIN_STEP,
+ OV02A10_GAIN_DEFAULT);
+
+ ov02a10->test_pattern =
+ v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(ov02a10_test_pattern_menu) -
+ 1, 0, 0,
+ ov02a10_test_pattern_menu);
+
+ if (handler->error) {
+ ret = handler->error;
+ dev_err(&client->dev, "failed to init controls(%d)\n", ret);
+ goto err_free_handler;
+ }
+
+ ov02a10->subdev.ctrl_handler = handler;
+
+ return 0;
+
+err_free_handler:
+ v4l2_ctrl_handler_free(handler);
+
+ return ret;
+}
+
+static int ov02a10_check_hwcfg(struct device *dev, struct ov02a10 *ov02a10)
+{
+ struct fwnode_handle *ep;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
+ struct v4l2_fwnode_endpoint bus_cfg = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY,
+ };
+ unsigned int i, j;
+ int ret;
+
+ if (!fwnode)
+ return -EINVAL;
+
+ ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
+ if (!ep)
+ return -ENXIO;
+
+ ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+ fwnode_handle_put(ep);
+ if (ret)
+ return ret;
+
+ /* Optional indication of mipi clock lane mode */
+ if (bus_cfg.bus.mipi_csi2.flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK)
+ ov02a10->mipi_clock_hs_mode_enable = true;
+
+ if (!bus_cfg.nr_of_link_frequencies) {
+ dev_err(dev, "no link frequencies defined");
+ ret = -EINVAL;
+ goto check_hwcfg_error;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(link_freq_menu_items); i++) {
+ for (j = 0; j < bus_cfg.nr_of_link_frequencies; j++) {
+ if (link_freq_menu_items[i] ==
+ bus_cfg.link_frequencies[j])
+ break;
+ }
+
+ if (j == bus_cfg.nr_of_link_frequencies) {
+ dev_err(dev, "no link frequency %lld supported",
+ link_freq_menu_items[i]);
+ ret = -EINVAL;
+ goto check_hwcfg_error;
+ }
+ }
+
+check_hwcfg_error:
+ v4l2_fwnode_endpoint_free(&bus_cfg);
+
+ return ret;
+}
+
+static int ov02a10_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct ov02a10 *ov02a10;
+ unsigned int rotation;
+ unsigned int clock_lane_tx_speed;
+ unsigned int i;
+ int ret;
+
+ ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
+ if (!ov02a10)
+ return -ENOMEM;
+
+ ret = ov02a10_check_hwcfg(dev, ov02a10);
+ if (ret) {
+ dev_err(dev, "failed to check HW configuration: %d", ret);
+ return ret;
+ }
+
+ v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
+ ov02a10->upside_down = false;
+ ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
+
+ /* Optional indication of physical rotation of sensor */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation", &rotation);
+ if (!ret) {
+ ov02a10->upside_down = rotation == 180;
+
+ if (rotation == 180) {
+ ov02a10->upside_down = true;
+ ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
+ }
+ }
+
+ /* Optional indication of mipi TX speed */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "ovti,mipi-tx-speed",
+ &clock_lane_tx_speed);
+
+ if (!ret)
+ ov02a10->mipi_clock_tx_speed = clock_lane_tx_speed;
+
+ /* Get system clock (eclk) */
+ ov02a10->eclk = devm_clk_get(dev, "eclk");
+ if (IS_ERR(ov02a10->eclk)) {
+ ret = PTR_ERR(ov02a10->eclk);
+ dev_err(dev, "failed to get eclk %d\n", ret);
+ return ret;
+ }
+
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
+ &ov02a10->eclk_freq);
+ if (ret) {
+ dev_err(dev, "failed to get eclk frequency\n");
+ return ret;
+ }
+
+ ret = clk_set_rate(ov02a10->eclk, ov02a10->eclk_freq);
+ if (ret) {
+ dev_err(dev, "failed to set eclk frequency (24MHz)\n");
+ return ret;
+ }
+
+ if (clk_get_rate(ov02a10->eclk) != OV02A10_ECLK_FREQ) {
+ dev_warn(dev, "wrong eclk frequency %d Hz, expected: %d Hz\n",
+ ov02a10->eclk_freq, OV02A10_ECLK_FREQ);
+ return -EINVAL;
+ }
+
+ ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
+ if (IS_ERR(ov02a10->pd_gpio)) {
+ ret = PTR_ERR(ov02a10->pd_gpio);
+ dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
+ return ret;
+ }
+
+ ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ov02a10->n_rst_gpio)) {
+ ret = PTR_ERR(ov02a10->n_rst_gpio);
+ dev_err(dev, "failed to get reset-gpios %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < OV02A10_NUM_SUPPLIES; i++)
+ ov02a10->supplies[i].supply = ov02a10_supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, OV02A10_NUM_SUPPLIES,
+ ov02a10->supplies);
+ if (ret) {
+ dev_err(dev, "failed to get regulators\n");
+ return ret;
+ }
+
+ mutex_init(&ov02a10->mutex);
+ ov02a10->cur_mode = &supported_modes[0];
+ ret = ov02a10_initialize_controls(ov02a10);
+ if (ret) {
+ dev_err(dev, "failed to initialize controls\n");
+ goto err_destroy_mutex;
+ }
+
+ ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
+ ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+ ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
+ if (ret < 0) {
+ dev_err(dev, "failed to init entity pads: %d", ret);
+ goto err_free_handler;
+ }
+
+ ret = v4l2_async_register_subdev(&ov02a10->subdev);
+ if (ret) {
+ dev_err(dev, "failed to register V4L2 subdev: %d", ret);
+ goto err_clean_entity;
+ }
+
+ pm_runtime_enable(dev);
+ if (!pm_runtime_enabled(dev)) {
+ ret = ov02a10_power_on(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to power on: %d\n", ret);
+ goto err_clean_entity;
+ }
+ }
+
+ return 0;
+
+err_clean_entity:
+ media_entity_cleanup(&ov02a10->subdev.entity);
+err_free_handler:
+ v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
+err_destroy_mutex:
+ mutex_destroy(&ov02a10->mutex);
+
+ return ret;
+}
+
+static int ov02a10_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
+ pm_runtime_disable(&client->dev);
+ if (!pm_runtime_status_suspended(&client->dev))
+ ov02a10_power_off(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+ mutex_destroy(&ov02a10->mutex);
+
+ return 0;
+}
+
+static const struct of_device_id ov02a10_of_match[] = {
+ { .compatible = "ovti,ov02a10" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ov02a10_of_match);
+
+static struct i2c_driver ov02a10_i2c_driver = {
+ .driver = {
+ .name = "ov02a10",
+ .pm = &ov02a10_pm_ops,
+ .of_match_table = ov02a10_of_match,
+ },
+ .probe_new = &ov02a10_probe,
+ .remove = &ov02a10_remove,
+};
+
+module_i2c_driver(ov02a10_i2c_driver);
+
+MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
+MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
+MODULE_LICENSE("GPL v2");
+
--
2.9.2
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 57+ messages in thread
* [V7, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
@ 2020-04-30 8:09 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-04-30 8:09 UTC (permalink / raw)
To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Add a V4L2 sub-device driver for OV02A10 image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
MAINTAINERS | 1 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov02a10.c | 1090 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 1103 insertions(+)
create mode 100644 drivers/media/i2c/ov02a10.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 63a2335..e7677c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12395,6 +12395,7 @@ L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+F: drivers/media/i2c/ov02a10.c
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 125d596..fff92c3 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -655,6 +655,17 @@ config VIDEO_IMX355
To compile this driver as a module, choose M here: the
module will be called imx355.
+config VIDEO_OV02A10
+ tristate "OmniVision OV02A10 sensor support"
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+ help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV02A10 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov02a10.
+
config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 77bf7d0..6566dd9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV02A10) += ov02a10.o
obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
new file mode 100644
index 0000000..6a30cf3
--- /dev/null
+++ b/drivers/media/i2c/ov02a10.c
@@ -0,0 +1,1090 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 MediaTek Inc.
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <media/media-entity.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-fwnode.h>
+
+#define CHIP_ID 0x2509
+#define OV02A10_REG_CHIP_ID_H 0x02
+#define OV02A10_REG_CHIP_ID_L 0x03
+#define OV02A10_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
+
+/* Bit[1] vertical upside down */
+/* Bit[0] horizontal mirror */
+#define REG_MIRROR_FLIP_CONTROL 0x3f
+
+/* Orientation */
+#define REG_MIRROR_FLIP_ENABLE 0x03
+
+/* Bit[7] clock HS mode enable
+ * 0: Clock continue
+ * 1: Clock HS
+ * Bit[6:2] HS VOD adjust
+ * Bit[1:0] P VHI adjust
+ */
+#define REG_HS_MODE_BLC 0x9d
+
+#define CLOCK_HS_MODE_ENABLE BIT(7)
+
+/* Bit[2:0] MIPI transmission speed select */
+#define TX_SPEED_AREA_SEL 0xa1
+
+#define REG_PAGE_SWITCH 0xfd
+#define REG_GLOBAL_EFFECTIVE 0x01
+#define REG_ENABLE BIT(0)
+
+#define REG_SC_CTRL_MODE 0xac
+#define SC_CTRL_MODE_STANDBY 0x00
+#define SC_CTRL_MODE_STREAMING 0x01
+
+#define OV02A10_EXP_SHIFT 8
+#define OV02A10_REG_EXPOSURE_H 0x03
+#define OV02A10_REG_EXPOSURE_L 0x04
+#define OV02A10_EXPOSURE_MIN 4
+#define OV02A10_EXPOSURE_MAX_MARGIN 4
+#define OV02A10_EXPOSURE_STEP 1
+
+#define OV02A10_VTS_SHIFT 8
+#define OV02A10_REG_VTS_H 0x05
+#define OV02A10_REG_VTS_L 0x06
+#define OV02A10_VTS_MAX 0x209f
+#define OV02A10_VTS_MIN 0x04cf
+#define OV02A10_BASIC_LINE 1224
+
+#define OV02A10_REG_GAIN 0x24
+#define OV02A10_GAIN_MIN 0x10
+#define OV02A10_GAIN_MAX 0xf8
+#define OV02A10_GAIN_STEP 0x01
+#define OV02A10_GAIN_DEFAULT 0x40
+
+/* Test pattern control */
+#define OV02A10_REG_TEST_PATTERN 0xb6
+#define OV02A10_TEST_PATTERN_ENABLE BIT(0)
+
+#define HZ_PER_MHZ 1000000L
+#define OV02A10_LINK_FREQ_390MHZ (390 * HZ_PER_MHZ)
+#define OV02A10_ECLK_FREQ (24 * HZ_PER_MHZ)
+#define OV02A10_DATA_LANES 1
+#define OV02A10_BITS_PER_SAMPLE 10
+
+static const char * const ov02a10_supply_names[] = {
+ "dovdd", /* Digital I/O power */
+ "avdd", /* Analog power */
+ "dvdd", /* Digital core power */
+};
+
+#define OV02A10_NUM_SUPPLIES ARRAY_SIZE(ov02a10_supply_names)
+
+struct ov02a10_reg {
+ u8 addr;
+ u8 val;
+};
+
+struct ov02a10_reg_list {
+ u32 num_of_regs;
+ const struct ov02a10_reg *regs;
+};
+
+struct ov02a10_mode {
+ u32 width;
+ u32 height;
+ u32 exp_def;
+ u32 hts_def;
+ u32 vts_def;
+ const struct ov02a10_reg_list reg_list;
+};
+
+struct ov02a10 {
+ u32 eclk_freq;
+ u32 mipi_clock_tx_speed;
+
+ struct clk *eclk;
+ struct gpio_desc *pd_gpio;
+ struct gpio_desc *n_rst_gpio;
+ struct regulator_bulk_data supplies[OV02A10_NUM_SUPPLIES];
+
+ bool streaming;
+ bool upside_down;
+ bool mipi_clock_hs_mode_enable;
+
+ /*
+ * Serialize control access, get/set format, get selection
+ * and start streaming.
+ */
+ struct mutex mutex;
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_ctrl *anal_gain;
+ struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vblank;
+ struct v4l2_ctrl *test_pattern;
+ struct v4l2_mbus_framefmt fmt;
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov02a10_mode *cur_mode;
+};
+
+static inline struct ov02a10 *to_ov02a10(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov02a10, subdev);
+}
+
+/*
+ * eclk 24Mhz
+ * pclk 39Mhz
+ * linelength 934(0x3a6)
+ * framelength 1390(0x56E)
+ * grabwindow_width 1600
+ * grabwindow_height 1200
+ * max_framerate 30fps
+ * mipi_datarate per lane 780Mbps
+ */
+static const struct ov02a10_reg ov02a10_1600x1200_regs[] = {
+ {0xfd, 0x01},
+ {0xac, 0x00},
+ {0xfd, 0x00},
+ {0x2f, 0x29},
+ {0x34, 0x00},
+ {0x35, 0x21},
+ {0x30, 0x15},
+ {0x33, 0x01},
+ {0xfd, 0x01},
+ {0x44, 0x00},
+ {0x2a, 0x4c},
+ {0x2b, 0x1e},
+ {0x2c, 0x60},
+ {0x25, 0x11},
+ {0x03, 0x01},
+ {0x04, 0xae},
+ {0x09, 0x00},
+ {0x0a, 0x02},
+ {0x06, 0xa6},
+ {0x31, 0x00},
+ {0x24, 0x40},
+ {0x01, 0x01},
+ {0xfb, 0x73},
+ {0xfd, 0x01},
+ {0x16, 0x04},
+ {0x1c, 0x09},
+ {0x21, 0x42},
+ {0x12, 0x04},
+ {0x13, 0x10},
+ {0x11, 0x40},
+ {0x33, 0x81},
+ {0xd0, 0x00},
+ {0xd1, 0x01},
+ {0xd2, 0x00},
+ {0x50, 0x10},
+ {0x51, 0x23},
+ {0x52, 0x20},
+ {0x53, 0x10},
+ {0x54, 0x02},
+ {0x55, 0x20},
+ {0x56, 0x02},
+ {0x58, 0x48},
+ {0x5d, 0x15},
+ {0x5e, 0x05},
+ {0x66, 0x66},
+ {0x68, 0x68},
+ {0x6b, 0x00},
+ {0x6c, 0x00},
+ {0x6f, 0x40},
+ {0x70, 0x40},
+ {0x71, 0x0a},
+ {0x72, 0xf0},
+ {0x73, 0x10},
+ {0x75, 0x80},
+ {0x76, 0x10},
+ {0x84, 0x00},
+ {0x85, 0x10},
+ {0x86, 0x10},
+ {0x87, 0x00},
+ {0x8a, 0x22},
+ {0x8b, 0x22},
+ {0x19, 0xf1},
+ {0x29, 0x01},
+ {0xfd, 0x01},
+ {0x9d, 0x16},
+ {0xa0, 0x29},
+ {0xa1, 0x03},
+ {0xad, 0x62},
+ {0xae, 0x00},
+ {0xaf, 0x85},
+ {0xb1, 0x01},
+ {0x8e, 0x06},
+ {0x8f, 0x40},
+ {0x90, 0x04},
+ {0x91, 0xb0},
+ {0x45, 0x01},
+ {0x46, 0x00},
+ {0x47, 0x6c},
+ {0x48, 0x03},
+ {0x49, 0x8b},
+ {0x4a, 0x00},
+ {0x4b, 0x07},
+ {0x4c, 0x04},
+ {0x4d, 0xb7},
+ {0xf0, 0x40},
+ {0xf1, 0x40},
+ {0xf2, 0x40},
+ {0xf3, 0x40},
+ {0x3f, 0x00},
+ {0xfd, 0x01},
+ {0x05, 0x00},
+ {0x06, 0xa6},
+ {0xfd, 0x01},
+};
+
+static const char * const ov02a10_test_pattern_menu[] = {
+ "Disabled",
+ "Color Bar",
+};
+
+static const s64 link_freq_menu_items[] = {
+ OV02A10_LINK_FREQ_390MHZ,
+};
+
+static u64 to_pixel_rate(u32 f_index)
+{
+ u64 pixel_rate = link_freq_menu_items[f_index] * 2 * OV02A10_DATA_LANES;
+
+ do_div(pixel_rate, OV02A10_BITS_PER_SAMPLE);
+
+ return pixel_rate;
+}
+
+static const struct ov02a10_mode supported_modes[] = {
+ {
+ .width = 1600,
+ .height = 1200,
+ .exp_def = 0x01ae,
+ .hts_def = 0x03a6,
+ .vts_def = 0x056e,
+ .reg_list = {
+ .num_of_regs = ARRAY_SIZE(ov02a10_1600x1200_regs),
+ .regs = ov02a10_1600x1200_regs,
+ },
+ },
+};
+
+static int ov02a10_write_array(struct ov02a10 *ov02a10,
+ const struct ov02a10_reg_list *r_list)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < r_list->num_of_regs; i++) {
+ ret = i2c_smbus_write_byte_data(client, r_list->regs[i].addr,
+ r_list->regs[i].val);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ov02a10_read_smbus(struct ov02a10 *ov02a10, unsigned char reg,
+ unsigned char *val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(client, reg);
+
+ if (ret < 0)
+ return ret;
+
+ *val = (unsigned char)ret;
+
+ return 0;
+}
+
+static int ov02a10_mod_reg(struct ov02a10 *ov02a10, u8 reg, u8 mask, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u8 readval;
+ int ret;
+
+ ret = ov02a10_read_smbus(ov02a10, reg, &readval);
+ if (ret)
+ return ret;
+
+ val = (readval & ~mask) | (val & mask);
+
+ return i2c_smbus_write_byte_data(client, reg, val);
+}
+
+static void ov02a10_fill_fmt(const struct ov02a10_mode *mode,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ fmt->width = mode->width;
+ fmt->height = mode->height;
+ fmt->field = V4L2_FIELD_NONE;
+}
+
+static int ov02a10_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
+
+ mutex_lock(&ov02a10->mutex);
+
+ if (ov02a10->streaming) {
+ mutex_unlock(&ov02a10->mutex);
+ return -EBUSY;
+ }
+
+ /* Only one sensor mode supported */
+ mbus_fmt->code = ov02a10->fmt.code;
+ ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
+ ov02a10->fmt = fmt->format;
+
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+}
+
+static int ov02a10_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
+
+ mutex_lock(&ov02a10->mutex);
+
+ fmt->format = ov02a10->fmt;
+ mbus_fmt->code = ov02a10->fmt.code;
+ ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
+
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+}
+
+static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ if (code->index >= ARRAY_SIZE(supported_modes))
+ return -EINVAL;
+
+ code->code = ov02a10->fmt.code;
+
+ return 0;
+}
+
+static int ov02a10_enum_frame_sizes(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ if (fse->index >= ARRAY_SIZE(supported_modes))
+ return -EINVAL;
+
+ fse->min_width = supported_modes[fse->index].width;
+ fse->max_width = supported_modes[fse->index].width;
+ fse->max_height = supported_modes[fse->index].height;
+ fse->min_height = supported_modes[fse->index].height;
+
+ return 0;
+}
+
+static int ov02a10_check_sensor_id(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u16 id;
+ u8 chip_id_h;
+ u8 chip_id_l;
+ int ret;
+
+ /* Check sensor revision */
+ ret = ov02a10_read_smbus(ov02a10, OV02A10_REG_CHIP_ID_H, &chip_id_h);
+ if (ret)
+ return ret;
+
+ ret = ov02a10_read_smbus(ov02a10, OV02A10_REG_CHIP_ID_L, &chip_id_l);
+ if (ret)
+ return ret;
+
+ id = OV02A10_ID(chip_id_h, chip_id_l);
+ if (id != CHIP_ID) {
+ dev_err(&client->dev, "Unexpected sensor id(%04x)\n", id);
+ return -EINVAL;
+ }
+
+ dev_dbg(&client->dev, "Detected OV%04X sensor\n", id);
+
+ return 0;
+}
+
+static int __maybe_unused ov02a10_power_on(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ int ret;
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
+
+ ret = clk_prepare_enable(ov02a10->eclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable eclk\n");
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable regulators\n");
+ goto disable_clk;
+ }
+ usleep_range(5000, 6000);
+
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 1);
+ usleep_range(5000, 6000);
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 1);
+ usleep_range(5000, 6000);
+
+ ret = ov02a10_check_sensor_id(ov02a10);
+ if (ret)
+ goto disable_regulator;
+
+ return 0;
+
+disable_regulator:
+ regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+disable_clk:
+ clk_disable_unprepare(ov02a10->eclk);
+
+ return ret;
+}
+
+static int __maybe_unused ov02a10_power_off(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
+ clk_disable_unprepare(ov02a10->eclk);
+ gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
+ regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
+
+ return 0;
+}
+
+static int __ov02a10_start_stream(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ const struct ov02a10_reg_list *reg_list;
+ int ret;
+
+ /* Apply default values of current mode */
+ reg_list = &ov02a10->cur_mode->reg_list;
+ ret = ov02a10_write_array(ov02a10, reg_list);
+ if (ret)
+ return ret;
+
+ /* Apply customized values from user */
+ ret = __v4l2_ctrl_handler_setup(ov02a10->subdev.ctrl_handler);
+ if (ret)
+ return ret;
+
+ /* Set orientation to 180 degree */
+ if (ov02a10->upside_down) {
+ ret = i2c_smbus_write_byte_data(client, REG_MIRROR_FLIP_CONTROL,
+ REG_MIRROR_FLIP_ENABLE);
+ if (ret) {
+ dev_err(&client->dev, "failed to set orientation\n");
+ return ret;
+ }
+ ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Set clock lane transmission mode according to DT property */
+ ret = ov02a10_mod_reg(ov02a10, REG_HS_MODE_BLC, CLOCK_HS_MODE_ENABLE,
+ ov02a10->mipi_clock_hs_mode_enable ?
+ CLOCK_HS_MODE_ENABLE : 0);
+ if (ret < 0)
+ return ret;
+
+ /* Set mipi TX speed according to DT property */
+ ret = i2c_smbus_write_byte_data(client, TX_SPEED_AREA_SEL,
+ ov02a10->mipi_clock_tx_speed);
+ if (ret < 0)
+ return ret;
+
+ /* Set stream on register */
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STREAMING);
+}
+
+static int __ov02a10_stop_stream(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STANDBY);
+}
+
+static int ov02a10_entity_init_cfg(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg)
+{
+ struct v4l2_subdev_format fmt = {
+ .which = cfg ? V4L2_SUBDEV_FORMAT_TRY
+ : V4L2_SUBDEV_FORMAT_ACTIVE,
+ .format = {
+ .width = 1600,
+ .height = 1200,
+ }
+ };
+
+ ov02a10_set_fmt(sd, cfg, &fmt);
+
+ return 0;
+}
+
+static int ov02a10_s_stream(struct v4l2_subdev *sd, int on)
+{
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ dev_dbg(&client->dev, "ov02a10 s_stream (%d)\n", on);
+ mutex_lock(&ov02a10->mutex);
+
+ if (ov02a10->streaming == on)
+ goto unlock_and_return;
+
+ if (on) {
+ ret = pm_runtime_get_sync(&client->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&client->dev);
+ goto unlock_and_return;
+ }
+
+ ret = __ov02a10_start_stream(ov02a10);
+ if (ret) {
+ __ov02a10_stop_stream(ov02a10);
+ ov02a10->streaming = !on;
+ goto err_rpm_put;
+ }
+ } else {
+ __ov02a10_stop_stream(ov02a10);
+ pm_runtime_put(&client->dev);
+ }
+
+ ov02a10->streaming = on;
+ mutex_unlock(&ov02a10->mutex);
+
+ return 0;
+
+err_rpm_put:
+ pm_runtime_put(&client->dev);
+unlock_and_return:
+ mutex_unlock(&ov02a10->mutex);
+
+ return ret;
+}
+
+static const struct dev_pm_ops ov02a10_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(ov02a10_power_off, ov02a10_power_on, NULL)
+};
+
+/*
+ * ov02a10_set_exposure - Function called when setting exposure time
+ * @priv: Pointer to device structure
+ * @val: Variable for exposure time, in the unit of micro-second
+ *
+ * Set exposure time based on input value.
+ *
+ * Return: 0 on success
+ */
+static int ov02a10_set_exposure(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_H,
+ val >> OV02A10_EXP_SHIFT);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_L, val);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_gain(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_GAIN, val);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_vblank(struct ov02a10 *ov02a10, int val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ u32 vts = val + ov02a10->cur_mode->height - OV02A10_BASIC_LINE;
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_H,
+ vts >> OV02A10_VTS_SHIFT);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_L, vts);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+}
+
+static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ int ret;
+
+ if (pattern)
+ pattern = OV02A10_TEST_PATTERN_ENABLE;
+
+ ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OV02A10_REG_TEST_PATTERN,
+ pattern);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
+ REG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, REG_SC_CTRL_MODE,
+ SC_CTRL_MODE_STREAMING);
+}
+
+static int ov02a10_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ov02a10 *ov02a10 = container_of(ctrl->handler,
+ struct ov02a10, ctrl_handler);
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ s64 max_expo;
+ int ret;
+
+ /* Propagate change of current control to all related controls */
+ if (ctrl->id == V4L2_CID_VBLANK) {
+ /* Update max exposure while meeting expected vblanking */
+ max_expo = ov02a10->cur_mode->height + ctrl->val -
+ OV02A10_EXPOSURE_MAX_MARGIN;
+ __v4l2_ctrl_modify_range(ov02a10->exposure,
+ ov02a10->exposure->minimum, max_expo,
+ ov02a10->exposure->step,
+ ov02a10->exposure->default_value);
+ }
+
+ /* V4L2 controls values will be applied only when power is already up */
+ if (!pm_runtime_get_if_in_use(&client->dev))
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_EXPOSURE:
+ ret = ov02a10_set_exposure(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_ANALOGUE_GAIN:
+ ret = ov02a10_set_gain(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_VBLANK:
+ ret = ov02a10_set_vblank(ov02a10, ctrl->val);
+ break;
+ case V4L2_CID_TEST_PATTERN:
+ ret = ov02a10_set_test_pattern(ov02a10, ctrl->val);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ };
+
+ pm_runtime_put(&client->dev);
+
+ return ret;
+}
+
+static const struct v4l2_subdev_video_ops ov02a10_video_ops = {
+ .s_stream = ov02a10_s_stream,
+};
+
+static const struct v4l2_subdev_pad_ops ov02a10_pad_ops = {
+ .init_cfg = ov02a10_entity_init_cfg,
+ .enum_mbus_code = ov02a10_enum_mbus_code,
+ .enum_frame_size = ov02a10_enum_frame_sizes,
+ .get_fmt = ov02a10_get_fmt,
+ .set_fmt = ov02a10_set_fmt,
+};
+
+static const struct v4l2_subdev_ops ov02a10_subdev_ops = {
+ .video = &ov02a10_video_ops,
+ .pad = &ov02a10_pad_ops,
+};
+
+static const struct media_entity_operations ov02a10_subdev_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static const struct v4l2_ctrl_ops ov02a10_ctrl_ops = {
+ .s_ctrl = ov02a10_set_ctrl,
+};
+
+static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
+ const struct ov02a10_mode *mode;
+ struct v4l2_ctrl_handler *handler;
+ struct v4l2_ctrl *ctrl;
+ u64 exposure_max;
+ u32 pixel_rate, h_blank;
+ int ret;
+
+ handler = &ov02a10->ctrl_handler;
+ mode = ov02a10->cur_mode;
+ ret = v4l2_ctrl_handler_init(handler, 7);
+ if (ret)
+ return ret;
+
+ handler->lock = &ov02a10->mutex;
+
+ ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
+ link_freq_menu_items);
+ if (ctrl)
+ ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ pixel_rate = to_pixel_rate(0);
+ v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
+ pixel_rate);
+
+ h_blank = mode->hts_def - mode->width;
+ ov02a10->hblank = v4l2_ctrl_new_std(handler, NULL, V4L2_CID_HBLANK,
+ h_blank, h_blank, 1, h_blank);
+ if (ov02a10->hblank)
+ ov02a10->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ ov02a10->vblank = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_VBLANK, mode->vts_def -
+ mode->height,
+ OV02A10_VTS_MAX - mode->height, 1,
+ mode->vts_def - mode->height);
+
+ exposure_max = mode->vts_def - 4;
+ ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_EXPOSURE,
+ OV02A10_EXPOSURE_MIN,
+ exposure_max,
+ OV02A10_EXPOSURE_STEP,
+ mode->exp_def);
+
+ ov02a10->anal_gain = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_ANALOGUE_GAIN,
+ OV02A10_GAIN_MIN,
+ OV02A10_GAIN_MAX,
+ OV02A10_GAIN_STEP,
+ OV02A10_GAIN_DEFAULT);
+
+ ov02a10->test_pattern =
+ v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(ov02a10_test_pattern_menu) -
+ 1, 0, 0,
+ ov02a10_test_pattern_menu);
+
+ if (handler->error) {
+ ret = handler->error;
+ dev_err(&client->dev, "failed to init controls(%d)\n", ret);
+ goto err_free_handler;
+ }
+
+ ov02a10->subdev.ctrl_handler = handler;
+
+ return 0;
+
+err_free_handler:
+ v4l2_ctrl_handler_free(handler);
+
+ return ret;
+}
+
+static int ov02a10_check_hwcfg(struct device *dev, struct ov02a10 *ov02a10)
+{
+ struct fwnode_handle *ep;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
+ struct v4l2_fwnode_endpoint bus_cfg = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY,
+ };
+ unsigned int i, j;
+ int ret;
+
+ if (!fwnode)
+ return -EINVAL;
+
+ ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
+ if (!ep)
+ return -ENXIO;
+
+ ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+ fwnode_handle_put(ep);
+ if (ret)
+ return ret;
+
+ /* Optional indication of mipi clock lane mode */
+ if (bus_cfg.bus.mipi_csi2.flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK)
+ ov02a10->mipi_clock_hs_mode_enable = true;
+
+ if (!bus_cfg.nr_of_link_frequencies) {
+ dev_err(dev, "no link frequencies defined");
+ ret = -EINVAL;
+ goto check_hwcfg_error;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(link_freq_menu_items); i++) {
+ for (j = 0; j < bus_cfg.nr_of_link_frequencies; j++) {
+ if (link_freq_menu_items[i] ==
+ bus_cfg.link_frequencies[j])
+ break;
+ }
+
+ if (j == bus_cfg.nr_of_link_frequencies) {
+ dev_err(dev, "no link frequency %lld supported",
+ link_freq_menu_items[i]);
+ ret = -EINVAL;
+ goto check_hwcfg_error;
+ }
+ }
+
+check_hwcfg_error:
+ v4l2_fwnode_endpoint_free(&bus_cfg);
+
+ return ret;
+}
+
+static int ov02a10_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct ov02a10 *ov02a10;
+ unsigned int rotation;
+ unsigned int clock_lane_tx_speed;
+ unsigned int i;
+ int ret;
+
+ ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
+ if (!ov02a10)
+ return -ENOMEM;
+
+ ret = ov02a10_check_hwcfg(dev, ov02a10);
+ if (ret) {
+ dev_err(dev, "failed to check HW configuration: %d", ret);
+ return ret;
+ }
+
+ v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
+ ov02a10->upside_down = false;
+ ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
+
+ /* Optional indication of physical rotation of sensor */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation", &rotation);
+ if (!ret) {
+ ov02a10->upside_down = rotation == 180;
+
+ if (rotation == 180) {
+ ov02a10->upside_down = true;
+ ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
+ }
+ }
+
+ /* Optional indication of mipi TX speed */
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "ovti,mipi-tx-speed",
+ &clock_lane_tx_speed);
+
+ if (!ret)
+ ov02a10->mipi_clock_tx_speed = clock_lane_tx_speed;
+
+ /* Get system clock (eclk) */
+ ov02a10->eclk = devm_clk_get(dev, "eclk");
+ if (IS_ERR(ov02a10->eclk)) {
+ ret = PTR_ERR(ov02a10->eclk);
+ dev_err(dev, "failed to get eclk %d\n", ret);
+ return ret;
+ }
+
+ ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
+ &ov02a10->eclk_freq);
+ if (ret) {
+ dev_err(dev, "failed to get eclk frequency\n");
+ return ret;
+ }
+
+ ret = clk_set_rate(ov02a10->eclk, ov02a10->eclk_freq);
+ if (ret) {
+ dev_err(dev, "failed to set eclk frequency (24MHz)\n");
+ return ret;
+ }
+
+ if (clk_get_rate(ov02a10->eclk) != OV02A10_ECLK_FREQ) {
+ dev_warn(dev, "wrong eclk frequency %d Hz, expected: %d Hz\n",
+ ov02a10->eclk_freq, OV02A10_ECLK_FREQ);
+ return -EINVAL;
+ }
+
+ ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
+ if (IS_ERR(ov02a10->pd_gpio)) {
+ ret = PTR_ERR(ov02a10->pd_gpio);
+ dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
+ return ret;
+ }
+
+ ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ov02a10->n_rst_gpio)) {
+ ret = PTR_ERR(ov02a10->n_rst_gpio);
+ dev_err(dev, "failed to get reset-gpios %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; i < OV02A10_NUM_SUPPLIES; i++)
+ ov02a10->supplies[i].supply = ov02a10_supply_names[i];
+
+ ret = devm_regulator_bulk_get(dev, OV02A10_NUM_SUPPLIES,
+ ov02a10->supplies);
+ if (ret) {
+ dev_err(dev, "failed to get regulators\n");
+ return ret;
+ }
+
+ mutex_init(&ov02a10->mutex);
+ ov02a10->cur_mode = &supported_modes[0];
+ ret = ov02a10_initialize_controls(ov02a10);
+ if (ret) {
+ dev_err(dev, "failed to initialize controls\n");
+ goto err_destroy_mutex;
+ }
+
+ ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
+ ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+ ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
+ if (ret < 0) {
+ dev_err(dev, "failed to init entity pads: %d", ret);
+ goto err_free_handler;
+ }
+
+ ret = v4l2_async_register_subdev(&ov02a10->subdev);
+ if (ret) {
+ dev_err(dev, "failed to register V4L2 subdev: %d", ret);
+ goto err_clean_entity;
+ }
+
+ pm_runtime_enable(dev);
+ if (!pm_runtime_enabled(dev)) {
+ ret = ov02a10_power_on(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to power on: %d\n", ret);
+ goto err_clean_entity;
+ }
+ }
+
+ return 0;
+
+err_clean_entity:
+ media_entity_cleanup(&ov02a10->subdev.entity);
+err_free_handler:
+ v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
+err_destroy_mutex:
+ mutex_destroy(&ov02a10->mutex);
+
+ return ret;
+}
+
+static int ov02a10_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ov02a10 *ov02a10 = to_ov02a10(sd);
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
+ pm_runtime_disable(&client->dev);
+ if (!pm_runtime_status_suspended(&client->dev))
+ ov02a10_power_off(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+ mutex_destroy(&ov02a10->mutex);
+
+ return 0;
+}
+
+static const struct of_device_id ov02a10_of_match[] = {
+ { .compatible = "ovti,ov02a10" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ov02a10_of_match);
+
+static struct i2c_driver ov02a10_i2c_driver = {
+ .driver = {
+ .name = "ov02a10",
+ .pm = &ov02a10_pm_ops,
+ .of_match_table = ov02a10_of_match,
+ },
+ .probe_new = &ov02a10_probe,
+ .remove = &ov02a10_remove,
+};
+
+module_i2c_driver(ov02a10_i2c_driver);
+
+MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
+MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
+MODULE_LICENSE("GPL v2");
+
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-04-30 8:09 ` Dongchun Zhu
(?)
@ 2020-05-05 7:04 ` Sakari Ailus
-1 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-05 7:04 UTC (permalink / raw)
To: Dongchun Zhu
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, tfiga, matthias.bgg, bingbu.cao,
srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang
Hi Dongchun,
On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..2be4bd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: devider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as interface power supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as analog power supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as digital power supply.
> +
> + powerdown-gpios:
> + description:
> + The phandle and specifier for the GPIO that controls sensor powerdown.
> +
> + reset-gpios:
> + description:
> + The phandle and specifier for the GPIO that controls sensor reset.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement, valid values are 0 and 180.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select.
What exactly does this signify? And how do you come up with the number?
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum: [ 3, 4 ]
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + remote-endpoint: true
> + link-frequencies: true
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <3>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + link-frequencies = /bits/ 64 <390000000>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
--
Regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-05 7:04 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-05 7:04 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
Hi Dongchun,
On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..2be4bd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: devider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as interface power supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as analog power supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as digital power supply.
> +
> + powerdown-gpios:
> + description:
> + The phandle and specifier for the GPIO that controls sensor powerdown.
> +
> + reset-gpios:
> + description:
> + The phandle and specifier for the GPIO that controls sensor reset.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement, valid values are 0 and 180.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select.
What exactly does this signify? And how do you come up with the number?
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum: [ 3, 4 ]
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + remote-endpoint: true
> + link-frequencies: true
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <3>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + link-frequencies = /bits/ 64 <390000000>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
--
Regards,
Sakari Ailus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-05 7:04 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-05 7:04 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
Hi Dongchun,
On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..2be4bd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: devider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as interface power supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as analog power supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as digital power supply.
> +
> + powerdown-gpios:
> + description:
> + The phandle and specifier for the GPIO that controls sensor powerdown.
> +
> + reset-gpios:
> + description:
> + The phandle and specifier for the GPIO that controls sensor reset.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement, valid values are 0 and 180.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select.
What exactly does this signify? And how do you come up with the number?
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum: [ 3, 4 ]
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + remote-endpoint: true
> + link-frequencies: true
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <3>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + link-frequencies = /bits/ 64 <390000000>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
--
Regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-05 7:04 ` Sakari Ailus
(?)
@ 2020-05-05 14:17 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-05 14:17 UTC (permalink / raw)
To: Sakari Ailus
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, matrix.zhu, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
Hi Sakari,
Thanks for the review.
On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 155 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..2be4bd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: devider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as interface power supply.
> > +
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as analog power supply.
> > +
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as digital power supply.
> > +
> > + powerdown-gpios:
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > +
> > + reset-gpios:
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor reset.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement, valid values are 0 and 180.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select.
>
> What exactly does this signify? And how do you come up with the number?
>
Apologies for not addressing this number clear.
From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
the default val: 0x03.
The description of this RW register is as below:
Bit[2:0]: MIPI transmission speed select.
Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
This would be fixed in next release.
In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
that value if there is no setting for this private property in DT.
The caller in driver would be updated like this in next release.
if (ov02a10->mipi_clock_tx_speed)
ret = i2c_smbus_write_byte_data(...,...);
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum: [ 3, 4 ]
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + remote-endpoint: true
> > + link-frequencies: true
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + clock-frequency = <400000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <3>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + remote-endpoint = <&mipi_in_wcam>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-05 14:17 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-05 14:17 UTC (permalink / raw)
To: Sakari Ailus
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, matrix.zhu, mchehab, linux-arm-kernel, linux-media
Hi Sakari,
Thanks for the review.
On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 155 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..2be4bd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: devider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as interface power supply.
> > +
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as analog power supply.
> > +
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as digital power supply.
> > +
> > + powerdown-gpios:
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > +
> > + reset-gpios:
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor reset.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement, valid values are 0 and 180.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select.
>
> What exactly does this signify? And how do you come up with the number?
>
Apologies for not addressing this number clear.
From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
the default val: 0x03.
The description of this RW register is as below:
Bit[2:0]: MIPI transmission speed select.
Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
This would be fixed in next release.
In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
that value if there is no setting for this private property in DT.
The caller in driver would be updated like this in next release.
if (ov02a10->mipi_clock_tx_speed)
ret = i2c_smbus_write_byte_data(...,...);
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum: [ 3, 4 ]
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + remote-endpoint: true
> > + link-frequencies: true
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + clock-frequency = <400000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <3>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + remote-endpoint = <&mipi_in_wcam>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-05 14:17 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-05 14:17 UTC (permalink / raw)
To: Sakari Ailus
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, matrix.zhu, mchehab, linux-arm-kernel, linux-media
Hi Sakari,
Thanks for the review.
On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 155 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..2be4bd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: devider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as interface power supply.
> > +
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as analog power supply.
> > +
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as digital power supply.
> > +
> > + powerdown-gpios:
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > +
> > + reset-gpios:
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor reset.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement, valid values are 0 and 180.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select.
>
> What exactly does this signify? And how do you come up with the number?
>
Apologies for not addressing this number clear.
From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
the default val: 0x03.
The description of this RW register is as below:
Bit[2:0]: MIPI transmission speed select.
Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
This would be fixed in next release.
In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
that value if there is no setting for this private property in DT.
The caller in driver would be updated like this in next release.
if (ov02a10->mipi_clock_tx_speed)
ret = i2c_smbus_write_byte_data(...,...);
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum: [ 3, 4 ]
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + remote-endpoint: true
> > + link-frequencies: true
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + clock-frequency = <400000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <3>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + remote-endpoint = <&mipi_in_wcam>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-04-30 8:09 ` Dongchun Zhu
(?)
@ 2020-05-05 16:15 ` Rob Herring
-1 siblings, 0 replies; 57+ messages in thread
From: Rob Herring @ 2020-05-05 16:15 UTC (permalink / raw)
To: Dongchun Zhu
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..2be4bd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: devider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as interface power supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as analog power supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as digital power supply.
> +
> + powerdown-gpios:
maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls sensor powerdown.
Can be dropped. Doesn't tell me anything specific to this device.
> +
> + reset-gpios:
maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls sensor reset.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement, valid values are 0 and 180.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum: [ 3, 4 ]
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + remote-endpoint: true
> + link-frequencies: true
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <3>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + link-frequencies = /bits/ 64 <390000000>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
> --
> 2.9.2
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-05 16:15 ` Rob Herring
0 siblings, 0 replies; 57+ messages in thread
From: Rob Herring @ 2020-05-05 16:15 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, devicetree, andriy.shevchenko, louis.kuo,
srv_heupstream, linus.walleij, shengnan.wang, tfiga,
bgolaszewski, sj.huang, drinkcat, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..2be4bd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: devider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as interface power supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as analog power supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as digital power supply.
> +
> + powerdown-gpios:
maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls sensor powerdown.
Can be dropped. Doesn't tell me anything specific to this device.
> +
> + reset-gpios:
maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls sensor reset.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement, valid values are 0 and 180.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum: [ 3, 4 ]
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + remote-endpoint: true
> + link-frequencies: true
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <3>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + link-frequencies = /bits/ 64 <390000000>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
> --
> 2.9.2
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-05 16:15 ` Rob Herring
0 siblings, 0 replies; 57+ messages in thread
From: Rob Herring @ 2020-05-05 16:15 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, devicetree, andriy.shevchenko, louis.kuo,
srv_heupstream, linus.walleij, shengnan.wang, tfiga,
bgolaszewski, sj.huang, drinkcat, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..2be4bd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: devider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as interface power supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as analog power supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as digital power supply.
> +
> + powerdown-gpios:
maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls sensor powerdown.
Can be dropped. Doesn't tell me anything specific to this device.
> +
> + reset-gpios:
maxItems: 1
> + description:
> + The phandle and specifier for the GPIO that controls sensor reset.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement, valid values are 0 and 180.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum: [ 3, 4 ]
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + remote-endpoint: true
> + link-frequencies: true
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <3>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + link-frequencies = /bits/ 64 <390000000>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
> --
> 2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-05 14:17 ` Dongchun Zhu
(?)
@ 2020-05-06 11:21 ` Sakari Ailus
-1 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-06 11:21 UTC (permalink / raw)
To: Dongchun Zhu
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, matrix.zhu, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
Hi Dongchun,
On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> Hi Sakari,
>
> Thanks for the review.
>
> On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > >
> > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > ---
> > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > MAINTAINERS | 7 +
> > > 2 files changed, 155 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > new file mode 100644
> > > index 0000000..2be4bd2
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > @@ -0,0 +1,148 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +# Copyright (c) 2020 MediaTek Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +
> > > +description: |-
> > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > + sensor output is available via CSI-2 serial data output.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: ovti,ov02a10
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + items:
> > > + - description: top mux camtg clock
> > > + - description: devider clock
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: eclk
> > > + - const: freq_mux
> > > +
> > > + clock-frequency:
> > > + description:
> > > + Frequency of the eclk clock in Hertz.
> > > +
> > > + dovdd-supply:
> > > + description:
> > > + Definition of the regulator used as interface power supply.
> > > +
> > > + avdd-supply:
> > > + description:
> > > + Definition of the regulator used as analog power supply.
> > > +
> > > + dvdd-supply:
> > > + description:
> > > + Definition of the regulator used as digital power supply.
> > > +
> > > + powerdown-gpios:
> > > + description:
> > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > +
> > > + reset-gpios:
> > > + description:
> > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > +
> > > + rotation:
> > > + description:
> > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum:
> > > + - 0 # Sensor Mounted Upright
> > > + - 180 # Sensor Mounted Upside Down
> > > +
> > > + ovti,mipi-tx-speed:
> > > + description:
> > > + Indication of MIPI transmission speed select.
> >
> > What exactly does this signify? And how do you come up with the number?
> >
>
> Apologies for not addressing this number clear.
>
> From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> the default val: 0x03.
> The description of this RW register is as below:
> Bit[2:0]: MIPI transmission speed select.
>
> Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> This would be fixed in next release.
>
> In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> that value if there is no setting for this private property in DT.
> The caller in driver would be updated like this in next release.
> if (ov02a10->mipi_clock_tx_speed)
> ret = i2c_smbus_write_byte_data(...,...);
How did you pick the value in the example? And why do you believe it is
specific to a platform, and not e.g. a sensor mode?
>
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum: [ 3, 4 ]
> > > +
> > > + # See ../video-interfaces.txt for details
> > > + port:
> > > + type: object
> > > + additionalProperties: false
> > > +
> > > + properties:
> > > + endpoint:
> > > + type: object
> > > + additionalProperties: false
> > > +
> > > + properties:
> > > + remote-endpoint: true
> > > + link-frequencies: true
> > > +
> > > + required:
> > > + - endpoint
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - clocks
> > > + - clock-names
> > > + - clock-frequency
> > > + - dovdd-supply
> > > + - avdd-supply
> > > + - dvdd-supply
> > > + - powerdown-gpios
> > > + - reset-gpios
> > > + - port
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + i2c {
> > > + clock-frequency = <400000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + ov02a10: camera-sensor@3d {
> > > + compatible = "ovti,ov02a10";
> > > + reg = <0x3d>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&clk_24m_cam>;
> > > +
> > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > + clock-names = "eclk", "freq_mux";
> > > + clock-frequency = <24000000>;
> > > +
> > > + rotation = <180>;
> > > + ovti,mipi-tx-speed = <3>;
> > > +
> > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > +
> > > + port {
> > > + wcam_out: endpoint {
> > > + remote-endpoint = <&mipi_in_wcam>;
> > > + link-frequencies = /bits/ 64 <390000000>;
> > > + };
> > > + };
> > > + };
> > > + };
> > > +
> > > +...
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index e64e5db..63a2335 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > S: Maintained
> > > F: drivers/char/pcmcia/cm4040_cs.*
> > >
> > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +L: linux-media@vger.kernel.org
> > > +S: Maintained
> > > +T: git git://linuxtv.org/media_tree.git
> > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > +
> > > OMNIVISION OV13858 SENSOR DRIVER
> > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > L: linux-media@vger.kernel.org
> >
>
--
Regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-06 11:21 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-06 11:21 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, matrix.zhu, mchehab, linux-arm-kernel, linux-media
Hi Dongchun,
On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> Hi Sakari,
>
> Thanks for the review.
>
> On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > >
> > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > ---
> > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > MAINTAINERS | 7 +
> > > 2 files changed, 155 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > new file mode 100644
> > > index 0000000..2be4bd2
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > @@ -0,0 +1,148 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +# Copyright (c) 2020 MediaTek Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +
> > > +description: |-
> > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > + sensor output is available via CSI-2 serial data output.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: ovti,ov02a10
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + items:
> > > + - description: top mux camtg clock
> > > + - description: devider clock
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: eclk
> > > + - const: freq_mux
> > > +
> > > + clock-frequency:
> > > + description:
> > > + Frequency of the eclk clock in Hertz.
> > > +
> > > + dovdd-supply:
> > > + description:
> > > + Definition of the regulator used as interface power supply.
> > > +
> > > + avdd-supply:
> > > + description:
> > > + Definition of the regulator used as analog power supply.
> > > +
> > > + dvdd-supply:
> > > + description:
> > > + Definition of the regulator used as digital power supply.
> > > +
> > > + powerdown-gpios:
> > > + description:
> > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > +
> > > + reset-gpios:
> > > + description:
> > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > +
> > > + rotation:
> > > + description:
> > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum:
> > > + - 0 # Sensor Mounted Upright
> > > + - 180 # Sensor Mounted Upside Down
> > > +
> > > + ovti,mipi-tx-speed:
> > > + description:
> > > + Indication of MIPI transmission speed select.
> >
> > What exactly does this signify? And how do you come up with the number?
> >
>
> Apologies for not addressing this number clear.
>
> From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> the default val: 0x03.
> The description of this RW register is as below:
> Bit[2:0]: MIPI transmission speed select.
>
> Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> This would be fixed in next release.
>
> In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> that value if there is no setting for this private property in DT.
> The caller in driver would be updated like this in next release.
> if (ov02a10->mipi_clock_tx_speed)
> ret = i2c_smbus_write_byte_data(...,...);
How did you pick the value in the example? And why do you believe it is
specific to a platform, and not e.g. a sensor mode?
>
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum: [ 3, 4 ]
> > > +
> > > + # See ../video-interfaces.txt for details
> > > + port:
> > > + type: object
> > > + additionalProperties: false
> > > +
> > > + properties:
> > > + endpoint:
> > > + type: object
> > > + additionalProperties: false
> > > +
> > > + properties:
> > > + remote-endpoint: true
> > > + link-frequencies: true
> > > +
> > > + required:
> > > + - endpoint
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - clocks
> > > + - clock-names
> > > + - clock-frequency
> > > + - dovdd-supply
> > > + - avdd-supply
> > > + - dvdd-supply
> > > + - powerdown-gpios
> > > + - reset-gpios
> > > + - port
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + i2c {
> > > + clock-frequency = <400000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + ov02a10: camera-sensor@3d {
> > > + compatible = "ovti,ov02a10";
> > > + reg = <0x3d>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&clk_24m_cam>;
> > > +
> > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > + clock-names = "eclk", "freq_mux";
> > > + clock-frequency = <24000000>;
> > > +
> > > + rotation = <180>;
> > > + ovti,mipi-tx-speed = <3>;
> > > +
> > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > +
> > > + port {
> > > + wcam_out: endpoint {
> > > + remote-endpoint = <&mipi_in_wcam>;
> > > + link-frequencies = /bits/ 64 <390000000>;
> > > + };
> > > + };
> > > + };
> > > + };
> > > +
> > > +...
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index e64e5db..63a2335 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > S: Maintained
> > > F: drivers/char/pcmcia/cm4040_cs.*
> > >
> > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +L: linux-media@vger.kernel.org
> > > +S: Maintained
> > > +T: git git://linuxtv.org/media_tree.git
> > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > +
> > > OMNIVISION OV13858 SENSOR DRIVER
> > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > L: linux-media@vger.kernel.org
> >
>
--
Regards,
Sakari Ailus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-06 11:21 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-06 11:21 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, matrix.zhu, mchehab, linux-arm-kernel, linux-media
Hi Dongchun,
On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> Hi Sakari,
>
> Thanks for the review.
>
> On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > >
> > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > ---
> > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > MAINTAINERS | 7 +
> > > 2 files changed, 155 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > new file mode 100644
> > > index 0000000..2be4bd2
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > @@ -0,0 +1,148 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +# Copyright (c) 2020 MediaTek Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +
> > > +description: |-
> > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > + sensor output is available via CSI-2 serial data output.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: ovti,ov02a10
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + items:
> > > + - description: top mux camtg clock
> > > + - description: devider clock
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: eclk
> > > + - const: freq_mux
> > > +
> > > + clock-frequency:
> > > + description:
> > > + Frequency of the eclk clock in Hertz.
> > > +
> > > + dovdd-supply:
> > > + description:
> > > + Definition of the regulator used as interface power supply.
> > > +
> > > + avdd-supply:
> > > + description:
> > > + Definition of the regulator used as analog power supply.
> > > +
> > > + dvdd-supply:
> > > + description:
> > > + Definition of the regulator used as digital power supply.
> > > +
> > > + powerdown-gpios:
> > > + description:
> > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > +
> > > + reset-gpios:
> > > + description:
> > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > +
> > > + rotation:
> > > + description:
> > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum:
> > > + - 0 # Sensor Mounted Upright
> > > + - 180 # Sensor Mounted Upside Down
> > > +
> > > + ovti,mipi-tx-speed:
> > > + description:
> > > + Indication of MIPI transmission speed select.
> >
> > What exactly does this signify? And how do you come up with the number?
> >
>
> Apologies for not addressing this number clear.
>
> From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> the default val: 0x03.
> The description of this RW register is as below:
> Bit[2:0]: MIPI transmission speed select.
>
> Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> This would be fixed in next release.
>
> In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> that value if there is no setting for this private property in DT.
> The caller in driver would be updated like this in next release.
> if (ov02a10->mipi_clock_tx_speed)
> ret = i2c_smbus_write_byte_data(...,...);
How did you pick the value in the example? And why do you believe it is
specific to a platform, and not e.g. a sensor mode?
>
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum: [ 3, 4 ]
> > > +
> > > + # See ../video-interfaces.txt for details
> > > + port:
> > > + type: object
> > > + additionalProperties: false
> > > +
> > > + properties:
> > > + endpoint:
> > > + type: object
> > > + additionalProperties: false
> > > +
> > > + properties:
> > > + remote-endpoint: true
> > > + link-frequencies: true
> > > +
> > > + required:
> > > + - endpoint
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - clocks
> > > + - clock-names
> > > + - clock-frequency
> > > + - dovdd-supply
> > > + - avdd-supply
> > > + - dvdd-supply
> > > + - powerdown-gpios
> > > + - reset-gpios
> > > + - port
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + i2c {
> > > + clock-frequency = <400000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + ov02a10: camera-sensor@3d {
> > > + compatible = "ovti,ov02a10";
> > > + reg = <0x3d>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&clk_24m_cam>;
> > > +
> > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > + clock-names = "eclk", "freq_mux";
> > > + clock-frequency = <24000000>;
> > > +
> > > + rotation = <180>;
> > > + ovti,mipi-tx-speed = <3>;
> > > +
> > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > +
> > > + port {
> > > + wcam_out: endpoint {
> > > + remote-endpoint = <&mipi_in_wcam>;
> > > + link-frequencies = /bits/ 64 <390000000>;
> > > + };
> > > + };
> > > + };
> > > + };
> > > +
> > > +...
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index e64e5db..63a2335 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > S: Maintained
> > > F: drivers/char/pcmcia/cm4040_cs.*
> > >
> > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +L: linux-media@vger.kernel.org
> > > +S: Maintained
> > > +T: git git://linuxtv.org/media_tree.git
> > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > +
> > > OMNIVISION OV13858 SENSOR DRIVER
> > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > L: linux-media@vger.kernel.org
> >
>
--
Regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-06 11:21 ` Sakari Ailus
(?)
@ 2020-05-07 12:58 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-07 12:58 UTC (permalink / raw)
To: Sakari Ailus
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, matrix.zhu, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
Hi Sakari,
Thanks for the review.
On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > Hi Sakari,
> >
> > Thanks for the review.
> >
> > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > >
> > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > ---
> > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > MAINTAINERS | 7 +
> > > > 2 files changed, 155 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > new file mode 100644
> > > > index 0000000..2be4bd2
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > @@ -0,0 +1,148 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > +
> > > > +maintainers:
> > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > +
> > > > +description: |-
> > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > + sensor output is available via CSI-2 serial data output.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + const: ovti,ov02a10
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + clocks:
> > > > + items:
> > > > + - description: top mux camtg clock
> > > > + - description: devider clock
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: eclk
> > > > + - const: freq_mux
> > > > +
> > > > + clock-frequency:
> > > > + description:
> > > > + Frequency of the eclk clock in Hertz.
> > > > +
> > > > + dovdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as interface power supply.
> > > > +
> > > > + avdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as analog power supply.
> > > > +
> > > > + dvdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as digital power supply.
> > > > +
> > > > + powerdown-gpios:
> > > > + description:
> > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > +
> > > > + reset-gpios:
> > > > + description:
> > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > +
> > > > + rotation:
> > > > + description:
> > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > + allOf:
> > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > + - enum:
> > > > + - 0 # Sensor Mounted Upright
> > > > + - 180 # Sensor Mounted Upside Down
> > > > +
> > > > + ovti,mipi-tx-speed:
> > > > + description:
> > > > + Indication of MIPI transmission speed select.
> > >
> > > What exactly does this signify? And how do you come up with the number?
> > >
> >
> > Apologies for not addressing this number clear.
> >
> > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > the default val: 0x03.
> > The description of this RW register is as below:
> > Bit[2:0]: MIPI transmission speed select.
> >
> > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > This would be fixed in next release.
> >
> > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > that value if there is no setting for this private property in DT.
> > The caller in driver would be updated like this in next release.
> > if (ov02a10->mipi_clock_tx_speed)
> > ret = i2c_smbus_write_byte_data(...,...);
>
> How did you pick the value in the example? And why do you believe it is
> specific to a platform, and not e.g. a sensor mode?
>
We look into P1:0XA1, one register that defines MIPI transmission speed
select.
From the datasheet, we can get the possible values that could be set to
P1:0xA1.
Actually this register is an independent of sensor mode, it is just
included in sensor mode's register setting table.
In addition, this private DT Property is created to fix the MIPI test
failure. The register values are adjusted and verified from vendor to
make sensor signal meet MIPI specification.
> >
> > > > + allOf:
> > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > + - enum: [ 3, 4 ]
> > > > +
> > > > + # See ../video-interfaces.txt for details
> > > > + port:
> > > > + type: object
> > > > + additionalProperties: false
> > > > +
> > > > + properties:
> > > > + endpoint:
> > > > + type: object
> > > > + additionalProperties: false
> > > > +
> > > > + properties:
> > > > + remote-endpoint: true
> > > > + link-frequencies: true
> > > > +
> > > > + required:
> > > > + - endpoint
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - clocks
> > > > + - clock-names
> > > > + - clock-frequency
> > > > + - dovdd-supply
> > > > + - avdd-supply
> > > > + - dvdd-supply
> > > > + - powerdown-gpios
> > > > + - reset-gpios
> > > > + - port
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > + #include <dt-bindings/gpio/gpio.h>
> > > > +
> > > > + i2c {
> > > > + clock-frequency = <400000>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + ov02a10: camera-sensor@3d {
> > > > + compatible = "ovti,ov02a10";
> > > > + reg = <0x3d>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&clk_24m_cam>;
> > > > +
> > > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > > + clock-names = "eclk", "freq_mux";
> > > > + clock-frequency = <24000000>;
> > > > +
> > > > + rotation = <180>;
> > > > + ovti,mipi-tx-speed = <3>;
> > > > +
> > > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > > +
> > > > + port {
> > > > + wcam_out: endpoint {
> > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > + link-frequencies = /bits/ 64 <390000000>;
> > > > + };
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > +...
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index e64e5db..63a2335 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > > S: Maintained
> > > > F: drivers/char/pcmcia/cm4040_cs.*
> > > >
> > > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > +L: linux-media@vger.kernel.org
> > > > +S: Maintained
> > > > +T: git git://linuxtv.org/media_tree.git
> > > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > +
> > > > OMNIVISION OV13858 SENSOR DRIVER
> > > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > L: linux-media@vger.kernel.org
> > >
> >
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 12:58 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-07 12:58 UTC (permalink / raw)
To: Sakari Ailus
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, matrix.zhu, mchehab, linux-arm-kernel, linux-media
Hi Sakari,
Thanks for the review.
On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > Hi Sakari,
> >
> > Thanks for the review.
> >
> > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > >
> > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > ---
> > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > MAINTAINERS | 7 +
> > > > 2 files changed, 155 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > new file mode 100644
> > > > index 0000000..2be4bd2
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > @@ -0,0 +1,148 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > +
> > > > +maintainers:
> > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > +
> > > > +description: |-
> > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > + sensor output is available via CSI-2 serial data output.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + const: ovti,ov02a10
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + clocks:
> > > > + items:
> > > > + - description: top mux camtg clock
> > > > + - description: devider clock
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: eclk
> > > > + - const: freq_mux
> > > > +
> > > > + clock-frequency:
> > > > + description:
> > > > + Frequency of the eclk clock in Hertz.
> > > > +
> > > > + dovdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as interface power supply.
> > > > +
> > > > + avdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as analog power supply.
> > > > +
> > > > + dvdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as digital power supply.
> > > > +
> > > > + powerdown-gpios:
> > > > + description:
> > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > +
> > > > + reset-gpios:
> > > > + description:
> > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > +
> > > > + rotation:
> > > > + description:
> > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > + allOf:
> > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > + - enum:
> > > > + - 0 # Sensor Mounted Upright
> > > > + - 180 # Sensor Mounted Upside Down
> > > > +
> > > > + ovti,mipi-tx-speed:
> > > > + description:
> > > > + Indication of MIPI transmission speed select.
> > >
> > > What exactly does this signify? And how do you come up with the number?
> > >
> >
> > Apologies for not addressing this number clear.
> >
> > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > the default val: 0x03.
> > The description of this RW register is as below:
> > Bit[2:0]: MIPI transmission speed select.
> >
> > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > This would be fixed in next release.
> >
> > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > that value if there is no setting for this private property in DT.
> > The caller in driver would be updated like this in next release.
> > if (ov02a10->mipi_clock_tx_speed)
> > ret = i2c_smbus_write_byte_data(...,...);
>
> How did you pick the value in the example? And why do you believe it is
> specific to a platform, and not e.g. a sensor mode?
>
We look into P1:0XA1, one register that defines MIPI transmission speed
select.
From the datasheet, we can get the possible values that could be set to
P1:0xA1.
Actually this register is an independent of sensor mode, it is just
included in sensor mode's register setting table.
In addition, this private DT Property is created to fix the MIPI test
failure. The register values are adjusted and verified from vendor to
make sensor signal meet MIPI specification.
> >
> > > > + allOf:
> > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > + - enum: [ 3, 4 ]
> > > > +
> > > > + # See ../video-interfaces.txt for details
> > > > + port:
> > > > + type: object
> > > > + additionalProperties: false
> > > > +
> > > > + properties:
> > > > + endpoint:
> > > > + type: object
> > > > + additionalProperties: false
> > > > +
> > > > + properties:
> > > > + remote-endpoint: true
> > > > + link-frequencies: true
> > > > +
> > > > + required:
> > > > + - endpoint
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - clocks
> > > > + - clock-names
> > > > + - clock-frequency
> > > > + - dovdd-supply
> > > > + - avdd-supply
> > > > + - dvdd-supply
> > > > + - powerdown-gpios
> > > > + - reset-gpios
> > > > + - port
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > + #include <dt-bindings/gpio/gpio.h>
> > > > +
> > > > + i2c {
> > > > + clock-frequency = <400000>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + ov02a10: camera-sensor@3d {
> > > > + compatible = "ovti,ov02a10";
> > > > + reg = <0x3d>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&clk_24m_cam>;
> > > > +
> > > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > > + clock-names = "eclk", "freq_mux";
> > > > + clock-frequency = <24000000>;
> > > > +
> > > > + rotation = <180>;
> > > > + ovti,mipi-tx-speed = <3>;
> > > > +
> > > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > > +
> > > > + port {
> > > > + wcam_out: endpoint {
> > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > + link-frequencies = /bits/ 64 <390000000>;
> > > > + };
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > +...
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index e64e5db..63a2335 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > > S: Maintained
> > > > F: drivers/char/pcmcia/cm4040_cs.*
> > > >
> > > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > +L: linux-media@vger.kernel.org
> > > > +S: Maintained
> > > > +T: git git://linuxtv.org/media_tree.git
> > > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > +
> > > > OMNIVISION OV13858 SENSOR DRIVER
> > > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > L: linux-media@vger.kernel.org
> > >
> >
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 12:58 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-07 12:58 UTC (permalink / raw)
To: Sakari Ailus
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, tfiga, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, louis.kuo, matthias.bgg,
bingbu.cao, matrix.zhu, mchehab, linux-arm-kernel, linux-media
Hi Sakari,
Thanks for the review.
On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > Hi Sakari,
> >
> > Thanks for the review.
> >
> > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > >
> > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > ---
> > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > MAINTAINERS | 7 +
> > > > 2 files changed, 155 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > new file mode 100644
> > > > index 0000000..2be4bd2
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > @@ -0,0 +1,148 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > +
> > > > +maintainers:
> > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > +
> > > > +description: |-
> > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > + sensor output is available via CSI-2 serial data output.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + const: ovti,ov02a10
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + clocks:
> > > > + items:
> > > > + - description: top mux camtg clock
> > > > + - description: devider clock
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: eclk
> > > > + - const: freq_mux
> > > > +
> > > > + clock-frequency:
> > > > + description:
> > > > + Frequency of the eclk clock in Hertz.
> > > > +
> > > > + dovdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as interface power supply.
> > > > +
> > > > + avdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as analog power supply.
> > > > +
> > > > + dvdd-supply:
> > > > + description:
> > > > + Definition of the regulator used as digital power supply.
> > > > +
> > > > + powerdown-gpios:
> > > > + description:
> > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > +
> > > > + reset-gpios:
> > > > + description:
> > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > +
> > > > + rotation:
> > > > + description:
> > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > + allOf:
> > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > + - enum:
> > > > + - 0 # Sensor Mounted Upright
> > > > + - 180 # Sensor Mounted Upside Down
> > > > +
> > > > + ovti,mipi-tx-speed:
> > > > + description:
> > > > + Indication of MIPI transmission speed select.
> > >
> > > What exactly does this signify? And how do you come up with the number?
> > >
> >
> > Apologies for not addressing this number clear.
> >
> > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > the default val: 0x03.
> > The description of this RW register is as below:
> > Bit[2:0]: MIPI transmission speed select.
> >
> > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > This would be fixed in next release.
> >
> > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > that value if there is no setting for this private property in DT.
> > The caller in driver would be updated like this in next release.
> > if (ov02a10->mipi_clock_tx_speed)
> > ret = i2c_smbus_write_byte_data(...,...);
>
> How did you pick the value in the example? And why do you believe it is
> specific to a platform, and not e.g. a sensor mode?
>
We look into P1:0XA1, one register that defines MIPI transmission speed
select.
From the datasheet, we can get the possible values that could be set to
P1:0xA1.
Actually this register is an independent of sensor mode, it is just
included in sensor mode's register setting table.
In addition, this private DT Property is created to fix the MIPI test
failure. The register values are adjusted and verified from vendor to
make sensor signal meet MIPI specification.
> >
> > > > + allOf:
> > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > + - enum: [ 3, 4 ]
> > > > +
> > > > + # See ../video-interfaces.txt for details
> > > > + port:
> > > > + type: object
> > > > + additionalProperties: false
> > > > +
> > > > + properties:
> > > > + endpoint:
> > > > + type: object
> > > > + additionalProperties: false
> > > > +
> > > > + properties:
> > > > + remote-endpoint: true
> > > > + link-frequencies: true
> > > > +
> > > > + required:
> > > > + - endpoint
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - clocks
> > > > + - clock-names
> > > > + - clock-frequency
> > > > + - dovdd-supply
> > > > + - avdd-supply
> > > > + - dvdd-supply
> > > > + - powerdown-gpios
> > > > + - reset-gpios
> > > > + - port
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > + #include <dt-bindings/gpio/gpio.h>
> > > > +
> > > > + i2c {
> > > > + clock-frequency = <400000>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + ov02a10: camera-sensor@3d {
> > > > + compatible = "ovti,ov02a10";
> > > > + reg = <0x3d>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&clk_24m_cam>;
> > > > +
> > > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > > + clock-names = "eclk", "freq_mux";
> > > > + clock-frequency = <24000000>;
> > > > +
> > > > + rotation = <180>;
> > > > + ovti,mipi-tx-speed = <3>;
> > > > +
> > > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > > +
> > > > + port {
> > > > + wcam_out: endpoint {
> > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > + link-frequencies = /bits/ 64 <390000000>;
> > > > + };
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > +...
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index e64e5db..63a2335 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > > S: Maintained
> > > > F: drivers/char/pcmcia/cm4040_cs.*
> > > >
> > > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > +L: linux-media@vger.kernel.org
> > > > +S: Maintained
> > > > +T: git git://linuxtv.org/media_tree.git
> > > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > +
> > > > OMNIVISION OV13858 SENSOR DRIVER
> > > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > L: linux-media@vger.kernel.org
> > >
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-05 16:15 ` Rob Herring
(?)
@ 2020-05-07 13:02 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-07 13:02 UTC (permalink / raw)
To: Rob Herring
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
Hi Rob,
Thanks for the review.
On Tue, 2020-05-05 at 11:15 -0500, Rob Herring wrote:
> On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 155 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..2be4bd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: devider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as interface power supply.
> > +
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as analog power supply.
> > +
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as digital power supply.
> > +
> > + powerdown-gpios:
>
> maxItems: 1
>
Thanks for the reminder, it would be fixed in next release.
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor powerdown.
>
> Can be dropped. Doesn't tell me anything specific to this device.
>
Fixed in next release.
> > +
> > + reset-gpios:
>
> maxItems: 1
>
Same as powerdown-gpios. We would just use maxItems only.
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor reset.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement, valid values are 0 and 180.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum: [ 3, 4 ]
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + remote-endpoint: true
> > + link-frequencies: true
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + clock-frequency = <400000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <3>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + remote-endpoint = <&mipi_in_wcam>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
> > --
> > 2.9.2
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 13:02 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-07 13:02 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, devicetree, andriy.shevchenko, louis.kuo,
srv_heupstream, linus.walleij, shengnan.wang, tfiga,
bgolaszewski, sj.huang, drinkcat, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
Hi Rob,
Thanks for the review.
On Tue, 2020-05-05 at 11:15 -0500, Rob Herring wrote:
> On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 155 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..2be4bd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: devider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as interface power supply.
> > +
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as analog power supply.
> > +
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as digital power supply.
> > +
> > + powerdown-gpios:
>
> maxItems: 1
>
Thanks for the reminder, it would be fixed in next release.
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor powerdown.
>
> Can be dropped. Doesn't tell me anything specific to this device.
>
Fixed in next release.
> > +
> > + reset-gpios:
>
> maxItems: 1
>
Same as powerdown-gpios. We would just use maxItems only.
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor reset.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement, valid values are 0 and 180.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum: [ 3, 4 ]
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + remote-endpoint: true
> > + link-frequencies: true
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + clock-frequency = <400000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <3>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + remote-endpoint = <&mipi_in_wcam>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
> > --
> > 2.9.2
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 13:02 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-07 13:02 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, devicetree, andriy.shevchenko, louis.kuo,
srv_heupstream, linus.walleij, shengnan.wang, tfiga,
bgolaszewski, sj.huang, drinkcat, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
Hi Rob,
Thanks for the review.
On Tue, 2020-05-05 at 11:15 -0500, Rob Herring wrote:
> On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 155 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > new file mode 100644
> > index 0000000..2be4bd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > @@ -0,0 +1,148 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > +
> > +maintainers:
> > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +
> > +description: |-
> > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > + image sensor, which is the latest production derived from Omnivision's CMOS
> > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > + sensor output is available via CSI-2 serial data output.
> > +
> > +properties:
> > + compatible:
> > + const: ovti,ov02a10
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: top mux camtg clock
> > + - description: devider clock
> > +
> > + clock-names:
> > + items:
> > + - const: eclk
> > + - const: freq_mux
> > +
> > + clock-frequency:
> > + description:
> > + Frequency of the eclk clock in Hertz.
> > +
> > + dovdd-supply:
> > + description:
> > + Definition of the regulator used as interface power supply.
> > +
> > + avdd-supply:
> > + description:
> > + Definition of the regulator used as analog power supply.
> > +
> > + dvdd-supply:
> > + description:
> > + Definition of the regulator used as digital power supply.
> > +
> > + powerdown-gpios:
>
> maxItems: 1
>
Thanks for the reminder, it would be fixed in next release.
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor powerdown.
>
> Can be dropped. Doesn't tell me anything specific to this device.
>
Fixed in next release.
> > +
> > + reset-gpios:
>
> maxItems: 1
>
Same as powerdown-gpios. We would just use maxItems only.
> > + description:
> > + The phandle and specifier for the GPIO that controls sensor reset.
> > +
> > + rotation:
> > + description:
> > + Definition of the sensor's placement, valid values are 0 and 180.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum:
> > + - 0 # Sensor Mounted Upright
> > + - 180 # Sensor Mounted Upside Down
> > +
> > + ovti,mipi-tx-speed:
> > + description:
> > + Indication of MIPI transmission speed select.
> > + allOf:
> > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > + - enum: [ 3, 4 ]
> > +
> > + # See ../video-interfaces.txt for details
> > + port:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + endpoint:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + remote-endpoint: true
> > + link-frequencies: true
> > +
> > + required:
> > + - endpoint
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - clock-frequency
> > + - dovdd-supply
> > + - avdd-supply
> > + - dvdd-supply
> > + - powerdown-gpios
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8183-clk.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + clock-frequency = <400000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ov02a10: camera-sensor@3d {
> > + compatible = "ovti,ov02a10";
> > + reg = <0x3d>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&clk_24m_cam>;
> > +
> > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > + clock-names = "eclk", "freq_mux";
> > + clock-frequency = <24000000>;
> > +
> > + rotation = <180>;
> > + ovti,mipi-tx-speed = <3>;
> > +
> > + dovdd-supply = <&mt6358_vcamio_reg>;
> > + avdd-supply = <&mt6358_vcama1_reg>;
> > + dvdd-supply = <&mt6358_vcn18_reg>;
> > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + wcam_out: endpoint {
> > + remote-endpoint = <&mipi_in_wcam>;
> > + link-frequencies = /bits/ 64 <390000000>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e64e5db..63a2335 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > S: Maintained
> > F: drivers/char/pcmcia/cm4040_cs.*
> >
> > +OMNIVISION OV02A10 SENSOR DRIVER
> > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +T: git git://linuxtv.org/media_tree.git
> > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > +
> > OMNIVISION OV13858 SENSOR DRIVER
> > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > L: linux-media@vger.kernel.org
> > --
> > 2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-07 12:58 ` Dongchun Zhu
(?)
@ 2020-05-07 13:50 ` Tomasz Figa
-1 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-05-07 13:50 UTC (permalink / raw)
To: Dongchun Zhu, Sakari Ailus
Cc: Linus Walleij, Bartosz Golaszewski, Mauro Carvalho Chehab,
Andy Shevchenko, Rob Herring, Mark Rutland, Nicolas Boichat,
matrix.zhu, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
Hi Sakari and Dongchun,
On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Sakari,
>
> Thanks for the review.
>
> On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari,
> > >
> > > Thanks for the review.
> > >
> > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > >
> > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > ---
> > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > MAINTAINERS | 7 +
> > > > > 2 files changed, 155 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > new file mode 100644
> > > > > index 0000000..2be4bd2
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > @@ -0,0 +1,148 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > +
> > > > > +maintainers:
> > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > +
> > > > > +description: |-
> > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > + sensor output is available via CSI-2 serial data output.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: ovti,ov02a10
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + clocks:
> > > > > + items:
> > > > > + - description: top mux camtg clock
> > > > > + - description: devider clock
> > > > > +
> > > > > + clock-names:
> > > > > + items:
> > > > > + - const: eclk
> > > > > + - const: freq_mux
> > > > > +
> > > > > + clock-frequency:
> > > > > + description:
> > > > > + Frequency of the eclk clock in Hertz.
> > > > > +
> > > > > + dovdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as interface power supply.
> > > > > +
> > > > > + avdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as analog power supply.
> > > > > +
> > > > > + dvdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as digital power supply.
> > > > > +
> > > > > + powerdown-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > +
> > > > > + reset-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > +
> > > > > + rotation:
> > > > > + description:
> > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > + allOf:
> > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > + - enum:
> > > > > + - 0 # Sensor Mounted Upright
> > > > > + - 180 # Sensor Mounted Upside Down
> > > > > +
> > > > > + ovti,mipi-tx-speed:
> > > > > + description:
> > > > > + Indication of MIPI transmission speed select.
> > > >
> > > > What exactly does this signify? And how do you come up with the number?
> > > >
> > >
> > > Apologies for not addressing this number clear.
> > >
> > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > the default val: 0x03.
> > > The description of this RW register is as below:
> > > Bit[2:0]: MIPI transmission speed select.
> > >
> > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > This would be fixed in next release.
> > >
> > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > that value if there is no setting for this private property in DT.
> > > The caller in driver would be updated like this in next release.
> > > if (ov02a10->mipi_clock_tx_speed)
> > > ret = i2c_smbus_write_byte_data(...,...);
> >
> > How did you pick the value in the example? And why do you believe it is
> > specific to a platform, and not e.g. a sensor mode?
> >
>
> We look into P1:0XA1, one register that defines MIPI transmission speed
> select.
> From the datasheet, we can get the possible values that could be set to
> P1:0xA1.
>
> Actually this register is an independent of sensor mode, it is just
> included in sensor mode's register setting table.
>
> In addition, this private DT Property is created to fix the MIPI test
> failure. The register values are adjusted and verified from vendor to
> make sensor signal meet MIPI specification.
>
In theory the value could depend on the mode, because different link
rate could impose different requirements for the physical interface.
In practice, we haven't seen any hardware that would require different
values for different modes.
Best regards,
Tomasz
> > >
> > > > > + allOf:
> > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > + - enum: [ 3, 4 ]
> > > > > +
> > > > > + # See ../video-interfaces.txt for details
> > > > > + port:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > > > > + endpoint:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > > > > + remote-endpoint: true
> > > > > + link-frequencies: true
> > > > > +
> > > > > + required:
> > > > > + - endpoint
> > > > > +
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - clocks
> > > > > + - clock-names
> > > > > + - clock-frequency
> > > > > + - dovdd-supply
> > > > > + - avdd-supply
> > > > > + - dvdd-supply
> > > > > + - powerdown-gpios
> > > > > + - reset-gpios
> > > > > + - port
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > +
> > > > > + i2c {
> > > > > + clock-frequency = <400000>;
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + ov02a10: camera-sensor@3d {
> > > > > + compatible = "ovti,ov02a10";
> > > > > + reg = <0x3d>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&clk_24m_cam>;
> > > > > +
> > > > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > > > + clock-names = "eclk", "freq_mux";
> > > > > + clock-frequency = <24000000>;
> > > > > +
> > > > > + rotation = <180>;
> > > > > + ovti,mipi-tx-speed = <3>;
> > > > > +
> > > > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > > > +
> > > > > + port {
> > > > > + wcam_out: endpoint {
> > > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > > + link-frequencies = /bits/ 64 <390000000>;
> > > > > + };
> > > > > + };
> > > > > + };
> > > > > + };
> > > > > +
> > > > > +...
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index e64e5db..63a2335 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > > > S: Maintained
> > > > > F: drivers/char/pcmcia/cm4040_cs.*
> > > > >
> > > > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > +L: linux-media@vger.kernel.org
> > > > > +S: Maintained
> > > > > +T: git git://linuxtv.org/media_tree.git
> > > > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > +
> > > > > OMNIVISION OV13858 SENSOR DRIVER
> > > > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > L: linux-media@vger.kernel.org
> > > >
> > >
> >
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 13:50 ` Tomasz Figa
0 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-05-07 13:50 UTC (permalink / raw)
To: Dongchun Zhu, Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari and Dongchun,
On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Sakari,
>
> Thanks for the review.
>
> On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari,
> > >
> > > Thanks for the review.
> > >
> > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > >
> > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > ---
> > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > MAINTAINERS | 7 +
> > > > > 2 files changed, 155 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > new file mode 100644
> > > > > index 0000000..2be4bd2
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > @@ -0,0 +1,148 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > +
> > > > > +maintainers:
> > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > +
> > > > > +description: |-
> > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > + sensor output is available via CSI-2 serial data output.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: ovti,ov02a10
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + clocks:
> > > > > + items:
> > > > > + - description: top mux camtg clock
> > > > > + - description: devider clock
> > > > > +
> > > > > + clock-names:
> > > > > + items:
> > > > > + - const: eclk
> > > > > + - const: freq_mux
> > > > > +
> > > > > + clock-frequency:
> > > > > + description:
> > > > > + Frequency of the eclk clock in Hertz.
> > > > > +
> > > > > + dovdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as interface power supply.
> > > > > +
> > > > > + avdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as analog power supply.
> > > > > +
> > > > > + dvdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as digital power supply.
> > > > > +
> > > > > + powerdown-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > +
> > > > > + reset-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > +
> > > > > + rotation:
> > > > > + description:
> > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > + allOf:
> > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > + - enum:
> > > > > + - 0 # Sensor Mounted Upright
> > > > > + - 180 # Sensor Mounted Upside Down
> > > > > +
> > > > > + ovti,mipi-tx-speed:
> > > > > + description:
> > > > > + Indication of MIPI transmission speed select.
> > > >
> > > > What exactly does this signify? And how do you come up with the number?
> > > >
> > >
> > > Apologies for not addressing this number clear.
> > >
> > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > the default val: 0x03.
> > > The description of this RW register is as below:
> > > Bit[2:0]: MIPI transmission speed select.
> > >
> > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > This would be fixed in next release.
> > >
> > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > that value if there is no setting for this private property in DT.
> > > The caller in driver would be updated like this in next release.
> > > if (ov02a10->mipi_clock_tx_speed)
> > > ret = i2c_smbus_write_byte_data(...,...);
> >
> > How did you pick the value in the example? And why do you believe it is
> > specific to a platform, and not e.g. a sensor mode?
> >
>
> We look into P1:0XA1, one register that defines MIPI transmission speed
> select.
> From the datasheet, we can get the possible values that could be set to
> P1:0xA1.
>
> Actually this register is an independent of sensor mode, it is just
> included in sensor mode's register setting table.
>
> In addition, this private DT Property is created to fix the MIPI test
> failure. The register values are adjusted and verified from vendor to
> make sensor signal meet MIPI specification.
>
In theory the value could depend on the mode, because different link
rate could impose different requirements for the physical interface.
In practice, we haven't seen any hardware that would require different
values for different modes.
Best regards,
Tomasz
> > >
> > > > > + allOf:
> > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > + - enum: [ 3, 4 ]
> > > > > +
> > > > > + # See ../video-interfaces.txt for details
> > > > > + port:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > > > > + endpoint:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > > > > + remote-endpoint: true
> > > > > + link-frequencies: true
> > > > > +
> > > > > + required:
> > > > > + - endpoint
> > > > > +
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - clocks
> > > > > + - clock-names
> > > > > + - clock-frequency
> > > > > + - dovdd-supply
> > > > > + - avdd-supply
> > > > > + - dvdd-supply
> > > > > + - powerdown-gpios
> > > > > + - reset-gpios
> > > > > + - port
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > +
> > > > > + i2c {
> > > > > + clock-frequency = <400000>;
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + ov02a10: camera-sensor@3d {
> > > > > + compatible = "ovti,ov02a10";
> > > > > + reg = <0x3d>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&clk_24m_cam>;
> > > > > +
> > > > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > > > + clock-names = "eclk", "freq_mux";
> > > > > + clock-frequency = <24000000>;
> > > > > +
> > > > > + rotation = <180>;
> > > > > + ovti,mipi-tx-speed = <3>;
> > > > > +
> > > > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > > > +
> > > > > + port {
> > > > > + wcam_out: endpoint {
> > > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > > + link-frequencies = /bits/ 64 <390000000>;
> > > > > + };
> > > > > + };
> > > > > + };
> > > > > + };
> > > > > +
> > > > > +...
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index e64e5db..63a2335 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > > > S: Maintained
> > > > > F: drivers/char/pcmcia/cm4040_cs.*
> > > > >
> > > > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > +L: linux-media@vger.kernel.org
> > > > > +S: Maintained
> > > > > +T: git git://linuxtv.org/media_tree.git
> > > > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > +
> > > > > OMNIVISION OV13858 SENSOR DRIVER
> > > > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > L: linux-media@vger.kernel.org
> > > >
> > >
> >
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 13:50 ` Tomasz Figa
0 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-05-07 13:50 UTC (permalink / raw)
To: Dongchun Zhu, Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari and Dongchun,
On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Sakari,
>
> Thanks for the review.
>
> On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari,
> > >
> > > Thanks for the review.
> > >
> > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > >
> > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > ---
> > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > MAINTAINERS | 7 +
> > > > > 2 files changed, 155 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > new file mode 100644
> > > > > index 0000000..2be4bd2
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > @@ -0,0 +1,148 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > +
> > > > > +maintainers:
> > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > +
> > > > > +description: |-
> > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > + sensor output is available via CSI-2 serial data output.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: ovti,ov02a10
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + clocks:
> > > > > + items:
> > > > > + - description: top mux camtg clock
> > > > > + - description: devider clock
> > > > > +
> > > > > + clock-names:
> > > > > + items:
> > > > > + - const: eclk
> > > > > + - const: freq_mux
> > > > > +
> > > > > + clock-frequency:
> > > > > + description:
> > > > > + Frequency of the eclk clock in Hertz.
> > > > > +
> > > > > + dovdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as interface power supply.
> > > > > +
> > > > > + avdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as analog power supply.
> > > > > +
> > > > > + dvdd-supply:
> > > > > + description:
> > > > > + Definition of the regulator used as digital power supply.
> > > > > +
> > > > > + powerdown-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > +
> > > > > + reset-gpios:
> > > > > + description:
> > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > +
> > > > > + rotation:
> > > > > + description:
> > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > + allOf:
> > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > + - enum:
> > > > > + - 0 # Sensor Mounted Upright
> > > > > + - 180 # Sensor Mounted Upside Down
> > > > > +
> > > > > + ovti,mipi-tx-speed:
> > > > > + description:
> > > > > + Indication of MIPI transmission speed select.
> > > >
> > > > What exactly does this signify? And how do you come up with the number?
> > > >
> > >
> > > Apologies for not addressing this number clear.
> > >
> > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > the default val: 0x03.
> > > The description of this RW register is as below:
> > > Bit[2:0]: MIPI transmission speed select.
> > >
> > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > This would be fixed in next release.
> > >
> > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > that value if there is no setting for this private property in DT.
> > > The caller in driver would be updated like this in next release.
> > > if (ov02a10->mipi_clock_tx_speed)
> > > ret = i2c_smbus_write_byte_data(...,...);
> >
> > How did you pick the value in the example? And why do you believe it is
> > specific to a platform, and not e.g. a sensor mode?
> >
>
> We look into P1:0XA1, one register that defines MIPI transmission speed
> select.
> From the datasheet, we can get the possible values that could be set to
> P1:0xA1.
>
> Actually this register is an independent of sensor mode, it is just
> included in sensor mode's register setting table.
>
> In addition, this private DT Property is created to fix the MIPI test
> failure. The register values are adjusted and verified from vendor to
> make sensor signal meet MIPI specification.
>
In theory the value could depend on the mode, because different link
rate could impose different requirements for the physical interface.
In practice, we haven't seen any hardware that would require different
values for different modes.
Best regards,
Tomasz
> > >
> > > > > + allOf:
> > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > + - enum: [ 3, 4 ]
> > > > > +
> > > > > + # See ../video-interfaces.txt for details
> > > > > + port:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > > > > + endpoint:
> > > > > + type: object
> > > > > + additionalProperties: false
> > > > > +
> > > > > + properties:
> > > > > + remote-endpoint: true
> > > > > + link-frequencies: true
> > > > > +
> > > > > + required:
> > > > > + - endpoint
> > > > > +
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - clocks
> > > > > + - clock-names
> > > > > + - clock-frequency
> > > > > + - dovdd-supply
> > > > > + - avdd-supply
> > > > > + - dvdd-supply
> > > > > + - powerdown-gpios
> > > > > + - reset-gpios
> > > > > + - port
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > +
> > > > > + i2c {
> > > > > + clock-frequency = <400000>;
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + ov02a10: camera-sensor@3d {
> > > > > + compatible = "ovti,ov02a10";
> > > > > + reg = <0x3d>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&clk_24m_cam>;
> > > > > +
> > > > > + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> > > > > + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> > > > > + clock-names = "eclk", "freq_mux";
> > > > > + clock-frequency = <24000000>;
> > > > > +
> > > > > + rotation = <180>;
> > > > > + ovti,mipi-tx-speed = <3>;
> > > > > +
> > > > > + dovdd-supply = <&mt6358_vcamio_reg>;
> > > > > + avdd-supply = <&mt6358_vcama1_reg>;
> > > > > + dvdd-supply = <&mt6358_vcn18_reg>;
> > > > > + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> > > > > + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> > > > > +
> > > > > + port {
> > > > > + wcam_out: endpoint {
> > > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > > + link-frequencies = /bits/ 64 <390000000>;
> > > > > + };
> > > > > + };
> > > > > + };
> > > > > + };
> > > > > +
> > > > > +...
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index e64e5db..63a2335 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> > > > > S: Maintained
> > > > > F: drivers/char/pcmcia/cm4040_cs.*
> > > > >
> > > > > +OMNIVISION OV02A10 SENSOR DRIVER
> > > > > +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > +L: linux-media@vger.kernel.org
> > > > > +S: Maintained
> > > > > +T: git git://linuxtv.org/media_tree.git
> > > > > +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > +
> > > > > OMNIVISION OV13858 SENSOR DRIVER
> > > > > M: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > L: linux-media@vger.kernel.org
> > > >
> > >
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-07 13:50 ` Tomasz Figa
(?)
@ 2020-05-07 14:11 ` Sakari Ailus
-1 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-07 14:11 UTC (permalink / raw)
To: Tomasz Figa
Cc: Dongchun Zhu, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
Hi Tomasz, Dongchun,
On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> Hi Sakari and Dongchun,
>
> On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Sakari,
> >
> > Thanks for the review.
> >
> > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > >
> > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > ---
> > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > MAINTAINERS | 7 +
> > > > > > 2 files changed, 155 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000..2be4bd2
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > @@ -0,0 +1,148 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > +
> > > > > > +maintainers:
> > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > +
> > > > > > +description: |-
> > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > +
> > > > > > +properties:
> > > > > > + compatible:
> > > > > > + const: ovti,ov02a10
> > > > > > +
> > > > > > + reg:
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + clocks:
> > > > > > + items:
> > > > > > + - description: top mux camtg clock
> > > > > > + - description: devider clock
> > > > > > +
> > > > > > + clock-names:
> > > > > > + items:
> > > > > > + - const: eclk
> > > > > > + - const: freq_mux
> > > > > > +
> > > > > > + clock-frequency:
> > > > > > + description:
> > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > +
> > > > > > + dovdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as interface power supply.
> > > > > > +
> > > > > > + avdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as analog power supply.
> > > > > > +
> > > > > > + dvdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as digital power supply.
> > > > > > +
> > > > > > + powerdown-gpios:
> > > > > > + description:
> > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > +
> > > > > > + reset-gpios:
> > > > > > + description:
> > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > +
> > > > > > + rotation:
> > > > > > + description:
> > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > + allOf:
> > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > + - enum:
> > > > > > + - 0 # Sensor Mounted Upright
> > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > +
> > > > > > + ovti,mipi-tx-speed:
> > > > > > + description:
> > > > > > + Indication of MIPI transmission speed select.
> > > > >
> > > > > What exactly does this signify? And how do you come up with the number?
> > > > >
> > > >
> > > > Apologies for not addressing this number clear.
> > > >
> > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > the default val: 0x03.
> > > > The description of this RW register is as below:
> > > > Bit[2:0]: MIPI transmission speed select.
> > > >
> > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > This would be fixed in next release.
> > > >
> > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > that value if there is no setting for this private property in DT.
> > > > The caller in driver would be updated like this in next release.
> > > > if (ov02a10->mipi_clock_tx_speed)
> > > > ret = i2c_smbus_write_byte_data(...,...);
> > >
> > > How did you pick the value in the example? And why do you believe it is
> > > specific to a platform, and not e.g. a sensor mode?
> > >
> >
> > We look into P1:0XA1, one register that defines MIPI transmission speed
> > select.
> > From the datasheet, we can get the possible values that could be set to
> > P1:0xA1.
> >
> > Actually this register is an independent of sensor mode, it is just
> > included in sensor mode's register setting table.
> >
> > In addition, this private DT Property is created to fix the MIPI test
> > failure. The register values are adjusted and verified from vendor to
> > make sensor signal meet MIPI specification.
> >
>
> In theory the value could depend on the mode, because different link
> rate could impose different requirements for the physical interface.
> In practice, we haven't seen any hardware that would require different
> values for different modes.
The mode (possibly in conjunction with other information available to the
driver via V4L2 fwnode interface) precisely defines the parameters of the
CSI-2 bus --- apart from the possible exception of the bus timing related
parameters but this is not supported by the name of the parameter.
Therefore I don't see how this parameter, which supposedly is used to
determine the CSI-2 transmissions speed, could be board specific and thus
belong to DT.
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 14:11 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-07 14:11 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Tomasz, Dongchun,
On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> Hi Sakari and Dongchun,
>
> On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Sakari,
> >
> > Thanks for the review.
> >
> > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > >
> > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > ---
> > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > MAINTAINERS | 7 +
> > > > > > 2 files changed, 155 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000..2be4bd2
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > @@ -0,0 +1,148 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > +
> > > > > > +maintainers:
> > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > +
> > > > > > +description: |-
> > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > +
> > > > > > +properties:
> > > > > > + compatible:
> > > > > > + const: ovti,ov02a10
> > > > > > +
> > > > > > + reg:
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + clocks:
> > > > > > + items:
> > > > > > + - description: top mux camtg clock
> > > > > > + - description: devider clock
> > > > > > +
> > > > > > + clock-names:
> > > > > > + items:
> > > > > > + - const: eclk
> > > > > > + - const: freq_mux
> > > > > > +
> > > > > > + clock-frequency:
> > > > > > + description:
> > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > +
> > > > > > + dovdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as interface power supply.
> > > > > > +
> > > > > > + avdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as analog power supply.
> > > > > > +
> > > > > > + dvdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as digital power supply.
> > > > > > +
> > > > > > + powerdown-gpios:
> > > > > > + description:
> > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > +
> > > > > > + reset-gpios:
> > > > > > + description:
> > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > +
> > > > > > + rotation:
> > > > > > + description:
> > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > + allOf:
> > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > + - enum:
> > > > > > + - 0 # Sensor Mounted Upright
> > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > +
> > > > > > + ovti,mipi-tx-speed:
> > > > > > + description:
> > > > > > + Indication of MIPI transmission speed select.
> > > > >
> > > > > What exactly does this signify? And how do you come up with the number?
> > > > >
> > > >
> > > > Apologies for not addressing this number clear.
> > > >
> > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > the default val: 0x03.
> > > > The description of this RW register is as below:
> > > > Bit[2:0]: MIPI transmission speed select.
> > > >
> > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > This would be fixed in next release.
> > > >
> > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > that value if there is no setting for this private property in DT.
> > > > The caller in driver would be updated like this in next release.
> > > > if (ov02a10->mipi_clock_tx_speed)
> > > > ret = i2c_smbus_write_byte_data(...,...);
> > >
> > > How did you pick the value in the example? And why do you believe it is
> > > specific to a platform, and not e.g. a sensor mode?
> > >
> >
> > We look into P1:0XA1, one register that defines MIPI transmission speed
> > select.
> > From the datasheet, we can get the possible values that could be set to
> > P1:0xA1.
> >
> > Actually this register is an independent of sensor mode, it is just
> > included in sensor mode's register setting table.
> >
> > In addition, this private DT Property is created to fix the MIPI test
> > failure. The register values are adjusted and verified from vendor to
> > make sensor signal meet MIPI specification.
> >
>
> In theory the value could depend on the mode, because different link
> rate could impose different requirements for the physical interface.
> In practice, we haven't seen any hardware that would require different
> values for different modes.
The mode (possibly in conjunction with other information available to the
driver via V4L2 fwnode interface) precisely defines the parameters of the
CSI-2 bus --- apart from the possible exception of the bus timing related
parameters but this is not supported by the name of the parameter.
Therefore I don't see how this parameter, which supposedly is used to
determine the CSI-2 transmissions speed, could be board specific and thus
belong to DT.
--
Kind regards,
Sakari Ailus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 14:11 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-07 14:11 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Tomasz, Dongchun,
On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> Hi Sakari and Dongchun,
>
> On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Sakari,
> >
> > Thanks for the review.
> >
> > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > >
> > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > ---
> > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > MAINTAINERS | 7 +
> > > > > > 2 files changed, 155 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000..2be4bd2
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > @@ -0,0 +1,148 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > +
> > > > > > +maintainers:
> > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > +
> > > > > > +description: |-
> > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > +
> > > > > > +properties:
> > > > > > + compatible:
> > > > > > + const: ovti,ov02a10
> > > > > > +
> > > > > > + reg:
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + clocks:
> > > > > > + items:
> > > > > > + - description: top mux camtg clock
> > > > > > + - description: devider clock
> > > > > > +
> > > > > > + clock-names:
> > > > > > + items:
> > > > > > + - const: eclk
> > > > > > + - const: freq_mux
> > > > > > +
> > > > > > + clock-frequency:
> > > > > > + description:
> > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > +
> > > > > > + dovdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as interface power supply.
> > > > > > +
> > > > > > + avdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as analog power supply.
> > > > > > +
> > > > > > + dvdd-supply:
> > > > > > + description:
> > > > > > + Definition of the regulator used as digital power supply.
> > > > > > +
> > > > > > + powerdown-gpios:
> > > > > > + description:
> > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > +
> > > > > > + reset-gpios:
> > > > > > + description:
> > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > +
> > > > > > + rotation:
> > > > > > + description:
> > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > + allOf:
> > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > + - enum:
> > > > > > + - 0 # Sensor Mounted Upright
> > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > +
> > > > > > + ovti,mipi-tx-speed:
> > > > > > + description:
> > > > > > + Indication of MIPI transmission speed select.
> > > > >
> > > > > What exactly does this signify? And how do you come up with the number?
> > > > >
> > > >
> > > > Apologies for not addressing this number clear.
> > > >
> > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > the default val: 0x03.
> > > > The description of this RW register is as below:
> > > > Bit[2:0]: MIPI transmission speed select.
> > > >
> > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > This would be fixed in next release.
> > > >
> > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > that value if there is no setting for this private property in DT.
> > > > The caller in driver would be updated like this in next release.
> > > > if (ov02a10->mipi_clock_tx_speed)
> > > > ret = i2c_smbus_write_byte_data(...,...);
> > >
> > > How did you pick the value in the example? And why do you believe it is
> > > specific to a platform, and not e.g. a sensor mode?
> > >
> >
> > We look into P1:0XA1, one register that defines MIPI transmission speed
> > select.
> > From the datasheet, we can get the possible values that could be set to
> > P1:0xA1.
> >
> > Actually this register is an independent of sensor mode, it is just
> > included in sensor mode's register setting table.
> >
> > In addition, this private DT Property is created to fix the MIPI test
> > failure. The register values are adjusted and verified from vendor to
> > make sensor signal meet MIPI specification.
> >
>
> In theory the value could depend on the mode, because different link
> rate could impose different requirements for the physical interface.
> In practice, we haven't seen any hardware that would require different
> values for different modes.
The mode (possibly in conjunction with other information available to the
driver via V4L2 fwnode interface) precisely defines the parameters of the
CSI-2 bus --- apart from the possible exception of the bus timing related
parameters but this is not supported by the name of the parameter.
Therefore I don't see how this parameter, which supposedly is used to
determine the CSI-2 transmissions speed, could be board specific and thus
belong to DT.
--
Kind regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-07 14:11 ` Sakari Ailus
(?)
@ 2020-05-07 14:25 ` Tomasz Figa
-1 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-05-07 14:25 UTC (permalink / raw)
To: Sakari Ailus
Cc: Dongchun Zhu, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Tomasz, Dongchun,
>
> On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > Hi Sakari and Dongchun,
> >
> > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Sakari,
> > >
> > > Thanks for the review.
> > >
> > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > >
> > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > ---
> > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > MAINTAINERS | 7 +
> > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000..2be4bd2
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > @@ -0,0 +1,148 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > +
> > > > > > > +description: |-
> > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > + compatible:
> > > > > > > + const: ovti,ov02a10
> > > > > > > +
> > > > > > > + reg:
> > > > > > > + maxItems: 1
> > > > > > > +
> > > > > > > + clocks:
> > > > > > > + items:
> > > > > > > + - description: top mux camtg clock
> > > > > > > + - description: devider clock
> > > > > > > +
> > > > > > > + clock-names:
> > > > > > > + items:
> > > > > > > + - const: eclk
> > > > > > > + - const: freq_mux
> > > > > > > +
> > > > > > > + clock-frequency:
> > > > > > > + description:
> > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > +
> > > > > > > + dovdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > +
> > > > > > > + avdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > +
> > > > > > > + dvdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > +
> > > > > > > + powerdown-gpios:
> > > > > > > + description:
> > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > +
> > > > > > > + reset-gpios:
> > > > > > > + description:
> > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > +
> > > > > > > + rotation:
> > > > > > > + description:
> > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > + allOf:
> > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > + - enum:
> > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > +
> > > > > > > + ovti,mipi-tx-speed:
> > > > > > > + description:
> > > > > > > + Indication of MIPI transmission speed select.
> > > > > >
> > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > >
> > > > >
> > > > > Apologies for not addressing this number clear.
> > > > >
> > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > the default val: 0x03.
> > > > > The description of this RW register is as below:
> > > > > Bit[2:0]: MIPI transmission speed select.
> > > > >
> > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > This would be fixed in next release.
> > > > >
> > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > that value if there is no setting for this private property in DT.
> > > > > The caller in driver would be updated like this in next release.
> > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > >
> > > > How did you pick the value in the example? And why do you believe it is
> > > > specific to a platform, and not e.g. a sensor mode?
> > > >
> > >
> > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > select.
> > > From the datasheet, we can get the possible values that could be set to
> > > P1:0xA1.
> > >
> > > Actually this register is an independent of sensor mode, it is just
> > > included in sensor mode's register setting table.
> > >
> > > In addition, this private DT Property is created to fix the MIPI test
> > > failure. The register values are adjusted and verified from vendor to
> > > make sensor signal meet MIPI specification.
> > >
> >
> > In theory the value could depend on the mode, because different link
> > rate could impose different requirements for the physical interface.
> > In practice, we haven't seen any hardware that would require different
> > values for different modes.
>
> The mode (possibly in conjunction with other information available to the
> driver via V4L2 fwnode interface) precisely defines the parameters of the
> CSI-2 bus --- apart from the possible exception of the bus timing related
> parameters but this is not supported by the name of the parameter.
>
> Therefore I don't see how this parameter, which supposedly is used to
> determine the CSI-2 transmissions speed, could be board specific and thus
> belong to DT.
According to the very imprecise information I have access to, it is
not about the CSI-2 bus itself, but rather some internal parameter of
the sensor's CSI interface. Unfortunately there isn't much information
on what this value exactly controls...
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 14:25 ` Tomasz Figa
0 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-05-07 14:25 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Tomasz, Dongchun,
>
> On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > Hi Sakari and Dongchun,
> >
> > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Sakari,
> > >
> > > Thanks for the review.
> > >
> > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > >
> > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > ---
> > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > MAINTAINERS | 7 +
> > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000..2be4bd2
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > @@ -0,0 +1,148 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > +
> > > > > > > +description: |-
> > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > + compatible:
> > > > > > > + const: ovti,ov02a10
> > > > > > > +
> > > > > > > + reg:
> > > > > > > + maxItems: 1
> > > > > > > +
> > > > > > > + clocks:
> > > > > > > + items:
> > > > > > > + - description: top mux camtg clock
> > > > > > > + - description: devider clock
> > > > > > > +
> > > > > > > + clock-names:
> > > > > > > + items:
> > > > > > > + - const: eclk
> > > > > > > + - const: freq_mux
> > > > > > > +
> > > > > > > + clock-frequency:
> > > > > > > + description:
> > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > +
> > > > > > > + dovdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > +
> > > > > > > + avdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > +
> > > > > > > + dvdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > +
> > > > > > > + powerdown-gpios:
> > > > > > > + description:
> > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > +
> > > > > > > + reset-gpios:
> > > > > > > + description:
> > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > +
> > > > > > > + rotation:
> > > > > > > + description:
> > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > + allOf:
> > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > + - enum:
> > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > +
> > > > > > > + ovti,mipi-tx-speed:
> > > > > > > + description:
> > > > > > > + Indication of MIPI transmission speed select.
> > > > > >
> > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > >
> > > > >
> > > > > Apologies for not addressing this number clear.
> > > > >
> > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > the default val: 0x03.
> > > > > The description of this RW register is as below:
> > > > > Bit[2:0]: MIPI transmission speed select.
> > > > >
> > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > This would be fixed in next release.
> > > > >
> > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > that value if there is no setting for this private property in DT.
> > > > > The caller in driver would be updated like this in next release.
> > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > >
> > > > How did you pick the value in the example? And why do you believe it is
> > > > specific to a platform, and not e.g. a sensor mode?
> > > >
> > >
> > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > select.
> > > From the datasheet, we can get the possible values that could be set to
> > > P1:0xA1.
> > >
> > > Actually this register is an independent of sensor mode, it is just
> > > included in sensor mode's register setting table.
> > >
> > > In addition, this private DT Property is created to fix the MIPI test
> > > failure. The register values are adjusted and verified from vendor to
> > > make sensor signal meet MIPI specification.
> > >
> >
> > In theory the value could depend on the mode, because different link
> > rate could impose different requirements for the physical interface.
> > In practice, we haven't seen any hardware that would require different
> > values for different modes.
>
> The mode (possibly in conjunction with other information available to the
> driver via V4L2 fwnode interface) precisely defines the parameters of the
> CSI-2 bus --- apart from the possible exception of the bus timing related
> parameters but this is not supported by the name of the parameter.
>
> Therefore I don't see how this parameter, which supposedly is used to
> determine the CSI-2 transmissions speed, could be board specific and thus
> belong to DT.
According to the very imprecise information I have access to, it is
not about the CSI-2 bus itself, but rather some internal parameter of
the sensor's CSI interface. Unfortunately there isn't much information
on what this value exactly controls...
Best regards,
Tomasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-07 14:25 ` Tomasz Figa
0 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-05-07 14:25 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Tomasz, Dongchun,
>
> On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > Hi Sakari and Dongchun,
> >
> > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Sakari,
> > >
> > > Thanks for the review.
> > >
> > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > >
> > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > ---
> > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > MAINTAINERS | 7 +
> > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > new file mode 100644
> > > > > > > index 0000000..2be4bd2
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > @@ -0,0 +1,148 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > +
> > > > > > > +description: |-
> > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > +
> > > > > > > +properties:
> > > > > > > + compatible:
> > > > > > > + const: ovti,ov02a10
> > > > > > > +
> > > > > > > + reg:
> > > > > > > + maxItems: 1
> > > > > > > +
> > > > > > > + clocks:
> > > > > > > + items:
> > > > > > > + - description: top mux camtg clock
> > > > > > > + - description: devider clock
> > > > > > > +
> > > > > > > + clock-names:
> > > > > > > + items:
> > > > > > > + - const: eclk
> > > > > > > + - const: freq_mux
> > > > > > > +
> > > > > > > + clock-frequency:
> > > > > > > + description:
> > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > +
> > > > > > > + dovdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > +
> > > > > > > + avdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > +
> > > > > > > + dvdd-supply:
> > > > > > > + description:
> > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > +
> > > > > > > + powerdown-gpios:
> > > > > > > + description:
> > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > +
> > > > > > > + reset-gpios:
> > > > > > > + description:
> > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > +
> > > > > > > + rotation:
> > > > > > > + description:
> > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > + allOf:
> > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > + - enum:
> > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > +
> > > > > > > + ovti,mipi-tx-speed:
> > > > > > > + description:
> > > > > > > + Indication of MIPI transmission speed select.
> > > > > >
> > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > >
> > > > >
> > > > > Apologies for not addressing this number clear.
> > > > >
> > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > the default val: 0x03.
> > > > > The description of this RW register is as below:
> > > > > Bit[2:0]: MIPI transmission speed select.
> > > > >
> > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > This would be fixed in next release.
> > > > >
> > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > that value if there is no setting for this private property in DT.
> > > > > The caller in driver would be updated like this in next release.
> > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > >
> > > > How did you pick the value in the example? And why do you believe it is
> > > > specific to a platform, and not e.g. a sensor mode?
> > > >
> > >
> > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > select.
> > > From the datasheet, we can get the possible values that could be set to
> > > P1:0xA1.
> > >
> > > Actually this register is an independent of sensor mode, it is just
> > > included in sensor mode's register setting table.
> > >
> > > In addition, this private DT Property is created to fix the MIPI test
> > > failure. The register values are adjusted and verified from vendor to
> > > make sensor signal meet MIPI specification.
> > >
> >
> > In theory the value could depend on the mode, because different link
> > rate could impose different requirements for the physical interface.
> > In practice, we haven't seen any hardware that would require different
> > values for different modes.
>
> The mode (possibly in conjunction with other information available to the
> driver via V4L2 fwnode interface) precisely defines the parameters of the
> CSI-2 bus --- apart from the possible exception of the bus timing related
> parameters but this is not supported by the name of the parameter.
>
> Therefore I don't see how this parameter, which supposedly is used to
> determine the CSI-2 transmissions speed, could be board specific and thus
> belong to DT.
According to the very imprecise information I have access to, it is
not about the CSI-2 bus itself, but rather some internal parameter of
the sensor's CSI interface. Unfortunately there isn't much information
on what this value exactly controls...
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-07 14:25 ` Tomasz Figa
(?)
@ 2020-05-08 6:51 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-08 6:51 UTC (permalink / raw)
To: Tomasz Figa
Cc: Sakari Ailus, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
Hi Sakari, Tomasz,
On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Tomasz, Dongchun,
> >
> > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > Hi Sakari and Dongchun,
> > >
> > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Sakari,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > Hi Dongchun,
> > > > > > >
> > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > >
> > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > ---
> > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > MAINTAINERS | 7 +
> > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > >
> > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > new file mode 100644
> > > > > > > > index 0000000..2be4bd2
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > +%YAML 1.2
> > > > > > > > +---
> > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > +
> > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > +
> > > > > > > > +maintainers:
> > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > +
> > > > > > > > +description: |-
> > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > +
> > > > > > > > +properties:
> > > > > > > > + compatible:
> > > > > > > > + const: ovti,ov02a10
> > > > > > > > +
> > > > > > > > + reg:
> > > > > > > > + maxItems: 1
> > > > > > > > +
> > > > > > > > + clocks:
> > > > > > > > + items:
> > > > > > > > + - description: top mux camtg clock
> > > > > > > > + - description: devider clock
> > > > > > > > +
> > > > > > > > + clock-names:
> > > > > > > > + items:
> > > > > > > > + - const: eclk
> > > > > > > > + - const: freq_mux
> > > > > > > > +
> > > > > > > > + clock-frequency:
> > > > > > > > + description:
> > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > +
> > > > > > > > + dovdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > +
> > > > > > > > + avdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > +
> > > > > > > > + dvdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > +
> > > > > > > > + powerdown-gpios:
> > > > > > > > + description:
> > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > +
> > > > > > > > + reset-gpios:
> > > > > > > > + description:
> > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > +
> > > > > > > > + rotation:
> > > > > > > > + description:
> > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > + allOf:
> > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > + - enum:
> > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > +
> > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > + description:
> > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > >
> > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > >
> > > > > >
> > > > > > Apologies for not addressing this number clear.
> > > > > >
> > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > the default val: 0x03.
> > > > > > The description of this RW register is as below:
> > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > >
> > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > This would be fixed in next release.
> > > > > >
> > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > that value if there is no setting for this private property in DT.
> > > > > > The caller in driver would be updated like this in next release.
> > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > >
> > > > > How did you pick the value in the example? And why do you believe it is
> > > > > specific to a platform, and not e.g. a sensor mode?
> > > > >
> > > >
> > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > select.
> > > > From the datasheet, we can get the possible values that could be set to
> > > > P1:0xA1.
> > > >
> > > > Actually this register is an independent of sensor mode, it is just
> > > > included in sensor mode's register setting table.
> > > >
> > > > In addition, this private DT Property is created to fix the MIPI test
> > > > failure. The register values are adjusted and verified from vendor to
> > > > make sensor signal meet MIPI specification.
> > > >
> > >
> > > In theory the value could depend on the mode, because different link
> > > rate could impose different requirements for the physical interface.
> > > In practice, we haven't seen any hardware that would require different
> > > values for different modes.
> >
> > The mode (possibly in conjunction with other information available to the
> > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > CSI-2 bus --- apart from the possible exception of the bus timing related
> > parameters but this is not supported by the name of the parameter.
> >
> > Therefore I don't see how this parameter, which supposedly is used to
> > determine the CSI-2 transmissions speed, could be board specific and thus
> > belong to DT.
>
> According to the very imprecise information I have access to, it is
> not about the CSI-2 bus itself, but rather some internal parameter of
> the sensor's CSI interface. Unfortunately there isn't much information
> on what this value exactly controls...
>
> Best regards,
> Tomasz
Just got some feedback from OV vendor about this parameter.
P1:0xA1 is the register to control D-PHY timing setting based on bclk.
It is to adjust the MIPI clock voltage to improve the clock drive
capability, and has no affect on the transmission speed of MIPI data.
From vendor's perspective, P1:0xA1 depends upon the length of FPC of
camera module that used on the board. Considering the physical
connections for MIPI signals to user-facing camera are very different
between our 2 projects, it can be very difficult to find universal SI
parameters for both projects.
Thus here we create one new DT property to separate these tuning in
driver, to be more like project-specific.
More details about the register is as below.
P1:0xA1 val: 0x03 default
Case: 0 20MHz-30MHz
1 30MHz-50MHz
2 50MHz-75MHz
3 75MHz-100MHz (default, old DB setting use)
4 100MHz-130MHz (suggested, new DB setting use)
5 Manual
So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
setting. We would adjust the register in next release.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-08 6:51 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-08 6:51 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Louis Kuo, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari, Tomasz,
On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Tomasz, Dongchun,
> >
> > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > Hi Sakari and Dongchun,
> > >
> > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Sakari,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > Hi Dongchun,
> > > > > > >
> > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > >
> > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > ---
> > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > MAINTAINERS | 7 +
> > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > >
> > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > new file mode 100644
> > > > > > > > index 0000000..2be4bd2
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > +%YAML 1.2
> > > > > > > > +---
> > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > +
> > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > +
> > > > > > > > +maintainers:
> > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > +
> > > > > > > > +description: |-
> > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > +
> > > > > > > > +properties:
> > > > > > > > + compatible:
> > > > > > > > + const: ovti,ov02a10
> > > > > > > > +
> > > > > > > > + reg:
> > > > > > > > + maxItems: 1
> > > > > > > > +
> > > > > > > > + clocks:
> > > > > > > > + items:
> > > > > > > > + - description: top mux camtg clock
> > > > > > > > + - description: devider clock
> > > > > > > > +
> > > > > > > > + clock-names:
> > > > > > > > + items:
> > > > > > > > + - const: eclk
> > > > > > > > + - const: freq_mux
> > > > > > > > +
> > > > > > > > + clock-frequency:
> > > > > > > > + description:
> > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > +
> > > > > > > > + dovdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > +
> > > > > > > > + avdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > +
> > > > > > > > + dvdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > +
> > > > > > > > + powerdown-gpios:
> > > > > > > > + description:
> > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > +
> > > > > > > > + reset-gpios:
> > > > > > > > + description:
> > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > +
> > > > > > > > + rotation:
> > > > > > > > + description:
> > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > + allOf:
> > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > + - enum:
> > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > +
> > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > + description:
> > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > >
> > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > >
> > > > > >
> > > > > > Apologies for not addressing this number clear.
> > > > > >
> > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > the default val: 0x03.
> > > > > > The description of this RW register is as below:
> > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > >
> > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > This would be fixed in next release.
> > > > > >
> > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > that value if there is no setting for this private property in DT.
> > > > > > The caller in driver would be updated like this in next release.
> > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > >
> > > > > How did you pick the value in the example? And why do you believe it is
> > > > > specific to a platform, and not e.g. a sensor mode?
> > > > >
> > > >
> > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > select.
> > > > From the datasheet, we can get the possible values that could be set to
> > > > P1:0xA1.
> > > >
> > > > Actually this register is an independent of sensor mode, it is just
> > > > included in sensor mode's register setting table.
> > > >
> > > > In addition, this private DT Property is created to fix the MIPI test
> > > > failure. The register values are adjusted and verified from vendor to
> > > > make sensor signal meet MIPI specification.
> > > >
> > >
> > > In theory the value could depend on the mode, because different link
> > > rate could impose different requirements for the physical interface.
> > > In practice, we haven't seen any hardware that would require different
> > > values for different modes.
> >
> > The mode (possibly in conjunction with other information available to the
> > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > CSI-2 bus --- apart from the possible exception of the bus timing related
> > parameters but this is not supported by the name of the parameter.
> >
> > Therefore I don't see how this parameter, which supposedly is used to
> > determine the CSI-2 transmissions speed, could be board specific and thus
> > belong to DT.
>
> According to the very imprecise information I have access to, it is
> not about the CSI-2 bus itself, but rather some internal parameter of
> the sensor's CSI interface. Unfortunately there isn't much information
> on what this value exactly controls...
>
> Best regards,
> Tomasz
Just got some feedback from OV vendor about this parameter.
P1:0xA1 is the register to control D-PHY timing setting based on bclk.
It is to adjust the MIPI clock voltage to improve the clock drive
capability, and has no affect on the transmission speed of MIPI data.
From vendor's perspective, P1:0xA1 depends upon the length of FPC of
camera module that used on the board. Considering the physical
connections for MIPI signals to user-facing camera are very different
between our 2 projects, it can be very difficult to find universal SI
parameters for both projects.
Thus here we create one new DT property to separate these tuning in
driver, to be more like project-specific.
More details about the register is as below.
P1:0xA1 val: 0x03 default
Case: 0 20MHz-30MHz
1 30MHz-50MHz
2 50MHz-75MHz
3 75MHz-100MHz (default, old DB setting use)
4 100MHz-130MHz (suggested, new DB setting use)
5 Manual
So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
setting. We would adjust the register in next release.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-08 6:51 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-08 6:51 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Louis Kuo, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari, Tomasz,
On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Tomasz, Dongchun,
> >
> > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > Hi Sakari and Dongchun,
> > >
> > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Sakari,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > Hi Dongchun,
> > > > > > >
> > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > >
> > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > ---
> > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > MAINTAINERS | 7 +
> > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > >
> > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > new file mode 100644
> > > > > > > > index 0000000..2be4bd2
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > +%YAML 1.2
> > > > > > > > +---
> > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > +
> > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > +
> > > > > > > > +maintainers:
> > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > +
> > > > > > > > +description: |-
> > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > +
> > > > > > > > +properties:
> > > > > > > > + compatible:
> > > > > > > > + const: ovti,ov02a10
> > > > > > > > +
> > > > > > > > + reg:
> > > > > > > > + maxItems: 1
> > > > > > > > +
> > > > > > > > + clocks:
> > > > > > > > + items:
> > > > > > > > + - description: top mux camtg clock
> > > > > > > > + - description: devider clock
> > > > > > > > +
> > > > > > > > + clock-names:
> > > > > > > > + items:
> > > > > > > > + - const: eclk
> > > > > > > > + - const: freq_mux
> > > > > > > > +
> > > > > > > > + clock-frequency:
> > > > > > > > + description:
> > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > +
> > > > > > > > + dovdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > +
> > > > > > > > + avdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > +
> > > > > > > > + dvdd-supply:
> > > > > > > > + description:
> > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > +
> > > > > > > > + powerdown-gpios:
> > > > > > > > + description:
> > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > +
> > > > > > > > + reset-gpios:
> > > > > > > > + description:
> > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > +
> > > > > > > > + rotation:
> > > > > > > > + description:
> > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > + allOf:
> > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > + - enum:
> > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > +
> > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > + description:
> > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > >
> > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > >
> > > > > >
> > > > > > Apologies for not addressing this number clear.
> > > > > >
> > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > the default val: 0x03.
> > > > > > The description of this RW register is as below:
> > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > >
> > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > This would be fixed in next release.
> > > > > >
> > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > that value if there is no setting for this private property in DT.
> > > > > > The caller in driver would be updated like this in next release.
> > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > >
> > > > > How did you pick the value in the example? And why do you believe it is
> > > > > specific to a platform, and not e.g. a sensor mode?
> > > > >
> > > >
> > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > select.
> > > > From the datasheet, we can get the possible values that could be set to
> > > > P1:0xA1.
> > > >
> > > > Actually this register is an independent of sensor mode, it is just
> > > > included in sensor mode's register setting table.
> > > >
> > > > In addition, this private DT Property is created to fix the MIPI test
> > > > failure. The register values are adjusted and verified from vendor to
> > > > make sensor signal meet MIPI specification.
> > > >
> > >
> > > In theory the value could depend on the mode, because different link
> > > rate could impose different requirements for the physical interface.
> > > In practice, we haven't seen any hardware that would require different
> > > values for different modes.
> >
> > The mode (possibly in conjunction with other information available to the
> > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > CSI-2 bus --- apart from the possible exception of the bus timing related
> > parameters but this is not supported by the name of the parameter.
> >
> > Therefore I don't see how this parameter, which supposedly is used to
> > determine the CSI-2 transmissions speed, could be board specific and thus
> > belong to DT.
>
> According to the very imprecise information I have access to, it is
> not about the CSI-2 bus itself, but rather some internal parameter of
> the sensor's CSI interface. Unfortunately there isn't much information
> on what this value exactly controls...
>
> Best regards,
> Tomasz
Just got some feedback from OV vendor about this parameter.
P1:0xA1 is the register to control D-PHY timing setting based on bclk.
It is to adjust the MIPI clock voltage to improve the clock drive
capability, and has no affect on the transmission speed of MIPI data.
From vendor's perspective, P1:0xA1 depends upon the length of FPC of
camera module that used on the board. Considering the physical
connections for MIPI signals to user-facing camera are very different
between our 2 projects, it can be very difficult to find universal SI
parameters for both projects.
Thus here we create one new DT property to separate these tuning in
driver, to be more like project-specific.
More details about the register is as below.
P1:0xA1 val: 0x03 default
Case: 0 20MHz-30MHz
1 30MHz-50MHz
2 50MHz-75MHz
3 75MHz-100MHz (default, old DB setting use)
4 100MHz-130MHz (suggested, new DB setting use)
5 Manual
So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
setting. We would adjust the register in next release.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-08 6:51 ` Dongchun Zhu
(?)
@ 2020-05-10 22:35 ` Sakari Ailus
-1 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-10 22:35 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Tomasz Figa, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
Hi Dongchun,
On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> Hi Sakari, Tomasz,
>
> On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hi Tomasz, Dongchun,
> > >
> > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > Hi Sakari and Dongchun,
> > > >
> > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > >
> > > > > Hi Sakari,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > Hi Sakari,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Dongchun,
> > > > > > > >
> > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > ---
> > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > new file mode 100644
> > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > +%YAML 1.2
> > > > > > > > > +---
> > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > +
> > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > +
> > > > > > > > > +maintainers:
> > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > +
> > > > > > > > > +description: |-
> > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > +
> > > > > > > > > +properties:
> > > > > > > > > + compatible:
> > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > +
> > > > > > > > > + reg:
> > > > > > > > > + maxItems: 1
> > > > > > > > > +
> > > > > > > > > + clocks:
> > > > > > > > > + items:
> > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > + - description: devider clock
> > > > > > > > > +
> > > > > > > > > + clock-names:
> > > > > > > > > + items:
> > > > > > > > > + - const: eclk
> > > > > > > > > + - const: freq_mux
> > > > > > > > > +
> > > > > > > > > + clock-frequency:
> > > > > > > > > + description:
> > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > +
> > > > > > > > > + dovdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > +
> > > > > > > > > + avdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > +
> > > > > > > > > + dvdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > +
> > > > > > > > > + powerdown-gpios:
> > > > > > > > > + description:
> > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > +
> > > > > > > > > + reset-gpios:
> > > > > > > > > + description:
> > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > +
> > > > > > > > > + rotation:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > + allOf:
> > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > + - enum:
> > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > +
> > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > + description:
> > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > >
> > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > >
> > > > > > >
> > > > > > > Apologies for not addressing this number clear.
> > > > > > >
> > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > the default val: 0x03.
> > > > > > > The description of this RW register is as below:
> > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > >
> > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > This would be fixed in next release.
> > > > > > >
> > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > >
> > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > >
> > > > >
> > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > select.
> > > > > From the datasheet, we can get the possible values that could be set to
> > > > > P1:0xA1.
> > > > >
> > > > > Actually this register is an independent of sensor mode, it is just
> > > > > included in sensor mode's register setting table.
> > > > >
> > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > failure. The register values are adjusted and verified from vendor to
> > > > > make sensor signal meet MIPI specification.
> > > > >
> > > >
> > > > In theory the value could depend on the mode, because different link
> > > > rate could impose different requirements for the physical interface.
> > > > In practice, we haven't seen any hardware that would require different
> > > > values for different modes.
> > >
> > > The mode (possibly in conjunction with other information available to the
> > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > parameters but this is not supported by the name of the parameter.
> > >
> > > Therefore I don't see how this parameter, which supposedly is used to
> > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > belong to DT.
> >
> > According to the very imprecise information I have access to, it is
> > not about the CSI-2 bus itself, but rather some internal parameter of
> > the sensor's CSI interface. Unfortunately there isn't much information
> > on what this value exactly controls...
> >
> > Best regards,
> > Tomasz
>
> Just got some feedback from OV vendor about this parameter.
>
> P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> It is to adjust the MIPI clock voltage to improve the clock drive
> capability, and has no affect on the transmission speed of MIPI data.
>
> From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> camera module that used on the board. Considering the physical
> connections for MIPI signals to user-facing camera are very different
> between our 2 projects, it can be very difficult to find universal SI
> parameters for both projects.
Are you using different values for this parameter on these two projects?
>
> Thus here we create one new DT property to separate these tuning in
> driver, to be more like project-specific.
>
> More details about the register is as below.
> P1:0xA1 val: 0x03 default
> Case: 0 20MHz-30MHz
> 1 30MHz-50MHz
> 2 50MHz-75MHz
> 3 75MHz-100MHz (default, old DB setting use)
> 4 100MHz-130MHz (suggested, new DB setting use)
> 5 Manual
> So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
>
> Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> setting. We would adjust the register in next release.
Thank you for digging into the issue.
Based on the above description, the parameter would depend on both the link
frequency and possibly also on wire length. I guess there's no harm from
using too strong drive, apart from perhaps power consumption? As in
principle this could be different for different sensor modes. Albeit I
don't remember seeing a sensor where such a parameter would have been
needed to be modified.
--
Regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-10 22:35 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-10 22:35 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Tomasz Figa, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Dongchun,
On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> Hi Sakari, Tomasz,
>
> On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hi Tomasz, Dongchun,
> > >
> > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > Hi Sakari and Dongchun,
> > > >
> > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > >
> > > > > Hi Sakari,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > Hi Sakari,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Dongchun,
> > > > > > > >
> > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > ---
> > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > new file mode 100644
> > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > +%YAML 1.2
> > > > > > > > > +---
> > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > +
> > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > +
> > > > > > > > > +maintainers:
> > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > +
> > > > > > > > > +description: |-
> > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > +
> > > > > > > > > +properties:
> > > > > > > > > + compatible:
> > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > +
> > > > > > > > > + reg:
> > > > > > > > > + maxItems: 1
> > > > > > > > > +
> > > > > > > > > + clocks:
> > > > > > > > > + items:
> > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > + - description: devider clock
> > > > > > > > > +
> > > > > > > > > + clock-names:
> > > > > > > > > + items:
> > > > > > > > > + - const: eclk
> > > > > > > > > + - const: freq_mux
> > > > > > > > > +
> > > > > > > > > + clock-frequency:
> > > > > > > > > + description:
> > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > +
> > > > > > > > > + dovdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > +
> > > > > > > > > + avdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > +
> > > > > > > > > + dvdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > +
> > > > > > > > > + powerdown-gpios:
> > > > > > > > > + description:
> > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > +
> > > > > > > > > + reset-gpios:
> > > > > > > > > + description:
> > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > +
> > > > > > > > > + rotation:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > + allOf:
> > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > + - enum:
> > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > +
> > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > + description:
> > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > >
> > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > >
> > > > > > >
> > > > > > > Apologies for not addressing this number clear.
> > > > > > >
> > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > the default val: 0x03.
> > > > > > > The description of this RW register is as below:
> > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > >
> > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > This would be fixed in next release.
> > > > > > >
> > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > >
> > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > >
> > > > >
> > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > select.
> > > > > From the datasheet, we can get the possible values that could be set to
> > > > > P1:0xA1.
> > > > >
> > > > > Actually this register is an independent of sensor mode, it is just
> > > > > included in sensor mode's register setting table.
> > > > >
> > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > failure. The register values are adjusted and verified from vendor to
> > > > > make sensor signal meet MIPI specification.
> > > > >
> > > >
> > > > In theory the value could depend on the mode, because different link
> > > > rate could impose different requirements for the physical interface.
> > > > In practice, we haven't seen any hardware that would require different
> > > > values for different modes.
> > >
> > > The mode (possibly in conjunction with other information available to the
> > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > parameters but this is not supported by the name of the parameter.
> > >
> > > Therefore I don't see how this parameter, which supposedly is used to
> > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > belong to DT.
> >
> > According to the very imprecise information I have access to, it is
> > not about the CSI-2 bus itself, but rather some internal parameter of
> > the sensor's CSI interface. Unfortunately there isn't much information
> > on what this value exactly controls...
> >
> > Best regards,
> > Tomasz
>
> Just got some feedback from OV vendor about this parameter.
>
> P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> It is to adjust the MIPI clock voltage to improve the clock drive
> capability, and has no affect on the transmission speed of MIPI data.
>
> From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> camera module that used on the board. Considering the physical
> connections for MIPI signals to user-facing camera are very different
> between our 2 projects, it can be very difficult to find universal SI
> parameters for both projects.
Are you using different values for this parameter on these two projects?
>
> Thus here we create one new DT property to separate these tuning in
> driver, to be more like project-specific.
>
> More details about the register is as below.
> P1:0xA1 val: 0x03 default
> Case: 0 20MHz-30MHz
> 1 30MHz-50MHz
> 2 50MHz-75MHz
> 3 75MHz-100MHz (default, old DB setting use)
> 4 100MHz-130MHz (suggested, new DB setting use)
> 5 Manual
> So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
>
> Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> setting. We would adjust the register in next release.
Thank you for digging into the issue.
Based on the above description, the parameter would depend on both the link
frequency and possibly also on wire length. I guess there's no harm from
using too strong drive, apart from perhaps power consumption? As in
principle this could be different for different sensor modes. Albeit I
don't remember seeing a sensor where such a parameter would have been
needed to be modified.
--
Regards,
Sakari Ailus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-10 22:35 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-05-10 22:35 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Tomasz Figa, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Dongchun,
On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> Hi Sakari, Tomasz,
>
> On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > Hi Tomasz, Dongchun,
> > >
> > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > Hi Sakari and Dongchun,
> > > >
> > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > >
> > > > > Hi Sakari,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > Hi Sakari,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Dongchun,
> > > > > > > >
> > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > ---
> > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > new file mode 100644
> > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > +%YAML 1.2
> > > > > > > > > +---
> > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > +
> > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > +
> > > > > > > > > +maintainers:
> > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > +
> > > > > > > > > +description: |-
> > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > +
> > > > > > > > > +properties:
> > > > > > > > > + compatible:
> > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > +
> > > > > > > > > + reg:
> > > > > > > > > + maxItems: 1
> > > > > > > > > +
> > > > > > > > > + clocks:
> > > > > > > > > + items:
> > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > + - description: devider clock
> > > > > > > > > +
> > > > > > > > > + clock-names:
> > > > > > > > > + items:
> > > > > > > > > + - const: eclk
> > > > > > > > > + - const: freq_mux
> > > > > > > > > +
> > > > > > > > > + clock-frequency:
> > > > > > > > > + description:
> > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > +
> > > > > > > > > + dovdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > +
> > > > > > > > > + avdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > +
> > > > > > > > > + dvdd-supply:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > +
> > > > > > > > > + powerdown-gpios:
> > > > > > > > > + description:
> > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > +
> > > > > > > > > + reset-gpios:
> > > > > > > > > + description:
> > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > +
> > > > > > > > > + rotation:
> > > > > > > > > + description:
> > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > + allOf:
> > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > + - enum:
> > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > +
> > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > + description:
> > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > >
> > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > >
> > > > > > >
> > > > > > > Apologies for not addressing this number clear.
> > > > > > >
> > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > the default val: 0x03.
> > > > > > > The description of this RW register is as below:
> > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > >
> > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > This would be fixed in next release.
> > > > > > >
> > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > >
> > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > >
> > > > >
> > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > select.
> > > > > From the datasheet, we can get the possible values that could be set to
> > > > > P1:0xA1.
> > > > >
> > > > > Actually this register is an independent of sensor mode, it is just
> > > > > included in sensor mode's register setting table.
> > > > >
> > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > failure. The register values are adjusted and verified from vendor to
> > > > > make sensor signal meet MIPI specification.
> > > > >
> > > >
> > > > In theory the value could depend on the mode, because different link
> > > > rate could impose different requirements for the physical interface.
> > > > In practice, we haven't seen any hardware that would require different
> > > > values for different modes.
> > >
> > > The mode (possibly in conjunction with other information available to the
> > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > parameters but this is not supported by the name of the parameter.
> > >
> > > Therefore I don't see how this parameter, which supposedly is used to
> > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > belong to DT.
> >
> > According to the very imprecise information I have access to, it is
> > not about the CSI-2 bus itself, but rather some internal parameter of
> > the sensor's CSI interface. Unfortunately there isn't much information
> > on what this value exactly controls...
> >
> > Best regards,
> > Tomasz
>
> Just got some feedback from OV vendor about this parameter.
>
> P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> It is to adjust the MIPI clock voltage to improve the clock drive
> capability, and has no affect on the transmission speed of MIPI data.
>
> From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> camera module that used on the board. Considering the physical
> connections for MIPI signals to user-facing camera are very different
> between our 2 projects, it can be very difficult to find universal SI
> parameters for both projects.
Are you using different values for this parameter on these two projects?
>
> Thus here we create one new DT property to separate these tuning in
> driver, to be more like project-specific.
>
> More details about the register is as below.
> P1:0xA1 val: 0x03 default
> Case: 0 20MHz-30MHz
> 1 30MHz-50MHz
> 2 50MHz-75MHz
> 3 75MHz-100MHz (default, old DB setting use)
> 4 100MHz-130MHz (suggested, new DB setting use)
> 5 Manual
> So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
>
> Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> setting. We would adjust the register in next release.
Thank you for digging into the issue.
Based on the above description, the parameter would depend on both the link
frequency and possibly also on wire length. I guess there's no harm from
using too strong drive, apart from perhaps power consumption? As in
principle this could be different for different sensor modes. Albeit I
don't remember seeing a sensor where such a parameter would have been
needed to be modified.
--
Regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-10 22:35 ` Sakari Ailus
(?)
@ 2020-05-11 11:41 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-11 11:41 UTC (permalink / raw)
To: Sakari Ailus
Cc: Tomasz Figa, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男),
dongchun.zhu
Hi Sakari,
On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > Hi Sakari, Tomasz,
> >
> > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Hi Tomasz, Dongchun,
> > > >
> > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > Hi Sakari and Dongchun,
> > > > >
> > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Sakari,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > Hi Dongchun,
> > > > > > >
> > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > Hi Sakari,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > Hi Dongchun,
> > > > > > > > >
> > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > ---
> > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > >
> > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > +%YAML 1.2
> > > > > > > > > > +---
> > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > +
> > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > +
> > > > > > > > > > +maintainers:
> > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > +
> > > > > > > > > > +description: |-
> > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > +
> > > > > > > > > > +properties:
> > > > > > > > > > + compatible:
> > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > +
> > > > > > > > > > + reg:
> > > > > > > > > > + maxItems: 1
> > > > > > > > > > +
> > > > > > > > > > + clocks:
> > > > > > > > > > + items:
> > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > + - description: devider clock
> > > > > > > > > > +
> > > > > > > > > > + clock-names:
> > > > > > > > > > + items:
> > > > > > > > > > + - const: eclk
> > > > > > > > > > + - const: freq_mux
> > > > > > > > > > +
> > > > > > > > > > + clock-frequency:
> > > > > > > > > > + description:
> > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > +
> > > > > > > > > > + dovdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > +
> > > > > > > > > > + avdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > +
> > > > > > > > > > + dvdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > +
> > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > + description:
> > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > +
> > > > > > > > > > + reset-gpios:
> > > > > > > > > > + description:
> > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > +
> > > > > > > > > > + rotation:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > + allOf:
> > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > + - enum:
> > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > +
> > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > + description:
> > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > >
> > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Apologies for not addressing this number clear.
> > > > > > > >
> > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > the default val: 0x03.
> > > > > > > > The description of this RW register is as below:
> > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > >
> > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > This would be fixed in next release.
> > > > > > > >
> > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > >
> > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > >
> > > > > >
> > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > select.
> > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > P1:0xA1.
> > > > > >
> > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > included in sensor mode's register setting table.
> > > > > >
> > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > make sensor signal meet MIPI specification.
> > > > > >
> > > > >
> > > > > In theory the value could depend on the mode, because different link
> > > > > rate could impose different requirements for the physical interface.
> > > > > In practice, we haven't seen any hardware that would require different
> > > > > values for different modes.
> > > >
> > > > The mode (possibly in conjunction with other information available to the
> > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > parameters but this is not supported by the name of the parameter.
> > > >
> > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > belong to DT.
> > >
> > > According to the very imprecise information I have access to, it is
> > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > the sensor's CSI interface. Unfortunately there isn't much information
> > > on what this value exactly controls...
> > >
> > > Best regards,
> > > Tomasz
> >
> > Just got some feedback from OV vendor about this parameter.
> >
> > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > It is to adjust the MIPI clock voltage to improve the clock drive
> > capability, and has no affect on the transmission speed of MIPI data.
> >
> > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > camera module that used on the board. Considering the physical
> > connections for MIPI signals to user-facing camera are very different
> > between our 2 projects, it can be very difficult to find universal SI
> > parameters for both projects.
>
> Are you using different values for this parameter on these two projects?
>
Yes. We're actually assigning two different values to this property.
One is 0x03, the other is 0x04.
> >
> > Thus here we create one new DT property to separate these tuning in
> > driver, to be more like project-specific.
> >
> > More details about the register is as below.
> > P1:0xA1 val: 0x03 default
> > Case: 0 20MHz-30MHz
> > 1 30MHz-50MHz
> > 2 50MHz-75MHz
> > 3 75MHz-100MHz (default, old DB setting use)
> > 4 100MHz-130MHz (suggested, new DB setting use)
> > 5 Manual
> > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> >
> > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > setting. We would adjust the register in next release.
>
> Thank you for digging into the issue.
>
> Based on the above description, the parameter would depend on both the link
> frequency and possibly also on wire length. I guess there's no harm from
> using too strong drive, apart from perhaps power consumption? As in
> principle this could be different for different sensor modes. Albeit I
> don't remember seeing a sensor where such a parameter would have been
> needed to be modified.
>
This may be related to something about sensor fine tuning.
As OV vendor pointed out, the sensor chip provides such one property
that user could adjust based on their specific project.
Also, case 4 (0x04) setting is confirmed to have a little more power
consumption than case 3 (0x03).
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-11 11:41 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-11 11:41 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Tomasz Figa, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari,
On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > Hi Sakari, Tomasz,
> >
> > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Hi Tomasz, Dongchun,
> > > >
> > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > Hi Sakari and Dongchun,
> > > > >
> > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Sakari,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > Hi Dongchun,
> > > > > > >
> > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > Hi Sakari,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > Hi Dongchun,
> > > > > > > > >
> > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > ---
> > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > >
> > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > +%YAML 1.2
> > > > > > > > > > +---
> > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > +
> > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > +
> > > > > > > > > > +maintainers:
> > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > +
> > > > > > > > > > +description: |-
> > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > +
> > > > > > > > > > +properties:
> > > > > > > > > > + compatible:
> > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > +
> > > > > > > > > > + reg:
> > > > > > > > > > + maxItems: 1
> > > > > > > > > > +
> > > > > > > > > > + clocks:
> > > > > > > > > > + items:
> > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > + - description: devider clock
> > > > > > > > > > +
> > > > > > > > > > + clock-names:
> > > > > > > > > > + items:
> > > > > > > > > > + - const: eclk
> > > > > > > > > > + - const: freq_mux
> > > > > > > > > > +
> > > > > > > > > > + clock-frequency:
> > > > > > > > > > + description:
> > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > +
> > > > > > > > > > + dovdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > +
> > > > > > > > > > + avdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > +
> > > > > > > > > > + dvdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > +
> > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > + description:
> > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > +
> > > > > > > > > > + reset-gpios:
> > > > > > > > > > + description:
> > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > +
> > > > > > > > > > + rotation:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > + allOf:
> > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > + - enum:
> > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > +
> > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > + description:
> > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > >
> > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Apologies for not addressing this number clear.
> > > > > > > >
> > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > the default val: 0x03.
> > > > > > > > The description of this RW register is as below:
> > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > >
> > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > This would be fixed in next release.
> > > > > > > >
> > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > >
> > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > >
> > > > > >
> > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > select.
> > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > P1:0xA1.
> > > > > >
> > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > included in sensor mode's register setting table.
> > > > > >
> > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > make sensor signal meet MIPI specification.
> > > > > >
> > > > >
> > > > > In theory the value could depend on the mode, because different link
> > > > > rate could impose different requirements for the physical interface.
> > > > > In practice, we haven't seen any hardware that would require different
> > > > > values for different modes.
> > > >
> > > > The mode (possibly in conjunction with other information available to the
> > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > parameters but this is not supported by the name of the parameter.
> > > >
> > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > belong to DT.
> > >
> > > According to the very imprecise information I have access to, it is
> > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > the sensor's CSI interface. Unfortunately there isn't much information
> > > on what this value exactly controls...
> > >
> > > Best regards,
> > > Tomasz
> >
> > Just got some feedback from OV vendor about this parameter.
> >
> > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > It is to adjust the MIPI clock voltage to improve the clock drive
> > capability, and has no affect on the transmission speed of MIPI data.
> >
> > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > camera module that used on the board. Considering the physical
> > connections for MIPI signals to user-facing camera are very different
> > between our 2 projects, it can be very difficult to find universal SI
> > parameters for both projects.
>
> Are you using different values for this parameter on these two projects?
>
Yes. We're actually assigning two different values to this property.
One is 0x03, the other is 0x04.
> >
> > Thus here we create one new DT property to separate these tuning in
> > driver, to be more like project-specific.
> >
> > More details about the register is as below.
> > P1:0xA1 val: 0x03 default
> > Case: 0 20MHz-30MHz
> > 1 30MHz-50MHz
> > 2 50MHz-75MHz
> > 3 75MHz-100MHz (default, old DB setting use)
> > 4 100MHz-130MHz (suggested, new DB setting use)
> > 5 Manual
> > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> >
> > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > setting. We would adjust the register in next release.
>
> Thank you for digging into the issue.
>
> Based on the above description, the parameter would depend on both the link
> frequency and possibly also on wire length. I guess there's no harm from
> using too strong drive, apart from perhaps power consumption? As in
> principle this could be different for different sensor modes. Albeit I
> don't remember seeing a sensor where such a parameter would have been
> needed to be modified.
>
This may be related to something about sensor fine tuning.
As OV vendor pointed out, the sensor chip provides such one property
that user could adjust based on their specific project.
Also, case 4 (0x04) setting is confirmed to have a little more power
consumption than case 3 (0x03).
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-05-11 11:41 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-05-11 11:41 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Tomasz Figa, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari,
On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > Hi Sakari, Tomasz,
> >
> > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Hi Tomasz, Dongchun,
> > > >
> > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > Hi Sakari and Dongchun,
> > > > >
> > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Sakari,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > Hi Dongchun,
> > > > > > >
> > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > Hi Sakari,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > Hi Dongchun,
> > > > > > > > >
> > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > ---
> > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > >
> > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > +%YAML 1.2
> > > > > > > > > > +---
> > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > +
> > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > +
> > > > > > > > > > +maintainers:
> > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > +
> > > > > > > > > > +description: |-
> > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > +
> > > > > > > > > > +properties:
> > > > > > > > > > + compatible:
> > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > +
> > > > > > > > > > + reg:
> > > > > > > > > > + maxItems: 1
> > > > > > > > > > +
> > > > > > > > > > + clocks:
> > > > > > > > > > + items:
> > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > + - description: devider clock
> > > > > > > > > > +
> > > > > > > > > > + clock-names:
> > > > > > > > > > + items:
> > > > > > > > > > + - const: eclk
> > > > > > > > > > + - const: freq_mux
> > > > > > > > > > +
> > > > > > > > > > + clock-frequency:
> > > > > > > > > > + description:
> > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > +
> > > > > > > > > > + dovdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > +
> > > > > > > > > > + avdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > +
> > > > > > > > > > + dvdd-supply:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > +
> > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > + description:
> > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > +
> > > > > > > > > > + reset-gpios:
> > > > > > > > > > + description:
> > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > +
> > > > > > > > > > + rotation:
> > > > > > > > > > + description:
> > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > + allOf:
> > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > + - enum:
> > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > +
> > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > + description:
> > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > >
> > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Apologies for not addressing this number clear.
> > > > > > > >
> > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > the default val: 0x03.
> > > > > > > > The description of this RW register is as below:
> > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > >
> > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > This would be fixed in next release.
> > > > > > > >
> > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > >
> > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > >
> > > > > >
> > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > select.
> > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > P1:0xA1.
> > > > > >
> > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > included in sensor mode's register setting table.
> > > > > >
> > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > make sensor signal meet MIPI specification.
> > > > > >
> > > > >
> > > > > In theory the value could depend on the mode, because different link
> > > > > rate could impose different requirements for the physical interface.
> > > > > In practice, we haven't seen any hardware that would require different
> > > > > values for different modes.
> > > >
> > > > The mode (possibly in conjunction with other information available to the
> > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > parameters but this is not supported by the name of the parameter.
> > > >
> > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > belong to DT.
> > >
> > > According to the very imprecise information I have access to, it is
> > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > the sensor's CSI interface. Unfortunately there isn't much information
> > > on what this value exactly controls...
> > >
> > > Best regards,
> > > Tomasz
> >
> > Just got some feedback from OV vendor about this parameter.
> >
> > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > It is to adjust the MIPI clock voltage to improve the clock drive
> > capability, and has no affect on the transmission speed of MIPI data.
> >
> > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > camera module that used on the board. Considering the physical
> > connections for MIPI signals to user-facing camera are very different
> > between our 2 projects, it can be very difficult to find universal SI
> > parameters for both projects.
>
> Are you using different values for this parameter on these two projects?
>
Yes. We're actually assigning two different values to this property.
One is 0x03, the other is 0x04.
> >
> > Thus here we create one new DT property to separate these tuning in
> > driver, to be more like project-specific.
> >
> > More details about the register is as below.
> > P1:0xA1 val: 0x03 default
> > Case: 0 20MHz-30MHz
> > 1 30MHz-50MHz
> > 2 50MHz-75MHz
> > 3 75MHz-100MHz (default, old DB setting use)
> > 4 100MHz-130MHz (suggested, new DB setting use)
> > 5 Manual
> > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> >
> > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > setting. We would adjust the register in next release.
>
> Thank you for digging into the issue.
>
> Based on the above description, the parameter would depend on both the link
> frequency and possibly also on wire length. I guess there's no harm from
> using too strong drive, apart from perhaps power consumption? As in
> principle this could be different for different sensor modes. Albeit I
> don't remember seeing a sensor where such a parameter would have been
> needed to be modified.
>
This may be related to something about sensor fine tuning.
As OV vendor pointed out, the sensor chip provides such one property
that user could adjust based on their specific project.
Also, case 4 (0x04) setting is confirmed to have a little more power
consumption than case 3 (0x03).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-05-11 11:41 ` Dongchun Zhu
(?)
@ 2020-07-15 14:01 ` Sakari Ailus
-1 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-07-15 14:01 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Tomasz Figa, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
hi Dongchun,
On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> Hi Sakari,
>
> On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari, Tomasz,
> > >
> > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > <sakari.ailus@linux.intel.com> wrote:
> > > > >
> > > > > Hi Tomasz, Dongchun,
> > > > >
> > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > Hi Sakari and Dongchun,
> > > > > >
> > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > >
> > > > > > > Hi Sakari,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Dongchun,
> > > > > > > >
> > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > Hi Sakari,
> > > > > > > > >
> > > > > > > > > Thanks for the review.
> > > > > > > > >
> > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > Hi Dongchun,
> > > > > > > > > >
> > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > ---
> > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > +---
> > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > +
> > > > > > > > > > > +maintainers:
> > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > +
> > > > > > > > > > > +description: |-
> > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > +
> > > > > > > > > > > +properties:
> > > > > > > > > > > + compatible:
> > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > +
> > > > > > > > > > > + reg:
> > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > +
> > > > > > > > > > > + clocks:
> > > > > > > > > > > + items:
> > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > +
> > > > > > > > > > > + clock-names:
> > > > > > > > > > > + items:
> > > > > > > > > > > + - const: eclk
> > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > +
> > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > +
> > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > + description:
> > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > +
> > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > + description:
> > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > +
> > > > > > > > > > > + rotation:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > + allOf:
> > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > + - enum:
> > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > +
> > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > >
> > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > >
> > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > the default val: 0x03.
> > > > > > > > > The description of this RW register is as below:
> > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > >
> > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > This would be fixed in next release.
> > > > > > > > >
> > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > >
> > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > >
> > > > > > >
> > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > select.
> > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > P1:0xA1.
> > > > > > >
> > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > included in sensor mode's register setting table.
> > > > > > >
> > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > make sensor signal meet MIPI specification.
> > > > > > >
> > > > > >
> > > > > > In theory the value could depend on the mode, because different link
> > > > > > rate could impose different requirements for the physical interface.
> > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > values for different modes.
> > > > >
> > > > > The mode (possibly in conjunction with other information available to the
> > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > parameters but this is not supported by the name of the parameter.
> > > > >
> > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > belong to DT.
> > > >
> > > > According to the very imprecise information I have access to, it is
> > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > on what this value exactly controls...
> > > >
> > > > Best regards,
> > > > Tomasz
> > >
> > > Just got some feedback from OV vendor about this parameter.
> > >
> > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > capability, and has no affect on the transmission speed of MIPI data.
> > >
> > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > camera module that used on the board. Considering the physical
> > > connections for MIPI signals to user-facing camera are very different
> > > between our 2 projects, it can be very difficult to find universal SI
> > > parameters for both projects.
> >
> > Are you using different values for this parameter on these two projects?
> >
>
> Yes. We're actually assigning two different values to this property.
> One is 0x03, the other is 0x04.
>
> > >
> > > Thus here we create one new DT property to separate these tuning in
> > > driver, to be more like project-specific.
> > >
> > > More details about the register is as below.
> > > P1:0xA1 val: 0x03 default
> > > Case: 0 20MHz-30MHz
> > > 1 30MHz-50MHz
> > > 2 50MHz-75MHz
> > > 3 75MHz-100MHz (default, old DB setting use)
> > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > 5 Manual
> > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > >
> > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > setting. We would adjust the register in next release.
> >
> > Thank you for digging into the issue.
> >
> > Based on the above description, the parameter would depend on both the link
> > frequency and possibly also on wire length. I guess there's no harm from
> > using too strong drive, apart from perhaps power consumption? As in
> > principle this could be different for different sensor modes. Albeit I
> > don't remember seeing a sensor where such a parameter would have been
> > needed to be modified.
> >
>
> This may be related to something about sensor fine tuning.
> As OV vendor pointed out, the sensor chip provides such one property
> that user could adjust based on their specific project.
> Also, case 4 (0x04) setting is confirmed to have a little more power
> consumption than case 3 (0x03).
Apologies for bringing back an old topic --- the driver supports just a
single mode, using a specific data rate.
If another mode is added later on, will it continue to use the same value
for this? Based on the documentation, it seems that this is primarily
defined by the frequency of the bus, not by board design. Therefore putting
this to DT (and thus ignoring the frequency) appears wrong.
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-07-15 14:01 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-07-15 14:01 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Tomasz Figa, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
hi Dongchun,
On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> Hi Sakari,
>
> On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari, Tomasz,
> > >
> > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > <sakari.ailus@linux.intel.com> wrote:
> > > > >
> > > > > Hi Tomasz, Dongchun,
> > > > >
> > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > Hi Sakari and Dongchun,
> > > > > >
> > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > >
> > > > > > > Hi Sakari,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Dongchun,
> > > > > > > >
> > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > Hi Sakari,
> > > > > > > > >
> > > > > > > > > Thanks for the review.
> > > > > > > > >
> > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > Hi Dongchun,
> > > > > > > > > >
> > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > ---
> > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > +---
> > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > +
> > > > > > > > > > > +maintainers:
> > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > +
> > > > > > > > > > > +description: |-
> > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > +
> > > > > > > > > > > +properties:
> > > > > > > > > > > + compatible:
> > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > +
> > > > > > > > > > > + reg:
> > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > +
> > > > > > > > > > > + clocks:
> > > > > > > > > > > + items:
> > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > +
> > > > > > > > > > > + clock-names:
> > > > > > > > > > > + items:
> > > > > > > > > > > + - const: eclk
> > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > +
> > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > +
> > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > + description:
> > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > +
> > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > + description:
> > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > +
> > > > > > > > > > > + rotation:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > + allOf:
> > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > + - enum:
> > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > +
> > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > >
> > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > >
> > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > the default val: 0x03.
> > > > > > > > > The description of this RW register is as below:
> > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > >
> > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > This would be fixed in next release.
> > > > > > > > >
> > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > >
> > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > >
> > > > > > >
> > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > select.
> > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > P1:0xA1.
> > > > > > >
> > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > included in sensor mode's register setting table.
> > > > > > >
> > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > make sensor signal meet MIPI specification.
> > > > > > >
> > > > > >
> > > > > > In theory the value could depend on the mode, because different link
> > > > > > rate could impose different requirements for the physical interface.
> > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > values for different modes.
> > > > >
> > > > > The mode (possibly in conjunction with other information available to the
> > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > parameters but this is not supported by the name of the parameter.
> > > > >
> > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > belong to DT.
> > > >
> > > > According to the very imprecise information I have access to, it is
> > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > on what this value exactly controls...
> > > >
> > > > Best regards,
> > > > Tomasz
> > >
> > > Just got some feedback from OV vendor about this parameter.
> > >
> > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > capability, and has no affect on the transmission speed of MIPI data.
> > >
> > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > camera module that used on the board. Considering the physical
> > > connections for MIPI signals to user-facing camera are very different
> > > between our 2 projects, it can be very difficult to find universal SI
> > > parameters for both projects.
> >
> > Are you using different values for this parameter on these two projects?
> >
>
> Yes. We're actually assigning two different values to this property.
> One is 0x03, the other is 0x04.
>
> > >
> > > Thus here we create one new DT property to separate these tuning in
> > > driver, to be more like project-specific.
> > >
> > > More details about the register is as below.
> > > P1:0xA1 val: 0x03 default
> > > Case: 0 20MHz-30MHz
> > > 1 30MHz-50MHz
> > > 2 50MHz-75MHz
> > > 3 75MHz-100MHz (default, old DB setting use)
> > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > 5 Manual
> > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > >
> > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > setting. We would adjust the register in next release.
> >
> > Thank you for digging into the issue.
> >
> > Based on the above description, the parameter would depend on both the link
> > frequency and possibly also on wire length. I guess there's no harm from
> > using too strong drive, apart from perhaps power consumption? As in
> > principle this could be different for different sensor modes. Albeit I
> > don't remember seeing a sensor where such a parameter would have been
> > needed to be modified.
> >
>
> This may be related to something about sensor fine tuning.
> As OV vendor pointed out, the sensor chip provides such one property
> that user could adjust based on their specific project.
> Also, case 4 (0x04) setting is confirmed to have a little more power
> consumption than case 3 (0x03).
Apologies for bringing back an old topic --- the driver supports just a
single mode, using a specific data rate.
If another mode is added later on, will it continue to use the same value
for this? Based on the documentation, it seems that this is primarily
defined by the frequency of the bus, not by board design. Therefore putting
this to DT (and thus ignoring the frequency) appears wrong.
--
Kind regards,
Sakari Ailus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-07-15 14:01 ` Sakari Ailus
0 siblings, 0 replies; 57+ messages in thread
From: Sakari Ailus @ 2020-07-15 14:01 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Tomasz Figa, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
hi Dongchun,
On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> Hi Sakari,
>
> On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari, Tomasz,
> > >
> > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > <sakari.ailus@linux.intel.com> wrote:
> > > > >
> > > > > Hi Tomasz, Dongchun,
> > > > >
> > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > Hi Sakari and Dongchun,
> > > > > >
> > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > >
> > > > > > > Hi Sakari,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Dongchun,
> > > > > > > >
> > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > Hi Sakari,
> > > > > > > > >
> > > > > > > > > Thanks for the review.
> > > > > > > > >
> > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > Hi Dongchun,
> > > > > > > > > >
> > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > ---
> > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > +---
> > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > +
> > > > > > > > > > > +maintainers:
> > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > +
> > > > > > > > > > > +description: |-
> > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > +
> > > > > > > > > > > +properties:
> > > > > > > > > > > + compatible:
> > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > +
> > > > > > > > > > > + reg:
> > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > +
> > > > > > > > > > > + clocks:
> > > > > > > > > > > + items:
> > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > +
> > > > > > > > > > > + clock-names:
> > > > > > > > > > > + items:
> > > > > > > > > > > + - const: eclk
> > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > +
> > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > +
> > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > +
> > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > + description:
> > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > +
> > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > + description:
> > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > +
> > > > > > > > > > > + rotation:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > + allOf:
> > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > + - enum:
> > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > +
> > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > + description:
> > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > >
> > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > >
> > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > the default val: 0x03.
> > > > > > > > > The description of this RW register is as below:
> > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > >
> > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > This would be fixed in next release.
> > > > > > > > >
> > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > >
> > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > >
> > > > > > >
> > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > select.
> > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > P1:0xA1.
> > > > > > >
> > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > included in sensor mode's register setting table.
> > > > > > >
> > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > make sensor signal meet MIPI specification.
> > > > > > >
> > > > > >
> > > > > > In theory the value could depend on the mode, because different link
> > > > > > rate could impose different requirements for the physical interface.
> > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > values for different modes.
> > > > >
> > > > > The mode (possibly in conjunction with other information available to the
> > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > parameters but this is not supported by the name of the parameter.
> > > > >
> > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > belong to DT.
> > > >
> > > > According to the very imprecise information I have access to, it is
> > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > on what this value exactly controls...
> > > >
> > > > Best regards,
> > > > Tomasz
> > >
> > > Just got some feedback from OV vendor about this parameter.
> > >
> > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > capability, and has no affect on the transmission speed of MIPI data.
> > >
> > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > camera module that used on the board. Considering the physical
> > > connections for MIPI signals to user-facing camera are very different
> > > between our 2 projects, it can be very difficult to find universal SI
> > > parameters for both projects.
> >
> > Are you using different values for this parameter on these two projects?
> >
>
> Yes. We're actually assigning two different values to this property.
> One is 0x03, the other is 0x04.
>
> > >
> > > Thus here we create one new DT property to separate these tuning in
> > > driver, to be more like project-specific.
> > >
> > > More details about the register is as below.
> > > P1:0xA1 val: 0x03 default
> > > Case: 0 20MHz-30MHz
> > > 1 30MHz-50MHz
> > > 2 50MHz-75MHz
> > > 3 75MHz-100MHz (default, old DB setting use)
> > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > 5 Manual
> > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > >
> > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > setting. We would adjust the register in next release.
> >
> > Thank you for digging into the issue.
> >
> > Based on the above description, the parameter would depend on both the link
> > frequency and possibly also on wire length. I guess there's no harm from
> > using too strong drive, apart from perhaps power consumption? As in
> > principle this could be different for different sensor modes. Albeit I
> > don't remember seeing a sensor where such a parameter would have been
> > needed to be modified.
> >
>
> This may be related to something about sensor fine tuning.
> As OV vendor pointed out, the sensor chip provides such one property
> that user could adjust based on their specific project.
> Also, case 4 (0x04) setting is confirmed to have a little more power
> consumption than case 3 (0x03).
Apologies for bringing back an old topic --- the driver supports just a
single mode, using a specific data rate.
If another mode is added later on, will it continue to use the same value
for this? Based on the documentation, it seems that this is primarily
defined by the frequency of the bus, not by board design. Therefore putting
this to DT (and thus ignoring the frequency) appears wrong.
--
Kind regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-07-15 14:01 ` Sakari Ailus
(?)
@ 2020-07-16 14:57 ` Tomasz Figa
-1 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-07-16 14:57 UTC (permalink / raw)
To: Sakari Ailus
Cc: Dongchun Zhu, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> hi Dongchun,
>
> On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > Hi Sakari,
> >
> > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari, Tomasz,
> > > >
> > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > >
> > > > > > Hi Tomasz, Dongchun,
> > > > > >
> > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > Hi Sakari and Dongchun,
> > > > > > >
> > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > Hi Sakari,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > Hi Dongchun,
> > > > > > > > >
> > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > Hi Sakari,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > +---
> > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > +
> > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > +
> > > > > > > > > > > > +description: |-
> > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > +
> > > > > > > > > > > > +properties:
> > > > > > > > > > > > + compatible:
> > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > +
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > +
> > > > > > > > > > > > + clocks:
> > > > > > > > > > > > + items:
> > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > +
> > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > + items:
> > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > +
> > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > +
> > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > +
> > > > > > > > > > > > + rotation:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > + allOf:
> > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > + - enum:
> > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > +
> > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > >
> > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > >
> > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > the default val: 0x03.
> > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > >
> > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > This would be fixed in next release.
> > > > > > > > > >
> > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > >
> > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > >
> > > > > > > >
> > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > select.
> > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > P1:0xA1.
> > > > > > > >
> > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > included in sensor mode's register setting table.
> > > > > > > >
> > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > >
> > > > > > >
> > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > values for different modes.
> > > > > >
> > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > parameters but this is not supported by the name of the parameter.
> > > > > >
> > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > belong to DT.
> > > > >
> > > > > According to the very imprecise information I have access to, it is
> > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > on what this value exactly controls...
> > > > >
> > > > > Best regards,
> > > > > Tomasz
> > > >
> > > > Just got some feedback from OV vendor about this parameter.
> > > >
> > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > capability, and has no affect on the transmission speed of MIPI data.
> > > >
> > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > camera module that used on the board. Considering the physical
> > > > connections for MIPI signals to user-facing camera are very different
> > > > between our 2 projects, it can be very difficult to find universal SI
> > > > parameters for both projects.
> > >
> > > Are you using different values for this parameter on these two projects?
> > >
> >
> > Yes. We're actually assigning two different values to this property.
> > One is 0x03, the other is 0x04.
> >
> > > >
> > > > Thus here we create one new DT property to separate these tuning in
> > > > driver, to be more like project-specific.
> > > >
> > > > More details about the register is as below.
> > > > P1:0xA1 val: 0x03 default
> > > > Case: 0 20MHz-30MHz
> > > > 1 30MHz-50MHz
> > > > 2 50MHz-75MHz
> > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > 5 Manual
> > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > >
> > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > setting. We would adjust the register in next release.
> > >
> > > Thank you for digging into the issue.
> > >
> > > Based on the above description, the parameter would depend on both the link
> > > frequency and possibly also on wire length. I guess there's no harm from
> > > using too strong drive, apart from perhaps power consumption? As in
> > > principle this could be different for different sensor modes. Albeit I
> > > don't remember seeing a sensor where such a parameter would have been
> > > needed to be modified.
> > >
> >
> > This may be related to something about sensor fine tuning.
> > As OV vendor pointed out, the sensor chip provides such one property
> > that user could adjust based on their specific project.
> > Also, case 4 (0x04) setting is confirmed to have a little more power
> > consumption than case 3 (0x03).
>
> Apologies for bringing back an old topic --- the driver supports just a
> single mode, using a specific data rate.
>
> If another mode is added later on, will it continue to use the same value
> for this? Based on the documentation, it seems that this is primarily
> defined by the frequency of the bus, not by board design. Therefore putting
> this to DT (and thus ignoring the frequency) appears wrong.
I don't think this is exactly implied by the frequency of the bus. The
values there are recommended for given frequency ranges, but there are
real cases where depending on the board different values are needed.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-07-16 14:57 ` Tomasz Figa
0 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-07-16 14:57 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> hi Dongchun,
>
> On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > Hi Sakari,
> >
> > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari, Tomasz,
> > > >
> > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > >
> > > > > > Hi Tomasz, Dongchun,
> > > > > >
> > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > Hi Sakari and Dongchun,
> > > > > > >
> > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > Hi Sakari,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > Hi Dongchun,
> > > > > > > > >
> > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > Hi Sakari,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > +---
> > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > +
> > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > +
> > > > > > > > > > > > +description: |-
> > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > +
> > > > > > > > > > > > +properties:
> > > > > > > > > > > > + compatible:
> > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > +
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > +
> > > > > > > > > > > > + clocks:
> > > > > > > > > > > > + items:
> > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > +
> > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > + items:
> > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > +
> > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > +
> > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > +
> > > > > > > > > > > > + rotation:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > + allOf:
> > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > + - enum:
> > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > +
> > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > >
> > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > >
> > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > the default val: 0x03.
> > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > >
> > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > This would be fixed in next release.
> > > > > > > > > >
> > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > >
> > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > >
> > > > > > > >
> > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > select.
> > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > P1:0xA1.
> > > > > > > >
> > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > included in sensor mode's register setting table.
> > > > > > > >
> > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > >
> > > > > > >
> > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > values for different modes.
> > > > > >
> > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > parameters but this is not supported by the name of the parameter.
> > > > > >
> > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > belong to DT.
> > > > >
> > > > > According to the very imprecise information I have access to, it is
> > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > on what this value exactly controls...
> > > > >
> > > > > Best regards,
> > > > > Tomasz
> > > >
> > > > Just got some feedback from OV vendor about this parameter.
> > > >
> > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > capability, and has no affect on the transmission speed of MIPI data.
> > > >
> > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > camera module that used on the board. Considering the physical
> > > > connections for MIPI signals to user-facing camera are very different
> > > > between our 2 projects, it can be very difficult to find universal SI
> > > > parameters for both projects.
> > >
> > > Are you using different values for this parameter on these two projects?
> > >
> >
> > Yes. We're actually assigning two different values to this property.
> > One is 0x03, the other is 0x04.
> >
> > > >
> > > > Thus here we create one new DT property to separate these tuning in
> > > > driver, to be more like project-specific.
> > > >
> > > > More details about the register is as below.
> > > > P1:0xA1 val: 0x03 default
> > > > Case: 0 20MHz-30MHz
> > > > 1 30MHz-50MHz
> > > > 2 50MHz-75MHz
> > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > 5 Manual
> > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > >
> > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > setting. We would adjust the register in next release.
> > >
> > > Thank you for digging into the issue.
> > >
> > > Based on the above description, the parameter would depend on both the link
> > > frequency and possibly also on wire length. I guess there's no harm from
> > > using too strong drive, apart from perhaps power consumption? As in
> > > principle this could be different for different sensor modes. Albeit I
> > > don't remember seeing a sensor where such a parameter would have been
> > > needed to be modified.
> > >
> >
> > This may be related to something about sensor fine tuning.
> > As OV vendor pointed out, the sensor chip provides such one property
> > that user could adjust based on their specific project.
> > Also, case 4 (0x04) setting is confirmed to have a little more power
> > consumption than case 3 (0x03).
>
> Apologies for bringing back an old topic --- the driver supports just a
> single mode, using a specific data rate.
>
> If another mode is added later on, will it continue to use the same value
> for this? Based on the documentation, it seems that this is primarily
> defined by the frequency of the bus, not by board design. Therefore putting
> this to DT (and thus ignoring the frequency) appears wrong.
I don't think this is exactly implied by the frequency of the bus. The
values there are recommended for given frequency ranges, but there are
real cases where depending on the board different values are needed.
Best regards,
Tomasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-07-16 14:57 ` Tomasz Figa
0 siblings, 0 replies; 57+ messages in thread
From: Tomasz Figa @ 2020-07-16 14:57 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> hi Dongchun,
>
> On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > Hi Sakari,
> >
> > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari, Tomasz,
> > > >
> > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > >
> > > > > > Hi Tomasz, Dongchun,
> > > > > >
> > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > Hi Sakari and Dongchun,
> > > > > > >
> > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > Hi Sakari,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > Hi Dongchun,
> > > > > > > > >
> > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > Hi Sakari,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > +---
> > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > +
> > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > +
> > > > > > > > > > > > +description: |-
> > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > +
> > > > > > > > > > > > +properties:
> > > > > > > > > > > > + compatible:
> > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > +
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > +
> > > > > > > > > > > > + clocks:
> > > > > > > > > > > > + items:
> > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > +
> > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > + items:
> > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > +
> > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > +
> > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > +
> > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > +
> > > > > > > > > > > > + rotation:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > + allOf:
> > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > + - enum:
> > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > +
> > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > + description:
> > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > >
> > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > >
> > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > the default val: 0x03.
> > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > >
> > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > This would be fixed in next release.
> > > > > > > > > >
> > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > >
> > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > >
> > > > > > > >
> > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > select.
> > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > P1:0xA1.
> > > > > > > >
> > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > included in sensor mode's register setting table.
> > > > > > > >
> > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > >
> > > > > > >
> > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > values for different modes.
> > > > > >
> > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > parameters but this is not supported by the name of the parameter.
> > > > > >
> > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > belong to DT.
> > > > >
> > > > > According to the very imprecise information I have access to, it is
> > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > on what this value exactly controls...
> > > > >
> > > > > Best regards,
> > > > > Tomasz
> > > >
> > > > Just got some feedback from OV vendor about this parameter.
> > > >
> > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > capability, and has no affect on the transmission speed of MIPI data.
> > > >
> > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > camera module that used on the board. Considering the physical
> > > > connections for MIPI signals to user-facing camera are very different
> > > > between our 2 projects, it can be very difficult to find universal SI
> > > > parameters for both projects.
> > >
> > > Are you using different values for this parameter on these two projects?
> > >
> >
> > Yes. We're actually assigning two different values to this property.
> > One is 0x03, the other is 0x04.
> >
> > > >
> > > > Thus here we create one new DT property to separate these tuning in
> > > > driver, to be more like project-specific.
> > > >
> > > > More details about the register is as below.
> > > > P1:0xA1 val: 0x03 default
> > > > Case: 0 20MHz-30MHz
> > > > 1 30MHz-50MHz
> > > > 2 50MHz-75MHz
> > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > 5 Manual
> > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > >
> > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > setting. We would adjust the register in next release.
> > >
> > > Thank you for digging into the issue.
> > >
> > > Based on the above description, the parameter would depend on both the link
> > > frequency and possibly also on wire length. I guess there's no harm from
> > > using too strong drive, apart from perhaps power consumption? As in
> > > principle this could be different for different sensor modes. Albeit I
> > > don't remember seeing a sensor where such a parameter would have been
> > > needed to be modified.
> > >
> >
> > This may be related to something about sensor fine tuning.
> > As OV vendor pointed out, the sensor chip provides such one property
> > that user could adjust based on their specific project.
> > Also, case 4 (0x04) setting is confirmed to have a little more power
> > consumption than case 3 (0x03).
>
> Apologies for bringing back an old topic --- the driver supports just a
> single mode, using a specific data rate.
>
> If another mode is added later on, will it continue to use the same value
> for this? Based on the documentation, it seems that this is primarily
> defined by the frequency of the bus, not by board design. Therefore putting
> this to DT (and thus ignoring the frequency) appears wrong.
I don't think this is exactly implied by the frequency of the bus. The
values there are recommended for given frequency ranges, but there are
real cases where depending on the board different values are needed.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-07-16 14:57 ` Tomasz Figa
(?)
@ 2020-07-20 2:30 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-07-20 2:30 UTC (permalink / raw)
To: Tomasz Figa
Cc: Sakari Ailus, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring,
Mark Rutland, Nicolas Boichat, matrix.zhu, Matthias Brugger,
Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男),
dongchun.zhu
Hi Sakari, Tomasz,
Thanks for the review.
On Thu, 2020-07-16 at 16:57 +0200, Tomasz Figa wrote:
> On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > hi Dongchun,
> >
> > On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari,
> > >
> > > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari, Tomasz,
> > > > >
> > > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > > >
> > > > > > > Hi Tomasz, Dongchun,
> > > > > > >
> > > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > > Hi Sakari and Dongchun,
> > > > > > > >
> > > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Sakari,
> > > > > > > > >
> > > > > > > > > Thanks for the review.
> > > > > > > > >
> > > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > > Hi Dongchun,
> > > > > > > > > >
> > > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > Hi Sakari,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the review.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > > +---
> > > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +description: |-
> > > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +properties:
> > > > > > > > > > > > > + compatible:
> > > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clocks:
> > > > > > > > > > > > > + items:
> > > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > > + items:
> > > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + rotation:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > > + allOf:
> > > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > > + - enum:
> > > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > > >
> > > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > > >
> > > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > > the default val: 0x03.
> > > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > > >
> > > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > > This would be fixed in next release.
> > > > > > > > > > >
> > > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > > >
> > > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > > select.
> > > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > > P1:0xA1.
> > > > > > > > >
> > > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > > included in sensor mode's register setting table.
> > > > > > > > >
> > > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > > >
> > > > > > > >
> > > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > > values for different modes.
> > > > > > >
> > > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > > parameters but this is not supported by the name of the parameter.
> > > > > > >
> > > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > > belong to DT.
> > > > > >
> > > > > > According to the very imprecise information I have access to, it is
> > > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > > on what this value exactly controls...
> > > > > >
> > > > > > Best regards,
> > > > > > Tomasz
> > > > >
> > > > > Just got some feedback from OV vendor about this parameter.
> > > > >
> > > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > > capability, and has no affect on the transmission speed of MIPI data.
> > > > >
> > > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > > camera module that used on the board. Considering the physical
> > > > > connections for MIPI signals to user-facing camera are very different
> > > > > between our 2 projects, it can be very difficult to find universal SI
> > > > > parameters for both projects.
> > > >
> > > > Are you using different values for this parameter on these two projects?
> > > >
> > >
> > > Yes. We're actually assigning two different values to this property.
> > > One is 0x03, the other is 0x04.
> > >
> > > > >
> > > > > Thus here we create one new DT property to separate these tuning in
> > > > > driver, to be more like project-specific.
> > > > >
> > > > > More details about the register is as below.
> > > > > P1:0xA1 val: 0x03 default
> > > > > Case: 0 20MHz-30MHz
> > > > > 1 30MHz-50MHz
> > > > > 2 50MHz-75MHz
> > > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > > 5 Manual
> > > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > > >
> > > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > > setting. We would adjust the register in next release.
> > > >
> > > > Thank you for digging into the issue.
> > > >
> > > > Based on the above description, the parameter would depend on both the link
> > > > frequency and possibly also on wire length. I guess there's no harm from
> > > > using too strong drive, apart from perhaps power consumption? As in
> > > > principle this could be different for different sensor modes. Albeit I
> > > > don't remember seeing a sensor where such a parameter would have been
> > > > needed to be modified.
> > > >
> > >
> > > This may be related to something about sensor fine tuning.
> > > As OV vendor pointed out, the sensor chip provides such one property
> > > that user could adjust based on their specific project.
> > > Also, case 4 (0x04) setting is confirmed to have a little more power
> > > consumption than case 3 (0x03).
> >
> > Apologies for bringing back an old topic --- the driver supports just a
> > single mode, using a specific data rate.
> >
> > If another mode is added later on, will it continue to use the same value
> > for this? Based on the documentation, it seems that this is primarily
> > defined by the frequency of the bus, not by board design. Therefore putting
> > this to DT (and thus ignoring the frequency) appears wrong.
>
> I don't think this is exactly implied by the frequency of the bus. The
> values there are recommended for given frequency ranges, but there are
> real cases where depending on the board different values are needed.
>
Sorry for coming late.
For the reg P1: 0xA1, I re-confirmed the setting of the param with OVT.
The replies are as follow.
1. P1:0xA1 is one register to control D-PHY timing parameters based on
bclk. Its setting shall match the MIPI CSI-2 timing clock.
2. For one another scenario, if MIPI pixel rate(link frequency) differs
between scenarios, the setting of this parameter may also be different.
3. In one special case, we may also need to adjust the value, even for
the same scenario, such as the failure of a certain MIPI test.
From my perspective, temporally we don't plan to have a different
scenario for OV02A10, as the current resolution(1600x1200) is near to
the lower limit of most smart mobile devices.
In the meantime, considering the difference of the physical connections
for MIPI signals to user-facing camera between our 2 projects, it seems
to be very difficult to find universal SI parameters for both projects.
So for this case, I wonder whether we could reserve this private
property to maintain such flexibility.
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-07-20 2:30 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-07-20 2:30 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Louis Kuo, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu,
Sakari Ailus, Matthias Brugger, Cao Bing Bu, matrix.zhu,
Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari, Tomasz,
Thanks for the review.
On Thu, 2020-07-16 at 16:57 +0200, Tomasz Figa wrote:
> On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > hi Dongchun,
> >
> > On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari,
> > >
> > > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari, Tomasz,
> > > > >
> > > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > > >
> > > > > > > Hi Tomasz, Dongchun,
> > > > > > >
> > > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > > Hi Sakari and Dongchun,
> > > > > > > >
> > > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Sakari,
> > > > > > > > >
> > > > > > > > > Thanks for the review.
> > > > > > > > >
> > > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > > Hi Dongchun,
> > > > > > > > > >
> > > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > Hi Sakari,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the review.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > > +---
> > > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +description: |-
> > > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +properties:
> > > > > > > > > > > > > + compatible:
> > > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clocks:
> > > > > > > > > > > > > + items:
> > > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > > + items:
> > > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + rotation:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > > + allOf:
> > > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > > + - enum:
> > > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > > >
> > > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > > >
> > > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > > the default val: 0x03.
> > > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > > >
> > > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > > This would be fixed in next release.
> > > > > > > > > > >
> > > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > > >
> > > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > > select.
> > > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > > P1:0xA1.
> > > > > > > > >
> > > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > > included in sensor mode's register setting table.
> > > > > > > > >
> > > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > > >
> > > > > > > >
> > > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > > values for different modes.
> > > > > > >
> > > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > > parameters but this is not supported by the name of the parameter.
> > > > > > >
> > > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > > belong to DT.
> > > > > >
> > > > > > According to the very imprecise information I have access to, it is
> > > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > > on what this value exactly controls...
> > > > > >
> > > > > > Best regards,
> > > > > > Tomasz
> > > > >
> > > > > Just got some feedback from OV vendor about this parameter.
> > > > >
> > > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > > capability, and has no affect on the transmission speed of MIPI data.
> > > > >
> > > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > > camera module that used on the board. Considering the physical
> > > > > connections for MIPI signals to user-facing camera are very different
> > > > > between our 2 projects, it can be very difficult to find universal SI
> > > > > parameters for both projects.
> > > >
> > > > Are you using different values for this parameter on these two projects?
> > > >
> > >
> > > Yes. We're actually assigning two different values to this property.
> > > One is 0x03, the other is 0x04.
> > >
> > > > >
> > > > > Thus here we create one new DT property to separate these tuning in
> > > > > driver, to be more like project-specific.
> > > > >
> > > > > More details about the register is as below.
> > > > > P1:0xA1 val: 0x03 default
> > > > > Case: 0 20MHz-30MHz
> > > > > 1 30MHz-50MHz
> > > > > 2 50MHz-75MHz
> > > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > > 5 Manual
> > > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > > >
> > > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > > setting. We would adjust the register in next release.
> > > >
> > > > Thank you for digging into the issue.
> > > >
> > > > Based on the above description, the parameter would depend on both the link
> > > > frequency and possibly also on wire length. I guess there's no harm from
> > > > using too strong drive, apart from perhaps power consumption? As in
> > > > principle this could be different for different sensor modes. Albeit I
> > > > don't remember seeing a sensor where such a parameter would have been
> > > > needed to be modified.
> > > >
> > >
> > > This may be related to something about sensor fine tuning.
> > > As OV vendor pointed out, the sensor chip provides such one property
> > > that user could adjust based on their specific project.
> > > Also, case 4 (0x04) setting is confirmed to have a little more power
> > > consumption than case 3 (0x03).
> >
> > Apologies for bringing back an old topic --- the driver supports just a
> > single mode, using a specific data rate.
> >
> > If another mode is added later on, will it continue to use the same value
> > for this? Based on the documentation, it seems that this is primarily
> > defined by the frequency of the bus, not by board design. Therefore putting
> > this to DT (and thus ignoring the frequency) appears wrong.
>
> I don't think this is exactly implied by the frequency of the bus. The
> values there are recommended for given frequency ranges, but there are
> real cases where depending on the board different values are needed.
>
Sorry for coming late.
For the reg P1: 0xA1, I re-confirmed the setting of the param with OVT.
The replies are as follow.
1. P1:0xA1 is one register to control D-PHY timing parameters based on
bclk. Its setting shall match the MIPI CSI-2 timing clock.
2. For one another scenario, if MIPI pixel rate(link frequency) differs
between scenarios, the setting of this parameter may also be different.
3. In one special case, we may also need to adjust the value, even for
the same scenario, such as the failure of a certain MIPI test.
From my perspective, temporally we don't plan to have a different
scenario for OV02A10, as the current resolution(1600x1200) is near to
the lower limit of most smart mobile devices.
In the meantime, considering the difference of the physical connections
for MIPI signals to user-facing camera between our 2 projects, it seems
to be very difficult to find universal SI parameters for both projects.
So for this case, I wonder whether we could reserve this private
property to maintain such flexibility.
> Best regards,
> Tomasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-07-20 2:30 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-07-20 2:30 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Louis Kuo, Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu,
Sakari Ailus, Matthias Brugger, Cao Bing Bu, matrix.zhu,
Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari, Tomasz,
Thanks for the review.
On Thu, 2020-07-16 at 16:57 +0200, Tomasz Figa wrote:
> On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > hi Dongchun,
> >
> > On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > > Hi Sakari,
> > >
> > > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari, Tomasz,
> > > > >
> > > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > > >
> > > > > > > Hi Tomasz, Dongchun,
> > > > > > >
> > > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > > Hi Sakari and Dongchun,
> > > > > > > >
> > > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Sakari,
> > > > > > > > >
> > > > > > > > > Thanks for the review.
> > > > > > > > >
> > > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > > Hi Dongchun,
> > > > > > > > > >
> > > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > Hi Sakari,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the review.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > > +---
> > > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +description: |-
> > > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +properties:
> > > > > > > > > > > > > + compatible:
> > > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clocks:
> > > > > > > > > > > > > + items:
> > > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > > + items:
> > > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + rotation:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > > + allOf:
> > > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > > + - enum:
> > > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > > + description:
> > > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > > >
> > > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > > >
> > > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > > the default val: 0x03.
> > > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > > >
> > > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > > This would be fixed in next release.
> > > > > > > > > > >
> > > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > > >
> > > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > > select.
> > > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > > P1:0xA1.
> > > > > > > > >
> > > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > > included in sensor mode's register setting table.
> > > > > > > > >
> > > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > > >
> > > > > > > >
> > > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > > values for different modes.
> > > > > > >
> > > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > > parameters but this is not supported by the name of the parameter.
> > > > > > >
> > > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > > belong to DT.
> > > > > >
> > > > > > According to the very imprecise information I have access to, it is
> > > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > > on what this value exactly controls...
> > > > > >
> > > > > > Best regards,
> > > > > > Tomasz
> > > > >
> > > > > Just got some feedback from OV vendor about this parameter.
> > > > >
> > > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > > capability, and has no affect on the transmission speed of MIPI data.
> > > > >
> > > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > > camera module that used on the board. Considering the physical
> > > > > connections for MIPI signals to user-facing camera are very different
> > > > > between our 2 projects, it can be very difficult to find universal SI
> > > > > parameters for both projects.
> > > >
> > > > Are you using different values for this parameter on these two projects?
> > > >
> > >
> > > Yes. We're actually assigning two different values to this property.
> > > One is 0x03, the other is 0x04.
> > >
> > > > >
> > > > > Thus here we create one new DT property to separate these tuning in
> > > > > driver, to be more like project-specific.
> > > > >
> > > > > More details about the register is as below.
> > > > > P1:0xA1 val: 0x03 default
> > > > > Case: 0 20MHz-30MHz
> > > > > 1 30MHz-50MHz
> > > > > 2 50MHz-75MHz
> > > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > > 5 Manual
> > > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > > >
> > > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > > setting. We would adjust the register in next release.
> > > >
> > > > Thank you for digging into the issue.
> > > >
> > > > Based on the above description, the parameter would depend on both the link
> > > > frequency and possibly also on wire length. I guess there's no harm from
> > > > using too strong drive, apart from perhaps power consumption? As in
> > > > principle this could be different for different sensor modes. Albeit I
> > > > don't remember seeing a sensor where such a parameter would have been
> > > > needed to be modified.
> > > >
> > >
> > > This may be related to something about sensor fine tuning.
> > > As OV vendor pointed out, the sensor chip provides such one property
> > > that user could adjust based on their specific project.
> > > Also, case 4 (0x04) setting is confirmed to have a little more power
> > > consumption than case 3 (0x03).
> >
> > Apologies for bringing back an old topic --- the driver supports just a
> > single mode, using a specific data rate.
> >
> > If another mode is added later on, will it continue to use the same value
> > for this? Based on the documentation, it seems that this is primarily
> > defined by the frequency of the bus, not by board design. Therefore putting
> > this to DT (and thus ignoring the frequency) appears wrong.
>
> I don't think this is exactly implied by the frequency of the bus. The
> values there are recommended for given frequency ranges, but there are
> real cases where depending on the board different values are needed.
>
Sorry for coming late.
For the reg P1: 0xA1, I re-confirmed the setting of the param with OVT.
The replies are as follow.
1. P1:0xA1 is one register to control D-PHY timing parameters based on
bclk. Its setting shall match the MIPI CSI-2 timing clock.
2. For one another scenario, if MIPI pixel rate(link frequency) differs
between scenarios, the setting of this parameter may also be different.
3. In one special case, we may also need to adjust the value, even for
the same scenario, such as the failure of a certain MIPI test.
From my perspective, temporally we don't plan to have a different
scenario for OV02A10, as the current resolution(1600x1200) is near to
the lower limit of most smart mobile devices.
In the meantime, considering the difference of the physical connections
for MIPI signals to user-facing camera between our 2 projects, it seems
to be very difficult to find universal SI parameters for both projects.
So for this case, I wonder whether we could reserve this private
property to maintain such flexibility.
> Best regards,
> Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
2020-07-20 2:30 ` Dongchun Zhu
(?)
@ 2020-08-25 1:53 ` Dongchun Zhu
-1 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-08-25 1:53 UTC (permalink / raw)
To: Tomasz Figa, Sakari Ailus
Cc: Linus Walleij, Bartosz Golaszewski, Mauro Carvalho Chehab,
Andy Shevchenko, Rob Herring, Mark Rutland, Nicolas Boichat,
matrix.zhu, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男),
dongchun.zhu
Hi Sakari,
Pardon, have you noticed my rely below?
Please let us know of any questions or suggestions you have.
On Mon, 2020-07-20 at 10:30 +0800, Dongchun Zhu wrote:
> Hi Sakari, Tomasz,
>
> Thanks for the review.
>
> On Thu, 2020-07-16 at 16:57 +0200, Tomasz Figa wrote:
> > On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > hi Dongchun,
> > >
> > > On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari,
> > > >
> > > > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari, Tomasz,
> > > > > >
> > > > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > > > >
> > > > > > > > Hi Tomasz, Dongchun,
> > > > > > > >
> > > > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > > > Hi Sakari and Dongchun,
> > > > > > > > >
> > > > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Sakari,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > Hi Sakari,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > > > +---
> > > > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +description: |-
> > > > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +properties:
> > > > > > > > > > > > > > + compatible:
> > > > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clocks:
> > > > > > > > > > > > > > + items:
> > > > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > > > + items:
> > > > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + rotation:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > > > + allOf:
> > > > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > > > + - enum:
> > > > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > > > >
> > > > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > > > the default val: 0x03.
> > > > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > > > >
> > > > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > > > This would be fixed in next release.
> > > > > > > > > > > >
> > > > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > > > >
> > > > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > > > select.
> > > > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > > > P1:0xA1.
> > > > > > > > > >
> > > > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > > > included in sensor mode's register setting table.
> > > > > > > > > >
> > > > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > > > values for different modes.
> > > > > > > >
> > > > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > > > parameters but this is not supported by the name of the parameter.
> > > > > > > >
> > > > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > > > belong to DT.
> > > > > > >
> > > > > > > According to the very imprecise information I have access to, it is
> > > > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > > > on what this value exactly controls...
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Tomasz
> > > > > >
> > > > > > Just got some feedback from OV vendor about this parameter.
> > > > > >
> > > > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > > > capability, and has no affect on the transmission speed of MIPI data.
> > > > > >
> > > > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > > > camera module that used on the board. Considering the physical
> > > > > > connections for MIPI signals to user-facing camera are very different
> > > > > > between our 2 projects, it can be very difficult to find universal SI
> > > > > > parameters for both projects.
> > > > >
> > > > > Are you using different values for this parameter on these two projects?
> > > > >
> > > >
> > > > Yes. We're actually assigning two different values to this property.
> > > > One is 0x03, the other is 0x04.
> > > >
> > > > > >
> > > > > > Thus here we create one new DT property to separate these tuning in
> > > > > > driver, to be more like project-specific.
> > > > > >
> > > > > > More details about the register is as below.
> > > > > > P1:0xA1 val: 0x03 default
> > > > > > Case: 0 20MHz-30MHz
> > > > > > 1 30MHz-50MHz
> > > > > > 2 50MHz-75MHz
> > > > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > > > 5 Manual
> > > > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > > > >
> > > > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > > > setting. We would adjust the register in next release.
> > > > >
> > > > > Thank you for digging into the issue.
> > > > >
> > > > > Based on the above description, the parameter would depend on both the link
> > > > > frequency and possibly also on wire length. I guess there's no harm from
> > > > > using too strong drive, apart from perhaps power consumption? As in
> > > > > principle this could be different for different sensor modes. Albeit I
> > > > > don't remember seeing a sensor where such a parameter would have been
> > > > > needed to be modified.
> > > > >
> > > >
> > > > This may be related to something about sensor fine tuning.
> > > > As OV vendor pointed out, the sensor chip provides such one property
> > > > that user could adjust based on their specific project.
> > > > Also, case 4 (0x04) setting is confirmed to have a little more power
> > > > consumption than case 3 (0x03).
> > >
> > > Apologies for bringing back an old topic --- the driver supports just a
> > > single mode, using a specific data rate.
> > >
> > > If another mode is added later on, will it continue to use the same value
> > > for this? Based on the documentation, it seems that this is primarily
> > > defined by the frequency of the bus, not by board design. Therefore putting
> > > this to DT (and thus ignoring the frequency) appears wrong.
> >
> > I don't think this is exactly implied by the frequency of the bus. The
> > values there are recommended for given frequency ranges, but there are
> > real cases where depending on the board different values are needed.
> >
>
> Sorry for coming late.
> For the reg P1: 0xA1, I re-confirmed the setting of the param with OVT.
> The replies are as follow.
> 1. P1:0xA1 is one register to control D-PHY timing parameters based on
> bclk. Its setting shall match the MIPI CSI-2 timing clock.
> 2. For one another scenario, if MIPI pixel rate(link frequency) differs
> between scenarios, the setting of this parameter may also be different.
> 3. In one special case, we may also need to adjust the value, even for
> the same scenario, such as the failure of a certain MIPI test.
>
> From my perspective, temporally we don't plan to have a different
> scenario for OV02A10, as the current resolution(1600x1200) is near to
> the lower limit of most smart mobile devices.
> In the meantime, considering the difference of the physical connections
> for MIPI signals to user-facing camera between our 2 projects, it seems
> to be very difficult to find universal SI parameters for both projects.
> So for this case, I wonder whether we could reserve this private
> property to maintain such flexibility.
>
> > Best regards,
> > Tomasz
>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-08-25 1:53 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-08-25 1:53 UTC (permalink / raw)
To: Tomasz Figa, Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari,
Pardon, have you noticed my rely below?
Please let us know of any questions or suggestions you have.
On Mon, 2020-07-20 at 10:30 +0800, Dongchun Zhu wrote:
> Hi Sakari, Tomasz,
>
> Thanks for the review.
>
> On Thu, 2020-07-16 at 16:57 +0200, Tomasz Figa wrote:
> > On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > hi Dongchun,
> > >
> > > On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari,
> > > >
> > > > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari, Tomasz,
> > > > > >
> > > > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > > > >
> > > > > > > > Hi Tomasz, Dongchun,
> > > > > > > >
> > > > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > > > Hi Sakari and Dongchun,
> > > > > > > > >
> > > > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Sakari,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > Hi Sakari,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > > > +---
> > > > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +description: |-
> > > > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +properties:
> > > > > > > > > > > > > > + compatible:
> > > > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clocks:
> > > > > > > > > > > > > > + items:
> > > > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > > > + items:
> > > > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + rotation:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > > > + allOf:
> > > > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > > > + - enum:
> > > > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > > > >
> > > > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > > > the default val: 0x03.
> > > > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > > > >
> > > > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > > > This would be fixed in next release.
> > > > > > > > > > > >
> > > > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > > > >
> > > > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > > > select.
> > > > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > > > P1:0xA1.
> > > > > > > > > >
> > > > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > > > included in sensor mode's register setting table.
> > > > > > > > > >
> > > > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > > > values for different modes.
> > > > > > > >
> > > > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > > > parameters but this is not supported by the name of the parameter.
> > > > > > > >
> > > > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > > > belong to DT.
> > > > > > >
> > > > > > > According to the very imprecise information I have access to, it is
> > > > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > > > on what this value exactly controls...
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Tomasz
> > > > > >
> > > > > > Just got some feedback from OV vendor about this parameter.
> > > > > >
> > > > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > > > capability, and has no affect on the transmission speed of MIPI data.
> > > > > >
> > > > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > > > camera module that used on the board. Considering the physical
> > > > > > connections for MIPI signals to user-facing camera are very different
> > > > > > between our 2 projects, it can be very difficult to find universal SI
> > > > > > parameters for both projects.
> > > > >
> > > > > Are you using different values for this parameter on these two projects?
> > > > >
> > > >
> > > > Yes. We're actually assigning two different values to this property.
> > > > One is 0x03, the other is 0x04.
> > > >
> > > > > >
> > > > > > Thus here we create one new DT property to separate these tuning in
> > > > > > driver, to be more like project-specific.
> > > > > >
> > > > > > More details about the register is as below.
> > > > > > P1:0xA1 val: 0x03 default
> > > > > > Case: 0 20MHz-30MHz
> > > > > > 1 30MHz-50MHz
> > > > > > 2 50MHz-75MHz
> > > > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > > > 5 Manual
> > > > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > > > >
> > > > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > > > setting. We would adjust the register in next release.
> > > > >
> > > > > Thank you for digging into the issue.
> > > > >
> > > > > Based on the above description, the parameter would depend on both the link
> > > > > frequency and possibly also on wire length. I guess there's no harm from
> > > > > using too strong drive, apart from perhaps power consumption? As in
> > > > > principle this could be different for different sensor modes. Albeit I
> > > > > don't remember seeing a sensor where such a parameter would have been
> > > > > needed to be modified.
> > > > >
> > > >
> > > > This may be related to something about sensor fine tuning.
> > > > As OV vendor pointed out, the sensor chip provides such one property
> > > > that user could adjust based on their specific project.
> > > > Also, case 4 (0x04) setting is confirmed to have a little more power
> > > > consumption than case 3 (0x03).
> > >
> > > Apologies for bringing back an old topic --- the driver supports just a
> > > single mode, using a specific data rate.
> > >
> > > If another mode is added later on, will it continue to use the same value
> > > for this? Based on the documentation, it seems that this is primarily
> > > defined by the frequency of the bus, not by board design. Therefore putting
> > > this to DT (and thus ignoring the frequency) appears wrong.
> >
> > I don't think this is exactly implied by the frequency of the bus. The
> > values there are recommended for given frequency ranges, but there are
> > real cases where depending on the board different values are needed.
> >
>
> Sorry for coming late.
> For the reg P1: 0xA1, I re-confirmed the setting of the param with OVT.
> The replies are as follow.
> 1. P1:0xA1 is one register to control D-PHY timing parameters based on
> bclk. Its setting shall match the MIPI CSI-2 timing clock.
> 2. For one another scenario, if MIPI pixel rate(link frequency) differs
> between scenarios, the setting of this parameter may also be different.
> 3. In one special case, we may also need to adjust the value, even for
> the same scenario, such as the failure of a certain MIPI test.
>
> From my perspective, temporally we don't plan to have a different
> scenario for OV02A10, as the current resolution(1600x1200) is near to
> the lower limit of most smart mobile devices.
> In the meantime, considering the difference of the physical connections
> for MIPI signals to user-facing camera between our 2 projects, it seems
> to be very difficult to find universal SI parameters for both projects.
> So for this case, I wonder whether we could reserve this private
> property to maintain such flexibility.
>
> > Best regards,
> > Tomasz
>
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
@ 2020-08-25 1:53 ` Dongchun Zhu
0 siblings, 0 replies; 57+ messages in thread
From: Dongchun Zhu @ 2020-08-25 1:53 UTC (permalink / raw)
To: Tomasz Figa, Sakari Ailus
Cc: Mark Rutland, Nicolas Boichat, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男),
Bartosz Golaszewski, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, matrix.zhu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS
<iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
Hi Sakari,
Pardon, have you noticed my rely below?
Please let us know of any questions or suggestions you have.
On Mon, 2020-07-20 at 10:30 +0800, Dongchun Zhu wrote:
> Hi Sakari, Tomasz,
>
> Thanks for the review.
>
> On Thu, 2020-07-16 at 16:57 +0200, Tomasz Figa wrote:
> > On Wed, Jul 15, 2020 at 4:01 PM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > hi Dongchun,
> > >
> > > On Mon, May 11, 2020 at 07:41:05PM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari,
> > > >
> > > > On Mon, 2020-05-11 at 01:35 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Fri, May 08, 2020 at 02:51:25PM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari, Tomasz,
> > > > > >
> > > > > > On Thu, 2020-05-07 at 16:25 +0200, Tomasz Figa wrote:
> > > > > > > On Thu, May 7, 2020 at 4:12 PM Sakari Ailus
> > > > > > > <sakari.ailus@linux.intel.com> wrote:
> > > > > > > >
> > > > > > > > Hi Tomasz, Dongchun,
> > > > > > > >
> > > > > > > > On Thu, May 07, 2020 at 03:50:40PM +0200, Tomasz Figa wrote:
> > > > > > > > > Hi Sakari and Dongchun,
> > > > > > > > >
> > > > > > > > > On Thu, May 7, 2020 at 3:00 PM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Sakari,
> > > > > > > > > >
> > > > > > > > > > Thanks for the review.
> > > > > > > > > >
> > > > > > > > > > On Wed, 2020-05-06 at 14:21 +0300, Sakari Ailus wrote:
> > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, May 05, 2020 at 10:17:18PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > Hi Sakari,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 2020-05-05 at 10:04 +0300, Sakari Ailus wrote:
> > > > > > > > > > > > > Hi Dongchun,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Apr 30, 2020 at 04:09:23PM +0800, Dongchun Zhu wrote:
> > > > > > > > > > > > > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > .../bindings/media/i2c/ovti,ov02a10.yaml | 148 +++++++++++++++++++++
> > > > > > > > > > > > > > MAINTAINERS | 7 +
> > > > > > > > > > > > > > 2 files changed, 155 insertions(+)
> > > > > > > > > > > > > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > > new file mode 100644
> > > > > > > > > > > > > > index 0000000..2be4bd2
> > > > > > > > > > > > > > --- /dev/null
> > > > > > > > > > > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > > > > > > > > > > > @@ -0,0 +1,148 @@
> > > > > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > > > > > > > > > > +# Copyright (c) 2020 MediaTek Inc.
> > > > > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > > > > +---
> > > > > > > > > > > > > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > > > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +maintainers:
> > > > > > > > > > > > > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +description: |-
> > > > > > > > > > > > > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > > > > > > > > > > > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > > > > > > > > > > > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > > > > > > > > > > > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > > > > > > > > > > > > + sensor output is available via CSI-2 serial data output.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +properties:
> > > > > > > > > > > > > > + compatible:
> > > > > > > > > > > > > > + const: ovti,ov02a10
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + maxItems: 1
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clocks:
> > > > > > > > > > > > > > + items:
> > > > > > > > > > > > > > + - description: top mux camtg clock
> > > > > > > > > > > > > > + - description: devider clock
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clock-names:
> > > > > > > > > > > > > > + items:
> > > > > > > > > > > > > > + - const: eclk
> > > > > > > > > > > > > > + - const: freq_mux
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + clock-frequency:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Frequency of the eclk clock in Hertz.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dovdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as interface power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + avdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as analog power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dvdd-supply:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the regulator used as digital power supply.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + powerdown-gpios:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor powerdown.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + The phandle and specifier for the GPIO that controls sensor reset.
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + rotation:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Definition of the sensor's placement, valid values are 0 and 180.
> > > > > > > > > > > > > > + allOf:
> > > > > > > > > > > > > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > > > > > > > > > > > > + - enum:
> > > > > > > > > > > > > > + - 0 # Sensor Mounted Upright
> > > > > > > > > > > > > > + - 180 # Sensor Mounted Upside Down
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + ovti,mipi-tx-speed:
> > > > > > > > > > > > > > + description:
> > > > > > > > > > > > > > + Indication of MIPI transmission speed select.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What exactly does this signify? And how do you come up with the number?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Apologies for not addressing this number clear.
> > > > > > > > > > > >
> > > > > > > > > > > > From the datasheet, P1:0xA1 register represents TX_SPEED_AREA_SEL with
> > > > > > > > > > > > the default val: 0x03.
> > > > > > > > > > > > The description of this RW register is as below:
> > > > > > > > > > > > Bit[2:0]: MIPI transmission speed select.
> > > > > > > > > > > >
> > > > > > > > > > > > Thus the enum should be definited as [ 0, 1, 2, 3, 4, 5, 6, 7 ].
> > > > > > > > > > > > This would be fixed in next release.
> > > > > > > > > > > >
> > > > > > > > > > > > In the meantime, as the default val of P1:0xA1 is 0x03, we hope to keep
> > > > > > > > > > > > that value if there is no setting for this private property in DT.
> > > > > > > > > > > > The caller in driver would be updated like this in next release.
> > > > > > > > > > > > if (ov02a10->mipi_clock_tx_speed)
> > > > > > > > > > > > ret = i2c_smbus_write_byte_data(...,...);
> > > > > > > > > > >
> > > > > > > > > > > How did you pick the value in the example? And why do you believe it is
> > > > > > > > > > > specific to a platform, and not e.g. a sensor mode?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > We look into P1:0XA1, one register that defines MIPI transmission speed
> > > > > > > > > > select.
> > > > > > > > > > From the datasheet, we can get the possible values that could be set to
> > > > > > > > > > P1:0xA1.
> > > > > > > > > >
> > > > > > > > > > Actually this register is an independent of sensor mode, it is just
> > > > > > > > > > included in sensor mode's register setting table.
> > > > > > > > > >
> > > > > > > > > > In addition, this private DT Property is created to fix the MIPI test
> > > > > > > > > > failure. The register values are adjusted and verified from vendor to
> > > > > > > > > > make sensor signal meet MIPI specification.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > In theory the value could depend on the mode, because different link
> > > > > > > > > rate could impose different requirements for the physical interface.
> > > > > > > > > In practice, we haven't seen any hardware that would require different
> > > > > > > > > values for different modes.
> > > > > > > >
> > > > > > > > The mode (possibly in conjunction with other information available to the
> > > > > > > > driver via V4L2 fwnode interface) precisely defines the parameters of the
> > > > > > > > CSI-2 bus --- apart from the possible exception of the bus timing related
> > > > > > > > parameters but this is not supported by the name of the parameter.
> > > > > > > >
> > > > > > > > Therefore I don't see how this parameter, which supposedly is used to
> > > > > > > > determine the CSI-2 transmissions speed, could be board specific and thus
> > > > > > > > belong to DT.
> > > > > > >
> > > > > > > According to the very imprecise information I have access to, it is
> > > > > > > not about the CSI-2 bus itself, but rather some internal parameter of
> > > > > > > the sensor's CSI interface. Unfortunately there isn't much information
> > > > > > > on what this value exactly controls...
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Tomasz
> > > > > >
> > > > > > Just got some feedback from OV vendor about this parameter.
> > > > > >
> > > > > > P1:0xA1 is the register to control D-PHY timing setting based on bclk.
> > > > > > It is to adjust the MIPI clock voltage to improve the clock drive
> > > > > > capability, and has no affect on the transmission speed of MIPI data.
> > > > > >
> > > > > > From vendor's perspective, P1:0xA1 depends upon the length of FPC of
> > > > > > camera module that used on the board. Considering the physical
> > > > > > connections for MIPI signals to user-facing camera are very different
> > > > > > between our 2 projects, it can be very difficult to find universal SI
> > > > > > parameters for both projects.
> > > > >
> > > > > Are you using different values for this parameter on these two projects?
> > > > >
> > > >
> > > > Yes. We're actually assigning two different values to this property.
> > > > One is 0x03, the other is 0x04.
> > > >
> > > > > >
> > > > > > Thus here we create one new DT property to separate these tuning in
> > > > > > driver, to be more like project-specific.
> > > > > >
> > > > > > More details about the register is as below.
> > > > > > P1:0xA1 val: 0x03 default
> > > > > > Case: 0 20MHz-30MHz
> > > > > > 1 30MHz-50MHz
> > > > > > 2 50MHz-75MHz
> > > > > > 3 75MHz-100MHz (default, old DB setting use)
> > > > > > 4 100MHz-130MHz (suggested, new DB setting use)
> > > > > > 5 Manual
> > > > > > So the value in the example should be [ 0, 1, 2, 3, 4, 5 ].
> > > > > >
> > > > > > Additionally, P1:0xA1 is recommended to be set as 0x04 in the newest DB
> > > > > > setting. We would adjust the register in next release.
> > > > >
> > > > > Thank you for digging into the issue.
> > > > >
> > > > > Based on the above description, the parameter would depend on both the link
> > > > > frequency and possibly also on wire length. I guess there's no harm from
> > > > > using too strong drive, apart from perhaps power consumption? As in
> > > > > principle this could be different for different sensor modes. Albeit I
> > > > > don't remember seeing a sensor where such a parameter would have been
> > > > > needed to be modified.
> > > > >
> > > >
> > > > This may be related to something about sensor fine tuning.
> > > > As OV vendor pointed out, the sensor chip provides such one property
> > > > that user could adjust based on their specific project.
> > > > Also, case 4 (0x04) setting is confirmed to have a little more power
> > > > consumption than case 3 (0x03).
> > >
> > > Apologies for bringing back an old topic --- the driver supports just a
> > > single mode, using a specific data rate.
> > >
> > > If another mode is added later on, will it continue to use the same value
> > > for this? Based on the documentation, it seems that this is primarily
> > > defined by the frequency of the bus, not by board design. Therefore putting
> > > this to DT (and thus ignoring the frequency) appears wrong.
> >
> > I don't think this is exactly implied by the frequency of the bus. The
> > values there are recommended for given frequency ranges, but there are
> > real cases where depending on the board different values are needed.
> >
>
> Sorry for coming late.
> For the reg P1: 0xA1, I re-confirmed the setting of the param with OVT.
> The replies are as follow.
> 1. P1:0xA1 is one register to control D-PHY timing parameters based on
> bclk. Its setting shall match the MIPI CSI-2 timing clock.
> 2. For one another scenario, if MIPI pixel rate(link frequency) differs
> between scenarios, the setting of this parameter may also be different.
> 3. In one special case, we may also need to adjust the value, even for
> the same scenario, such as the failure of a certain MIPI test.
>
> From my perspective, temporally we don't plan to have a different
> scenario for OV02A10, as the current resolution(1600x1200) is near to
> the lower limit of most smart mobile devices.
> In the meantime, considering the difference of the physical connections
> for MIPI signals to user-facing camera between our 2 projects, it seems
> to be very difficult to find universal SI parameters for both projects.
> So for this case, I wonder whether we could reserve this private
> property to maintain such flexibility.
>
> > Best regards,
> > Tomasz
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2020-08-25 1:56 UTC | newest]
Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-30 8:09 [V7, 0/2] media: i2c: Add support for OV02A10 sensor Dongchun Zhu
2020-04-30 8:09 ` Dongchun Zhu
2020-04-30 8:09 ` Dongchun Zhu
2020-04-30 8:09 ` [V7, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings Dongchun Zhu
2020-04-30 8:09 ` Dongchun Zhu
2020-04-30 8:09 ` Dongchun Zhu
2020-05-05 7:04 ` Sakari Ailus
2020-05-05 7:04 ` Sakari Ailus
2020-05-05 7:04 ` Sakari Ailus
2020-05-05 14:17 ` Dongchun Zhu
2020-05-05 14:17 ` Dongchun Zhu
2020-05-05 14:17 ` Dongchun Zhu
2020-05-06 11:21 ` Sakari Ailus
2020-05-06 11:21 ` Sakari Ailus
2020-05-06 11:21 ` Sakari Ailus
2020-05-07 12:58 ` Dongchun Zhu
2020-05-07 12:58 ` Dongchun Zhu
2020-05-07 12:58 ` Dongchun Zhu
2020-05-07 13:50 ` Tomasz Figa
2020-05-07 13:50 ` Tomasz Figa
2020-05-07 13:50 ` Tomasz Figa
2020-05-07 14:11 ` Sakari Ailus
2020-05-07 14:11 ` Sakari Ailus
2020-05-07 14:11 ` Sakari Ailus
2020-05-07 14:25 ` Tomasz Figa
2020-05-07 14:25 ` Tomasz Figa
2020-05-07 14:25 ` Tomasz Figa
2020-05-08 6:51 ` Dongchun Zhu
2020-05-08 6:51 ` Dongchun Zhu
2020-05-08 6:51 ` Dongchun Zhu
2020-05-10 22:35 ` Sakari Ailus
2020-05-10 22:35 ` Sakari Ailus
2020-05-10 22:35 ` Sakari Ailus
2020-05-11 11:41 ` Dongchun Zhu
2020-05-11 11:41 ` Dongchun Zhu
2020-05-11 11:41 ` Dongchun Zhu
2020-07-15 14:01 ` Sakari Ailus
2020-07-15 14:01 ` Sakari Ailus
2020-07-15 14:01 ` Sakari Ailus
2020-07-16 14:57 ` Tomasz Figa
2020-07-16 14:57 ` Tomasz Figa
2020-07-16 14:57 ` Tomasz Figa
2020-07-20 2:30 ` Dongchun Zhu
2020-07-20 2:30 ` Dongchun Zhu
2020-07-20 2:30 ` Dongchun Zhu
2020-08-25 1:53 ` Dongchun Zhu
2020-08-25 1:53 ` Dongchun Zhu
2020-08-25 1:53 ` Dongchun Zhu
2020-05-05 16:15 ` Rob Herring
2020-05-05 16:15 ` Rob Herring
2020-05-05 16:15 ` Rob Herring
2020-05-07 13:02 ` Dongchun Zhu
2020-05-07 13:02 ` Dongchun Zhu
2020-05-07 13:02 ` Dongchun Zhu
2020-04-30 8:09 ` [V7, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver Dongchun Zhu
2020-04-30 8:09 ` Dongchun Zhu
2020-04-30 8:09 ` Dongchun Zhu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.