1. 25 Apr, 2022 16 commits
  2. 22 Apr, 2022 10 commits
  3. 21 Apr, 2022 9 commits
  4. 20 Apr, 2022 5 commits
    • Minghao Chi's avatar
      ASoC: SOF: using pm_runtime_resume_and_get to simplify the code · b3598fe6
      Minghao Chi authored
      Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
      pm_runtime_put_noidle. This change is just to simplify the code, no
      actual functional changes.
      Reported-by: default avatarZeal Robot <zealci@zte.com.cn>
      Signed-off-by: default avatarMinghao Chi <chi.minghao@zte.com.cn>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20220420030315.2575691-1-chi.minghao@zte.com.cnSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      b3598fe6
    • Ajit Kumar Pandey's avatar
      ASoC: amd: acp: Add pm ops callback in machine driver · fbae863d
      Ajit Kumar Pandey authored
      Add alsa snd_soc_pm_ops callback in ACP machine driver to support
      suspend and resume operation of sound card components
      Signed-off-by: default avatarAjit Kumar Pandey <AjitKumar.Pandey@amd.com>
      Link: https://lore.kernel.org/r/20220420094442.1352717-1-AjitKumar.Pandey@amd.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      fbae863d
    • Mark Brown's avatar
      ASoC: soc-pcm: improve BE state transitions · 2ad1e059
      Mark Brown authored
      Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
      
      With additional tests with the introduction of a 'deep-buffer' PCM
      device mixed with the regular low-latency path, we came up with two
      improvements in the BE state machine and transitions. The short
      explanation is that the BE cannot directly use the trigger commands
      provided by the FE, and a translation is needed to deal with paused
      states.
      2ad1e059
    • Mark Brown's avatar
      ASoC: SOF: add INTEL_IPC4 plumbing · 7ed1bf73
      Mark Brown authored
      Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
      
      The INTEL_IPC4 protocol and firmware architecture will rely on
      different sets of firmware binary and topology files. Some platforms
      will only support INTEL_IPC4, some will support both INTEL_IPC4 and
      SOF_IPC for development, and some will stay with the existing SOF_IPC.
      
      This patchset adds new IPC definitions, and search paths for firmware
      and topology files, along with means to override the default IPC type
      and search paths for development. The firmware binary names are
      aligned with those used by the Intel AVS driver to avoid duplicate
      firmware installs, but the topology will have to differ due to driver
      architecture differences.
      7ed1bf73
    • Mark Brown's avatar
      ASoC: Intel: avs: Topology and path management · e1bbfccf
      Mark Brown authored
      Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
      
      A continuation of avs-driver initial series [1]. This chapter covers
      path management and topology parsing part which was ealier path of the
      main series. The two patches that represented these two subjects in the
      initial series, have been split into many to allow for easier review and
      discussion.
      
      AVS topology is split into two major parts: dictionaries - found within
      ASoC topology manifest - and path templates.
      
      Dictionaries job is to reduce the total amount of memory
      occupied by topology elements. Rather than having every pipeline and
      module carry its own information, each refers to specific entry in
      specific dictionary by provided (from topology file) indexes. In
      consequence, most struct avs_tplg_xxx are made out of pointers.
      
      Path templates are similar to path descriptions found in skylake-driver
      and they describe how given path shall look like in runtime - number of
      modules and pipelines that shape it and how they are laid out. A single
      path template is tied either to FE or BE and thus at most to a single,
      user-visible endpoint when speaking of FE.
      
      Path is a software representation of its ADSP firmware equivalent. It's
      a logical container for pipelines which are themselves containers - this
      time for modules i.e. processing units.
      Depending on the number of audio formats supported, each path template
      may carry one or more descriptions of given path. During runtime, when
      audio format is known, description matching said format is selected and
      used when instantiating path on ADSP firmware side through IPCs.
      e1bbfccf