- Sound-open-firmware - mailman.alsa-project.org

[Sound-open-firmware] [PATCH v4 00/14] ASoC: Sound Open Firmware (SOF) core
by Pierre-Louis Bossart 18 Feb '19

18 Feb '19

Sound Open Firmware (SOF) is a host and DSP architecture agnostic audio DSP firmware. SOF is not tied to any specific host architecture or any specific physical IO communication type (it will work with on SoC DSPs, or DSP connected via SPI/I2C). SOF is also not coupled to any particular DSP architecture and has abstraction similar to Linux to allow porting to other DSP architectures. https://www.sofproject.org/ This patch series introduces the SOF core and utilities. Support for Intel devices is provided as a follow-up series. The SOF core manages all the core DSP services and ALSA/ASoC IO. The core is responsible for loading firmware, parsing topology, exposing PCMs and kcontrols, providing debug and trace mechanisms and performing IPC between host and DSP. The SOF core also has logic to allow reuse of existing machine drivers for other platforms/machines without any code modification. i.e. DAI links can be modified at runtime to bind with SOF and SOF topologies instead of existing hard coded DAI links and topology. Changes since v3: Addressed dozens ofcomments from Takashi Iwai, Mark Brown, Andy Shevchenko, Daniel Baluta (Thanks!) Hardened memory allocation, fixed module load/unload oops or errors (now at hundreds of cycles on ApolloLake devices) Fixed suspend/resume and removed use of suspend_late, now using snd_soc_pm_ops and standard flow Fixed topology free (multiple patches already contributed for ASoC-core) Fixed debugfs/pm_runtime interaction Removed error checks on debugfs, changed to EXPORT_SYMBOL_GPL Added filenames in debug messages, ues hex_dump_to_buffer Removed "sof-audio" platform device and added better error checks on probe Reworked data structures to remove mix of const/variable fields and duplication of pointers for platform-specific changes Removed redundant ops tables Fixed trace/logger issues Fixed issues with loader (alignment and block size errors) Fixed release_firmware handling (was all over the place) Simplified PCI handling Added comments on non-atomic triggers Removed enum controls (not supported in topology) Simplified include file dependencies Fix cppcheck warnings Fixed Kconfigs to deal with Kbuild warnings on exotic architectures Precisions: The code in this patchset is directly squashed from the SOF development branch [1], which tracks Mark Brown's for-next branch on a weekly basis and the configurations used for testing are based on the defconfigs at [2]. The patches are also used backported for Chromebook devices. Full disclosure on known limitation and issues (full list at [3]) a) the interaction with ASoC is not always perfect, there are a couple of points where a better solution is desired (use of private data, support for link DMA, etc). The known points are explicitly documented in the code and will be updated. To be clearer, it's our belief that SOF does not cripple ASoC in any way, and that merging this SOF core does not harm others. It's just complicated to get things right, especially on a couple of cases where the topology and DPCM frameworks generate complex flows that very few people understand. b) The get/put methods for controls generate an IPC and possibly a wake-up. This is not optimal and is being fixed. c) runtime_pm is being hardened and the use of SMART_SUSPEND was suggested. Thank you for reviews and comments, we appreciate the time spent commenting on this large patchset. Thanks in particular to Alan Cox and Andy Shevchenko for their comments on an earlier version. This patchset also includes contributions from Daniel Baluta for loading code on non-Intel platforms. Pierre [1] https://github.com/thesofproject/linux [2] https://github.com/thesofproject/kconfig [3] https://github.com/thesofproject/linux/issues Liam Girdwood (12): ASoC: SOF: Add Sound Open Firmware driver core ASoC: SOF: Add Sound Open Firmware KControl support ASoC: SOF: Add driver debug support. ASoC: SOF: Add support for IPC IO between DSP and Host ASoC: SOF: Add PCM operations support ASoC: SOF: Add support for loading topologies ASoC: SOF: Add DSP firmware logger support ASoC: SOF: Add DSP HW abstraction operations ASoC: SOF: Add firmware loader support ASoC: SOF: Add userspace ABI support ASoC: SOF: Add PM support ASoC: SOF: Add Nocodec machine driver support Pierre-Louis Bossart (2): ASoC: SOF: Add xtensa support ASoC: SOF: Add utils include/sound/soc.h | 3 + include/sound/sof.h | 100 + include/sound/sof/control.h | 125 ++ include/sound/sof/dai-intel.h | 178 ++ include/sound/sof/dai.h | 75 + include/sound/sof/header.h | 158 ++ include/sound/sof/info.h | 118 ++ include/sound/sof/pm.h | 48 + include/sound/sof/stream.h | 149 ++ include/sound/sof/topology.h | 256 +++ include/sound/sof/trace.h | 66 + include/sound/sof/xtensa.h | 44 + include/uapi/sound/sof/abi.h | 62 + include/uapi/sound/sof/eq.h | 164 ++ include/uapi/sound/sof/fw.h | 78 + include/uapi/sound/sof/header.h | 27 + include/uapi/sound/sof/manifest.h | 188 ++ include/uapi/sound/sof/tokens.h | 98 + include/uapi/sound/sof/tone.h | 21 + include/uapi/sound/sof/trace.h | 93 + sound/soc/sof/control.c | 361 ++++ sound/soc/sof/core.c | 473 +++++ sound/soc/sof/debug.c | 219 +++ sound/soc/sof/ipc.c | 842 +++++++++ sound/soc/sof/loader.c | 363 ++++ sound/soc/sof/nocodec.c | 109 ++ sound/soc/sof/ops.c | 204 +++ sound/soc/sof/ops.h | 414 +++++ sound/soc/sof/pcm.c | 710 ++++++++ sound/soc/sof/pm.c | 381 ++++ sound/soc/sof/sof-priv.h | 599 ++++++ sound/soc/sof/topology.c | 2808 +++++++++++++++++++++++++++++ sound/soc/sof/trace.c | 298 +++ sound/soc/sof/utils.c | 109 ++ sound/soc/sof/xtensa/Kconfig | 2 + sound/soc/sof/xtensa/Makefile | 5 + sound/soc/sof/xtensa/core.c | 138 ++ 37 files changed, 10086 insertions(+) create mode 100644 include/sound/sof.h create mode 100644 include/sound/sof/control.h create mode 100644 include/sound/sof/dai-intel.h create mode 100644 include/sound/sof/dai.h create mode 100644 include/sound/sof/header.h create mode 100644 include/sound/sof/info.h create mode 100644 include/sound/sof/pm.h create mode 100644 include/sound/sof/stream.h create mode 100644 include/sound/sof/topology.h create mode 100644 include/sound/sof/trace.h create mode 100644 include/sound/sof/xtensa.h create mode 100644 include/uapi/sound/sof/abi.h create mode 100644 include/uapi/sound/sof/eq.h create mode 100644 include/uapi/sound/sof/fw.h create mode 100644 include/uapi/sound/sof/header.h create mode 100644 include/uapi/sound/sof/manifest.h create mode 100644 include/uapi/sound/sof/tokens.h create mode 100644 include/uapi/sound/sof/tone.h create mode 100644 include/uapi/sound/sof/trace.h create mode 100644 sound/soc/sof/control.c create mode 100644 sound/soc/sof/core.c create mode 100644 sound/soc/sof/debug.c create mode 100644 sound/soc/sof/ipc.c create mode 100644 sound/soc/sof/loader.c create mode 100644 sound/soc/sof/nocodec.c create mode 100644 sound/soc/sof/ops.c create mode 100644 sound/soc/sof/ops.h create mode 100644 sound/soc/sof/pcm.c create mode 100644 sound/soc/sof/pm.c create mode 100644 sound/soc/sof/sof-priv.h create mode 100644 sound/soc/sof/topology.c create mode 100644 sound/soc/sof/trace.c create mode 100644 sound/soc/sof/utils.c create mode 100644 sound/soc/sof/xtensa/Kconfig create mode 100644 sound/soc/sof/xtensa/Makefile create mode 100644 sound/soc/sof/xtensa/core.c -- 2.17.1

