| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
commit 17fc2e0a3db11889e942c5ab15a1fcb876638f25 upstream.
According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it
to 384.
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 85e36a1f4a735d991ba5106781ea48e89a0b8901 upstream.
It should be "RINPUT3" instead of "LINPUT3" route to "Right Input
Mixer".
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 810e4425c224af6be67dff68c8832af1b5a11f89 upstream.
set_dai_fmt_both() callback is called from snd_soc_runtime_set_dai_fmt()
which is called from snd_soc_register_card(), but at this time codec
is not powered on yet. Replace direct i2c write with regcache write.
Fixes: 5f0acedddf533c (ASoC: rx1950_uda1380: Use static DAI format setup)
Fixes: 5cc10b9b77c234 (ASoC: h1940_uda1380: Use static DAI format setup)
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 545774bd6e1427d98dde77244329d2311c5eca6f upstream.
mc13xxx_reg_rmw() won't change any bit if passing 0 to the mask field.
Pass AUDIO_SSI_SEL instead of 0 for the mask field to set AUDIO_SSI_SEL
bit.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 60a8d62b8497c23eb3d48149af7e55dac2dd83a2 upstream.
DMIC clock source is not from codec system clock directly. it is
generated from the division of system clock. And it should be 256 *
sample rate of AIF1.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 74d6ea52aeef0236242221c6eff6d892565c5a92 upstream.
The PLL output will be unstable in some cases. We can fix it by
setting some registers.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 427ced4b203dfea4f08b1298cd1f88e19039fca4 upstream.
In case of error, the function devm_kzalloc() returns NULL
not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f073faa73626f41db7050a69edd5074c53ce6d6c upstream.
If den=1 and pllin_rate>20MHz then den and num are adjusted to 0
causing a divide by zero error a few lines further on. Therefore
this patch correctly scales num and den such that
pllin_rate/den < 20MHz as required in the device data sheet.
Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4d9b13c7cc803fbde59d7e998f7de2b9a2101c7e upstream.
This is to ensure that 'alsactl restore' does not apply default
initialisation as the chip reset defaults are preferred.
Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8787041d9bb832b9449b1eb878cedcebce42c61a upstream.
The WM8741 DAC supports the following typical audio sampling rates:
44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz)
32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz)
For the rates lists, we should use 82000 instead of 88235, 176400
instead of 1764000 and 192000 instead of 19200 (seems to be a typo).
Signed-off-by: Sergej Sawazki <ce3a@gmx.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 74ff960222d90999508b4ba0d3449f796695b6d5 upstream.
The delay time after a reset in the codec probe callback was too short,
and did not work on certain hw because the codec needs more time to
power on. This increases the delay time from 1us to 1ms.
Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Acked-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound
Pull last-minute ASoC fix from Mark Brown:
"This patch backs out a change that came in during the merge window
which selects a configuration for GPIO4 on pcm512x CODECs that may not
be suitable for all systems using the device. Changes for v4.1 will
make this properly configurable but for now it's safest to revert to
the v3.19 behaviour and leave the pin configuration alone.
Sorry for sending this direct at the last minute but due to the GPIO
misuse it'd be really good to get it in the release and I'd not
realised it hadn't been sent yet - between some travel, a job change
and other non-urgent fixes coming in I'd lost track of the urgency.
It's been in -next for several weeks now, is isolated to the driver
and fairly clear to inspection"
* tag 'asoc-fix-v4.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound:
ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4
|
|
Currently GPIO4 is hardcoded to output the pll-lock signal.
Unfortunately this is after the pll-out GPIO is configured which
is selectable in the device tree. Therefore it is not possible to
use GPIO4 for pll-out. Therefore this patch removes the
configuration of GPIO4.
Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
into asoc-linus
|
|
'asoc/fix/da732x', 'asoc/fix/fsl-ssi', 'asoc/fix/lock' and 'asoc/fix/rt286' into asoc-linus
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
The board ID will be changed between revisions. So, it is better
to map it by project name.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached
value instead of writing it directly.
Patch inspired by Russell King's more colorful remarks in this
patch:
https://github.com/SolidRun/linux-imx6-3.14/commit/dd4bf6a
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
Routes without a control must use NULL for the control name. The sn95031
driver uses "NULL" instead in a few places. Previous to commit 5fe5b767dc6f
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the sn95031 driver in the process.
This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.
Fixes: 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
Routes without a control must use NULL for the control name. The da732x
driver uses "NULL" instead in a few places. Previous to commit 5fe5b767dc6f
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the da732x driver in the process.
This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.
Fixes: 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
Routes without a control must use NULL for the control name. The ak4671
driver uses "NULL" instead in a few places. Previous to commit 5fe5b767dc6f
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the ak4671 driver in the process.
This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.
Fixes: 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
|
|
|
|
|
|
The patch corrects the routing paths of that after IF1/2 DACx Mux
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The STA32X_AUTO3 is a writable register that currently does not appear
in the regmap ranges(neither read nor write). By adding this register
to the register ranges there is no gap anymore and the existing
register ranges can be joined. This fixes a regression introduced in
commit a1be4cead9b9504aa6fc93b624975601cec8c188 where the driver was
moved to direct regmap usage and the STA32X_AUTO3 register was missed.
That made it impossible to choose the preset EQ mode set through the
STA32X_AUTO3 register.
Fixes: a1be4cead9 (ASoC: sta32x: Convert to direct regmap API usage)
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
RT5670_IRQ_CTRL1(0xbd) is a non volatile register. And we need to
restore its value after suspend/resume.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
Add missing header files to avoid implicit
declarations and indirect inclusions.
Signed-off-by: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We need to set left/right control for the speaker amp to get stereo
output on speaker.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This fixes the following compilation errors:
sound/soc/codecs/max98357a.c: In function ‘max98357a_daiops_trigger’:
sound/soc/codecs/max98357a.c:30:3: error: implicit declaration of function ‘gpiod_set_value’ [-Werror=implicit-function-declaration]
sound/soc/codecs/max98357a.c: In function ‘max98357a_codec_probe’:
sound/soc/codecs/max98357a.c:55:2: error: implicit declaration of function ‘devm_gpiod_get’ [-Werror=implicit-function-declaration]
sound/soc/codecs/max98357a.c:61:2: error: implicit declaration of function ‘gpiod_direction_output’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Kenneth Westfield <kwestfie@codeaurora.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The max98357a driver depends on GPIOLIB. This may cause the following
build failure.
sound/soc/codecs/max98357a.c: In function 'max98357a_daiops_trigger':
sound/soc/codecs/max98357a.c:30:3: error: implicit declaration of function 'gpiod_set_value'
sound/soc/codecs/max98357a.c: In function 'max98357a_codec_probe':
sound/soc/codecs/max98357a.c:55:2: error: implicit declaration of function 'devm_gpiod_get'
sound/soc/codecs/max98357a.c:61:2: error: implicit declaration of function 'gpiod_direction_output'
Seen with mips:allmodconfig as well as various randconfig builds.
Fixes: af5adf129369 ("ASoC: max98357a: Add MAX98357A codec driver")
Cc: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
'asoc/topic/wm8960', 'asoc/topic/wm8988' and 'asoc/topic/xtfpga' into asoc-next
|
|
and 'asoc/topic/txx9' into asoc-next
|
|
'asoc/topic/tdm-slot', 'asoc/topic/tegra' and 'asoc/topic/tlv320aic3x' into asoc-next
|
|
'asoc/topic/rx51', 'asoc/topic/samsung' and 'asoc/topic/sh' into asoc-next
|
|
'asoc/topic/rt286' into asoc-next
|
|
'asoc/topic/intel', 'asoc/topic/jz4740' and 'asoc/topic/max98357a' into asoc-next
|
