devicetree: Add video bus switch

  N900 contains front and back camera, with a switch between the
two. This adds support for the switch component, and it is now
possible to select between front and back cameras during runtime.

This adds documentation for the devicetree binding.

Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
  

Hi Pavel,

My apologies for the delays in reviewing. Feel free to ping me in the future
if this happens. :-)

On Fri, Feb 03, 2017 at 01:35:08PM +0100, Pavel Machek wrote:
> 
> N900 contains front and back camera, with a switch between the
> two. This adds support for the switch component, and it is now
> possible to select between front and back cameras during runtime.
> 
> This adds documentation for the devicetree binding.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> 
> 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
> +========================
> +
> +This is a binding for a gpio controlled switch for camera interfaces. Such a
> +device is used on some embedded devices to connect two cameras to the same
> +interface of a image signal processor.
> +
> +Required properties
> +===================
> +
> +compatible	: must contain "video-bus-switch"

How generic is this? Should we have e.g. nokia,video-bus-switch? And if so,
change the file name accordingly.

> +switch-gpios	: GPIO specifier for the gpio, which can toggle the
> +		  selected camera. The GPIO should be configured, so
> +		  that a disabled GPIO means, that the first port is
> +		  selected.
> +
> +Required Port nodes
> +===================
> +
> +More documentation on these bindings is available in
> +video-interfaces.txt in the same directory.
> +
> +reg		: The interface:
> +		  0 - port for image signal processor
> +		  1 - port for first camera sensor
> +		  2 - port for second camera sensor

I'd say this must be pretty much specific to the one in N900. You could have
more ports. Or you could say that ports beyond 0 are camera sensors. I guess
this is good enough for now though, it can be changed later on with the
source if a need arises.

Btw. was it still considered a problem that the endpoint properties for the
sensors can be different? With the g_routing() pad op which is to be added,
the ISP driver (should actually go to a framework somewhere) could parse the
graph and find the proper endpoint there.

I don't think we need to wait for that now, but this is how the problem
could be solved going forward.

> +
> +Example
> +=======
> +
> +video-bus-switch {
> +	compatible = "video-bus-switch"
> +	switch-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port@0 {
> +			reg = <0>;
> +
> +			csi_switch_in: endpoint {
> +				remote-endpoint = <&csi_isp>;
> +			};
> +		};
> +
> +		port@1 {
> +			reg = <1>;
> +
> +			csi_switch_out1: endpoint {
> +				remote-endpoint = <&csi_cam1>;
> +			};
> +		};
> +
> +		port@2 {
> +			reg = <2>;
> +
> +			csi_switch_out2: endpoint {
> +				remote-endpoint = <&csi_cam2>;
> +			};
> +		};
> +	};
> +};
> 
> 
>
  

On Friday 03 February 2017 13:35:08 Pavel Machek wrote:
> N900 contains front and back camera, with a switch between the
> two. This adds support for the switch component, and it is now
> possible to select between front and back cameras during runtime.

IIRC for controlling cameras on N900 there are two GPIOs. Should not you
have both in switch driver?
  

On Fri 2017-02-03 14:32:19, Pali Rohár wrote:
> On Friday 03 February 2017 13:35:08 Pavel Machek wrote:
> > N900 contains front and back camera, with a switch between the
> > two. This adds support for the switch component, and it is now
> > possible to select between front and back cameras during runtime.
> 
> IIRC for controlling cameras on N900 there are two GPIOs. Should not you
> have both in switch driver?

I guess you recall wrongly :-). Switch seems to work. The issue was
with switch GPIO also serving as reset GPIO for one sensor, or
something like that, if _I_ recall correctly ;-).

Best regards,
									Pavel
  

Hi,

On Fri, Feb 03, 2017 at 10:07:28PM +0100, Pavel Machek wrote:
> On Fri 2017-02-03 14:32:19, Pali Rohár wrote:
> > On Friday 03 February 2017 13:35:08 Pavel Machek wrote:
> > > N900 contains front and back camera, with a switch between the
> > > two. This adds support for the switch component, and it is now
> > > possible to select between front and back cameras during runtime.
> > 
> > IIRC for controlling cameras on N900 there are two GPIOs. Should
> > not you have both in switch driver?
>
> I guess you recall wrongly :-). Switch seems to work. The issue was
> with switch GPIO also serving as reset GPIO for one sensor, or
> something like that, if _I_ recall correctly ;-).

I have a schematic in my master thesis, which shows how the camera
sensors are connected to the SoC. The PDF is available here:

https://www.uni-oldenburg.de/fileadmin/user_upload/informatik/ag/svs/download/thesis/Reichel_Sebastian.pdf

The schematic is on page 37 (or 45 if your PDF reader does not
use different numbers for the preamble stuff).

--Sebastian
  

On Fri, Feb 03, 2017 at 01:35:08PM +0100, Pavel Machek wrote:
> 
> N900 contains front and back camera, with a switch between the
> two. This adds support for the switch component, and it is now
> possible to select between front and back cameras during runtime.
> 
> This adds documentation for the devicetree binding.
> 
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> 
> 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.

