module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The verb command in stac92xx_post_suspend caused the audio to stop
working after resuming from S3 mode on HP laptops with the VREF-pin
mute-LED control.  Removing relevant post_suspend registering.

Although removing D3 on AFG is no optimal solution, the impact should
be small in comparison with the broken S3/S4.
Signed-off-by: NCharles Chin <Charles.Chin@idt.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This quirk sould be reverted. It has the following probems:

1) The quirk was intended to "ASUS MV2-MX SE" motherboards only, but the
ID used matches a much broader range, potentially all boards containing a
VIA chipset model in the family of vendor VIA 0x1106 and audio device ID
0x3288, which encompasses VIA-VT82xx, VIA-VT1xx and VIA-VT20xx chipsets.

2) VIA chipsets rely on azx_via_get_position() to handle correctly dma
transfers during capture. Using POS_FIX_LPIB instead of POS_FIX_VIACOMBO
leads to partially corrupted input buffers during capture. The effects
of this bug are not immediately visible, it took strong DSP expertise,
some expensive signal generator and a spectrum analyzer to identify it
and verify correct behaviour using original default.

3) It's almost certain that the quirk did not fix the real problem,
if there was one. Refer to original submission:
http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025109.htmlSigned-of-by: NMarc Vertes <mvertes@sigfox.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some HP laptops use a pin VREF for controlling the mute LED, and such a
pin shouldn't be powered off.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

VT1708 has no support for unsolicited events per jack-plug, the driver
implements the workq for polling the jack-detection.  The mixer element
"Jack Detect" was supposed to control this behavior on/off, but this
doesn't work properly as is now.  The workq is always started and the
HP automute is always enabled.

This patch fixes the jack-detect control behavior by triggering / stopping
the work appropriately at the state change.  Also the work checks the
internal state to continue scheduling or not.

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

The CS420X_IMAC27 was copied from the line before but CS420X_APPLE
was clearly intented.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use an inline function for the common pattern for assigning a capsrc.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the imux entries are rebuilt in alc_rebuild_imux_for_auto_mic(),
the initialization of index field is missing.  It may work without it
casually when the original imux was created by the auto-parser, but
it's definitely broken in the case of static configs where no imux was
parsed beforehand.  Because of this, the auto-mic switching doesn't
work properly on some model options.

This patch adds the missing initialization of index field.
Reported-by: NDmitry Nezhevenko <dion@inhex.net>
Cc: <stable@kernel.org> [v3.1]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The PCI SSID 8086:7270 is commonly used for multiple Apple machines,
thus we can't use it as identifier for a unique model.  Because of this
conflict, some machines show weird behavior.  For example, MacBook Air
shows Front and Surround speakers although only Surround works due to
the wrongly overridden pin-configuration for imac27.

This patch fixes two things:
- Stop the wrong pin-config override of imac27 by removing PCI SSID
  entry for avoiding the wrong mappings,
- Add the generic GPIO setup for Apple machines by checking the codec
  SSID vendor bits
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NDirk Hohndel <hohndel@infradead.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In snd_hda_check_board_codec_sid_config(), not only comparing with the
exact value but allow the bit-mask comparison for vendor-only, etc.
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NDirk Hohndel <hohndel@infradead.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With the ELD repoll mechanism, we can (and should) fail the ELD reading
immediately when find something obviously wrong and let the caller retry
after some delay.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Improve the one-shot ELD repoll to up to 6 retries.

Up to now the 300ms looks sufficient for the test boxes. However
I'm a bit worried about how well it can fit the wider user base.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reported-by: NAlbert Pool <albertpool@solcon.nl>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

spec->cur_adc isn't set until cs_capture_pcm_prepare() is called although
the driver tries to select the connection at init time and at auto-mic
switch.  This results in the access to the widget NID 0, which is
obviously invalid, also a wrong capture source.

This patch fixes the issue by issuing the connect-select verb conditionally
at appropriate places.
Reported-and-tested-by: NDylan Reid <dgreid@chromium.org>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It looks more natural and saves two lines of code.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
actually readable. During the time the ELD buffer is mysteriously all 0.

Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

memset(eld) clears eld->proc_entry which will leak the struct
snd_info_entry when unloading module.

Fix it by
- memset only the fields before eld->eld_buffer
- set eld->eld_valid to true _after_ all eld fields have been filled

Cc: <stable@kernel.org>
Cc: Pierre-louis Bossart <pierre-louis.bossart@intel.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Having just one semicolon after a break statement is enough.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Clean up and fix pwr_nids for 92HD71 / 73 / 83 family codecs; remove
pwr_mapping which was incorrect.

The original pwr_nids support of 92HD83xxx was incorrect and never
actually worked before.  Now we should have things working correctly
without having to hack by DID anymore.

It is also not necessary to explicitly turn on all the pins near the
beginning of patch_stac92hd83xxx() now, the pins will go though
initialization properly.

Tested on 92HD66 / 71 / 73 / 75 / 83 / 89 / 91 demo boards.
Signed-off-by: NCharles Chin <Charles.Chin@idt.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We disabled the check of NO_PRESENCE bit of the default pin-config
in commit f4419172 temporarily.  One problem was that the first
implementation was wrong -- the bit after the shift must be checked.
However, this would still give many regressions on machines with broken
BIOS.  They set this bit wrongly even on active pins.

