mux-controller.txt 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157
  1. Common multiplexer controller bindings
  2. ======================================
  3. A multiplexer (or mux) controller will have one, or several, consumer devices
  4. that uses the mux controller. Thus, a mux controller can possibly control
  5. several parallel multiplexers. Presumably there will be at least one
  6. multiplexer needed by each consumer, but a single mux controller can of course
  7. control several multiplexers for a single consumer.
  8. A mux controller provides a number of states to its consumers, and the state
  9. space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
  10. 0-7 for an 8-way multiplexer, etc.
  11. Consumers
  12. ---------
  13. Mux controller consumers should specify a list of mux controllers that they
  14. want to use with a property containing a 'mux-ctrl-list':
  15. mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
  16. single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
  17. mux-ctrl-phandle : phandle to mux controller node
  18. mux-ctrl-specifier : array of #mux-control-cells specifying the
  19. given mux controller (controller specific)
  20. Mux controller properties should be named "mux-controls". The exact meaning of
  21. each mux controller property must be documented in the device tree binding for
  22. each consumer. An optional property "mux-control-names" may contain a list of
  23. strings to label each of the mux controllers listed in the "mux-controls"
  24. property.
  25. Drivers for devices that use more than a single mux controller can use the
  26. "mux-control-names" property to map the name of the requested mux controller
  27. to an index into the list given by the "mux-controls" property.
  28. mux-ctrl-specifier typically encodes the chip-relative mux controller number.
  29. If the mux controller chip only provides a single mux controller, the
  30. mux-ctrl-specifier can typically be left out.
  31. Example:
  32. /* One consumer of a 2-way mux controller (one GPIO-line) */
  33. mux: mux-controller {
  34. compatible = "gpio-mux";
  35. #mux-control-cells = <0>;
  36. mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>;
  37. };
  38. adc-mux {
  39. compatible = "io-channel-mux";
  40. io-channels = <&adc 0>;
  41. io-channel-names = "parent";
  42. mux-controls = <&mux>;
  43. mux-control-names = "adc";
  44. channels = "sync", "in";
  45. };
  46. Note that in the example above, specifying the "mux-control-names" is redundant
  47. because there is only one mux controller in the list. However, if the driver
  48. for the consumer node in fact asks for a named mux controller, that name is of
  49. course still required.
  50. /*
  51. * Two consumers (one for an ADC line and one for an i2c bus) of
  52. * parallel 4-way multiplexers controlled by the same two GPIO-lines.
  53. */
  54. mux: mux-controller {
  55. compatible = "gpio-mux";
  56. #mux-control-cells = <0>;
  57. mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
  58. <&pioA 1 GPIO_ACTIVE_HIGH>;
  59. };
  60. adc-mux {
  61. compatible = "io-channel-mux";
  62. io-channels = <&adc 0>;
  63. io-channel-names = "parent";
  64. mux-controls = <&mux>;
  65. channels = "sync-1", "in", "out", "sync-2";
  66. };
  67. i2c-mux {
  68. compatible = "i2c-mux";
  69. i2c-parent = <&i2c1>;
  70. mux-controls = <&mux>;
  71. #address-cells = <1>;
  72. #size-cells = <0>;
  73. i2c@0 {
  74. reg = <0>;
  75. #address-cells = <1>;
  76. #size-cells = <0>;
  77. ssd1307: oled@3c {
  78. /* ... */
  79. };
  80. };
  81. i2c@3 {
  82. reg = <3>;
  83. #address-cells = <1>;
  84. #size-cells = <0>;
  85. pca9555: pca9555@20 {
  86. /* ... */
  87. };
  88. };
  89. };
  90. Mux controller nodes
  91. --------------------
  92. Mux controller nodes must specify the number of cells used for the
  93. specifier using the '#mux-control-cells' property.
  94. Optionally, mux controller nodes can also specify the state the mux should
  95. have when it is idle. The idle-state property is used for this. If the
  96. idle-state is not present, the mux controller is typically left as is when
  97. it is idle. For multiplexer chips that expose several mux controllers, the
  98. idle-state property is an array with one idle state for each mux controller.
  99. The special value (-1) may be used to indicate that the mux should be left
  100. as is when it is idle. This is the default, but can still be useful for
  101. mux controller chips with more than one mux controller, particularly when
  102. there is a need to "step past" a mux controller and set some other idle
  103. state for a mux controller with a higher index.
  104. Some mux controllers have the ability to disconnect the input/output of the
  105. multiplexer. Using this disconnected high-impedance state as the idle state
  106. is indicated with idle state (-2).
  107. These constants are available in
  108. #include <dt-bindings/mux/mux.h>
  109. as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2).
  110. An example mux controller node look like this (the adg972a chip is a triple
  111. 4-way multiplexer):
  112. mux: mux-controller@50 {
  113. compatible = "adi,adg792a";
  114. reg = <0x50>;
  115. #mux-control-cells = <1>;
  116. idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>;
  117. };