So far, the driver doesn't power down the widget at going down to D3
when the widget node has an EAPD capability and EAPD is actually set
on all codecs unless codec->power_filter is set explicitly.
This caused a problem on some Conexant codecs, leading to click
noises, and we set it as NULL there.  But it is very unlikely that the
problem hits only these codecs.

Looking back at the development history, this workaround for EAPD was
introduced just for some laptops with STAC9200 codec, then we applied
it blindly for all.  Now, since it's revealed to have an ill effect,
we should disable this workaround per default and apply only for the
known requiring systems.

The EAPD workaround is implemented now as snd_hda_codec_eapd_power_filter(),
and this has to be set explicitly by the codec driver when needed.
As of now, only patch_stac9200() sets this one.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use the dynamic array allocations for pins, converters and PCM arrays
instead of the fixed size arrays.  The modern HDMI codecs get more and
more pins, and we don't know the sensitive limit.

Most of the patch are spent for the straight conversions from the
fixed array access to snd_array helpers.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

script/kernel-doc reports the following type of warnings (when run in verbose
mode):

Warning(sound/core/init.c:152): No description found for return value of
'snd_card_create'

To fix that:
- add missing descriptions of function return values
- use "Return:" sections to describe those return values

Along the way:
- complete some descriptions
- fix some typos
Signed-off-by: NYacine Belkadi <yacine.belkadi.1@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Expose the newly added TCO LTC and sync check functions to userspace.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds new ALSA controls to query the LTC state from userspace.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch prepares snd_hdspm_get_sync_check() to also check the TCO
sync state. The added feature will be exposed to the user in a later
commit.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Considerably shorten the code by using a macro. Though this won't lower
the binary size, it makes the source more readable.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For 96kHz, MADI allows to multiplex the samples (SMUX) or to use a
dedicated 96K mode. The RME cards default to 96K mode, but since not all
external MADI equipment supports this, provide a switch to users that
changes the on-wire protocol to SMUX.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When using the additional Time Code Option module in slave mode or the
SYNC-In wordclock connector, the sample rate needs to be returned by
hdspm_external_sample_rate().

Since this sample rate may contain any value with 1Hz granularity, we
need to round it to a common rate as done by the OSX driver.

[Fixed missing function declarations by tiwai]
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit introduces hdspm_get_pll_freq() to avoid code duplication.
Reading the sample rate from the DDS register will be required by
upcoming code.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a headphone pin is set up as a shared hp/mic pin, we rather want
to keep it as a headphone primarily as default, but the driver
overrides it always as a mic pin, just because the input controls are
created after outputs.  Add a check of pin NID and skip the
re-initialization of pinctl for such a shared hp/mic pin.
Reported-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the headphone mic jack enum control is created (via explicitly
specification by user), it doesn't make much sense to change the I/O
direction dynamically per capture source change, since the I/O
direction is rather controlled over the enum ctl.

This also reduces the implicit dependency between the capture source
and the hp mic jack enum ctls, which might confuse a program accessing
the whole control elements at once like alsactl.

In addition, this patch introduces update_hp_automute_hook() function
to call the proper hook function.  It's just to remove the open codes
in multiple places in hda_generic.c.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There is no big merit to distinguish these two hints.  Instead, just
have a single flag, add_jack_modes, for creating the jack mode enum
ctls for both I/O directions.

The hint string parser code is left and translated as add_jack_modes
just for keeping compatibility.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The previous commits added the capability to change the pin control of
hp/mic shared jack, but it actually didn't work as expected when the
value is changed from the output to the input, since I forgot to reset
the pin I/O bit in that case.  This patch fixes the problem.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In order to let user test the known workaround more easily, give a few
known fixups for ALC260 to the model strings so that it can be passed
via the module option.

Also, move the unusual setups found in FSC S7020 fixup into a special
model, fujitsu-jwse, Jonathan Woithe Special Edition.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a headphone jack is configured as a shared hp/mic jack, the jack
mode enum needs to handle both input and output directions.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch improves the generic parser code to allow to set up the
headphone jack as a mic input.  User can enable this feature by giving
hp_mic hint string.

The former shared hp/mic feature for the single built-in mic is still
retained.  This detection can be disabled now via hp_mic_detect hint
string, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit 57e5c630 "emu10k1: allow to
 disable the SRC" force hardware use only one rate (48000 hz).
