driver fixes for new regressions since v3.19. Second are fixes to the
common clock divider type caused by recent changes to how we round clock
rates. This affects many clock drivers that use this common code.
Finally there are fixes for drivers that improperly compared struct clk
pointers (drivers must not deref these pointers). While some of these
drivers have done this for a long time, this did not cause a problem
until we started generating unique struct clk pointers for every
consumer. A new function, clk_is_match was introduced to get these
drivers working again and they are fixed up to no longer deref the
pointers themselves.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVBewEAAoJEKI6nJvDJaTUR2gP/2frIXCm/krwkDyofIGxxQ+F
RwIXFTn9GG9QEUwKLUcxRUegHbWbZMXYp6W19hUcUdYz3pD+uEJSuH0NI8kW1Ohy
32P5/ALuoTq7OVzBBz/9di9jBDdIM1wusLZGJfOWk9DXBLOS3VHuhN55D47dqWS/
GsszeEpp8r1WBKFVmAkuQ5Jc0CqgS5GxvMOndXXVN3kDMhCT+9pBiqtUT0V3YV/J
d5GCvfPlO/Xmjnpjf99MPButkfiW/o6YXt3H0QY6hhskS1Av8alyfabVctk8lqOW
py8SQFY7MdRLZ84Zk87sqKCKUc/vHkTBT9vKWYm65l3yJ5OEFv60NaFMYY61HVlJ
n6qWU6SbFZvkPnQTJn6Ii/v7BQ92bXjYpLNcBK8UY35jIjmHsPS/YXCbkmArtn1N
/yAB4TIfH8uX93smFb3XEmZLSiKFuZAhU8YbjDzYgsGuQ9EwN3aNP9c5mzC7Soou
tYnDqVic0i993qQTD2Db5dplGwxelCRJpazO2kK6NW/EJzE8XJaM6XVy1xIBKiDX
bbWPdp53/eWV7gbUEZ8zzcS06G/DLw5/N45XyaWIx+2ThDjhOAlVHTAFDY+Oa743
42Dkwtr5GZ6yORyXY1wI5HttUGU0gnPN0kM84GQG8O/GbzGureZSW1e6G7tJJljn
JXhROl0w4aIPwUUxry7R
=nc5C
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clock framework fixes from Michael Turquette:
"The clk fixes for 4.0-rc4 comprise three themes.
First are the usual driver fixes for new regressions since v3.19.
Second are fixes to the common clock divider type caused by recent
changes to how we round clock rates. This affects many clock drivers
that use this common code.
Finally there are fixes for drivers that improperly compared struct
clk pointers (drivers must not deref these pointers). While some of
these drivers have done this for a long time, this did not cause a
problem until we started generating unique struct clk pointers for
every consumer. A new function, clk_is_match was introduced to get
these drivers working again and they are fixed up to no longer deref
the pointers themselves"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
ASoC: kirkwood: fix struct clk pointer comparing
ASoC: fsl_spdif: fix struct clk pointer comparing
ARM: imx: fix struct clk pointer comparing
clk: introduce clk_is_match
clk: don't export static symbol
clk: divider: fix calculation of initial best divider when rounding to closest
clk: divider: fix selection of divider when rounding to closest
clk: divider: fix calculation of maximal parent rate for a given divider
clk: divider: return real rate instead of divider value
clk: qcom: fix platform_no_drv_owner.cocci warnings
clk: qcom: fix platform_no_drv_owner.cocci warnings
clk: qcom: Add PLL4 vote clock
clk: qcom: lcc-msm8960: Fix PLL rate detection
clk: qcom: Fix slimbus n and m val offsets
clk: ti: Fix FAPLL parent enable bit handling
The current HDA generic parser initializes / modifies the amp values
always in stereo, but this seems causing the problem on ALC3229 codec
that has a few mono channel widgets: namely, these mono widgets react
to actions for both channels equally.
In the driver code, we do care the mono channel and create a control
only for the left channel (as defined in HD-audio spec) for such a
node. When the control is updated, only the left channel value is
changed. However, in the resume, the right channel value is also
restored from the initial value we took as stereo, and this overwrites
the left channel value. This ends up being the silent output as the
right channel has been never touched and remains muted.
This patch covers the places where unconditional stereo amp accesses
are done and converts to the conditional accesses.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94581
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the
built-in mic records only the right channel. Apply the same
workaround as MBP8,1 to spread the mono channel via a Cirrus codec
vendor-specific COEF setup.
Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CS420x codecs seem to deal only the single amps of ADC nodes even
though the nodes receive multiple inputs. This leads to the
inconsistent amp value after S3/S4 resume, for example.
The fix is just to set codec->single_adc_amp flag. Then the driver
handles these ADC amps as if single connections.
Reported-and-tested-by: Vasil Zlatanov <vasil.zlatanov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The device complies to the UAC1 standard but hides that fact with
proprietary descriptors. The autodetect quirk for Roland devices
catches the audio interface but misses the MIDI part, so a specific
quirk is needed.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reported-by: Rafa Lafuente <rafalafuente@gmail.com>
Tested-by: Raphaël Doursenaud <raphael@doursenaud.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There was no check about the id string of user control elements, so we
accepted even a control element with an empty string, which is
obviously bogus. This patch adds more sanity checks of id strings.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since commit 035a61c314 ("clk: Make clk API return per-user struct clk
instances"), clk API users can no longer check if two struct clk
pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
simply comparing two pointers. That's because with the per-user clk
change, a brand new struct clk is created whenever clients try to look
up the clock by calling clk_get() or sister functions like clk_get_sys()
and of_clk_get(). This changes the original behavior where the struct
clk is only created for once when clock driver registers the clock to
CCF in the first place. The net change here is before commit
035a61c314 the struct clk pointer is unique for given hardware
clock, while after the commit the pointers returned by clk lookup calls
become different for the same hardware clock.
That said, the struct clk pointer comparing in the code doesn't work any
more. Call helper function clk_is_match() instead to fix the problem.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Since commit 035a61c314 ("clk: Make clk API return per-user struct clk
instances"), clk API users can no longer check if two struct clk
pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
simply comparing two pointers. That's because with the per-user clk
change, a brand new struct clk is created whenever clients try to look
up the clock by calling clk_get() or sister functions like clk_get_sys()
and of_clk_get(). This changes the original behavior where the struct
clk is only created for once when clock driver registers the clock to
CCF in the first place. The net change here is before commit
035a61c314 the struct clk pointer is unique for given hardware
clock, while after the commit the pointers returned by clk lookup calls
become different for the same hardware clock.
That said, the struct clk pointer comparing in the code doesn't work any
more. Call helper function clk_is_match() instead to fix the problem.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the
built-in mic NID 0x17 instead of NID 0x1d, and it results in the
non-working mic. This patch just remaps the pin correctly via fixup.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=920604
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
With previous commit, this module managed to leave the counting to each
drivers, but the isochronous resources functionality still increment/decrement
the count.
This commit purge such codes to leave the responsibility to each drivers.
Fix: c6f224dc20 ('ALSA: firewire-lib: remove reference counting')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit [63e51fd708: ALSA: hda - Don't take unresponsive D3
transition too serious] introduced a conditional fallback behavior to
the HD-audio controller depending on the flag set. However, it
introduced a silly bug, too, that the flag was evaluated in a reverse
way. This resulted in a regression of HD-audio controller driver
where it can't go to the fallback mode at communication errors.
Unfortunately (or fortunately?) this didn't come up until recently
because the affected code path is an error handling that happens only
on an unstable hardware chip. Most of recent chips work stably, thus
they didn't hit this problem. Now, we've got a regression report with
a VIA chip, and this seems indeed requiring the fallback to the
polling mode, and finally the bug was revealed.
The fix is a oneliner to remove the wrong logical NOT in the check.
(Lesson learned - be careful about double negation.)
The bug should be backported to stable, but the patch won't be
applicable to 3.13 or earlier because of the code splits. The stable
fix patches for earlier kernels will be posted later manually.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
Fixes: 63e51fd708 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A few driver specific fixes here, none of them earth shattering in
themselves, that have accumliated since the opening of the merge window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU96stAAoJECTWi3JdVIfQLfUH/jBYQqxrPp8qm7Lt9LOuwC4U
SOi0ERIVhLSKZMo7G4wHmbEapx2FBgH+wxqh9kNLaISvOIH4odFS4Fr1XYE70cY9
97M46uzLqdaKCDgvkXdx1NLA0zubEGWLOtdVYlrMAzin0FXNH+KYhxkRQbJ6f0LE
yKmNemnHHtJ4gDl/kMED7bc+mkYSOpwUE/8HLOEA8bcE3luDnj7rvQwOhPIYq0Tz
Ij4GM8HSfWPp/k3YmZVcF8GA6icN3LG5Jg7DOu6S19fMYimTDaHQDCw0AoLfiIOQ
DykyHg7ay/I3B6zUz4JikLIW5KjFxZfeQ818YE0GQ4PgePfb0GSIFt0LnNmq4Oo=
=GIb7
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v4.0
A few driver specific fixes here, none of them earth shattering in
themselves, that have accumliated since the opening of the merge window.
There is a missing lower bound check on "pitchbend" so it means we can
read up to 6 elements before the start of the opl3_note_table[] array.
Thanks to Clemens Ladisch for his help with this patch.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The usages of clamp() macro in sound/usb/line6/playback.c are just
wrong, the low and high values are swapped.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be
set to 32.
The 64 was introduced by commit (in 2009):
a152ff24b9 ASoC: OMAP: Make DMA 64 aligned
But the dma_mask and coherent_dma_mask can not be used to specify alignment.
Fixes: a152ff24b9 (ASoC: OMAP: Make DMA 64 aligned)
Reported-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Atmel based boards can now only be used with device tree. Drop non DT
initialization.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
For received packet stream, the offset of 'RX_SEQ_START' locates after
the offset of 'RX_NUMBER_MIDI', although current macro and proc output
includes wrong offsets.
Fortunately, this bug doesn't affect streaming functionality because
these macro is not used.
This commit fixes these wrong macro and outputs.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The amdtp_stream_wait_callback() doesn't return minus value and
the return code is not for error code.
This commit fixes with a propper condition and an error code.
Fixes: f3699e2c77 ('ALSA: oxfw: Change the way to start stream')
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes faulty behaviour in a setup where the input clock for the
SRG is fed through the CLKR/CLKX pin but the McBSP is configured to be
master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR/CLKX must
not be configured as output pin. Otherwise the input clock is messed up
horribly.
This patch makes it possible to use the CLKR/CLKX pin rather than CLKS to
inject a reference clock in setups where McBSP is master and not both
rx and tx are used. However for this to work it has to be ensured that
set_dai_sysclk() is called after set_dai_fmt().
This was tested on a beagleboard-xm using McBSP1 to drive a i2s DAC through
the tx lines (CLKX,FSX,DX). Using this patch the CLKR pin is used to inject
an external reference clock.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@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>
This is essentially a partial revert of the commit [b1920c2110:
'ALSA: hda - Enable runtime PM on Panther Point']. There was a bug
report showing the HD-audio bus hang during runtime PM on HP Spectre
XT.
Reported-by: Dang Sananikone <dang.sananikone@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It is a bad idea to export static functions. GCC for some platforms
shows errors like:
error: __ksymtab_azx_get_response causes a section type conflict
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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
When a PCM draining is performed to an empty stream that has been
already in PREPARED state, the current code just ignores and leaves as
it is, although the drain is supposed to set all such streams to SETUP
state. This patch covers that overlooked case.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The manual recommends that we reset the DSP when we suspend so add that in
runtime suspend handler
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The IPC driver saved only IMR register, we need to save the CSR as well, so
add it
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The updated firmware expects the MMX ID to be used as 3, so update the
driver as well
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A part of these drivers, especially BeBoB driver, are programmed to wait
some events. Thus the drivers should not destroy any data in .remove()
context.
This commit moves some destructors from 'struct fw_driver.remove()' to
'struct snd_card.private_free()' to shutdown safely.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently stream destructor in each driver has a problem to be called in
a context in which sound card object is released, because the destructors
call amdtp_stream_pcm_abort() and touch PCM runtime data.
The PCM runtime data is destroyed in application's context with
snd_pcm_close(), on the other hand PCM substream data is destroyed after
sound card object is released, in most case after all of ALSA character
devices are released. When PCM runtime is destroyed and PCM substream is
remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes
Null-pointer-dereference.
This commit changes stream destructors and allows each driver to call
it after releasing runtime.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
AMDTP helper functions increment/decrement reference counter for an
instance of FireWire unit, while it's complicated for each driver to
process error state.
In previous commit, each driver has the role of reference counting. This
commit removes this role from the helper function.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fireworks and Dice drivers try to touch instances of FireWire unit after
sound card object is released, while references to the unit is decremented
in .remove(). When unplugging during streaming, sound card object is
released after .remove(), thus Fireworks and Dice drivers causes GPF or
Null-pointer-dereferencing to application processes because an instance of
FireWire unit was already released.
This commit adds reference-counting for FireWire unit in drivers to allow
them to touch an instance of FireWire unit after .remove(). In most case,
any operations after .remove() may be failed safely.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need
to give explicitly here.
Reported-and-tested-by: Misan Thropos <misanthropos@gmx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sign for microsecond (U+0085, MICRO SIGN) was encoded to '0x c2 b5'
by UTF-8 character encoding scheme. But the byte sequence was converted
to '0x c3 82 c2 b5' in a previous commit. As a result, the byte
sequence cannot represent microsecond sign in UTF-8 or ASCII. This
may confuse developers.
This commit replaces the sign to string expression with 'microseconds'
to purge superfluous troubles.
Fixes: 5c697e5b46ef("ALSA: firewire-lib: remove rx_blocks_for_midi quirk")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