A workaround is to check whether all pins contain this bit.  As far as
I've checked, broken BIOSen set this bit on all pins, no matter whether
active or not.  In such a case, the driver should ignore this bit check.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a virtual mater control is created, the driver looks for slave
elements from the assigned card instance.  But this may include the
elements of other codecs when multiple codecs are on the same HD-audio
bus.  This works at the first time, but it'll give Oops when it's once
freed and re-created via reconfig sysfs.

This patch changes the element-look-up strategy to limit only to the
mixer elements of the same codec.
Reported-by: NDavid Henningsson <david.henningsson@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fix the not working internal mic on Dell Vostro 3500 laptop by introducing the
new model dell-vostro-3500.
Signed-off-by: NJulian Wollrath <jwollrath@web.de>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

According to the bug reporter, model=auto is needed to make the
internal microphone work.

BugLink: https://bugs.launchpad.net/bugs/819699
Reported-by: Andrej (agno01)
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a Realtek codec has a matrix-style capture-source selection, we
need to scan all connections instead of only imux items.  Otherwise some
input might be kept unmuted.  Although the corresponding input must be
dead so there should be no input from it, it's still safer to mute the
route completely.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The implementation on commit [08a1f5eb: ALSA: hda - Check NO_PRESENCE
pincfg default bit] seems like a mis-interpretation of specification.
The spec gives the reversed bit definition.  But, following the spec
also causes to change so many existing device configurations, thus we
can't change it so easily for now.  For 3.2-rc1, it's safer to revert
this check (actually this patch comments out the code).

We may re-introduced the fixed version once after the wider test-case
coverages are done.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The regression-fix in 3.1 for the check of DMA-position validity caused
yet another regression for CA0110.  As usual, this hardware seems working
only with LPIB properly.  Adding the appropriate driver-caps bit to force
LPIB fixes the problem.
Reported-and-tested-by: NAndres Freund <andres@anarazel.de>
Cc: <stable@kernel.org> [v3.1]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The 3.1 kernel has a regression for ALC861 codec where no sound output
is heard with the default setup.  It's because the amps in DACs aren't
properly unmuted while the output mixers are assigned only to pins.

This patch fixes the missing initialization of DACs when no mixer is
assigned to them.
Tested-by: NAndrea Iob <andrea_iob@yahoo.it>
Cc: <stable@kernel.org> [v3.1+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some BIOS report invalid pins as digital output pins.  The driver checks
the connection but it doesn't do it fully correctly, and it leaves some
undefined value as the audio-out widget, which makes the driver spewing
warnings.  This patch fixes the issue.

Reference: https://bugzilla.novell.com/show_bug.cgi?id=727348

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

Revise stac92xx_parse_auto_config to automatically scan for digital input
and output converters.
Signed-off-by: NCharles Chin <Charles.Chin@idt.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just clean-up what GCC caught.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the driver finds multiple ADCs, it tries to create an alternative
capture PCM stream.  However, these secondary ADCs might be useless or
in uncontrolled paths in some cases, e.g. when auto-mic or dynamic
ADC-switching is enabled.  Also, when only a single capture source is
available, the multi-streams don't make sense, too.

With this patch, the driver checks such condition and skips the alt
stream appropriately.

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

These codecs have SPDIF-in, which is new to the 92HD83xxx compatible
families, so a bit of logic is added to support them.
Signed-off-by: NCharles Chin <Charles.Chin@idt.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The power-widget control in patch_stac92hd83xxx() never worked properly,
thus it's safer to turn it off as default for now.
Signed-off-by: NCharles Chin <Charles.Chin@idt.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

HD-audio spec defines a bit in pin default configuration for indicating
that the pin isn't used for jack-detection although the codec is capable
of it.  Better to check this bit as well in jack_is_detectable() helper
function.
Reported-by: NRaymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

If a line in the firmware file is larger than the given buffer size (and
so the firmware file size), size is set to a value larger than the actual
buffer size. This results in an overflow in the buffer passed.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

These aren't modules, but they do make use of these macros, so
they will need export.h to get that definition.  Previously,
they got it via the implicit module.h inclusion.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Lots of sound drivers were getting module.h via the implicit presence
of it in <linux/device.h> but we are going to clean that up.  So
fix up those users now.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

The implicit presence of module.h lured several users into
incorrectly thinking that they only needed/used modparam.h
but once we clean up the module.h presence, these will show
up as build failures, so fix 'em now.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

It seems that Conexant CX20549 chip handle only a single input-amp even
though the audio-input widget has multiple sources.  This has been never
clear, and I implemented in the current way based on the debug information
I got at the early time -- the device reacts individual input-amp values
for different sources.  This is true for another Conexant codec, but it's
not applied to CX20549 actually.

This patch changes the auto-parser code to handle a single input-amp
per audio-in widget for CX20549.  After applying this, you'll see only a
single "Capture" volume control instead of separate "Mic" or "Line"
captures when the device is set up to use a single ADC.

We haven't tested 20551 and 20561 codecs yet.  If these show the similar
behavior like 20549, they need to set spec->single_adc_amp=1, too.

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

In the old Conexant chips (5045, 5047, 5051 and 5066), a single EAPD
may handle both headphone and speaker outputs while it's assigned only
to one of them.  Turning off dynamically leads to the unexpected silent
output in such a configuration with the auto-mute function.

Since it's difficult to know how the EAPD is handled in the actual h/w
implementation, better to keep EAPD on while running for such codecs.

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