Current soc-dapm / soc-core are using a long way round to call
.set_bias_level.

	if (driver->set_bias_level)
		dapm->set_bias_level = ...;
	...
	if (dapm->set_bias_level)
		ret = dapm->set_bias_level(...);

We can directly call it via driver->set_bias_level.
One note here is that both Card and Component have dapm,
but, Card's dapm doesn't have dapm->component.
We need to check it.

This patch moves snd_soc_component_set_bias_level() to soc-component.c
and updates parameters.
dapm->set_bias_level is no longer needed
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87tvb94d0n.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Current soc-dapm / soc-core are using a long way round to call
.stream_event.

	if (driver->stream_event)
		dapm->stream_event = ...;
	...
	if (dapm->stream_event)
		ret = dapm->stream_event(...);

We can directly call it via driver->stream_event.
One note here is that both Card and Component have dapm,
but, Card's dapm doesn't have dapm->component.
We need to check it.

This patch moves snd_soc_component_stream_event() to soc-component.c
and updates parameters.
dapm->stream_event is no longer needed
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87v9vp4d0r.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Current soc-dapm / soc-core are using a long way round to call
.seq_notifier.

	if (driver->seq_notifier)
		dapm->seq_notifier = ...;
	...
	if (dapm->seq_notifier)
		ret = dapm->seq_notifier(...);

We can directly call it via driver->seq_notifier.
One note here is that both Card and Component have dapm,
but, Card's dapm doesn't have dapm->component.
We need to check it.

This patch moves snd_soc_component_seq_notifier() to soc-component.c,
and updates parameters.
dapm->seq_notifier is no longer needed
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wog54d0v.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to
reduce coming code size and make it more readable.

Cc: stable@vger.kernel.org
Signed-off-by: NOleksandr Suvorov <oleksandr.suvorov@toradex.com>
Reviewed-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: NIgor Opaniuk <igor.opaniuk@toradex.com>
Reviewed-by: NFabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

To detect potential errors, let's add:

a) build-time warnings when the table size isn't aligned with the enum
list
b) run-time warnings when the values are not initialized. This
requires an increase by one of all values to avoid the default 0.
Suggested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently all widgets attached to a DAI link will be powered
up when the DAI is active, however this may include routes
that are not actually in use if there are unused channels
available on the DAI.

The macros for creating AIF widgets already include an entry for
slot, it is proposed to change that to channel. The effective
difference here being respresenting the logical channel index
rather than the physical slot index. The CODECs currently
using the slot entry on the DAPM_AIF macros are using it in
a manner consistent with this, the CODECs not using it just
have the field set to zero.

A variable is added to snd_soc_dapm_widget to represent
this channel index and then for each AIF widget attached to
a DAI this is compared against the number of channels on
the stream. Enabling the links for those which will be in
use. This has the nice property that the CODECs which haven't
used the slot/channel entry in the macro will function exactly
as before due to all the AIF widgets having a channel of zero
and a stream by definition having at least one channel.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add a new dobj type SND_SOC_DOBJ_GRAPH for dapm routes
and add snd_soc_dobj member to struct snd_soc_dapm_route.
This enables device drivers to save driver specific
data pertaining to dapm routes and also be able
to clean up the data when the driver module is unloaded.