4 33

[Sound-open-firmware] Design document - topology, scheduling et all
by Daniel Baluta 14 Feb '19

14 Feb '19

Hi all, First of all I'm now in the phase where I only need to implement the DMA driver for i.MX and create the topology file. Few questions: 1) Is there any simple scenario (topology file) where I could test that scheduling, ipc, pipelines, etc works without the DMA? It is my first time using topology and I'm still yet to get around the m4 topology description. 2) Is there any design document for the SOF architecture. I'm still yet to understand how components and scheduler interact. thanks, Daniel.

2 3

[Sound-open-firmware] [PATCH v2 00/20] ASoC: Sound Open Firmware (SOF) - Intel support
by Pierre-Louis Bossart 14 Feb '19

14 Feb '19

This patch series introduces the support for Intel devices (Baytrail, CherryTrail, Broadwell/Haswell, ApolloLake, GeminiLake, CannonLake, IceLake). Support for Skylake and KabyLake is incomplete at the moment but the basic building blocks required are already present. The series starts with the 'legacy' devices, then all the more recent ones and concludes with ACPI/PCI hooks. SKL+ platforms can be compiled without HDaudio link/codec support, in which case the hdac library is not used. When support for HDMI or HDaudio codecs is selected, parts of this library are used. The machine drivers supported by SOF are not provided as part of this series. The build will only work in 'nocodec' mode for now. Support for SPI-based devices, compressed streams is also not provided for now since it's not ready for upstream just yet. Thank you for reviews and comments, we appreciate the time spent commenting on this large patchset. Thanks in particular to Alan Cox and Andy Shevchenko for their comments on an earlier version. Changes since v2: Addressed dozens of comments from Takashi Iwai, Mark Brown, Andy Shevchenko, Daniel Baluta (Thanks!) Transition to new display power management Fixed suspend issues Optimized register polling, better handling of timeouts and firmware download retries Detect number of HDaudio codec and select machine driver accordingly Added workqueue based probe for HDaudio (dependency on modules) Fixed platform name override and conflicts with DT deferred probe changes Added prefix for firmware and topology files and module arguments Split Baytrail and Edison Fixed warnings (smatch, cppcheck) Keyon Jie (2): ASoC: SOF: Intel: Add hda-bus support and initialization ASoC: SOF: Intel: SKL, CNL, APL platform DAIs Liam Girdwood (15): ASoC: SOF: Intel: Add BYT, CHT and BSW DSP HW support. ASoC: SOF: Intel: Add HSW HW DSP support ASoC: SOF: Intel: Add BDW HW DSP support ASoC: SOF: Intel: Add APL/CNL HW DSP support ASoC: SOF: Intel: Add HDA controller for Intel DSP ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations ASoC: SOF: Intel: Add Intel specific HDA IPC mechanisms. ASoC: SOF: Intel: Add Intel specific HDA firmware loader ASoC: SOF: Intel: Add Intel specific HDA PCM operations ASoC: SOF: Intel: Add Intel specific HDA stream operations ASoC: SOF: Intel: Add Intel specific HDA trace operations ASoC: SOF: Intel: Add platform differentiation for SKL, APL and CNL ASoC: SOF: Add ACPI device support ASoC: SOF: Add PCI device support ASoC: SOF: Add Build support for SOF core and Intel drivers Pierre-Louis Bossart (3): ASoC: SOF: Intel: Add support for HDAudio codecs ASoC: SOF: Intel: Add SKL-specific code loader ASoC: Intel: Kconfig: expose common option between SST and SOF drivers sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/intel/Kconfig | 7 +- sound/soc/sof/Kconfig | 141 +++++ sound/soc/sof/Makefile | 18 + sound/soc/sof/intel/Kconfig | 253 ++++++++ sound/soc/sof/intel/Makefile | 17 + sound/soc/sof/intel/apl.c | 111 ++++ sound/soc/sof/intel/bdw.c | 716 +++++++++++++++++++++ sound/soc/sof/intel/byt.c | 893 +++++++++++++++++++++++++++ sound/soc/sof/intel/cnl.c | 269 ++++++++ sound/soc/sof/intel/hda-bus.c | 108 ++++ sound/soc/sof/intel/hda-codec.c | 171 +++++ sound/soc/sof/intel/hda-ctrl.c | 165 +++++ sound/soc/sof/intel/hda-dai.c | 362 +++++++++++ sound/soc/sof/intel/hda-dsp.c | 440 +++++++++++++ sound/soc/sof/intel/hda-ipc.c | 403 ++++++++++++ sound/soc/sof/intel/hda-loader-skl.c | 526 ++++++++++++++++ sound/soc/sof/intel/hda-loader.c | 359 +++++++++++ sound/soc/sof/intel/hda-pcm.c | 235 +++++++ sound/soc/sof/intel/hda-stream.c | 663 ++++++++++++++++++++ sound/soc/sof/intel/hda-trace.c | 98 +++ sound/soc/sof/intel/hda.c | 680 ++++++++++++++++++++ sound/soc/sof/intel/hda.h | 549 ++++++++++++++++ sound/soc/sof/intel/hsw.c | 717 +++++++++++++++++++++ sound/soc/sof/intel/shim.h | 177 ++++++ sound/soc/sof/intel/skl.c | 104 ++++ sound/soc/sof/sof-acpi-dev.c | 310 ++++++++++ sound/soc/sof/sof-pci-dev.c | 351 +++++++++++ 29 files changed, 8844 insertions(+), 1 deletion(-) create mode 100644 sound/soc/sof/Kconfig create mode 100644 sound/soc/sof/Makefile create mode 100644 sound/soc/sof/intel/Kconfig create mode 100644 sound/soc/sof/intel/Makefile create mode 100644 sound/soc/sof/intel/apl.c create mode 100644 sound/soc/sof/intel/bdw.c create mode 100644 sound/soc/sof/intel/byt.c create mode 100644 sound/soc/sof/intel/cnl.c create mode 100644 sound/soc/sof/intel/hda-bus.c create mode 100644 sound/soc/sof/intel/hda-codec.c create mode 100644 sound/soc/sof/intel/hda-ctrl.c create mode 100644 sound/soc/sof/intel/hda-dai.c create mode 100644 sound/soc/sof/intel/hda-dsp.c create mode 100644 sound/soc/sof/intel/hda-ipc.c create mode 100644 sound/soc/sof/intel/hda-loader-skl.c create mode 100644 sound/soc/sof/intel/hda-loader.c create mode 100644 sound/soc/sof/intel/hda-pcm.c create mode 100644 sound/soc/sof/intel/hda-stream.c create mode 100644 sound/soc/sof/intel/hda-trace.c create mode 100644 sound/soc/sof/intel/hda.c create mode 100644 sound/soc/sof/intel/hda.h create mode 100644 sound/soc/sof/intel/hsw.c create mode 100644 sound/soc/sof/intel/shim.h create mode 100644 sound/soc/sof/intel/skl.c create mode 100644 sound/soc/sof/sof-acpi-dev.c create mode 100644 sound/soc/sof/sof-pci-dev.c -- 2.17.1

