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

[Sylwester Nawrocki]

Hi Guennadi,

On 07/16/2012 11:09 AM, Guennadi Liakhovetski wrote:
> On Fri, 25 May 2012, Sylwester Nawrocki wrote:
> 
>> Signed-off-by: Sylwester Nawrocki<s.nawrocki at samsung.com>
>> Signed-off-by: Kyungmin Park<kyungmin.park at 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.

Hmm, indeed, I got slightly misled by the Samsung SoCs' User Manuals 
that used bt.601/bt.656 to distinguish between bus with sync signals
and with embedded sync.

>> +    - 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

We have video buses and data receivers and transmitters attached to them.
The pads concept doesn't quite fit here for me. Specifying possible links 
with character string tags might be a way to go, but I'd like to hear
others' opinion on that. Do we have any bindings already that do something
similar ?

> 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

Hmm, I'm not terribly familiar with pinctrl API, but wouldn't it be 
required to have two pin group names: (data + clock + sync) signals and
(data + clock) (for embedded video synchronization) ? We would have to name
these two configurations somehow anyway, wouldn't we ?

Also, as Stephen pointed out, the control flow is supposed to be from
drivers to pin controller, not the other way around.

> 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.

OK.

> 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?

I've never seen such a situation. I would expect that if sync signal wires 
are routed, they shall be used. Otherwise only embedded synchronization
would be used, to save PCB area.
 
> So, maybe we don't need these at all.

We need something that would let drivers distinguish which (serial/
parallel) bus is supported on a board. And what type of synchronization
is used. I'm fine as long as this can be specified reliably in DT and
drivers of the transmitters/receivers can configure their output/input
interfaces. I'm not against dynamic configuration but static one also
need to be supported.

--
Regards,
Sylwester