Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Put an upper bound on how long we will wait for the device to respond to
a read/write request (i.e., 100 milliseconds) and return an error if
this is reached.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The device indicates the result of a read/write operation by making the
status available on a subsequent request from the driver.  This is not
ready immediately, though, so the driver is currently slamming the
device with hundreds of pointless requests before getting the expected
response.  Add a two millisecond delay before each attempt.  This is
approximately the behavior observed with version 4.2.7.1 of the Windows
driver.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The BDW audio firmware DSP manages the DMA and the DMA cannot be
stopped exactly at the end of the playback stream. This means
stale samples may be played at PCM stop unless the driver copies
silence to the subsequent periods.
Signed-off-by: NLibin Yang <libin.yang@intel.com>
Reviewed-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

BugLink: https://bugs.launchpad.net/bugs/1412800Signed-off-by: NTienFu Chen <tienfu.chen@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In 'replace' event data, numerical ID of control is always invalid. This
commit fix this bug so as the event data has renewed numerical ID for
control.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The first URBs are submitted during the prepare stage. When .trigger is
called, the ALSA core saves a trigger tstamp that doesn't correspond to
the actual time when the samples are submitted. The trigger_tstamp is
now updated when the first data are submitted to avoid any time offsets.

A usb-specific trigger_tstamp_pending_update flag is used for now,
at some point the flag would need to move to the ALSA core, USB
is not the only interface where silent block transfers are programmed
as part of the prepare stage, with actual data enabled when .trigger
is called.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Make sure wallclock counter and trigger timestamp are read very
close to each other for better alignment.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Don't use generic snapshot of trigger_tstamp if low-level driver or
hardware can get a more precise value for better audio/system time
synchronization.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

timestamp in RUNNING mode is already taken in update_hw_ptr routine,
getting a new timestamp introduces offset between hw_ptr, audio_tstamp
and system time

Add else condition to read timestamp as fallback and only when
enabled
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The problem here is that we check:

	if (dev >= SNDRV_CARDS)

Then we increment "dev".

       if (!joystick_port[dev++])

Then we use it as an offset into a array with SNDRV_CARDS elements.

	if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {

This has 3 effects:
1) If you use the module option to specify the joystick port then it has
   to be shifted one space over.
2) The wrong error message will be printed on failure if you have over
   32 cards.
3) Static checkers will correctly complain that are off by one.

Fixes: db1005ec ('ALSA: riptide - Fix joystick resource handling')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge tag 'asoc-v3.20-3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

ASoC: Final updates for v3.20

A few more updates for v3.20 that have accumilated over the second half
of last week.  One new (relatively simple) driver for the Maxim
max98357a and some other driver specific fixes and enhancements.  I did
apply a few patches that haven't been in -next just now before sending
this, all fixes except for one simple device ID addition patch.

Merge remote-tracking branches 'asoc/topic/wm8804', 'asoc/topic/wm8904', 'asoc/topic/wm8960', 'asoc/topic/wm8988' and 'asoc/topic/xtfpga' into asoc-next

Merge remote-tracking branches 'asoc/topic/ts3a227e', 'asoc/topic/ts3a277e' and 'asoc/topic/txx9' into asoc-next

Merge remote-tracking branches 'asoc/topic/simple', 'asoc/topic/sta32x', 'asoc/topic/tdm-slot', 'asoc/topic/tegra' and 'asoc/topic/tlv320aic3x' into asoc-next

Merge remote-tracking branches 'asoc/topic/rt5670', 'asoc/topic/rt5677', 'asoc/topic/rx51', 'asoc/topic/samsung' and 'asoc/topic/sh' into asoc-next

Merge remote-tracking branches 'asoc/topic/pxa', 'asoc/topic/rcar' and 'asoc/topic/rt286' into asoc-next

Merge remote-tracking branches 'asoc/topic/fsl-spdif', 'asoc/topic/imx', 'asoc/topic/intel', 'asoc/topic/jz4740' and 'asoc/topic/max98357a' into asoc-next

Merge remote-tracking branches 'asoc/topic/doc', 'asoc/topic/dwc', 'asoc/topic/fsi', 'asoc/topic/fsl' and 'asoc/topic/fsl-asrc' into asoc-next

Merge remote-tracking branches 'asoc/topic/cs42l73', 'asoc/topic/dai' and 'asoc/topic/davinci' into asoc-next

Merge remote-tracking branches 'asoc/topic/bt-sco', 'asoc/topic/cs35l32', 'asoc/topic/cs42l52' and 'asoc/topic/cs42l56' into asoc-next

Merge remote-tracking branches 'asoc/topic/ad193x', 'asoc/topic/alc5632', 'asoc/topic/atmel' and 'asoc/topic/au1x' into asoc-next

Merge remote-tracking branches 'asoc/fix/ac97', 'asoc/fix/atmel', 'asoc/fix/intel', 'asoc/fix/rt286', 'asoc/fix/rt5640', 'asoc/fix/samsung', 'asoc/fix/sgtl5000', 'asoc/fix/sta32x', 'asoc/fix/tlv320aic3x' and 'asoc/fix/wm8731' into asoc-linus

ASoC: Updates for v3.20

Nothing too exciting here yet, a small optimization for DAPM from
Lars-Peter and a few small bits and pieces for drivers but nothing
that really stands out.

# gpg: Signature made Tue 30 Dec 2014 00:15:48 HKT using RSA key ID 5D5487D0
# gpg: Oops: keyid_from_fingerprint: no pubkey
# gpg: key AF88CD16: no public key for trusted key - skipped
# gpg: key AF88CD16 marked as ultimately trusted
# gpg: key 5621E907: no public key for trusted key - skipped
# gpg: key 5621E907 marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg:                 aka "Mark Brown <broonie@debian.org>"
# gpg:                 aka "Mark Brown <broonie@kernel.org>"
# gpg:                 aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg:                 aka "Mark Brown <broonie@linaro.org>"
# gpg:                 aka "Mark Brown <Mark.Brown@linaro.org>"

RT5670 doesn't support auto incrementing writes so driver should
set the use_single_rw flag for regmap.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

This patch adds support for rt288 codec.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@kernel.org>

sound/soc/intel/cht_bsw_rt5645.c:315:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Now when the CDCLK I2S output clock can be handled through the clock
API the Odroid X2/U3 can be switched to the simple-audio-card DT binding.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Clock related properties are added to the Exynos4 I2S device nodes
so they can be referred to as clock providers. Missing i2s_opclk1
clock is added to the I2S0 node and clock properties are added
to the MAX98090 codec node to allow it to control/read frequency
of the MCLK clock directly.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently when adding a new control, the assigned numerical ID is not
set for event data, thus userspace applications cannot realize it just
by event data.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Provide a unique name for each driver instead of using "line6usb" for
all of them.  This will allow for different configurations based on the
driver type.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It is unlikely this function would ever be used in a context without a
pointer to a `struct usb_line6_toneport', so grab the device type from
it rather than having the caller do it.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a predicate for testing if the device supports source selection to
make the conditional logic around this a bit cleaner.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>