2 21

[Sound-open-firmware] SOF/Intel: change of directory structure for firmware binaries
by Pierre-Louis Bossart 08 Feb '19

08 Feb '19

FYI, if anyone uses the latest SOF kernel branch (topic/sof-dev), there was a change in the location of the files used by the Linux kernel for Intel platforms: firmware files are by default in /lib/firmware/intel/sof topology files are in /lib/firmware/intel/sof-tplg. You can override this by adding module arguments to go back to the previous setup. modprobe sof-[pci|acpi]-dev fw_path=intel tplg_path=intel This change was made so that firmware and topologies can be released separately, and allow a contributor company to release support for multiple platforms at the same time, with symlinks used for the directories instead of individual files. It'll also help distros or OEMs use non-default firmware locations for their own releases, if they included non-public components or change the firmware configurations. Sorry for the inconvenience in the transition. -Pierre

1 0

[Sound-open-firmware] help with unit tests
by kalamara＠ceid.upatras.gr 08 Feb '19

08 Feb '19

Hello, this is the first post from a newb user so first of all kudos to everyone for this amazing project. I have followed the build from scratch instructions and built successfully the apl firmware (from branch master), but am having trouble building the unit tests: :~/lara/sof/sof/build_ut$ cmake -DTOOLCHAIN=xtensa-apl-elf -DROOT_DIR=`pwd`/../../xtensa-root/xtensa-apl-elf -DBUILD_UNIT_TESTS=ON .. -- Preparing Xtensa toolchain -- Configuring done -- Generating done -- Build files have been written to: /home/antonis/lara/sof/sof/build_ut :~/lara/sof/sof/build_ut$ make apollolake_defconfig [100%] Applying olddefconfig with apollolake_defconfig Using existing configuration '.config' as base Configuration written to '.config' [100%] Built target apollolake_defconfig :~/lara/sof/sof/build_ut$ make -j4 -- Preparing Xtensa toolchain -- Configuring done -- Generating done -- Build files have been written to: /home/antonis/lara/sof/sof/build_ut [ 0%] Built target ld_script_memory_mock [ 0%] Performing update step for 'cmocka_git' [ 0%] Generating /home/antonis/lara/sof/sof/build_ut/generated/include/config.h [ 0%] Built target genconfig Scanning dependencies of target audio_for_volume [ 0%] Building C object test/cmocka/src/audio/volume/CMakeFiles/audio_for_volume.dir/__/__/__/__/__/src/audio/volume_generic.c.o [ 2%] Building C object test/cmocka/src/audio/volume/CMakeFiles/audio_for_volume.dir/__/__/__/__/__/src/audio/volume.c.o [ 2%] Building C object test/cmocka/src/audio/volume/CMakeFiles/audio_for_volume.dir/__/__/__/__/__/src/audio/volume_hifi3.c.o [ 3%] Linking C static library libaudio_for_volume.a [ 3%] Built target audio_for_volume Current branch master is up to date. [ 4%] Performing configure step for 'cmocka_git' -- The C compiler identification is GNU 8.1.0 -- Check for working C compiler: /home/antonis/lara/sof/xtensa-apl-elf/bin/xtensa-apl-elf-gcc -- Check for working C compiler: /home/antonis/lara/sof/xtensa-apl-elf/bin/xtensa-apl-elf-gcc -- broken CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message): The C compiler "/home/antonis/lara/sof/xtensa-apl-elf/bin/xtensa-apl-elf-gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_809b9/fast" make[3]: Entering directory '/home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeTmp' /usr/bin/make -f CMakeFiles/cmTC_809b9.dir/build.make CMakeFiles/cmTC_809b9.dir/build make[4]: Entering directory '/home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_809b9.dir/testCCompiler.c.o /home/antonis/lara/sof/xtensa-apl-elf/bin/xtensa-apl-elf-gcc -o CMakeFiles/cmTC_809b9.dir/testCCompiler.c.o -c /home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTC_809b9 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_809b9.dir/link.txt --verbose=1 /home/antonis/lara/sof/xtensa-apl-elf/bin/xtensa-apl-elf-gcc CMakeFiles/cmTC_809b9.dir/testCCompiler.c.o -o cmTC_809b9 /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find crt1-sim.o: No such file or directory /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find crt0.o: No such file or directory /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find _vectors.o: No such file or directory /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find -lc /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find -lsim /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find -lc /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find -lhandlers-sim /home/antonis/lara/sof/xtensa-apl-elf/bin/../lib/gcc/xtensa-apl-elf/8.1.0/../../../../xtensa-apl-elf/bin/ld: cannot find -lhal collect2: error: ld returned 1 exit status CMakeFiles/cmTC_809b9.dir/build.make:97: recipe for target 'cmTC_809b9' failed make[4]: *** [cmTC_809b9] Error 1 make[4]: Leaving directory '/home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeTmp' Makefile:126: recipe for target 'cmTC_809b9/fast' failed make[3]: *** [cmTC_809b9/fast] Error 2 make[3]: Leaving directory '/home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeTmp' CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:18 (project) -- Configuring incomplete, errors occurred! See also "/home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeOutput.log". See also "/home/antonis/lara/sof/sof/build_ut/cmocka_git/build/CMakeFiles/CMakeError.log". test/cmocka/CMakeFiles/cmocka_git.dir/build.make:105: recipe for target 'cmocka_git/src/cmocka_git-stamp/cmocka_git-configure' failed make[2]: *** [cmocka_git/src/cmocka_git-stamp/cmocka_git-configure] Error 1 CMakeFiles/Makefile2:572: recipe for target 'test/cmocka/CMakeFiles/cmocka_git.dir/all' failed make[1]: *** [test/cmocka/CMakeFiles/cmocka_git.dir/all] Error 2 Makefile:94: recipe for target 'all' failed make: *** [all] Error 2 It seems something that should be obvious is missing from my setup, even though i am able to build SOF binaries? Can you please advise? my environment is Ubuntu 18.04.1 LTS cmake version 3.10.2 regards and thanks antonis

