This is a fix for the problem in commit 785f857d, the pop noise
issue on some machines with ALC269.  The problem was the uninitialized
state after the resume due to the delayed resume of the codec chips.
In that commit, we tried to fix by forcibly putting the codec to D3 at
suspend.  But, this still also leaves the uninitialized state after
resume, and it _might_ be still problematic with some BIOS.  Since the
commit turned out to regress another issues, we reverted it in the
end.

Now, in this fix, try to fix by turning on the codec immediately at
the resume path.  We need to take care of the power-saving in this
case.  When the device is woken up at the power-saved state, it should
go power-saving again after the resume.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The work struct must be initialized before the possible call in the
destructor.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just a clean up by calling the same helper function.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts commit 785f857d.

The commit causes a problem with the wrong D3 state after suspend
because the call of hda_set_power_state() involves with the power-up
sequence, which changes the power_count, and this confuses the resume
sequence that checks the power_count as well.

Originally, this go-to-D3 sequence should be a simple task without the
power-up sequence.  But, it'd need some proper sanity checks in the
case of power-saved state, so it's not too easy to write now in the
3.4-rc cycle.

In short, the safest option now is to revert this affecting commit.

Of course, we need to clean up and robustify the power-saving code
better for 3.5 kernel.
Reported-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The call for alc_auto_parse_customize_define() must be done after the
fixup pre-probe initialization.  Otherwise SKU_IGNORE fixup won't work
properly (e.g. HP RP5800 with ALC662 codec).
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hdsp uses its own ioctls to acquire config- and status information.
Expose the corresponding ioctl handler via ioctl_compat, so that 32bit applications can use it on 64bit kernels.
Signed-off-by: NAndre Schramm <andre.schramm@iosono-sound.com>
Reviewed-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reported-by: NPhilipp Matthias Hahn <pmhahn@pmhahn.de>
Cc: <stable@kernel.org> [v3.3+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Acer Aspire 5739G requires the same fix-up for 4930G to support the
surround / bass speakers.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43180Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This assertion seems to imply that chip->dsp_code_to_load is a pointer.
It's actually an integer handle on the actual firmware, and 0 has no
special meaning.

The assertion prevents initialisation of a Darla20 card, but would also
affect other models. It seems it was introduced in commit dd7b254d.

ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting...
ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000
ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware...
ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20
------------[ cut here ]------------
WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]()
Hardware name: Dell DM051
BUG? (!chip->dsp_code_to_load || !chip->comm_page)
Signed-off-by: NMark Hills <mark@pogo.org.uk>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASoC: Updates for 3.4

Nothing terribly exciting here, a bunch of small and simple fixes
scattered around the place.

Signed-off-by: NOleg Matcovschi <oleg.matcovschi@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLiam Girdwood <lrg@ti.com>

As s3c2412-i2s is using the s3c_i2sv2 it should call the more specialised
s3c_i2sv2_register_dai instead of simply calling snd_soc_register_dai.

Without this call the snd_soc_dai_ops structure isn't initialised correctly.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The core allocates the live copies, we shouldn't try to duplicate it and
were buggy trying to do so as we were using uninitialised data for the
control data.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

* commit f9dfbf91 "ASoC: tlv320aic23: convert to soc-cache" leads to
a bug preventing resumeof the codec as regmap expects a 9 bits data
register but 0xFFFF is passed in tlv320aic23_set_bias_level and this
values gets cached preventing any write to the TLV320AIC23_PWR
register as the final value produced by regmap is (register << 9) | value

* this patch solves the problem by only working on the 9 bits the
register contains.
Signed-off-by: NEric Bénard <eric@eukrea.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

Commit 980b0bc6 ("ASoC: blackfin: Use dai_fmt") converted the blackfin ASoC
machine drivers to use the dai_links dai_fmt field to setup their DAI format.
For the bf5xx-ssm2602 the commit removed the manual call to snd_soc_dai_set_fmt,
but missed to set the dai_links dai_fmt field.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NRichard Zhao <richard.zhao@freescale.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

Add description for 'reg' field.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

While we need to clean up unused single ended line outputs we don't want
to do this if the outputs are in differential mode.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

ASoC: updates for 3.4

Slightly larger than normal - the DAPM fix is a "this should always have
worked" type of thing which is very clear and should have no impact on
systems that don't need it.  The WM8994 fix is driver specific but
pretty important for that driver.

This ensures a clean startup of the channels, without this change some
use cases could result in issues in a small proportion of cases.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

