kernel/sound/soc/sof/intel/hda-ipc.c, branch linux-6.2.y

ASoC: SOF: Intel: ipc4: Ack a received reply or notification separately

2022-10-18T18:16:45Z

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 Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Link: https://lore.kernel.org/r/20221018124008.6846-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: ipc4: Wait for channel to be free before sending a message

2022-10-18T18:16:44Z

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 Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Link: https://lore.kernel.org/r/20221018124008.6846-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: ipc4: Read the interrupt reason registers at the same time

2022-10-18T18:16:43Z

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 Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Link: https://lore.kernel.org/r/20221018124008.6846-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: add initial SKL/KBL hardware support

2022-09-20T18:07:30Z

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 Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220920131700.133103-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: replace dev_vdbg with tracepoints

2022-09-19T14:44:06Z

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 Signed-off-by: Noah Klayman Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220919122108.43764-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot

2022-07-12T12:45:02Z

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 Signed-off-by: Peter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220712122357.31282-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: HDA: Set IPC4-specific DSP ops for CaVS platforms

2022-05-12T10:41:25Z

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 Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220511171648.1622993-2-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: Convert to use the generic set_stream_data_offset ops

2022-03-11T13:41:07Z

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 Reviewed-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Daniel Baluta Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220310042720.976809-9-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda-ipc: Add hda_set_stream_data_offset()

2022-03-11T13:41:06Z

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 Reviewed-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Daniel Baluta Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220310042720.976809-8-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hdac_ext_stream: consistent prefixes for variables/members

2022-02-09T14:36:14Z

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 Reviewed-by: Kai Vehmanen Reviewed-by: Rander Wang Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20220209063104.9971-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown