mbox series

[v5,00/17] ASoC: Intel: AVS - Audio DSP for cAVS

Message ID 20220311153544.136854-1-cezary.rojewski@intel.com (mailing list archive)
Headers show
Series ASoC: Intel: AVS - Audio DSP for cAVS | expand

Message

Cezary Rojewski March 11, 2022, 3:35 p.m. UTC 
A continuation of cleanup work of Intel SST solutions found in
sound/soc/intel/. With two major chapters released last year catpt [1]
and removal of haswell solution [2], time has come for Skylake-driver.

Througout 2019, 2020 and 2021 Skylake-driver has had many fixes applied
and even attempts of refactors as seen in fundamental overhaul [3], IPC
flow adjustments [4] and LARGE_CONFIG overhaul [5] series.
Unfortunately, story repeats itself - problems are found within the core
of a driver. Painting it with different colors does not change the fact
that is it still a house of cards. As changes needed to address those
issues would make Skylake solution incompatible with its previous
revisions, a decision has been made to provide a new solution instead.
In time it would deprecate and replace Skylake-driver.

That solution has been called AVS - from AudioDSP architecture name:
Audio-Voice-Speech. It is meant to provide support for the exact same
range of platforms as its predecessor: SKL, KBL, AML and APL.

Note: this series is dependent upon HDA-series [6] which exposes several
codec-organization functions allowing for reduced code size on
avs-driver side.

Note: this series does not add fully functional driver as its size would
get out of control. Here, focus is put on adding IPC protocol and code
loading code.


Changes v4 -> v5:
- dropped WARN()s usage as requested by Pierre
- another round of typo fixes
- aligned code to make use of 100-char-per-line limit
- updated the dates in source and header files, it's 2022 already


Changes v3 -> v4:
- noted the limitations of LARGE_CONFIG_GET handler and dropped
  non-inclusive wording as requested by Pierre and Ranjani
- code loading flow now verifies if power downing non-MAIN_CORE fails
- commented kfree() usage in FW_CONFIG and HW_CONFIG getters


Changes v2 -> v3:
- fixed variable initialization errors mentioned by sparse


Changes v1 -> v2:
Almost all updates here are thanks to feedback from Pierre.
- several comments and few kernel-docs have been added in areas which
  felt more or less unclear
- avs_ipc_wait_busy_completion() now spins up to 'repeats_left' number
  of times before giving up
- 'adsp_ba' field of struct avs_dev has been renamed to 'dsp_ba'
- 'dops' field of struct avs_spec has been renamed to 'dsp_ops'
- IPC abstraction has been simplified: SKL_ADSP_REG_HIP* regs are used
  directly
- fixed allnoconfig with AVS enabled compilation issues
- fixed code loading error paths: previously requested firmware is now
  released before function return to the caller
- code and function arguments tied to D0IX support have been removed
  from this patchset and will be part of followup series adding that
  feature instead
- enriched dev_err() messages in avs_dsp_get_core() and
  avs_dsp_put_core()
- numerous wording fixes used in power/reset/stall DSP operations


Changes RFC v1 [7]: -> v1:
- separated HDA codec-organization patches, path and topology handling,
  PCM and complementary features such as recovery from this series to
  ease the review process
- fixed EXPORT_SYMBOL_GPL for exported members of ASoC framework
- result of stall() is now checked when sending ROM message
- result of snd_hdac_ext_stream_set_spib() is now checked when loading
  basefw
- if basefw is not ready, notification processing is now skipped
- documented several topology parsing helpers


Changes [internal] RFC v2 -> [public] RFC v1:
- dropped any sysfs related changes from this series, moved to follow up
  one
- dropped entire subscription-mechanism found in ipc.c. Handlers that
  are delegated to service certain firmware notifications are now called
  directly
- fixed kernel doc for snd_soc_dapm_new_dai_widgets() as reported by ikp
- prefixed snd_hda_codec_device_init() as suggested by Amadeo
- improved comments for d0ix transitions for APL-based platforms as
  suggested by Pierre
- a ton of spelling related fixes in most of the commit messages
- fixed remaining warnings pointed by scan-build (variable assigned but
  not used)
- replaced most of 'cAVS X.Y' expression usages with 'platform-based'
  equivalents as suggested by Pierre e.g.: cAVS 1.5 -> SKL-based


