summaryrefslogtreecommitdiff
path: root/sound/soc/sof/intel/hda-ipc.c
AgeCommit message (Collapse)AuthorFilesLines
2024-05-07ALSA/ASoC: Intel: clarify Copyright informationMark Brown1-1/+1
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: This patchset does not change any functionality. It only clarifies the Copyright information in ASoC/HDAudio contributions, where an "All rights reserved" notice was mistakenly added in a number of files over the years, likely due to copy/paste. The Intel template never included this statement.
2024-05-06ASoC: SOF: Intel: clarify Copyright informationPierre-Louis Bossart1-1/+1
For some reason a number of files included the "All rights reserved" statement. Good old copy-paste made sure this mistake proliferated. Remove the "All rights reserved" in all Intel-copyright to align with internal guidance. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> 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/20240503140359.259762-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-05ASoC: SOF: Intel: move hda.c to different modulePierre-Louis Bossart1-0/+5
Now that most of the code moves are done, we can add a new module and the required EXPORT_SYMBOL definitions. No functionality change, just a new module added. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20240503135221.229202-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-05ASoC: SOF: Intel: move common code from hda.cPierre-Louis Bossart1-0/+99
To avoid circular dependencies when moving hda.c to a separate module, we need to move the common code to hda-ipc.c and hda-dsp.c No functionality change, just code move. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20240503135221.229202-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-05-05ASoC: SOF: Intel: start splitting top-level from common partsPierre-Louis Bossart1-0/+11
The existing code relies on the 'HDA_COMMON' module and namespace. We need to start splitting top-level parts from the low-level ones, otherwise we will not be able to reuse the low-level parts DMA support for SoundWire/BPT. In the end the dependencies will be: +----------------------------------------------+ | | | v sof-pci-intel-xxx --> sof-intel-hda ------------> sof-hda-common | ^ | | +-> soundwire_intel --> sof_hda_sdw_bpt This patch adds the initial split between the sof-pci-intel-xxx modules and the common parts, in a follow-up patch we will further split the HDA_COMMON parts Since the PCI modules are not all independent, i.e. the CNL parts are also used in JSL and TGL, additional Kconfig and namespace modules were added. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20240503135221.229202-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-04-04ASoC: SOF: Intel: hda: make DSPless mode work with DSP disabled in BIOSPierre-Louis Bossart1-0/+3
When the DSP is disabled in the BIOS, the DSP_BAR and PP_BAR cannot be accessed. One possible objection noted in initial reviews is that this patch adds a number of branches. However the number of branches is actually limited in probe/suspend/resume routines mostly, so there isn't really a degradation in terms of readability and maintainability. Adding yet another level of abstraction/ops/callbacks would increase complexity and not really help in terms of code reuse or readability and maintainability. A split between controller and DSP driver would be even more invasive. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230404092115.27949-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-14ASoC: SOF: Intel: Enable d0i3 work for ipc4Rander Wang1-0/+28
Schedule a delayed work for d0i3 entry after every non-pm ipc msg. Signed-off-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230214103345.30669-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-17ASoC: SOF: Prepare set_stream_data_offset for compress APIDaniel Baluta1-1/+2
Make second parameter of set_stream_data_offset generic in order to be used for both PCM and compress streams. Current patch doesn't introduce any functional change, just prepare the code for compress support. Reviewed-by: Paul Olaru <paul.olaru@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20230117122533.201708-3-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-17ASoC: SOF: Prepare ipc_msg_data to be used with compress APIDaniel Baluta1-2/+3
Make second parameter of ipc_msg_data generic in order to be able to support compressed streams. This patch doesn't hold any functional change. With this case we can use ipc_msg_data, to retrieve information from DSP for both PCM/Compress API. Reviewed-by: Paul Olaru <paul.olaru@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20230117122533.201708-2-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-18ASoC: SOF: Intel: ipc4: Ack a received reply or notification separatelyPeter Ujfalusi1-3/+4
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 Ujfalusi1-0/+17
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 Ujfalusi1-1/+2
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-09-20ASoC: SOF: Intel: add initial SKL/KBL hardware supportPierre-Louis Bossart1-0/+8
In preparation of the IPCv4 IPC support, this patch adds support for SkyLake and KabyLake boot and descriptors used when probing the PCI driver. The work was initially contributed in 2018 by Liam Girdwood and Zhu Yingjiang, and abandoned due to firmware signature issues. With the upcoming support of IPC v4, and hence the Intel closed-source firmware, it's time to re-add this capability. The SKL ops will be added in the next patch. Tested with the IPC4 and closed-source firmware on Dell XPS 9350 and KBL NUC with HDaudio codecs. The SSP and DMIC interfaces are not supported at this time. Co-developed-by: Ranjani Sridharan <ranjani.sridharan@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> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220920131700.133103-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-19ASoC: SOF: Intel: replace dev_vdbg with tracepointsBard Liao1-7/+4
This patch replaces all dev_vdbg calls with tracepoints to reduce overhead and enable use of trace collection and analysis tools. Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Noah Klayman <noah.klayman@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220919122108.43764-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-12ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware bootPeter Ujfalusi1-14/+25
It is not yet clear, but it is possible to create a firmware so broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same condition is present for IPC3. Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220712122357.31282-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-12ASoC: SOF: Intel: HDA: Set IPC4-specific DSP ops for CaVS platformsRanjani Sridharan1-0/+82
Add implementation of low level, platform dependent IPC4 message handling and set the DSP ops for IPC4 for APL, CNL and TGL platforms. Co-developed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@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/20220511171648.1622993-2-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-03-11ASoC: SOF: Intel: Convert to use the generic set_stream_data_offset opsPeter Ujfalusi1-7/+0
Switch from the IPC dependent ipc_pcm_params() ops to the IPC neutral set_stream_data_offset(). Remove the no longer used hda_ipc_pcm_params() function as well. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220310042720.976809-9-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-03-11ASoC: SOF: Intel: hda-ipc: Add hda_set_stream_data_offset()Peter Ujfalusi1-5/+10
Add implementation for the generic set_stream_data_offset() callback to be used by HDA platforms. Convert the hda_ipc_pcm_params() to a wrapper for the new function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220310042720.976809-8-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-09ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/membersPierre-Louis Bossart1-5/+5
The existing code maximizes confusion by using 'stream' and 'hstream' variables of different types, e.g: struct hdac_stream *stream; struct hdac_ext_stream *stream; struct hdac_stream *hstream; struct hdac_ext_stream *hstream; This confusion is partly inherited from legacy code but SOF contributors added their own creative spin, e.g. struct hdac_ext_stream *link_dev; struct hdac_ext_stream *dsp_stream; struct hdac_ext_stream hda_stream; and my personal favorite: stream = &hda_stream->hda_stream; This patch suggests a consistent naming across all Intel code related to HDAudio stream management. The convention is - by hierarchical order: struct sof_intel_hda_stream *hda_stream; struct hdac_ext_stream *hext_stream; struct hdac_stream *hstream; No functionality change - just renaming of variables/members. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220209063104.9971-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Add 'non_recoverable' parameter to snd_sof_dsp_panic()Peter Ujfalusi1-2/+17
Some platforms use retries during firmware boot to overcome DSP startup issues. In these cases we might receive a DSP panic message which should not be treated as fatal if it happens during boot. Pass this information to snd_sof_dsp_panic() and omit the panic print if it is not fatal or the user does not want to see all dumps. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-17ASoC: SOF: intel: Use the generic helper to get the replyPeter Ujfalusi1-27/+2
Make use of the generic snd_sof_ipc_process_reply() from the core instead the local implementation. snd_sof_ipc_process_reply() handles the reply retrieving and the ipc reply Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20211116152137.52129-4-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-28ASoC: SOF: add error handling to snd_sof_ipc_msg_data()Guennadi Liakhovetski1-6/+9
If an invalid stream is passed to snd_sof_ipc_msg_data() it won't fill the provided object with data. The caller has to be able to recognise such cases to avoid handling invalid data. Make the function return an error when failing. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20210928103516.8066-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03ASoC: SOF: Intel: hda-ipc: fix reply size checkingGuennadi Liakhovetski1-2/+2
Checking that two values don't have common bits makes no sense, strict equality is meant. Fixes: f3b433e4699f ("ASoC: SOF: Implement Probe IPC API") Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210802151749.15417-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-01ASoC: SOF/Intel: clarify SPDX license with GPL-2.0-onlyPierre-Louis Bossart1-1/+1
Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only tag. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20200501145850.15178-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13ASoC: SOF: Intel: remove unnecessary waitq before loading firmwareAmery Song1-6/+0
The HDA_DSP_IPC_PURGE_FW IPC from ROM is already handled in cl_dsp_init(), and it will never be received in the IRQ thread, so the wait condition on this IPC will never be satisfied. The wait before loading firmware is redundant and can be removed safely. Signed-off-by: Amery Song <chao.song@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Keyon Jie <yang.jie@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20200312200622.24477-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13ASoC: SOF: Intel: hda: remove unnecessary ROM IPC filter functionAmery Song1-11/+3
The HDA_DSP_IPC_PURGE_FW IPC from ROM is already handled in cl_dsp_init(), and as IPC IRQ is disabled at this stage, this IPC will be never received in the IRQ thread. The function hda_dsp_ipc_is_sof for filtering the ROM IPC can be removed safely. Signed-off-by: Amery Song <chao.song@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Keyon <yang.jie@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200312200622.24477-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-19ASoC: SOF: Implement Probe IPC APICezary Rojewski1-1/+3
Add all required types and methods to support each and every request that driver could sent to firmware. Probe is one of SOF firmware features which allows for data extraction and injection directly from or to DMA stream. Exposes eight IPCs: - addition and removal of injection DMAs - addition and removal of probe points - info retrieval of injection DMAs and probe points - probe initialization and cleanup Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200218143924.10565-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: SOF: Intel: hda: solve MSI issues by merging ipc and stream irq handlersBard Liao1-18/+5
The existing code uses two handlers for a shared edge-based MSI interrupts. In corner cases, interrupts are lost, leading to IPC timeouts. Those timeouts do not appear in legacy mode. This patch merges the two handlers and threads into a single one, and simplifies the mask/unmask operations by using a single top-level mask (Global Interrupt Enable). The handler only checks for interrupt sources using the Global Interrupt Status (GIS) field, and all the actual work happens in the thread. This also enables us to remove the use of spin locks. Stream events are prioritized over IPC ones. This patch was tested with HDaudio and SoundWire platforms, and all known IPC timeout issues are solved in MSI mode. The SoundWire-specific patches will be provided in follow-up patches, where the SoundWire interrupts are handled in the same thread as IPC and stream interrupts. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204212859.13239-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-28ASoC: SOF: Intel: hda-ipc: Don't read mailbox for PM_GATE replyKeyon Jie1-2/+4
Memory windows could be powered off before receiving PM_GATE IPC reply from FW, we can't read the mailbox to get reply. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191025224122.7718-15-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-09ASoC: SOF: Intel: hda: Use generic function for fw ready / mem windows creationDaniel Baluta1-146/+4
We can use generic sof_fw_ready function and reduce code duplication. Careful here that we need to provide the implementation for get_mailbox_offset and get_window_offset. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190807150203.26359-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-07-23ASoC: SOF: Intel: hda: remove misleading error trace from IRQ threadKai Vehmanen1-2/+2
Downgrade "nothing to do in IRQ thread" message from error to a debug message in the IPC interrupt handler thread. The spurious wake-up can happen if a HDA stream interrupt is raised while the IPC interrupt thread is running. IPC functionality is not impacted by this condition, so debug is a more appropriate trace level. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190722141402.7194-21-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: Intel: ipc: don't check for HIPCCTL register valuePierre-Louis Bossart1-6/+2
The HIPCCTL register controls the IPC interrupts. It can be set or cleared to mask or enable these interrupts, but it makes no sense to read and test its fields in an interrupt (which can only executed if its fields are set). Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: Intel: hda-ipc: re-enable IPC IRQ at end of handlerPierre-Louis Bossart1-8/+16
Align with Skylake driver and enable the IRQ at end of handler, instead of at beginning. Also add an error log if we have nothing to do in this handler. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: Intel: hda-ipc: read all IPC registers firstPierre-Louis Bossart1-5/+2
Align with hardware recommended sequences, and read all IPC registers before doing any other actions. Playing with BUSY and DONE bits may invalidate values. The values read may not actually be necessary but at least this provides a snapshot of the IPC registers with no consistency issues. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-03ASoC: SOF: Do not send cmd via SHIM registerDaniel Baluta1-3/+1
We use shim registers only to notify the other side that a message was sent. The actual information for the message is transmitted via mailbox. cmd information inside shim register is not used by the DSP, so we remove it to avoid confusion. Signed-off-by: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-28ASoC: SOF: ipc: fix a race, leading to IPC timeoutsGuennadi Liakhovetski1-3/+14
Currently on all supported platforms the IPC IRQ thread first signals the sender when an IPC response is received from the DSP, then unmasks the IPC interrupt. Those actions are performed without holding any locks, so the thread can be interrupted between them. IPC timeouts have been observed in such scenarios: if the sender is woken up and it proceeds with sending the next message without unmasking the IPC interrupt, it can miss the next response. This patch takes a spin-lock to prevent the IRQ thread from being preempted at that point. It also makes sure, that the next IPC transmission by the host cannot take place before the IRQ thread has finished updating all the required IPC registers. Fixes: 53e0c72d98b ("ASoC: SOF: Add support for IPC IO between DSP and Host") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-03ASoC: SOF: Intel: hda-ipc: simplify handling of IPC IRQKeyon Jie1-8/+5
When using a shared IRQ between IPC interrupt and stream IOC interrupt, the interrupt handlers need to check the interrupt source before scheduling their respective IRQ threads. In the case of IPC handler, it should check if it is an IPC interrupt before waking up the IPC IRQ thread. The IPC IRQ thread, once scheduled, does not need to check the IRQ source again. So, remove the superfluous check in the thread. Remove the irq_status field from snd_sof_dev struct also as it is no longer needed. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-27ASoC: SOF: Intel: Add Intel specific HDA IPC mechanisms.Liam Girdwood1-0/+458
Add HDA specific IPC mechanism for Intel DSP HW. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>