The snd_soc_dapm_xxxx_pin all require the dapm_mutex to be held when
they are called as they edit the dirty list, however very few of the
callers do so.

This patch adds unlocked versions of all the functions replacing the
existing implementations with one that holds the lock internally. We
also fix up the places where the lock was actually held on the caller
side.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

The error messages for bypassing/unbypassing a regulator appear to be
swapped round, this patch corrects these.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Commit f7d3c170 ("ASoC: dapm: Change prototype of soc_widget_read") changed the
signature of soc_widget_read() so that it, instead of return the register value
as a int, takes a pointer to a unsigned int and stores the register value in
that pointer. There are still a few places that pass a int type value to that
function though. Change these to unsigned int. For more consistency also change
the signature of soc_widget_write() to take a unsigned int instead of an int for
the register value.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The prefix for the codec driver can be used during dual identical
codec usecases. However, dapm adds prefix twice for codec DAI widget
in snd_soc_dapm_add_route API.

This change is to avoid double prefix addition for codec DAI widget
and is needed while using identical dual codecs.
Signed-off-by: NSonghee Baek <sbaek@nvidia.com>
Signed-off-by: NArun Shamanna Lakshmi <aruns@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

soc_widget_read API returns the register data and it is possible
that a register can contain 0xffffffff. Thus, change the prototype
of soc_widget_read to return only the error code and pass the reg
data through pointer argument.
Signed-off-by: NArun Shamanna Lakshmi <aruns@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Connect the DAPM graph through each BE DAI link to the componnent(s) on the
other side of the BE DAI link. This allows the graph to be walked on
both sides of the link when graph changes are made.
Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

    DPCM can dynamically alter the FE to BE PCM links at runtime based
on mixer/mux setting updates. Add soc_dpcm_runtime_update() calling in
get/put function for mixer/mux to support this feature.
Signed-off-by: NNenghua Cao <nhcao@marvell.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Leaving BUG_ON() in a core layer like dapm is rather inappropriate as
it leads to panic(), even though sanity checks might be still useful
for debugging.
Instead, Use WARN_ON(), and handle the error cases accordingly.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

BUG() used in the driver is just to spit the stack trace on buggy
points, not really needed to stop the whole operation.  For that
purpose, it'd be more convenient to use WARN() instead with more
error information.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

... instead of NULL dereferences.

Spotted by coverity CID 402004.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

... due to a copy & paste error.

Spotted by coverity CID 710923.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

In order to avoid trying to use an external clock or supply for an
on-chip supply prior to it being enabled move the clock and regulator
supply events to a separate step in DAPM sequencing from normal supply
events.

This should have minimal practical impact since these widgets are sorted
using SND_SOC_NOPM which is a negative value and hence sorted
separately to any real register writes, though it may be relevant if
supplies have event callbacks only.
Signed-off-by: NMark Brown <broonie@linaro.org>

Within a DAPM sequence we normally don't care about when exactly a register
write has completed so long as they happen in the order we requested. This
means that we can issue most of the writes we do asynchronously which
should maximise the ability of the underlying frameworks to keep the
hardware busy, providing a small performance improvement on some systems.

We currently ensure that all writes are completed both when changing to a
different device and when calling into the regulator and clock frameworks.
This should ensure that the previous ordering is maintained.

We also ensure that writes are completed prior to calling into widget
event functions since some event functions implement delays.  This
should be improved in future so that widgets can disable this sync in
order to add extra writes.
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch adds support for virtual DAPM mixer controls. They are similar to
virtual DAPM enums. There is no hardware register backing the control, so
changing the control's value wont have any direct effect on the hardware. But it
still influences the DAPM graph by causing the path it sits on to be connected
or disconnected. This in turn can cause power changes for some of the widgets on
the DAPM graph, which will then modify the hardware state.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

VMID widgets behave very similar to signal generator widgets. Both are always
considered to be powered up. This means that we need to ignore the VMID widgets
in the same way as signal generator widgets when calculating the DAPM context's
target bias level. Otherwise the presence of a VMID widget, regardless whether
it is on an active path or not, will cause the DAPM context to be powered up.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

We need to make sure that the control's cached value is initialized to the same
value as the control's widget->on_val. Otherwise updates might be lost.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

snd_soc_dapm_new_widgets() works on the ASoC card as a whole not on a specific
DAPM context. The DAPM context that is passed as the parameter is only used to
look up the pointer to the card. This patch updates the signature of
snd_soc_dapm_new_widgets() to take the card directly.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The current calls to dapm_mark_dirty() in snd_soc_dapm_add_path() are on a path
that is only reached if the sink widget is either a mixer or a mux. Move the
calls further up so they are called for all widget types.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Ensure that the recently added path kcontrol list is initialised otherwise
we may crash trying to delete routes that don't have kcontrols.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>

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>