As the recent firmware code tries to reread and cache the firmware by
itself, it's even better to keep the struct firmware data instead of
keeping a local copy.  Also, it makes little sense to disable the fw
loader for this driver, so added the explicit dependency, too.

Last, but not least, allocate the firmware data loaded via ioctl in
vmalloc'ed buffer instead, as the firmware size isn't that small.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Th buffer to save registers for PM is enough small for kmalloc(), not
necessary to use vmalloc().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new firmware code tries to re-read the formerly read firmware
files before suspend.  Thus it's wiser to keep the "patch" firmware in
the driver for avoiding this unnecessary re-reading.

Of course, this will consume a bit of memory for unused stuff, but
the patch fw is supposed to be fairly small, so it's more benefit in
the end.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Yet again like previous two commits, drop the old hwdep user-space
firmware code from vx driver (snd-vxpocket and snd-vx222).
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Like the previous commit for mixart, drop the home-baked fw loader
code.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It makes no longer sense to keep the old hwdep user-space firmware
loading, which has been deprecated since ages ago.

Just add a hard dependency on CONFIG_FW_LOADER and drop the useless
code.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since we keep the pin default config values anyway internally, we
don't have to set the values in the codec.  This patch removes the
code writing the pincfg values.

As a gratis bonus, we can remove also the code restoring the original
pincfg values at PM resume or module free.  This will give us more
benefit, as it can reduce the unnecessary power-up of codecs.

This won't change the driver functionality.  The only difference would
be that the codec proc file will show the original pincfg values
instead of the actually referred values.  The actually referred values
can be determined from sysfs *_pin_configs files.
(Also hda-emu was updated to follow this change.)
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The free callback is called at the state where no extra verbs are
executed, thus calling *_shutup() is useless, as it's checking the
shutdown flag.  Remove such superfluous calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

PCM hw_free and close should wait until all the pending stop
operations have been finished.  Basically only PCM trigger callback
should use non-wait calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As we are stopping the endpoints asynchronously now, it's better to
trigger the stop of both data and sync endpoints and wait for pending
stopping operations, instead of the sequential trigger-and-wait
procedure.

So the wait argument in snd_usb_endpoint_stop() is dropped, and it's
expected that the caller synchronizes explicitly by calling
snd_usb_endpoint_sync_pending_stop().  (Actually there is only one
place calling this, so it was safe to change.)
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For further code simplification, drop the conditional call for
usb_kill_urb() with can_wait argument in deactivate_urbs(), and use
only usb_unlink_urb() and wait_clear_urbs() pairs.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reduce the redundant arguments for snd_usb_endpoint_start() and
snd_usb_endpoint_stop().  Also replaced from int to bool.

No functional changes by this commit.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The async unlink behavior has been working over years.  The option was
provided only as a workaround for 2.4.x kernel.  Let's get rid of it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Also, silences the following smatch warning:
sound/usb/format.c:170 parse_audio_format_rates_v1() warn:
returning -1 instead of -ENOMEM is sloppy
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

'rt' was dereferenced before the NULL check.
Moved the code after the check.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Return the value obtained from snd_pcm_hw_constraint_minmax() instead
of -EINVAL. Silences the following smatch warning:
sound/core/pcm_native.c:2003 snd_pcm_hw_constraints_complete() info:
why not propagate 'err' from snd_pcm_hw_constraint_minmax() instead of -22?
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

kfree on a null pointer is a no-op.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge the recent HD-audio codec change for fixing recursive suspend
calls.

Conflicts:
	sound/pci/hda/hda_codec.c

We've got a report that the runtime PM may make the codec the
unresponsive on AMD platforms.  Since the feature has been tested only
on the recent Intel platforms, it's safer to limit the support to such
devices for now.

This patch adds a new DCAPS bit flag indicating the runtime PM
support, and mark it for Intel controllers.
Reported-and-tested-by: NJulian Wollrath <jwollrath@web.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Acer Aspire AO756 has an analog built-in mic on nid 0x1b and an
external mic on nid 0x19.  The BIOS doesn't set this up.

The mic detect on this Acer Aspire netbook and Acer C7 ChromeBook is
only valid when the headphone is plugged.  The detect circuit relies on
the tip detect switch being closed on the jack.  Tell hda_jack to ignore
the mic sense unless the headphones are plugged.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Introduce the concept of a "gated" jack.  The gated jack's pin sense
is
only valid when the "gating" jack is plugged.  This requires checking
the gating jack when the gated jack changes and re-checking the gated
jack when the gating jack is plugged/unplugged.

This allows handling of devices where the mic jack detect floats when
the headphone jack is unplugged.

[Rewritten for fixing the possible snd_array reallocation, covering
 the missing callback calls and jack sync operations, as well as some
 code cleanups -- tiwai]
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the bus reset is performed during the suspend/resume (including
the power-saving too), it calls snd_hda_suspend() and
snd_hda_resume() again, and deadlocks eventually.

