The "break;" should be indented.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The beep input device is registered via input_register_device(), but
this is called in snd_hda_attach_beep_device() where the sound devices
aren't registered yet.  This leads to the binding to non-existing
object, thus results in failure.  And, even if the binding worked
(against the PCI object), it's still racy; the input device appears
before the sound objects.

For fixing this, register the input device properly at dev_register
ops of the codec object it's bound with.  Also, call
snd_hda_detach_beep_device() at dev_disconnection so that it's
detached at the right timing.  As a bonus, since it's called in the
codec's ops, we can get rid of the further call from the other codec
drivers.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use dev_err() and co for messages from HD-audio controller and codec
drivers.  The codec drivers are mostly bound with codec objects, so
some helper macros, codec_err(), codec_info(), etc, are provided.
They merely wrap the corresponding dev_xxx().

There are a few places still calling snd_printk() and its variants
as they are called without the codec or device context.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The last user of snd_hda_gen_spec_free() is patch_via.c, and we can
rewrite it safely with snd_hda_gen_free(), so that
snd_hda_gen_spec_free() can be a local function in hda_generic.c.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now Realtek and Conexant codec parsers just call snd_hda_gen_free().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current code for controlling mic mute LED in patch_sigmatel.c
blindly assumes that there is a single capture switch.  But, there can
be multiple multiple ones, and each of them flips the state, ended up
in an inconsistent state.

For fixing this problem, this patch adds kcontrol to be passed to the
hook function so that the callee can check which switch is being
accessed.  In stac_capture_led_hook(), the state is checked as a
bitmask, and turns on the LED when all capture switches are off.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... by using snd_Hda_codec_update_cache() instead of *_write_cache().
Since all path elements should have been updated by this function,
we are safe to assume that the cache contents are consistent.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Apply the codec->power_filter to the FG nodes in general for reducing
hackish set_power_state ops override in patch_sigmatel.c.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AD1986A mic pins (0x1d and 0x1f) share the same widget for controlling
the loopback volume/mute, but the generic parser didn't check it.
This ended up with the duplicated controls for the same effect.

This patch adds the check of the duplication for avoiding it.

After this fix, there will be only one control although it affects
both paths; this remaining issue should be fixed later in a different
patch.

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

Replace all with the standard EXPORT_SYMBOL_GPL().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

AD1986A codec is a pretty old codec and has really many hidden
restrictions.  One of such is that each DAC is dedicated to certain
pin although there are possible connections.  Currently, the generic
parser tries to assign individual DACs as much as possible, and this
lead to two bad situations: connections where the sound actually
doesn't work, and connections conflicting other channels.

We may fix this by trying to find the best connections more harder,
but as of now, it's easier to give some hints for paired DAC/pin
connections and honor them if available, since such a hint is needed
only for specific codecs (right now only AD1986A, and there will be
unlikely any others in future).

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

Not all channels have been initialized, so far, especially when aamix
NID itself doesn't have amps but its leaves have.  This patch fixes
these holes.  Otherwise you might get unexpected loopback inputs,
e.g. from surround channels.

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

AD and VIA codecs had stereo mixer input enabled as default before
moving to the generic parser, and people think the lack of such a
regression.  In this patch, the stereo mixer input is added back to
the input selection if no auto-mic is available, and if it's not
disabled explicitly via hint.  This should satisfy most of demands,
i.e. stereo mix on desktop machines like what it worked before, and it
still keeps the new auto-mic feature on laptops.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The loopback mixing paths aren't initialized correctly at init
callback.  Mostly this is harmless as codecs usually set the mute
state as default, but we still should make sure.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have blindly assumed that all valid configurations should have
either analog or digital playback, but there can be capture-only
configurations.  The parser shouldn't escape in such a case.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current generic parser assumes blindly that the volume and mute
amps are found in the aamix node itself.  But on some codecs,
typically Analog Devices ones, the aamix amps are separately
implemented in each leaf node of the aamix node, and the current
driver can't establish the correct amp controls.  This is a regression
compared with the previous static quirks.

This patch extends the search for the amps to the leaf nodes for
allowing the aamix controls again on such codecs.
In this implementation, I didn't code to loop through the whole paths,
since usually one depth should suffice, and we can't search too
deeply, as it may result in the conflicting control assignments.

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

When the hp mic pin has no VREF bits, the driver forgot to set PIN_IN
bit.  Spotted during debugging old MacBook Airs.

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

