Do not free BE hw if it's still used by other FE during dpcm runtime
shutdown. Otherwise the BE runtime state will be STATE_HW_FREE and
won't be updated to STATE_CLOSE when shutdown ends, because BE dai
shutdown function won't close pcm when detecting BE is still under
use. With STATE_HW_FREE, BE can't be triggered start again.

This corner case can easily appear when one BE is used by two FE,
without this patch "ASoC: dpcm: Fix race between FE/BE updates and
trigger"(ea9d0d77). One FE tries to
shutdown but it's raced against xrun on another FE. It improves the
be dai hw_free logic.
Signed-off-by: NQiao Zhou <zhouqiao@marvell.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix off by one read beyond the end of a table.
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

It is right not left sidetone which goes to "DACR".
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non
mixer/mux widgets") revealed ill-defined control in a route between
"STENL Mux" and DACs in max98090.c:

max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> DACL
max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACL
max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACL
max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> DACR
max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACR
max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACR

Since there is no control between "STENL Mux" and DACs the control name must
be NULL not "NULL".
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Commit e409dfbf ("ASoC: dapm: Add a few supply widget sanity checks")
broke digital microphone support in max98090.c:

max98090 i2c-193C9890:00: Conditional paths are not supported for supply widgets (DMICL_ENA -> [DMIC] -> DMIC Mux)
max98090 i2c-193C9890:00: ASoC: no dapm match for DMICL_ENA --> DMIC --> DMIC Mux
max98090 i2c-193C9890:00: ASoC: Failed to add route DMICL_ENA -> DMIC -> DMIC Mux
max98090 i2c-193C9890:00: Conditional paths are not supported for supply widgets (DMICR_ENA -> [DMIC] -> DMIC Mux)
max98090 i2c-193C9890:00: ASoC: no dapm match for DMICR_ENA --> DMIC --> DMIC Mux
max98090 i2c-193C9890:00: ASoC: Failed to add route DMICR_ENA -> DMIC -> DMIC Mux

