Attempting to create the route as part of adding a mux control causes us
to attempt to add the same route twice since we loop over all sources
for the mux after creating the control. Instead do the addition in the
callers.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>

ASoC automatically creates snd_soc_dapm_dai_in and snd_soc_dapm_dai_out
widgets for DAI drivers, and adds them to the list.  Later on, ASoC
creates automatic routes between these widgets and a widget with a
stream name.

We look for a snd_soc_dapm_dai_in or snd_soc_dapm_dai_out widget, and
use this to obtain the DAI structure.  We then scan all widgets for
any with a stream name refering to either the capture or the playback
stream, and create routes.

If you have both a snd_soc_dapm_dai_in and a snd_soc_dapm_dai_out
referring to the same DAI structure, this ends up creating one set of
routes for the DAI for the snd_soc_dapm_dai_in widget, and a duplicated
set of routes for the snd_soc_dapm_dai_out widget.

Fix this by checking that the stream name for the widget matches the
DAI widget name.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NMark Brown <broonie@linaro.org>

Some devices have the problem that if a internal audio signal source is disabled
the output of the source becomes undefined or goes to a undesired state (E.g.
DAC output goes to ground instead of VMID). In this case it is necessary, in
order to avoid unwanted clicks and pops, to disable any mixer input the signal
feeds into or to active a mute control along the path to the output. Often it is
still desirable to expose the same mixer input control to userspace, so cerain
paths can sill be disabled manually. This means we can not use conventional DAPM
to manage the mixer input control. This patch implements a method for letting
DAPM overwrite the state of a userspace visible control. I.e. DAPM will disable
the control if the path on which the control sits becomes inactive. Userspace
will then only see a cached copy of the controls state. Once DAPM powers the
path up again it will sync the userspace setting with the hardware and give
control back to userspace.

To implement this a new widget type is introduced. One widget of this type will
be created for each DAPM kcontrol which has the auto-disable feature enabled.
For each path that is controlled by the kcontrol the widget will be connected to
the source of that path. The new widget type behaves like a supply widget,
which means it will power up if one of its sinks are powered up and will only
power down if all of its sinks are powered down. In order to only have the mixer
input enabled when the source signal is valid the new widget type will be
disabled before all other widget types and only be enabled after all other
widget types.

E.g. consider the following simplified example. A DAC is connected to a mixer
and the mixer has a control to enable or disable the signal from the DAC.

                     +-------+
  +-----+            |       |
  | DAC |-----[Ctrl]-| Mixer |
  +-----+       :    |       |
     |          :    +-------+
     |          :
    +-------------+
    | Ctrl widget |
    +-------------+

If the control has the auto-disable feature enabled we'll create a widget for
the control. This widget is connected to the DAC as it is the source for the
mixer input. If the DAC powers up the control widget powers up and if the DAC
powers down the control widget is powered down. As long as the control widget
is powered down the hardware input control is kept disabled and if it is enabled
userspace can freely change the control's state.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

list_first_entry() will always return a valid pointer, even if the list is
empty. So the check whether path is NULL will always be false. So we end up
calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points
right in the middle of the widget struct and by trying to modify the path the
widgets memory will become corrupted. Fix this by using list_emtpy() to check if
the widget doesn't have any paths.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

When calling krealloc for the kcontrol data the items in the path list that
point back to the head of the list will now point to freed memory, which causes
the list to become corrupted. To fix this, instead of resizing the whole data
struct, only resize the widget list.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

snd_soc_cnew() can return NULL, so we should check the result before trying to
use it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

There is a typo here so we end up using the old freed pointer instead of
the newly allocated one.  (If the "n" is zero then the code works,
obviously).
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Wait with updating the widgets power field until the changes are actually
written to the hardware in dapm_seq_run_coalesced(). This will allow us to query
the current hardware state between calling dapm_power_one_widget() and actually
writing the new power state to hardware.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

snd_soc_dapm_add_path() is similar to snd_soc_dapm_add_route() except that it
expects the pointer to the source and sink widgets instead of their names. This
allows us to simplify the case where we already have a pointer to widgets. (E.g.
as we have in snd_soc_dapm_link_dai_widgets()). snd_soc_dapm_add_route() will be
updated to just look up the widget and then use snd_soc_dapm_add_path() to
handle everything else.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently the DAPM code is limited to only setting or clearing a single bit in a
register to power a widget up or down. This patch extends the DAPM code to be
more flexible in that regard and allow widgets to use arbitrary values to be
used to put a widget in either on or off state.

Since the snd_soc_dapm_widget struct already contains a on_val and off_val field
no additional fields need to be added and in fact the invert field can even be
removed. Also the generated code is slightly smaller.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently we store for each path which control (if any at all) is associated
with that control. But we are only ever interested in the reverse relationship,
i.e. we want to know all the paths a certain control is associated with. This is
currently implemented by always iterating over all paths. This patch updates the
code to keep a list for each control which contains all the paths that are
associated with that control. This improves the run time of e.g.
soc_dapm_mixer_update_power() and soc_dapm_mux_update_power() from O(n) (with n
being the number of paths for the card) to O(1).
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The 'value' field is really per control and not per widget. Currently it is only
used for virtual MUXes, which only have one control per widget. So in that case
there is not so much of a difference between whether it is stored per widget or
per control. Moving the 'value' field from the widget to the control will allow
us to use it also for cases where we have more than one control per widget. E.g.
for mixers with multiple input controls.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

