The WM1811 has a slightly different range on LDO2 to other WM8994 class
devices.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

By accident few places still uses the _2r calls from
the core.
This is a quick fix, the drivers using the old callbacks
going to be changed.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Checking the pdata-flags used 'or', so the check is always true. Use 'and' to
correctly mask the flags.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We synchronise jack state on startup - when we do that make sure that we
have set up all the DAPM widgets first in case we end up touching any of
the partially set up widgets when syncing the jack pins.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

The snd_soc_*_volsw_2r functionality has been merged to
*volsw callbacks.
Few places still used the get, or put variant of volsw_2r,
replace those with the corresponding *_volsw.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

Eliminate below build warning:
  CC      sound/soc/codecs/wm9090.o
sound/soc/codecs/wm9090.c: In function 'wm9090_probe':
sound/soc/codecs/wm9090.c:550: warning: unused variable 'wm9090'
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

These functions are removed in commit f0fba2ad
"ASoC: multi-component - ASoC Multi-Component Support".
Let's remove the leftover function declaration in header file.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Let the user know, that the callback has been called with unexpected
register parameter.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We do not have users for snd_soc_put_volsw_2r anymore.
It can be removed.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The ASoC core now have one callback function, which can handle
single, and double register mixer controls.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Handle the put_volsw/put_volsw_2r in one function.

To avoid build breakage in twl6040 keep the
snd_soc_put_volsw_2r as define, and map it snd_soc_put_volsw.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Handle the get_volsw/get_volsw_2r in one function.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Handle the info_volsw/info_volsw_2r in one function.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

SOC_SINGLE/DOUBLE_VALUE is used for mixer controls, where the
bits are within one register.

Assign .rreg to be the same as .reg for these types.

With this change we can tell if the mixer in question:
is mono:
mc->reg == mc->rreg && mc->shift == mc->rshift

is stereo, within single register:
mc->reg == mc->rreg && mc->shift != mc->rshift

is stereo, in two registers:
mc->reg != mc->rreg

The patch provide a small inline function to query, if the mixer
is stereo, or mono.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Avoid using the mc->rreg to identify the 2r type of gain control.
Introduce a variable to track this.
This change is needed to avoid breakage with the upcoming volsw volsw_2r
merger.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The custom get_volsw does not need to call any core get_volsw calls,
since we are returning the shadow values for the gains.
Return -EINVAL in the unlikely event, if the function has been called
for unhandled control. This way we can remove one check in the code.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Use the macros for controls require custom get/put function.
This is to make sure that the soc_mixer_control is used
consistently among the drivers.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Arun KS <arunks@mistralsolutions.com>
Cc: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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

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>

schedule_delayed_work() returns a bool indicating if the work was already
queued when it succeeds so we need to squash a true down to zero.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Also fix return values for speaker switch updates.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org

Return -EINVAL in the unlikely event, if the function has been called
for unhandled control. This way we can remove one check in the code.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

With the new macro we can remove duplicated code
for the SOC_DOUBLE_R type of controls.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

With the new macro we can remove duplicated code
for the SOC_DOUBLE type of controls.
We can also remap the SOC_SINGLE_VALUE macro to
SOC_DOUBLE_VALUE
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>