The only two users of the suspend_bias_level field were two rather old
drivers which weren't exactly doing things by the book. Those drivers have
been updated and field is now unused and can be removed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.

Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.

The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When being powered on, either initially on probe or when resuming from
suspend, the wm8971 configures the device for quick output capacitor
charging. Since the charging can take a rather long time (up to multiple
seconds) it is done asynchronously without blocking. A delayed work item is
run once the charging is finished and the device is switched to the target
bias level.

This all done asynchronously to the regular DAPM sequence accessing the same
data structures and registers without any looking, which can lead to race
conditions. Furthermore this potentially delays the start of stream on the
CODEC while the rest of the system is already up and running, meaning the
first bytes of audio are lost. It also does no comply with the assumption of
the DAPM core that if set_bias_level() returned successfully the device will
be at the requested bias level.

This patch slightly refactors things and makes sure that the caps charging
is properly integrated into the DAPM sequence. When transitioning from
SND_SOC_BIAS_OFF to SND_SOC_BIAS_STANDBY the part will be put into fast
charging mode and a work item will be scheduled that puts it back into
standby charging once the charging period has elapsed. If a playback or
capture stream is started while charging is in progress the driver will now
wait in SND_SOC_BIAS_PREPARE until the charging is done. This makes sure
that charging is done asynchronously in the background when the chip is
idle, but at the same time makes sure that playback/capture is not started
before the charging is done.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.

Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.

The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When being powered on, either initially on probe or when resuming from
suspend, the wm8971 configures the device for quick output capacitor
charging. Since the charging can take a rather long time (up to multiple
seconds) it is done asynchronously without blocking. A delayed work item is
run once the charging is finished and the device is switched to the target
bias level.

This all done asynchronously to the regular DAPM sequence accessing the same
data structures and registers without any looking, which can lead to race
conditions. Furthermore this potentially delays the start of stream on the
CODEC while the rest of the system is already up and running, meaning the
first bytes of audio are lost. It also does no comply with the assumption of
the DAPM core that if set_bias_level() returned successfully the device will
be at the requested bias level.

This patch slightly refactors things and makes sure that the caps charging
is properly integrated into the DAPM sequence. When transitioning from
SND_SOC_BIAS_OFF to SND_SOC_BIAS_STANDBY the part will be put into fast
charging mode and a work item will be scheduled that puts it back into
standby charging once the charging period has elapsed. If a playback or
capture stream is started while charging is in progress the driver will now
wait in SND_SOC_BIAS_PREPARE until the charging is done. This makes sure
that charging is done asynchronously in the background when the chip is
idle, but at the same time makes sure that playback/capture is not started
before the charging is done.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The delayed work used by the wm8971 driver to manage the caps charging
doesn't have any special requirements that would justify using a custom
workqueue, just use the generic system_power_efficient_wq instead.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix problem where playback of Denon DA-300USB DAC sometimes does not
start and leads to error messages like "clock source 41 is not valid,
cannot use".

Solution: Treat this device the same as other Denon/Marantz devices in
sound/usb/quirks.c.

Tested with both PCM and DSD formats.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93261Signed-off-by: NFrank C Guenther <bugzilla.frnkcg@spamgourmet.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add SNDRV_PCM_INFO_DRAIN_TRIGGER in snd_pcm_hardware.info to
call sst_hsw_stream_set_silence_start() when PCM draining.
Signed-off-by: NLibin Yang <libin.yang@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Adds a quirk to disable the check that the sample rate has been set correctly, as the Lifecam does not support getting the sample rate.

This means that we don't need to wait for the USB timeout when attempting to get the sample rate. Waiting for the timeout causes problems in some applications, which give up on the device acquisition process before it has had time to complete, resulting in no sound.

[minor tidy up by tiwai]
Signed-off-by: NJoe Turner <joe@oampo.co.uk>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NEliot Blennerhassett <eliot@blennerhassett.gen.nz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period
sizes of 32-4096, this translates to 4-512 periods.

The older RME cards have a variable buffer size but require exactly two
periods.

This patch enforces nperiods=2 on those cards.
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Cc: <stable@vger.kernel.org> # 2.6.39+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Otherwise, the mute led can't work at all.
Tested-by: NTaihsiang Ho <taihsiang.ho@canonical.com>
Cc: <stable@vger.kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1410704Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Smatch complains that "control" is user specifigy and needs to be
capped.  The call tree to understand this warning is quite long.

snd_seq_write()  <-- get the event from the user
  snd_seq_client_enqueue_event()
    snd_seq_deliver_event()
      deliver_to_subscribers()
        snd_seq_deliver_single_event()
          snd_opl3_oss_event_input()
            snd_midi_process_event()
              do_control()
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The address cannot be negative so make it unsigned.  Also, an unsigned
int is always sufficient for the length, so no need to overdo it with a
size_t.  Finally, add in range checks to see if the values passed in
actually fit where they are used.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The firmware version is a single byte so have the variable type agree.
Since the address to this member is passed to the read function, using
an int is not even portable.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The serial number (aka ESN) is a 32-bit value.
Signed-off-by: NChris Rorvick <chris@rorvick.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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>

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>

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>

Current snd_soc_unregister_card() indicates unregistered debug
message when it was called. But, it should be called only when
it was really unregistered.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Removes some functions that are not used anywhere:
sst_hsw_stream_unmute() sst_hsw_stream_mute() msg_set_stage_type()
sst_hsw_dx_get_state() sst_hsw_stream_set_write_position()
sst_hsw_stream_get_vol_reg() sst_hsw_stream_get_peak_reg()
sst_hsw_stream_get_pointer_reg() sst_hsw_stream_get_read_reg()
sst_hsw_stream_get_mixer_id() sst_hsw_stream_get_hw_id()
sst_hsw_mixer_set_volume_curve() sst_hsw_mixer_unmute()
sst_hsw_mixer_mute() sst_hsw_stream_set_volume_curve()

This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: NMark Brown <broonie@kernel.org>

Function sst_acpi_probe() uses plain strcpy for setting member firmware_name
of a struct intel_sst_drv from member firmware of a struct sst_machines.
Thereby the destination array has got a length of 20 byte while the source may
hold 32 byte. Since eg. commit 64b9c90b ("ASoC: Intel: Fix BYTCR firmware
name") increased strings from "fw_sst_0f28.bin" to "intel/fw_sst_0f28.bin"
there is an actual possibility that the 20 byte array at the end of struct
intel_sst_drv is overrun.

Thus increase the size of the destination and use the same define for both
structs. Detected by Coverity CID 1260087.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Commit 28c8331d ("ARM: S5PV210: Remove support for board files")
removed the Kconfig symbols MACH_GONI and MACH_AQUILA. As a result the
dependencies of SND_SOC_GONI_AQUILA_WM8994 can never be met. So remove
the unbuildable "SoC I2S Audio support for AQUILA/GONI - WM8994".
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add codec driver for the Maxim MAX98357A DAC.
Signed-off-by: NKenneth Westfield <kwestfie@codeaurora.org>
Acked-by: NBanajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>