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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVKY6pAAoJECTWi3JdVIfQkeAH/1d9FBe2VEqkDR8uJ8T7STsM
1PWg4pT2dLCRiqqhFgrZkKGqdyVCUWbXFz/ksGoK3bip8VMy8naBen1xKdyWgcQT
ZZuGQfywFGxOQSI0vdZSXdr1XyQO47AFRiJ2H9NQEOIMOzCRsjpAtihhkZL8rrCn
AwwViO6TFg09gijkQdbVsm6fxCBlDHM46/EhxP+Xo2K4TEOEeT+ZKxX6IpcJNmA5
Sw6TgyeQwu8LfHwNREczcojmk1wapytZvVivbNedNw7B6I1ujdPIsmnHWFWbiWv5
lfhcM77VLKmv3mwB/v1yRBEf3lNCgqn523N+S8Al9SjDkdLyibhuAWqZXUzsjqY=
=TbSp
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v4.0-rc7' of 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>
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 5fe5b767dc
("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: 5fe5b767dc ("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 5fe5b767dc
("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: 5fe5b767dc ("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 5fe5b767dc
("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: 5fe5b767dc ("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 a1be4cead9 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: af5adf1293 ("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>
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUoX40AAoJECTWi3JdVIfQCHkH/20AXx65DLEvKjtKJTbhE25j
XSmN3ZtXuEdzg70rG1E2YZsZofxRWShX7HHyCwmepWfe30o+V4UCR+4HyHIWVLF6
O3TpupfcQ9ACP+/jQQxxySnTld6LJqW7rNXpxTVGeaba82uDtKIVgv/gHoUtEBDi
NfG0RoVcfpb0k52LWzijIDx4YxVCuIkPHLFqBP63S92XNgw7bc8zjMl65ayY43M+
obfD0ISIdEudmkyqNrQzuNtxl14wsYjzQ5VYqltW5kLaEQVtmD8Zp1bOVI3m0xhX
KY8zQnUUwA4+Cxs8aAm/NvczAZ/GyEQSIjTdUQZDXm0k6H81eya108SfxGvaMYI=
=DSaV
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.19-rc2' 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: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Add codec driver for the Maxim MAX98357A DAC.
Signed-off-by: Kenneth Westfield <kwestfie@codeaurora.org>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Linus Torvalds