ASoC: SOF: Intel: clarify Copyright information

For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.

Remove the "

ASoC: SOF: Intel: clarify Copyright information

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: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: Remove duplicated code in sof_suspend

Over time the function has changed and now there is no need to have the
duplicated sof_fw_trace_suspend() and sof_suspend_clients() in the
if (ta

ASoC: SOF: pm: Remove duplicated code in sof_suspend

Over time the function has changed and now there is no need to have the
duplicated sof_fw_trace_suspend() and sof_suspend_clients() in the
if (target_state == SOF_DSP_PM_D0) branch.

Remove it and add a simple check with a single goto statement.

Reviewed-by: Daniel Baluta <[email protected]>
Reviewed-by: Paul Olaru <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: save io region state in case of errors in resume

If there are failures in DSP runtime resume, the device state will not
reach active and this makes it impossible e.g. to retrieve a po

ASoC: SOF: pm: save io region state in case of errors in resume

If there are failures in DSP runtime resume, the device state will not
reach active and this makes it impossible e.g. to retrieve a possible
DSP panic dump via "exception" debugfs node. If
CONFIG_SND_SOC_SOF_DEBUG_ENABLE_DEBUGFS_CACHE=y is set, the data in
cache is stale. If debugfs cache is not used, the region simply cannot
be read.

To allow debugging these scenarios, update the debugfs cache contents in
resume error handler. User-space can then later retrieve DSP panic and
other state via debugfs (requires SOF debugfs cache to be enabled in
build).

Reported-by: Curtis Malainey <[email protected]
Link: https://github.com/thesofproject/linux/issues/4274
Signed-off-by: Kai Vehmanen <[email protected]
Reviewed-by: Pierre-Louis Bossart <[email protected]
Reviewed-by: Ranjani Sridharan <[email protected]
Reviewed-by: Curtis Malainey <[email protected]
Reviewed-by: Péter Ujfalusi <[email protected]
Signed-off-by: Peter Ujfalusi <[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]

show more ...

ASoC: SOF: pm: Tear down pipelines only if DSP was active

With PCI if the device was suspended it is brought back to full
power and then suspended again.

This doesn't happen when device is describe

ASoC: SOF: pm: Tear down pipelines only if DSP was active

With PCI if the device was suspended it is brought back to full
power and then suspended again.

This doesn't happen when device is described via DT.

We need to make sure that we tear down pipelines only if the device
was previously active (thus the pipelines were setup).

Otherwise, we can break the use_count:

[ 219.009743] sof-audio-of-imx8m 3b6e8000.dsp:
sof_ipc3_tear_down_all_pipelines: widget PIPELINE.2.SAI3.IN is still in use: count -1

and after this everything stops working.

Fixes: d185e0689abc ("ASoC: SOF: pm: Always tear down pipelines before DSP suspend")
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Signed-off-by: Daniel Baluta <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: Add support for DSPless mode

Via the SOF_DBG_DSPLESS_MODE sof_debug flag the SOF stack can be asked to
not use the DSP for audio.

The core's support for DSPless mode is only going to be

ASoC: SOF: Add support for DSPless mode

Via the SOF_DBG_DSPLESS_MODE sof_debug flag the SOF stack can be asked to
not use the DSP for audio.

The core's support for DSPless mode is only going to be enabled if the
platform reports that it can be used without DSP.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: Extend the optionality of IPC ops to IPC as well

The IPC ops are optional, but they require that the ops struct is to be
allocated with all callbacks set to NULL.

Update the code to

ASoC: SOF: pm: Extend the optionality of IPC ops to IPC as well

The IPC ops are optional, but they require that the ops struct is to be
allocated with all callbacks set to NULL.

Update the code to extend the optionality to:
sdev->ipc == NULL
sdev->ipc->ops == NULL
sdev->ipc->ops->[pm/tplg] == NULL (treated optional for pm currently)
sdev->ipc->ops->[pm/tplg]->ops == NULL (treated optional currently)

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: Always tear down pipelines before DSP suspend

When the DSP is suspended while the firmware is in the crashed state, we
skip tearing down the pipelines. This means that the widget refe

ASoC: SOF: pm: Always tear down pipelines before DSP suspend

When the DSP is suspended while the firmware is in the crashed state, we
skip tearing down the pipelines. This means that the widget reference
counts will not get to reset to 0 before suspend. This will lead to
errors with resuming audio after system resume. To fix this, invoke the
tear_down_all_pipelines op before skipping to DSP suspend.

Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Curtis Malainey <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: Set target state earlier

If the DSP crashes before the system suspends, the setting of target state
will be skipped because the firmware state will no longer be
SOF_FW_BOOT_COMPLETE.

ASoC: SOF: pm: Set target state earlier

If the DSP crashes before the system suspends, the setting of target state
will be skipped because the firmware state will no longer be
SOF_FW_BOOT_COMPLETE. This leads to the incorrect assumption that the
DSP should suspend to D0I3 instead of suspending to D3. To fix this,
set the target_state before we skip to DSP suspend even when the DSP has
crashed.

Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Curtis Malainey <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: add definitions for S4 and S5 states

We currently don't have a means to differentiate between S3, S4 and
S5. Add definitions so that we have select different code paths
depending on t

ASoC: SOF: pm: add definitions for S4 and S5 states

We currently don't have a means to differentiate between S3, S4 and
S5. Add definitions so that we have select different code paths
depending on the target state in follow-up patches.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2

The existing code only deals with S0 and S3, let's start adding S1 and S2.

No functional change.

Signed-off-by: Pierre-Louis Bossart <pierre

ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2

The existing code only deals with S0 and S3, let's start adding S1 and S2.

No functional change.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: add definitions for S4 and S5 states

We currently don't have a means to differentiate between S3, S4 and
S5. Add definitions so that we have select different code paths
depending on t

ASoC: SOF: pm: add definitions for S4 and S5 states

We currently don't have a means to differentiate between S3, S4 and
S5. Add definitions so that we have select different code paths
depending on the target state in follow-up patches.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2

The existing code only deals with S0 and S3, let's start adding S1 and S2.

No functional change.

Signed-off-by: Pierre-Louis Bossart <pierre

ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2

The existing code only deals with S0 and S3, let's start adding S1 and S2.

No functional change.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: Switch to IPC generic firmware tracing

Introduce new, generic API for firmware tracing with sof_fw_trace_ prefix
and switch to use it.
At the same time the old IPC3 code can be dropped fr

ASoC: SOF: Switch to IPC generic firmware tracing

Introduce new, generic API for firmware tracing with sof_fw_trace_ prefix
and switch to use it.
At the same time the old IPC3 code can be dropped from trace.c, which is
now a generic wrapper for the firmware tracing ops.

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]>

