A lot of changes here for quite a quiet release in subsystem terms -
there's been a lot of fixes and cleanups all over the subsystem both
from generic work and from people working on specific drivers.
- More cleanup and consolidation work in the core and the generic card
drivers from Morimoto-san.
- Lots of cppcheck fixes for Pierre-Louis Brossart.
- New drivers for Freescale i.MX DMA over rpmsg, Mediatek MT6358
accessory detection, and Realtek RT1019, RT1316, RT711 and RT715.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmCGv4YACgkQJNaLcl1U
h9DwqAf/bSdRqMQLPAAzU/O79ztMRwSRcF14ygZceoqnNbohwqzeFTHweTK8NINj
dZsZiXK/NYDlcbBE3e5VcYr6g149L+1Xu6HZEY1CBUz7LOR8QaHUXAnJQHuXlv/D
J0EK5NBILR8jk9mpPd/c+dd3lo4liREWTOQKCcIuFI8M5V8CZqtoSfg6RK2qf3Oi
myC3+2pEqI4+h5GQRy5y7mxtFOn4w9kzp49P7EwD9SL9o4VGbsaORMeA+QaOe9PS
KLn6ZKSJ7lBcxvg5a1w4E4SwRC/GA0QY+n1YMNGfrfCm7PSdw4GSyovd9xQKwrvG
vhf+bYkzRBVRqvQP9pvrGGJY9DdDIA==
=A+NC
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.13
A lot of changes here for quite a quiet release in subsystem terms -
there's been a lot of fixes and cleanups all over the subsystem both
from generic work and from people working on specific drivers.
- More cleanup and consolidation work in the core and the generic card
drivers from Morimoto-san.
- Lots of cppcheck fixes for Pierre-Louis Brossart.
- New drivers for Freescale i.MX DMA over rpmsg, Mediatek MT6358
accessory detection, and Realtek RT1019, RT1316, RT711 and RT715.
audio-graph-card2 can reuse audio_graph_remove() / asoc_simple_remove().
This patch moves it to simple-card-utils.c.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87y2df3uby.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
audio-graph-card2 can reuse audio_graph_card_probe().
This patch moves it to simple-card-utils.c.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zgxv3uc4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On Tegra186 and later, the number of links can go up to 72, so bump the
maximum number of links to the next power of two (128).
Fixes: f2138aed23 ("ASoC: simple-card-utils: enable flexible CPU/Codec/Platform")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20210416071147.2149109-2-thierry.reding@gmail.com
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
simple-card / audio-graph can use clock as dai->clk or dai->sysclk.
These related information should be indicated at same position.
This patch tidyup it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h7kcwf8t.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current asoc_simple_canonicalize_cpu/platform() is assuming single CPU,
single Platform, but we want to support Multi support.
This patch is prepare for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87im4swf8y.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We shouldn't use dai_props->cpus/codecs/cpu_dai/codec_dai/codec_conf
directly, because these are array to supporting multi CPU/Codec/Platform.
This patch adds asoc_link_to_xxx() macro for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87k0p8wf9b.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now ALSA is supporting multi-CPU/Codec,
thus, we want to know number of CPU/Codec when debugging.
This patch indicates it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87lf9owf9g.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC is now supporting multi DAI, but, current
simple-card / audio-graph are assuming fixed single DAI.
Now, asoc_simple_parse_xxx() macro is assuming single DAI.
To support multi-CPU/Codec, this patch unpack asoc_simple_parse_xxx()
macro, and uses "&dai_link->cpus[i]" instead of "dai_link->cpus".
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pmz0wf9u.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC is now supporting multi DAI, but, current
simple-card / audio-graph are assuming fixed single DAI.
This patch uses for_each_prop_xxx() to support multi DAI.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1jgwf9y.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
li->dais is same as number of CPU + Codec,
li->conf is same as number of Codec when dummy-Codec.
li->dais/li->conf are no longer needed.
This patch removes these.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sg3wwfa3.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace ugly #if (!IS_ENABLED) by if (!IS_ENABLED), remove
cross-module dependencies and use classic mechanism to pass
information to the machine driver.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20210409220121.1542362-7-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We currently have an ugly way of handling the SOF nocodec mode, with
blatant violations between layers. To create the nocodec card, let's
add two new fields and the existing mach_params structure, that way
there will be no differences with regular cards.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20210409220121.1542362-3-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current simple-card / audio-graph creates 1xCPU + 1xCodec + 1xPlatform
for all dai_link, but some of them is not needed.
For example Platform is not needed for DPCM BE case.
Moreover, we can share snd-soc-dummy DAI for CPU-dummy / dummy-Codec
in DPCM.
This patch adds dummy DAI and share it when DPCM case,
I beliave it can contribute to reduce memory.
By this patch, CPU-dummy / dummy-CPU are set at asoc_simple_init_priv(),
thus, its settings are no longer needed at DPCM detecting timing
on simple-card / audio-graph.
Moreover, we can remove triky Platform settings code for DPCM BE,
because un-needed Platform is not created.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87tuoqod22.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current simple-card / audio-graph are assuming fixed
single-CPU/Codec/Platform.
This patch prepares multi-CPU/Codec/Platform support.
Note is that it is not yet full-multi-support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87v996od2c.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA control interface allows users to add arbitrary control elements
(called "user controls" or "user elements"), and its resource usage is
limited just by the max number of control sets (currently 32). This
limit, however, is quite loose: each allocation of control set may
have 1028 elements, and each element may have up to 512 bytes (ILP32) or
1024 bytes (LP64) of value data. Moreover, each control set may contain
the enum strings and TLV data, which can be up to 64kB and 128kB,
respectively. Totally, the whole memory consumption may go over 38MB --
it's quite large, and we'd rather like to reduce the size.
OTOH, there have been other requests even to increase the max number
of user elements; e.g. ALSA firewire stack require the more user
controls, hence we want to raise the bar, too.
For satisfying both requirements, this patch changes the management of
user controls: instead of setting the upper limit of the number of
user controls, we check the actual memory allocation size and set the
upper limit of the total allocation in bytes. As long as the memory
consumption stays below the limit, more user controls are allowed than
the current limit 32. At the same time, we set the lower limit (8MB)
as default than the current theoretical limit, in order to lower the
risk of DoS.
As a compromise for lowering the default limit, now the actual memory
limit is defined as a module option, 'max_user_ctl_alloc_size', so that
user can increase/decrease the limit if really needed, too.
Link: https://lore.kernel.org/r/s5htur3zl5e.wl-tiwai@suse.de
Co-developed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210408103149.40357-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patchset tries to resolve the diversity in the audio LED
control among the ALSA drivers. A new control layer registration
is introduced which allows to run additional operations on
top of the elementary ALSA sound controls.
A new control access group (three bits in the access flags)
was introduced to carry the LED group information for
the sound controls. The low-level sound drivers can just
mark those controls using this access group. This information
is not exported to the user space, but user space can
manage the LED sound control associations through sysfs
(last patch) per Mark's request. It makes things fully
configurable in the kernel and user space (UCM).
The actual state ('route') evaluation is really easy
(the minimal value check for all channels / controls / cards).
If there's more complicated logic for a given hardware,
the card driver may eventually export a new read-only
sound control for the LED group and do the logic itself.
The new LED trigger control code is completely separated
and possibly optional (there's no symbol dependency).
The full code separation allows eventually to move this
LED trigger control to the user space in future.
Actually it replaces the already present functionality
in the kernel space (HDA drivers) and allows a quick adoption
for the recent hardware (ASoC codecs including SoundWire).
snd_ctl_led 24576 0
The sound driver implementation is really easy:
1) call snd_ctl_led_request() when control LED layer should be
automatically activated
/ it calls module_request("snd-ctl-led") on demand /
2) mark all related kcontrols with
SNDRV_CTL_ELEM_ACCESS_SPK_LED or
SNDRV_CTL_ELEM_ACCESS_MIC_LED
Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmBjRuQOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9ZQw/6Ao2X1io4TVnyO/gO8HtwmnZ6TWcrLUlySaep
H6Suf0RHsOQO9VOaMcUarA3Wnz1vZ44qJ/fkdLTslnIPGSRJDUx15bbb+n2N6pQJ
gS7Umxy6n73rQyEoDjd3ZorvDGjFSVFpjM+RYjk/Ohq+yziz7nQ/SZuHPPeqm1GU
C5d9SxyXGdqlJJ6yFCHzbtjSmIey+l1TZ+j3rSSww/CzDKxB2l5J6JZAMUjVdL9b
J80Mcw0XLdG9iTtEnkUt3TwvLMcMl95UPeQHIkVQlwsRRb3BtHNIwJLPQ/n+Cou7
Hre3y2miUYHrNICEzMdMlpDzQBqu5wvpXgbgIV0CwAwCXPZBVWE1hVJ9gG0l+r1G
fy1a75OmEin4V9g8w+wNTWDEgjwAOkWhA67WVjpbvHtd6kEbISzt4JHFksG1rjU2
vXOIj2VBmQN6zHtxfcZqY8Ge4A7XGo7tAM/3NsUxin+2y7ZXI6sDvv+0esYmqrYr
9as/tD84L5LTrbUYewaUgEdauQXluQI1egRi7pSeg7hZyLeYYkmszk54Ra3zdlmM
m7Hr6u+Y/G7yeFdn/WdeG3VzdmxhC2ZFfk3gq0vneBS3WrATbf6nAORp2bwzGSz4
pUsVLSv+vhpZdSF+IxpUuMnsLkkbUCvFivXLjQ6irSWvp7uts1HWdRowdg7Pe2lC
FVbFRuA=
=1uM7
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmBkoFEACgkQJNaLcl1U
h9BqTgf5AUfR5NbQgJIUMtdMsuz+bthKGuPnpYhYzNUH0io9i3Sjpt0Mbw21dLp2
nXW+70BH0tJZBGR4DNGpmcpBLH5WPdOR9WIv4vCYy9Pr0uCGGKF/JkGeZAg7/llF
C3+yDfTnF0AvR+74xbf/LTjBPGja/08PED1ZC00NAkLhE3C0Pa/VQ0NaEtPUULWE
ZOWboF7hfQUeGzGPTqNp4Cy0/Pzokk6Fvl4kgfrxjNWO7ojIv9mCAvmYbusLW7NU
3Ph5VGsIuyMeorEoAVOFaBY2nrYG/mFZyzTNWJMgvF1MdeigMPNfbbffrUK0sn6k
e81zgWbwxboEujQ91/EZU7glIqtb6A==
=rr4V
-----END PGP SIGNATURE-----
Merge tag 'mute-led-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into asoc-5.13
ALSA: control - add generic LED API
This patchset tries to resolve the diversity in the audio LED
control among the ALSA drivers. A new control layer registration
is introduced which allows to run additional operations on
top of the elementary ALSA sound controls.
A new control access group (three bits in the access flags)
was introduced to carry the LED group information for
the sound controls. The low-level sound drivers can just
mark those controls using this access group. This information
is not exported to the user space, but user space can
manage the LED sound control associations through sysfs
(last patch) per Mark's request. It makes things fully
configurable in the kernel and user space (UCM).
The actual state ('route') evaluation is really easy
(the minimal value check for all channels / controls / cards).
If there's more complicated logic for a given hardware,
the card driver may eventually export a new read-only
sound control for the LED group and do the logic itself.
The new LED trigger control code is completely separated
and possibly optional (there's no symbol dependency).
The full code separation allows eventually to move this
LED trigger control to the user space in future.
Actually it replaces the already present functionality
in the kernel space (HDA drivers) and allows a quick adoption
for the recent hardware (ASoC codecs including SoundWire).
snd_ctl_led 24576 0
The sound driver implementation is really easy:
1) call snd_ctl_led_request() when control LED layer should be
automatically activated
/ it calls module_request("snd-ctl-led") on demand /
2) mark all related kcontrols with
SNDRV_CTL_ELEM_ACCESS_SPK_LED or
SNDRV_CTL_ELEM_ACCESS_MIC_LED
Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
simple-card / audio-graph are assuming single CPU/Codec/Platform on
dai_link. Because of it, it is difficult to support Multi-CPU/Codec.
This patch allocs CPU/Codec/Platform dai_link imformation
instead of using existing props information. It can update to
multi-CPU/Codec, but is still assuming single-CPU/Codec for now.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blb61tpv.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patchset tries to resolve the diversity in the audio LED
control among the ALSA drivers. A new control layer registration
is introduced which allows to run additional operations on
top of the elementary ALSA sound controls.
A new control access group (three bits in the access flags)
was introduced to carry the LED group information for
the sound controls. The low-level sound drivers can just
mark those controls using this access group. This information
is not exported to the user space, but user space can
manage the LED sound control associations through sysfs
(last patch) per Mark's request. It makes things fully
configurable in the kernel and user space (UCM).
The actual state ('route') evaluation is really easy
(the minimal value check for all channels / controls / cards).
If there's more complicated logic for a given hardware,
the card driver may eventually export a new read-only
sound control for the LED group and do the logic itself.
The new LED trigger control code is completely separated
and possibly optional (there's no symbol dependency).
The full code separation allows eventually to move this
LED trigger control to the user space in future.
Actually it replaces the already present functionality
in the kernel space (HDA drivers) and allows a quick adoption
for the recent hardware (ASoC codecs including SoundWire).
snd_ctl_led 24576 0
The sound driver implementation is really easy:
1) call snd_ctl_led_request() when control LED layer should be
automatically activated
/ it calls module_request("snd-ctl-led") on demand /
2) mark all related kcontrols with
SNDRV_CTL_ELEM_ACCESS_SPK_LED or
SNDRV_CTL_ELEM_ACCESS_MIC_LED
Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmBjRuQOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9ZQw/6Ao2X1io4TVnyO/gO8HtwmnZ6TWcrLUlySaep
H6Suf0RHsOQO9VOaMcUarA3Wnz1vZ44qJ/fkdLTslnIPGSRJDUx15bbb+n2N6pQJ
gS7Umxy6n73rQyEoDjd3ZorvDGjFSVFpjM+RYjk/Ohq+yziz7nQ/SZuHPPeqm1GU
C5d9SxyXGdqlJJ6yFCHzbtjSmIey+l1TZ+j3rSSww/CzDKxB2l5J6JZAMUjVdL9b
J80Mcw0XLdG9iTtEnkUt3TwvLMcMl95UPeQHIkVQlwsRRb3BtHNIwJLPQ/n+Cou7
Hre3y2miUYHrNICEzMdMlpDzQBqu5wvpXgbgIV0CwAwCXPZBVWE1hVJ9gG0l+r1G
fy1a75OmEin4V9g8w+wNTWDEgjwAOkWhA67WVjpbvHtd6kEbISzt4JHFksG1rjU2
vXOIj2VBmQN6zHtxfcZqY8Ge4A7XGo7tAM/3NsUxin+2y7ZXI6sDvv+0esYmqrYr
9as/tD84L5LTrbUYewaUgEdauQXluQI1egRi7pSeg7hZyLeYYkmszk54Ra3zdlmM
m7Hr6u+Y/G7yeFdn/WdeG3VzdmxhC2ZFfk3gq0vneBS3WrATbf6nAORp2bwzGSz4
pUsVLSv+vhpZdSF+IxpUuMnsLkkbUCvFivXLjQ6irSWvp7uts1HWdRowdg7Pe2lC
FVbFRuA=
=1uM7
-----END PGP SIGNATURE-----
Merge tag 'tags/mute-led-rework' into for-next
ALSA: control - add generic LED API
This patchset tries to resolve the diversity in the audio LED
control among the ALSA drivers. A new control layer registration
is introduced which allows to run additional operations on
top of the elementary ALSA sound controls.
A new control access group (three bits in the access flags)
was introduced to carry the LED group information for
the sound controls. The low-level sound drivers can just
mark those controls using this access group. This information
is not exported to the user space, but user space can
manage the LED sound control associations through sysfs
(last patch) per Mark's request. It makes things fully
configurable in the kernel and user space (UCM).
The actual state ('route') evaluation is really easy
(the minimal value check for all channels / controls / cards).
If there's more complicated logic for a given hardware,
the card driver may eventually export a new read-only
sound control for the LED group and do the logic itself.
The new LED trigger control code is completely separated
and possibly optional (there's no symbol dependency).
The full code separation allows eventually to move this
LED trigger control to the user space in future.
Actually it replaces the already present functionality
in the kernel space (HDA drivers) and allows a quick adoption
for the recent hardware (ASoC codecs including SoundWire).
snd_ctl_led 24576 0
The sound driver implementation is really easy:
1) call snd_ctl_led_request() when control LED layer should be
automatically activated
/ it calls module_request("snd-ctl-led") on demand /
2) mark all related kcontrols with
SNDRV_CTL_ELEM_ACCESS_SPK_LED or
SNDRV_CTL_ELEM_ACCESS_MIC_LED
Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent laptops have usually two LEDs assigned to reflect
the speaker and microphone mute state. This implementation
adds a tiny layer on top of the control API which calculates
the state for those LEDs using the driver callbacks.
Two new access flags are introduced to describe the controls
which affects the audio path settings (an easy code change
for drivers).
The LED resource can be shared with multiple sound cards with
this code. The user space controls may be added to the state
chain on demand, too.
This code should replace the LED code in the HDA driver and
add a possibility to easy extend the other drivers (ASoC
codecs etc.).
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210317172945.842280-4-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The layer registration allows to handle an extra functionality
on top of the control API. It can be used for the audio
LED control for example.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210317172945.842280-3-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This helper is required for the following generic LED mute
patch. The helper also simplifies some other functions.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210317172945.842280-2-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Asymmetric multiprocessor, there is Cortex-A core and Cortex-M core,
Linux is running on A core, RTOS is running on M core.
The audio hardware device can be controlled by Cortex-M device,
So audio playback/capture can be handled by M core.
Rpmsg is the interface for sending and receiving msg to and from M
core, that we can create a virtual sound on Cortex-A core side.
A core will tell the Cortex-M core sound format/rate/channel,
where is the data buffer, what is the period size, when to start,
when to stop and when suspend or resume happen, each of this behavior
there is defined rpmsg command.
Especially we designed the low power audio case, that is to
allocate a large buffer and fill the data, then Cortex-A core can go
to sleep mode, Cortex-M core continue to play the sound, when the
buffer is consumed, Cortex-M core will trigger the Cortex-A core to
wakeup to fill data.
changes in v5:
- remove unneeded property in binding doc and driver
- update binding doc according to Rob's comments.
- Fix link issue reported by kernel test robot
changes in v4:
- remove the sound card node, merge the property to cpu dai node
according to Rob's comments.
- sound card device will be registered by cpu dai driver.
- Fix do_div issue reported by kernel test robot
changes in v3:
- add local refcount for clk enablement in hw_params()
- update the document according Rob's comments
changes in v2:
- update codes and comments according to Mark's comments
Shengjiu Wang (6):
ASoC: soc-component: Add snd_soc_pcm_component_ack
ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg
ASoC: dt-bindings: fsl_rpmsg: Add binding doc for rpmsg audio device
ASoC: imx-audio-rpmsg: Add rpmsg_driver for audio channel
ASoC: imx-pcm-rpmsg: Add platform driver for audio base on rpmsg
ASoC: imx-rpmsg: Add machine driver for audio base on rpmsg
.../devicetree/bindings/sound/fsl,rpmsg.yaml | 108 +++
include/sound/soc-component.h | 3 +
sound/soc/fsl/Kconfig | 30 +
sound/soc/fsl/Makefile | 6 +
sound/soc/fsl/fsl_rpmsg.c | 279 ++++++
sound/soc/fsl/fsl_rpmsg.h | 35 +
sound/soc/fsl/imx-audio-rpmsg.c | 140 +++
sound/soc/fsl/imx-pcm-rpmsg.c | 918 ++++++++++++++++++
sound/soc/fsl/imx-pcm-rpmsg.h | 512 ++++++++++
sound/soc/fsl/imx-rpmsg.c | 150 +++
sound/soc/soc-component.c | 14 +
sound/soc/soc-pcm.c | 2 +
12 files changed, 2197 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
create mode 100644 sound/soc/fsl/fsl_rpmsg.c
create mode 100644 sound/soc/fsl/fsl_rpmsg.h
create mode 100644 sound/soc/fsl/imx-audio-rpmsg.c
create mode 100644 sound/soc/fsl/imx-pcm-rpmsg.c
create mode 100644 sound/soc/fsl/imx-pcm-rpmsg.h
create mode 100644 sound/soc/fsl/imx-rpmsg.c
--
2.27.0
snd_soc_fixup_dai_links_platform_name() is assuming it is single platform.
return error if multi platforms.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rc7aoo9.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current snd_soc_fixup_dai_links_platform_name() creates name first (A),
and checks setup target pointer (B), and set it (C).
We should check target pointer first IMO.
This patch exchange the order to (B) -> (A) -> (C).
int snd_soc_fixup_dai_links_platform_name(...)
{
...
/* set platform name for each dailink */
for_each_card_prelinks(card, i, dai_link) {
(A) name = devm_kstrdup(...);
if (!name)
return -ENOMEM;
(B) if (!dai_link->platforms)
return -EINVAL;
/* only single platform is supported for now */
(C) dai_link->platforms->name = name;
}
return 0;
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8735wnaoon.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We shouldn't use dai_link->cpus/codecs/platforms directly,
because these are array now to supporting multi CPU/Codec/Platform.
This patch adds asoc_link_to_xxx() macro for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kh3aopc.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add snd_soc_pcm_component_ack back, which can be used to get an
updated buffer pointer in the platform driver.
On Asymmetric multiprocessor, this pointer can be sent to Cortex-M
core for audio processing.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1615516725-4975-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper sof_dai_ssp_mclk to get the topology configured MCLK from a
pcm_runtime, return 0 if it is not available, and error if the dai type
is not SSP at the moment.
Export the helper for external use, e.g. from machine drivers.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210319124950.3853994-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When SND_HDA_PREALLOC_SIZE is set to 0, applications can request as much
memory as there is allowed. With value of AZX_MAX_BUF_SIZE it is 1GB per
stream, which is not realistic use case. Change it 4MB.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=201251#c322
Suggested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20210318160618.2504068-3-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
soc-pcm has very similar but different DPCM BE DAI stop operation at
1) dpcm_be_dai_startup() error case rollback
2) dpcm_be_dai_startup_unwind()
3) dpcm_be_dai_shutdown()
The differences are
1) for rollback
2) Doesn't check by snd_soc_dpcm_be_can_update() (Is this bug ?)
3) Do soc_pcm_hw_free() if it was not !OPENed and !HW_FREEed,
and call soc_pcm_close().
We can share same code by
1) hw_free is not needed. Needs last dpcm as rollback.
2) hw_free is not needed.
3) hw_free is needed.
This patch adds new dpcm_be_dai_stop() and share these 3.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a6rduoam.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
sound/soc/codecs/rt5645.c is the only user of the rt5645_platform_data,
move its definition to sound/soc/codecs/rt5645.c and remove the now
empty include/sound/rt5645.h file.
Note since the DMI quirk mechanism uses pointers to the
rt5645_platform_data struct we can NOT simply add its members to
the rt5645_priv struct and completely remove the struct.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210306230223.516566-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The pointer to of_phandle_args passed to snd_soc_get_dai_name() and
of_xlate_dai_name() implementations is not modified. Since it is being
used only to translate passed OF node to a DAI name, it should not be
modified, so mark it as const for correctness and safer code.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20210221153024.453583-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In January, Intel kbuild bot and Arnd Bergmann reported multiple
issues with randconfig. This patchset builds on Arnd's suggestions to
a) expose ACPI and PCI devices in separate modules, while sof-acpi-dev
and sof-pci-dev become helpers. This will result in minor changes
required for developers/testers, i.e. modprobe snd-sof-pci will no
longer result in a probe. The SOF CI was already updated to deal with
this module dependency change and introduction of new modules.
b) Fix SOF/SoundWire/DSP_config dependencies by moving the code
required to detect SoundWire presence in ACPI tables to sound/hda.
Link: https://lore.kernel.org/r/20210302003125.1178419-1-pierre-louis.bossart@linux.intel.com
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmA+Tc4OHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9r6w/9E/pkuOIX9qTTeuVhOk2uoODQeSd9JSNXMvoN
rm9oamjBrugBl/x0V5UAFVLO3AXGfDJTGJT71dF51RbODyj0ISim+Ve7/2ObggN6
LRGoiAL850KGYhaAsLxTm/7OI2gH/WYwMerRdrvrJRDXAFHW5U2zLpHuj9TaZSDE
LgpwJvQbSBNbMu72xix2/KuWUnh7UVVhT9guvi+wLJkC4F81FHO5btu5rWo/BGfW
ekWVKw4raLMfjx2Y1P3X5/veCTgPTMOQC2Z5nuB6o9btXPTRf3tTigJcnt2xlpVk
d0FtoFyn0blJ1rC3bkzAjTh3wiaLvSoz9Z8MPRoLECqk70Dtg6l1IQHmK7JCol0B
EHNcW4WKAbUpRfohBw2xahZU4KJddPsdWUwSWCcY3a6rwa6MGJ2Vc1Foy3uZ0kW5
uIvwuxtuZDDazLTSr2wXeD+lF3Y6fKU4DPbpEbcYrTV+K9F6jUiArAXRQ98CrxUe
MtiC2L5ll24XhxL4m5XO0DLBa0Rx+qlJ7ZoGq4iG6ekRZwC+Q6UEvjnIa5ZnnPBC
veV+0Z243/y0TBy+VoVOS1XxR3xjEYYErGms6A/WBSMEZAX7AhGmre4iusgNNSyU
bCIcIyjIuCLLAilwfS0siG87KYYFpEHOz+XFliM6qWDr+6cIbXmNrQhlsAVLoQ8G
BcBiIiA=
=ttBB
-----END PGP SIGNATURE-----
Merge tag 'tags/sound-sdw-kconfig-fixes' into for-linus
ALSA/ASoC/SOF/SoundWire: fix Kconfig issues
In January, Intel kbuild bot and Arnd Bergmann reported multiple
issues with randconfig. This patchset builds on Arnd's suggestions to
a) expose ACPI and PCI devices in separate modules, while sof-acpi-dev
and sof-pci-dev become helpers. This will result in minor changes
required for developers/testers, i.e. modprobe snd-sof-pci will no
longer result in a probe. The SOF CI was already updated to deal with
this module dependency change and introduction of new modules.
b) Fix SOF/SoundWire/DSP_config dependencies by moving the code
required to detect SoundWire presence in ACPI tables to sound/hda.
Link: https://lore.kernel.org/r/20210302003125.1178419-1-pierre-louis.bossart@linux.intel.com
To change the module dependencies and simplify Kconfigs, we need to
introduce new driver names (sof-audio-acpi-intel-byt and
sof-audio-acpi-intel-bdw), and move from an exact string match to a
partial one.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210302003125.1178419-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Multiple bug reports report issues with the SOF and SST drivers when
dealing with single microphone cases.
We currently read the DMIC array information unconditionally but we
don't check that the configuration type is actually a mic array.
When the DMIC link does not rely on a mic array configuration, the
recommendation is to check the format information to infer the maximum
number of channels, and map this to the number of microphones.
This leaves a potential for a mismatch between actual microphones
available in hardware and what the ACPI table contains, but we have no
other source of information.
Note that single microphone configurations can alternatively be
handled with a 'mic array' configuration along with a 'vendor-defined'
geometry.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201251
BugLink: https://github.com/thesofproject/linux/issues/2725
Fixes: 7a33ea70e1 ('ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210302000146.1177770-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Another quiet release in terms of features, though several of the
drivers got quite a bit of work and there were a lot of general changes
resulting from Morimoto-san's ongoing cleanup work.
- As ever, lots of hard work by Morimoto-san cleaning up the code and
making it more consistent.
- Many improvements in the Intel drivers including a wide range of
quirks and bug fixes.
- A KUnit testsuite for the topology code.
- Support for Ingenic JZ4760(B), Intel AlderLake-P, DT configured
nVidia cards, Qualcomm lpass-rx-macro and lpass-tx-macro
- Removal of obsolete SIRF prima/atlas, Txx9 and ZTE zx drivers.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmAtZ7cACgkQJNaLcl1U
h9DD5Af/eeERQ2uVOqtw0If+XL1xRYe6RewgDoNcO/l/5WxBLrBH6NbEf0OwNJeg
vzZAkUBtxmx6XiW2M/h+4ucW1OPcg5IzxIWTHfGDMlKIxzb0jgWugRnJ7sdTnOs3
c+QHnvuOT7QzZBviAIkc5uZ5thAImYF8zDyKoGF5llztmnBYymtgpnvnRNZGM0ou
76oUzSvkCFI2b0Yf6bpGok2nBVlOu82HSHOUKjXVWk+LAeiivlYGOEZpdIKEe3S8
u6atQJ29XRr52Yuc2z4xnFQTW1cIDlwj2Fk5x/z8hX+5nRhNSGuIv1l5m7TfBj3e
mCO9cltKZxly0NXysgekn95JHwwwkA==
=MJSb
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.12' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.12
Another quiet release in terms of features, though several of the
drivers got quite a bit of work and there were a lot of general changes
resulting from Morimoto-san's ongoing cleanup work.
- As ever, lots of hard work by Morimoto-san cleaning up the code and
making it more consistent.
- Many improvements in the Intel drivers including a wide range of
quirks and bug fixes.
- A KUnit testsuite for the topology code.
- Support for Ingenic JZ4760(B), Intel AlderLake-P, DT configured
nVidia cards, Qualcomm lpass-rx-macro and lpass-tx-macro
- Removal of obsolete SIRF prima/atlas, Txx9 and ZTE zx drivers.
Use explicit number to define elem_type enum instead of using
SOF_IPC_EXT_*.
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Karol Trzciński <karolx.trzcinski@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210208232149.58899-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The below patch series are to support Audio over HDMI.
The modification in this patch series shall allow I2S driver
to playback standard PCM format and IEC958 encoded format to
the ADV7511 HDMI chip.
ALSA IEC958 plugin will be used to compose the IEC958 format.
Existing hdmi-codec driver only support standard pcm format.
Support of IEC958 encoded format passdown from ALSA IEC958 plugin
is needed so that the IEC958 encoded data can be streamed to the
HDMI chip.
Sia Jee Heng (4):
ASoC: codec: hdmi-codec: Support IEC958 encoded PCM format
drm: bridge: adv7511: Support I2S IEC958 encoded PCM format
dt-bindings: sound: Intel, Keembay-i2s: Add hdmi-i2s compatible string
ASoC: Intel: KMB: Support IEC958 encoded PCM format
.../bindings/sound/intel,keembay-i2s.yaml | 1 +
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 +
.../gpu/drm/bridge/adv7511/adv7511_audio.c | 6 ++
include/sound/hdmi-codec.h | 5 ++
sound/soc/codecs/hdmi-codec.c | 4 +-
sound/soc/intel/keembay/kmb_platform.c | 73 ++++++++++++++++++-
sound/soc/intel/keembay/kmb_platform.h | 1 +
7 files changed, 89 insertions(+), 2 deletions(-)
base-commit: 2557c711b87cd42bb22be9ca6ff3fce038624f30
--
2.18.0
The extended HDA bus (hdac_ext) provides interfaces for more
fine-grained control of individual links than what plain HDA
provides for. Links can be powered off when they are not used and if
all links are released, controller can shut down the command DMA.
These interfaces are currently not used by common HDA codec drivers.
When a HDA codec is runtime suspended, it calls snd_hdac_codec_link_down(),
but there is no link to the HDA extended bus, and on controller side
the links are shut down only when all codecs are suspended.
This patch adds link_power() to hdac_bus ops. Controllers using the HDA
extended core, can use this to plug in snd_hdac_ext_bus_link_power() to
implement more fine-grained control of link power.
No change is needed for plain HDA controllers nor to existing HDA
codec drivers.
Co-developed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210205184630.1938761-2-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Existing hdmi-codec driver only support standard pcm format.
Support of IEC958 encoded format pass from ALSA IEC958 plugin is needed
so that the IEC958 encoded data can be streamed to the HDMI chip.
Signed-off-by: Sia Jee Heng <jee.heng.sia@intel.com>
Link: https://lore.kernel.org/r/20210204014258.10197-2-jee.heng.sia@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Following functions are renamed for a better global visibility.
graph_card_probe() --> audio_graph_card_probe()
graph_parse_of() --> audio_graph_parse_of()
graph_remove() --> audio_graph_remove() [exported as well]
The references of these are updated in audio graph and Tegra audio
graph card drivers.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/1612719418-5858-2-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The commit e7bbb7acab ("dmaengine: add peripheral configuration")
adds peripheral configuration for dma_slave_config.
This configuration is useful for some audio peripherals, for
example, the peripheral supports multi fifos, we can
let the DMA know which fifos are selected. So also add
this configuration for snd_dmaengine_dai_dma_data.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1612509985-11063-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