BTW, there's a new mux-controller binding under review you might look 
at. It would only be needed here if the mux ctrl also controls other 
things.

> +
> +This is a binding for a gpio controlled switch for camera interfaces. Such a
> +device is used on some embedded devices to connect two cameras to the same
> +interface of a image signal processor.
> +
> +Required properties
> +===================
> +
> +compatible	: must contain "video-bus-switch"

video-bus-gpio-mux

> +switch-gpios	: GPIO specifier for the gpio, which can toggle the

mux-gpios to align with existing GPIO controlled muxes.

> +		  selected camera. The GPIO should be configured, so
> +		  that a disabled GPIO means, that the first port is
> +		  selected.
> +
> +Required Port nodes
> +===================
> +
> +More documentation on these bindings is available in
> +video-interfaces.txt in the same directory.
> +
> +reg		: The interface:
> +		  0 - port for image signal processor
> +		  1 - port for first camera sensor
> +		  2 - port for second camera sensor

This could be used for display side as well. So describe these just as 
inputs and outputs.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Wed 2017-02-08 15:36:09, Rob Herring wrote:
> On Fri, Feb 03, 2017 at 01:35:08PM +0100, Pavel Machek wrote:
> > 
> > N900 contains front and back camera, with a switch between the
> > two. This adds support for the switch component, and it is now
> > possible to select between front and back cameras during runtime.
> > 
> > This adds documentation for the devicetree binding.
> > 
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > 
> > 
> > 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.

> BTW, there's a new mux-controller binding under review you might look 
> at. It would only be needed here if the mux ctrl also controls other 
> things.

Do you have a pointer?

> > +Required Port nodes
> > +===================
> > +
> > +More documentation on these bindings is available in
> > +video-interfaces.txt in the same directory.
> > +
> > +reg		: The interface:
> > +		  0 - port for image signal processor
> > +		  1 - port for first camera sensor
> > +		  2 - port for second camera sensor
> 
> This could be used for display side as well. So describe these just as 
> inputs and outputs.

I'd prefer not to confuse people. I guess that would be 0 -- output
port, 1, 2 -- input ports... But this is media data, are you sure it
is good idea to change this?

									Pavel
  

> > +
> > +This is a binding for a gpio controlled switch for camera interfaces. Such a
> > +device is used on some embedded devices to connect two cameras to the same
> > +interface of a image signal processor.
> > +
> > +Required properties
> > +===================
> > +
> > +compatible	: must contain "video-bus-switch"
> 
> video-bus-gpio-mux

Sakari already asked for rename here. I believe I waited reasonable
time, but got no input from you, so I did rename it. Now you decide on
different name.

Can we either get timely reactions or less bikeshedding?

Thanks,

                                                                Pavel
  

On Wed, Feb 8, 2017 at 4:34 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> > +
>> > +This is a binding for a gpio controlled switch for camera interfaces. Such a
>> > +device is used on some embedded devices to connect two cameras to the same
>> > +interface of a image signal processor.
>> > +
>> > +Required properties
>> > +===================
>> > +
>> > +compatible : must contain "video-bus-switch"
>>
>> video-bus-gpio-mux
>
> Sakari already asked for rename here. I believe I waited reasonable
> time, but got no input from you, so I did rename it. Now you decide on
> different name.
>
> Can we either get timely reactions or less bikeshedding?

You mean less than 5 days because I don't see any other version of
this? But in short, no, you can't.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Wed, Feb 8, 2017 at 4:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Wed 2017-02-08 15:36:09, Rob Herring wrote:
>> On Fri, Feb 03, 2017 at 01:35:08PM +0100, Pavel Machek wrote:
>> >
>> > N900 contains front and back camera, with a switch between the
>> > two. This adds support for the switch component, and it is now
>> > possible to select between front and back cameras during runtime.
>> >
>> > This adds documentation for the devicetree binding.
>> >
>> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
>> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
>> >
>> >
>> > 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.

>
>> BTW, there's a new mux-controller binding under review you might look
>> at. It would only be needed here if the mux ctrl also controls other
>> things.
>
> Do you have a pointer?

Let me Google that for you:

>
>> > +Required Port nodes
>> > +===================
>> > +
>> > +More documentation on these bindings is available in
>> > +video-interfaces.txt in the same directory.
>> > +
>> > +reg                : The interface:
>> > +             0 - port for image signal processor
>> > +             1 - port for first camera sensor
>> > +             2 - port for second camera sensor
>>
>> This could be used for display side as well. So describe these just as
>> inputs and outputs.
>
> I'd prefer not to confuse people. I guess that would be 0 -- output
> port, 1, 2 -- input ports... But this is media data, are you sure it
> is good idea to change this?

And I'd prefer something that can be reused by others.

