Dragos Tarcatu [Mon, 11 Nov 2019 22:20:38 +0000 (16:20 -0600)]
ASoC: SOF: topology: free kcontrol memory on error
The volume and bytes kcontrols are currently not freeing their
memory on initialization failures. When an error occurs, all the
widgets loaded so far are unloaded via sof_widget_unload().
But this only happens for the widgets that got successfully loaded.
Fix that by kfree()-ing the allocated memory on load error.
Fixes: 311ce4fe7637d ("ASoC: SOF: Add support for loading topologies") Reviewed-by: Paul Olaru <paul.olaru@nxp.com> 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/20191111222039.19651-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Keyon Jie [Mon, 11 Nov 2019 22:33:43 +0000 (16:33 -0600)]
ASoC: SOF: PM: only suspend to D0I3 when needed
We should suspend audio to D3 by default, for the sake of power saving,
change the condition of D0I3 suspending here to that when there is
stream with suspend_ignored specified.
Keyon Jie [Mon, 11 Nov 2019 22:33:42 +0000 (16:33 -0600)]
ASoC: SOF: add helper to check if we should enter d0i3 suspend
Add helper to check if the DSP should be put in D0i3. This function
returns true if a stream has ignored the SUSPEND trigger to keep the
pipelines running in the DSP.
ASoC: SOF: Intel: hda: use fallback for firmware name
We have platforms such as CFL with no known I2S codec being used, and
the ACPI tables are currently empty, so fall-back to using the
firmware filename used in nocodec mode
ASoC: Intel: kbl_rt5663_rt5514_max98927: Add dmic format constraint
On KBL platform, the microphone is attached to external codec(rt5514)
instead of PCH. However, TDM slot between PCH and codec is 16 bits only.
In order to avoid setting wrong format, we should add a constraint to
force to use 16 bits format forever.
This commit adds the Dialog DA7213 audio codec as a selectable option
in the kernel config. Currently the driver can only be selected for
Intel Baytrail/Cherrytrail devices or if SND_SOC_ALL_CODECS is enabled.
Curtis Malainey [Wed, 6 Nov 2019 01:13:34 +0000 (17:13 -0800)]
ASoC: bdw-rt5677: Turn on MCLK1 for DSP via DAPM
The RT5677 DSP needs the I2S MCLK1 to run its DSP. Add a dapm route to
SSP0 CODEC IN so the clock is turned on automatically when the DSP is
turned on.
Curtis Malainey [Wed, 6 Nov 2019 01:13:33 +0000 (17:13 -0800)]
ASoC: rt5677: Allow VAD to be shut on/off at all times
Due to limitations of the clocking configuration, we have no way of
scheduling our hibernation before the bdw dsp hibernates. This causes
issues when the system suspends with an open stream. We need userspace
to toggle the kcontrol before we are suspended so that any writes on
suspend are not lost and we don't corrupt the regmap.
Ben Zhang [Wed, 6 Nov 2019 01:13:32 +0000 (17:13 -0800)]
ASoC: rt5677: Disable irq at suspend
The irq is disabled at suspend to avoid running the threaded irq
handler after the codec has been powered off. At resume, codec irq is
re-enabled and the interrupt status register is checked to see if
headphone has been pluggnd/unplugged while the device is suspended.
There is still a chance that the headphone gets enabled or disabled
after the codec is suspended. disable_irq syncs the threaded irq
handler, but soc-jack's threaded irq handler schedules a delayed
work to poll gpios (for debounce). This is still OK. The codec won't
be powered back on again because all audio paths have been suspended,
and there are no force enabled supply widgets (MICBIAS1 is disabled).
The gpio status read after codec power off could be wrong, so the
gpio values are checked again after resume.
Ben Zhang [Wed, 6 Nov 2019 01:13:31 +0000 (17:13 -0800)]
ASoC: rt5677: Stop and restart DSP over suspend/resume
MCLK1 gets disabled at suspend and re-enabled at resume. Before
MCLK1 is re-enabled, if the DSP is already on (either the DSP was
left on during suspend, or the DSP is turned on early at resume),
i2c register read returns garbage and corrupts the regmap cache.
This patch stops the DSP before suspend and restarts it after
resume with a dalay to ensure MCLK is on while loading firmware.
Ben Zhang [Wed, 6 Nov 2019 01:13:30 +0000 (17:13 -0800)]
ASoC: rt5677: Mark reg RT5677_PWR_ANLG2 as volatile
The codec dies when RT5677_PWR_ANLG2(MX-64h) is set to 0xACE1
while it's streaming audio over SPI. The DSP firmware turns
on PLL2 (MX-64 bit 8) when SPI streaming starts. However regmap
does not believe that register can change by itself. When
BST1 (bit 15) is turned on with regmap_update_bits(), it doesn't
read the register first before write, so PLL2 power bit is
cleared by accident.
Marking MX-64h as volatile in regmap solved the issue.
Ben Zhang [Wed, 6 Nov 2019 01:13:28 +0000 (17:13 -0800)]
ASoC: rt5677: Enable jack detect while DSP is running
Before a hotword is detected, GPIO1 pin is configured as IRQ
output so that jack detect works. When a hotword is detected,
the DSP firmware configures the GPIO1 pin as GPIO1 and
drives a 1. rt5677_irq() is called after a rising edge on
the GPIO1 pin, due to either jack detect event or hotword
event, or both. All possible events are checked and handled
in rt5677_irq() where GPIO1 pin is configured back to IRQ
output if a hotword is detected.
Ben Zhang [Wed, 6 Nov 2019 01:13:26 +0000 (17:13 -0800)]
ASoC: rt5677: Load firmware via SPI using delayed work
The firmware rt5677_elf_vad is an ELF binary obtained from
request_firmware(). Sections of the ELF are loaded to
the DSP via SPI. A model (e.g. en_us.mmap) can optionally be
loaded to the DSP at RT5677_MODEL_ADDR to overwrite the
baked-in model in rt5677_elf_vad.
Then we switch to DSP mode, load firmware, and let DSP run.
When a hotword is detected, an interrupt is fired and
rt5677_irq() is called. When 'DSP VAD Switch' is turned off,
the codec is set back to normal mode.
The kcontrol 'DSP VAD Switch' is automatically enabled/disabled
when the hotwording PCM stream is opened/closed.
Shengjiu Wang [Mon, 11 Nov 2019 07:50:48 +0000 (15:50 +0800)]
ASoC: fsl_audmix: Add spin lock to protect tdms
Audmix support two substream, When two substream start
to run, the trigger function may be called by two substream
in same time, that the priv->tdms may be updated wrongly.
The expected priv->tdms is 0x3, but sometimes the
result is 0x2, or 0x1.
Dragos Tarcatu [Wed, 6 Nov 2019 14:58:16 +0000 (08:58 -0600)]
ASoC: SOF: topology: Fix bytes control size checks
When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:
[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411
Fix that by rejecting the topology if the bytes data size > max_size
Fixes: 311ce4fe7637d ("ASoC: SOF: Add support for loading topologies") Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com> 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/20191106145816.9367-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: fixup dead-lock at snd_soc_unregister_component()
snd_soc_unregister_component() is calling snd_soc_lookup_component()
under mutex_lock(). But, snd_soc_lookup_component() itself is using
mutex_lock(), thus it will be dead-lock.
This patch adds _nolocked version of it, and avoid dead-lock issue.
Fixes: ac6a4dd3e9f0("ASoC: soc-core: use snd_soc_lookup_component() at snd_soc_unregister_component()") Reported-by: "kernelci.org bot" <bot@kernelci.org>" Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87bltph4da.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Dragos Tarcatu [Wed, 6 Nov 2019 14:58:16 +0000 (08:58 -0600)]
ASoC: SOF: topology: Fix bytes control size checks
When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:
[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411
Fix that by rejecting the topology if the bytes data size > max_size
Fixes: 311ce4fe7637d ("ASoC: SOF: Add support for loading topologies") Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com> 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/20191106145816.9367-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: remove topology specific operation
soc-core has some API which is used from topology, but it is doing
topology specific operation at soc-core.
soc-core should care about core things, and topology should care
about topology things, otherwise, it is very confusable.
For example topology type is not related to soc-core,
it is topology side issue.
This patch removes meaningless check from soc-core.
This patch keeps extra initialization/destruction at
snd_soc_add_dai_link() / snd_soc_remove_dai_link()
which were for topology.
From this patch, non-topology card can use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87pni6251h.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: call snd_soc_register_dai() from snd_soc_register_dais()
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
This patch calls snd_soc_register_dai() from snd_soc_register_dais()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87r22m251l.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: don't call snd_soc_dapm_new_dai_widgets() at snd_soc_register_dai()
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
snd_soc_register_dai() is now used from topology.
But to reduce duplicated code, it should be used from _dais(), too.
Because of topology side specific reason,
it is calling snd_soc_dapm_new_dai_widgets(),
but it is not needed _dais() side.
This patch factorizes snd_soc_register_dai() to
topology / _dais() common part, and topology specific part.
And do topology specific part at soc-topology.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87sgn2251p.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: have legacy_dai_naming at snd_soc_register_dai()
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
snd_soc_register_dai() is now used from topology.
But to reduce duplicated code, it should be used from _dais(), too.
To prepare it, this patch adds missing parameter legacy_dai_naming
to snd_soc_register_dai().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87tv7i251u.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 is difficult to debug.
This patch adds missing soc_del_dai() and snd_soc_unregister_dai().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87v9ry251z.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: use snd_soc_lookup_component() at snd_soc_unregister_component()
snd_soc_unregister_component() is now finding component manually,
but we already have snd_soc_lookup_component() to find component;
Let's use existing function.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87zhha252c.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
soc-core has
snd_soc_add_component(), snd_soc_component_add(),
snd_soc_del_component(), snd_soc_component_del().
These are very confusing naming.
snd_soc_component_xxx() are called from snd_soc_xxx_component(),
and these are very small.
Let's merge these into snd_soc_xxx_component(), and
remove snd_soc_component_xxx().
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 is difficult to debug.
Now ALSA SoC has snd_soc_add_component(), but there is no paired
snd_soc_del_component(). Thus, snd_soc_unregister_component() is
calling cleanup function randomly. it is difficult to read.
This patch adds missing snd_soc_del_component_unlocked() and
balance up code.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/8736f23jn4.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.
ALSA SoC has soc_bind_dai_link(), but its paired soc_unbind_dai_link()
is not implemented.
More confusable is that soc_remove_pcm_runtimes() which should be
soc_unbind_dai_link() is implemented without synchronised
to soc_bind_dai_link().
This patch cleanup this unbalance.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/877e4e3jni.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: soc-core: call soc_bind_dai_link() under snd_soc_add_dai_link()
If we focus to soc_bind_dai_link() at snd_soc_instantiate_card(),
we will notice very complex operation.
static int snd_soc_instantiate_card(...)
{
...
/*
* (1) Bind dai_link via card pre-linked dai_link
*
* Bind dai_link via card pre-linked.
* 1 dai_link will be 1 rtd, and connected to card.
* for_each_card_prelinks() is for card pre-linked dai_link.
*
* Image
*
* card
* - rtd(A)
* - rtd(A)
*/
for_each_card_prelinks(card, i, dai_link) {
ret = soc_bind_dai_link(card, dai_link);
...
}
...
/*
* (2) Connect card pre-linked dai_link to card list
*
* Connect all card pre-linked dai_link to *card list*.
* Here, (A) means from card pre-linked.
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
*/
for_each_card_prelinks(card, i, dai_link) {
ret = snd_soc_add_dai_link(card, dai_link);
...
}
...
/*
* (3) Probe binded component
*
* Each rtd has many components.
* Here probes each rtd connected components.
* rtd(A) in Image is the probe target.
*
* During this component probe, topology may add new dai_link to
* *card list* by using snd_soc_add_dai_link() which is
* used at (2).
* Here, (B) means from topology
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
* - dai_link(B)
* - dai_link(B)
*/
ret = soc_probe_link_components(card);
...
/*
* (4) Bind dai_link again
*
* Bind dai_link again for topology.
* Note, (1) used for_each_card_prelinks(),
* here is using for_each_card_links()
*
* This means from card list.
* As Image indicating, it has dai_link(A) (from card pre-link)
* and dai_link(B) (from topology).
* main target here is dai_link(B).
* soc_bind_dai_link() ignores already used
* dai_link (= dai_link(A))
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
* - rtd(B) - dai_link(B)
* - rtd(B) - dai_link(B)
*/
for_each_card_links(card, dai_link) {
ret = soc_bind_dai_link(card, dai_link);
...
}
...
}
As you see above, it is doing very complex method.
The problem is binding dai_link via "card pre-linked" (= (1)) and
"topology added dai_link" (= (3)) are separated.
The code can be simple if we can bind dai_link when dai_link
is connected to *card list*.
This patch do it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/878sou3jnn.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
soc_is_dai_link_bound() check will be called both
*before* soc_bind_dai_link() (A), and
*under* soc_bind_dai_link() (B).
These are very verbose code. Let's remove one of them.
* static int soc_bind_dai_link(...)
{
...
(B) if (soc_is_dai_link_bound(...)) {
...
return 0;
}
...
}
static int snd_soc_instantiate_card(...)
{
...
for_each_card_links(...) {
(A) if (soc_is_dai_link_bound(...))
continue;
* ret = soc_bind_dai_link(...);
if (ret)
goto probe_end;
}
...
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87a79a3jns.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Maxime Ripard [Tue, 5 Nov 2019 10:56:15 +0000 (11:56 +0100)]
ASoC: adau7118: Fix example warning
The ADAU7118 has an example where the codec has an i2c address of 14, and
the unit address set to 14 as well.
However, while the address is expressed in decimal, the unit-address is
supposed to be in hexadecimal, which ends up with two different addresses
that trigger a DTC warning. Fix this by setting the address to 0x14.
Cc: Nuno Sá <nuno.sa@analog.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Fixes: 969d49b2cdc8 ("dt-bindings: asoc: Add ADAU7118 documentation") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191105105615.21391-1-maxime@cerno.tech Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: topology: set trigger order for FE DAI link
Set trigger order for FE DAI links to SND_SOC_DPCM_TRIGGER_POST
to trigger the BE DAI's before the FE DAI's. This prevents the
xruns seen on playback pipelines using the link DMA.
ASoC: pcm: update FE/BE trigger order based on the command
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
This option is only required with the Skylake platform driver, there
is no reason to have this option in machine drivers. This is
e.g. useless for SOF-based solutions.
updated solution to the problem reported with randconfig:
CONFIG_SND_SOC_SOF_IMX depends on CONFIG_SND_SOC_SOF, but is in
turn referenced by the sof-of-dev driver. This creates a reverse
dependency that manifests in a link error when CONFIG_SND_SOC_SOF_OF
is built-in but CONFIG_SND_SOC_SOF_IMX=m:
sound/soc/sof/sof-of-dev.o:(.data+0x118): undefined reference to `sof_imx8_ops'
use def_trisate to propagate the right settings without select.
ASoC: SOF: Kconfig: add EXPERT dependency for developer options, clarify help
Some distros select all possible options, despite existing warnings to
be careful. This leads to e.g. user reports that the HDaudio codec and
DMIC are not handled by SOF.
Add an explicit menu item to unlock developer options, and make them
dependent on CONFIG_EXPERT. Hopefully with this double-lock these
options will only be selected by developers.
ASoC: SOF: Intel: Broadwell: clarify mutual exclusion with legacy driver
Some distros select all options blindly, which leads to confusion and
bug reports. SOF does not fully support Broadwell due to firmware
dependencies, the machine drivers can only support one option, and
UCM/topology files are still being propagated to downstream distros,
so make SOF on Broadwell an opt-in option that first require distros
to opt-out of existing defaults.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204237 Fixes: f35bf70f61d3 ('ASoC: Intel: Make sure BDW based machine drivers build for SOF') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101173045.27099-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Intel: Baytrail: clarify mutual exclusion with Atom/SST driver
Some distros select all options blindly, which leads to confusion and
bug reports. Since SOF does not support Baytrail-CR for now, and
UCM/topology files are still being propagated to downstream distros,
make SOF on Baytrail an opt-in option that first require distros to
opt-out of existing defaults.
Naveen Manohar [Fri, 1 Nov 2019 17:18:47 +0000 (12:18 -0500)]
ASoC: Intel: boards: Add CML m/c using RT1011 and RT5682
Machine driver to enable
RT5682 on SSP0, DMIC, HDMI and
RT1011 AMP on SSP1 with
2 CH / 24 bit TDM Playback over 4 individual codecs and
4 CH / 24 bit Capture to provide feedback.
Signed-off-by: Naveen Manohar <naveen.m@intel.com> Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191101171847.26767-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Kai Vehmanen [Fri, 1 Nov 2019 17:06:35 +0000 (12:06 -0500)]
ASoC: hdac_hda: fix race in device removal
When ASoC card instance is removed containing a HDA codec,
hdac_hda_codec_remove() may run in parallel with codec resume.
This will cause problems if the HDA link is freed with
snd_hdac_ext_bus_link_put() while the codec is still in
middle of its resume process.
To fix this, change the order such that pm_runtime_disable()
is called before the link is freed. This will ensure any
pending runtime PM action is completed before proceeding
to free the link.
This issue can be easily hit with e.g. SOF driver by loading and
unloading the drivers.
Shuming Fan [Wed, 30 Oct 2019 08:55:33 +0000 (16:55 +0800)]
ASoC: rt5682: improve the sensitivity of push button
The sensitivity could improve by decreasing the HW debounce time
and reduce the delay time of workequeue.
This patch added a device property for HW debounce time control.
We could change this value to tune the sensitivity of push button.
snd_soc_tplg_component_remove() is pair of snd_soc_tplg_component_load(),
and it is topology related cleanup function.
The driver which called _load() needs to call _remove() by its responsibility.
Today, skl-pcm and topology are the user, and these are calling both
_load() and _remove().
soc-core doesn't need to call it.
This patch remove it.
Kai Vehmanen [Tue, 29 Oct 2019 13:40:13 +0000 (15:40 +0200)]
ASoC: SOF: Intel: add support for snd-hda-codec-hdmi
Add support to implement HDMI/DP audio by using the common
snd-hda-codec-hdmi driver.
Change of codec driver affects user-space as the two
drivers expose different mixer controls. A new kernel
module option "use_common_hdmi" is added to user-space
to indicate which interface should be used. The default
driver can be selected via a Kconfig option.
Kai Vehmanen [Tue, 29 Oct 2019 13:40:12 +0000 (15:40 +0200)]
ASoC: Intel: skl-hda-dsp-generic: fix include guard name
Match the include guard define to actual filename. The source
directory now has an actual hda_dsp_common.h header, so the old
include guard may cause confusion.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191029134017.18901-5-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Kai Vehmanen [Tue, 29 Oct 2019 13:40:11 +0000 (15:40 +0200)]
ASoC: Intel: skl-hda-dsp-generic: use snd-hda-codec-hdmi
Add support for using snd-hda-codec-hdmi driver for HDMI/DP
instead of ASoC hdac-hdmi. This is aligned with how other
HDA codecs are already handled.
When snd-hda-codec-hdmi is used, the PCM device numbers are
parsed from card topology and passed to the codec driver.
This needs to be done at runtime as topology changes may
affect PCM device allocation.
Kai Vehmanen [Tue, 29 Oct 2019 13:40:09 +0000 (15:40 +0200)]
ALSA: hda/hdmi - implement mst_no_extra_pcms flag
To support the DP-MST multiple streams via single connector feature,
the HDMI driver was extended with the concept of backup PCMs. See
commit 9152085defb6 ("ALSA: hda - add DP MST audio support").
This implementation works fine with snd_hda_intel.c as PCM topology
is fully managed within the single driver.
When the HDA codec driver is used from ASoC components, the concept
of backup PCMs no longer fits. For ASoC topologies, the physical
HDMI converters are presented as backend DAIs and these should match
with hardware capabilities. The ASoC topology may define arbitrary
PCMs (i.e. frontend DAIs) and have processing elements before eventual
routing to the HDMI BE DAIs. With backup PCMs, the link between
FE and BE DAIs would become dynamic and change when monitors are
(un)plugged. This would lead to modifying the topology every time
hotplug events happen, which is not currently possible in ASoC and
there does not seem to be any obvious benefits from this design.
To overcome above problems and enable the HDMI driver to be used
from ASoC, this patch adds a new mode (mst_no_extra_pcms flags) to
patch_hdmi.c. In this mode, the codec driver does not assume
the backup PCMs to be created.
Cheng-Yi Chiang [Mon, 28 Oct 2019 07:19:27 +0000 (15:19 +0800)]
ASoC: rockchip_max98090: Optionally support HDMI use case
Support three different use cases with rockchip_max98090 driver.
The three use cases:
- max98090 only: Current usage, where HDMI link is missing.
- HDMI only: Needed use case for veyron_mickey board.
- max98090 + HDMI: Ideal use case for veyron_jerry, veyron_minnie..etc.
The presence of max98090 is determined by the presence of
rockchip,audio-codec device property.
The presence of HDMI is determined by the presence of
rockchip,hdmi-codec device property.
Create different sound card based on the configuration.
Note that we keep max98090 only usage for backward compatibility.
Cheng-Yi Chiang [Mon, 28 Oct 2019 07:19:26 +0000 (15:19 +0800)]
ASoC: rockchip-max98090: Support usage with and without HDMI
Add one optional property "rockchip,hdmi-codec" to let user specify HDMI
device node in DTS so machine driver can find hdmi-codec device node for
HDMI codec DAI.
Use the presence of rockchip,audio-codec and rockchip,hdmi-codec to
specify the use case.
Use max98090 only : specify rockchip,audio-codec.
Use HDMI only: specify rockchip,hdmi-codec.
Use both max98090 and HDMI: specify rockchip,audio-codec and
rockchip,hdmi-codec.
Move these properties to optional because they are not needed for
HDMI-only use case.
"rockchip,audio-codec": The phandle of the MAX98090 audio codec
"rockchip,headset-codec": The phandle of Ext chip for jack detection
Jaroslav Kysela [Mon, 28 Oct 2019 17:33:29 +0000 (18:33 +0100)]
ASoC: SOF - remove the dead code (skylake/kabylake)
Appearently the CONFIG_SND_SOC_SOF_KABYLAKE and CONFIG_SND_SOC_SOF_SKYLAKE
options are not present in Kconfig and 'struct snd_sof_dsp_ops sof_skl_ops'
is not declared in the code, too.
Signed-off-by: Jaroslav Kysela <perex@perex.cz> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20191028173329.29538-1-perex@perex.cz Signed-off-by: Mark Brown <broonie@kernel.org>
Jaroslav Kysela [Mon, 28 Oct 2019 16:46:24 +0000 (17:46 +0100)]
ASoC: intel - fix the card names
Those strings are exposed to the user space as the
card name thus used in the GUIs. The common
standard is to avoid '_' here. The worst case
is 'sof-skl_hda_card' string.
Signed-off-by: Jaroslav Kysela <perex@perex.cz> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191028164624.14334-1-perex@perex.cz Signed-off-by: Mark Brown <broonie@kernel.org>
Keyon Jie [Fri, 25 Oct 2019 22:41:21 +0000 (17:41 -0500)]
ASoC: SOF: PM: Add support for DSP D0i3 state when entering S0ix
When system is entering into S0ix, the PCI device may transition to the
D0i3 substate instead of D3. In D0i3, some always-on functionality can
be enabled, such as acoustic event detection, voice activity detection
or hotwording. When an event is detected, the DSP firmware can wake-up
the device for a transition to D0 with an interrupt.
Keyon Jie [Fri, 25 Oct 2019 22:41:18 +0000 (17:41 -0500)]
ASoC: SOF: ignore suspend/resume for D0ix compatible streams
During system suspend, the PM framework will freeze all applications and
the ALSA/ASoC core will suspend all RUNNING PCM streams.
However, D0ix-compatible PCM streams should keep the related pipelines
active in the DSP when the system is entering S0ix. The TRIGGER_SUSPEND
event is trapped in such cases to prevent the pipelines from being
stopped. Likewise, the TRIGGER_RESUME/START events should not affect the
pipeline state.
The SOF driver also triggers some DSP Firmware pipelines based on the
DAPM widgets power events. In such cases, we also ignore PRE_PMU and
POST_PMD events to keep the pipelines active.
projects / linux.git / log