Currently patch_alc269() calls the fixup with HDA_FIXUP_ACT_PRE_PROBE
before setting up the codec model-specific setups (e.g. setting
codec_variant or mixer_nid setup).  This is rather confusing as others
do call the *_PRE_PROBE fixup after such a setup.  Due to this
disorder, we have to override spec->shutup not at the usual
HDA_FIXUP_ACT_PRE_PROBE but the unusual HDA_FIXUP_ACT_PROBE time.

This patch corrects the fixup call orders in patch_alc269(), and also
corrects the action to set up spec->shutup accordingly.

No functional changes but just refactoring.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In this patch, the remaining static init verbs in VIA codec driver are
converted to the standard snd_hda_add_verbs() calls.  The conversion
is straightforward, but one change to be noted is the place of calls:
since these verbs are supposed to be executed at the beginning of the
init / resume procedure, we need to add snd_hda_add_verbs() calls
before calling the other parsers.

This is merely a cleanup, no functional changes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch replaces the control element creations in VIA codec driver
with the standard snd_hda_gen_add_kctl() calls as a cleanup.  There
are two major fields targeted by this patch: the beep controls and
static init controls.

The former is converted just like other codec drivers do.  The
spec->beep_amp field can be eliminated by this change as well.

The latter, static init controls, are replaced simply with explicit
snd_hda_gen_add_kctl() calls.

After these conversions, via_build_controls() becomes superfluous and
replaced with snd_hda_gen_build_controls(), too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently VIA codec driver invokes via_free() at each place of the
error path.  Move the error handling to the end of each function
commonly and do goto-error as a standard idiom.

This is a preliminary patch for the further cleanups, and no
functional changes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch moves the mixer creation code in Cirrus codec driver from
its own build_controls callback to snd_hda_gen_add_kctl() for
simplification.

As a bonus, this allows us to remove the cs421x_build_controls as it
becomes identical with snd_hda_gen_build_controls().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Like the previous commit for Realtek codec, the similar cleanup work
can be applied to Conexant codec, too.  A slight difference is that
the call of cx_auto_parse_beep() is moved after
snd_hda_gen_parse_auto_config().  It's not strictly needed, but it'd
be good to make the creation of such beep mixers at the end, which
matches with the former situation.

Along with this conversion, cx_auto_build_controls() becomes just
calling snd_hda_gen_build_controls(), so it's simply replaced with
snd_hda_gen_build_controls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In the Realtek codec driver, we used to build kctl elements for beep
mixer in the own build_controls callback.  This is an open-code and
can be covered by the standard feature of the generic parser with
snd_hda_gen_add_kctl() instead.

Also, after the conversion, spec->beep_amp becomes superfluous; hence
it's removed along with the conversion.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The beep mixer controls are the only remaining stuff that uses
spec->mixers[] array, and they can be well converted to the standard
helper in the generic parser, snd_hda_gen_add_kctl().

This simplifies the code, especially the superfluous mixers and
num_mixers fields can be now removed from alc_spec.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The ALC660VD_FIX_ASUS_GPIO1 quirk requires to set up GPIO bit0 ON
while bit 1 OFF.  Implement the fixup function and convert from the
static init verbs.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Dell XPS13 has multi-step fixups, and one of them
(ALC288_FIXUP_DELL_XPS_13_GPIO6) corresponds to the management of GPIO
bit6 (0x40).  It used to be a static init verbs (to turn *off* the
bit6).

In this patch, we convert it as the gpio_mask and gpio_dir
initializations folded in the existing fixup function.  With this
change, ALC288_FIXUP_DELL_XPS_13_GPIO6 becomes superfluous, thus it's
removed.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch converts the remaining static init verbs for GPIO bits with
the common gpio_* fields management.  Only the verbs setting the GPIO
data bits are targeted in this patch.  The rest will be changed in
later patches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now we can simplify the mute LED GPIO handling as well.  Each fixup
dealing with GPIO for the mute LED controls defined the static init
verbs, and they are converted to the common GPIO bit fields with the
new helper, alc_fixup_hp_gpio_led().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The fixup for Macbook Pro is nothing but setting the GPIO bits as
usual but with one exception: it adds some delay at writing the GPIO
bits.

Add a flag to put the conditional delay in the common helper, and
clean up alc885_fixup_macpro_gpio() with the new flag.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Until now, two fields, gpio_data and gpio_led, coexist in alc_spec
although basically both of them serve for the same purpose -- the GPIO
data bits.

