| Age | Commit message (Collapse) | Author |
|---|
|
commit 12ed719291a953d443921f9cdb0ffee41066c340 upstream.
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6426460e5d87810e042962281fe3c1e8fc256162 upstream.
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 70372a7566b5e552dbe48abdac08c275081d8558 upstream.
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.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f0153c3d948c1764f6c920a0675d86fc1d75813e upstream.
RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period
sizes of 32-4096, this translates to 4-512 periods.
The older RME cards have a variable buffer size but require exactly two
periods.
This patch enforces nperiods=2 on those cards.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3cd1ce0420ce89937bef9096d5bdb13fbdf0f8b0 upstream.
Fix problem where playback of Denon DA-300USB DAC sometimes does not
start and leads to error messages like "clock source 41 is not valid,
cannot use".
Solution: Treat this device the same as other Denon/Marantz devices in
sound/usb/quirks.c.
Tested with both PCM and DSD formats.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93261
Signed-off-by: Frank C Guenther <bugzilla.frnkcg@spamgourmet.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7976eb49cbd138d8014fa02682d8f969ad1e9ff2 upstream.
Otherwise, the mute led can't work at all.
Tested-by: Taihsiang Ho <taihsiang.ho@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1410704
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4227de2a7e5f0ff6a58e919a9c4f2bb06e882f48 upstream.
Toshiba Satellite S50D laptop with an IDT codec uses the GPIO4 (0x10)
as the master EAPD.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=915858
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e4940626defdf6c92da1052ad3f12741c1a28c90 upstream.
The problem here is that we check:
if (dev >= SNDRV_CARDS)
Then we increment "dev".
if (!joystick_port[dev++])
Then we use it as an offset into a array with SNDRV_CARDS elements.
if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {
This has 3 effects:
1) If you use the module option to specify the joystick port then it has
to be shifted one space over.
2) The wrong error message will be printed on failure if you have over
32 cards.
3) Static checkers will correctly complain that are off by one.
Fixes: db1005ec6ff8 ('ALSA: riptide - Fix joystick resource handling')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f9a7ba326938f03b9305af8d31c360fce10cd4df upstream.
An earlier bug fix of mine made the SND_DM365_VOICE_CODEC symbol
tristate to avoid creating an undefined reference from the
davinci-vcif.c driver to the davinci_soc_platform_register
function that may be in a module.
However, this may now lead to a different error on randconfig
kernels:
"warning: SND_DM365_VOICE_CODEC creates inconsistent choice state"
This happens because we now have a choice statement with
one bool and one tristate option, and the latter might not
support being set to 'y' because of dependencies.
This new change turns the other option into 'tristate' as well,
which avoids the problem.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 19926c6de0c3 ("ASoC: davinci: vcif must be a module if SND_DAVINCI_SOC is")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7331ea474e9e7a348541c207bdb6aa518c6403f4 upstream.
Commit f6b2a04590bb ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM
setup") converted the driver to register the board level DAPM elements with
the card's DAPM context rather than the CODEC's DAPM context. The change
overlooked that the speaker widget event callback accesses the widget's
codec field which is only valid if the widget has been registered in a CODEC
DAPM context. This patch modifies the callback to take an alternative route
to get the CODEC.
Fixes: f6b2a04590bb ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM
setup")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4c121129c9dcb43b33d1cd568c8f2636e72597b0 upstream.
The rt5677 codec has gained code that requires SPI to work correctly,
but there is no provision in Kconfig to prevent the driver from
being used when SPI is disabled or a loadable module, resulting
in this build error:
sound/built-in.o: In function `rt5677_spi_write':
:(.text+0xa7ba0): undefined reference to `spi_sync'
sound/built-in.o: In function `rt5677_spi_driver_init':
:(.init.text+0x253c): undefined reference to `spi_register_driver'
ERROR: "spi_sync" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined!
ERROR: "spi_register_driver" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined!
This makes the SPI portion of the driver depend on the SPI subsystem,
and disables the function that uses SPI for firmware download if SPI
is disabled. The latter may not be the correct solution, but I could
not come up with a better one.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: af48f1d08a54741 ("ASoC: rt5677: Support DSP function for VAD application")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 279e17ae81c17b40ae7a6c9e10f386a7aac7aa55 upstream.
Function sst_acpi_probe() uses plain strcpy for setting member firmware_name
of a struct intel_sst_drv from member firmware of a struct sst_machines.
Thereby the destination array has got a length of 20 byte while the source may
hold 32 byte. Since eg. commit 64b9c90b8600 ("ASoC: Intel: Fix BYTCR firmware
name") increased strings from "fw_sst_0f28.bin" to "intel/fw_sst_0f28.bin"
there is an actual possibility that the 20 byte array at the end of struct
intel_sst_drv is overrun.
Thus increase the size of the destination and use the same define for both
structs. Detected by Coverity CID 1260087.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 92b133f251b5f914f3ed28bc83e5b7a40d4e22ed upstream.
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: AC'97 fixes
These are rather too large for this late in the release cycle but
they're clear, well understood and have been tested to fix a regression
which was introduced for v3.19. The details are all in Lars' changelog
and they've been cooking in -next for a while, to a large extent out
of conservatism about the size.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fix for Intel firmware name
Another one liner that arrived after the earlier pull request. There's
a trivial conflict with my -next branch, I'll send a pull request with
that resolution and some other new stuff before Monday.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.19
A few last minute fixes for v3.19, all driver specific. None of them
stand out particularly - it's all the standard people who are affected
will care stuff.
The Samsung fix is a DT only fix for the audio controller, it's being
merged via the ASoC tree due to process messups (the submitter sent it
at the end of a tangentally related series rather than separately to the
ARM folks) in order to make sure that it gets to people sooner.
|
|
All sst firmware is provided under the intel directory of the linux-firmware
tree. By default this directory structure is kept when installing on a target
system. Change the path to expect a default linux-firmware installation.
Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted
8 SYS_MCLK cycles after all power rails have been brought
up. After this time, communication can start
...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
When SCC work in DSP A mode, the data outputs/inputs are shift out on
falling edge, the frame sync are sample on the rising edge.
Reported-by: Songjun Wu <songjun.wu@atmel.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Shift the I2S mode value by the necessary amount before writing the
registers. This makes Right Justified and PCM mode work in addition to
the default Left Justified mode.
Signed-off-by: Filip Brozovic <fbrozovic@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix the issue introduced by:
368494093354 ASoC: tlv320aic3x: Add TDM support
The CTRLC register were not receiving the correct delay configuration,
which will corrupt DSP_A audio mode.
Fixes: 368494093354 (ASoC: tlv320aic3x: Add TDM support)
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding
this, control the reentrance by introducing a refcount. Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().
The exactly same bug is present in ak4113.c and fixed as well.
Reported-by: Pavel Hofman <pavel.hofman@ivitera.com>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Tested-by: Pavel Hofman <pavel.hofman@ivitera.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We need hold lock each time updating shirm registers, otherwise,
we may set unexpected values to them when they are set in
different thread at different time sequence.
The notification work will be scheduled in global work queue,
which won't hold this sst->spinlock itself, so here we need
change to use the lock version to update shim registers.
Signed-off-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The I2C init path forgot to init the mutex, leading to an oops when
controls are accessed.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
According to the I2S specification information as following:
- WS = 0, channel 1 (left)
- WS = 1, channel 2 (right)
So, the start event should be TF/RF falling edge.
Reported-by: Songjun Wu <songjun.wu@atmel.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
Asus T100TAF uses ACPI ID "10EC5642" for its audio codec. I suppose it is
updated ACPI ID for the RT5642 codec since some earlier platforms are using
"10EC5640" with the RT5642 too.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The wm97xx touchscreen driver binds itself to the snd_ac97 device that gets
registered by the CODEC driver and expects that the device has already been
reset. Before commit 6794f709b712 ("ASoC: ac97: Drop delayed device
registration") the device was only registered after the probe function of
the CODEC driver had finished running, but starting with the mentioned
commit the device is registered as soon as snd_soc_new_ac97_codec() is
called. This causes the touchscreen driver to no longer work. Modify the
CODEC drivers to use snd_soc_alloc_ac97_codec() instead of
snd_soc_new_ac97_codec() and make sure that the AC'97 device is reset before
the snd_ac97 device gets registered.
Fixes: 6794f709b712 ("ASoC: ac97: Drop delayed device registration")
Reported-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Manuel Lauss <manuel.lauss@gmail.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
In some cases it is necessary to before additional operations after the
device has been initialized and before the device is registered. This can
for example be resetting the device.
This patch introduces a new function snd_soc_alloc_ac97_codec() which is
similar to snd_soc_new_ac97_codec() except that it does not register the
device. Any users of snd_soc_alloc_ac97_codec() are responsible for calling
device_add() manually.
Fixes: 6794f709b712 ("ASoC: ac97: Drop delayed device registration")
Reported-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
When the last subscriber to a "Through" port has been removed, the
subscribed destination ports might still be active, so it would be
wrong to send "all sounds off" and "reset controller" events to them.
The proper place for such a shutdown would be the closing of the actual
MIDI port (and close_substream() in rawmidi.c already can do this).
This also fixes a deadlock when dummy_unuse() tries to send events to
its own port that is already locked because it is being freed.
Reported-by: Peter Billam <peter@www.pjb.com.au>
Cc: <stable@vger.kernel.org>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
'asoc/fix/ts3a227e', 'asoc/fix/wm8904' and 'asoc/fix/wm8960' into asoc-linus
|
|
'asoc/fix/fsl-ssi', 'asoc/fix/imx', 'asoc/fix/intel', 'asoc/fix/omap', 'asoc/fix/rockchip' and 'asoc/fix/rt286' into asoc-linus
|
|
|
|
|
|
Signed-off-by: Jason Lee Cragg <jcragg@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Do no send MIDI bytes at the full rate at which FireWire packets happen
to be sent, but restrict them to the actual rate of a real MIDI port.
This is required by the specification, and prevents data loss when the
device's buffer overruns.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
There are several devices that expect to receive MIDI data only in the
first eight data blocks of a packet. If the driver restricts the data
rate to the allowed rate (as mandated by the specification, but not yet
implemented by this driver), this happens naturally. Therefore, there
is no reason to ever try to use more data packets with any device.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We should select FSR also to be driven by McBSP, not only FSX.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
In soc_new_compress() when rtd->dai_link->dynamic is set, we create the pcm
substreams with this call:
ret = snd_pcm_new_internal(rtd->card->snd_card, new_name, num,
1, 0, &be_pcm);
which passes 0 as capture_count leading to
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as
playback_count and capture_count to snd_pcm_new_internal().
Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
There is only one I2S I/F, AD/DA path must operate to the same
format.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Correct the path name for mux to get rid of the following warning:
--->8---
wm8904 1-001a: Control not supported for path ADCL -> [Left] -> AIFOUTL
wm8904 1-001a: ASoC: no dapm match for ADCL --> Left --> AIFOUTL
wm8904 1-001a: ASoC: Failed to add route ADCL -> Left -> AIFOUTL
wm8904 1-001a: Control not supported for path ADCR -> [Right] -> AIFOUTL
wm8904 1-001a: ASoC: no dapm match for ADCR --> Right --> AIFOUTL
wm8904 1-001a: ASoC: Failed to add route ADCR -> Right -> AIFOUTL
wm8904 1-001a: Control not supported for path ADCL -> [Left] -> AIFOUTR
wm8904 1-001a: ASoC: no dapm match for ADCL --> Left --> AIFOUTR
wm8904 1-001a: ASoC: Failed to add route ADCL -> Left -> AIFOUTR
wm8904 1-001a: Control not supported for path ADCR -> [Right] -> AIFOUTR
wm8904 1-001a: ASoC: no dapm match for ADCR --> Right --> AIFOUTR
wm8904 1-001a: ASoC: Failed to add route ADCR -> Right -> AIFOUTR
wm8904 1-001a: Control not supported for path AIFINR -> [Right] -> DACL
wm8904 1-001a: ASoC: no dapm match for AIFINR --> Right --> DACL
wm8904 1-001a: ASoC: Failed to add route AIFINR -> Right -> DACL
wm8904 1-001a: Control not supported for path AIFINL -> [Left] -> DACL
wm8904 1-001a: ASoC: no dapm match for AIFINL --> Left --> DACL
wm8904 1-001a: ASoC: Failed to add route AIFINL -> Left -> DACL
wm8904 1-001a: Control not supported for path AIFINR -> [Right] -> DACR
wm8904 1-001a: ASoC: no dapm match for AIFINR --> Right --> DACR
wm8904 1-001a: ASoC: Failed to add route AIFINR -> Right -> DACR
wm8904 1-001a: Control not supported for path AIFINL -> [Left] -> DACR
wm8904 1-001a: ASoC: no dapm match for AIFINL --> Left --> DACR
wm8904 1-001a: ASoC: Failed to add route AIFINL -> Left -> DACR
---8<---
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If asoc_simple_card_probe() fails, asoc_simple_card_unref() may be
called before dev_set_drvdata(), causing a NULL pointer dereference in
asoc_simple_card_unref():
Unable to handle kernel NULL pointer dereference at virtual address 000000d4
...
PC is at asoc_simple_card_unref+0x14/0x48
LR is at asoc_simple_card_probe+0x3d4/0x40c
This typically happens because asoc_simple_card_parse_of() returns
-EPROBE_DEFER, but other failure modes are possible.
devm_snd_soc_register_card()/snd_soc_register_card() may fail either
before or after dev_set_drvdata().
Pass a snd_soc_card pointer instead of a platform_device pointer to
asoc_simple_card_unref() to fix this.
Note that if CONFIG_OF_DYNAMIC=n, of_node_put() is a dummy, and gcc may
optimize away the loop over card->dai_link, never actually dereferencing
card, and thus avoiding the crash...
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: e512e001dafa54e5 ("ASoC: simple-card: Fix the reference count of device nodes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
The following crash happens when trying to unload the snd_soc_imx_wm8962 module
while playback is active:
[ 208.666868] Unable to handle kernel paging request at virtc
[ 208.674110] pgd = 80004000
[ 208.676867] [7f06541c] *pgd=4c334811, *pte=00000000, *ppte=00000000
[ 208.683211] Internal error: Oops: 80000007 [#1] SMP ARM
[ 208.688445] Modules linked in: snd_soc_wm8962 snd_soc_fsl_ssi snd_soc_imx_audmux imx_pcm_fiq evbug]
...
In order to avoid such problem, fill the card owner field as suggested by
Lars-Peter Clausen:
"But looking at the source it seems that this is a core feature of ALSA and at
least for the card module itself it will do the ref-counting when a stream is
started/stopped. And we even support setting the owner of a card in ASoC.
It's just that pretty much no ASoC card driver bothers to set the owner field
in the snd_soc_card struct. So this particular problem can be fixed by updating
the imx-wm8962 driver to set the owner field."
By doing as suggested, we no longer see the crash when attempting to unload the
snd_soc_imx_wm8962 module while playback is active:
$ modprobe -r snd_soc_imx_wm8962
modprobe: can't unload module snd_soc_imx_wm8962: Resource temporarily
unavailable
Reported-by: Jiada Wang <jiada_wang@mentor.com>
Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The DSP programs are listed out of order.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
|
|
The patch modified the behavior that updates the PLL parameter. It set the
update bit before the PLL power up.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