For avoiding the recursive call, add a new flag indicating that the PM
is being performed, and don't go to the bus reset mode when it's on.
Reported-and-tested-by: NJulian Wollrath <jwollrath@web.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge a regression fix for USB MIDI on non-standard usb-audio drivers
by Clemens.

Commit 88a8516a (ALSA: usbaudio: implement USB autosuspend) added
autosuspend code to all files making up the snd-usb-audio driver.
However, midi.c is part of snd-usb-lib and is also used by other
drivers, not all of which support autosuspend.  Thus, calls to
usb_autopm_get_interface() could fail, and this unexpected error would
result in the MIDI output being completely unusable.

Make it work by ignoring the error that is expected with drivers that do
not support autosuspend.
Reported-by: NColin Fletcher <colin.m.fletcher@googlemail.com>
Reported-by: NDevin Venable <venable.devin@gmail.com>
Reported-by: NDr Nick Bailey <nicholas.bailey@glasgow.ac.uk>
Reported-by: NJannis Achstetter <jannis_achstetter@web.de>
Reported-by: NRui Nuno Capela <rncbc@rncbc.org>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: 2.6.39+ <stable@vger.kernel.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>

We set "s" before we have capped "speed" so it could be the wrong value.
This could lead to a divide by zero bug.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use bitmap_weight to count the total number of bits set in bitmap.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent change for USB-audio disconnection race fixes introduced a
mutex deadlock again.  There is a circular dependency between
chip->shutdown_rwsem and pcm->open_mutex, depicted like below, when a
device is opened during the disconnection operation:

A. snd_usb_audio_disconnect() ->
     card.c::register_mutex ->
       chip->shutdown_rwsem (write) ->
         snd_card_disconnect() ->
           pcm.c::register_mutex ->
             pcm->open_mutex

B. snd_pcm_open() ->
     pcm->open_mutex ->
       snd_usb_pcm_open() ->
         chip->shutdown_rwsem (read)

Since the chip->shutdown_rwsem protection in the case A is required
only for turning on the chip->shutdown flag and it doesn't have to be
taken for the whole operation, we can reduce its window in
snd_usb_audio_disconnect().
Reported-by: NJiri Slaby <jslaby@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There is a precedence bug because | has higher precedence than ?:.  This
code was cut and pasted and I fixed a similar bug a few days ago.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The dereference snd_pcm_plug_stream(plug) should come after the NULL
check snd_BUG_ON(!plug).
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The dereference snd_pcm_plug_stream(plug) should come after the NULL
check snd_BUG_ON(!plug).
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Probing this device currently fails in snd_usb_audio_probe() because
the call to snd_usb_create_mixer() fails.  This is due to unknown or
non-standard interface descriptor subtypes in parse_audio_unit():

  usbaudio: unit 51: unexpected type 0x09
  snd-usb-audio: probe of 1-8:1.0 failed with error -5

Some people are working around this by recompiling usb-audio with the
call to snd_usb_create_mixer() commented out.  It would be nice to
avoid that.

While the best idea would be to look into the mixer creation failure,
a reasonable short-term solution is to use quirks to only probe the
trouble-free interfaces.  This allows audio and MIDI interfaces to be
used without any obvious issues.

Interface 0 is the main one to ignore.  It contains lots of
control-fu, including the unexpected interface descriptor subtypes.
Interface 5 is for firmware updates and I'm not sure how to get
support for this.  Interface 3 is some sort of control interface that
I don't understand:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0
      iInterface              0
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength            9
        bInCollection           1
        baInterfaceNr( 0)       1
Signed-off-by: NMartin Schwenke <martin@meltin.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

I don't think this works as intended.  '|' higher precedence than ?: so
the bitwize OR "0 | (val & STR_MOST)" is a no-op.

I have re-written it to be more clear.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASoC: Fixes for v3.7

A few small fixes plus a large but simple change for WM5102 which writes
out a bunch of register updates to the device when we enable the clock
as recommended following chip evaluation.

Merge branches 'fix/arizona', 'fix/core', 'fix/cs42l52', 'fix/mxs', 'fix/samsung' and 'fix/wm8978' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into tmp

Add a MIDI driver for the Stanton FireWire DJ controllers.
Tested-by: NSean M. Pappalardo - D.J. Pegasus <spappalardo@mixxx.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>

Bah, forgot this again...
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Assume that unknown ICE1724-based cards are AC97-only that can suspend
without any additional card-specific code.

This fixes suspend on Gainward Hollywood@Home 7.1.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is another variant of iMac 9,1 with a different codec SSID.
Reported-and-tested-by: NEveraldo Canuto <everaldo.canuto@gmail.com>
Cc: <stable@vger.kernel.org> [v3.3+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>