Preparation for adding the mux subsystem to the driver-api documenation. Signed-off-by: Peter Rosin <p...@axentia.se> --- drivers/mux/core.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
diff --git a/drivers/mux/core.c b/drivers/mux/core.c index d1271c1ee23c..ccb5479f8a39 100644 --- a/drivers/mux/core.c +++ b/drivers/mux/core.c @@ -7,6 +7,43 @@ * Author: Peter Rosin <p...@axentia.se> */ +/** + * DOC: overview + * + * The multiplexer subsystem uses the following naming: + * + * - Multiplexer controller: the piece of hardware that changes the + * state of a hardware multiplexer (or indeed, several parallel + * multiplexers). + * + * - Multiplexer chip: a collection of multiplexer controllers, in a chip. + * + * - Multiplexer driver: the device driver that interacts with and handles the + * above hardware. The driver has structures representing a mux chip and mux + * controllers. + * + * - Multiplexer consumer: the driver that needs to manipulate the hardware + * multiplexer. + * + * The mux subsystem provides a framework for multiplexer drivers that can + * be used by other consumer drivers. It has two primary purposes. + * + * First, when a consumer driver can be used with one of several multiplexers, + * depending on hardware configuration, the actual multiplexer is abstracted + * away in the mux drivers. The multiplexer consumer driver can be neater + * this way. + * + * Second, when two consumers -- possibly from different subsystems -- compete + * for the same mux controller, i.e. when one mux controller muxes more than + * one signal, the mux framework provides locking. + * + * If the mux driver is so special that it will only ever have a single + * consumer, and that consumer can really only work with that one mux driver, + * the mux framework is not really providing much benefit. It might be a better + * idea to simply manipulate the mux hardware directly from the consumer + * driver. + */ + #define pr_fmt(fmt) "mux-core: " fmt #include <linux/device.h> -- 2.11.0