In preparation for adding additional per control data wrap all access to the
widget list in helper functions.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

We use the same 3 lines to get the CODEC for a kcontrol in a quite a few places.
This patch puts them into a common helper function. Having this encapsulated in
a helper function will also make it more easier to eventually change the data
layout of the kcontrol's private data.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

DAPM operations are always performed on the card as a whole. Yet (primarily for
historic reasons) dapm_power_widgets() takes a DAPM context as its parameter.
The DAPM context is mainly used to look up a pointer to the card.  The same is
true for a couple of functions that are being called from dapm_power_widgets().
This patch changes the signature of dapm_power_widgets() and a couple of related
functions to take a snd_soc_card instead of a snd_soc_dapm_context.

Some of the functions also use the DAPM's device to print error and debug
messages. This can be a bit confusing though since this means the messages for
all widgets, also those from other contexts, will be printed with that device.
The patch updates those cases to use the device of the widget's DAPM context.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The update field of a DAPM context is only assigned while the card's dapm_mutex
is locked, the field is also cleared again while the mutex is stil locked. So
there will only ever be one DAPM context at a time with a non-NULL update field.
So it is safe to move the update field from the DAPM context struct to the card
struct. Doing so will allow further cleanups in this area.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

In order to avoid race conditions the assignment of dapm->update should happen
while card->dapm_mutex is being held. To allow CODEC drivers to run a register
update when using snd_soc_dapm_mux_update_power() or
snd_soc_dapm_mixer_update_power() add a update parameter to these two functions.
The update parameter will be assigned to dapm->update while card->dapm_mutex is
locked.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently when updating a control that is shared between multiple widgets the
whole power-up/power-down sequence is being run once for each widget. The
control register is updated during the first run, which means the CODEC internal
routing is also updated for all widgets during this first run. The input and
output paths for each widgets are only updated though during the respective run
for that widget. This leads to a slight inconsistency between the CODEC's
internal state and ASoC's state, which causes non optimal behavior in regard to
click and pop avoidance.

E.g. consider the following setup where two MUXs share the same control.

          +------+
 A1 ------|      |
          | MUX1 |----- C1
 B1 ------|      |
          +------+
             |
  control ---+
             |
          +------+
 A2 ------|      |
          | MUX2 |----- C2
 B2 ------|      |
          +------+

If the control is updated to switch the MUXs from input A to input B with the
current code the power-up/power-down sequence will look like this:

Run soc_dapm_mux_update_power for MUX1
  Power-down A1
  Update MUXing
  Power-up B1

Run soc_dapm_mux_update_power for MUX2
  Power-down A2
  (Update MUXing)
  Power-up B2

Note that the second 'Update Muxing' is a no-op, since the register was already
updated.

While the preferred order for avoiding pops and clicks should be:

Run soc_dapm_mux_update_power for control
  Power-down A1
  Power-down A2
  Update MUXing
  Power-up B1
  Power-up B2

This patch changes the behavior to the later by running the updates for all
widgets that the control is attached to at the same time.

The new code is also a bit simpler since callers of
soc_dapm_{mux,muxer}_update_power don't have to loop over each widget anymore
and neither do we need to keep track for which of the kcontrol's widgets the
current update is.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

soc_dpcm_runtime_update() operates on a ASoC card as a whole. Currently it takes
a snd_soc_dapm_widget as its only parameter though. The widget is then used to
look up the card and is otherwise unused. This patch changes the function to
take a pointer to the card directly. This makes it possible to to call
soc_dpcm_runtime_update() for updates which are not related to one specific
widget.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

As noticed by Lars-Peter Clausen since the move to using widgets to hook
into the DAIs we no longer directly manage the power of AIF or DAC/ADC
widgets from the stream integration so they can just use the generic power
checks instead of the custom stream integration ones they currently do.
Signed-off-by: NMark Brown <broonie@linaro.org>

The ALSA core expect the put callback of a control to return 1 if the value of
the control changed and 0 if it did not. Both snd_soc_dapm_put_volsw() and
snd_soc_dapm_put_enum_virt() currently always returns 0. For both functions we
already have a 'change' variable which either contains 1 or 0 depending on
whether the value has changed or not, so just return that.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

