user/sven/linux.git/include/sound/sof, branch v6.7.9

ASoC: SOF: ipc4-mtrace: move debug slot related definitions to header.h

2023-09-19T12:48:45Z

The macro definitions of debug slot can be used by gdb, telemetry and mtrace log, so move these definitions to header.h from mtrace. Then these macro definitions can be shared Signed-off-by: Rander Wang Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20230919092416.4137-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4: Add new message type: SOF_IPC4_GLB_LOAD_LIBRARY_PREPARE

2023-09-15T12:15:33Z

On Intel platforms there is a strict order requirement for the DMA programming: DSP side configures the buffer and sets the GEN bit Host side sets the RUN bit. In order to follow this flow, a new global message type has been added to prepare the DSP side of the DMA: host sends LOAD_LIBRARY_PREPARE with the dma_id DSP side sets its buffer and sets the GEN bit Host sets the RUN bit Host sends LOAD_LIBRARY with dma_id and lib_id DSP receives the library data. It is up to the platform code to use the new prepare stage message and how to handle the reply to it from the firmware, which can indicate that the message type is not supported/handled. In this case the kernel should proceed to the LOAD_LIBRARY stage assuming a single stage library loading: host sends LOAD_LIBRARY_PREPARE with the dma_id DSP replies that the message type is not supported/handled Host acknowledges the return code and sets the RUN bit Host sends LOAD_LIBRARY with dma_id and lib_id DSP receives the library data. Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Ranjani Sridharan Reviewed-by: Chao Song Link: https://lore.kernel.org/r/20230915114018.1701-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Deprecate invalid enums in IPC3

2023-07-31T22:24:03Z

The switch component was never completed and sat half empty for over 3 years. It was recently deleted. For modern components this would require not change in the kernel but since this was a legacy allocation from the enum days of IPC3 we should mark the respective enum as deprecated. The splitter component was never even got a source file in the firmware. Therefore also delete it since this is not needed. Reviewed-by: Bard Liao Signed-off-by: Curtis Malainey Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230731213242.434594-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4: Add macros for chain-dma message bits

2023-03-21T12:13:30Z

In the chained DMA mode, the firmware allocates buffers for the host and link DMA, and takes care of copying data between host- and link-DMA buffers in a low-latency thread. This is different to a regular pipeline, no processing is allowed, and the connection between host- and link DMA is handled with a dedicated IPC. This patch exposes the macros needed to create the required IPC messages. Signed-off-by: Jyri Sarha Reviewed-by: Rander Wang Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20230321092654.7292-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4: Add macro to set the core_id in create_pipe message

2023-03-07T13:58:12Z

The create pipeline message can carry the target code_id which is set to 0 at the moment. Add macros to set the core_id in the message extension. Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230307123556.31328-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-pcm: Use the PCM stream's pipeline_info during trigger

2023-01-27T12:14:07Z

Use the list of pipelines in the PCM stream's pipeline info to trigger the pipelines in the right order. Add a helper for triggering pipelines in batch mode that will be used to trigger multiple pipelines at the same time. Signed-off-by: Ranjani Sridharan Reviewed-by: Libin Yang Reviewed-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20230127120031.10709-12-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Add DAI configuration support for AMD platforms.

2022-11-29T12:56:09Z

Add support for configuring sp and hs DAI from topology. Signed-off-by: V sujith kumar Reddy Link: https://lore.kernel.org/r/20221129100102.826781-1-vsujithkumar.reddy@amd.corp-partner.google.com Signed-off-by: Mark Brown

ASoC: Merge up fixes

2022-11-29T12:55:51Z

Merge the fixes branch up so we can apply further AMD work.

ASoC: SOF: dai: move AMD_HS to end of list to restore backwards-compatibility

2022-11-18T11:39:46Z

The addition of AMD_HS breaks Mediatek platforms by using an index previously allocated to Mediatek. This is a backwards-compatibility issue and needs to be fixed. All firmware released by AMD needs to be re-generated and re-distributed. Fixes: ed2562c64b4f ("ASoC: SOF: Adding amd HS functionality to the sof core") Link: https://github.com/thesofproject/sof/issues/6615 Link: https://lore.kernel.org/alsa-devel/36a45c7a-820a-7675-d740-c0e83ae2c417@collabora.com/ Reported-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Daniel Baluta Reviewed-by: Basavaraj Hiregoudar Reviewed-by: V sujith kumar Reddy Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20221117232120.112639-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3-topology: use old pipeline teardown flow with SOF2.1 and older

2022-11-01T18:28:07Z

Originally in commit b2ebcf42a48f ("ASoC: SOF: free widgets in sof_tear_down_pipelines() for static pipelines"), freeing of pipeline components at suspend was only done with recent FW as there were known limitations in older firmware versions. Tests show that if static pipelines are used, i.e. all pipelines are setup whenever firmware is powered up, the reverse action of freeing all components at power down, leads to firmware failures with also SOF2.0 and SOF2.1 based firmware. The problems can be specific to certain topologies with e.g. components not prepared to be freed at suspend (as this did not happen with older SOF kernels). To avoid hitting these problems when kernel is upgraded and used with an older firmware, bump the firmware requirement to SOF2.2 or newer. If an older firmware is used, and pipeline is a static one, do not free the components at suspend. This ensures the suspend flow remains backwards compatible with older firmware versions. This limitation does not apply if the product configuration is updated to dynamic pipelines. The limitation is not linked to firmware ABI, as the interface to free pipeline components has been available already before ABI3.19. The problem is in the implementation, so firmware version should be used to decide whether it is safe to use the newer flow or not. This patch adds a new SOF_FW_VER() macro to compare SOF firmware release versions. Link: https://github.com/thesofproject/sof/issues/6475 Signed-off-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20221101114913.1292671-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown