Peter Ujfalusi <[email protected]> says:
This series fixes some issues left to the first version
sof_ipc4_mod_init_ext_dp_memory_data payload building code. The
payload to specify memory requirements of Data Processing components,
running as independent processes in SOF firmware.
But more importantly it adds a payload of similar purpose to the
pipeline create message, e.g. sof_ipc4_glb_pipe_payload. It sums up
the memory requirements of individual Low Latency components in the
pipeline and sends the summed up values in pipeline create message.
Link: https://patch.msgid.link/[email protected]
Fix a copy-paste error in struct sof_ipc4_mod_init_ext_dp_memory_data
datamember comments. And while at it, drop the overly specific notes
on the datamember values. The values are coming from topology and
and what to do with them is decided in SOF FW. Its a bad idea to try
to document their meaning in detail here. The Linux driver is only
passing the values.
Signed-off-by: Jyri Sarha <[email protected]>
Reviewed-by: Liam Girdwood <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
The firmware will be able to only save and restore the context related to
library management.
This means that even without a full context save, the libraries do not
need to be re-loaded to the firmware after second or consecutive boots.
This is reported via the FW_READY notification, where BIT(15) indicates:
0 - the library restore is not done
1 - library restore is done
This bit is only valid if full context save is not enabled, full context
save is by definition saves and restores the library related book-keeping
as well.
Add a new flag to tell the platform code if the libraries have been
restored, no need to reload them after boot.
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Liam Girdwood <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
ACE3 (Panther Lake) introduced support for microphone privacy feature which
can - in hardware - mute incoming audio data based on a state of a physical
switch.
The change in the privacy state is delivered through interface IP blocks
and can only be handled by the link owner.
In Intel platforms Soundwire is for example host owned, so the interrupt
can only be handled by the host.
Since the input stream is going to be muted by hardware, the host needs to
send a message to firmware about the change in privacy so it can execute a
fade out/in to enhance user experience.
The support for microphone privacy can be queried from the HW_CONFIG data
under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the
core will pass it to platform code if the intel_configure_mic_privacy()
callback is provided.
Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC
message to the firmware on state change.
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Liam Girdwood <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Reviewed-by: Cezary Rojewski <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
With the module notification message the information about the notification
is provided via the mailbox with the sof_ipc4_notify_module_data struct.
It contains the module and instance id of the sender of the notification,
the event_id and optionally additional data which is module and event
specific.
At the same time add definitions to identify ALSA kcontrol change
notification.
These notifications use standardized event_id, modules must follow this if
they support such notifications:
upper 16 bit: 0xA15A as a magic identification value
lower 16 bit: param_id of the changed control
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
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 <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Chao Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
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 <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
IPC4 uses the SET_DX message to enable/disable cores managed by the DSP.
The dx_state.core_mask indicates which core is going to change state,
the dx_state.dx_mask is to power on (1) or off (0) the core.
In the dx_mask only those bits (cores) checked which bit is set in the
core_mask, other bits (cores) ignored.
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Mark Brown