Skip to content

L
linux
Switch branch/tag
  1. 20 May, 2015 2 commits
  3. 18 May, 2015 11 commits
  5. 15 May, 2015 9 commits
  7. 12 May, 2015 1 commit
    • Charles Keepax's avatar
      ASoC: dapm: Add cache to speed up adding of routes · 45a110a1
      Charles Keepax authored 
      Some CODECs have a significant number of DAPM routes and for each route,
when it is added to the card, the entire card widget list must be
searched. When adding routes it is very likely, however, that adjacent
routes will require adjacent widgets. For example all the routes for a
mux are likely added in a block and the sink widget will be the same
each time and it is also quite likely that the source widgets are
sequential located in the widget list.

This patch adds a cache to the DAPM context, this cache will hold the
source and sink widgets from the last call to snd_soc_dapm_add_route for
that context. A small search of the widget list will be made from those
points for both the sink and source. Currently this search only checks
both the last widget and the one adjacent to it.

On wm8280 which has approximately 500 widgets and 30000 routes (one of
the largest CODECs in mainline), the number of paths that hit the cache
is 24000, which significantly improves probe time.
Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      45a110a1
  9. 11 May, 2015 12 commits
  11. 08 May, 2015 1 commit
  13. 06 May, 2015 4 commits
    • Lars-Peter Clausen's avatar
      ASoC: dapm: Add demux support · d714f97c
      Lars-Peter Clausen authored 
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d714f97c
    • Lars-Peter Clausen's avatar
      ASoC: dapm: Add new widgets to the end of the widget list · 92fa1242
      Lars-Peter Clausen authored 
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      92fa1242
    • Charles Keepax's avatar
      ASoC: dapm: Add support for autodisable mux controls · 561ed680
      Charles Keepax authored 
      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: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Tested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      561ed680
    • Charles Keepax's avatar
      ASoC: dapm: Append "Autodisable" to autodisable widget names · 773da9b3
      Charles Keepax authored 
      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: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Tested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      773da9b3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7