media: add V4L2 DT binding documentation
Subsystems (3)
PATCH 1/1 media: add V4L2 DT binding documentation
This patch adds a document, describing common V4L2 device tree bindings.
--- Documentation/devicetree/bindings/media/v4l2.txt | 143 ++++++++++++++++++++++ 1 files changed, 143 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
Documentation/devicetree/bindings/media/v4l2.txt new file +143 -0
@@ -0,0 +1,143 @@ +Video4Linux Version 2 (V4L2) + +General concept: +- video pipelines consist of external devices, e.g., camera sensors, controlled + over an I2C bus, and SoC internal IP blocks, including video DMA engines and + video data processors. +- this document describes common bindings of all video pipeline devices. +- SoC internal blocks are described by DT nodes, placed similarly to other SoC + blocks. +- external devices are places on their respective control busses, e.g., I2C +- data interfaces on all video devices are described by "port" child DT nodes +- port configuration depends on other devices, participating in the data + transfer, and is described by "link" DT nodes, specified as children of + all "port" nodes, connected to this bus. +- if a port can be configured to work with more than one other device on the + same bus, a "link" child DT node must be provided for each of them. +- if more than one port is present on a device or more than one link is + connected to a port, a common scheme, using "#address-cells," "#size-cells" + and "reg" properties is used. + +Optional link properties: +- remote: phandle to the other endpoint link DT node. +- data-shift: on parallel data busses, if data-width is used to specify the + number of data lines, data-shift can be used to specify which data lines are + used, e.g., "data-width=<10>; data-shift=<2>;" means, that lines 9:2 are used. +- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity + respectively. +- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities are + not specified, embedded synchronisation may be required, where supported. +- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock pin. +- immutable: used for SoC-internal links, if no configuration is required. +- data-lanes: array of serial, e.g., MIPI CSI-2, data hardware lane numbers in + the ascending order, beginning with logical lane 0. +- clock-lanes: hardware lane number, used for the clock lane. + +Example: + + ceu0: ceu at 0xfe910000 { + compatible = "renesas,sh-mobile-ceu"; + reg = <0xfe910000 0xa0>; + interrupts = <0x880>; + + mclk: master_clock { + compatible = "renesas,ceu-clock"; + #clock-cells = <1>; + clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port { + #address-cells = <1>; + #size-cells = <0>; + + ceu0_1: link at 1 { + reg = <1>; /* local link # */ + remote = <&ov772x_1_1>; /* remote phandle */ + bus-width = <8>; /* used data lines */ + data-shift = <0>; /* lines 7:0 are used */ + + /* If [hv]sync-active are missing, embedded bt.605 sync is used */ + hsync-active = <1>; /* active high */ + vsync-active = <1>; /* active high */ + pclk-sample = <1>; /* rising */ + }; + + ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable; + }; + }; + }; + + i2c0: i2c at 0xfff20000 { + ... + ov772x_1: camera at 0x21 { + compatible = "omnivision,ov772x"; + reg = <0x21>; + vddio-supply = <®ulator1>; + vddcore-supply = <®ulator2>; + + clock-frequency = <20000000>; + clocks = <&mclk 0>; + clock-names = "xclk"; + + port { + /* With 1 link per port no need in addresses */ + ov772x_1_1: link { + bus-width = <8>; + remote = <&ceu0_1>; + hsync-active = <1>; + hsync-active = <0>; /* who came up with an inverter here?... */ + pclk-sample = <1>; + }; + }; + }; + + imx074: camera at 0x1a { + compatible = "sony,imx074"; + reg = <0x1a>; + vddio-supply = <®ulator1>; + vddcore-supply = <®ulator2>; + + clock-frequency = <30000000>; /* shared clock with ov772x_1 */ + clocks = <&mclk 0>; + clock-names = "sysclk"; /* assuming this is the name in the datasheet */ + + port { + imx074_1: link { + clock-lanes = <0>; + data-lanes = <1>, <2>; + remote = <&csi2_1>; + }; + }; + }; + }; + + csi2: csi2 at 0xffc90000 { + compatible = "renesas,sh-mobile-csi2"; + reg = <0xffc90000 0x1000>; + interrupts = <0x17a0>; + #address-cells = <1>; + #size-cells = <0>; + + port at 1 { + compatible = "renesas,csi2c"; /* one of CSI2I and CSI2C */ + reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S, PHY_M has port address 0, is unused */ + + csi2_1: link { + clock-lanes = <0>; + data-lanes = <2>, <1>; + remote = <&imx074_1>; + }; + }; + port at 2 { + reg = <2>; /* port 2: link to the CEU */ + + csi2_2: link { + immutable; + remote = <&ceu0_0>; + }; + }; + };
Signature · 1 line
1.7.2.5
PATCH 1/1 media: add V4L2 DT binding documentation
Hi Guennadi,
Quoted 24 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>--- Documentation/devicetree/bindings/media/v4l2.txt | 143 ++++++++++++++++++++++ 1 files changed, 143 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/v4l2.txtDocumentation/devicetree/bindings/media/v4l2.txt new file +9
-0@@ -0,0 +1,143 @@ +Video4Linux Version 2 (V4L2) + +General concept: +- video pipelines consist of external devices, e.g., camera sensors, controlled + over an I2C bus, and SoC internal IP blocks, including video DMA engines and + video data processors. +- this document describes common bindings of all video pipeline devices. +- SoC internal blocks are described by DT nodes, placed similarly to other SoC + blocks.
Documentation/devicetree/bindings/media/v4l2.txt line 19
Quoted 10 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +10
-0+- external devices are places on their respective control busses, e.g., I2C +- data interfaces on all video devices are described by "port" child DT nodes +- port configuration depends on other devices, participating in the data + transfer, and is described by "link" DT nodes, specified as children of + all "port" nodes, connected to this bus. +- if a port can be configured to work with more than one other device on the + same bus, a "link" child DT node must be provided for each of them. +- if more than one port is present on a device or more than one link is + connected to a port, a common scheme, using "#address-cells," "#size-cells" + and "reg" properties is used.
How about rephrasing/rearranging this to:
This document describes common bindings of all video pipeline devices.
General concept
---------------
Video pipelines consist of external devices, e.g. camera sensors, controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including video DMA engines and video data processors.
SoC internal blocks are described by DT nodes, placed similarly to other SoC blocks. External devices are represented as child nodes of their respective bus controller nodes, e.g. I2C.
Data interfaces on all video devices are described by "port" child DT nodes. Configuration of a port depends on other devices participating in the data transfer and is described by "link" DT nodes, specified as children of the "port" nodes:
/foo {
port at 0 {
link at 0 { ... };
link at 1 { ... };
};
port at 1 { ... };
};If a port can be configured to work with more than one other device on the same bus, a "link" child DT node must be provided for each of them. If more than one port is present on a device or more than one link is connected to a port, a common scheme, using "#address-cells" "#size-cells" and "reg" properties is used.
Documentation/devicetree/bindings/media/v4l2.txt line 23
Quoted 3 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +3
-0+Optional link properties: +- remote: phandle to the other endpoint link DT node. +- data-shift: on parallel data busses, if data-width is used to specify the
s/busses/buses
Documentation/devicetree/bindings/media/v4l2.txt line 32
Quoted 9 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +9
-0+ number of data lines, data-shift can be used to specify which data lines are + used, e.g., "data-width=<10>; data-shift=<2>;" means, that lines 9:2 are used. +- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity + respectively. +- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities are + not specified, embedded synchronisation may be required, where supported. +- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock pin. +- immutable: used for SoC-internal links, if no configuration is required. +- data-lanes: array of serial, e.g., MIPI CSI-2, data hardware lane numbers in
nit: s/e.g.,/e.g. ?
Documentation/devicetree/bindings/media/v4l2.txt line 34
Quoted 2 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +2
-0+ the ascending order, beginning with logical lane 0. +- clock-lanes: hardware lane number, used for the clock lane.
s/clock lane/clock ?
Quoted 43 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +43
-0+ +Example: + + ceu0: ceu at 0xfe910000 { + compatible = "renesas,sh-mobile-ceu"; + reg = <0xfe910000 0xa0>; + interrupts = <0x880>; + + mclk: master_clock { + compatible = "renesas,ceu-clock"; + #clock-cells = <1>; + clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port { + #address-cells = <1>; + #size-cells = <0>; + + ceu0_1: link at 1 { + reg = <1>; /* local link # */ + remote = <&ov772x_1_1>; /* remote phandle */ + bus-width = <8>; /* used data lines */ + data-shift = <0>; /* lines 7:0 are used */ + + /* If [hv]sync-active are missing, embedded bt.605 sync is used */ + hsync-active = <1>; /* active high */ + vsync-active = <1>; /* active high */ + pclk-sample = <1>; /* rising */ + }; + + ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable; + }; + }; + }; + + i2c0: i2c at 0xfff20000 { + ... + ov772x_1: camera at 0x21 { + compatible = "omnivision,ov772x";
Documentation/devicetree/bindings/media/v4l2.txt line 87
Quoted 10 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +10
-0+ reg = <0x21>; + vddio-supply = <®ulator1>; + vddcore-supply = <®ulator2>; + + clock-frequency = <20000000>; + clocks = <&mclk 0>; + clock-names = "xclk"; + + port { + /* With 1 link per port no need in addresses */
s/in/for ?
Quoted 46 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +46
-0+ ov772x_1_1: link { + bus-width = <8>; + remote = <&ceu0_1>; + hsync-active = <1>; + hsync-active = <0>; /* who came up with an inverter here?... */ + pclk-sample = <1>; + }; + }; + }; + + imx074: camera at 0x1a { + compatible = "sony,imx074"; + reg = <0x1a>; + vddio-supply = <®ulator1>; + vddcore-supply = <®ulator2>; + + clock-frequency = <30000000>; /* shared clock with ov772x_1 */ + clocks = <&mclk 0>; + clock-names = "sysclk"; /* assuming this is the name in the datasheet */ + + port { + imx074_1: link { + clock-lanes = <0>; + data-lanes = <1>, <2>; + remote = <&csi2_1>; + }; + }; + }; + }; + + csi2: csi2 at 0xffc90000 { + compatible = "renesas,sh-mobile-csi2"; + reg = <0xffc90000 0x1000>; + interrupts = <0x17a0>; + #address-cells = <1>; + #size-cells = <0>; + + port at 1 { + compatible = "renesas,csi2c"; /* one of CSI2I and CSI2C */ + reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S, PHY_M has port address 0, is unused */ + + csi2_1: link { + clock-lanes = <0>; + data-lanes = <2>, <1>; + remote = <&imx074_1>; + };
Documentation/devicetree/bindings/media/v4l2.txt line 143
Quoted 10 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +10
-0+ }; + port at 2 { + reg = <2>; /* port 2: link to the CEU */ + + csi2_2: link { + immutable; + remote = <&ceu0_0>; + }; + }; + };
--
Regards,
Sylwester
PATCH 1/1 media: add V4L2 DT binding documentation
Hi Sylwester
Ok, looks like there are no more comments coming, so, we can submit a new version:-)
Thanks for your comments:
Quoted 45 lines · Sylwester Nawrocki
Hi Guennadi,
Quoted 24 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>--- Documentation/devicetree/bindings/media/v4l2.txt | 143 ++++++++++++++++++++++ 1 files changed, 143 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/v4l2.txtDocumentation/devicetree/bindings/media/v4l2.txt new file +9
-0@@ -0,0 +1,143 @@ +Video4Linux Version 2 (V4L2) + +General concept: +- video pipelines consist of external devices, e.g., camera sensors, controlled + over an I2C bus, and SoC internal IP blocks, including video DMA engines and + video data processors. +- this document describes common bindings of all video pipeline devices. +- SoC internal blocks are described by DT nodes, placed similarly to other SoC + blocks.Documentation/devicetree/bindings/media/v4l2.txt line 19
Quoted 10 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +10
-0+- external devices are places on their respective control busses, e.g., I2C +- data interfaces on all video devices are described by "port" child DT nodes +- port configuration depends on other devices, participating in the data + transfer, and is described by "link" DT nodes, specified as children of + all "port" nodes, connected to this bus. +- if a port can be configured to work with more than one other device on the + same bus, a "link" child DT node must be provided for each of them. +- if more than one port is present on a device or more than one link is + connected to a port, a common scheme, using "#address-cells," "#size-cells" + and "reg" properties is used.How about rephrasing/rearranging this to:
This document describes common bindings of all video pipeline devices.
General concept
---------------
Quoted 6 lines
Video pipelines consist of external devices, e.g. camera sensors, controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including video DMA engines and video data processors.
SoC internal blocks are described by DT nodes, placed similarly to other SoC blocks. External devices are represented as child nodes of their respective bus controller nodes, e.g. I2C.
Well, I don't mind. I looked at a random file under Documentation/devicetree/bindings and used the same style, but we can use a free-flowing text too.
Quoted 19 lines
Data interfaces on all video devices are described by "port" child DT nodes. Configuration of a port depends on other devices participating in the data transfer and is described by "link" DT nodes, specified as children of the "port" nodes:
/foo { port at 0 { link at 0 { ... }; link at 1 { ... }; }; port at 1 { ... }; };If a port can be configured to work with more than one other device on the same bus, a "link" child DT node must be provided for each of them. If more than one port is present on a device or more than one link is connected to a port, a common scheme, using "#address-cells" "#size-cells" and "reg" properties is used.
Quoted 5 lines
Documentation/devicetree/bindings/media/v4l2.txt line 23
Quoted 3 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +3
-0+Optional link properties: +- remote: phandle to the other endpoint link DT node. +- data-shift: on parallel data busses, if data-width is used to specify thes/busses/buses
Nnnnooo... I think, "busses" is British and "buses" is American English, and I'm usually trying to follow the former, as much as I can:-) Also see "drivers/i2c/busses/"
Quoted 11 lines
Documentation/devicetree/bindings/media/v4l2.txt line 32
Quoted 9 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +9
-0+ number of data lines, data-shift can be used to specify which data lines are + used, e.g., "data-width=<10>; data-shift=<2>;" means, that lines 9:2 are used. +- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity + respectively. +- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities are + not specified, embedded synchronisation may be required, where supported. +- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock pin. +- immutable: used for SoC-internal links, if no configuration is required. +- data-lanes: array of serial, e.g., MIPI CSI-2, data hardware lane numbers innit: s/e.g.,/e.g. ?
This is a good question, actually. Until now I've been following a suggestion by some well-educated British friend of mine, who told me to use commas on either side of "e.g." and "i.e." But in most textx I read I indeed see only one comma - before those. So, I tried to search and got a couple of hits, which suggest, that putting a comma on both sides or at least _after_ those abbreviations is more American grammar, and only before is more British... So, I think I'll follow your advise on this too and switch to the no-comma-after style, thanks.
Quoted 4 lines
Documentation/devicetree/bindings/media/v4l2.txt line 34
Quoted 2 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +2
-0+ the ascending order, beginning with logical lane 0. +- clock-lanes: hardware lane number, used for the clock lane.s/clock lane/clock ?
Well, to me both make sense. The meanings are a bit different, but none seems wrong to me. My version seems a bit more specific - not just "some" clock, but the CSI-2 clock lane?
Quoted 47 lines
Quoted 47 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +47
-0+ +Example: + + ceu0: ceu at 0xfe910000 { + compatible = "renesas,sh-mobile-ceu"; + reg = <0xfe910000 0xa0>; + interrupts = <0x880>; + + mclk: master_clock { + compatible = "renesas,ceu-clock"; + #clock-cells = <1>; + clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port { + #address-cells = <1>; + #size-cells = <0>; + + ceu0_1: link at 1 { + reg = <1>; /* local link # */ + remote = <&ov772x_1_1>; /* remote phandle */ + bus-width = <8>; /* used data lines */ + data-shift = <0>; /* lines 7:0 are used */ + + /* If [hv]sync-active are missing, embedded bt.605 sync is used */ + hsync-active = <1>; /* active high */ + vsync-active = <1>; /* active high */ + pclk-sample = <1>; /* rising */ + }; + + ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable; + }; + }; + }; + + i2c0: i2c at 0xfff20000 { + ... + ov772x_1: camera at 0x21 { + compatible = "omnivision,ov772x"; + reg = <0x21>; + vddio-supply = <®ulator1>; + vddcore-supply = <®ulator2>; +
Quoted 8 lines
Documentation/devicetree/bindings/media/v4l2.txt line 87
Quoted 6 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +6
-0+ clock-frequency = <20000000>; + clocks = <&mclk 0>; + clock-names = "xclk"; + + port { + /* With 1 link per port no need in addresses */s/in/for ?
Ehm, no idea either. Both "no need in" and "no need for" produce enough hits in search engines:-)
Quoted 59 lines
Quoted 46 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +46
-0+ ov772x_1_1: link { + bus-width = <8>; + remote = <&ceu0_1>; + hsync-active = <1>; + hsync-active = <0>; /* who came up with an inverter here?... */ + pclk-sample = <1>; + }; + }; + }; + + imx074: camera at 0x1a { + compatible = "sony,imx074"; + reg = <0x1a>; + vddio-supply = <®ulator1>; + vddcore-supply = <®ulator2>; + + clock-frequency = <30000000>; /* shared clock with ov772x_1 */ + clocks = <&mclk 0>; + clock-names = "sysclk"; /* assuming this is the name in the datasheet */ + + port { + imx074_1: link { + clock-lanes = <0>; + data-lanes = <1>, <2>; + remote = <&csi2_1>; + }; + }; + }; + }; + + csi2: csi2 at 0xffc90000 { + compatible = "renesas,sh-mobile-csi2"; + reg = <0xffc90000 0x1000>; + interrupts = <0x17a0>; + #address-cells = <1>; + #size-cells = <0>; + + port at 1 { + compatible = "renesas,csi2c"; /* one of CSI2I and CSI2C */ + reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S, PHY_M has port address 0, is unused */ + + csi2_1: link { + clock-lanes = <0>; + data-lanes = <2>, <1>; + remote = <&imx074_1>; + };Documentation/devicetree/bindings/media/v4l2.txt line 143
Quoted 10 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +10
-0+ }; + port at 2 { + reg = <2>; /* port 2: link to the CEU */ + + csi2_2: link { + immutable; + remote = <&ceu0_0>; + }; + }; + };--
Quoted 3 lines
Regards,
Sylwester
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
PATCH 1/1 media: add V4L2 DT binding documentation
In reply to Guennadi LiakhovetskiQuoted 4 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>
Overall, I think this looks pretty reasonable, so:
Just a couple comments:
Documentation/devicetree/bindings/media/v4l2.txt line 45
Quoted 7 lines
+++
b/Documentation/devicetree/bindings/media/v4l2.txtDocumentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0: ceu at 0xfe910000 { + mclk: master_clock { + compatible = "renesas,ceu-clock"; + #clock-cells = <1>;
Why 1? If there's only 1 clock output from this provider, I don't see a need for any cells, unless there are some configuration flags?
Quoted 5 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port {
...
Documentation/devicetree/bindings/media/v4l2.txt line 69
Quoted 4 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable;
Did we decide "immutable" was actually needed? Presumably the driver for the HW in question knows the HW isn't configurable, and would simply not attempt to apply any configuration even if the .dts author erroneously provided some?
Quoted 5 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ }; + }; + }; + + i2c0: i2c at 0xfff20000 {
...
Quoted 1 line
Documentation/devicetree/bindings/media/v4l2.txt new file +1
-0+ ov772x_1: camera at 0x21 {
...
Review
Quoted 1 line
(quoted diff) +1
-0+ clocks = <&mclk 0>;
So presumably that could just be "clocks = <&mclk>;"?
PATCH 1/1 media: add V4L2 DT binding documentation
Hi Stephen
Quoted 7 lines · Stephen Warren
Quoted 4 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>Overall, I think this looks pretty reasonable, so:
Good, thanks!
Quoted 6 lines
Acked-by Stephen Warren <[email protected]>Just a couple comments:
Quoted 1 line
+++
b/Documentation/devicetree/bindings/media/v4l2.txt
Quoted 8 lines
Documentation/devicetree/bindings/media/v4l2.txt line 45
Quoted 5 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0: ceu at 0xfe910000 { + mclk: master_clock { + compatible = "renesas,ceu-clock"; + #clock-cells = <1>;Why 1? If there's only 1 clock output from this provider, I don't see a need for any cells, unless there are some configuration flags?
Yes, indeed, that's also what's suggested in the clock bindings documentation, thanks for pointing out.
Quoted 7 lines
Quoted 6 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port {...
Quoted 9 lines
Documentation/devicetree/bindings/media/v4l2.txt line 69
Quoted 4 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable;Did we decide "immutable" was actually needed? Presumably the driver for the HW in question knows the HW isn't configurable, and would simply not attempt to apply any configuration even if the .dts author erroneously provided some?
Well, I've been thinking about this today. I think, bridge drivers will call centrally provided helper functions to enumerate links inside ports. While doing that they will want to differentiate between links to external devices with explicit configuration, and links to internal devices, whose configuration drivers might be able to figure out themselves. How should a driver find out what device this link is pointing to? Should it follow the "remote" phandle and then check the "compatible" property? The word "immutable" is a hint, that this is a link to an internal device, but it might either be unneeded or be transformed into something more informative.
Quoted 11 lines
Quoted 5 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ }; + }; + }; + + i2c0: i2c at 0xfff20000 {...
Quoted 1 line
Documentation/devicetree/bindings/media/v4l2.txt new file +1
-0+ ov772x_1: camera at 0x21 {...
Review
Quoted 1 line
(quoted diff) +1
-0+ clocks = <&mclk 0>;So presumably that could just be "clocks = <&mclk>;"?
Right.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
PATCH 1/1 media: add V4L2 DT binding documentation
Quoted 11 lines · Guennadi Liakhovetski
Hi Stephen
Quoted 7 lines · Stephen Warren
Quoted 4 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>Overall, I think this looks pretty reasonable, so:
...
Quoted 17 lines
Quoted 7 lines
Quoted 6 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port {...
Quoted 9 lines
Documentation/devicetree/bindings/media/v4l2.txt line 69
Quoted 4 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable;Did we decide "immutable" was actually needed? Presumably the driver for the HW in question knows the HW isn't configurable, and would simply not attempt to apply any configuration even if the .dts author erroneously provided some?
Quoted 1 line
Well, I've been thinking about this today. I think, bridge drivers will
Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?
Quoted 1 line
call centrally provided helper functions to enumerate links inside ports.
Presumably a given driver would only parse the ports/links of its own DT node, and hence would be able to provide a parameter to any helper function that indicated the same information that "immutable" would?
Quoted 8 lines
While doing that they will want to differentiate between links to external devices with explicit configuration, and links to internal devices, whose configuration drivers might be able to figure out themselves. How should a driver find out what device this link is pointing to? Should it follow the "remote" phandle and then check the "compatible" property? The word "immutable" is a hint, that this is a link to an internal device, but it might either be unneeded or be transformed into something more informative.
I would imagine that a given driver would only ever parse its own DT node; the far end of any link is purely the domain of the other driver. I thought that each link node would contain whatever hsync-active, data-lanes, ... properties that were needed to configure the local device?
PATCH 1/1 media: add V4L2 DT binding documentation
Quoted 30 lines · Stephen Warren
Quoted 11 lines · Guennadi Liakhovetski
Hi Stephen
Quoted 7 lines · Stephen Warren
Quoted 4 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>Overall, I think this looks pretty reasonable, so:
...
Quoted 17 lines
Quoted 16 lines
Quoted 6 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port {...
Documentation/devicetree/bindings/media/v4l2.txt line 69
Quoted 4 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable;Did we decide "immutable" was actually needed? Presumably the driver for the HW in question knows the HW isn't configurable, and would simply not attempt to apply any configuration even if the .dts author erroneously provided some?
Quoted 3 lines
Quoted 1 line
Well, I've been thinking about this today. I think, bridge drivers will
Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?
Right, sorry for not explaining. We call a bridge a device, that's sitting on a bus like USB, PCI or - as in the SoC case - on an internal one and interfacing to, say, a video sensor or a TV decoder or encoder. In the SoC case most primitive bridges just take data from video sensors attached over, say, an 8-bit parallel bus and DMA it into RAM buffers. Some bridges can also perform some data processing.
Quoted 5 lines
Quoted 1 line
call centrally provided helper functions to enumerate links inside ports.
Presumably a given driver would only parse the ports/links of its own DT node, and hence would be able to provide a parameter to any helper function that indicated the same information that "immutable" would?
Well, let's drop "immutable" for now, since we don't have a good idea whether we need it or not. If we do need it, we'll add it later, removing a part of a standart is more difficult.
Quoted 9 lines
Quoted 8 lines
While doing that they will want to differentiate between links to external devices with explicit configuration, and links to internal devices, whose configuration drivers might be able to figure out themselves. How should a driver find out what device this link is pointing to? Should it follow the "remote" phandle and then check the "compatible" property? The word "immutable" is a hint, that this is a link to an internal device, but it might either be unneeded or be transformed into something more informative.
Quoted 4 lines
I would imagine that a given driver would only ever parse its own DT node; the far end of any link is purely the domain of the other driver. I thought that each link node would contain whatever hsync-active, data-lanes, ... properties that were needed to configure the local device?
I think, information needed to configure a bridge device to connect to a camera sensor, like sync polarities etc., might not be sufficient to configure it to interface to an SoC internal unit, like a MIPI CSI-2 interface. I can see 2 possibilities to recognise, that this link is going to an internal device: (1) follow the remote phandle, (2) use a vendor-specific property to specify the remote device type. I guess, you'd prefer the latter?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
PATCH 1/1 media: add V4L2 DT binding documentation
Quoted 67 lines · Guennadi Liakhovetski
Quoted 30 lines · Stephen Warren
Quoted 11 lines · Guennadi Liakhovetski
Hi Stephen
Quoted 7 lines · Stephen Warren
Quoted 4 lines · Guennadi Liakhovetski
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by Sylwester Nawrocki <[email protected]>Signed-off-by Guennadi Liakhovetski <[email protected]>Overall, I think this looks pretty reasonable, so:
...
Quoted 17 lines
Quoted 16 lines
Quoted 6 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +5
-0+ clock-frequency = <50000000>; /* max clock frequency */ + clock-output-names = "mclk"; + }; + + port {...
Documentation/devicetree/bindings/media/v4l2.txt line 69
Quoted 4 lines
Documentation/devicetree/bindings/media/v4l2.txt new file +4
-0+ ceu0_0: link at 0 { + reg = <0>; + remote = <&csi2_2>; + immutable;Did we decide "immutable" was actually needed? Presumably the driver for the HW in question knows the HW isn't configurable, and would simply not attempt to apply any configuration even if the .dts author erroneously provided some?
Quoted 3 lines
Quoted 1 line
Well, I've been thinking about this today. I think, bridge drivers will
Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?
Right, sorry for not explaining. We call a bridge a device, that's sitting on a bus like USB, PCI or - as in the SoC case - on an internal one and interfacing to, say, a video sensor or a TV decoder or encoder. In the SoC case most primitive bridges just take data from video sensors attached over, say, an 8-bit parallel bus and DMA it into RAM buffers. Some bridges can also perform some data processing.
Quoted 5 lines
Quoted 1 line
call centrally provided helper functions to enumerate links inside ports.
Presumably a given driver would only parse the ports/links of its own DT node, and hence would be able to provide a parameter to any helper function that indicated the same information that "immutable" would?
Well, let's drop "immutable" for now, since we don't have a good idea whether we need it or not. If we do need it, we'll add it later, removing a part of a standart is more difficult.
Quoted 9 lines
Quoted 8 lines
While doing that they will want to differentiate between links to external devices with explicit configuration, and links to internal devices, whose configuration drivers might be able to figure out themselves. How should a driver find out what device this link is pointing to? Should it follow the "remote" phandle and then check the "compatible" property? The word "immutable" is a hint, that this is a link to an internal device, but it might either be unneeded or be transformed into something more informative.
Quoted 4 lines
I would imagine that a given driver would only ever parse its own DT node; the far end of any link is purely the domain of the other driver. I thought that each link node would contain whatever hsync-active, data-lanes, ... properties that were needed to configure the local device?
Quoted 7 lines
I think, information needed to configure a bridge device to connect to a camera sensor, like sync polarities etc., might not be sufficient to configure it to interface to an SoC internal unit, like a MIPI CSI-2 interface. I can see 2 possibilities to recognise, that this link is going to an internal device: (1) follow the remote phandle, (2) use a vendor-specific property to specify the remote device type. I guess, you'd prefer the latter?
I guess I'm still not exactly clear on what/why the bridge device needs to know; a concrete example might help.
Either way though, (2) sounds like it's probably best; all information required to configure a given device is within that device's node.
Being pedantic, I'm not sure precisely what you mean by vendor-specific. If you mean the DT property name would include a vendor prefix, then yes, I imagine that's quite possible, although it'd be good to try and create standardized properties that multiple vendors and devices can use if it makes sense. If you mean something more than that, then I'd argue that those properties aren't just vendor-specific, but rather specific to the individual binding for the individual device (which does imply the vendor prefix, but not the general applicability of the property to all of a vendor's devices).