When a headphone jack is configurable as input, the generic parser
tries to make it retaskable as Headphone Mic.  The switching can be
done smoothly if Capture Source control exists (i.e. there is another
input source).  Or when user explicitly enables the creation of jack
mode controls, "Headhpone Mic Jack Mode" will be created accordingly.

However, if the headphone mic is the only input source, we have to
create "Headphone Mic Jack Mode" control because there is no capture
source selection.  Otherwise, the generic parser assumes that the
input is constantly enabled, thus the headphone is permanently set
as input.  This situation happens on the old MacBook Airs where no
input is supported properly, for example.

This patch fixes the problem: now "Headphone Mic Jack Mode" is created
when such an input selection isn't possible.

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

Drop the hard dependency on the generic parser code and load / unload
the generic parser code dynamically if built as a module.  This allows
us to avoid the generic parser if only HDMI/DP codecs are found.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We don't change the EAPD bit in set_pin_eapd() if keep_eapd_on flag is
set by the codec driver and enable is false.  But, we also apply the
flipping of enable value according to inv_eapd flag in the same
function, and this confused the former check, handled as if it's
turned ON.  The inverted EAPD check must be applied after keep_eapd_on
check, instead.

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

Add a bitmask to hda_gen_spec indicating NIDs to exclude from the
possible volume controls.  That is, when the bit is set, the NID
corresponding to the bit won't be picked as an output volume control
any longer.