show more ...

ASoC: SOF: remove incorrect clearing of prepared flag

When the system is suspended while a PCM is paused, it doesn't receive
the SUSPEND trigger. So, the SOF driver has to ensure that the PCM and
th

ASoC: SOF: remove incorrect clearing of prepared flag

When the system is suspended while a PCM is paused, it doesn't receive
the SUSPEND trigger. So, the SOF driver has to ensure that the PCM and
the widgets associated with the paused PCM are freed in the firmware
during suspend. This is handled in the
sof_tear_down_left_over_pipelines() call. But since the state of this
PCM is SUSPENDED, we end up clearing the prepared flag for the PCM
before freeing it. This results in IPC errors while freeing the widgets.
But because the widget use_counts are reset to 0 even though the IPC
fails, releasing the paused stream after resuming from suspend proceeds
normally.

Fix the IPC errors by removing the clearing of the prepared flag in
sof_set_hw_params_upon_resume(). In fact, we can remove the
sof_set_hw_params_upon_resume() and call
snd_sof_dsp_hw_params_upon_resume() directly. This will ensure that the
PCM is freed in the firmware before the IPC's for freeing the widgets
are sent.

BugLink: https://github.com/thesofproject/linux/issues/3543
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Ranjani Sridharan <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: disable dma trace in s0ix

When system enters s0ix, the dma trace won't be used. Otherwise,
the DMA will access the host memory, which will prevent entering
S0ix. Driver has notified firmw

ASoC: SOF: disable dma trace in s0ix

When system enters s0ix, the dma trace won't be used. Otherwise,
the DMA will access the host memory, which will prevent entering
S0ix. Driver has notified firmware not to send message through
dma trace. Let's also trigger stop dma trace in driver side.

Signed-off-by: Libin Yang <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Ranjani Sridharan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: extend the interface to stop DMA trace

Change the interface to stop the DMA trace for suspend. Replace the
snd_sof_init_trace_ipc() and snd_sof_release_trace() calls with more
explicit in

ASoC: SOF: extend the interface to stop DMA trace

