summaryrefslogtreecommitdiffstats
path: root/sound/soc/codecs/lm4857.c
diff options
context:
space:
mode:
authorLars-Peter Clausen <lars@metafoo.de>2015-05-01 18:02:43 +0200
committerMark Brown <broonie@kernel.org>2015-05-06 18:31:02 +0200
commitd714f97c5b8c4c5da56b89a7289acb3f12ef7abb (patch)
tree814ea8f11899bff80e966bb64dfc394742d61de1 /sound/soc/codecs/lm4857.c
parentASoC: dapm: Add new widgets to the end of the widget list (diff)
downloadlinux-d714f97c5b8c4c5da56b89a7289acb3f12ef7abb.tar.xz
linux-d714f97c5b8c4c5da56b89a7289acb3f12ef7abb.zip
ASoC: dapm: Add demux support
A demux is conceptually similar to a mux. Where a mux has multiple input and one output and selects one of the inputs to be connected to the output, the demux has one input and multiple outputs and selects one of the outputs to which the input gets connected. This similarity makes it straight forward to support them in DAPM using the existing mux support, we only need to swap sinks and sources when initially setting up the paths. The only slightly tricky part is that there can only be one control per path. Since mixers/muxes are at the sink of a path and a demux is at the source and both types want a control it is not possible to directly connect a demux output to a mixer/mux input. The patch adds some sanity checks to make sure that this does not happen. Drivers who want to model hardware which directly connects a demux output to a mixer/mux input can do this by inserting a dummy widget between the two. E.g.: { "Dummy", "Demux Control", "Demux" }, { "Mixer", "Mixer Control", "Dummy" }, Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'sound/soc/codecs/lm4857.c')
0 files changed, 0 insertions, 0 deletions