Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 30 12月, 2014 4 次提交
  3. 08 12月, 2014 1 次提交
  5. 07 12月, 2014 1 次提交
  7. 01 12月, 2014 1 次提交
  9. 26 11月, 2014 2 次提交
    • J
      ASoC: Remove 'const' from the device_node pointers · c362effe
      由 Jean-Francois Moine 提交于 
      As Russell King's explained it, there should not be pointers to
struct device_node:

"struct device_node is a ref-counted structure.  That means if you
 store a reference to it, you should "get" it, and you should "put"
 it once you've done.  The act of "put"ing the pointed-to structure
 involves writing to that structure, so it is totally unappropriate
 to store a device_node structure as a const pointer.  It forces you
 to have to cast it back to a non-const pointer at various points
 in time to use various OF function calls."

[This isn't quite the application here, we're not geting or putting the
pointer though we did add some other users who call non-const OF
functions -- broonie]
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>
      c362effe
    • L
      ASoC: Disable regmap helpers if regmap is disabled · e874bf5f
      由 Lars-Peter Clausen 提交于 
      If regmap is disabled there will be no users of the ASoC regmap helpers.
Furthermore regmap_exit() will no be defined causing the following compile
error:
	sound/soc/soc-core.c: In function 'snd_soc_component_exit_regmap':
	sound/soc/soc-core.c:2645:2: error: implicit declaration of function
		'regmap_exit' [-Werror=implicit-function-declaration]

So disable the helpers if regmap is disabled.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Fixes: 20feb881 ASoC: Add helper functions for deferred regmap setup")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      e874bf5f
  11. 25 11月, 2014 3 次提交
  13. 21 11月, 2014 1 次提交
  15. 19 11月, 2014 1 次提交
  17. 18 11月, 2014 6 次提交
  19. 11 11月, 2014 1 次提交
  21. 10 11月, 2014 1 次提交
    • T
      ALSA: pcm: Add snd_pcm_stop_xrun() helper · 1fb8510c
      由 Takashi Iwai 提交于 
      Add a new helper function snd_pcm_stop_xrun() to the standard sequnce
lock/snd_pcm_stop(XRUN)/unlock by a single call, and replace the
existing open codes with this helper.

The function checks the PCM running state to prevent setting the wrong
state, too, for more safety.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1fb8510c
  23. 09 11月, 2014 1 次提交
  25. 06 11月, 2014 1 次提交
  27. 05 11月, 2014 1 次提交
    • T
      ASoC: dpcm: Fix race between FE/BE updates and trigger · ea9d0d77
      由 Takashi Iwai 提交于 
      DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state.  Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered.  For example, suppose to switch a BE while a FE's
stream is running.  This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.

When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN).  Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.

Usually, for avoiding such a race, we take a lock.  There is a PCM
stream lock for that purpose.  However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.

This patch provides an alternative solution.  This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes.  For doing it, two things are introduced:

- Each runtime_update state change of FEs is protected via PCM stream
  lock.
- The FE's trigger callback checks the runtime_update flag.  If it's
  not set, the trigger action is executed there.  If set, mark the
  pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
  pending trigger is present.  If yes, it executes the trigger action
  at this point.
Reported-and-tested-by: NQiao Zhou <zhouqiao@marvell.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
      ea9d0d77
  29. 04 11月, 2014 2 次提交
  31. 03 11月, 2014 2 次提交
  33. 30 10月, 2014 3 次提交
  35. 29 10月, 2014 2 次提交
  37. 28 10月, 2014 6 次提交
    • T
      ALSA: jack: Fix kerneldoc comments · 7b366d5f
      由 Takashi Iwai 提交于 
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7b366d5f
    • L
      ASoC: Use generic control handlers for S8 control · c1b4d1c7
      由 Lars-Peter Clausen 提交于 
      Commit f227b88f ("ASoC: core: Add signed register volume control logic")
added support for signed control to the generic volsw control handler.
This makes it possible to use them for the S8 control as well, rather than
having to use a custom control handler implementation.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      c1b4d1c7
    • L
      ASoC: dapm: Use more aggressive caching · 92a99ea4
      由 Lars-Peter Clausen 提交于 
      Currently we cache the number of input and output paths going to/from a
widget only within a power update sequence. But not in between power update
sequences.

