[PATCH 04/14] media: add V4L2 DT binding documentation
Rob Herring
robherring2 at gmail.com
Wed Oct 3 00:15:34 EST 2012
On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> This patch adds a document, describing common V4L2 device tree bindings.
>
> Co-authored-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> ---
> Documentation/devicetree/bindings/media/v4l2.txt | 162 ++++++++++++++++++++++
> 1 files changed, 162 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
>
> diff --git a/Documentation/devicetree/bindings/media/v4l2.txt b/Documentation/devicetree/bindings/media/v4l2.txt
> new file mode 100644
> index 0000000..b8b3f41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/v4l2.txt
> @@ -0,0 +1,162 @@
> +Video4Linux Version 2 (V4L2)
DT describes the h/w, but V4L2 is Linux specific. I think the binding
looks pretty good in terms of it is describing the h/w and not V4L2
components or settings. So in this case it's really just the name of the
file and title I have issue with.
One other comment below:
> +
> +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.
> +
> +Optional link properties:
> +- remote: phandle to the other endpoint link DT node.
This name is a little vague. Perhaps "endpoint" would be better.
Rob
> +- slave-mode: a boolean property, run the link in slave mode. Default is master
> + mode.
> +- 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.
> +- data-active: similar to HSYNC and VSYNC specifies data line polarity.
> +- field-even-active: field signal level during the even field data transmission.
> +- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock pin.
> +- 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.
> +- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
> + clock mode.
> +
> +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 */
> + data-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>;
> + vsync-active = <0>; /* who came up with an inverter here?... */
> + data-active = <1>;
> + 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>;
> + };
> + };
> + };
>
More information about the devicetree-discuss
mailing list