- 17 Dec, 2021 2 commits
-
-
Ranjani Sridharan authored
The SOF driver removed the support for INFO_RESUME in the commit "ASoC: SOF: pcm: do not add SNDRV_PCM_INFO_RESUME to runtime hw info". And resuming is handled by the ALSA core with the .prepare and .trigger_start stages. So, remove handling of RESUME trigger in the HDA DAI BE trigger op. Reviewed-by:
Kai Vehmanen <kai.vehmanen@intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211216231628.344687-3-pierre-louis.bossart@linux.intel.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
The SOF driver removed the support for INFO_RESUME in the commit "ASoC: SOF: pcm: do not add SNDRV_PCM_INFO_RESUME to runtime hw info". And resuming is handled by the ALSA core with the .prepare and .trigger_start stages. So, remove handling of RESUME trigger in the component driver trigger op. Reviewed-by:
-
- 16 Dec, 2021 1 commit
-
-
Mark Brown authored
Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>: This set of patches deals with modifications to the signature of kcontrol get/set data functions to make them more intuitive. The last patch deals with initializing the binary control data size after boot up.
-
- 15 Dec, 2021 13 commits
-
-
Pierre-Louis Bossart authored
on i386 or x86_64: when # CONFIG_ACPI is not set, so SND_SOC_ACPI is not set: WARNING: unmet direct dependencies detected for SND_AMD_ACP_CONFIG Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_ACPI [=n] Selected by [y]: - SND_SOC_AMD_ACP_COMMON [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && X86 [=y] && PCI [=y] This problem is due to the unconditional selection of SND_AMD_ACP_CONFIG in other options. Using 'depends on' solved an initial problem but exposed another, let's use select instead. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Fixes: d9b994cd ('ASoC: AMD: acp-config: fix missing dependency on SND_SOC_ACPI') Signed-off-by:
Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@intel.com> Reviewed-by:
Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Link: https://lore.kernel.org/r/20211215163511.151286-1-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
David Heidelberg authored
Convert Tegra audio complex with the * ALC5632 * MAX98090 * RT5640 * RT5677 * SGTL5000 * TrimSlice * WM8753 * WM8903 * WM9712 codec to the YAML format. Additional changes: - added missing HPOUTL to the WM9712 codec. - extended rt5677 codec with multiple pins Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
David Heidelberg <david@ixit.cz> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211211224946.79875-1-david@ixit.czSigned-off-by:
-
Ranjani Sridharan authored
Read back the control data from the DSP to initialize the control data size to match that of the data in the DSP. This is particularly useful for volatile read-only kcontrols in static pipelines. Signed-off-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20211215180404.53254-9-ranjani.sridharan@linux.intel.comSigned-off-by:
-
Peter Ujfalusi authored
The SOF_CTRL_TYPE_VALUE_COMP_* type is not used by the firmware nor in the kernel side. It is also not clear what action should be taken for such type. With this in mind: The correct ipc_cmd can be selected based on the `ctrl_cmd` and the `set` parameters: if the ctrl_cmd is SOF_CTRL_CMD_BINARY then SOF_CTRL_TYPE_DATA_* otherwise SOF_CTRL_TYPE_VALUE_CHAN_*. The SET or GET direction can be selected with the use of `set` parameter. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Peter Ujfalusi authored
The component type is not used in firmware nor in the kernel currently and it is not even clear how it should be handled. Do not even try to handle it to avoid errors. Signed-off-by:
-
Peter Ujfalusi authored
There is no need to use two variables to store and check the same information, the scontrol->cmd is the same as scontrol->control_data->cmd. Drop the former one and when it is needed, access the cmd from the control_data. Signed-off-by:
-
Peter Ujfalusi authored
The scontrol->control_data->cmd has been configured during initialization to the correct sof_ipc_ctrl_cmd. No need to pass duplicated information, let's use the already available one via scontrol. Signed-off-by:
-
Peter Ujfalusi authored
Set the scontrol->control_data->cmd early to the same as scontrol->cmd. This is a preparatory patch to remove the ctrl_cmd parameter for the snd_sof_ipc_set_get_comp_data() function. Signed-off-by:
-
Peter Ujfalusi authored
The correct ipc_cmd can be selected based on the `ctrl_cmd` and the `set` parameters: if the ctrl_cmd is SOF_CTRL_CMD_BINARY then SOF_IPC_COMP_*_DATA otherwise SOF_IPC_COMP_*_VALUE. The SET or GET direction can be selected with the use of `set` parameter. Signed-off-by:
-
Peter Ujfalusi authored
Rename the send parameter to set in snd_sof_ipc_set_get_comp_data() and sof_set_get_large_ctrl_data() to be more aligned with the function name. No functional change. Signed-off-by:
-
Jiasheng Jiang authored
The return value of device_property_read_u32_array() is not always 0. To catch the exception in case that devm_kzalloc failed and the rt5663->imp_table was NULL, which caused the failure of device_property_read_u32_array. Fixes: 450f0f6a ("ASoC: rt5663: Add the manual offset field to compensate the DC offset") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20211215031550.70702-1-jiasheng@iscas.ac.cnSigned-off-by:
-
Daniel Baluta authored
Similar with commit 8a49cd11 ("ASoC: SOF: ACPI: avoid reverse module dependency") we will be having hardware specific drivers that link against a common "helper" framework. sof-of-dev.c becomes a library with the interface defined in the newly created file sof-of-dev.h. This is the final step started with Kconfig simplification in commit 7548a391 ("ASoC: SOF: i.MX: simplify Kconfig") Signed-off-by:
Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by:
-
Mark Brown authored
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: We've been adding a 'deep buffer' PCM device to several SOF topologies in order to reduce power consumption. The typical use-case would be music playback over a headset: this additional PCM device provides more buffering and longer latencies, leaving the rest of the system sleep for longer periods. Notifications and 'regular' low-latency audio playback would still use the 'normal' PCM device and be mixed with the 'deep buffer' before rendering on the headphone endpoint. The tentative direction would be to expose this alternate device to PulseAudio/PipeWire/CRAS via the UCM SectionModifier definitions. That seemed a straightforward topology change until our automated validation stress tests started reporting issues on SoundWire platforms, when e.g. two START triggers might be send and conversely the STOP trigger is never sent. The SoundWire stream state management flagged inconsistent states when the two 'normal' and 'deep buffer' devices are used concurrently with rapid play/stop/pause monkey testing. Looking at the soc-pcm.c code, it seems that the BE state management needs a lot of love. a) there is no consistent protection for the BE state. In some parts of the code, the state updates are protected by a spinlock but in the trigger they are not. When we open/play/close the two PCM devices in stress tests, we end-up testing a state that is being modified. That can't be good. b) there is a conceptual deadlock: on stop we check the FE states to see if a shared BE can be stopped, but since we trigger the BE first the FE states have not been modified yet, so the TRIGGER_STOP is never sent. This patchset suggests the removal of the dedicated 'dpcm_lock' and follows the design suggested by Takashi Iwai. By default the protection relies on the 'pcm_mutex', except for the FE and BE triggers where the mutex cannot be used. In this case, the FE PCM lock is used instead. In the cases where a BE is added/removed, the pcm_mutex and FE PCM lock are both taken. In addition, the BE PCM lock is used to serialize access to a shared BE. With these patches I am able to run our entire validation suite without any issues with this new 'deep buffer' topology, and no regressions on existing solutions [1]. The tests were reproduced by Bard Liao for SoundWire devices. One might ask 'how come we didn't see this earlier'? The answer is probably that the .trigger callbacks in most implementations seems to perform DAPM operations, and sending the triggers multiple times is not an issue. In the case of SoundWire, we do use the .trigger callback to reconfigure the bus using the 'bank switch' mechanism. It could be acceptable to tolerate a trigger multiple times, but the deadlock on stop cannot be fixed at the SoundWire level alone. Opens: 1) The issues reported by Nvidia on the RFCv3 may or may not be present. We'd need test results to make sure the locking update does not introduce a regression on Tegra. 2) There are other reports of kernel oopses [2] that seem related to the lack of protection. I'd be good to confirm if this patchset solve these problems as well. [1] https://github.com/thesofproject/linux/pull/3146 [2] https://lore.kernel.org/alsa-devel/002f01d7b4f5$c030f4a0$4092dde0$@samsung.com/ changes since RFCv3: Used two patches from Takashi. We now use the pcm_mutex, the FE stream lock when adding and deleting a BE, and the BE stream lock to handle concurrency between streams using the same BE. Added a patch to use GFP_ATOMIC for the DPCM structure. Fixed PAUSE_RELEASE transition (GitHub comment from Kai Vehmanen) changes since RFCv2: Removal of dpcm_lock to use FE PCM locks (credits to Takashi Iwai for the suggestion). The FE PCM lock is now used before each use of for_each_dpcm_be() - with the exception of the trigger where the lock is already taken. This change is also applied in drivers which make use of this loop (compress, SH, FSL). Addition of BE PCM lock to deal with mutual exclusion between triggers for the same BE. Alignment of the BE atomicity on the FE on connections, this is required to avoid sleeping in atomic context. Additional cleanups (indentation, static functions) changes since RFC v1: Removed unused function Removed exported symbols only used in soc-pcm.c, used static instead Use a mutex instead of a spinlock Protect all for_each_dpcm_be() loops Fix bugs introduced in the refcount Pierre-Louis Bossart (4): ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure ASoC: soc-pcm: align BE 'atomicity' with that of the FE ASoC: soc-pcm: test refcount before triggering ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE Takashi Iwai (2): ASoC: soc-pcm: Fix and cleanup DPCM locking ASoC: soc-pcm: serialize BE triggers include/sound/soc-dpcm.h | 2 + include/sound/soc.h | 2 - sound/soc/soc-core.c | 1 - sound/soc/soc-pcm.c | 351 +++++++++++++++++++++++++++------------ 4 files changed, 246 insertions(+), 110 deletions(-) -- 2.25.1
-
- 14 Dec, 2021 12 commits
-
-
Miaoqian Lin authored
The function gpr_alloc_port return ERR_PTR on errors, it doesn't return null. Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20211211065840.1221-1-linmq006@gmail.comSigned-off-by:
-
Judy Hsiao authored
Distinguish which headset codec is on the board by codec_dai->name instead of card->name. It fixes the crash of being unable to handle kernel paging requests at virtual address ADDR by initializing the correct audio codec on the board. Call stack of the crash: ``` Unable to handle kernel paging request at virtual address ... ... Call trace: rt5682_set_component_pll+0xcc/0xb78 [snd_soc_rt5682] snd_soc_component_set_pll+0x90/0x154 snd_soc_dai_set_pll+0xf4/0x1ac sc7180_snd_startup+0x268/0x3c0 [snd_soc_sc7180] snd_soc_link_startup+0xa4/0x180 soc_pcm_open+0x35c/0x15c8 snd_pcm_open_substream+0xa90/0x13b0 snd_pcm_open+0x1a4/0x55c snd_pcm_capture_open+0x7c/0xe8 snd_open+0x2b8/0x2e4 chrdev_open+0x364/0x3d4 do_dentry_open+0x66c/0xc58 vfs_open+0x7c/0x8c path_openat+0x108c/0x2bbc do_filp_open+0x15c/0x258 do_sys_open+0x278/0x62c __arm64_compat_sys_openat+0x9c/0xb0 ... ``` Fixes: 425c5fce ("ASoC: qcom: Add support for ALC5682I-VS codec") Signed-off-by:
Judy Hsiao <judyhsiao@chromium.org> Link: https://lore.kernel.org/r/20211214022509.1288245-1-judyhsiao@chromium.orgSigned-off-by:
-
Pierre-Louis Bossart authored
A BE connected to more than one FE, e.g. in a mixer case, can go through the following transitions. play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START stop FE2 -> BE state is STOP (see note [1] below) release FE1 -> BE state is START stop FE1 -> BE state is STOP play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START release FE1 -> BE state is START stop FE2 -> BE state is START stop FE1 -> BE state is STOP play FE1 -> BE state is START play FE2 -> BE state is START (no change) pause FE1 -> BE state is START (no change) pause FE2 -> BE state is PAUSED release FE1 -> BE state is START release FE2 -> BE state is START (no change) stop FE1 -> BE state is START (no change) stop FE2 -> BE state is STOP The existing code for PAUSE_RELEASE only allows for the case where the BE is paused, which clearly would not work in the sequences above. Extend the allowed states to restart the BE when PAUSE_RELEASE is received, and increase the refcount if the BE is already in START. [1] the existing logic does not move the BE state back to PAUSED when the FE2 is stopped. This patch does not change the logic; it would be painful to keep a history of changes on the FE side, the state machine is already rather complicated with transitions based on the last BE state and the trigger type. Reported-by:
Bard Liao <bard.liao@intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
On start/pause_release/resume, when more than one FE is connected to the same BE, it's possible that the trigger is sent more than once. This is not desirable, we only want to trigger a BE once, which is straightforward to implement with a refcount. For stop/pause/suspend, the problem is more complicated: the check implemented in snd_soc_dpcm_can_be_free_stop() may fail due to a conceptual deadlock when we trigger the BE before the FE. In this case, the FE states have not yet changed, so there are corner cases where the TRIGGER_STOP is never sent - the dual case of start where multiple triggers might be sent. This patch suggests an unconditional trigger in all cases, without checking the FE states, using a refcount protected by the BE PCM stream lock. Signed-off-by:
-
Takashi Iwai authored
When more than one FE is connected to a BE, e.g. in a mixing use case, the BE can be triggered multiple times when the FE are opened/started concurrently. This race condition is problematic in the case of SoundWire BE dailinks, and this is not desirable in a general case. This patch relies on the existing BE PCM lock, which takes atomicity into account. The locking model assumes that all interactions start with the FE, so that there is no deadlock between FE and BE locks. Signed-off-by:
Takashi Iwai <tiwai@suse.de> [test, checkpatch fix and clarification of commit message by plbossart] Signed-off-by:
-
Takashi Iwai authored
The existing locking for DPCM has several issues a) a confusing mix of card->mutex and card->pcm_mutex. b) a dpcm_lock spinlock added inconsistently and on paths that could be recursively taken. The use of irqsave/irqrestore was also overkill. The suggested model is: 1) The pcm_mutex is the top-most protection of BE links in the FE. The pcm_mutex is applied always on either the top PCM callbacks or the external call from DAPM, not taken in the internal functions. 2) the FE stream lock is taken in higher levels before invoking dpcm_be_dai_trigger() 3) when adding and deleting a BE, both the pcm_mutex and FE stream lock are taken. Signed-off-by:
-
Pierre-Louis Bossart authored
Since the flow for DPCM is based on taking a lock for the FE first, we need to make sure during the connection between a BE and an FE that they both use the same 'atomicity', otherwise we may sleep in atomic context. If the FE is nonatomic, this patch forces the BE to be nonatomic as well. That should have no negative impact since the BE 'inherits' the FE properties. However, if the FE is atomic and the BE is not, then the configuration is flagged as invalid. Signed-off-by:
-
Pierre-Louis Bossart authored
We allocate a structure in dpcm_be_connect(), which may be called in atomic context. Using GFP_KERNEL is not quite right, we have to use GFP_ATOMIC to prevent the allocator from sleeping. Suggested-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by:
-
Mark Brown authored
Merge series from Stephan Gerhold <stephan@gerhold.net>: This series makes it possible to route audio through the combined audio/modem DSP on MSM8916/APQ8016 devices instead of bypassing it using the LPASS drivers. This is necessary to support certain functionality such as voice call audio. See PATCH 4/5 for details. Also, qcom,apq8016-sbc.txt is converted to DT schema by adding it to the existing qcom,sm8250.yaml. The bindings are similar enough that it is easier to share a single schema instead of duplicating everything into multiple ones.
-
Jiaxin Yu authored
Fix the following sparse warning: (new ones prefixed by >>) >> sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c:370:33: sparse: sparse: incorrect type in argument 3 (different base types) sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c:370:33: sparse: expected unsigned int to sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c:370:33: sparse: got restricted snd_pcm_format_t [usertype] Correct discription of format, use S32_LE and S24_LE to distinguish the different 32bit. Signed-off-by:Jiaxin Yu <jiaxin.yu@mediatek.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20211209073224.21793-1-jiaxin.yu@mediatek.comSigned-off-by:
-
Rikard Falkeborn authored
The only usage of sof_probe_compr_ops is to assign its address to the cops field in the snd_soc_dai_driver struct (in sound/soc/sof/intel/hda-dai.c). Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20211204203220.54712-1-rikard.falkeborn@gmail.comSigned-off-by:
-
Allen-KH Cheng authored
In SOF OF device, pm_runtime_put_autosuspend() is not matching any pm_runtime_get_sync(). This is imbalanced for PM runtime. Also, for consistency we call pm_runtime_mark_last_busy() before enabling PM runtime. 1. Remove pm_runtime_put_autosuspend() in probe_complete 2. Reorder PM runtime calls int probe_complete Signed-off-by:
Allen-KH Cheng <Allen-KH.Cheng@mediatek.com> Reviewed-by:
-
- 13 Dec, 2021 12 commits
-
-
Stephan Gerhold authored
The apq8016-sbc-sndcard is designed to be used with the LPASS drivers (bypassing the combined audio/modem DSP in MSM8916/APQ8016). Make it possible to use QDSP6 audio instead for the msm8916-qdsp6-sndcard. This only requires adding some additional hooks that set up the DPCM backends correctly. Similar code is already used in drivers for newer SoCs such as apq8096.c, sdm845.c and sm8250.c. A slightly different initialization sequence is used for the apq8016-sbc and msm8916-qdsp6 sound card by defining the apq8016_sbc_add_ops() function as device match data. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211202145505.58852-6-stephan@gerhold.netSigned-off-by:
-
Stephan Gerhold authored
There are two possible audio setups on MSM8916/APQ8016: Normally the audio is routed through the audio/modem DSP (covered by the qdsp6 driver). During upstreaming for the DragonBoard 410c it was decided to bypass it and instead talk directly to the audio controller using the "lpass" driver. Bypassing the DSP gives more control about the audio configuration but limits the functionality: For example, routing audio through the audio/modem DSP is strictly required for voice call audio. Also, without the special changes in the DB410c firmware other MSM8916 devices can only use the bypass as long as the modem DSP is not started. Otherwise, the firmware will assume control of the LPASS hardware block and audio is no longer functional. Add support for using the DSP audio setup instead using a new "qcom,msm8916-qdsp6-sndcard" compatible. It is basically a mixture of the apq8016-sbc-sndcard and the newer sm8250-sndcard, which uses indirect QDSP6 DAI links instead of the direct LPASS DAI links. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Stephan Gerhold authored
All the Qualcomm sound card drivers use the same common device tree parsing code, so the allowed device tree nodes are almost the same for all of them. Convert the qcom,apq8016-sbc-sndcard documentation to a DT schema by adding it to the existing qcom,sm8250 schema. The only speciality of qcom,apq8016-sbc-sndcard is that it has memory resources for setting up an I/O mux. This can be handled using a conditional if statement that only requires it for the apq8016-sbc compatible. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Stephan Gerhold authored
The sm8250 audio driver uses the common Qualcomm device tree parser and therefore already supports the "aux-devs" property that allows adding additional auxiliary devices to the sound card (e.g. analog speaker amplifiers that can be connected using "audio-routing"). Document the property in the DT schema for sm8250 as well. The description is taken from simple-card.yaml which has a very similar property. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Stephan Gerhold authored
The MultiMedia audio routes can be deduced from other parts of the device tree (e.g. the definitions of the MultiMedia DAIs) and therefore specifying them again in "audio-routing" is redundant and prone to mistakes. This is no longer necessary since commit 6fd8d2d2 ("ASoC: qcom: qdsp6: Move frontend AIFs to q6asm-dai"). Let's drop them from the example in the DT schema as well to avoid confusion. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Pierre-Louis Bossart authored
Explain why JasperLake is exposed in cnl.c instead of icl.c No functionality change. Signed-off-by:
-
Pierre-Louis Bossart authored
The existing code does not use the 'host_dma_id', 'link_dma_id', 'host_bps' fields remove them. Signed-off-by:
-
Pierre-Louis Bossart authored
The code inherited from the Skylake driver does not seem to follow any known hardware recommendations. The only two recommended options are a) use DPIB registers if VC1 traffic is not allowed b) use DPIB DDR update if VC1 traffic is used In all of SOF-based updated, VC1 is not supported so we can 'safely' move to using DPIB registers only. This patch keeps the legacy code, in case there was an undocumented issue lost to history, and adds the DPIB DDR update for additional debug. Signed-off-by:
-
Pierre-Louis Bossart authored
The existing code is inconsistent, we should only enable DPIB if the 'use_posbuf' field is true. Signed-off-by:
-
Pierre-Louis Bossart authored
we use 'bus->use_posbuf && bus->posbuf.addr' in hda_dsp_ctrl_init_chip(), use the same for hda_dsp_ctrl_stop_chip() Signed-off-by:
-
Pierre-Louis Bossart authored
The work-around enabled in hda-stream.c is only required on earlier versions of SOCs/PCH (Skylake, KabyLake, ApolloLake, GeminiLake). Before setting the format on the host DMA, it is required to couple the host and link DMA - which as a consequence shall use the same format. This patch introduces a quirk field in the platform descriptor and makes the work-around conditional. Newer platforms have no limitations on the use of host and link DMA, which can use different formats. Signed-off-by:
-
Ranjani Sridharan authored
Move the ICL specific ops to icl.c. Also introduce a macro ICL_DSP_HPRO_CORE_ID to define the core that should be powered up when HPRO is enabled. Reviewed-by:
-