Change the interface to stop the DMA trace for suspend. Replace the
snd_sof_init_trace_ipc() and snd_sof_release_trace() calls with more
explicit interface for PM (the sole user for this interface).

The new snd_sof_trace_suspend() call takes the target PM state as argument,
allowing the trace implementation to decide how to handle the transition.
Use this information to release DMA resources only if DSP is suspended and
will not remain in D0.

Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Libin Yang <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Ranjani Sridharan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: topology: Add ops for setting up and tearing down pipelines

Introduce two new ops, set_up_all_pipelines and tear_down_all_pipelines
in struct ipc_tplg_ops and define these for IPC3.

Sign

ASoC: SOF: topology: Add ops for setting up and tearing down pipelines

Introduce two new ops, set_up_all_pipelines and tear_down_all_pipelines
in struct ipc_tplg_ops and define these for IPC3.

Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: Make sof_suspend/resume IPC agnostic

Add a new set of IPC ops for PM with the ctx_save and ctx_restore ops
for suspend/resume and implement the ops for IPC3.

Signed-off-by: Ranjani Sridh

ASoC: SOF: Make sof_suspend/resume IPC agnostic

Add a new set of IPC ops for PM with the ctx_save and ctx_restore ops
for suspend/resume and implement the ops for IPC3.

Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: sof-client: Add support for clients not managed by pm framework

Some SOF client can be of 'passive' type, meaning that they do not handle
PM framework callbacks by themselves but rely on

ASoC: SOF: sof-client: Add support for clients not managed by pm framework

Some SOF client can be of 'passive' type, meaning that they do not handle
PM framework callbacks by themselves but rely on the auxiliary driver's
suspend and resume callbacks to be notified about the core's suspend or
resume event.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pm: Force DSP off on suspend in BOOT_FAILED state also

Try to force the DSP to be turned off next time if the fw_state is either
CRASHED or BOOT_FAILED when a suspend happens in order to

ASoC: SOF: pm: Force DSP off on suspend in BOOT_FAILED state also

Try to force the DSP to be turned off next time if the fw_state is either
CRASHED or BOOT_FAILED when a suspend happens in order to attempt a clean
boot to recover.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: Set SOF_FW_BOOT_FAILED in case we have failure during boot

Change the fw_state to SOF_FW_BOOT_FAILED if we encountered an error during
booting the firmware.

Signed-off-by: Peter Ujfalusi

ASoC: SOF: Set SOF_FW_BOOT_FAILED in case we have failure during boot

Change the fw_state to SOF_FW_BOOT_FAILED if we encountered an error during
booting the firmware.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: Introduce new firmware state: SOF_FW_CRASHED

The SOF_FW_CRASHED state is meant to indicate the unfortunate case when the
firmware has crashed after a successful boot.

IPC tx timeout is n

ASoC: SOF: Introduce new firmware state: SOF_FW_CRASHED

The SOF_FW_CRASHED state is meant to indicate the unfortunate case when the
firmware has crashed after a successful boot.

IPC tx timeout is not treated as indication of a firmware crash as it tends
to happen regularly while the firmware is operational.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Paul Olaru <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: pipelines: Harmonize all functions to use struct snd_sof_dev

First thing the pipelines function which have "struct device *dev" as
parameter do is:
struct snd_sof_dev *sdev = dev_get_drvd

ASoC: SOF: pipelines: Harmonize all functions to use struct snd_sof_dev

First thing the pipelines function which have "struct device *dev" as
parameter do is:
struct snd_sof_dev *sdev = dev_get_drvdata(dev);

and in all cases the passed dev is actually coming from sdev->dev.

Skip this steps and pass directly the sdev to all pipelines related
functions as few of them already does this.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: Introduce macro to set the firmware state

Add sof_set_fw_state() macro to wrap the sdev->fw_state management to allow
actions to be taken when certain state is set or when state is changi

ASoC: SOF: Introduce macro to set the firmware state

Add sof_set_fw_state() macro to wrap the sdev->fw_state management to allow
actions to be taken when certain state is set or when state is changing.

Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

ASoC: SOF: topology: Add kernel parameter for topology verification

Add a kernel debug flag to enable a one-shot topology
verification for all pipelines including the dynamic
ones. If the debug flag

ASoC: SOF: topology: Add kernel parameter for topology verification

Add a kernel debug flag to enable a one-shot topology
verification for all pipelines including the dynamic
ones. If the debug flag is set, all the topology
component loading will be verified during the complete
callback.

Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Signed-off-by: Daniel Baluta <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...