But we know how changes to the DAPM graph affect the number of input (form a
source) and output (to a sink) paths of a widget and only need to
recalculate them if a operation has been performed that might have changed
them.
	* Adding/removing or connecting/disconnecting a path means that the for
	  the source of the path the number of output paths can change and for
	  the sink the number of input paths can change.
	* Connecting/disconnecting a widget has the same effect has connecting/
	  disconnecting all paths of the widget. So for the widget itself the
	  number of inputs and outputs can change, for all sinks of the widget
	  the number of inputs can change and for all sources of the widget the
	  number of outputs can change.
	* Activating/Deactivating a stream can either change the number of
	  outputs on the sources of the widget associated with the stream or the
	  number of inputs on the sinks.

Instead of always invalidating all cached numbers of input and output paths
for each power up or down sequence this patch restructures the code to only
invalidate the cached numbers when a operation that might change them has
been performed. This can greatly reduce the number of DAPM power checks for
some very common operations.

Since per DAPM operation typically only either change the number of inputs
or outputs the number of path checks is reduced by at least 50%. The number
of neighbor checks is also reduced about the same percentage, but since the
number of neighbors encountered when walking from sink to source is not the
same as when walking from source to sink the actual numbers will slightly
vary from card to card (e.g. for a mixer we see 1 neighbor when walking from
source to sink, but the number of inputs neighbors when walking from source
to sink).

Bigger improvements can be observed for widgets with multiple connected
inputs and output (e.g. mixers probably being the most widespread form of
this). Previously we had to re-calculate the number of inputs and outputs
on all input and output paths. With this change we only have to re-calculate
the number of outputs on the input path that got changed and the number of
inputs on the output paths.

E.g. imagine the following example:

	A --> B ----.
	            v
	M --> N --> Z <-- S <-- R
	            |
	            v
	            X

Widget Z has multiple input paths, if any change was made that cause Z to be
marked as dirty the power state of Z has to be re-computed. This requires to
know the number of inputs and outputs of Z, which requires to know the
number of inputs and outputs of all widgets on all paths from or to Z.
Previously this meant re-computing all inputs and outputs of all the path
going into or out of Z. With this patch in place only paths that actually
have changed need to be re-computed.

If the system is idle (or the part of the system affected by the changed
path) the number of path checks drops to either 0 or 1, regardless of how
large or complex the DAPM context is. 0 if there is no connected sink and no
connected source. 1 if there is either a connected source or sink, but not
both. The number of neighbor checks again will scale accordingly and will be
a constant number that is the number of inputs or outputs of the widget for
which we did the path check.

When loading a state file or switching between different profiles typically
multiple mixer and mux settings are changed, so we see the benefit of this
patch multiplied for these kinds of operations.

Testing with the ADAU1761 shows the following changes in DAPM stats for
changing a single Mixer switch for a Mixer with 5 inputs while the DAPM
context is idle.

         Power  Path  Neighbour
Before:  2      12    30
After:   2       1     2

For the same switch, but with a active playback stream the stat changed are
as follows.

         Power  Path  Neighbour
Before:  10     20    54
After:   10      7    21

Cumulative numbers for switching the audio profile which changes 7 controls
while the system is idle:

         Power  Path  Neighbour
Before:  16      80   170
After:   16       7    23

Cumulative numbers for switching the audio profile which changes 7 controls
while playback is active:

         Power  Path  Neighbour
Before:  51     123   273
After:   51      29   109

Starting (or stopping) the playback stream:

         Power  Path  Neighbour
Before:  34     34    117
After:   34     17    69
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      92a99ea4
    • L
      ASoC: dapm: Mark endpoints instead of IO widgets dirty during suspend/resume · 8be4da29
      由 Lars-Peter Clausen 提交于 
      The state of endpoint widgets is affected by that card's power state.
Endpoint widgets that do no have the ignore_suspend flag set will be
considered inactive during suspend. So they have to be re-checked and marked
dirty after the card's power state changes. Currently the input and output
widgets are marked dirty instead, this works most of the time since
typically a path from one endpoint to another will go via a input or output
widget. But marking the endpoints dirty is technically more correct and will
also work for odd corner cases.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8be4da29
    • L
      ASoC: dapm: Add a flag to mark paths connected to supply widgets · c1862c8b
      由 Lars-Peter Clausen 提交于 
      Supply widgets do not count towards the input and output widgets of their
