Improve the DPCM BE search debug output to make it easier to debug
issues in topologies.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit fbb16563c6 ("ASoC: snd_soc_component_driver has pmdown_time")
added new .pmdown_time which is for inverted version of current
.ignore_pmdown_time
But it is confusable name. Let's rename it to .use_pmdown_time
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
commit f523acebbb ("ASoC: add Component level pcm_new/pcm_free v2")
added component level pcm_new/pcm_free, but flush_delayed_work()
on soc_pcm_private_free() is called in for_each_rtdcom() loop.
It doesn't need to be called many times.
This patch moves it out of loop.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current snd_soc_runtime_ignore_pmdown_time() tallys all Codec and
CPU's "ignore_pmdown_time". Now, CPU (= via compoent)
ignore_pmdown_time is fixed as "true". Codec's one is copied from Codec
driver. This means Codec side default is "false".
Current all Codec driver will be replaced into Component, thus, we can
use for_each_rtdcom() for this totalization. This patch adds new
"pmdown_time" on Component driver. Its inverted value will be used
for this "ignore" totalizaton.
Of course all existing Component driver doesn't have its settings now,
thus, all existing "pmdown_time" is "false". This means all
Components will ignore pmdown time. This is current CPU behavior.
To keep compatibility, snd_soc_runtime_ignore_pmdown_time() totalize
Component's inverted "pmdown_time" (= total will be true) and
Codec's "ignore_pmdown_time" (= depends on Codec driver settings).
Because It is using AND operation, its result is based on Codec driver
settings only.
This means this operation can keep compatibility and doesn't have
nonconformity.
When we replace Codec to Component, the driver which has
".ignore_pmdown_time = true" will be just removed,
and the driver which doesn't have it will have new
".pmdown_time = true".
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Platform will be replaced into Component in the future.
snd_soc_platform_driver has snd_pcm_ops, but snd_soc_component_driver
doesn't have it. To prepare for replacing, this patch adds snd_pcm_ops
on component driver.
platform will be replaced into component, and its code will be removed.
But during replacing, both platform and component process code exists.
To keep compatibility, to avoid platform NULL access and to avoid
platform/component duplicate operation during replacing process, this
patch has such code. Some of this code will be removed when platform was
removed.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In current ALSA SoC, Platform only has pcm_new/pcm_free feature,
but it should be supported on Component level. This patch adds it.
The v1 was added commit 99b04f4c40 ("ASoC: add Component level
pcm_new/pcm_free") but it called all "card" connected component's
pcm_new/free, it was wrong.
This patch calls "rtd" connected component.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When ASoC driver is unbound dynamically during its operation (i.e. a
kind of hot-unplug), we may hit Oops due to the resource access after
the release by a delayed work, something like:
Unable to handle kernel paging request at virtual address dead000000000220
....
PC is at soc_dapm_dai_stream_event.isra.14+0x20/0xd0
LR is at snd_soc_dapm_stream_event+0x74/0xa8
....
[<ffff000008715610>] soc_dapm_dai_stream_event.isra.14+0x20/0xd0
[<ffff00000871989c>] snd_soc_dapm_stream_event+0x74/0xa8
[<ffff00000871b23c>] close_delayed_work+0x3c/0x50
[<ffff0000080bbd6c>] process_one_work+0x1ac/0x318
[<ffff0000080bbf20>] worker_thread+0x48/0x420
[<ffff0000080c201c>] kthread+0xfc/0x128
[<ffff0000080842f0>] ret_from_fork+0x10/0x18
For fixing the race, this patch adds a sync-point in pcm private_free
callback to finish the delayed work before actually releasing the
resources.
Reported-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Double NULL pointer check for ops and ops->func is difficult to read
and might be forget to check it if new func was add.
This patch adds new null_snd_soc_ops and use it if rtd->dai_link didn't
have it to avoid NULL ops, and reduces ops NULL check.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
On soc_add_dai(), it uses null_dai_ops if driver doesn't have
its own ops. This means, dai->driver->ops never been NULL.
dai->driver->ops check is not needed.
This patch removes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
hw_params may be fixup by be_hw_params_fixup, calling
soc_pcm_params_symmetry() before hw_params will have issue
if there is hw_params changes in be_hw_params_fixup.
For example, with following use case
1. a dai-link which is able to convert sample rate on BE side
2. set BE playback and capture sample rate to 44100Hz
3. play a 48000Hz audio stream with this dai-link
4. record from this dai-link with 44100Hz sample rate
Got following error message when record starts
[ 495.013527] be_link_ak4613: ASoC: unmatched rate symmetry: 48000 - 44100
[ 495.021729] be_link_ak4613: ASoC: hw_params BE failed -22
[ 495.028589] rsnd_link0: ASoC: hw_params BE failed -22
Because in soc_pcm_hw_params(), FE rate is still having value before
it is fixup by be_hw_params_fixup(), when soc_pcm_params_symmetry() checks
symmetry, thus soc_pcm_params_symmetry() complains about the unmatched rate
between the active stream and the new stream tries to start.
This patch moves soc_pcm_params_symmetry() after hw_params to resolve the
above issue.
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Basically, current ALSA SoC framework is based on CPU/Codec/Platform,
but its operation doesn't have consistent.
Thus, source code was unreadable, and difficult to understand.
This patch connects each component (= CPU/Codec/Platform) to rtd by
using snd_soc_rtdcom_add(), and convert uneven operations to consistent
operation.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
'debugfs_dpcm_state' member from structure snd_soc_pcm_runtime
is never used at all, so it is safe to remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit 99b04f4c40 ("ASoC: add Component level
pcm_new/pcm_free"), which started calling the pcm_new callback for every
component in a *card* when creating a new pcm, something which does not
seem to make any sense.
This specifically led to memory leaks in systems with more than one
platform component and where DMA memory is allocated in the
platform-driver callback. For example, when both mcasp devices are being
used on an am335x board, DMA memory would be allocated twice for every
DAI link during probe.
When CONFIG_SND_VERBOSE_PROCFS was set this fortunately also led to
warnings such as:
WARNING: CPU: 0 PID: 565 at ../fs/proc/generic.c:346 proc_register+0x110/0x154
proc_dir_entry 'sub0/prealloc' already registered
Since there seems to be no users of the new component callbacks, and the
current implementation introduced a regression, let's revert the
offending commit for now.
Fixes: 99b04f4c40 ("ASoC: add Component level pcm_new/pcm_free")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable <stable@vger.kernel.org> # 4.10
Multiple frontend dailinks may be connected to a backend
dailink at the same time. When one of frontend dailinks is
closed, the associated backend dailink should not be closed
if it is connected to other active frontend dailinks. Change
ensures that backend dailink is closed only after all
connected frontend dailinks are closed.
Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Now that all users of old copy and silence ops have been converted to
the new PCM ops, the old stuff can be retired and go away.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For supporting the explicit in-kernel copy of PCM buffer data, and
also for further code refactoring, three new PCM ops, copy_user,
copy_kernel and fill_silence, are introduced. The old copy and
silence ops will be deprecated and removed later once when all callers
are converted.
The copy_kernel ops is the new one, and it's supposed to transfer the
PCM data from the given kernel buffer to the hardware ring-buffer (or
vice-versa depending on the stream direction), while the copy_user ops
is equivalent with the former copy ops, to transfer the data from the
user-space buffer.
The major difference of the new copy_* and fill_silence ops from the
previous ops is that the new ops take bytes instead of frames for size
and position arguments. It has two merits: first, it allows the
callback implementation often simpler (just call directly memcpy() &
co), and second, it may unify the implementations of both interleaved
and non-interleaved cases, as we'll see in the later patch.
As of this stage, copy_kernel ops isn't referred yet, but only
copy_user is used.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
No one is using snd_soc_platform_trigger().
Let's remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
No existing platform is using .bespoke_trigger.
Let's remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
No existing platform is using .delay.
Let's remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When multiple front-ends are using the same back-end, putting state of a
front-end to STOP state upon receiving pause command will result in backend
stream getting released by DPCM framework unintentionally. In order to
avoid backend to be released when another active front-end stream is
present, put the stream state to PAUSED state instead of STOP state.
Signed-off-by: Patrick Lai <plai@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
In current ALSA SoC, Platform only has pcm_new/pcm_free feature,
but it should be supported on Component level. This patch adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
dpcm_state_string() returns a pointer to a string literal. Modifying a
string literal causes undefined behaviour. So make the return type of the
function const char * to make it explicit that the returned value should
not be modified.
This patch is purely cosmetic, none of the users of dpcm_state_string()
attempt to modify the returned content.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
When operating the BE, we should print out the dai_link name of BE other
than FE. This is useful when analyzing the kernel log.
Signed-off-by: Donglin Peng <pengdonglin@smartisan.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If be_hw_param_fixup is defined for BE then it will
force the BE to a specific configuration supported
by HW. In this case don't apply symmetry.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently in situations where a normal CODEC to CODEC link follows a
DPCM DAI, an error in the following form will be logged:
ASoC: can't get [playback|capture] BE for <widget name>
ASoC: no BE found for <widget name>
This happens because all widgets in a path containing a DPCM DAI will
be passed to dpcm_add_paths, which will try to interpret the CODEC<->CODEC
as if it were a DPCM DAI, in turn causing the error.
This patch aims to resolve the described issue by stopping the DPCM graph
walk, initiated from dpcm_path_get, at the first widget associated with
a DPCM BE.
Signed-off-by: Piotr Stankiewicz <piotrs@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Certain situations may warrant examining DAPM paths only to a certain
arbitrary point, as opposed to always following them to the end. For
instance, when establishing a connection between a front-end DAI link
and a back-end DAI link in a DPCM path, it does not make sense to walk
the DAPM graph beyond the first widget associated with a back-end link.
This patch introduces a mechanism which lets a user of
dai_get_connected_widgets supply a function which will be called for
every node during the graph walk. When invoked, this function can
execute arbitrary logic to decide whether the walk, given a DAPM widget
and walk direction, should be terminated at that point or continued
as normal.
Signed-off-by: Piotr Stankiewicz <piotrs@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
While performing hw_free, DPCM checks the BE state but leaves out
the suspend state. The suspend state needs to be checked as well,
as we might be suspended and then usermode closes rather than
resuming the audio stream.
This was found by a stress testing of system with playback in
loop and killed after few seconds running in background and second
script running suspend-resume test in loop
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Current DPCM doesn't copy dpcm->hw_params and doesn't call be_hw_params
if some FE are connected. But 2nd or later FE might want to know BE hw_params.
This patch solves this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If a device would like to use delayed suspending then PM
recommendation is to set ‘power.use_autosuspend’ flag. To allow
users to do so we need to change runtime calls in core to use
autosuspend counterparts.
For user who do not wish to use delayed suspend not setting the
device's ‘power.use_autosuspend’ flag will result in non-delayed
suspend even with these APIs which incidentally is also the default
behaviour, so only users will be impacted who opt in for this.
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DPCM does not fully support symmetry attributes. soc_pcm_apply_symmetry()
is skipped in soc_pcm_open() for DPCM, without being applied elsewhere.
So HW parameters cannot be correctly limited, and user space can do
playback/capture at different rates while HW actually does not support it.
soc_pcm_params_symmetry() will return error and the second stream stops.
This patch adds soc_pcm_apply_symmetry() for FE, BE, and codec DAIs
in DPCM path that was skipped in soc_pcm_open().
Signed-off-by: PC Liao <pc.liao@mediatek.com>
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the number of DAI links is statically defined by the machine
driver at build time using an array. This makes it difficult to shrink/
grow the number of DAI links at runtime in order to reflect any changes
in topology.
We can change the DAI link array in the core to a list so that PCMs and
FE DAI links can be added and deleted at runtime to reflect changes in
use case and DSP topology. The machine driver can still register DAI links
as an array.
As the 1st step, this patch change the PCM runtime array to a list. A new
PCM runtime is added to the list when a DAI link is bound successfully.
Later patches will further implement the DAI link list.
More:
- define snd_soc_new/free_pcm_runtime() to create/free a runtime.
- define soc_add_pcm_runtime() to add a runtime to the rtd list.
- define soc_remove_pcm_runtimes() to clean up the runtime list.
- traverse the rtd list to probe the link components and dais.
- Add a field "num" to PCM runtime struct, used to specify the device
number when creating the pcm device, and for a soc card to access
its dai_props array.
- The following 3rd party machine/platform drivers iterate the rtd list
to check the runtimes:
sound/soc/intel/atom/sst-mfld-platform-pcm.c
sound/soc/intel/boards/cht_bsw_rt5645.c
sound/soc/intel/boards/cht_bsw_rt5672.c
sound/soc/intel/boards/cht_bsw_max98090_ti.c
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
During suspend/resume, there is a flow that if a driver does not support
SNDRV_PCM_INFO_RESUME, it will fail at snd_pcm_resume(), and user space
can then issue SNDRV_PCM_IOCTL_PREPARE to let audio continue to play.
However, in dpcm_be_dai_prepare() it only allows BEs to be prepared
in state SND_SOC_DPCM_STATE_HW_PARAMS or SND_SOC_DPCM_STATE_STOP.
The BE state will then stay in SND_SOC_DPCM_STATE_SUSPEND, consequently
dpcm_be_dai_shutdown() is skipped in the end of playback and
be_substream->runtime is not cleared while this runtime is actually freed
by snd_pcm_detach_substream(). If another suspend comes, a NULL pointer
dereference will happen in snd_pcm_suspend() when accessing
BE substream's runtime.
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the new snd_pcm_hw_constraint_single() helper function instead of
calling snd_pcm_hw_constraint_minmax() with the same value for min and max
to install a constraint that limits the possible configuration values to a
single value. Using snd_pcm_hw_constraint_single() makes the indented
result clearer and is slightly shorter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the capability to use multiple codecs on the same DAI linke where
one codec is used for playback and another one is used for capture.
Tested on a setup using an SSM2518 for playback and an ICS43432 I2S MEMS
microphone for capture.
No verification is made that the playback and capture codec setups are
compatible in terms of number of TDM slots (where applicable).
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When running dapm_dai_get_connected_widgets() currently in
is_connected_{input,output}_ep() for each widget that gets added the array
is resized and the code also loops over all existing entries to avoid
adding a widget multiple times.
The former can be avoided by collecting the widgets in a linked list and
only once we have all widgets allocate the array.
The later can be avoided by changing when the widget is added. Currently it
is added when walking the neighbor lists of a widget. Since a widget can be
neighbors with multiple other widgets it could get added twice and hence
the check is necessary. But the main body of is_connected_{input,output}_ep
is guaranteed to be only executed at most once per widget. So adding the
widget to the list at the beginning of the function automatically makes
sure that each widget gets only added once. The only difference is that
using this method the starting point itself will also end up on the list,
but it can easily be skipped when creating the array.
Overall this reduces the code size and speeds things slightly up.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
In dpcm_get_be(), it looks for a BE rtd that has the DAI widget
according to current stream type. Only playback_widgets are searched
in the case of playback stream and vice versa. However, the DAI widget
itself can be playback or capture.
If the DAI widget is capture, but current stream type is playback,
dpcm_get_be() will always fail to find a rtd, print error messages,
and continue to the next DAI widget in list. We can just skip this
DAI widget to further suppress error messages. This happens in a
special case when 2 codecs are inter-connected, and the 1st codec's
"capture" widget is used to send data to the 2nd codec during "playback":
mtk-rt5650-rt5676 sound: ASoC: can't get playback BE for Sub AIF2 Capture
rt5650_rt5676 Playback: ASoC: no BE found for Sub AIF2 Capture
Add checks to continue to next DAI widget if current DAI widget's
direction does not match the stream type.
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current DPCM is caring only FE format. but it will be no sound
if FE/BE was below style, and user selects S24_LE format.
FE: S16_LE/S24_LE
BE: S16_LE
DPCM can rewrite the format, so basically we don't want to
constrain with the BE constraints. But sometimes it will be trouble.
This patch adds new .dpcm_merged_format on struct snd_soc_dai_link.
DPCM will use FE / BE merged format if .struct snd_soc_dai_link
has it. We can have other .dpcm_merged_xxx in the future
.dpcm_merged_foramt
.dpcm_merged_rate
.dpcm_merged_chan
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Keita Kobayashi <keita.kobayashi.ym@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If the registration of a debugfs directory fails this is treated as a
non-fatal error in ASoC and operation continues as normal. This means we
need to be careful and check if the parent debugfs directory exists if we
try to register a debugfs file or sub-directory. Otherwise we might end up
passing NULL for the parent and the file or directory will be registered in
the top-level debugfs directory.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