Changes [internal] RFC v1 -> [internal] RFC v2:
- fixed memleak caused by lack of kfree(vols) if memory allocation fails
  in avs_peakvol_create() as reported by Curtis
- fixed missing 'i' iterator incrementation in avs_widget_ready()
  causing reference loss as reported by Curtis
- replace hardcode: 0x40 usage with snd_hdac_calc_stream_format as
  suggested by Curtis.
  In consequence, readability for all code loading (CL) procedues has
  increased and such approach auto-documents the CL stream preparation

- updated behavior of all index-fetching functions found in utils.c:
  avs_module_entry_index(), avs_module_id_entry_index() and follow ups:
  avs_get_module_entry(), avs_get_module_id_entry() to better conform to
  linux-kernel standard when no entry is found (return -ENOENT) rather
  than C++ standard (return -1, what in kernel case translated to -EPERM)
  as suggested by Curtis and Peter
- several suggestions have been made regarding spacing, and so far, I've
  agreed and applied with all of them. None proposed seemed out of place
  or redundant

- avs_path_stop() renamed to avs_path_pause() pipeline states are
  represented by RESET/PAUSED/RUNNING. avs_path_reset() and
  avs_path_run() were already there and avs_path_stop() just didn't look
  cohesive
- added missing parsers for num_output_pin and num_input_pin which are
  required for custom modules such as WAVES or DSM
- dropped 'priv_param_length' from custom module descriptor as this
  field is obsolete in firmware

- parse_dictionary() has been split into parse_dictionary_header() and
  parse_dictionary_entries() to drop code duplication present in several
  parsing function which could not re-use entire parse_dictionary()
- added avs_tplg_vendor_array_lookup_next() and
  avs_tplg_vendor_entry_next() to drop code duplicated present in several
  parsing functions. This change greatly impacted readability of all
  parsers
- parsing helpers such avs_tplg_vendor_array_lookup() now return offset
  by updating specified in function argument list u32 *offset variable.
  This is to address problem when u32 offset would be greater than max
  int, which is the return type for these functions
- AVS_DEFINE_PTR_PARSER() macro has been introduced to drop code
  duplication for all ptr-parsing users

- all struct avs_path_module creators have had their declaration
  updated: function argument *owner ceased to exist as it could already
  be accessed by mod->owner

- fixed the order of operation for conditional paths (e.g.: echo
  reference) so these are no longer controlled by "source" path and
  instead are impacted by state changes of source and sink paths both.
  Previously only source path e.g. playback sourcing echo reference
  would trigger RUNNING status for conditional path. Equivalent RUNNING
  on WoV path which is in this case sink path, would not do so, leading
  to order-of-operation problems. Behavior has been changed to: both
  source and sink need to be RUNNING for conditional path to be set to
  RUNNING too. PAUSED for either source or sink will cause PAUSED
  transition for conditional path.
- to achieve the above, path states are now saved in 'state' i.e. new
  u32 field for struct avs_path

- resigned from fw_filename field usage in favour of newly added
  tplg_filename for machine board descriptors as suggested by Pierre
- platform descriptor fields have had their names update better reflect
  their purpose as suggested by Pierre
- fixed comp_list missing locking when manipulated
- all message senders now accept request as pointer as suggeseted by
  Peter
- resigned of AZX_ usage for all ADSP-related registers, leaving them
  only for HOST memory space related operations
- fixed disable path for core DSP operations: power/reset/stall as
  reported by Peter

- safety when locking between received responses (reply vs notification)
  has been lowered as suggested by Pierre. Most usages are not performed
  in IRQ context and none is done in hard-IRQ one
- s/master/main/ plus AVS_MAIN_CORE_MASK has replaced ->master_mask
- several functions have had their logging updated - logs have been
  moved to lower level functions as suggested by Pierre
- hdac_ext_stream usage has been streamlined to estream, hdac_streams
  are represented by hstream instead
- hw_params() are resilient to scenarios when they are called mutliple
  times as reported by Pierre
- avs_dsp_enable() now collapses if any of its steps fails as reported
  by Pierre and Peter
- avs_module_ida_empty() now returns value of type bool as suggested by
  Bard


