Merge tag 'asoc-v3.13-rc8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v3.13

A few small fixes in drivers, nothing too remarkable here but all good
to have - mainly these are fixes for things that were introduced in the
last merge window but only just got useful testing.

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

ASoC: More updates for v3.14

A few more updates for v3.14 since the last set, highlights include:

 - Lots of DMA updates from Lars-Peter
 - Improvements to the constraints handling code from Lars-Peter
 - A very helpful conversion of the TWL4030 driver to regmap from Peter
 - A new driver for the Freescale ESAI controller from Nicolin Chen
 - Conversion of some of the drivers to use params_width()

Merge remote-tracking branches 'asoc/topic/adsp', 'asoc/topic/atmel', 'asoc/topic/bcm2835', 'asoc/topic/docs', 'asoc/topic/fsl', 'asoc/topic/generic', 'asoc/topic/kirkwood', 'asoc/topic/mc13783', 'asoc/topic/mxs', 'asoc/topic/nuc900', 'asoc/topic/sai', 'asoc/topic/sh', 'asoc/topic/ssm2602', 'asoc/topic/tlv320aic3x', 'asoc/topic/twl4030', 'asoc/topic/ux500', 'asoc/topic/width' and 'asoc/topic/x86' into for-tiwai

When we plug a 3-ring headset on some Dell machines, the headset
mic can't be detected, after apply this patch, the headset mic
can work well on all those machines.

On the machine with the Subsytem ID 0x10280610, if we use
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, the headset mic can be
detected and work well, but the sound can't be outputed via
headphone anymore, use ALC269_FIXUP_DELL3_MIC_NO_PRESENCE
can fix this problem.

BugLink: https://bugs.launchpad.net/bugs/1260303
Cc: David Henningsson <david.henningsson@canonical.com>
Tested-by: NDavid Chen <david.chen@canonical.com>
Tested-by: NCyrus Lien <cyrus.lien@canonical.com>
Tested-by: NShawn Wang <shawn.wang@canonical.com>
Tested-by: NChih-Hsyuan Ho <chih.ho@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

range_min is the lowest address in the virtual register range. This is
the first register with address 0, not the first register of page 1.

Currently all writes to page 1 are mapped to page 0, so the codec fails
to operate.

Fixes: 4d208ca4 (ASoC: tlv320aic32x4: Convert to direct regmap API usage)
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org (v3.13 if the fix misses -final)

Make it easier for generic code to work with set_sysclk() by distinguishing
between the operation not being supported and an error as is done for
other operations like set_dai_fmt()
Signed-off-by: NMark Brown <broonie@linaro.org>

soc_widget_read API returns the register data and it is possible
that a register can contain 0xffffffff. Thus, change the prototype
of soc_widget_read to return only the error code and pass the reg
data through pointer argument.
Signed-off-by: NArun Shamanna Lakshmi <aruns@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The Samsung dmaengine ASoC driver is used with two different dmaengine drivers.
The pl80x, which properly supports residue reporting and the pl330, which
reports that it does not support residue reporting. So there is no need to
manually set the NO_RESIDUE flag. This has the advantage that a proper (race
condition free) PCM pointer() implementation is used when the pl80x driver is
used. Also once the pl330 driver supports residue reporting the ASoC PCM driver
will automatically start using it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pl330 driver properly reports that it does not have residue reporting
support, which means the PCM dmanegine driver is able to figure this out on its
own. So there is no need to set the flag manually. Removing the flag has the
advantage that once the pl330 driver gains support for residue reporting it will
automatically be used by the generic dmaengine PCM driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The dmaengine framework now exposes the granularity with which it is able to
report the transfer residue for a certain DMA channel. Check the granularity in
the generic dmaengine PCM driver and
	a) Set the SNDRV_PCM_INFO_BATCH if the granularity is per period or worse.
	b) Fallback to the (race condition prone) period counting if the driver does
	not support any residue reporting.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently we have two different snd_soc_platform_driver structs in the generic
dmaengine PCM driver. One for dmaengine drivers that support residue reporting
and one for those which do not. When registering the PCM component we check
whether the NO_RESIDUE flag is set or not and use the corresponding
snd_soc_platform_driver. This patch modifies the driver to only have one
snd_soc_platform_driver struct where the pointer() callback checks the
NO_RESIDUE flag at runtime. This allows us to set the NO_RESIDUE flag after the
PCM component has been registered. This becomes necessary when querying whether
the dmaengine driver supports residue reporting from the dmaengine driver itself
since the DMA channel might only be requested after the PCM component has been
registered.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The pl330 driver currently does not support residue reporting, so set the
residue granularity to DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch adds a new field to the dma_slave_caps struct which indicates the
granularity with which the driver is able to update the residue field of the
dma_tx_state struct. Making this information available to dmaengine users allows
them to make better decisions on how to operate. E.g. for audio certain features
like wakeup less operation or timer based scheduling only make sense and work
correctly if the reported residue is fine-grained enough.

