Hi Pavel, On Fri, Feb 10, 2017 at 08:54:35PM +0100, Pavel Machek wrote: > > > >>> > 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@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- 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
