Hi Guennadi,
On 09/27/2012 04:07 PM, Guennadi Liakhovetski wrote:
> This patch adds a document, describing common V4L2 device tree bindings.
>
> Co-authored-by: Sylwester Nawrocki<s.nawrocki@xxxxxxxxxxx>
> Signed-off-by: Guennadi Liakhovetski<g.liakhovetski@xxxxxx>
> ---
> 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)
> +
> +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@0 {
> + link@0 { ... };
> + link@1 { ... };
> + };
> + port@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.
> +- 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.
It is not very clear we are using common contiguous range of logical indexes
for the clock and the data lanes, IMO. Maybe something like this would be
more explicit:
- data-lanes: an array of hardware data lane indexes. Position of an entry
determines logical lane number, while the value of an entry indicates hardware
lane number, e.g. for 2-lane MIPI CSI-2 bus we could have data-lanes = <1>, <2>;,
assuming the clock lane is on hardware lane 0. This property is applicable to
serial buses only (e.g. MIPI CSI-2).
?
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