This patch consolidates both usages and eliminates the superfluous
gpio_led field.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For updating GPIO bits dynamically, provide a new helper, and use it
from the alc260 automute hook.  This helper will be used by other
places in future, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently the GPIO bits are managed by individual verbs in some cases
while toggled dynamically in other cases.  For simplifying the GPIO
management, define the GPIO mask, dir and data bits in alc_spec
fields, and refer to / set them consistently from all places.

As a first step, along with the definition of the new gpio_* fields,
this patch replaces the static verbs that are used at initialization
and fixups with the common helper functions.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some devices have the overrides of spec->init_amp at
HDA_FIXUP_ACT_PROBE just because alc_ssid_check() gives the
false-positive values from the SSID.

For more consistent behavior, define the logic in the following way:

- Define ALC_INIT_UNDEFINED as the default value before calling
  alc_ssid_check()
- Each fixup may set up spec->init_amp with another value at
  HDA_FIXUP_ACT_PRE_PROBE
- At detection, check whether spec->init_amp is ALC_INIT_UNDEFINED or
  not; if it's different, we skip the detection

Also, it turned out that ASUS TX300 requires the spec->init_amp
override, too; currently it ignores the GPIO bits implicitly by its
static init verb, but this will be changed in the later patchset.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a devicetree binding for codecs. This is especially useful if the
AC97 bitclk clock is provided by the codec, as it has to be described in
the devicetree description for the ac97 bus code to aquire it.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the generic ac97 bus binding, especially for ac97 codecs discovered
by ac97 hardware probing.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

alc269_fixup_hp_line1_mic1_led() can be simplified more with the
existing helper code.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There are a couple of places setting cap_sync_hook in the codec
drivers, and they just overwrite the value.  Add a sanity check via
WARN_ON() in case if an old non-NULL value is overridden and
forgotten.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

To simplify the code and to get the mic-mute LED behavior control, use
the new helper function for controlling the mic mute LED instead of
open-codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of refusing, allow the configuration with the multiple ADCs
(thus multiple capture switches) for enabling the mic mute LED.
This has been done for Sigmatel/IDT codecs, and we treat the OR-ed
values from all capture switches as the boolean condition.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Convert to use the common helper for controlling the mic mute LED for
HP laptops, just as we've done for Realtek codecs.  This will give the
mic mute LED enum as gratis.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Similar as the previous commit, convert to use the common helper for
controlling the mic mute LED for HP and other machines in the Realtek
codec driver, too.  This will give the mic mute LED enum as gratis.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use the new common helper for setting up and controlling the mic mute
LED over thinkpad_acpi.  This also provides a new mixer enum "Mic
Mute-LED Mode" (that was present only for Dell models), which allows
user to choose the mic mute LED behavior.  For example, if you want
the mic mute LED turned on only while mic is on, choose "Follow
Capture" there.
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Move the code for setting up and controlling the mic mute LED hook
from dell-wmi helper to the generic parser, so that it can be referred
from the multiple driver codes.

No functional change.
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds support for MOTU Traveler, launched in 2005, discontinued
quite before. As a result, transmission of PCM frame and MIDI messages is
available via ALSA PCM and RawMIDI/Sequencer interfaces.

This model supports sampling transmission frequency up to 192.0 kHz, and
AES/EBU on XLR interface and ADAT on optical interface. Unlike
Motu 828MkII, Windows driver can switch fetching mode for DSP, like
mute/unmute feature.

Although this commit enables high sampling transmission frequency, actual
sound from this model is not good. As long as I tested, it's silence at
176.4 kHz, and it includes hissing noise at 192.0 kHz. In my opinion, as I
reported at 3526ce7f9ba7 ('ALSA: firewire-motu: add MOTU specific protocol
layer'), timestamping on source packet header (SPH) may not still be good
for this model as well.

$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  04106505  bus_info_length 4, crc_length 16, crc 25861
404  31333934  bus_name "1394"
408  20001000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4)
40c  0001f200  company_id 0001f2     |
410  0001f32f  device_id 000001f32f  | EUI-64 0001f2000001f32f

               root directory
               -----------------------------------------------------------------
414  0004c65c  directory_length 4, crc 50780
418  030001f2  vendor
41c  0c0083c0  node capabilities per IEEE 1394
420  8d000006  --> eui-64 leaf at 438
424  d1000001  --> unit directory at 428

               unit directory at 428
               -----------------------------------------------------------------
428  00035955  directory_length 3, crc 22869
42c  120001f2  specifier id
430  13000009  version
434  17107800  model

               eui-64 leaf at 438
               -----------------------------------------------------------------