Basically this is just a band-aid for working around the issue found
with CS4208 codec, where only the headphone pin has a volume AMP with
different dB steps.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60811
Cc: <stable@vger.kernel.org> [v3.12+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The generic parser has a support of vmaster hook, but this is
initialized only in the init callback with the check of the presence
of the corresponding kctl.  However, since kctl is NULL at the very
first init callback that is called before build_controls callback, the
vmaster hook sync is skipped there.  Eventually this leads to the
uninitialized state depending on the hook implementation.

This patch adds a simple workaround, just calling the sync function
explicitly at build_controls callback.

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

The create_bind_cap_vol_ctl does not create any control indicating
that an inverted dmic is present. Therefore, create multiple
capture volumes in this scenario, so we always have some indication
that the internal mic is inverted.

This happens on the Lenovo Ideapad U310 as well as the Lenovo Yoga 13
(both are based on the CX20590 codec), but the fix is generic and
could be needed for other codecs/machines too.

Thanks to Szymon Acedański for the pointer and a draft patch.

BugLink: https://bugs.launchpad.net/bugs/1239392
BugLink: https://bugs.launchpad.net/bugs/1227491Reported-by: NSzymon Acedański <accek@mimuw.edu.pl>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current generic parser code assumes that always a pin widget
controls the mute for an output blindly although it might be a
different widget in the middle.  Instead of the fixed assumption,
check each parsed path and just pick up the right widget that has been
already defined as a mute control.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The auto-mute using the amp currently works only for a single amp on a
pin.  Make it working also with HDA_CTL_BIND_MUTE type, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've added a fake mute control (setting the amp volume to zero) for
CX5051 at commit [3868137e: ALSA: hda - Add a fake mute feature], but
this feature was overlooked in the generic parser implementation.  Now
the driver lacks of mute controls on these codecs.

The fix is just to check both AC_AMPCAP_MUTE and AC_AMPCAP_MIN_MUTE
bits in each place checking the amp capabilities.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59001
Cc: <stable@vger.kernel.org> [v3.9+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

VAIO-Z laptops need to use the specific DAC for the speaker output
by some unknown reason although the codec itself supports the flexible
connection.  So we implemented a workaround by a new flag,
no_primary_hp, for assigning the speaker pin first.

This worked until 3.8 kernel, but it got broken because the driver
learned for a better multi-io pin mapping, and not it can assign two
mic pins for multi-io.  Since the multi-io requires to be the primary
output, the hp and two mic pins are assigned in prior to the speaker
in the end.

Although the machine has two mic pins, one of them is used as a noise-
canceling headphone, thus it's no real retaskable mic jack.  Thus, at
best, we can disable the multi-io assignment and make the parser
behavior back to the state before the multi-io.

This patch adds again a new flag, no_multi_io, to indicate that the
device has no multi-io capability, and set it in the fixup for
VAIO-Z.  The no_multi_io flag itself can be used generically, added
via a helper line, too.
Reported-by: NTormen <my.nl.abos@gmail.com>
Reported-by: NAdam Williamson <awilliam@redhat.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hda_jack_detect() function returns a boolean value for a jack
plugged in or not, but it also returns always true when the
corresponding pin is phantom (i.e. fixed).  This is OK in most cases,
but it makes the generic parser misbehaving about the auto-mute or
auto-mic switching, e.g. when one of headphone pins is a fixed.
Namely, the driver decides whether to mute the speaker or not, just
depending on the headphone plug state: if one of the headphone jacks
is seen as active, then the speaker is muted.  Thus this will result
always in the muted speaker output.

So, the problem is the function returns a boolean, after all, although
we need to think of "phantom" jack.  Now a new function,
snd_hda_jack_detect_state() is introduced to return these tristates.
The generic parser uses this function for checking the headphone or
mic jack states.

Meanwhile, the behavior of snd_hda_jack_detect() is kept as is, for
keeping compatibility in other driver codes.
Acked-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The char arrays with size 44 are for the name string of
snd_ctl_elem_id.  Define the constant and replace the raw numbers with
it for clarifying better.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

add_control_with_pfx() in hda_generic.c assumes a shorter name string
for the control element, and this resulted in the truncation of the
long but valid string like "Headphone Surround Switch" in the middle.

This patch aligns the max size to the actual limit of snd_ctl_elem_id,
44.

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

Add a new flag, auto_mute_via_amp, to determine the behavior of the
headphone / line-out auto-mute.  When this flag is set, the generic
driver mutes the speaker and line outputs via the amp mute of each
pin, instead of changing the pin control values.

This is introduced for devices that don't work expectedly with the pin
control values; for example, some devices are known to keep enabling
the speaker outputs no matter which pin control values are set on the
speaker pins.

The driver doesn't check actually whether the pins have the output amp
caps, but assumes that the proper mixer (mute) controls are created on
all these pins.  If not the case, you can't use this flag for your
device.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The previous commit was written in the way to make the backport to
3.9.y easier, and left the duplicated open codes intentionally.
Now let's clean up the duplicated codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

VT1802 codec seems to reset EAPD of other pins in the hardware level,
and this was another reason of the silent headphone output on some
machines.  As a workaround, introduce a new flag indicating to keep
the EPAD on to the generic parser, and set it in patch_via.c.
Reported-by: NAlex Riesen <raa.lkml@gmail.com>
Cc: <stable@vger.kernel.org> [v3.9]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some codec drivers (VIA codecs and some Realtek fixups) set the
automute and automic hooks after calling
snd_hda_gen_parse_auto_config().  In the current code, the hook
pointers are referred only in snd_hda_gen_parse_auto_config() and
passed to snd_hda_jack_detect_enable_callback(), thus changing the
hook values won't change the actually called callbacks properly.

This patch fixes this bug by setting the static functions as the
primary callback functions for the jack detection, and let them
calling the appropriate hooks dynamically.

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

When an inactive path is powered down with spec->power_down_unused
flag, we should check the activity of each widget in the path whether
it's still referred from any active path.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When setting up the aamix output paths, use the primary DAC instead of
the individual DAC for each output as default.  Otherwise multiple
DACs will be turned on for a single aamix widget, which results in
doubly or more volumes, because the duplicated signals will be sent
through all these DACs for a single stream.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When we have a loopback mixer control, this should manage the state
whether the output paths include the aamix or not.  But the current
code blindly initializes the output paths with aamix = true, thus the
aamix is enabled unless the loopback mixer control is changed.

Also, update_aamix_paths() called by the loopback mixer control put
callback invokes snd_hda_activate_path() with aamix = true even for
disabling the mixing.  This leaves the aamix path even though the
loopback control is turned off.

This patch fixes these issues:
- Introduced aamix_default() helper to indicate whether with_aamix is
  true or false as default
- Fix the argument in update_aamix_paths() for disabling loopback
Reported-by: NLydia Wang <LydiaWang@viatech.com.cn>
Cc: <stable@vger.kernel.org> [v3.9+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now that we have a flag for headphone mics, we can use that flag
in the jack creation instead of creating the jack manually.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This allows a specific mic to get the "Headphone Mic" name, in addition
to the existing "Headset Mic" name.

Also, it allows for a special mark: if the sequence number is set
to 0xc, that's an indication to prefer it for headset mic, and if it's
set to 0xd, that's an indication to prefer it for headphone mic.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

changed is not initialized in path_power_down_sync, but it is expected
to be false in case no change happened in the loop. So set it to
false.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>