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@xxxxxxxxxxx> >> Signed-off-by: Kyungmin Park<kyungmin.park@xxxxxxxxxxx> >> --- >> 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 -- 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
