According to user manual, it is required that FLL_LAMBDA > 0
in all cases (Integer and Franctional modes).
Fixes: 9a76f1ff6e ("ASoC: Add initial WM8962 CODEC driver")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/1576065442-19763-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On CML boards with the RT5682 headset codec and RT1011 speaker
amplifier, the platform firmware exposes three ACPI HIDs
(10EC5682, 10EC1011 and MX98357A). The last HID is a mistake in
DSDT tables, which causes the wrong machine driver to be loaded.
This patch changes the key used to identify boards and changes the
order of entries in the table to load the correct machine driver.
The order does matter and should not be modified to work-around this
firmware issue.
Signed-off-by: Amery Song <chao.song@intel.com>
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191210004854.16845-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Turns out SSP 3-5 are only available on cht, to avoid dumping on
undefined registers let's split the definition.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191210004854.16845-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
An error occurs during parsing more than one ext_data from the mailbox, because
of invalid data offset handling. Fix by removing the incorrect duplicate
increment of the offset.
The return value is also reset in the switch case. This does not change the
behavior but improves readability - there is no longer a need to check what the
return value of get_ext_windows is.
Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Signed-off-by: Bartosz Kokoszko <bartoszx.kokoszko@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191210004854.16845-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Added warning log when found some unknown FW boot ext header,
to improve debuggability.
Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191210004854.16845-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In normal sound case all DAIs are detected as CPU-Codec.
simple_dai_link_of supports the presence of a platform but it counts
it as a CPU DAI resulting in the creation of an extra link.
Adding a platform property to a link description like:
simple-audio-card,dai-link {
cpu {
sound-dai = <&sai1>;
};
plat {
sound-dai = <&dsp>;
};
codec {
sound-dai = <&wm8960>;
}
will result in the creation of two links:
* sai1 <-> wm8960
* dsp <-> wm8960
which is obviously not what we want. We just want one single link
with:
* sai1 <-> wm8960 (and platform set to dsp).
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20191209135353.17427-1-daniel.baluta@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The return value of soc_tplg_pcm_create() is currently not checked
in soc_tplg_pcm_elems_load(). If an error is to occur there, the
topology ignores it and continues loading.
Fix that by checking the status and rejecting the topology on error.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191210003939.15752-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_add_dai_link() might fail. This situation occurs for
instance in a very specific use case where a PCM device and a
Back End DAI link are given identical names in the topology.
When this happens, soc_new_pcm_runtime() fails and then
snd_soc_add_dai_link() returns -ENOMEM when called from
soc_tplg_fe_link_create(). Because of that, the link will not
get added into the card list, so any attempt to remove it later
ends up in a panic.
Fix that by checking the return status and free the memory in case
of an error.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191210003939.15752-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are many paths to soc_free_pcm_runtime which can both have and
have not yet inited the workqueue yet. When we flush the queue when we
have not yet inited the queue we cause warnings to be printed.
An example is soc_cleanup_card_resources which is called by
snd_soc_bind_card which has multiple failure points before and after
soc_link_init -> soc_new_pcm which is where the queue is inited.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20191128011358.39234-1-cujomalainey@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When the Teclast X89 quirk was added we did not have jack-detection
support yet.
Note the over-current detection limit is set to 2mA instead of the usual
1.5mA because this tablet tends to give false-positive button-presses
when it is set to 1.5mA.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191203221442.2657-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are cases where we fail before we reach soc_new_pcm which would
init the workqueue. When we fail we attempt to flush the queue which
generates warnings from the workqueue subsystem when we have not inited
the queue. Solution is to use a proxy function to get around this issue.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20191203173007.46504-1-cujomalainey@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix build error:
sound/soc/intel/atom/sst/sst.c: In function intel_sst_interrupt_mrfld:
sound/soc/intel/atom/sst/sst.c:93:5: error: implicit declaration of function memcpy_fromio;
did you mean memcpy32_fromio? [-Werror=implicit-function-declaration]
memcpy_fromio(msg->mailbox_data,
^~~~~~~~~~~~~
memcpy32_fromio
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191128135853.8360-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
max98090_interrupt() and max98090_pll_work() run in 2 different threads.
There are 2 possible races:
Note: M98090_REG_DEVICE_STATUS = 0x01.
Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked.
max98090_interrupt max98090_pll_work
----------------------------------------------
schedule max98090_pll_work
restart max98090 codec
receive ULK INT
assert ULK == 0
schedule max98090_pll_work (1).
In the case (1), the PLL is locked but max98090_interrupt unnecessarily
schedules another max98090_pll_work.
max98090_interrupt max98090_pll_work max98090 codec
----------------------------------------------------------------------
ULK = 1
receive ULK INT
read 0x01
ULK = 0 (clear on read)
schedule max98090_pll_work
restart max98090 codec
ULK = 1
receive ULK INT
read 0x01
ULK = 0 (clear on read)
read 0x01
assert ULK == 0 (2).
In the case (2), both max98090_interrupt and max98090_pll_work read
the same clear-on-read register. max98090_pll_work would falsely
thought PLL is locked.
Note: the case (2) race is introduced by the previous commit ("ASoC:
max98090: exit workaround earlier if PLL is locked") to check the status
and exit the loop earlier in max98090_pll_work.
There are 2 possible solution options:
A. turn off ULK interrupt before scheduling max98090_pll_work; and turn
on again before exiting max98090_pll_work.
B. remove the second thread of execution.
Option A cannot fix the case (2) race because it still has 2 threads
access the same clear-on-read register simultaneously. Although we
could suppose the register is volatile and read the status via I2C could
be much slower than the hardware raises the bits.
Option B introduces a maximum 10~12 msec penalty delay in the interrupt
handler. However, it could only punish the jack detection by extra
10~12 msec.
Adopts option B which is the better solution overall.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the datasheet, PLL lock time typically takes 2 msec and
at most takes 7 msec.
Check the lock status every 1 msec and exit the workaround if PLL is
locked.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20191122073114.219945-3-tzungbi@google.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It was observed Baytrail-based chromebooks could cause continuous PLL
unlocked when using playback stream and capture stream simultaneously.
Specifically, starting a capture stream after started a playback stream.
As a result, the audio data could corrupt or turn completely silent.
As the datasheet suggested, the maximum PLL lock time should be 7 msec.
The workaround resets the codec softly by toggling SHDN off and on if
PLL failed to lock for 10 msec. Notably, there is no suggested hold
time for SHDN off.
On Baytrail-based chromebooks, it would easily happen continuous PLL
unlocked if there is a 10 msec delay between SHDN off and on. Removes
the msleep().
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20191122073114.219945-2-tzungbi@google.com
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The simple-card tries to signal the codec to disable rate constraints,
see commit 2458adb8f9 ("SoC: simple-card-utils: set 0Hz to sysclk when
shutdown"). This wasn't handled by the codec, instead it would set the
FLL frequency to 0Hz which isn't working. Since we don't have any rate
constraints just ignore this request.
Fixes: 13409d27cb ("ASoC: wm8904: configure sysclk/FLL automatically")
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20191122232532.22258-1-michael@walle.cc
Signed-off-by: Mark Brown <broonie@kernel.org>
If CONFIG_SPI is n, SND_SOC_RT5677_SPI also is n, building fails:
sound/soc/codecs/rt5677.o: In function `rt5677_irq':
rt5677.c:(.text+0x2dbf): undefined reference to `rt5677_spi_hotword_detected'
sound/soc/codecs/rt5677.o: In function `rt5677_dsp_work':
rt5677.c:(.text+0x3709): undefined reference to `rt5677_spi_write'
This adds stub helpers to fix this.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 461c623270 ("ASoC: rt5677: Load firmware via SPI using delayed work")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191127082145.6100-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Link unload now fails for ESAI/SAI DAIs with:
"error: invalid DAI type 6" because DAI type is not
properly handled.
Fix this by correctly handling cases where type is ESAI or SAI.
Fixes: a4eff5f86c ("ASoC: SOF: imx: Read ESAI parameters and send them to DSP")
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191126141606.21650-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The shim registers in BYT/CHT/BSW are 64bits based, correct the
copy/paste (from bdw.c where the shim registers are 32bits based) error
in byt_dump().
Fixes: 3a9e204d4e ("ASoC: SOF: Intel: Add context data to any IPC timeout")
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191126141533.21601-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some usages only call startup and shutdown without setting hw_params
(e.g. arecord --dump-hw-params). If we don't enable clk in startup, it
will cause ref count error because the clk will be disabled in shutdown.
For this reason, we should move enabling clk from hw_params to startup.
In addition, the hw_params is fixed in this driver(48000 rate, 2
channels, S16_LE format) so we don't need to change the clk rate after
the hw_params is set.
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Acked-by: Akshu Agrawal <akshu.agarawal@amd.com>
Link: https://lore.kernel.org/r/20191126075424.80668-1-yuhsuan@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code:
LENOVO-20QE000VMC-ThinkPadX1Carbon7th-20QE000VMC
With the patch:
LENOVO-20QE000VMC-ThinkPadX1Carbon7th
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20191120174435.30920-2-perex@perex.cz
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add append_dmi_string() function and make the code more readable.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191120174435.30920-1-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191120133252.6365-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit 957ce0c6b8 (ASoC: soc-pcm: check symmetry after
hw_params).
That commit cause soc_pcm_params_symmetry can't take effect.
cpu_dai->rate, cpu_dai->channels and cpu_dai->sample_bits
are updated in the middle of soc_pcm_hw_params, so move
soc_pcm_params_symmetry to the end of soc_pcm_hw_params is
not a good solution, for judgement of symmetry in the function
is always true.
FIXME:
According to the comments of that commit, I think the case
described in the commit should disable symmetric_rates
in Back-End, rather than changing the position of
soc_pcm_params_symmetry.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1573555602-5403-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The RST (reset-gpios) is low active so the driver must handle it
accordingly.
Add comments to explain clearly how the line is used.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191120131753.6831-3-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This ASCII string can carry additional information about
soundcard components or configuration. Add the possibility
to set this string via the ASoC card.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191119174933.25526-1-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>
soc-topology adds extra dai_link by using snd_soc_add_dai_link(),
and removes it by snd_soc_romove_dai_link().
This snd_soc_add/remove_dai_link() and/or its related
functions are unbalanced before, and now, these are balance-uped.
But, it finds the random operation issue, and it is reported by
Pierre-Louis.
When card was released, topology will call snd_soc_remove_dai_link()
via (A).
static void soc_cleanup_card_resources(struct snd_soc_card *card)
{
struct snd_soc_dai_link *link, *_link;
/* This should be called before snd_card_free() */
(A) soc_remove_link_components(card);
/* free the ALSA card at first; this syncs with pending operations */
if (card->snd_card) {
(B) snd_card_free(card->snd_card);
card->snd_card = NULL;
}
/* remove and free each DAI */
(X) soc_remove_link_dais(card);
for_each_card_links_safe(card, link, _link)
(C) snd_soc_remove_dai_link(card, link);
...
}
At (A), topology calls snd_soc_remove_dai_link().
Then topology rtd, and its related all data are freed.
Next, (B) is called, and then, pcm->private_free = soc_pcm_private_free()
is called.
static void soc_pcm_private_free(struct snd_pcm *pcm)
{
struct snd_soc_pcm_runtime *rtd = pcm->private_data;
/* need to sync the delayed work before releasing resources */
flush_delayed_work(&rtd->delayed_work);
snd_soc_pcm_component_free(rtd);
}
Here, it gets rtd via pcm->private_data.
But, topology related rtd are already freed at (A).
Normal sound card has no damage, becase it frees rtd at (C).
These are finalizing rtd related data.
Thus, these should be called when rtd was freed, not sound card
was freed. It is very natural and understandable.
In other words, pcm->private_free = soc_pcm_private_free()
is no longer needed.
Extra issue is that there is zero chance to call
soc_remove_dai() for topology related dai at (X).
Because (A) removes rtd connection from card too, and,
(X) is based on card connected rtd.
This means, (X) need to be called before (C) (= for normal sound)
and (A) (= for topology).
Now, I want to focus this patch which is the reason why
snd_card_free() = (B) is located there.
commit 4efda5f213
("ASoC: Fix use-after-free at card unregistration")
Original snd_card_free() was called last of this function.
But moved to top to avoid use-after-free issue.
The issue was happen at soc_pcm_free() which was pcm->private_free,
today it is updated/renamed to soc_pcm_private_free().
In other words, (B) need to be called before (C) (= for normal sound)
and (A) (= for topology), because it needs (not yet freed) rtd.
But, (A) need to be called before (B),
because it needs card->snd_card pointer.
If we call flush_delayed_work() and snd_soc_pcm_component_free()
(= same as soc_pcm_private_free()) when rtd was freed (= (C), (A)),
there is no reason to call snd_card_free() at top of this function.
It can be called end of this function, again.
But, in such case, it will likely break unbind again, as Takashi-san
reported. When unbind is performed in a busy state, the code may
release still-in-use resources.
At least we need to call snd_card_disconnect_sync() at the first place.
The final code will be...
static void soc_cleanup_card_resources(struct snd_soc_card *card)
{
struct snd_soc_dai_link *link, *_link;
if (card->snd_card)
(Z) snd_card_disconnect_sync(card->snd_card);
(X) soc_remove_link_dais(card);
(A) soc_remove_link_components(card);
for_each_card_links_safe(card, link, _link)
(C) snd_soc_remove_dai_link(card, link);
...
if (card->snd_card) {
(B) snd_card_free(card->snd_card);
card->snd_card = NULL;
}
}
To avoid release still-in-use resources,
call snd_card_disconnect_sync() at (Z).
(X) is needed for both non-topology and topology.
topology removes rtd via (A), and
non topology removes rtd via (C).
snd_card_free() is no longer related to use-after-free issue.
Thus, locating (B) is no problem.
Fixes: df95a16d2a ("ASoC: soc-core: fix RIP warning on card removal")
Fixes: bc7a9091e5 ("ASoC: soc-core: add soc_unbind_dai_link()")
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/87o8xax88g.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch uses rtd instead of pcm at snd_soc_pcm_component_new/free()
parameter.
This is prepare for dai_link remove bug fix on topology.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pnhqx89j.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Expose mixer control API for reading and writing controls from the kernel.
This API can be used by ALSA kernel drivers with ADSP support to
read and write firmware-defined memory regions.
Signed-off-by: Li Xu <li.xu@cirrus.com>
Signed-off-by: David Rhodes <david.rhodes@cirrus.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/1573847653-17094-2-git-send-email-david.rhodes@cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The tlv320aic31xx devices allow to adjust the output common-mode voltage
for best analog performance. The datasheet states that the common mode
voltage should be set to be <= AVDD/2.
This changes allows to configure the output common-mode voltage via a DT
property. If the property is absent the voltage is automatically chosen
as the highest voltage below/equal to AVDD/2.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20191118151207.28576-1-l.stach@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The manifest information is different between CNL, CML and CFL platforms
hence we need to load different files.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191111222901.19892-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In case the RST line is connected to a GPIO line it needs to be pulled high
when the driver probes to be able to use the codec.
Add support also for cases when more than one codec is is controlled by the
same GPIO line by requesting the gpio with GPIOD_FLAGS_BIT_NONEXCLUSIVE.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191113124734.27984-3-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver forgets to call pm_runtime_disable in remove and
probe failure.
Add the calls to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20191118073707.28298-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver misses calls to pm_runtime_disable and regulator_bulk_disable
in remove and a call to free_irq in probe failure.
Add the calls to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191118073633.28237-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Qualcomm DSPs also support the flac decoder, so add support for FLAC
decoder and convert the snd_dec_flac params to qdsp format.
Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20191115102705.649976-4-vkoul@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Qualcomm DSPs expect flac config to be set for flac decoders, so add the
API to program the flac config to the DSP
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20191115102705.649976-3-vkoul@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
dma_request_slave_channel_reason() is:
#define dma_request_slave_channel_reason(dev, name) \
dma_request_chan(dev, name)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191113095445.3211-3-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dma_request_slave_channel_reason() is:
#define dma_request_slave_channel_reason(dev, name) \
dma_request_chan(dev, name)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191113095445.3211-2-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_cleanup_card_resources() will call card->remove(), but it should be
called if card->probe() or card->late_probe() are called.
snd_soc_bind_card() might be error before calling
card->probe() / card->late_probe().
In that time, card->remove() will be called.
This patch adds card_probed parameter to judge it.
Fixes: bfce78a559 ("ASoC: soc-core: tidyup soc_init_dai_link()")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/87o8xg4ltr.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and it will be difficult to
debug.
snd_soc_bind_card() is calling snd_soc_dapm_init() for both
card and component.
Let's call paired snd_soc_dapm_shutdown() at paired
soc_cleanup_card_resources().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r22c4lub.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_bind_card() is calling many initialize functions
for each card / link / dai / aux etc, etc, etc...
When error happen, the message is indicated at snd_soc_bind_card(),
not at each functions.
But, only soc_probe_aux_devices() case is indicating error at functions,
not at snd_soc_bind_card().
It is not an issue, but unbalanced.
This patch moves error message to snd_soc_bind_card().
Also avoids deep-nested code.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87lfsthkw9.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
having both soc_bind_card() and snd_soc_instantiate_card() is
very confusable. Let's merge these.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87mud9hkwj.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
having both soc_remove_component() and soc_cleanup_component() is
very confusable. Let's merge these.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87o8xphkwt.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't need to separete snd_soc_remove_dai_link() and
soc_unbind_dai_link() anymore. Let's merge these.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pni5hkx1.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't need to separete snd_soc_add_dai_link() and
soc_bind_dai_link() anymore. Let's merge these.
One note is that before this patch, it adds list (A)
eventhough if it had dai_link->ignore (1), or already bounded dai_link (2).
But I guess it is wrong. This patch also solve this issue.
/* BEFORE */
int soc_bind_dai_link(...)
{
...
(1) if (dai_link->ignore)
return 0;
(2) if (soc_is_dai_link_bound(...))
return 0;
...
}
int snd_soc_add_dai_link(...)
{
...
=> ret = soc_bind_dai_link(...);
=> if (ret < 0)
=> return ret;
(A) list_add_tail(&dai_link->list, &card->dai_link_list);
...
}
/* AFTER */
int snd_soc_add_dai_link(...)
{
...
(1) if (dai_link->ignore)
return 0;
(2) if (soc_is_dai_link_bound(...))
return 0;
...
(A) list_add_tail(&dai_link->list, &card->dai_link_list);
return 0;
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r22lhkx8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't need to separete snd_soc_unregister_dai() and
soc_del_dai() anymore. Let's merge these
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sgn1hkxg.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
