summaryrefslogtreecommitdiff
path: root/sound/soc/sof
AgeCommit message (Collapse)AuthorFilesLines
2022-10-20ALSA/ASoC: hda: move SPIB/DRMS functionality from ext layerPierre-Louis Bossart2-9/+10
The SPIB and DRMS capabilities are orthogonal to the DSP enablement and can be used whether the stream is coupled or not. The existing code partitioning makes limited sense, the capabilities are parsed at the sound/hda level but helpers are located in sound/hda/ext. This patch moves all the SPIB/DRMS functionality to the sound/hda layer. This reduces the complexity of the sound/hda/ext layer which is now limited to handling the multi-link extensions and stream coupling/decoupling helpers. Note that this is an iso-functionality code move and rename, the HDaudio legacy driver would need additional changes to make use of these capabilities. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20221019162115.185917-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-10-20ALSA/ASoC: hda: ext: add 'bus' prefix for multi-link stream settingPierre-Louis Bossart1-3/+3
All the helpers dealing with multi-link configurations are located in the hdac_ext_controller.c, except the two set/clear routines that modify the LOSIDV registers. For consistency, move the two helpers and add the 'bus' prefix. One could argue that the 'ml' prefix might be more relevant but that would be a larger code change. No functionality change, just move and rename. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221019162115.185917-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-10-20ALSA/ASoC: hda: ext: remove 'link' prefix for stream-related operationsPierre-Louis Bossart1-8/+8
We should only use 'link' in the context of multi-link configurations. Streams are configured from a different register space and are not dependent on link except for LOSIDV settings. Not functionality change, just pure rename. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221019162115.185917-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-10-20ALSA/ASoC: hda: ext: add 'ext' prefix to snd_hdac_link_free_allPierre-Louis Bossart1-1/+1
No functionality change, just prefix addition to clearly identify that the helper only applies to the 'ext' part for Intel platforms. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221019162115.185917-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-10-20ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpersPierre-Louis Bossart1-2/+2
We have two helpers with confusing names and different purposes. Rename bus_get_link() and bus_get_link_at() as bus_get_hlink_by_name() and bus_get_hlink_by_addr() respectively. No functionality change Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221019162115.185917-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-10-20ASoC: SOF: Intel: hda-dai: use hlink variable/parameterPierre-Louis Bossart1-12/+12
Follow the convention and use hlink for consistency. No functionality change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221019162115.185917-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-10-19ASoC: SOF: Intel: pci-tgl: fix ADL-N descriptorPierre-Louis Bossart1-1/+29
ADL-N uses a different signing key, which means we can't reuse the regular ADL descriptor used for ADL-P/M/S. Fixes: cd57eb3c403cb ("ASoC: SOF: Intel: pci-tgl: add ADL-N support") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20221019154926.163539-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-19ASoC: jz4752b: Capture fixesMark Brown1-15/+40
Merge series from Siarhei Volkau <lis8215@gmail.com>: The patchset fixes: - Line In path stays powered off during capturing or bypass to mixer. - incorrectly represented dB values in alsamixer, et al. - incorrect represented Capture input selector in alsamixer in Playback tab. - wrong control selected as Capture Master
2022-10-19ASoC: SOF: Intel: Harden the IPC4 low level sequencingMark Brown6-13/+88
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: Hi, The IPC4 use of doorbell registers leaves some corner cases not well defined and the 'correct sequences' are subjective in a sense. The DSP doorbell registers are used as separate and independent channels and the sequences for host -> DSP -> host (reply) can be racy. For example: The ACKing of a received message can happen before the firmware sends the reply or it can as well happen after the reply has been sent and received by the host. Both can be considered 'correct sequences' but they need different handling. This series will allow the kernel to service any interpretation of the sequencing on the firmware side.
2022-10-19ASoC: Intel/SOF: simplify S3 resume flowsMark Brown1-14/+0
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: All Intel drivers for cAVS platforms contain a sequence for S3 resume which doesn't seem justified nor necessary. Forensic Git investigation in internal repositories did not provide any rationale for the implementation, and tests show no impact when those sequences are removed. This sequence was identified as problematic during a large HDaudio cleanup where all programming sequences were revisited before extensions are added.
2022-10-18ASoC: SOF: ipc4-mtrace: protect per-core nodes against multiple openKai Vehmanen1-2/+18
Add protection against multiple open of the mtrace/coreN debugfs nodes. This is not supported in the implementation, and this will show up as unexpected behaviour of the interface, and potential use of already freed memory. Fixes: f4ea22f7aa75 ("ASoC: SOF: ipc4: Add support for mtrace log extraction") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.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/20221018121332.20802-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: ipc3: Log the tx message before sending itPeter Ujfalusi1-2/+2
It makes more sense to log the message before it is sent to the DSP. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20221018133843.16958-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: Intel: ipc4: Ack a received reply or notification separatelyPeter Ujfalusi3-8/+11
By acking a received message we tell the DSP that we have processed the message (reply or notification) and we are open to receive a new one. The original implementation did this in a common code after the received message got handled as reply or notification. With right timing this opens up a small window when we have processed the reply and let the other thread proceed to send a new message to the DSP, which is allowed as the DSP is free to receive message. But when the message is received and processed by the DSP and it wants to send a reply it will still see that the previous message has not been acked, so it fails to send a reply. Later the first reply got acked by the kernel, but it is too late and the in-flight message got a timeout due to firmware not responding (which it tried, but could not). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20221018124008.6846-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: Intel: ipc4: Wait for channel to be free before sending a messagePeter Ujfalusi5-0/+71
Before attempting to send a message to the DSP we need to check if the downstream BUSY flag has been cleared by the firmware to avoid lost IPC messages by the firmware. This is required by a firmware which only acks the received message after it has sent a reply to the host. With a bad luck, the host would send a message before the firmware gets to the clearing the flag and thus losing a message. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20221018124008.6846-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: Intel: ipc4: Read the interrupt reason registers at the same timePeter Ujfalusi3-3/+4
Read both registers as the first step in the interrupt handler to make sure that we are handling the event which triggered the interrupt. The delayed reading of the target request register might reflect incorrect information about the reason why the interrupt was risen. Note also that the IPC3 interrupt handler is implemented in this way also. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20221018124008.6846-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: ipc4: Log the tx message before sending itPeter Ujfalusi1-2/+2
It makes more sense to log the message before it is sent to the DSP. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20221018124008.6846-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: Intel: hda-dsp: simplify S3 resume flowsPierre-Louis Bossart1-14/+0
The flow contains surprising parts that seem to have been inspired by the Skylake driver. During a resume from S3, the state of the links prior to suspend should not matter. One would have to assume that the links are powered down anyways prior to suspend, and there is also no specific code that turns links on unconditionally on resume. Likewise, the snd_hdac_init_chip() routine will start the cmd_io handling, and it's not clear why we should care about the state of the DMA prior to suspend. This patch removes these two sequences to simplify the flow. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221017204946.207986-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: Intel: pci-mtl: fix firmware namePierre-Louis Bossart1-1/+1
Initial IPC4 tests used the same conventions as previous reference closed-source firmware, but for MeteorLake the convention is the same as previous SOF releases (sof-<platform>.ri). Only the prefix changes to avoid confusions between IPC types. This change has no impact on users since the firmware has not yet been released. Fixes: 064520e8aeaa2 ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20221017204004.207446-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-03Merge tag 'asoc-v6.1' of ↵Takashi Iwai59-560/+3401
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v6.1 This has been a very quiet release for the core but quite a busy one for drivers with a big crop of new drivers and lots of feature additions and fixes to existing ones: - A new string helper parse_int_array_user(). - Improvements to the SOF IPC4 code, especially around trace. - Support for AMD Rembrant DSPs, AMD Pink Sardine ACP 6.2, Apple Silcon systems, Everest ES8326, Intel Sky Lake and Kaby Lake, MediaTek MT8186 support, NXP i.MX8ULP DSPs, Qualcomm SC8280XP, SM8250 and SM8450 and Texas Instruments SRC4392 There is a conflict with the conversion of I2C remove functions to void in the cs42l42 driver which is fairly straightforward to resolve but should be highlighted to Linus.
2022-09-26ASoC: SOF: mediatek: mt8195: Add pcm_pointer callbackChunxu Li1-0/+33
Add pcm_pointer callback for mt8195 to support read host position from DSP Signed-off-by: Chunxu Li <chunxu.li@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220924033559.26599-3-chunxu.li@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-26ASoC: SOF: mediatek: mt8195: Add pcm_hw_params callbackChunxu Li1-0/+11
Add pcm_hw_params callback for mt8195 to support continue update dma host position Signed-off-by: Chunxu Li <chunxu.li@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220924033559.26599-2-chunxu.li@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: ipc4/Intel: Improve and enable IPC error dumpMark Brown10-15/+77
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: On Intel platforms the registers for DSP communications are used differently, the IPC dump information is not correct since important registers are not printed and existing ones are used a bit differently for IPC4. As a last step, enable the IPC timeout 'handling' and allow the printout of the now usefull IPC dump.
2022-09-23ASoC: SOF: ipc4: Call snd_sof_handle_fw_exception() in case of timeoutPeter Ujfalusi1-0/+1
It can help debugging IPC timeout issues (like we do with IPC3) if we dump the IPC and DSP information. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20220923133616.26267-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: hda: Only dump firmware registers for IPC3Peter Ujfalusi1-1/+2
The firmware register dump is IPC3 specific, it is not available for other IPC versions. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20220923133616.26267-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: mtl: Print relevant register in ipc_dumpPeter Ujfalusi1-9/+8
The use of the IPC registers are different between IPC3 and IPC4. The ipc_dump needs to use different prints depending on the used IPC protocol. The existing code was printing registers relevant for IPC3, which is not even supported on MTL. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20220923133616.26267-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: skl: Use the ipc4 version of the ipc_dumpPeter Ujfalusi1-1/+1
The use of the IPC registers are different between IPC3 and IPC4. The ipc_dump needs to use different prints depending on the used IPC protocol. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20220923133616.26267-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: hda: Add separate ops for ipc_dump for IPC4Peter Ujfalusi3-1/+25
The use of the IPC registers are different between IPC3 and IPC4. The ipc_dump needs to use different prints depending on the used IPC protocol. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20220923133616.26267-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: cnl: Add separate ops for ipc_dump for IPC4Peter Ujfalusi4-3/+40
The use of the IPC registers are different between IPC3 and IPC4. The ipc_dump needs to use different prints depending on the used IPC protocol. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20220923133616.26267-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: MTL: remove the unnecessary snd_sof_dsp_read()Yong Zhi1-8/+0
The return val of snd_sof_dsp_read() right before polling the same register is not used, so remove the redundant call. Signed-off-by: Yong Zhi <yong.zhi@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220922213644.666315-11-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: MTL: reuse the common ops for PMRanjani Sridharan1-150/+0
Now that the disabling of interrupts and powering down the DSP has been abstracted, re-use the common ops for PM for MTL as well. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220922213644.666315-10-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: HDA: use IPC version-specific opsRanjani Sridharan1-8/+5
Use the IP-specific ops for disabling interrupts and powering down the DSP in hda_suspend. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220922213644.666315-9-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: MTL: define and set the disable_interrupts opRanjani Sridharan1-0/+7
Disable the IPC and SDW interrupts in the disable_interrupts op. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220922213644.666315-8-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: define and set the disable_interrupts op for cavs platformsRanjani Sridharan7-0/+18
Disable the IPC and SDW nterrupts in the disable_interrupts op for cavs platforms. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220922213644.666315-7-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: Add a new op for disabling interruptsRanjani Sridharan1-0/+1
The sequence for disabling DSP interrupts varies between different IP versions. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220922213644.666315-6-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: use power_down_dsp op in hda_dsp_removeFred Oh1-3/+3
Use power_down_dsp op to differentiate power down sequences in platforms. Signed-off-by: Fred Oh <fred.oh@linux.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> Link: https://lore.kernel.org/r/20220922213644.666315-5-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: mtl: define and set power_down_dsp opFred Oh1-0/+28
For MTL platform, dsp cores need to go power down first then dsp subsystem also need to set power down. Signed-off-by: Fred Oh <fred.oh@linux.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> Link: https://lore.kernel.org/r/20220922213644.666315-4-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: define and set power_down_dsp op for HDA platformsFred Oh7-0/+18
hda_power_down_dsp is set for power_down_dsp op for all HDA platforms. Signed-off-by: Fred Oh <fred.oh@linux.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> Link: https://lore.kernel.org/r/20220922213644.666315-3-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-23ASoC: SOF: Intel: introduce new op to handle dsp power downFred Oh1-0/+1
DSP core power down sequences are different between cavs platforms and MTL. Signed-off-by: Fred Oh <fred.oh@linux.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> Link: https://lore.kernel.org/r/20220922213644.666315-2-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-22ASoC: SOF: pci-tgl: add missing PCI IDs for RPLPierre-Louis Bossart1-0/+4
Add IDs for RPL-M and RPL-PX Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20220922100254.27159-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-22ASoC: SOF: Intel: pci-tgl: reorder PCI IDsPierre-Louis Bossart1-2/+2
No functionality change, just sort ADL PCI IDs by increasing order. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20220922100254.27159-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-21ASoC: SOF: mediatek: add pcm_pointer callback for mt8186Chunxu Li1-0/+33
add pcm_pointer callback for mt8186 to support read host position from DSP Signed-off-by: Chunxu Li <chunxu.li@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220921120239.31934-1-chunxu.li@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-21ASoC: SOF: ipc4-topology: Free the ida when IPC fails in sof_ipc4_widget_setup()Peter Ujfalusi1-1/+8
The allocated ida needs to be freed up if the IPC message fails since next time when we try again to set up the widget we are going to try to allocate another ID and given enough tries, we are going to run out of unique IDs. Fixes: 711d0427c713 ("ASoC: SOF: ipc4-topology: move ida allocate/free to widget_setup/free") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220921112751.9253-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-21ASoC: SOF: Add SKL/KBL support for IPC4 CI testsMark Brown9-2/+841
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: This patchset was submitted earlier in April 2022 as part of the "ASoC: SOF: add INTEL_IPC4 plumbing" series. As requested the SKL/KBL support is moved to a different series. This update adds minor style fixes and the ops that were missing at the time. SKL and KBL daily tests have been running for several months and helped identify missing sequences in the SOF driver for HDaudio links, or platform differences that the driver did not account for (number of pipelines, etc). Note that this capability is not recommended for any distribution, it is ONLY for SOF IPC4 CI tests on HDaudio devices, we will not extend this SKL/KBL support for I2S devices based on ES8336 or Chromebooks which are ONLY supported by the AVS driver.
2022-09-21ADD SOF support for rembrandt platformMark Brown17-151/+651
Merge series from V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com>: This series consists of 1.Make ACP core code generic for newer SOC transition 2.Add support for Rembrandt plaform 3.Adding amd HS functionality to the sof core 4.increase SRAM inbox and outbox size to 1024
2022-09-21ASoC: SOF: ipc4-topology: minor cleanupMark Brown1-3/+2
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: Two updates on warnings reported by cppcheck.
2022-09-21ASoC: SOF: sof-audio: fix prepare/unprepareMark Brown1-5/+7
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: 2 patches from Rander required to enable mixing usages with multiple pipelines.
2022-09-21ASoC: soc.h: random cleanupMark Brown1-2/+2
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: These are random cleanup for soc.h
2022-09-20ASoC: SOF: amd: increase SRAM inbox and outbox size to 1024V sujith kumar Reddy6-17/+48
Increase inbox and outbox mailbox size from 512 to 1024 to support thirdparty DTS integration ipc tx/rx messages communication. This is done through firmware window get info. Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220913144319.1055302-5-Vsujithkumar.Reddy@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20ASoC: SOF: Adding amd HS functionality to the sof coreV sujith kumar Reddy3-0/+43
Add I2S HS control instance to the sof core. This will help the amd topology to use the I2S HS Dai. Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220913144319.1055302-4-Vsujithkumar.Reddy@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20ASoC: SOF: amd: Add support for Rembrandt plaform.V sujith kumar Reddy7-1/+351
Add pci driver and platform driver to enable SOF support on ACP6x architecture based Rembrandt platform. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220913144319.1055302-3-Vsujithkumar.Reddy@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>