ALC256 has its own quirk to override the shutup call, and it contains
the COEF update for pulling down the headset jack control. Currently,
the COEF update is called after clearing the headphone pin, and this
seems triggering a stall of the codec communication, and results in a
long delay over a second at suspend.
A quick resolution is to swap the calls: at first with the COEF
update, then clear the headphone pin.
Fixes: 4a219ef8f3 ("ALSA: hda/realtek - Add ALC256 HP depop function")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198503
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some final updates for the merge window, this brings in some
improvements to the ACPI GPIO handling for Intel and a bunch of fixes.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlph4RMTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0MzZB/9wMMti91eAeyTnnZvhf+7USCrhbYha
NQr0gktACvGY5y+qhVOdPGASzWBjUObWu0Ne+W32/WRWjJ9Gh54yomH5uAHCP8kl
qFugDwxagy1hKqMMn1reKhSbxPFbS1uOEDAZZPC1hWAWk9ZgXpKL9uI+kAZIBZ2z
48CVHBb6XUwD7Pcb5jOcUEhr5CLyCwoeAsiXDztDI5BCzvbrENe3lQoX5snoswij
/0qX7SrJmgiH/mMiLZQs4PU9v4nwzwrXpwYXwUWJGZPVPNGTtpnhc5xk0UgmMytW
D7pzf5GIkra+khon5BbxvAo0aNaRLpw+lTCnBIRhP3Aa/Tfe9mnOZhbF
=bULv
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.16-3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v4.16
Some final updates for the merge window, this brings in some
improvements to the ACPI GPIO handling for Intel and a bunch of fixes.
Now the debugfs files dais/platforms/codecs have a size limit PAGE_SIZE and
the user can not see the whole contents of dai_list/platform_list/codec_list
when they are larger than this limit.
This patch uses seq_file instead to make sure dais/platforms/codecs show the
full contents of dai_list/platform_list/codec_list.
Signed-off-by: Donglin Peng <dolinux.peng@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If bcm2835 is configured as bitclock master calling hw_params()
after prepare() fails with EBUSY. This also makes it impossible to
use bcm2835 in full duplex mode.
The error is caused by the split clock setup: clk_set_rate
is called in hw_params, clk_prepare_enable in prepare. As hw_params
doesn't check if the clock was already enabled clk_set_rate
fails with EBUSY.
Fix this by moving clock startup from prepare to hw_params and
let hw_params properly deal with an already set up or enabled
clock.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Probe deferral may happen, so do not print an error message in this
case.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When the MCLK is not yet available when the codec is probed, probe
deferral will happen and in this case we should not print an
error message.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SND_SST_ATOM_HIFI2_PLATFORM_PCI select SND_SOC_INTEL_COMMON which do not
exists anymore.
So remove this select.
Fixes: c6059879be ("ASoC: Intel: Fix Kconfig with top-level selector")
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The E1 has two headphone jacks, one of which can be set as a microphone
input. In the default mode, it uses the built-in microphone as an input.
By sending a special command, the second headphone jack is instead used
as an input.
This might work with the E3 as well, but I don't have one of those to
test it.
Signed-off-by: Ian Douglas Scott <ian@iandouglasscott.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The second assignment to res is identical to the previous assignment
so it is redundant and can be removed.
Cleans up clang warning:
sound/soc/intel/skylake/skl-topology.c:191:25: warning: Value stored to
'res' during its initialization is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add ALC215 its own depop functions for alc_init and alc_shutup.
Assign it to ALC225 usage.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch will enable headset mode for ALC215/ALC285/ALC289 platform.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt <luisbg@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current ALSA SoC, Codec only has .read/.write callback.
Codec will be merged into Component in next generation ALSA SoC,
thus current Codec specific feature need to be merged into it.
This is glue patch for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 39b5a0f80c ("ASoC: cx20442: don't use reg_cache")
removed .read/.write from driver, but it might breaks non-regmap
driver, because ALSA SoC framework might call it.
To fix this regression, this patch back .read/.write.
and also this patch uses cx20442 internal reg_cache
which is needed for .read/.write.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit c001bf633a ("ASoC: use internal reg_cache on uda1380")
removed .read/.write from driver, but it might breaks non-regmap
driver, because ALSA SoC framework might call it.
To fix this regression, this patch back .read/.write
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit c4305af43a ("ASoC: use internal reg_cache on tlv320dac33")
removed .read/.write from driver, but it might breaks non-regmap
driver, because ALSA SoC framework might call it.
To fix this regression, this patch back .read/.write
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The commit ffcd28d88e ("ALSA: hda - Select INPUT for Realtek
HD-audio codec") introduced the reverse-selection of CONFIG_INPUT for
Realtek codec in order to avoid the mess with dependency between
built-in and modules. Later on, we obtained IS_REACHABLE() macro
exactly for this kind of problems, and now we can remove th INPUT
selection in Kconfig and put IS_REACHABLE(INPUT) to the appropriate
places in the code, so that the driver doesn't need to select other
subsystem forcibly.
Fixes: ffcd28d88e ("ALSA: hda - Select INPUT for Realtek HD-audio codec")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # and build-tested
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The loop timeout doesn't work because it's a post op and ends with "tmo"
set to -1. I changed it from a post-op to a pre-op and I changed the
initial the starting value from 5 to 6 so we still iterate 5 times. I
left the other as it was because it's a large number.
Fixes: b3c70c9ea6 ("ASoC: Alchemy AC97C/I2SC audio support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The SNDRV_SEQ_IOCTL_SET_QUEUE_TEMPO ioctl sets the tempo and the ppq
in a single call, while the current implementation updates each value
one by one. This is a bit racy, and also suboptimal from the
performance POV, as each call does re-acquire the lock and invokes
the update of ALSA timer resolution.
This patch reorganizes the code slightly so that we change both the
tempo and the ppq in a shot. The skew value can be put into the same
lock, but this is rather a rarely used feature and completely
independent from the temp/ppq (it's evaluated only in the interrupt),
so it's left as it was.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The capture interface does not work, and the playback interface
actually supports only 48kHz unlike what is advertised (44.1, 32, 22,
16, 8).
The only unknown here is if there are other devices that use the same
product ID, but given that this ID is currently unknown, I would assume
it is specially allocated for the nura headset.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
