linux.git/sound/soc/sof/sof-priv.h, branch v5.16

ASoC: SOF: prepare code to allocate IPC messages in fw_ready

2021-10-08T12:51:16+00:00

The fixed maximum size of IPC message does not allow for large
transfers, e.g. for filter data. Currently such messages will
be divided into smaller pieces and sent to firmware in multiple
chunks. For future IPC, this strategy is not suitable.

The maximum IPC message size is limited by host box size which
can be known when firmware is ready, so the fw_ready callback
can allocate IPC messages with platform-specific sizes instead
of the current fixed-size.

To be compatible with released firmware, current platforms will
still use SOF_IPC_MSG_MAX_SIZE. For future platforms, there will
be a new fw_ready function and the platform-specific allocation
will take place there.

Signed-off-by: Rander Wang 
Reviewed-by: Bard Liao 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Signed-off-by: Peter Ujfalusi 
Message-Id: <20211008093836.28210-1-peter.ujfalusi@linux.intel.com>
Signed-off-by: Mark Brown

Merge series "Introduce new SOF helpers" from Daniel Baluta

2021-10-07T21:24:58+00:00

Daniel Baluta :

From: Daniel Baluta 

This patchseries adds new helpers in order to reduce code duplication
and prepare for compress audio support with SOF.

Bud Liviu-Alexandru (1):
  ASoC: SOF: Make Intel IPC stream ops generic

Daniel Baluta (3):
  ASoC: SOF: Introduce snd_sof_mailbox_read / snd_sof_mailbox_write
    callbacks
  ASoC: SOF: imx: Use newly introduced generic IPC stream ops
  ASoC: SOF: Introduce fragment elapsed notification API

 sound/soc/sof/Kconfig                         |  4 ++
 sound/soc/sof/Makefile                        |  3 +-
 sound/soc/sof/compress.c                      | 51 +++++++++++++++++++
 sound/soc/sof/imx/Kconfig                     |  2 +
 sound/soc/sof/imx/imx8.c                      | 39 +++++++-------
 sound/soc/sof/imx/imx8m.c                     | 26 ++++------
 sound/soc/sof/intel/Makefile                  |  3 --
 sound/soc/sof/intel/apl.c                     |  4 ++
 sound/soc/sof/intel/bdw.c                     | 12 +++--
 sound/soc/sof/intel/byt.c                     | 24 ++++++---
 sound/soc/sof/intel/cnl.c                     |  4 ++
 sound/soc/sof/intel/icl.c                     |  4 ++
 sound/soc/sof/intel/pci-tng.c                 | 12 +++--
 sound/soc/sof/intel/tgl.c                     |  4 ++
 sound/soc/sof/ipc.c                           |  6 ++-
 sound/soc/sof/ops.h                           | 15 ++++++
 sound/soc/sof/pcm.c                           |  7 ++-
 sound/soc/sof/sof-audio.h                     | 11 +++-
 sound/soc/sof/sof-priv.h                      | 28 ++++++----
 .../sof/{intel/intel-ipc.c => stream-ipc.c}   | 50 +++++++++---------
 sound/soc/sof/topology.c                      |  6 ++-
 21 files changed, 218 insertions(+), 97 deletions(-)
 create mode 100644 sound/soc/sof/compress.c
 rename sound/soc/sof/{intel/intel-ipc.c => stream-ipc.c} (58%)

--
2.27.0

ASoC: SOF: Make Intel IPC stream ops generic

2021-10-07T15:57:54+00:00

This operations should be generic as there is nothing Intel
specific. This works well for NXP i.MX8 stream IPC ops.

We start by moving sof/intel/intel-ipc.c into sof/stream-ipc.c and
rename the functions to be generic.

Notice that we use newly introduced snd_sof_dsp_mailbox_read
instead of sof_mailbox_read, to make sure that we are not
bound to existing MMIO memory access, and we allow platform
to implement their own memory access routines.

Signed-off-by: Daniel Baluta 
Signed-off-by: Bud Liviu-Alexandru 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Daniel Baluta 
Reviewed-by: Péter Ujfalusi 
Link: https://lore.kernel.org/r/20211004152147.1268978-3-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown

ASoC: SOF: Introduce snd_sof_mailbox_read / snd_sof_mailbox_write callbacks

2021-10-07T15:57:53+00:00

We need to introduce snd_sof_mailbox_{read/write} in order to provide
a generic way for mailbox access. These routines are optional, each
platform can implement their own specific routines.

So far, all platforms use mmapped I/O thus they can use custom made
routines sof_mailbox_read / sof_mailbox_write that use MMIO.

Signed-off-by: Daniel Baluta 
Signed-off-by: Bud Liviu-Alexandru 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Péter Ujfalusi 
Link: https://lore.kernel.org/r/20211004152147.1268978-2-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown

ASoC: SOF: Introduce macro to set the firmware state

2021-10-07T14:45:36+00:00

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 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Kai Vehmanen 
Link: https://lore.kernel.org/r/20211006110645.26679-15-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Drop SOF_DBG_DUMP_FORCE_ERR_LEVEL and sof_dev_dbg_or_err

2021-10-07T14:45:31+00:00

The sof_dev_dbg_or_err() is only used by intel/hda.c when dumping dsp
debug information.
It was used to print the extended rom status in either dev_dbg (during
retries) and finally with dev_err, but other lines were printed with
dev_err regardless.

Since we now only print the dump once, the flag and the macros is no longer
needed.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20211006110645.26679-11-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: debug: Add SOF_DBG_DUMP_OPTIONAL flag for DSP dumping

2021-10-07T14:45:29+00:00

The new SOF_DBG_DUMP_OPTIONAL flag can be used to mark a DSP dump that
should only be printed when the SOF_DBG_PRINT_ALL_DUMPS sof_core_debug
flag is set, otherwise it should be ignored and not printed.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Link: https://lore.kernel.org/r/20211006110645.26679-9-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: Print the dbg_dump and ipc_dump once to reduce kernel log noise

2021-10-07T14:45:25+00:00

Do not print the dump more than once to keep the kernel log cleaner in case
of a firmware failure.

When the DSP is rebooted due to suspend or runtime_suspend reset the flags
to re-enable the dump prints.

Add also a debug flag to print all dumps to get more coverage if needed.

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

ASoC: SOF: core: debug: force all processing on primary core

2021-10-07T14:45:21+00:00

The topology file currently provides information on which
pipeline/processing is to be scheduled on which DSP core.

To help diagnose potential issues, this patch provides an override of
the 'core' tokens to use the primary core (typically core0). Of course
this may result in a Core0 activity that exceeds hardware
capabilities, so this should only be used when the total processing
fits on DSP - possibly using firmware mockup processing and stubs.

No new dmesg log was added to avoid adding noise during topology
parsing, but the existing logs will show the primary core being used.

This is strictly for validation/debug, products should NEVER use this
override, the topology is assumed to be the description of the
firmware graph.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Kai Vehmanen 
Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20211006110645.26679-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: topology: allow for dynamic pipelines override for debug

2021-10-05T12:09:55+00:00

For debug and community support, it's useful to expose a kernel
parameter to prevent the use of dynamic pipelines exposed in a
topology file, or conversely to force an existing topology to use
dynamic pipelines.

Add an override bit and an enable bit which is valid only when the
override is set.

For products, the intent is that the topology file defines the
behavior, these two bits are only intended for diagnosis and
performance checks.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Ranjani Sridharan 
Link: https://lore.kernel.org/r/20211004212729.199550-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown