Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 5月, 2015 6 次提交
  3. 15 5月, 2015 9 次提交
  5. 12 5月, 2015 12 次提交
  7. 11 5月, 2015 1 次提交
  9. 08 5月, 2015 1 次提交
  11. 07 5月, 2015 4 次提交
    • L
      ASoC: dapm: Add demux support · d714f97c
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      d714f97c
    • L
      ASoC: dapm: Add new widgets to the end of the widget list · 92fa1242
      由 Lars-Peter Clausen 提交于 
      Currently new widgets are appended to the beginning of the cards widget
list. This has the effect that widgets that are created while iterating
over the widget list in snd_soc_dapm_new_widgets() (like e.g. the
auto-disable widgets) are not covered during that invocation of the
function. If no further invocations of snd_soc_dapm_new_widgets() happen
these widgets will not be fully initialized and e.g. no debugfs entries are
created for them.

By adding new widgets to the end of the widget list we make sure that
widgets that are created in snd_soc_dapm_new_widgets() will still be
handled during the same snd_soc_dapm_new_widgets() invocation and are
always fully initialized.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      92fa1242
    • C
      ASoC: dapm: Add support for autodisable mux controls · 561ed680
      由 Charles Keepax 提交于 
      Commit 57295073 ("ASoC: dapm: Implement mixer input auto-disable")
added support for autodisable controls, controls whose values are only
written to the hardware when their respective widgets are powered up.
But it only added support for controls based on the mixer abstraction.

This patch add support for mux controls (DAPM controls based on the
enum abstraction) to be auto-disabled as well. As each mux can only have
a single control, there is no need to tie the autodisable widget to the
inputs (as is done for the mixer controls) it can be tided directly to
the mux widget itself.

Note that it is assumed that the first entry in a autodisable mux
control will always represent the off state for the mux and is what the
mux will be set to whilst it is disabled.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      561ed680
    • C
      ASoC: dapm: Append "Autodisable" to autodisable widget names · 773da9b3
      由 Charles Keepax 提交于 
      This makes it a little easier to follow what is happening in debugfs.
Additionally is also useful in facilitating work to add autodisable
muxes because the control name is already used for the mux widget and
thus shouldn't be reused for the autodisable widget.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      773da9b3
  13. 04 5月, 2015 1 次提交
  15. 01 5月, 2015 2 次提交
  17. 28 4月, 2015 3 次提交
  19. 17 4月, 2015 1 次提交