We don't really care how many widgets a supply is supplying, we just care
if the number is non-zero. This didn't actually produce any improvement
in the test cases I've been using but seems obviously sensible enough that
I'm pushing it out anyway.

We could do a similar thing for other widgets but this may be unhelpful
for further refactorings Liam was working on aiming to allow us to
identify connected audio paths.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The whole point of supply widgets is that they aren't inputs to their
sinks so a state change in a supply should never affect the state of the
widget being supplied and we don't need to mark them as dirty.

           Power    Path   Neighbour
Before:    69       727    905
After:     63       607    731

This is particularly useful where supplies affect large portions of the
chip (eg, a bandgap supplying the analogue sections).
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some widgets will get power_check() run on them more than once during a
DAPM run, most commonly due to supply widgets checking to see if their
consumers are powered up. It's wasteful to do this so cache the result
of power_check() during a run. For one system I tested this on I got an
improvement of:

           Power    Path   Neighbour
Before:    106      970    1186
After:     69       727    905

from this.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Help diagnose why we're checking widgets by providing some logging when
we first dirty them. This should possibly be a trace point if it's useful
but can be absurdly verbose if enabled, we can always change it later if
desired.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If two widgets are not currently connected then there is no need to
propagate a power state change between them as we mark the affected
widgets when we change a connection. Similarly if a neighbour widget is
already in the state being set for the current widget then there is no
need to recheck.

On one system I tested this gave:

           Power    Path   Neighbour
Before:    114      1066   1327
After:     106      970    1186

which is an improvement, although relatively small.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In order to reduce the number of DAPM power checks we run keep a list of
widgets which have been changed since the last DAPM run and iterate over
that rather than the full widget list. Whenever we change the power state
for a widget we add all the source and sink widgets it has to the dirty
list, ensuring that all widgets in the path are checked.

This covers more widgets than we need to as some of the neighbour widgets
won't be connected but it's simpler as a first step. On one system I tried
this gave:

           Power    Path   Neighbour
Before:    207      1939   2461
After:     114      1066   1327

which seems useful.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We're not actually doing any dynamic power management based on connection
and output drivers (which are pretty much the same thing) are marked as
unconditionally connected already.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We've got the same code in two different places, let's have it in a single
place instead.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Makes the code simpler.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Future patches will try to reduce the number of widgets we check on each
DAPM run but we're still going to need to look and see if the devices is
on at all so we can manage the overall device bias. Move these checks out
into the main dapm_power_widgets() function so we don't have to think about
them for now.

Once we're doing more incremental updates it'll probably be worth using
refcounts for each bias level to avoid having to do the sweep over all
widgets but that's not going to be where the big performance wins are.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Split the decision about what the new power should be out from the
implementation of that decision.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Missed when the stat was originally added.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Currently we force all devices in the system to be at the same bias level.
This is due to concerns about power or pop/click impacts from either
ramping VMID or mismatching VMID on the analogue I/O lines between
connected devices but does mean we power devices up more often than we
really need to.

If a device flags idle_bias_off this will usually mean that it's either
all digital or ground referenced (in which case the idle and powered bias
levels are identical) so this concern does not apply and we can save some
power by leaving it off when not needed itself.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The number of times we look at a potentially connected neighbour is just
as important as the number of times we actually recurse into looking at
that neighbour so also collect that statistic.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The indentation is getting a little deep. Should be straight code motion,
no functional changes.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

One of the longest standing areas for improvement in ASoC has been the
DAPM algorithm - it repeats the same checks many times whenever it is run
and makes no effort to limit the areas of the graph it checks meaning we
do an awful lot of walks over the full graph. This has never mattered too
much as the size of the graph has generally been small in relation to the
size of the devices supported and the speed of CPUs but it is annoying.

In preparation for work on improving this insert a trace point after the
graph walk has been done. This gives us specific timing information for
the walk, and in order to give quantifiable (non-benchmark) numbers also
count every time we check a link or check the power for a widget and report
those numbers. Substantial changes in the algorithm may require tweaks to
the stats but they should be useful for simpler things.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Useful for diagnostics.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

We have dapm_context instead of codec parameter.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Currently it is only possible to route one source per switch into a mixer.
This patch modifies the code, so that it is possible to route multiple sources
into a mixer via the same switch. One use-case for this is routing a stereo
channel pair into a mono-mixer via the same switch.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Stream event debug can be noisy on larger audio devices so improve the
debug SNR by changing it to the verbose level.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for Dynamic PCM (AKA DSP) support.

This adds a callback function to be called at the completion of a DAPM stream
event.

This can be used by DSP components to perform calculations based on DAPM graphs
after completion of stream events.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for ASoC Dynamic PCM (AKA DSP) support.

Provide convenience methods to retrieve the soc_card or snd_card from a
DAPM context.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Makes life a little easier if you want to add subsequences to an existing
driver as you can use -1 to put things at the start of sequences.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Allow platform driver widgets to perform any IO required for DAPM.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Previously we were using the DAPM context rather than a widget as the
argument for update_bits() so we didn't need to care that our list walk
of widgets left us one beyond the end of the list. Now we're using them
for the register update we need to make sure we're pointing at an actual
widget not the list_head.

Fix originally suggested by Liam on IM.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

This time with soc_widget_update_bits reflecting recent soc_update_bits changes.

Currently widget IO is tightly coupled to the CODEC drivers. Future platform DSP
devices have mixer components that can alter power usage and hence require full
DAPM support.

