The main role of the WM9081 is as a class D speaker amplifier so there
is no concern about pops. There are also very few registers and a fast
power up time so we can happily mark the driver as idle_bias_off.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Raise the ramp time to 50ms to cover corner cases, use the startup bias
generator, explicitly reset the ramp circuit when complete and reorder
things all of which should improve performance somewhat for systems that
are sensitive to noise from VMID.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The enable of the single ended line outputs on wm_hubs devices performs
better if the output is enabled prior to starting VMID. Since inactive
outputs are held at VMID anyway there is little cost to doing this for
unused outputs. Add callbacks into wm_hubs and keep track of which outputs
are really active so we can disable them once we're active.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
According to the mixer path diagram input sources' attenuators logically
belong to the playback path and DMIC boost only affects capture.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This brings the TLVs in sync with the documentation and allows to properly
manipulate mic boost controls with alsamixer.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Make sure we generate enough BCLKs for I2S style modes by always having
a minimum of two channels worth of clocks for the BCLK.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
No practical impact but now we have the control type we may as well use
it for the slightly nicer sequencing.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Make the mechanism used for WM8994 more like that for WM1811 and WM8958:
provide the logic to distinguish between headphone and headset and hard
code the reporting of sensible SND_JACK values. Should integration with
other detection mechanisms be required we can add appropriate callbacks
(though some integrations should be able to use the subsystem ones).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Otherwise we might get an error if the GPIO is configured as an input
since that makes the register volatile and a suspended device can't be
read from.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is the default state that the runtime PM infrastructure expects so
instead just kick the runtime PM core to suspend us if we're not doing
anything (as is default).
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
In cases where we should enter STANDBY DAPM will power us up, otherwise
there is no need to power up and we can remain in OFF.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently ASoC can only add kcontrols using codec and platform component device
handles. It's also desirable to add kcontrols for DAIs (i.e. McBSP) and for
SoC card machine drivers too. This allows the kcontrol to have a direct handle to
the parent ASoC component DAI/SoC Card/Platform/Codec device and hence easily
get it's private data.
This change makes snd_soc_add_controls() static and wraps it in the folowing
calls (card and dai are new) :-
snd_soc_add_card_controls()
snd_soc_add_codec_controls()
snd_soc_add_dai_controls()
snd_soc_add_platform_controls()
This patch also does a lot of small mechanical changes in individual codec drivers
to replace snd_soc_add_controls() with snd_soc_add_codec_controls().
It also updates the McBSP DAI driver to use snd_soc_add_dai_controls().
Finally, it updates the existing machine drivers that register controls to either :-
1) Use snd_soc_add_card_controls() where no direct codec control is required.
2) Use snd_soc_add_codec_controls() where there is direct codec control.
In the case of 1) above we also update the machine drivers to get the correct
component data pointers from the kcontrol (rather than getting the machine pointer
via the codec pointer).
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If we get an indeterminate impedance with both headset polarities then
give up and report the accessory as a headphone rather than continually
retrying.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
