Hi Pavel,

On Fri, Feb 10, 2017 at 08:54:35PM +0100, Pavel Machek wrote:

quoted

quoted

quoted

quoted

quoted

diff --git a/Documentation/devicetree/bindings/media/video-bus-switch.txt b/Documentation/devicetree/bindings/media/video-bus-switch.txt
new file mode 100644
index 0000000..1b9f8e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-bus-switch.txt

@@ -0,0 +1,63 @@
+Video Bus Switch Binding
+========================

I'd call it a mux rather than switch.

It is a switch, not a multiplexor (
https://en.wikipedia.org/wiki/Multiplexing ). Only one camera can
operate at a time.

It's no different than an i2c mux. It's one at a time.

Take a look at the wikipedia. If you do "one at a time" at 100Hz, you
can claim it is time-domain multiplex. But we are plain switching the
cameras. It takes second (or so) to setup the pipeline.

This is not multiplex.

The functionality is still the same, isn't it? Does it change what it is if
the frequency might be 100 Hz or 0,01 Hz?

I was a bit annoyed for having to have two drivers for switching the source
(one for GPIO, another for syscon / register), where both of the drivers
would be essentially the same with the minor exception of having a slightly
different means to toggle the mux setting.

The MUX framework adds an API for controlling the MUX. Thus we'll need only
a single driver that uses the MUX framework API for V4L2. As an added bonus,
V4L2 would be in line with the rest of the MUX usage in the kernel.

The set appears to already contain a GPIO MUX. What's needed would be to use
the MUX API instead of direct GPIOs usage.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html