Adds a quirks table for the M-Audio Fast Track C400.
Thanks to Clemens Ladisch <clemens@ladisch.de> for pointing out that
the table must be sorted.

Based on the following patch from the alsa-devel list:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051676.html

See also:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-April/051219.htmlSigned-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Adds the unit ID and the control as parameters to the creation of the
effect unit control for the M-Audio Fast Track Ultra. This allows the
code to be shared with other devices that use different unit ID and
control, such as the M-Audio Fast Track C400.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Current code mishandles the case where the device is a UAC2
and the bDescriptorSubtype is a UAC2 Effect Unit (0x07).
It tries to parse it as a Processing Unit (which is similar to two
other UAC1 units with overlapping subtypes), but since the structure
is different (See: 4.7.2.10, 4.7.2.11 in UAC2 standard), the parsing
is done incorrectly and prevents the device from initializing.
For now, just ignore the unit.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, channel IDs exceeding 31 (0x1f) cannot be used.
The channel ID is derived from the cmask. Extending cmask
to a 64-bit type would only allow it to go up to 63 (0x3f).
Some devices have channel IDs exceeding that as well.
To address that, add an offset to the mixer element which
is then accounted for in the UAC set/get functions.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For implicit feedback endpoints, the number of bytes for each packet
is matched by the corresponding synchronizing endpoint.
The size is calculated by taking the actual size and dividing it by
the stride - currently by the endpoint's stride, but we should use the
synchronization source's stride.
This is evident when the number of channels differ between the
synchronization source and the implicitly fed-back endpoint, as with
M-Audio Fast Track C400 - the synchronization source (capture)
has 4 channels, while the implicit feedback mode endpoint has 6.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In this context, 0x01 is USB_ENDPOINT_XFER_ISOC.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the support for channel maps of the PCM streams on USB audio
devices.  The channel map information is already found in
ChannelConfig descriptor entries, which haven't been referred until
now.

Each chmap entry is added to audioformat list entry and copied to TLV
dynamically instead of creating a whole chmap array.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a playback stream is paused, the stream isn't actually stopped,
thus we still need to take care of the in-flight data amount for the
delay calculation.  Otherwise the value of subs->last_delay is no
longer reliable and can give a bogus value after resuming from pause.
This will result in "delay: estimated XX, actual YY" error messages.

Also, during pause after all in flight data are processed
(i.e. last_delay = 0), we don't have to calculate the actual delay
from the current frame.  Give a short path in such a case.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It doesn't make sense to calculate the delay for capture streams in
the current implementation.  It's always zero, so we should skip the
computation in snd_usb_pcm_pointer() in the case of capture.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Jeffrey Barish reported an obvious bug in the pcm part of the usb-audio
driver which causes the code to not initialize the sync endpoint from
configure_endpoint().
Reported-by: NJeffrey Barish <jeff_barish@earthlink.net>
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Cc: stable@kernel.org [3.5+]
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>

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>

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>

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>

There are bug reports of a crash with USB-audio devices when PCM
prepare is performed immediately after the stream is stopped via
trigger callback.  It turned out that the problem is that we don't
wait until all URBs are killed.

This patch adds a new function to synchronize the pending stop
operation on an endpoint, and calls in the prepare callback for
avoiding the crash above.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=49181Reported-and-tested-by: NArtem S. Tashkinov <t.artem@lycos.com>
Cc: <stable@vger.kernel.org> [v3.6]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Similar like the previous commit, cover with chip->shutdown_rwsem
and chip->shutdown checks.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Replace mutex with rwsem for codec->shutdown protection so that
concurrent accesses are allowed.

Also add the protection to snd_usb_autosuspend() and
snd_usb_autoresume(), too.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Close some races at disconnection of a USB audio device by adding the
chip->shutdown_mutex and chip->shutdown check at appropriate places.

The spots to put bandaids are:
- PCM prepare, hw_params and hw_free
- where the usb device is accessed for communication or get speed, in
 mixer.c and others; the device speed is now cached in subs->speed
 instead of accessing to chip->dev

The accesses in PCM open and close don't need the mutex protection
because these are already handled in the core PCM disconnection code.

The autosuspend/autoresume codes are still uncovered by this patch
because of possible mutex deadlocks.  They'll be covered by the
upcoming change to rwsem.

Also the mixer codes are untouched, too.  These will be fixed in
another patch, too.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Reloop Audio needs a fixed endpoint quirk with S24_3LE format and
UAC_EP_CS_ATTR_SAMPLE_RATE attribute.
Signed-off-by: NDidier Villevalois <ptitjes@free.fr>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Without this quirk the VG-99 will work in standard mode (set under
USB on System menu page 2) giving 16 bits at 44.1 Khz audio in/out
but no midi, and is not recognised when set to advanced mode.

After applying this, I can also use the VG-99 in advanced mode: 24
24 bits audio in/out at 44.1 Khz, and midi in/out. Sysex is so far
untested.

In standard mode, the device appears with ID 0x00b3, so the
behaviour isn't affected by this quirk.

Thanks to Clemens Ladisch for simplifying and correcting my initial
attempt!
Signed-off-by: NPete Leigh <pete.leigh@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The variable ep is initialized but never used
otherwise, so remove the unused variable.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
currently it lost original meaning but still has some effects:

 | effect                 | alternative flags
-+------------------------+---------------------------------------------
1| account as reserved_vm | VM_IO
2| skip in core dump      | VM_IO, VM_DONTDUMP
3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP

This patch removes reserved_vm counter from mm_struct.  Seems like nobody
cares about it, it does not exported into userspace directly, it only
reduces total_vm showed in proc.

Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.

remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.

[akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Venkatesh Pallipadi <venki@google.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Added quirk to provide at least playback-only support.
Signed-off-by: NOto Petrik <oto.petrik@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Also fix the calls to next_packet_size() for the pause case. This was
missed in 245baf98 ("ALSA: snd-usb: fix calls to next_packet_size").
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reported-and-tested-by: NChristian Tefzer <ctrefzer@gmx.de>
Cc: stable@kernel.org
[ Taking directly because Takashi is on vacation  - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While going through Ubuntu bugs, I discovered this patch being
posted and a confirmation that the patch works as expected.

Finding out how the hw volume really works would be preferrable
to just disabling the broken one, but this would be better than
nothing.

Credit: sndfnsdfin (qawsnews)
BugLink: https://bugs.launchpad.net/bugs/559939Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent fix for USB suspend breakage moved the code to set up EP
from hw_params to prepare, but it means also the EP setup might be
called multiple times unnecessarily because the prepare callback can
be called multiple times without starting the stream (e.g. OSS
emulation).

This patch adds a new flag to struct snd_usb_substream indicating
whether the setup of EP is required, and do it only when necessary,
i.e. right after hw_params or suspend.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Move interface and endpoint configuration from hw_params to prepare
callback.  During system suspend/resume when the USB device power isn't
cycled the interface and endpoint configuration need to be set before
audio playback can continue.  Resume involves another call to prepare
but not to hw_params, moving it here allows a playing stream to continue
after resume.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Change the interface to configure an endpoint so that it doesn't require
a hw_params struct.  This will allow it to be called from prepare
instead of hw_params, configuring it after system resume.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Set the peiod_bytes member of snd_usb_substream.  It was no longer being
set, but will be needed to resume properly in a future commit.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent fix for the missing fine delayed time adjustment gives
strange error messages at each start of the playback stream, such as
  delay: estimated 0, actual 352
  delay: estimated 353, actual 705

These come from the sanity check in retire_playback_urb().  Before the
stream is activated via start_endpoints(), a few silent packets have
been already sent.  And at this point the delay account is still in
the state as if the new packets are just queued, so the driver gets
confused and spews the bogus error messages.

For fixing the issue, we just need to check whether the received
packet is valid, whether it's zero sized or not.
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Cc: <stable@vger.kernel.org> [v3.5+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Playback Designs' USB devices have some hardware limitations on their
USB interface. In particular:

 - They need a 20ms delay after each class compliant request as the
   hardware ACKs the USB packets before the device is actually ready
   for the next command. Sending data immediately will result in buffer
   overflows in the hardware.
 - The devices send bogus feedback data at the start of each stream
   which confuse the feedback format auto-detection.

This patch introduces a new quirks hook that is called after each
control packet and which adds a delay for all devices that match
Playback Designs' USB VID for now.

In addition, it adds a counter to snd_usb_endpoint to drop received
packets on the floor. Another new quirks function that is called once
an endpoint is started initializes that counter for these devices on
their sync endpoint.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Reported-and-tested-by: NAndreas Koch <andreas@akdesigninc.com>
Supported-by: NDemian Martin <demianm_1@yahoo.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Added support for Xbox Communicator to USB quirks.
Signed-off-by: NMarko Friedemann <mfr@bmx-chemnitz.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>