4 3

[Sound-open-firmware] [PATCH v3 00/14] Sound Open Firmware (SOF) core
by Pierre-Louis Bossart 30 Jan '19

30 Jan '19

Sound Open Firmware (SOF) is a host and DSP architecture agnostic audio DSP firmware. SOF is not tied to any specific host architecture or any specific physical IO communication type (it will work with on SoC DSPs, or DSP connected via SPI/I2C). SOF is also not coupled to any particular DSP architecture and has abstraction similar to Linux to allow porting to other DSP architectures. https://www.sofproject.org/ This patch series introduces the SOF core and utilities. Support for Intel devices is provided as a follow-up series. The SOF core manages all the core DSP services and ALSA/ASoC IO. The core is responsible for loading firmware, parsing topology, exposing PCMs and kcontrols, providing debug and trace mechanisms and performing IPC between host and DSP. The SOF core also has logic to allow reuse of existing machine drivers for other platforms/machines without any code modification. i.e. DAI links can be modified at runtime to bind with SOF and SOF topologies instead of existing hard coded DAI links and topology. Main changes since v2 (end of August): There are honestly too many changes to be listed... The biggest changes are the introduction of an ABI check and runtime_pm, as well as countless improvements coming from product validation. We will provide a revision history starting with the next update. Precisions: Since I've been maintaining the SOF kernel parts for most of 2018, Liam and I mutually agreed that it would be more efficient for me to send the patches upstream to avoid any disconnects. The code in this patchset is directly squashed from the SOF development branch [1], which tracks Mark Brown's for-next branch on a weekly basis and the configurations used for testing are based on the defconfigs at [2] Full disclosure on known limitation and issues (full list at [3]) a) the interaction with ASoC is not always perfect, there are a couple of points where a better solution is desired (use of private data, support for link DMA, etc). The known points are explicitly documented in the code and will be updated. To be clearer, it's our belief that SOF does not cripple ASoC in any way, and that merging this SOF core does not harm others. It's just complicated to get things right, especially on a couple of cases where the topology and DPCM frameworks generate complex flows that very few people understand. b) The get/put methods for controls generate an IPC and possibly a wake-up. This is not optimal and is being fixed. c) The debugfs parts will be updated for runtime_pm parts d) The topology free, firmware release and Hdaudio exit sequences will be updated. It is our intention to fully support module load/unload and free all resources. e) runtime_pm is being hardened and the use of SMART_SUSPEND was suggested. Thank you for reviews and comments, we appreciate the time spent commenting on this large patchset. Thanks in particular to Alan Cox and Andy Shevchenko for their comments on an earlier version. Pierre [1] https://github.com/thesofproject/linux [2] https://github.com/thesofproject/kconfig [3] https://github.com/thesofproject/linux/issues Liam Girdwood (12): ASoC: SOF: Add Sound Open Firmware driver core ASoC: SOF: Add Sound Open Firmware KControl support ASoC: SOF: Add driver debug support. ASoC: SOF: Add support for IPC IO between DSP and Host ASoC: SOF: Add PCM operations support ASoC: SOF: Add support for loading topologies ASoC: SOF: Add DSP firmware logger support ASoC: SOF: Add DSP HW abstraction operations ASoC: SOF: Add firmware loader support ASoC: SOF: Add userspace ABI support ASoC: SOF: Add PM support ASoC: SOF: Add Nocodec machine driver support Pierre-Louis Bossart (2): ASoC: SOF: Add xtensa support ASoC: SOF: Add utils include/sound/soc.h | 3 + include/sound/sof.h | 91 + include/sound/sof/control.h | 125 ++ include/sound/sof/dai-intel.h | 175 ++ include/sound/sof/dai.h | 75 + include/sound/sof/header.h | 158 ++ include/sound/sof/info.h | 118 ++ include/sound/sof/pm.h | 48 + include/sound/sof/stream.h | 149 ++ include/sound/sof/topology.h | 256 +++ include/sound/sof/trace.h | 66 + include/sound/sof/xtensa.h | 44 + include/uapi/sound/sof/abi.h | 63 + include/uapi/sound/sof/eq.h | 164 ++ include/uapi/sound/sof/fw.h | 67 + include/uapi/sound/sof/header.h | 27 + include/uapi/sound/sof/manifest.h | 188 ++ include/uapi/sound/sof/tokens.h | 95 + include/uapi/sound/sof/tone.h | 21 + include/uapi/sound/sof/trace.h | 93 + sound/soc/sof/control.c | 421 +++++ sound/soc/sof/core.c | 398 +++++ sound/soc/sof/debug.c | 176 ++ sound/soc/sof/ipc.c | 813 +++++++++ sound/soc/sof/loader.c | 322 ++++ sound/soc/sof/nocodec.c | 81 + sound/soc/sof/ops.c | 200 +++ sound/soc/sof/ops.h | 379 ++++ sound/soc/sof/pcm.c | 755 ++++++++ sound/soc/sof/pm.c | 403 +++++ sound/soc/sof/sof-priv.h | 574 ++++++ sound/soc/sof/topology.c | 2775 +++++++++++++++++++++++++++++ sound/soc/sof/trace.c | 295 +++ sound/soc/sof/utils.c | 173 ++ sound/soc/sof/xtensa/Kconfig | 3 + sound/soc/sof/xtensa/Makefile | 5 + sound/soc/sof/xtensa/core.c | 152 ++ 37 files changed, 9951 insertions(+) create mode 100644 include/sound/sof.h create mode 100644 include/sound/sof/control.h create mode 100644 include/sound/sof/dai-intel.h create mode 100644 include/sound/sof/dai.h create mode 100644 include/sound/sof/header.h create mode 100644 include/sound/sof/info.h create mode 100644 include/sound/sof/pm.h create mode 100644 include/sound/sof/stream.h create mode 100644 include/sound/sof/topology.h create mode 100644 include/sound/sof/trace.h create mode 100644 include/sound/sof/xtensa.h create mode 100644 include/uapi/sound/sof/abi.h create mode 100644 include/uapi/sound/sof/eq.h create mode 100644 include/uapi/sound/sof/fw.h create mode 100644 include/uapi/sound/sof/header.h create mode 100644 include/uapi/sound/sof/manifest.h create mode 100644 include/uapi/sound/sof/tokens.h create mode 100644 include/uapi/sound/sof/tone.h create mode 100644 include/uapi/sound/sof/trace.h create mode 100644 sound/soc/sof/control.c create mode 100644 sound/soc/sof/core.c create mode 100644 sound/soc/sof/debug.c create mode 100644 sound/soc/sof/ipc.c create mode 100644 sound/soc/sof/loader.c create mode 100644 sound/soc/sof/nocodec.c create mode 100644 sound/soc/sof/ops.c create mode 100644 sound/soc/sof/ops.h create mode 100644 sound/soc/sof/pcm.c create mode 100644 sound/soc/sof/pm.c create mode 100644 sound/soc/sof/sof-priv.h create mode 100644 sound/soc/sof/topology.c create mode 100644 sound/soc/sof/trace.c create mode 100644 sound/soc/sof/utils.c create mode 100644 sound/soc/sof/xtensa/Kconfig create mode 100644 sound/soc/sof/xtensa/Makefile create mode 100644 sound/soc/sof/xtensa/core.c -- 2.17.1