Some old codecs like ALC880 seem to give a bogus pin capability value 0
occasionally.  This breaks the new sanity check in snd_hda_set_pin_ctl().
Skip the sanity checks in such a case.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a new helper function to guess the default VREF pin control bits
for mic in.  This can be used to set the pin control value safely
matching with the actual pin capabilities.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For setting the pin-control values more safely to match with the
actual pin capability bits, a copule of new helper functions,
snd_hda_set_pin_ctl() and snd_hda_set_pin_ctl_cache(), are
introduced.  These are simple replacement of the codec verb write with
AC_VERB_SET_PIN_WIDGET but do more sanity checks and filter out
superfluous pin-control bits if they don't fit with the corresponding
pin capabilities.

Some codecs are screwed up or ignore the command when such a wrong bit
is set.  These helpers will avoid such secret errors.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

According to the reporter, external mic starts to work if the
laptop-dmic model is used. According to BIOS pin config, all
pins are consistent with the alc269vb_laptop_dmic fixup, except
for the external mic, which is not present.

Cc: stable@kernel.org
BugLink: https://bugs.launchpad.net/bugs/950490Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Conflicts:
	sound/pci/hda/patch_conexant.c
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge fixes for Thinkpad docking-station regressions for 3.3 kernels
back to 3.4.  These were committed in that branch to make the stable
merging easier.

Conflicts:
	sound/pci/hda/patch_conexant.c

ThinkPad 410,420,510,520 and X201 with cx50585 & co chips have the
docking-station ports, but BIOS doesn't initialize for these pins.
Thus, like the former X200, we need to set up the pins manually in the
driver.

The odd part is that the same PCI SSID is used for X200 and T400, thus
we need to prepare individual fixup tables for cx5051 and others.

Bugzilla entries:
	https://bugzilla.redhat.com/show_bug.cgi?id=808559
	https://bugzilla.redhat.com/show_bug.cgi?id=806217
	https://bugzilla.redhat.com/show_bug.cgi?id=810697Reported-by: NJosh Boyer <jwboyer@redhat.com>
Reported-by: NJens Taprogge <jens.taprogge@taprogge.org>
Tested-by: NJens Taprogge <jens.taprogge@taprogge.org>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some output pins on Conexant chips have no HP control bit, but the
auto-parser initializes these pins unconditionally with PIN_HP.

Check the pin-capability and avoid the HP bit if not supported.

Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Current alsa_sound_last_init() was called as __initcall().
So, on current ALSA, only devices that had been properly
registered at this point were shown.
So, it will show "No soundcards found" if driver requests
probe deferment. it's often misleading.
This patch delays the timing of alsa_sound_last_init()
as workaround.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviwed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While refactoring the mute-LED handling for HP laptops, I messed up
the polarity check in a wrong way.  The red (or the mute-LED if any)
should appear in the muted state, corresponding to GPIO on.
Reported-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Through the transition to the auto-parser, the support for
Quanta/Gericom KN1 got broken.  There are two problems behind it:

- This machine doesn't like the default COEF setup for ALC260 we take
  now as default

- BIOS doesn't set the pins correctly at all; especially the machine
  uses only the pin 0x0f for both headphone and speaker

This patch adds the fixup as a workaround for these issues.
Reported-and-tested-by: NUros Vampl <mobile.leecher@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Leading up to the ->device_prep_slave_sg change in
185ecb5f 'dmaengine: add context
parameter to prep_slave_sg and prep_dma_cyclic' a generic wrapper was
added in place to guard against the API change, though the fsi driver
wasn't updated in the process (presumably its dmaengine support hadn't
been merged yet at the time). This trivially switches over to the new
wrapper and gets it building again.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Fix kernel-doc warning in sound/core/vmaster.c:

Warning(sound/core/vmaster.c:429): No description found for parameter 'private_data'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently we increment the number of RTD's per card during the DAI link
bind. This can cause an incorrect RTD count when we cannot find a component
and defer the probe (and hence perform the DAI link bind for the card again).

Fix the count so that it is cleared before every card registration
and bind attempt.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If cs42l73_get_mclkx_coeff() returns < 0 (which it can) in
sound/soc/codecs/cs42l73.c::cs42l73_set_mclk(), then we'll be using
the (negative) return value as array index on the very next line of
code - that's bad.

Catch the negative return value and propagate it to the caller (which
checks for it) and things are a bit more sane :-)
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In sound/pci/hda/patch_realtek.c::alc_auto_fill_dac_nids(), in the
'for (;;)' loop, if the 'badness' value returned from
fill_and_eval_dacs() is negative, then we'll return from the function
without freeing the memory we allocated for 'best_cfg', thus leaking.
Fix the leak by kfree()'ing the memory when badness is negative.

While I was there I also noticed some trailing whitespace in the
function that I removed (along with all other trailing whitespace in
the file) - it didn't seem worth-while to do that as two patches, so I
hope it's OK that I just did it all as one patch.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Line widgets had not been included in either the power up or power down
sequences so if a widget had an event associated with it that event would
never be run. Fix this minimally by adding them to the sequences, we
should probably be doing away with the specific widget types as they all
have the same priority anyway.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org