438  000206b2  leaf_length 2, crc 1714
43c  0001f200  company_id 0001f2     |
440  0001f32f  device_id 000001f32f  | EUI-64 0001f2000001f32f
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For MOTU protocol version 2, this driver arranges the number of data
chunks to align chunks to quadlet data channel. However, MOTU Traveler
has padding bytes in the end of data block at high clock mode.

This commit removes the arrangement. Fortunately, at low and middle clock
mode, supported model for v2 protocol (828mkII) gets no influence from this
change because all of combination for data chunks are just aligned to
quadlet data channel.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

MOTU Traveler supports AES/EBU on XLR interface and data block of rx/tx
packet includes two chunk for the interface. This commit adds a flag
for this purpose.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This driver explicitly assumes that all of supported models have main data
chunk separated from chunk for analog ports. However, MOTU Traveler doesn't
support the separated main data chunk.

This commit adds a flag for the separated main data chunk.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In MOTU firewire protocol, data block consists of 24 bit data chunks except
for one quadlet for source packet header (SPH). The number of data chunk in
a data block is different between three clock modes; low, middle and high.
When unit supports ADAT on optical interface, the data block includes some
chunks for ADAT channels. These ADAT chunks are unavailable at high mode.

This driver has local functions to calculate the number of ADAT chunks. But
They uses stack for three clock modes. This is useless for higher mode.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The get_seconds() function is deprecated because it truncates the
timestamp to 32 bits, so all users should change to ktime_get_seconds()
or ktime_get_real_seconds().

The firmware interface for passing the timestamp is also limited to
32 bits, so this patch only has the cosmetic effect of avoiding the
old interface.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently a variable of type enum CT_AMIXER_CTL is used for enum
CT_SUM_CTL values. This leads to warnings when using clang:
sound/pci/ctxfi/ctmixer.c:945:32: warning: implicit conversion from enumeration type
      'enum CT_SUM_CTL' to different enumeration type 'enum CT_AMIXER_CTL'
      [-Wenum-conversion]
        for (i = AMIXER_MASTER_F, j = SUM_IN_F;
                                    ~ ^~~~~~~~
sound/pci/ctxfi/ctmixer.c:975:29: warning: implicit conversion from enumeration type
      'enum CT_SUM_CTL' to different enumeration type 'enum CT_AMIXER_CTL'
      [-Wenum-conversion]
        for (i = AMIXER_PCM_F, j = SUM_IN_F; i <= AMIXER_PCM_S; i++, j++) {
                                 ~ ^~~~~~~~

Introduce enum CT_SUM_CTL k and it instead.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This fixes a warning seen with clang:

sound/pci/ice1712/prodigy_hifi.c:321:28: warning: variable 'wm_vol' is not
      needed and will not be emitted [-Wunneeded-internal-declaration]
static const unsigned char wm_vol[256] = {
                           ^
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commentary says to use various parameters, and lays out what
the mapping is...  The code used a 32KHz rate when the comment
says that it needs to use a 48KHz rate.  And this has been the
case since day one.

On the Alienware M17x R4, the DMic used to have exceptionally quiet
pickup and a lot of noise.  Changing the data rate fixes both of
these issues.

Searching the kernel bug tracker for ca0132-related issues shows no
mention of this being an issue for other hardware, and I have no
other hardware to test with, so a quirk is used to limit the effect
to just the M17x R4.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit 009b8f97 conditionalized
adding the "CA0132 Analog Mic-In2" PCM with a comment to the
effect that, "desktops don't use this ADC", but the test was set
up such that the ADC was only created for desktops.  Invert the
test.

Fixes: 009b8f97 ("ALSA: hda/ca0132: update core functions for sbz + r3di")
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

QUIRK_NONE is, quite explicitly, the default case.  The entire
point of a quirks system is to allow "programming by difference"
from a given base case, which requires that merely defining a new
quirk for some piece of hardware should not change the behavior of
the driver for that hardware.  In turn, this means that testing
for QUIRK_NONE explicitly is a violation of that implicit contract.

Change a test for QUIRK_NONE and QUIRK_ALIENWARE to default, and
add a test for QUIRK_SBZ to disable the default behavior in that
instance.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit e93ac30a (ALSA: HDA/ca0132:
add extra init functions for r3di + sbz) introduced an extra
initialization function that was improperly guarded, taking effect
on systems with QUIRK_ALIENWARE, even though such systems were
supposedly not affected.

It may be that this piece of initialization should be done for all
systems, but that's not a call that I can make.

Fixes: e93ac30a ("ALSA: HDA/ca0132: add extra init functions for r3di + sbz")
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>