| Common multiplexer controller bindings | |
| ====================================== | |
| A multiplexer (or mux) controller will have one, or several, consumer devices | |
| that uses the mux controller. Thus, a mux controller can possibly control | |
| several parallel multiplexers. Presumably there will be at least one | |
| multiplexer needed by each consumer, but a single mux controller can of course | |
| control several multiplexers for a single consumer. | |
| A mux controller provides a number of states to its consumers, and the state | |
| space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, | |
| 0-7 for an 8-way multiplexer, etc. | |
| Consumers | |
| --------- | |
| Mux controller consumers should specify a list of mux controllers that they | |
| want to use with a property containing a 'mux-ctrl-list': | |
| mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list] | |
| single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier] | |
| mux-ctrl-phandle : phandle to mux controller node | |
| mux-ctrl-specifier : array of #mux-control-cells specifying the | |
| given mux controller (controller specific) | |
| Mux controller properties should be named "mux-controls". The exact meaning of | |
| each mux controller property must be documented in the device tree binding for | |
| each consumer. An optional property "mux-control-names" may contain a list of | |
| strings to label each of the mux controllers listed in the "mux-controls" | |
| property. | |
| Drivers for devices that use more than a single mux controller can use the | |
| "mux-control-names" property to map the name of the requested mux controller | |
| to an index into the list given by the "mux-controls" property. | |
| mux-ctrl-specifier typically encodes the chip-relative mux controller number. | |
| If the mux controller chip only provides a single mux controller, the | |
| mux-ctrl-specifier can typically be left out. | |
| Example: | |
| /* One consumer of a 2-way mux controller (one GPIO-line) */ | |
| mux: mux-controller { | |
| compatible = "gpio-mux"; | |
| #mux-control-cells = <0>; | |
| mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; | |
| }; | |
| adc-mux { | |
| compatible = "io-channel-mux"; | |
| io-channels = <&adc 0>; | |
| io-channel-names = "parent"; | |
| mux-controls = <&mux>; | |
| mux-control-names = "adc"; | |
| channels = "sync", "in"; | |
| }; | |
| Note that in the example above, specifying the "mux-control-names" is redundant | |
| because there is only one mux controller in the list. However, if the driver | |
| for the consumer node in fact asks for a named mux controller, that name is of | |
| course still required. | |
| /* | |
| * Two consumers (one for an ADC line and one for an i2c bus) of | |
| * parallel 4-way multiplexers controlled by the same two GPIO-lines. | |
| */ | |
| mux: mux-controller { | |
| compatible = "gpio-mux"; | |
| #mux-control-cells = <0>; | |
| mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, | |
| <&pioA 1 GPIO_ACTIVE_HIGH>; | |
| }; | |
| adc-mux { | |
| compatible = "io-channel-mux"; | |
| io-channels = <&adc 0>; | |
| io-channel-names = "parent"; | |
| mux-controls = <&mux>; | |
| channels = "sync-1", "in", "out", "sync-2"; | |
| }; | |
| i2c-mux { | |
| compatible = "i2c-mux"; | |
| i2c-parent = <&i2c1>; | |
| mux-controls = <&mux>; | |
| #address-cells = <1>; | |
| #size-cells = <0>; | |
| i2c@0 { | |
| reg = <0>; | |
| #address-cells = <1>; | |
| #size-cells = <0>; | |
| ssd1307: oled@3c { | |
| /* ... */ | |
| }; | |
| }; | |
| i2c@3 { | |
| reg = <3>; | |
| #address-cells = <1>; | |
| #size-cells = <0>; | |
| pca9555: pca9555@20 { | |
| /* ... */ | |
| }; | |
| }; | |
| }; | |
| Mux controller nodes | |
| -------------------- | |
| Mux controller nodes must specify the number of cells used for the | |
| specifier using the '#mux-control-cells' property. | |
| Optionally, mux controller nodes can also specify the state the mux should | |
| have when it is idle. The idle-state property is used for this. If the | |
| idle-state is not present, the mux controller is typically left as is when | |
| it is idle. For multiplexer chips that expose several mux controllers, the | |
| idle-state property is an array with one idle state for each mux controller. | |
| The special value (-1) may be used to indicate that the mux should be left | |
| as is when it is idle. This is the default, but can still be useful for | |
| mux controller chips with more than one mux controller, particularly when | |
| there is a need to "step past" a mux controller and set some other idle | |
| state for a mux controller with a higher index. | |
| Some mux controllers have the ability to disconnect the input/output of the | |
| multiplexer. Using this disconnected high-impedance state as the idle state | |
| is indicated with idle state (-2). | |
| These constants are available in | |
| #include <dt-bindings/mux/mux.h> | |
| as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). | |
| An example mux controller node look like this (the adg972a chip is a triple | |
| 4-way multiplexer): | |
| mux: mux-controller@50 { | |
| compatible = "adi,adg792a"; | |
| reg = <0x50>; | |
| #mux-control-cells = <1>; | |
| idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>; | |
| }; |