These two functions were added two years ago in commit 4805608a ("ASoC: dapm -
Add methods to retrieve snd_card and soc_card from dapm context.") but have
remained unused so far. Considering that the dapm context actually has a direct
pointer to the card the functions also seem to be unnecessary. E.g. the
expressions 'dapm_get_soc_card(dapm)' and 'dapm->card' yield the same result.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The power up/down sequence order for DAPM switch widgets is not explicitly
initialized, causing them to be run always as the first widget type for both
power up and down. Move it to the same position in the sequence as other mixer
widget types.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since commit 85762e71 ("ASoC: dapm: Implement mixer control sharing") the
long_name field of the snd_soc_dapm_path struct is unused. All of the name
handling now happens entirely in dapm_create_or_share_mixmux_kcontrol(). So we
can remove the long_name field from the snd_soc_dapm_path struct.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

We have the same code for freeing a DAPM path in three different locations.
Introduce a new helper function to take care of this.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The condition 'i == item' is only true when, well, 'i' equals 'item'.
So just use 'item' directly as the index into the array.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The private data containing the widget list that is a assigned to a DAPM
kcontrol is never freed. Setup the private_free for DAPM kcontrols to take care
of this.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Even though they are virtual widgets DAI widgets still get counted for the
DAPM context power management so we can't just use the active state to
check if they should be powered as they may not be part of a complete path.

Instead split them into input and output widgets and do the same power
checks as we perform on AIFs.
Reported-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The power_list field is used when adding a widget to a power sequence list. Use
the same field when iterating the list using list_for_each_entry, otherwise
we'll see undefined behavior.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

kasprintf calculates the size of the result string, allocates a buffer large
enough to hold the string and then performs the format string operation. There
are a couple of places in ASoC where these three steps are done by hand and
where kasprintf can be used instead.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some devices may benefit from being able to start some parts of the widget
power up/down sequence earlier on in the sequence than the point at which
the final power state is committed. Support these by providing events which
are called before any power state changes are done.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>

Update dapm_clock_event to use clk_prepare_enable and
clk_disable_unprepare.
Signed-off-by: NFabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

When clearing the walked flags there is no need to clear all paths, we
only need to clear the paths we actually walked. This means we can split
dapm_clear_walk() into input and output versions and rather than going
through all DAPM paths we can recurse down the path until we encounter
paths we have not yet walked.

This reduces the number of operations we need to perform and improves
cache locality.

[Pulled out of the vendor tree that the patch was originally generated
for by me, any bugs were introduced in that process -- broonie]
Signed-off-by: NRyo Tsutsui <Ryo.Tsutsui@wolfsonmicro.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We already clear the walked state in dapm_widget_power_check(), no need
to do it again.
Signed-off-by: NRyo Tsutsui <Ryo.Tsutsui@wolfsonmicro.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This is the equivalent of commit af46800b "ASoC: Implement mux control
sharing", but applied to mixers instead of muxes.

This allows a single control to affect multiple mixer widgets at once,
which is useful when there is a single set of register bits that affects
multiple mixers in HW, for example both the L and R mixers of a stereo
path.

Without this, you either:

1) End up with multiple controls that affect the same register bits, but
whose DAPM state falls out of sync with HW, since the DAPM state is only
updated for the specific control that is modified, and not for other
paths that are affected by the register bit(s).

2) False paths through DAPM, since you end up merging unconnected stereo
paths together into a single widget which hosts the single control, and
then branching back out again, thus conjoining the enable states of the
two input paths.

Now that the kcontrol creation logic is split out into a separate
function, dapm_create_or_share_mixmux_kcontrol(), also use that to
replace most of the body of dapm_new_mux(). This should produce no
functional change, but simply eliminates some mostly duplicated code.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

*path is not yet initialized when we check if the widget is connected.

The compiler also warns about this:
sound/soc/soc-dapm.c: In function 'is_connected_output_ep':
sound/soc/soc-dapm.c:824:18: warning: 'path' may be used uninitialized in this function
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Commit 497098be ("ASoC: dapm: Remove bodges for no-widget CODECs") removed the
last user of the n_widgets field. Currently it is incremented for each widget
added, but the value is never used, so we can remove it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Currently if a path loops back on itself we correctly skip over it to
avoid going into an infinite loop but this causes us to ignore the need
to power up the path as we don't count the loop for the purposes of
counting inputs and outputs. This means that internal loopbacks within a
device that have powered devices on them won't be powered up.

Fix this by treating any path that is currently in the process of being
recursed as having a single input or output so that it is counted for
the purposes of power decisions.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>

Help avoid noise from the power up of the capture path propagating through
into the start of the recording (especially noise caused by the ramp of
microphone biases) by keeping the capture muted until after we've finished
powering things up with DAPM in the same manner we do for playback. This
allows us to take advantage of soft mute support in the hardware more
effectively and is more consistent.

The core code using the existing digital mute operation is updated to take
advantage of this. Some additional cases in the soc-pcm code and suspend
will need separate handling but these are less practically relevant than
the main runtime stream start/stop case.

Rather than refactor the digital mute function in every single driver a
new operation is added for drivers taking advantage of this functionality,
the old operation should be phased out over time.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by Vinod Koul <vinod.koul@intel.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>

Enable bypass when the regulator is idle, not when it is in use. This is
consistent with what the few existing users actually want.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>