Right now four different levels of granularity are supported:
	* DESCRIPTOR: The DMA channel is only able to tell whether a descriptor has
	  been completed or not, which means residue reporting is not supported by
	  this channel. The residue field of the dma_tx_state field will always be
	  0.
	* SEGMENT: The DMA channel updates the residue field after each successfully
	  completed segment of the transfer (For cyclic transfers this is after each
	  period). This is typically implemented by having the hardware generate an
	  interrupt after each transferred segment and then the drivers updates the
	  outstanding residue by the size of the segment. Another possibility is if
	  the hardware supports SG and the segment descriptor has a field which gets
	  set after the segment has been completed. The driver then counts the
	  number of segments without the flag set to compute the residue.
	* BURST: The DMA channel updates the residue field after each transferred
	  burst. This is typically only supported if the hardware has a progress
	  register of some sort (E.g. a register with the current read/write address
	  or a register with the amount of bursts/beats/bytes that have been
	  transferred or still need to be transferred).
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Merge branch 'topic/samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-dma

Merge branch 'topic/axi' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-dma

It's a bug that writing to the platform data directly, for it should
be constant. So just copy it before writing.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Instead of open-coding the intersecting of two rate masks (and getting slightly
wrong for some of the corner cases) use the new snd_pcm_rate_mask_intersect()
helper function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

A bit of special care is necessary when creating the intersection of two rate
masks. This comes from the special meaning of the SNDRV_PCM_RATE_CONTINUOUS and
SNDRV_PCM_RATE_KNOT bits, which needs special handling when intersecting two
rate masks. SNDRV_PCM_RATE_CONTINUOUS means the hardware supports all rates in a
specific interval. SNDRV_PCM_RATE_KNOT means the hardware supports a set of
discrete rates specified by a list constraint. For all other cases the supported
rates are specified directly in the rate mask.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

SNDRV_PCM_RATE_CONTINUOUS means that all rates (possibly limited to a certain
interval) are supported. There is no need to manually set other rate bits.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NDaniel Glöckner <daniel-gl@gmx.net>
Signed-off-by: NMark Brown <broonie@linaro.org>

SNDRV_PCM_RATE_CONTINUOUS means that all rates (possibly limited to a certain
interval) are supported. There is no need to manually set other rate bits.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

If none of the components (CODEC or CPU DAI) sets a maximum sample rate we'll
end up with the rate_max field of the runtime hardware set to 0.  (Note that it
is still possible for the components to constrain the supported sample rates
using other methods, e.g. setting a list constraint) If rate_max is 0 this means
that the sound card doesn't support any rates at all, which is not the desired
result. So initialize rate_max to UINT_MAX. For symmetry reasons also set
rate_min to 0.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Linux 3.13-rc3

There are three files in oss for which I could not find an easy way to
replace interruptible_sleep_on_timeout with a non-racy version. This
patch instead just adds a private implementation of the function, now
named oss_broken_sleep_on, and changes over the remaining users in
sound/oss/ so we can remove the global interface.

[fixed coding style warnings by tiwai]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The use of interruptible_sleep_on_timeout in the dmasound driver
is questionable and we want to kill off all sleep_on variants.
This replaces the calls with wait_event_interruptible_timeout
where possible, to wait for a particular event instead of blocking
in a racy way. In the sq_write function, the easiest solution is
an open-coded prepare_to_wait loop.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

sleep_on is known to be racy and going away because of this. All instances
of interruptible_sleep_on and interruptible_sleep_on_timeout in the midibuf
driver can trivially be replaced with wait_event_interruptible and
wait_event_interruptible_timeout.

[fixed coding style warnings by tiwai]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Interruptible_sleep_on is racy and we want to remove it. This replaces
the use in the vwsnd driver with an open-coded prepare_to_wait
loop that fixes the race between concurrent open() and close() calls,
and also drops the global mutex while waiting here, which restores
the original behavior that was changed during the BKL removal.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We want to remove all sleep_on variants from the kernel because they are
racy. In case of the pinnacle driver, we can replace
interruptible_sleep_on_timeout with wait_event_interruptible_timeout
by changing the meaning of a few flags used in the driver so they
are cleared at wakeup time, which is a somewhat more appropriate
way to do the same, although probably still racy.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new vmaster hook, update_tpacpi_mute_led(), calls the original
vmaster hook, but I forgot to save the original hook function but keep
calling the updated one, which of course results in a stupid endless
loop.  Fixed now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

No code change, just a cosmetic cleanup to keep entries ordered by the
device ID within a block of unique vendor IDs.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Creative Live! Cam Vista IM (VF0420) reports rate of 16kHz while working
at 8kHz. The patch adds its USB ID to the existing quirk.
Signed-off-by: NPavel Hofman <pavel.hofman@ivitera.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NEduard Gilmutdinov <edgilmutdinov@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On some AIO (All In One) models with the codec alc668
(Vendor ID: 0x10ec0668) on it, when we plug a headphone into the jack,
the system will switch the output to headphone and set the speaker to
automute as well as change the speaker Pin-ctls from 0x40 to 0x00,
this will bring loud noise to the headphone.

I tried to disable the corresponding EAPD, but it did not help to
eliminate the noise.

According to Takashi's suggestion, we use amp operation to replace the
pinctl modification for the automute, this really eliminate the noise.

BugLink: https://bugs.launchpad.net/bugs/1268468
Cc: David Henningsson <david.henningsson@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>