This provides a generic widget IO operation wrapper in preparation for
future patches that implement platform driver DAPM.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Normally DAPM will power up any connected audio path. This is not ideal
for sidetone paths as with sidetone paths the audio path is not wanted in
itself, it is only desired if the two paths it provides a sidetone between
are both active. If the sidetone path causes a power up then it can be
hard to minimise pops as we first power up either the sidetone or the main
output path and then power the other, with the second power up potentially
introducing a DC offset.

Address this by introducing the concept of a weak path. If a path is marked
as weak then DAPM will ignore that path when walking the graph, though all
the relevant controls are still available to the application layer to allow
these paths to be configured.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Currently it is possible that snd_soc_new_{mixer,mux,pga} is called with a
DAPM context not matching the widgets context. This can lead to a wrong
prefix_len calculation, which will result in undefined behaviour. To avoid
this always use the DAPM context from the widget itself.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org

This allows the card driver to use the bias level variable more easily in
multi component systems.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

The card callback will get called for each DAPM context in the card so it
can be useful for it to know which device is currently undergoing a
transition.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

No functional changes but much less indentation.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

It's redundant now thanks to the use of the generic trace infrastructure.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

More with the legibility.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

If the only widgets active within a CODEC are supplies and micbiases we
are not passing audio, we are probably just doing microphone detection.
This will not generally require either fully accurate reference voltages
or much power so

If this turns out to be unsuitable for some systems we can provide a
facility to override this decision.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Rather than a simple flag to say if we want the DAPM context to be at full
power specify the target bias state. This should have no current effect
but is a bit more direct and so makes it easier to change our decisions
about the which bias state to go into in future.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Commit af46800b ("ASoC: Implement mux control sharing") introduced
function dapm_is_shared_kcontrol.

When this function returns true, the naming of DAPM controls is derived
from the kcontrol_new. Otherwise, the name comes from the widget (and
possibly a widget's naming prefix).

A bug in the implementation of dapm_is_shared_kcontrol made it return 1
in all cases. Hence, that commit caused a change in control naming for
all controls instead of just shared controls.

Specifically, a control is always considered shared because it is always
compared against itself. Solve this by never comparing against the widget
containing the control being created.

Equally, controls should never be shared between DAPM contexts; when the
same codec is instantiated multiple times, the same kcontrol_new will be
used. However, the control should no be shared between the multiple
instances.

I tested that with the Tegra WM8903 driver:
* Shared is now mostly 0 as expected, and sometimes 1.
* The expected controls are still generated after this change.

However, I don't have any systems that have a widget/control naming
prefix, so I can't test that aspect.

Thanks for Jarkko Nikula for pointing out how to fix this.
Reported-by: NLiam Girdwood <lrg@ti.com>
Tested-by: NJarkko Nikula <jhnikula@gmail.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Commit 52ba67bf ("ASoC: Force all DAPM contexts into the same bias state")
powers up all the DAPM contexts in a card if any DAPM context becomes
active. Unfortunately power down newer happens if per-card DAPM context
doesn't have any widgets.

Reason for this is that power state of per-card DAPM context without
widgets is never cleared and thus all the DAPM contexts remain permanently
active. Test for widgetless calling DAPM context in dapm_power_widgets()
doesn't work for per-card DAPM context since power change is never
originating from widgetless per-card DAPM context.

Fix this by pre-clearing power state flag of non-codec DAPM context at the
beginning of power sequence.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Control sharing is enabled when two widgets include pointers to the
same kcontrol_new in their definition. Specifically:

static const struct snd_kcontrol_new adcinput_mux =
	SOC_DAPM_ENUM("ADC Input", adcinput_enum);

static const struct snd_soc_dapm_widget wm8903_dapm_widgets[] = {
  SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux),
  SND_SOC_DAPM_MUX("Right ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux),
};

This is useful when a single register bit or field affects multiple
muxes at once. The common case is to have separate control bits or
fields for each mux (channel). An alternative way of looking at this
is that the mux is a stereo (or even n-channel) mux, rather than
independant mono muxes.

Without this change, a separate kcontrol will be created for each
DAPM_MUX. This has the following disadvantages:

* Confuses the user/programmer with redundant controls that don't
  map to separate hardware.

* When one of the controls is changed, ASoC fails to update the DAPM
  logic for paths solely affected by the other controls impacted by
  the same register bits. This causes some paths not to be correctly
  powered up or down. Prior to this change, to work around this, the
  user or programmer had to manually toggle all duplicate controls away
  from the intended setting, and then back to it.

Control sharing implies that the control is named based on the
kcontrol_new itself, not any of the widgets that are affected by it.

Control sharing is implemented by: When creating kcontrols, if a
kcontrol does not yet exist for a particular kcontrol_new, then a new
kcontrol is created with a list of widgets containing just a single
entry. This is the normal case. However, if a kcontrol does already
exists for the given kcontrol_new, the current widget is simply added
to that kcontrol's list of affected widgets.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

A future change will allow multiple widgets to be affected by the same
control. For example, a single register bit that controls separate muxes
in both the L and R audio paths.

This change updates the code that handles relevant controls to be able
to iterate over a list of affected widgets. Note that only the put
functions need significant modification to implement the iteration; the
get functions do not need to iterate, nor unify the results, since all
affected widgets reference the same kcontrol.

When creating the list of widgets, always create a 1-sized list, since
the control sharing is not implemented in this change.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Future changes will need reference to the kcontrol created for a given
kcontrol_new. Store the created kcontrol values now.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>