Problem is partially caused by commit f69e3caa ("ASoC: max98090: Enable
both DMIC channels also when using mono configuration") which connects
"DMICL_ENA" and "DMICR_ENA" supply widgets to "DMIC Mux".

Fix the breakage by reverting f69e3caa and then by adding additional
"DMICR_ENA" to "DMICL" and "DMICL_ENA" to "DMICR" cross-connections. This
disconnects these supply widgets from the mux and makes sure that both DMIC
data channels are still enabled together.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Make sure to check the version field of the firmware header to make sure to
not accidentally try to parse a firmware file with a different layout.
Trying to do so can result in loading invalid firmware code to the device.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Many firmwares do not wait for the start bit before they begin
processing audio, whilst this is a bug on the firmware side there are
too many such firmwares in the wild to ignore the situation. This patch
moves the core enable to happen at same time as the start, the firmware
looses the ability to overlap its own startup with the audio path bring
up but we ensure that all firmwares behave.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We should not free any buffers associated with writing out coefficients
to the DSP until all the async writes have completed. This patch updates
the out of memory path when allocating a new buffer to include a call to
regmap_async_complete.
Reported-by: NJS Park <aitdark.park@samsung.com>
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound  to happen
5 seconds after the end of a playback.

The SMALL_POP bit should fix this, but its definition is incorrect:
according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
bit 1.

Fix the definition accordingly and enable the bit as intended per the code
comment.

After applying this change, no loud 'click' sound is heard after playback
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

In commit a1253ef6 ("ASoC: cs42l51: split i2c from codec driver"),
the I2C part of the CS42L51 was moved to a separate file, but the
definition of the of_device_id array was left in the driver file
itself, no longer connected to the platform_driver structure using the
.of_match_table pointer.

This commit exports the of_device_id array in cs42l51, and uses it as
.of_match_able in cs42l51-i2c.c. This solution was suggested by Brian
Austin.

Fixes: a1253ef6 ("ASoC: cs42l51: split i2c from codec driver")
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NBrian Austin <brian.austin@cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

When the bus is configured to have more BCLK then the data type demands we
need to use the rotation to move the data to correct place.
Reported-by: NMisael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In IIS mode the tx and rx configuration is symmetric, the BCLK and FSYNC is
shared.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call.
Signed-off-by: NAnil Kumar <anilk4.v@gmail.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This function has no more non regmap user, which means we can remove the
implementation of the function and associated functions and structure
fields.

For convenience we keep a static inline version of the function that
forwards calls to regcache_sync() unconditionally.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

For convenience for drivers that do not want to keep their own pointer to
regmap struct around forward calls to snd_soc_cache_sync() to
regcache_sync() if the driver is using regmap. This is similar to what we do
for snd_soc_read()/snd_soc_write().

This patch also fixes drivers which already have been converted to regmap,
but still use snd_soc_cache_sync() for trying to the sync the cache.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

PLL should be powered up once filter power is on. So, "PLL1"
should be connected to filters instead of DACs.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The patch corrects the incorrect default register values.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

This enables the snd_soc_snow module to be auto-loaded.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The Baytrail-based chromebooks have a 20MHz mclk, the code was setting
the divisor incorrectly in this case.  According to the 98090
datasheet, the divisor should be set to DIV1 for 10 <= mclk <= 20.
Correct this and the surrounding clock ranges as well to match the
datasheet.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

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

CPU and CODEC DAI probe are performed in exactly the same way. Which means
we can reuse the snd_soc_codec_dai_probe() for probing CPU DAIs as well.

While we are at it also drop the unused card parameter form the function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The card field of the snd_soc_dai field is very rarely used. We can use
dai->component->card instead and remove the card field from the snd_soc_dai
struct.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Typically a DAI does not need direct access to the platform. Currently the
only user of this field is in a platform driver where we have a more direct
way of getting a pointer to the platform. This patch updates the driver to
use the more direct way and then removes the platform field from the
snd_soc_dai struct.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Those are unused and new drivers should use device driver suspend/resume.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 14621c7e ("ASoC: Consolidate CPU and CODEC DAI lookup")
consolidated the lookup of CPU DAIs and CODEC DAIs into a single function.
When matching a component by name for CODEC DAIs the code previous to the
patch compared the name in the DAI link table with component->name. For CPU
DAIs the code compared to dev_name(component->dev). The newly introduced
function ended up using the later as well.

For most components dev_name(component->dev) and component->name are the
same. The main notable exception are I2C devices where the driver name and
the device name are concatenated to form the component name. By using
dev_name(component->dev) instead of component->name the patch broke the
matching of I2C CODECs by name.

This patch restores the original behavior by using component->name instead
of dev_name(component->dev). This will be safe even for CPU DAIs since for
CPU DAIs both are the same.

Fixes: 14621c7e ("ASoC: Consolidate CPU and CODEC DAI lookup")
Reported-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The AFIFO should not be stopped (or started for that matter) when McASP is
running since it can cause unpredictable issues because we are switching off
AFIFO for the direction which was handling the requests from McASP and was
generating DMA request toward the system DMA.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Follow the sequence described in the TRMs when starting RX.
Write to RXBUF register was not correct and there is no need to release the
RX state machine/Receive frame sync generator twice.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Follow the sequence described in the TRMs when starting TX. This sequence
will make sure that we are not facing with initial channel swap caused by
no data available in McASP for transmit.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The main ASoC source file is getting quite large and the standard ops don't
really have anything to do with the rest of the file so split them out into
a separate file.
Signed-off-by: NMark Brown <broonie@kernel.org>

R-Car sound doesn't support PAUSE.
Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

FSI doesn't support PAUSE.
Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

amixer query fails due to it is not readable reigster
Signed-off-by: NFang, Yang A <yang.a.fang@intel.com>
Acked-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We can get into an infinite loop if the I2S_CLR register fails to
clear due to a missing break statement, so add that.
Signed-off-by: NJianqun <jay.xu@rock-chips.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The convention for i2c_device_id name does not need to have company prefix.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

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>

Supply widgets are somewhat special and not all kinds of paths to or from
supply widgets make sense. This patch adds a few sanity checks that errors
out during the path instantiation for those invalid paths. This will prevent
drivers to depend on weird behavior resulting from such paths as well as
will allow the DAPM algorithms to assume that they never see such paths.

This patch adds checks for the following three invalid types of paths:
	* A path with a non-supply widget as a source connected to a supply
	  widget as a sink. Such a path has no effect on either of the two
	  connected widgets.
	* Paths with a connected() callback that have a non-supply widget as the
	  source. The DAPM algorithm only uses the conneceted() callback for
	  supply widget power checks. And since it prevents caching of the DAPM
	  state there is no intention to make it more generic as it has
	  negative performance implications.
	* Paths which connect a supply to a mixer or mux via a control. Controls
	  are only meant to affect the routing of audio data.
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>

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>

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>