5 47

[Sound-open-firmware] sound-next or linux-next sof patches
by Daniel Baluta 28 Jan '19

28 Jan '19

Hi, What's the closest SOF branch to linux-next or sound/for-next? Our i.MX8 boards support was only recently added in various trees and it is currently only in linux-next. thanks, Daniel.

2 2

[Sound-open-firmware] Timer implementation: Haswell vs Baytrail
by Daniel Baluta 28 Jan '19

28 Jan '19

Hi all, Can someone explain what is the difference between hsw vs byt timer implementation? It looks like hsw uses a generic xtensa timer implementation based on directly reading Xtensa special registers while Byt uses some bits in SHIM layer. What is the advantage of byt implementation? Also, the implementation for hsw looks generic enough so that it can be used by other architectures that do not have a shim layer, right? thanks, Daniel

2 1

[Sound-open-firmware] SOF: Where is the purpose of host_msg ?
by Daniel Baluta 23 Jan '19

23 Jan '19

Hi Pierre/Liam, In src/include/sof/ipc.h there is: struct ipc { uint32_t host_msg;» » /* current message from host */ // } This keeps the message received from IA core. Anyhow, DSP core doesn't seem to use it at all. Except maybe for some logging: src/drivers/intel/baytrail/ipc.c: _ipc->host_msg = msg; src/drivers/intel/baytrail/ipc.c: trace_ipc("ipc: msg rx -> 0x%x", ipc->host_msg); src/drivers/intel/cavs/ipc.c: _ipc->host_msg = msg; src/drivers/intel/cavs/ipc.c: trace_ipc("ipc: msg rx -> 0x%x", ipc->host_msg); src/drivers/intel/cavs/sue-ipc.c: trace_ipc("ipc: msg rx -> 0x%x", ipc->host_msg); src/drivers/intel/haswell/ipc.c: _ipc->host_msg = msg; src/drivers/intel/haswell/ipc.c: trace_ipc("ipc: msg rx -> 0x%x", ipc->host_msg); src/include/sof/ipc.h: uint32_t host_msg; /* current message from host */ I am asking this because initially I thought the communication between IA core and DSP involves: - sending cmd using shim layer - sending actual data using mailbox. But it seems that all the information is exchanged via the mailbox memory. So, going back to my question will host_msg be used in the future? If not, I think it is best to remove it because it is confusing. The same happens when DSP tries to send something to IA. For example it writes msg->header. But this is never used on the other side. ipc_platform_send_msg » /* now interrupt host to tell it we have message sent */ » shim_write(SHIM_IPCDL, msg->header); » shim_write(SHIM_IPCDH, SHIM_IPCDH_BUSY); Also, would be easier for me on the ARM side to only send info via mailbox and notification via what you call shim layer. thanks, Daniel.

3 7

Re: [Sound-open-firmware] [alsa-devel] [PATCH v3 04/14] ASoC: SOF: Add support for IPC IO between DSP and Host
by Pierre-Louis Bossart 23 Jan '19

23 Jan '19

On 1/22/19 1:04 PM, Mark Brown wrote: > On Thu, Jan 10, 2019 at 02:11:32PM -0600, Pierre-Louis Bossart wrote: > >>>> + /* attach any data */ >>>> + if (msg_bytes) >>>> + memcpy(msg->msg_data, msg_data, msg_bytes); >>> How big do these messages get? Do we need to hold the lock while we >>> memcpy()? >> Messages can be as big as the mailbox, which is hardware dependent. It could >> be from a few bytes to a larger e.g. 4k page or more, and indeed we need to >> keep the lock. > Is this copying into an actual mailbox or into some data structure in > memory? It looked like it's copying into a buffer for sending rather > than the mailbox. I realize between your feedback and Daniel's that we have a terminology issue. On the Intel side we don't have a dedicated hardware mailbox unit, it's only doorbell registers and shared memory windows. > >>>> + /* schedule the message if not busy */ >>>> + if (snd_sof_dsp_is_ready(sdev)) >>>> + schedule_work(&ipc->tx_kwork); >>> If the DSP is idle is there a reason this has to happen in another >>> thread? >> we will rename this as snd_sof_dsp_is_ipc_ready() to avoid any confusion >> with the DSP state. We only care about IPC registers/doorbells at this >> point, not the fact that the DSP is in its idle loop. > You're missing the point - why can't we just immediately send the > message to the DSP from here, what's the benefit of scheduling some work > to do that? I realize this might be Intel-specific and will likely have to evolve. Keyon/Liam, this is your code, can you comment on Mark's comments (here) > >>>> + spin_unlock_irqrestore(&sdev->ipc_lock, flags); >>> The thread is also going to take an irq spinlock after all. >> didn't get this point, sorry. > One reason to bounce to another thread would be to do something that you > can't do in this context like take a lock in a place you can't take > locks but here we're taking a lock that needs thread context already. Liam/Keyon comment needed here as well. I think there are multiple questions that should be better answered to 1. why do we schedule a thread when the DSP is not busy 2. what happens if it is? 3. can we avoid freeing the lock to take it again when we schedule?

2 1