[1]: https://www.spinics.net/lists/alsa-devel/msg116440.html
[2]: https://www.spinics.net/lists/alsa-devel/msg116901.html
[3]: https://www.spinics.net/lists/alsa-devel/msg94199.html
[4]: https://www.spinics.net/lists/alsa-devel/msg92588.html
[5]: https://lore.kernel.org/all/20190808181549.12521-1-cezary.rojewski@intel.com/
[6]: https://lore.kernel.org/alsa-devel/20220207114906.3759800-1-cezary.rojewski@intel.com/T/#t
[7]: https://lore.kernel.org/all/20211208111301.1817725-1-cezary.rojewski@intel.com/


Cezary Rojewski (17):
  ALSA: hda: Add helper macros for DSP capable devices
  ASoC: Export DAI register and widget ctor and dctor functions
  ASoC: Intel: Introduce AVS driver
  ASoC: Intel: avs: Inter process communication
  ASoC: Intel: avs: Add code loading requests
  ASoC: Intel: avs: Add pipeline management requests
  ASoC: Intel: avs: Add module management requests
  ASoC: Intel: avs: Add power management requests
  ASoC: Intel: avs: Add ROM requests
  ASoC: Intel: avs: Add basefw runtime-parameter requests
  ASoC: Intel: avs: Firmware resources management utilities
  ASoC: Intel: avs: Declare module configuration types
  ASoC: Intel: avs: Dynamic firmware resources management
  ASoC: Intel: avs: General code loading flow
  ASoC: Intel: avs: Implement CLDMA transfer
  ASoC: Intel: avs: Code loading over CLDMA
  ASoC: Intel: avs: Code loading over HDA

 include/sound/hdaudio.h         |   3 +
 include/sound/hdaudio_ext.h     |  50 +++
 include/sound/soc-dapm.h        |   1 +
 sound/soc/intel/Kconfig         |  12 +
 sound/soc/intel/Makefile        |   1 +
 sound/soc/intel/avs/Makefile    |   6 +
 sound/soc/intel/avs/avs.h       | 247 +++++++++++
 sound/soc/intel/avs/cldma.c     | 316 ++++++++++++++
 sound/soc/intel/avs/cldma.h     |  29 ++
 sound/soc/intel/avs/core.c      |  61 +++
 sound/soc/intel/avs/dsp.c       | 302 +++++++++++++
 sound/soc/intel/avs/ipc.c       | 382 ++++++++++++++++
 sound/soc/intel/avs/loader.c    | 608 ++++++++++++++++++++++++++
 sound/soc/intel/avs/messages.c  | 695 +++++++++++++++++++++++++++++
 sound/soc/intel/avs/messages.h  | 752 ++++++++++++++++++++++++++++++++
 sound/soc/intel/avs/registers.h |  75 ++++
 sound/soc/intel/avs/utils.c     | 301 +++++++++++++
 sound/soc/soc-core.c            |   1 +
 sound/soc/soc-dapm.c            |  15 +
 19 files changed, 3857 insertions(+)
 create mode 100644 sound/soc/intel/avs/Makefile
 create mode 100644 sound/soc/intel/avs/avs.h
 create mode 100644 sound/soc/intel/avs/cldma.c
 create mode 100644 sound/soc/intel/avs/cldma.h
 create mode 100644 sound/soc/intel/avs/core.c
 create mode 100644 sound/soc/intel/avs/dsp.c
 create mode 100644 sound/soc/intel/avs/ipc.c
 create mode 100644 sound/soc/intel/avs/loader.c
 create mode 100644 sound/soc/intel/avs/messages.c
 create mode 100644 sound/soc/intel/avs/messages.h
 create mode 100644 sound/soc/intel/avs/registers.h
 create mode 100644 sound/soc/intel/avs/utils.c

Comments

Mark Brown March 11, 2022, 8:22 p.m. UTC | #1 
On Fri, 11 Mar 2022 16:35:27 +0100, Cezary Rojewski wrote:
> A continuation of cleanup work of Intel SST solutions found in
> sound/soc/intel/. With two major chapters released last year catpt [1]
> and removal of haswell solution [2], time has come for Skylake-driver.
> 
> Througout 2019, 2020 and 2021 Skylake-driver has had many fixes applied
> and even attempts of refactors as seen in fundamental overhaul [3], IPC
> flow adjustments [4] and LARGE_CONFIG overhaul [5] series.
> Unfortunately, story repeats itself - problems are found within the core
> of a driver. Painting it with different colors does not change the fact
> that is it still a house of cards. As changes needed to address those
> issues would make Skylake solution incompatible with its previous
> revisions, a decision has been made to provide a new solution instead.
> In time it would deprecate and replace Skylake-driver.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[01/17] ALSA: hda: Add helper macros for DSP capable devices
        commit: c19bd02e9029f0f75b58f4b8662527da74be8985
