kernel/sound/soc/sof/intel/mtl.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: mtl: move SoundWire interrupt enabling to callback

2022-11-23T15:32:04Z

There's no real rationale for enabling the SoundWire interrupt in the init, this can be done from the enable_sdw_irq() callback. 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-5-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: mtl: factor interrupt enable/disable interrupt functions

2022-11-23T15:32:03Z

The offsets and sequences are identical for interrupt enabling and disabling, we can refactor the code with a single routine and a boolean. 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-4-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: MTL: fix comment error

2022-10-26T13:18:32Z

Fix small cut-and-paste error in comment. Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Signed-off-by: Yong Zhi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20221024164350.234830-1-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