neighbors and for supply widgets themselves we do not care for the number
of input or output paths. This means that a path that connects to a supply
widget effectively behaves the same as a path that as the weak property set.
This patch adds a new path flag that gets set to true when the path is
connected to at least one supply widget. If a path with the flag set is
encountered in is_connected_{input,output}_ep() is is skipped in the same
way that weak paths are skipped. This slightly brings down the number of
path checks.

Since both the weak and the supply flag are implemented as bitfields which
are stored in the same word there is no runtime overhead due to checking
both rather than just one and also the size of the path struct is not
increased by this patch. Another advantage is that we do not have to handle
supply widgets in is_connected_{input,output}_ep() anymore since it will
never be called for supply widgets. The only exception is from
dapm_widget_power_read_file() where a check is added to special case supply
widgets.

Testing with the ADAU1761, which has a handful of supply widgets, shows the
following changes in the DAPM stats for a playback stream start.

         Power  Path  Neighbour
Before:  34     78    117
After:   34     48    117
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      c1862c8b
    • L
      ASoC: dapm: Introduce toplevel widget categories · 6dd98b0a
      由 Lars-Peter Clausen 提交于 
      DAPM widgets can be classified into four categories:
	* supply: Supply widgets do not affect the power state of their
		non-supply widget neighbors and unlike other widgets a
		supply widget is not powered up when it is on an active
		path, but when at least on of its neighbors is powered up.
	* source: A source is a widget that receives data from outside the
		DAPM graph or generates data. This can for example be a
		microphone, the playback DMA or a signal generator. A source
		widget will be considered powered up if there is an active
		path to a sink widget.
	* sink: A sink is a widget that transmits data to somewhere outside
		of the DAPM graph. This can e.g. be a speaker or the capture
		DMA. A sink widget will be considered powered up if there is
		an active path from a source widget.
	* normal: Normal widgets are widgets not covered by the categories
		above. A normal widget will be considered powered up if it
		is on an active path between a source widget and a sink
		widget.

The way the number of input and output paths for a widget is calculated
depends on its category. There are a bunch of factors which decide which
category a widget is. Currently there is no formal classification of these
categories and we calculate the category of the widget based on these
factors whenever we want to know it. This is at least once for every widget
during each power update sequence. The factors which determine the category
of the widgets are mostly static though and if at all change rather seldom.
This patch introduces three new per widget flags, one for each of non-normal
widgets categories. Instead of re-computing the category each time we want
to know them the flags will be checked. For the majority of widgets the
category is solely determined by the widget id, which means it never changes
and only has to be set once when the widget is created. The only widgets
with dynamic categories are:

	snd_soc_dapm_dai_out: Is considered a sink iff the capture stream is
		active, otherwise normal.
	snd_soc_dapm_dai_in: Is considered a source iff the playback stream
		is active, otherwise normal.
	snd_soc_dapm_input: Is considered a sink iff it has no outgoing
		paths, otherwise normal.
	snd_soc_dapm_output: Is considered a source iff it has no incoming
		paths, otherwise normal.
	snd_soc_dapm_line: Is considered a sink iff it has no outgoing paths
		and is considered a source iff it has no incoming paths,
		otherwise normal.

For snd_soc_dapm_dai_out/snd_soc_dapm_dai_in widgets the category will be
updated when a stream is started or stopped. For the other dynamic widgets
the category will be updated when a path connecting to it is added or
removed.

Introducing those new widget categories allows to make
is_connected_{output,input}_ep, which are among the hottest paths of the
DAPM algorithm, more generic and significantly shorter.

The before and after sizes for is_connected_{output,input}_ep are:

On ARM (defconfig + CONFIG_SND_SOC):
	function                                     old     new   delta
	is_connected_output_ep                       480     340    -140
	is_connected_input_ep                        456     352    -104

On amd64 (defconfig + CONFIG_SND_SOC):
	function                                     old     new   delta
	is_connected_output_ep                       579     427    -152
	is_connected_input_ep                        563     427    -136

Which is about a 25%-30% decrease, other architectures are expected to have
similar numbers. At the same time the size of the snd_soc_dapm_widget struct
does not change since the new flags are stored in the same word as the
existing flags.

Note: that since the per widget 'ext' flag was only used to decide whether a
snd_soc_dapm_input or snd_soc_dapm_output widget was a source or a sink it
is now unused and can be removed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      6dd98b0a