>
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Thu, Feb 9, 2017 at 5:02 PM, Rob Herring <robh@kernel.org> wrote:
> On Wed, Feb 8, 2017 at 4:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> On Wed 2017-02-08 15:36:09, Rob Herring wrote:
>>> On Fri, Feb 03, 2017 at 01:35:08PM +0100, Pavel Machek wrote:
>>> >
>>> > N900 contains front and back camera, with a switch between the
>>> > two. This adds support for the switch component, and it is now
>>> > possible to select between front and back cameras during runtime.
>>> >
>>> > This adds documentation for the devicetree binding.
>>> >
>>> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
>>> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>>> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
>>> >
>>> >
>>> > 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.
>
>>
>>> BTW, there's a new mux-controller binding under review you might look
>>> at. It would only be needed here if the mux ctrl also controls other
>>> things.
>>
>> Do you have a pointer?
>
> Let me Google that for you:

https://lwn.net/Articles/713971/

>
>>
>>> > +Required Port nodes
>>> > +===================
>>> > +
>>> > +More documentation on these bindings is available in
>>> > +video-interfaces.txt in the same directory.
>>> > +
>>> > +reg                : The interface:
>>> > +             0 - port for image signal processor
>>> > +             1 - port for first camera sensor
>>> > +             2 - port for second camera sensor
>>>
>>> This could be used for display side as well. So describe these just as
>>> inputs and outputs.
>>
>> I'd prefer not to confuse people. I guess that would be 0 -- output
>> port, 1, 2 -- input ports... But this is media data, are you sure it
>> is good idea to change this?
>
> And I'd prefer something that can be reused by others.
>
>>
>>                                                                         Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

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

									Pavel
  

On Thu 2017-02-09 16:58:29, Rob Herring wrote:
> On Wed, Feb 8, 2017 at 4:34 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> > +
> >> > +This is a binding for a gpio controlled switch for camera interfaces. Such a
> >> > +device is used on some embedded devices to connect two cameras to the same
> >> > +interface of a image signal processor.
> >> > +
> >> > +Required properties
> >> > +===================
> >> > +
> >> > +compatible : must contain "video-bus-switch"
> >>
> >> video-bus-gpio-mux
> >
> > Sakari already asked for rename here. I believe I waited reasonable
> > time, but got no input from you, so I did rename it. Now you decide on
> > different name.
> >
> > Can we either get timely reactions or less bikeshedding?
> 
> You mean less than 5 days because I don't see any other version of
> this? But in short, no, you can't.

Could we switch device tree bindings from "cc: subsystem, to: device
tree" to "to: subsystem, cc: device tree" mode? Currently it takes
more effort to merge the device tree parts than the relevant driver,
and that is not quite good.

Best regards,
								Pavel
  

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.
  

Hi!

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

Well. In your living your you can have a switch, which is switch at
much less than 0.01Hz. You can also have a dimmer, which is a PWM,
which is switch at 100Hz or so. So yes, I'd say switch and mux are
different things.

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

Well, most of the video-bus-switch is the video4linux glue. Actual
switching is very very small part. So.. where is the other driver?
Looks like we have the same problem.

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

If there's a driver that already does switching for video4linux
devices? Do you have a pointer?

								Pavel
  

Hi Pavel,

On Mon, Feb 13, 2017 at 10:54:20AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > 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?
> 
> Well. In your living your you can have a switch, which is switch at
> much less than 0.01Hz. You can also have a dimmer, which is a PWM,
> which is switch at 100Hz or so. So yes, I'd say switch and mux are
> different things.

Light switches are mostly on/off switches. It'd be interesting to have a
light switch that you could use to light either of the light bulbs in a room
but not to switch both of them on at the same time. Or off... :-)

I wonder if everyone would be happy with a statement saying that it's a
on / on switch which is used to implement a multiplexer?

> 
> > 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.
> 
> Well, most of the video-bus-switch is the video4linux glue. Actual
> switching is very very small part. So.. where is the other driver?
> Looks like we have the same problem.

It's here, slightly hidden in plain sight in the same patch with the MUX
framework:

<URL:https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1328763.html>

> 
> > 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.
> 
> If there's a driver that already does switching for video4linux
> devices? Do you have a pointer?

I don't think there's one. But with MUX API, we'll be fine using a single
driver instead of two (other one for syscon on iMX).

Cc Steve and Philipp.
  

On Mon 2017-02-13 12:20:35, Sakari Ailus wrote:
> Hi Pavel,
> 
> On Mon, Feb 13, 2017 at 10:54:20AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > 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?
> > 
> > Well. In your living your you can have a switch, which is switch at
> > much less than 0.01Hz. You can also have a dimmer, which is a PWM,
> > which is switch at 100Hz or so. So yes, I'd say switch and mux are
> > different things.
> 
> Light switches are mostly on/off switches. It'd be interesting to have a
> light switch that you could use to light either of the light bulbs in a room
> but not to switch both of them on at the same time. Or off... :-)
> 
> I wonder if everyone would be happy with a statement saying that it's a
> on / on switch which is used to implement a multiplexer?

I believe the difference is the timescale. If it switches "slow" it is
a switch. If it switches fast, it is a dimmer, mux, or something....

Anyway, someone else was faster, so they get to name their creation...

									Pavel