linux.git/sound/soc/sof/intel/cnl.c, branch v6.7

ASoC: SOF: Intel: Use generic names for IPC types

2023-09-19T12:49:11+00:00

Use the new SOF_IPC_TYPE_3, SOF_IPC_TYPE_4 in core code.

No functional changes, just renaming.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Daniel Baluta 
Reviewed-by: Rander Wang 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20230919104226.32239-8-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Intel: add abstraction for SoundWire wake-ups

2023-08-07T22:09:45+00:00

The existing code cannot work for LunarLake, let's add a layer of
abstraction.

No functional change in this patch.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Rander Wang 
Link: https://lore.kernel.org/r/20230807210959.506849-17-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Intel: Split the set_power_op for IPC3 and IPC4

2023-04-20T11:52:02+00:00

Suspending to S0iX with IPC3 requires the PM_GATE IPC to be sent again
to stop the DMA trace. But with IPC4, this is not needed as the trace is
stopped with the LARGE_CONFIG_SET IPC. Also, sending the MOD_D0IX IPC to
set the D0I3 state again when the DSP is in D0I3 already results in an
imbalance in PM runtime states in the firmware. So split the
set_power_state ops for IPC3 and IPC4 to avoid sending the MOD_D0IX IPC
when the DSP is already in D0I3 with IPC4.

Signed-off-by: Ranjani Sridharan 
Reviewed-by: Rander Wang 
Reviewed-by: Bard Liao 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230420104714.29573-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Intel: Enable d0i3 work for ipc4

2023-02-14T13:25:14+00:00

Schedule a delayed work for d0i3 entry after every non-pm ipc msg.

Signed-off-by: Rander Wang 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Péter Ujfalusi 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20230214103345.30669-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

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

2022-11-23T15:32:05+00:00

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:02+00:00

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:07+00:00

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:19+00:00

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:07+00:00

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:45+00:00

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