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: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi 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: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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

This is a preliminary patch for introducing a protection to access
races of snd_array instances.  Call snd_array_init() appropriately
at the initialization time and don't call it twice.

Also the allocations of codec-spec structs are cleaned up by helper
functions in patch_sigmatel.c and patch_analog.c.
Signed-off-by: Takashi 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: Takashi Iwai <tiwai@suse.de>

USB audio class 2 has more channel map positions than we currently
have.  Let's add missing definitions.
Signed-off-by: Takashi 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: Takashi 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: Takashi Iwai <tiwai@suse.de>

The internal mic on MBP81 gives only the right channel, and the left
channel is static.  Add a verb to fix the ADC2 channel mode to expand
mono right to stereo.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50781Signed-off-by: Takashi Iwai <tiwai@suse.de>

We forgot to apply the fixup verbs in cs_init().

But adding the fixup verbs will break mbp101 fixup that has been fixed
recently again, since the mbp101 fixup contains the wrong verbs to
override.  So these bogus verbs must be removed, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

It's constant, so better to be put in the static init array.
Signed-off-by: Takashi 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: Jeffrey Barish <jeff_barish@earthlink.net>
Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: stable@kernel.org [3.5+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

It's defined only for PM.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a flag to suppress the update in emu1010_firmware_thread() during
suspend/resume.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Instead of calling request_firmware() at each time, keep the obtained
firmware internally and reuse it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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: Takashi Iwai <tiwai@suse.de>

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

Like the previous commit for mixart, drop the home-baked fw loader
code.
Signed-off-by: Takashi 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: Takashi 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: Takashi 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: Takashi Iwai <tiwai@suse.de>

Signed-off-by: Takashi 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: Takashi 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: Takashi 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: Takashi 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: Takashi 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: Takashi 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: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

'rt' was dereferenced before the NULL check.
Moved the code after the check.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Takashi 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: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

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

If this array is not cleared, the jack related code later might
fail to create "Internal Speaker Phantom Jack" on Dell Inspiron 3420 and
Dell Vostro 2420.

BugLink: https://bugs.launchpad.net/bugs/1076840
Cc: stable@vger.kernel.org (3.6+)
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

We found a new codec ID 292, and that just a simple quirk would enable
sound output/input on this ALC292 chip.

BugLink: https://bugs.launchpad.net/bugs/1081466
Cc: stable@vger.kernel.org
Tested-by: Acelan Kao <acelan.kao@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: Fixes for v3.7

The biggest batch of fixes here is the Kirkwood DMA fixes, plus a couple
of other small fixes.

Merge branches 'fix/arizona', 'fix/cs4271', 'fix/kirkwood' and 'fix/samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into tmp

Don't even momentarily set the pause status when starting the channel;
if we do, we should check the busy bit to ensure that we comply with
the spec.  In any case, it isn't necessary; we will not active on a
START event so there is no need to pause the DMA.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>