EMU 0404/1010/1616 have support two hardware sampling rates (44100 and
48000 hz). This patch add check if we have EMU 0404/1010/1616 and
choose correct sample rate to restrict.
Signed-off-by: NMihail Zenkov <mihail.zenkov@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reported-by: NHarald Becker <ralda@gmx.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This expands the regression fix from
d2821599.
The firmware also needs to be loaded when it was already cached.
Signed-off-by: NFlorian Zeitz <florob@babelmonkeys.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch fixes initialization of the AK4114 chip so spdif capture is working properly.
Worked out together with Pavel Hofman.
Signed-off-by: NJonas Petersen <jnsptrsn1@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Along with a clean up commit [e9f66d9b: ALSA: pci: clean up using
module_pci_driver()], bt87x driver lost the functionality of load_all
parameter.  This patch does a partial revert of the commit only for
bt87x.c to recover it.
Reported-by: NClemens Ladisch <cladisch@googlemail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch fix regression in emu1010 firmware loading after
http://git.alsa-project.org/?p=alsa-kprivate.git;a=commitdiff;h=b209c4dfcd960ab176d4746ab7dc442a3edb4575

I just revert small part of this commit. Tested on emu1212m pci.
Signed-off-by: NMihail Zenkov <mihail.zenkov@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just as for analog codecs, a jack that isn't suitable for detection
(in this case, NO_PRESENCE was set) should be a phantom Jack
instead of a normal one.

Thanks to Raymond Yau for spotting.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/961286
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ELD validity can change during the lifetime of a presence detect,
so we need to be able to listen for changes on the ELD control.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Because the eld buffer can be simultaneously accessed from both
workqueue context (updating) and process context (kcontrol read),
we need to protect it with a mutex to guarantee consistency.

To avoid holding the mutex while reading the ELD info from the
codec, we introduce a temporary eld buffer.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For better readability, the information that is parsed out of the
ELD data is now put into a separate parsed_hdmi_eld struct.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Previously, it was possible to read the eld data of the previous
monitor connected. This should not be allowed.

Also refactor the function slightly.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, eld_valid is never set to false, except at kernel module
load time. This patch makes sure that eld is no longer valid when
the cable is (hot-)unplugged.

Cc: stable@kernel.org
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In the recent update, Fujitsu S7020 laptop with ALC260 codec lost the
speaker output, no matter how the amps and the pins are set.  After a
long debugging session, we found out that the default codec init code
is harmful for this machine, and we have to reset it to
ALC_INIT_NONE.
Reported-and-tested-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

These two machines have no mute LED string in BIOS.

BugLink: https://bugs.launchpad.net/bugs/1128934Tested-by: NTammy Yang <tammy.yang@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Define channel map for playback, capture devices of au88x0
Signed-off-by: NRaymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This chip needs the speaker pin to go to D3 to avoid clicks,
so default_power_filter does not work here.

This was found on Thinkpad R61i/T61i but I guess it applies to
the entire chip. If not, quirks should be set for at least
PCI SSID 17aa:20ac.

Thanks to c4pp4 for testing.

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

We've got a regression report wrt the IRQ issue related with the
power-save on a Dell machine, and disabling runtime PM works around.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53441

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

The current badness value used for the missing multi-io seems too
weak, and the multi-io tends to be skipped for desktop configurations
when no enough DACs are available.  It's because the total badness of
the multi-io becomes often larger than the badness with assigning an
individual DAC to a headphone jack.  This is good for one side, but it
seems that the surround outputs are more demanded by that.

This patch increases the badness value for the missing multi-io
slightly so that the multi-io would be preferred than the individual
headphone DAC if they conflict.  Through the tests with hda-emu,
mostly only desktop configurations with ALC662/663 and CMI codecs are
affected by this change, and all look reasonable.
Reported-by: NRaymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [dcda5806: ALSA: hda - Add workaround for conflicting
IEC958 controls] introduced a workaround for cards that have both
SPDIF and HDMI devices for giving device=1 to SPDIF control elements.
It turned out, however, that this workaround doesn't work well -

- The workaround checks only conflicts in a single codec, but SPDIF
  and HDMI are provided by multiple codecs in many cases, and

- ALSA mixer abstraction doesn't care about the device number in ctl
  elements, thus you'll get errors from amixer such as
  % amixer scontrols -c 0
  ALSA lib simple_none.c:1551:(simple_add1) helem (MIXER,'IEC958
  Playback Switch',0,1,0) appears twice or more
  amixer: Mixer hw:0 load error: Invalid argument

This patch fixes the previous broken workaround.  Instead of changing
the device number of SPDIF ctl elements, shift the element indices of
such controls up to 16.  Also, the conflict check is performed over
all codecs found on the bus.

HDMI devices will be put to dev=0,index=0 as before.  Only the
conflicting SPDIF device is moved to a different place.  The new place
of SPDIF device is supposed by the updated alsa-lib HDA-Intel.conf,
respectively.
Reported-by: NStephan Raue <stephan@openelec.tv>
Reported-by: NAnssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org> [v3.8]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The chip address is 32bit long but INVALID_CHIP_ADDRESS is defined as
an unsigned long.  This makes dsp_chip_to_dsp_addx() misbehaving on
64bit architectures.  Fix the INVALID_CHIP_ADDRESS definition to be
32bit.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The problem addressed by this fixup is not specific to Vaio Z, affecting
some Vaio all-in-one desktop PCs too. Update the code comments accordingly.
Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>