Also, reorder the snd_soc_dobj_type types to align with
matching topology header types.
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Larger CODECs may contain many several hundred widgets and which set of
parameters is selected only needs to be recorded on a per DAI basis. As
such move the selected CODEC to CODEC link params to be stored in the
runtime rather than the DAPM widget, to save some memory.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently, snd_soc_dapm_connect_dai_link_widgets connects up the routes
representing normal DAIs, however CODEC to CODEC links are hooked up
through separate infrastructure in soc_link_dai_widgets. Improve the
consistency of the code by using snd_soc_dapm_connect_dai_link for both
types of DAIs.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit a655de80 ("ASoC: core: Allow topology to override
machine driver FE DAI link config.") caused soc_dai_hw_params to
be come dependent on the substream private_data being set with
a pointer to the snd_soc_pcm_runtime. Currently, CODEC to CODEC
links don't set this, which causes a NULL pointer dereference:

[<4069de54>] (soc_dai_hw_params) from
[<40694b68>] (snd_soc_dai_link_event+0x1a0/0x380)

Since the ASoC core in general assumes that the substream
private_data will be set to a pointer to the snd_soc_pcm_runtime,
update the CODEC to CODEC links to respect this.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Purpose of having pinctrl dapm is to dynamically put the pins in
low power state when they are not actively used by the audio and
saving power.

Without this each driver has to set the pinctrl states, either
during probe or dynamically depending on the callbacks received
from ASoC core.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add some DAPM widget types to better support the construction of DAPM
graphs within DSPs.
Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

A DAPM_DOUBLE_R control type can be used for dual channel mixer input
selectors / mute controls across 2 registers, possibly toggling both
channels together.

The control is meant to be shared by 2 widgets, 1 for each channel,
such that the mixer control exposed to userspace remains a combined
stereo control.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

A DAPM_DOUBLE control type can be used for dual channel mixer input
selectors / mute controls in one register, possibly toggling both
channels together.

The control is meant to be shared by 2 widgets, 1 for each channel,
such that the mixer control exposed to userspace remains a combined
stereo control.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

To support double channel shared controls split across 2 registers, one
for each channel, we must be able to update both registers together.

Add a second set of register fields to struct snd_soc_dapm_update, and
update the DAPM control writeback (put) callbacks to support this.

For codecs that use custom events which call into DAPM to do updates,
also clear struct snd_soc_dapm_update before using it, so the second
set of fields remains clean.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This is useful outside the core, when one dapm element is added
at a time.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Certain situations may warrant examining DAPM paths only to a certain
arbitrary point, as opposed to always following them to the end. For
instance, when establishing a connection between a front-end DAI link
and a back-end DAI link in a DPCM path, it does not make sense to walk
the DAPM graph beyond the first widget associated with a back-end link.

This patch introduces a mechanism which lets a user of
dai_get_connected_widgets supply a function which will be called for
every node during the graph walk. When invoked, this function can
execute arbitrary logic to decide whether the walk, given a DAPM widget
and walk direction, should be terminated at that point or continued
as normal.
Signed-off-by: NPiotr Stankiewicz <piotrs@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 086d7f80 ("ASoC: Convert WM8962 MICBIAS to a supply widget",
2011-09-23) says:

	A supply widget is generally clearer than a MICBIAS widget and a
	mic bias is just a type of supply so use a supply widget for the
	MICBIAS. This also avoids confusion with the routing when
	connected to multiple inputs.

but this has never been documented as a policy.  Add some comments to
make it clear.
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

DAPM models various widgets but lacks a sink widget.
DSPs can have modules which take audio data, process it and are
capable of generating events thus acting as a sink of data.

To make the dapm graph complete for such paths we need a dapm
sink widget for these modules, so add a SND_SOC_DAPM_SINK to
declare such a widget.  This widget will be treated as
SND_SOC_DAPM_EP_SINK endpoint in the dapm graph
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

If there is anything in damp->path_source_cache or
damp->path_sink_cache, it can not be valid after the widgets have been
freed. Without this patch a repeated remove and load of a machine
driver may cause NULL pointer reference in dapm_wcache_lookup() when a
freed widget, not belonging to any list, is haunting in the wcache.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Reported-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Given a kcontrol, we may want to access the parent widget
and it's associated data. So export function to return it.
Signed-off-by: NMythri P K <mythri.p.k@intel.com>
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

After the recent cleanups and generalizations of the DAPM algorithm the
handling of input and output paths is now fully symmetric. This means by
making some slight changes to the data structure and using arrays with one
entry for each direction, rather than separate fields, it is possible to
create a generic implementation that is capable of handling both input and
output paths.

Unfortunately this generalization significantly increases the code size on
the hot path of is_connected_{input,output}_ep() and
dapm_widget_invalidate_{input,output}_paths(), which has a negative impact
on the overall performance. The inner loops of those functions are quite
small and the generic implementation adds extra pointer arithmetic in a few
places.

Testing on ARM shows that the combined code size of the specialized
functions is about 50% larger than the generalized function in relative
numbers. But in absolute numbers its less than 200 bytes, which is still
quite small. On the other hand the generalized function increases the
execution time of dapm_power_one_widget() by 30%. Given that this function
is one of the most often called functions of the DAPM framework the
trade-off of getting better performance at expense of generating slightly
larger code at seems to be worth it.

To avoid this still keep two versions of these functions around, one for
input and one for output. But have a generic implementation of the
algorithm which gets inlined by those two versions. And then let the
compiler take care of optimizing it and removing he extra instructions.

This still reduces the source code size as well as the makes making changes
to the implementation more straight forward since the same change does no
longer need to be done in two separate places. Also on the slow paths we
can use a generic implementations that handle both input and output paths.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add helper iterator macros for iterating over the source and sink paths of
widget. This will make it easier to change the implementation later on.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

snd_soc_tplg_widget_remove_all() has a verbatim copy of an older version of
the widget freeing code from dapm_free_widgets(). Add a new helper function
that takes care of freeing a widget and use it in both places.

This removes the duplicated code and also makes sure that future changes to
the widget freeing code only have to be made in one location.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The topology core parses the FW topology file for known block types and
instanciates any common ALSA/ASoC objects that it discovers. The core
also passes any block that is does not understand to client component
drivers for enumeration.

The core exports some APIs to client drivers in order to load and unload
firmware topology data as use case require.

Currently the core deals with the following object types :-

 o kcontrols. This includes TLV, enumerated and bytes controls.
 o DAPM widgets. All types with any associated kcontrol.
 o DAPM graph.
 o FE PCM. FE PCM capabilities and configuration can be defined.
 o BE DAI Link. BE DAI link capabilities and configuration can be defined.
 o Codec <-> codec style links capabilities and configuration.
Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

 The ASoC topology UAPI header defines the structures
 required to define any DSP firmware audio topology and control objects from
 userspace.

The following objects are supported :-
 o kcontrols including TLV controls.
 o DAPM widgets and graph elements
 o Vendor bespoke objects.
 o Coefficient data
 o FE PCM capabilities and config.
 o BE link capabilities and config.
 o Codec <-> codec link capabilities and config.
 o Topology object manifest.

The file format is simple and divided into blocks for each object type and
each block has a header that defines it's size and type. Blocks can be in
any order of type and can either all be in a single file or spread across
more than one file. Blocks also have a group identifier ID so that they can
be loaded and unloaded by ID.
Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

Currently drivers are responsible for managing the bias_level field of
their DAPM context. The DAPM state itself is managed by the DAPM core
though and the core has certain expectations on how and when the bias_level
field should be updated. If drivers don't adhere to these undefined
behavior can occur.

This patch adds a few helper functions for manipulating the DAPM context
state, each function with a description on when it should be used and what
its effects are. This will also help us to move more of the bias_level
management from drivers to the DAPM core.

For convenience also add snd_soc_codec_* wrappers around these helpers.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Correct small copy and paste error where autodisable was not being
enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The delayed_work field in the snd_soc_dapm_context struct is now unused and
can be removed. Removing it reduces the size of the snd_soc_dapm_context
struct by ~50% from 100 bytes to 48 bytes.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The only two users of the suspend_bias_level field were two rather old
drivers which weren't exactly doing things by the book. Those drivers have
been updated and field is now unused and can be removed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

dai-link params for codec-codec links were fixed. The fixed
link between codec and another chip which may be another codec,
baseband, bluetooth codec etc may require run time configuaration
changes. This change provides an optional alsa control to select
one of the params from a list of params.
Signed-off-by: NNikesh Oswal <nikesh@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

snd_soc_dapm_kcontrol_codec() is a extremely simple function and inlining it
typically results in less code than necessary for calling the non-inlined
version of the function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Instead of calling device_create_file() manually, assign the static
attribute group entries at the device registration.  This simplifies
the error handling and avoids the possible races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

There are no more users of this field left so it can finally be removed.
New users should use snd_soc_dapm_to_codec(w->dapm);

The reason why it is removed is because it doesn't fit to well anymore in
the componentized ASoC hierarchy, where DAPM works on the snd_soc_component
level. And the alternative of snd_soc_dapm_to_codec(w->dapm) typically
generates the same amount of code, so there is really no reason to keep it.

For automatic conversion the following coccinelle semantic patch can be used:
// <smpl>
@@
struct snd_soc_dapm_widget *w;
@@
-w->codec
+snd_soc_dapm_to_codec(w->dapm)
// </smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

For legacy reasons the ASoC framework assumes that a CODEC INPUT or OUTPUT
widget that is not explicitly connected to a external source or sink is
potentially connected to a source or a sink and hence the framework treats
the widget itself as source (for INPUT) or sink (for OUTPUT). For this
reason a INPUT or OUTPUT widget that is really not connected needs to be
explicitly marked as so.

Setting the card's fully_routed flag will cause the ASoC core, once that all
widgets and routes have been registered, to go through the list of all
widgets and mark all INPUT and OUTPUT that are not externally connected as
non-connected. This essentially negates the default behaviour of treating
INPUT or OUTPUT widgets without external routes as sources or sinks.

This patch takes a different approach while getting the same result. Instead
of first marking INPUT and OUTPUT widgets as sinks/sources and then later
marking them as non-connected, just never mark them as a sink or a source if
the fully_routed flag is set on a card.

This requires a lot less code and also results in a slightly faster card
initialization since there is no need to iterate over all widgets and check
whether the INPUT and OUTPUT widgets are connected or not.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

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>