Re: [RFC/PATCH 04/13] devicetree: Add common video devices bindings documentation

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

On Fri, 25 May 2012, Sylwester Nawrocki wrote:

> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  Documentation/devicetree/bindings/video/video.txt |   10 ++++++++++
>  1 file changed, 10 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/video.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/video.txt b/Documentation/devicetree/bindings/video/video.txt
> new file mode 100644
> index 0000000..9f6a637
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/video.txt
> @@ -0,0 +1,10 @@
> +Common properties of video data source devices (image sensor, video encoders, etc.)
> +
> +Video bus types
> +---------------
> +
> +- video-bus-type : must be one of:
> +
> +    - itu-601   : parallel bus with HSYNC and VSYNC - ITU-R BT.601;
> +    - itu-656   : parallel bus with embedded synchronization - ITU-R BT.656;

wikipedia tells me, that bt.601 is mostly a data encoding standard, it 
also defines bus-types, but recent versions also include serial busses.

> +    - mipi-csi2 : MIPI-CSI2 serial bus;

In general: are these at all needed? Wouldn't it be better to specify pads 
on sensors and interfaces to differentiate between serial and parallel 
connections. As for whether HSYNC and VSYNC are used - I see 3 
possibilities there:

1. real sync signals are used - the default.

2. embedded syncs shall be used, because sync signals are missing. This 
should (arguably) be derived from pinctrl - see this discussion:

http://lkml.indiana.edu/hypermail/linux/kernel/1205.2/index.html#03893

3. sync signals are present, but cannot be used, because one of the 
partners doesn't support them - .g_mbus_config() can be used to retrieve 
this information.

4. sync signals are available and supported by both peers, but for some 
reason the user prefers to use embedded sync data - is such a case 
feasible? Even if so, this should be run-time configurable then?

So, maybe we don't need these at all.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/