[02/17] ASoC: Export DAI register and widget ctor and dctor functions
        commit: da0398099a83483014adc509a2845c88ccf672af
[03/17] ASoC: Intel: Introduce AVS driver
        commit: 9fe51c559a862d6c884f6784de26c8f9463187b1
[04/17] ASoC: Intel: avs: Inter process communication
        commit: 2879516fcd6d7ec5972762dbd94859d9221e70d8
[05/17] ASoC: Intel: avs: Add code loading requests
        commit: cb1eb6b5be42799d23f81ffde84ee3537365b0ed
[06/17] ASoC: Intel: avs: Add pipeline management requests
        commit: b956b27b477ae63e92240f813c1027de601df11f
[07/17] ASoC: Intel: avs: Add module management requests
        commit: f14a1c5a9f830025dc8638303ddefd5f731ae4bc
[08/17] ASoC: Intel: avs: Add power management requests
        commit: 469e87ca9a2029c325362496c7b589683a382505
[09/17] ASoC: Intel: avs: Add ROM requests
        commit: 25f414fcdb875e4203ff43f42898367c32df4827
[10/17] ASoC: Intel: avs: Add basefw runtime-parameter requests
        commit: 3322e1688953966da15fcd0ae3183a351e241ea3
[11/17] ASoC: Intel: avs: Firmware resources management utilities
        commit: c1a427e8da9332a5832fd4a5429adede34bfa85f
[12/17] ASoC: Intel: avs: Declare module configuration types
        commit: 580a5912d1fe774f9902b614fa33e1add92ca749
[13/17] ASoC: Intel: avs: Dynamic firmware resources management
        commit: 215e67b2d2de1d8d34a53c440b9a19a732ee6fb0
[14/17] ASoC: Intel: avs: General code loading flow
        commit: b27f452317236b0cbaa94c4498f8241e2ad871b1
[15/17] ASoC: Intel: avs: Implement CLDMA transfer
        commit: 45864e49a05aa446b9d99c464c1a9f46956ed32c
[16/17] ASoC: Intel: avs: Code loading over CLDMA
        commit: 65794fe1a5f6f5fb10fa7b71a762158332144855
[17/17] ASoC: Intel: avs: Code loading over HDA
        commit: 092cf7b26a48a542d9aabfc0f517fa263102a4c1

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
Mark Brown March 11, 2022, 8:24 p.m. UTC | #2 
On Fri, Mar 11, 2022 at 04:35:27PM +0100, Cezary Rojewski wrote:
> A continuation of cleanup work of Intel SST solutions found in
> sound/soc/intel/. With two major chapters released last year catpt [1]
> and removal of haswell solution [2], time has come for Skylake-driver.

I've applied this but please do look at some of the clarifications that
Pierre is asking for - there probably is some room for improvement
there, but nothing that's going to require a restructuring of the whole
codebase so it seems better to apply and look at things incrementally
than to have to recheck the whole series again.  Splitting this into
easier to digest chunks is helping.
Cezary Rojewski March 14, 2022, 6 p.m. UTC | #3 
On 2022-03-11 9:24 PM, Mark Brown wrote:
> On Fri, Mar 11, 2022 at 04:35:27PM +0100, Cezary Rojewski wrote:
>> A continuation of cleanup work of Intel SST solutions found in
>> sound/soc/intel/. With two major chapters released last year catpt [1]
>> and removal of haswell solution [2], time has come for Skylake-driver.
> 
> I've applied this but please do look at some of the clarifications that
> Pierre is asking for - there probably is some room for improvement
> there, but nothing that's going to require a restructuring of the whole
> codebase so it seems better to apply and look at things incrementally
> than to have to recheck the whole series again.  Splitting this into
> easier to digest chunks is helping.

Every comment and review is taken seriously.

I'll sync with the team shortly and proceed with the discussion around 
"avs path" series too. Did not want to spam the list with several 
avs-related topics at once and thus the delay.


Regards,
Czarek