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

ASoC: SOF: Intel: hda: add callback to check SoundWire lcount information

2022-11-23T15:32:05Z

The number of links is stored in different registers depending on the IP version, add sdw_check_lcount() callback. This callback only checks that the number of links supported in hardware is compatible with the number of links exposed in ACPI _DSD properties. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20221111042653.45520-6-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: add per-chip enable_sdw_irq() callback

2022-11-23T15:32:02Z

Different generations of Intel hardware rely on different programming sequences to enable SoundWire IP. In existing hardware, the SoundWire interrupt is enabled with a register field in the DSP register space. With HDaudio multi-link extensions registers, the SoundWire interrupt will be enabled with a generic interrupt enable field in LCTL, without any dependency on the DSP being enabled. Add a per-chip callback following the example of the check_sdw_irq() model already upstream. Note that the callback is not populated yet for MeteorLake (MTL) since the interrupts are already enabled in the init. A follow-up patch will move the functionality to this callback after a couple of cleanups. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20221111042653.45520-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: add d0i3_offset in chip_info

2022-11-07T17:10:07Z

MTL has different d0i3 offset compared to cavs platforms. Use d0i3_offset to unify the setting. Reviewed-by: Ranjani Sridharan Signed-off-by: Rander Wang Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20221107164154.21925-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel/IPC4: Support for external firmware libraries

2022-10-21T19:04:19Z

Merge series from Peter Ujfalusi : In IPC4 all DSP loadable executable is a 'library' containing modules. The main or basefw is also a library which contains multiple modules. IPC4 allows to use loadable libraries to extend the functionality of the booted basefw. This series adds support for loading external libraries in case they are needed by the loaded topology file. The libraries must be placed to a specific firmware directory (fw_lib_prefix), which is: intel/avs-lib|sof-ipc4-lib/ followed by the platform name and in case of community key use a 'community' directory. For example for upx-i11 (community key): intel/avs-lib/tgl/community is the default path. The name of the library should be the UUID of the module it contains since the library loading is going to look for the file as .bin In case there is a need to bundle multiple modules into single library, symlinks can be used to point to the file: module_boundle.bin .bin -> module_boundle.bin .bin -> module_boundle.bin .bin -> module_boundle.bin But note that in this case all modules will be loaded to the DSP since only the whole library can be loaded, not individual modules.

ASoC: SOF: Intel: Add ipc4 library loading implementation

2022-10-21T12:05:07Z

On Intel HDA platforms the library loading is done via DMA and an IPC message is also need to be sent to initiate the downloading of the new library. Co-developed-by: Ranjani Sridharan Signed-off-by: Ranjani Sridharan Signed-off-by: Peter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Reviewed-by: Chao Song Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20221020121238.18339-16-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

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: ipc4/Intel: Improve and enable IPC error dump

2022-09-23T19:46:25Z

Merge series from Peter Ujfalusi : 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.

ASoC: SOF: Intel: cnl: Add separate ops for ipc_dump for IPC4

2022-09-23T13:53:17Z

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