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

Re: [Sound-open-firmware] help with unit tests
by Wilson, Danny 28 Feb '19

28 Feb '19

Hello, I am a new user from VeriSilicon, also trying to get unit tests to run. Thanks for bringing this project to GitHub. On 2/8/19 1:06 PM Jankowski, Janusz wrote: > TL;DR: Unit Tests are not supported for xtensa GCC toolchains at the moment (work in progress). You can run them only with xtensa xt-* toolchain that provides simulator (xt-run). On 2/8/19 8:24 PM, Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com worte: > FWIW, there is an alternate way of getting everything in one shot with > 'repo', there are build-scripts provided so that you can reproduce the > same setup as other developers. > > repo init -u https://github.com/thesofproject/sof-manifests > > repo sync -c My environment is: Ubuntu 18.04.2 LTS When trying the alternate method described by Pierre, I get the following permission denied error: ~/work/sof$ repo init -u https:://github.com/thesofproject/sof-manifests Traceback (most recent call last): File "/home/us9005/work/sof/.repo/repo/main.py", line 40, in <module> import event_log File "/home/us9005/work/sof/.repo/repo/event_log.py", line 165, in <module> _EVENT_ID = multiprocessing.Value('i', 1) File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/__init__.py", line 253, in Value return Value(typecode_or_type, *args, **kwds) File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/sharedctypes.py", line 108, in Value lock = RLock() File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/__init__.py", line 183, in RLock return RLock() File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/synchronize.py", line 172, in __init__ SemLock.__init__(self, RECURSIVE_MUTEX, 1, 1) File "/snap/git-repo/18/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied Is this a repository permission I am lacking? Is there a particular build-script that includes the xtensa-xt* toolchain for unit tests? Regards, Danny Wilson

2 1

[Sound-open-firmware] [PATCH] topology: ssp: add polarity inversion option in SSP_CLOCK
by Dragos Tarcatu 25 Feb '19

25 Feb '19

alsatplg allows setting inverted bclk and fsync polarities by setting either bclk_invert or fsync_invert to "true". This patch adds a default parameter in the SSP_CLOCK m4 macro which allows setting inverted bclk and fsync polarities. Signed-off-by: Dragos Tarcatu <dragos_tarcatu(a)mentor.com> --- tools/topology/platform/common/ssp.m4 | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/topology/platform/common/ssp.m4 b/tools/topology/platform/common/ssp.m4 index f3c7862..76b2766 100644 --- a/tools/topology/platform/common/ssp.m4 +++ b/tools/topology/platform/common/ssp.m4 @@ -2,11 +2,12 @@ divert(-1) dnl SSP related macros -dnl SSP_CLOCK(clock, freq, codec_master) +dnl SSP_CLOCK(clock, freq, codec_master, polarity) +dnl polarity is optional define(`SSP_CLOCK', $1 STR($3) - $1_freq STR($2)) - + $1_freq STR($2) + `ifelse($4, `inverted', `$1_invert "true"',`')') dnl SSP_TDM(slots, width, tx_mask, rx_mask) define(`SSP_TDM', -- 2.7.4

2 1

Re: [Sound-open-firmware] [alsa-devel] [v4, 00/14] ASoC: Sound Open Firmware (SOF) core
by xiang xiao 25 Feb '19

25 Feb '19

On Tue, Feb 19, 2019 at 5:49 PM Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> wrote: > > > > On 18/02/2019 20:03, Xiang Xiao wrote: > > Should we utilize official IPC frameowrk instead reinverting the wheel? > > 1.Load firmware by drivers/remoteproc > > https://www.kernel.org/doc/Documentation/remoteproc.txt > > 2.Do the comunication through drivers/rpmsg > > https://www.kernel.org/doc/Documentation/rpmsg.txt > > Many vendor(TI, Qualcomm, ST, NXP, Xilinx...) migrate to remoteproc/rpmsg, why Intel provide an other IPC mechanism? > > It definitely makes more sense to use rpmsg for Generic IPC driver here. > > Qualcomm DSP audio drivers (non SOF) already use rpmsg. This will > definitely help everyone in future while immigrating to SOF. > Actually, Xiaomi also build DSP audio driver on top of rpmsg, but fully integrate with the ASoC topology framework, and the firmware is base on FreeRTOS and OpenMAX. SOF initiative is very good and exciting, our team members(include me) spend a couple weeks to study the current code base on both firmware and kernel side, we even port SOF to our DSP/MCU and make it run, but I have to point out that: SOF IPC is too simple and rigid, tightly couple with Intel platform and audio domain, which make: a.It's difficult to integrate with other vendor SoC, especially if other vendor already adopt remote/rpmsg(this is already a trend!). b.It's difficult to add other IPC services for example: i.Audio DSP talk to power MCU to adjust clock and voltage ii.Export ultrasonic distance measurement to IIO subsystem > > Actually, remoteproc/rpmsg is much better than SOF IPC because: > > 1.Completely isolate the firmware load and message transfer: > > The same rpmsg driver could run on any remote processor > > 2.Separate the application protocol from transfer layer: > > One remote processor could host many rpmsg services > > 3.Completely follow kernel driver model(rpsmg_bus, rpmsg_device and rpmsg_driver). > > 4.Support by many RTOS(Bare Metal, FreeRTOS, Zephyr, NuttX, Nucleus, uC/OS...) for remote side: > > https://github.com/OpenAMP/open-amp > > https://github.com/NXPmicro/rpmsg-lite > > 5.Maintained by the standard committee: > > https://www.multicore-association.org/workgroup/oamp.php > > https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio > > Since the keypoint of SOF is the platform agnostic and modular, please use the standard technique here. > > > > Thanks > > Xiang > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > --srini

6 13

Re: [Sound-open-firmware] [alsa-devel] [PATCH v4 01/14] ASoC: SOF: Add Sound Open Firmware driver core
by Pierre-Louis Bossart 22 Feb '19

22 Feb '19

On 2/21/19 12:47 PM, Mark Brown wrote: > On Wed, Feb 20, 2019 at 03:32:54PM -0600, Pierre-Louis Bossart wrote: > >> The only reason for extending the struct snd_soc_pcm_runtime was to enable >> the use of a 'context' in PCM operations, see e.g in patch 5/14 the repeated >> pattern to get an 'SOF PCM' context: >> struct snd_sof_pcm *spcm = rtd->private; > The reason you're having trouble with this is that the DSP isn't really > properly visible in the system, it's pushed in on the side with DPCM > coexisting with multiple other drivers so as far as I can see it's hard > for it to fit in anywhere in Intel systems. > >> So ironically in ASoC we don't have a means to use a private_data field for >> the substreams since it's used for a 'standard' mechanism. > This is why there's things like snd_soc_dai_get_dma_data() and > snd_soc_component_get_drvdata() - if you're a fully visible component in > the system there's ways to get to your ASoC specific driver data. For > something like SoF that'd mean cooperating with the drivers for the > devices with the SoF using DSPs in some way. > >> The extension suggested in this patch 1/14 was really trying to come back to >> a practical means to store a context in a substream, and make the PCM >> operations manageable. I totally agree that extending the PCM runtime might >> not recommended or safe, but at this point I don't have any slack in the >> existing data structures to add a context in a substream. >> Does this help clarify the problem statement? > It is fairly clear what driver data is useful for. The issue is that > instead of getting to it through the relevant hardware component you're > adding something directly in the core data structure, whatever way we > look at it that's going to be awkward. Consider for example what > happens if someone integrates a system with a SoF DSP in the SoC and > another SoF DSP in the CODEC - there will be two separate copies of SoF > on a single DAI so a SoF specific value directly in the runtime isn't > going to work. > > If there were a component for the DSP (or the DSP was fully part of some > other existing component) then it should be possible to arrange to get > to the DSP data using that but with it just floating there unattached to > anything it's harder. After spending a bit more time on this, I agree it's possible to retrieve the required information without any change to the rtd structure. There are existing precedents using substream->runtime->private_data, e.g. to store an HDAudio stream tag, and SOF already has a list of contexts that can be searched for with a simple list walk. Modeling the DSP differently is something I'll add to my growing-by-the-day TODO list.

1 0

Re: [Sound-open-firmware] [alsa-devel] [v4, 00/14] ASoC: Sound Open Firmware (SOF) core
by Pierre-Louis Bossart 22 Feb '19

22 Feb '19

>> Just for information... ST Microelectronics plans to port SOF to at >> least one of its platforms (based on ARM cores). Today, for the >> co-processor management we use the rpmsg and remoteproc frameworks on >> the Linux kernel side and OpenAMP on the remote processor side. We are >> therefore interested in xiang's work. >> An advantage we see in this generic solution is that compatibility >> between the Linux kernel frameworks and the OpenAMP library is ensured >> through discussions in the Linux and OpenAMP communities, involving >> maintainers and several vendors. Thanks Arnaud for sharing this information. You made my day. We've had to deal with a number of hurdles related to platform and tools availability, so it's good news indeed if there are more platforms endorsing SOF. > This is a very good point, especially with people actually jumping on it > if we can avoid having multiple ABIs to worry about that would make life > a lot easier. We should at least figure out if it will be disruptive to > adapt it later on, even if Intel ends up continuing to use a custom > system integration. Yes indeed. At a high level we only have very generic send/receive IPC messages, and it really shouldn't matter how the transport happens. However the actual contents/semantics of the messages do matter, and I'll have to run a check to make sure it scales.

1 0

Re: [Sound-open-firmware] [PATCH v4 07/14] ASoC: SOF: Add DSP firmware logger support
by Pierre-Louis Bossart 21 Feb '19

21 Feb '19

On 2/20/19 11:44 AM, Mark Brown wrote: > On Wed, Feb 13, 2019 at 04:07:27PM -0600, Pierre-Louis Bossart wrote: > >> + /* make sure count is <= avail */ >> + count = avail > count ? count : avail; > count = min(avail, count)? as discussed in the last review, we didn't use min() since it adds a number of obscure warnings with sparse. I haven't found any time to look into this so for now left the code as is. Sparse is a useful tool for the address checks (topology/DMAs with _le32, __iomem, etc), the fewer warnings we get the better.

2 2

Re: [Sound-open-firmware] [PATCH v4 01/14] ASoC: SOF: Add Sound Open Firmware driver core
by Pierre-Louis Bossart 20 Feb '19

20 Feb '19

On 2/20/19 10:26 AM, Mark Brown wrote: > On Wed, Feb 20, 2019 at 08:35:16AM -0600, Pierre-Louis Bossart wrote: > >> I see your point and agree the current direction isn't scalable, but I am >> not sure about the definition of 'first class device'. >> Did you mean 'component' at the same level as the 'platforms' and 'codecs', >> with all the DSP stuff nicely packaged and maintained in a self-contained >> way? >> Or a subcomponent that might be part of those platforms and codecs? > As far as I can see for the Intel systems it's looking like a first > class component - there will be some systems where the DSP is embedded > in something (like the big CODECs) but even there it's easier as it's > contained within the device rather than affecting multiple devices which > is the big issue here. Sorry Mark, I am struggling with the 'first class' idea. Allow me to go back to the practical issue we faced here, and maybe/hopefully this will help us converge on a consensus. The only reason for extending the struct snd_soc_pcm_runtime was to enable the use of a 'context' in PCM operations, see e.g in patch 5/14 the repeated pattern to get an 'SOF PCM' context: struct snd_sof_pcm *spcm = rtd->private; Managing a context for PCM ops is typically done in other drivers by using the substream->private_data aka snd_pcm_substream_chip(substream). In ASoC/DPCM, unfortunately this substream->private_data field was reclaimed to store a pointer to a 'struct snd_soc_pcm_runtime', see e.g. in soc-pcm.c: pcm->private_data = rtd; if (playback) pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream->private_data = rtd; if (capture) pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream->private_data = rtd; So ironically in ASoC we don't have a means to use a private_data field for the substreams since it's used for a 'standard' mechanism. The extension suggested in this patch 1/14 was really trying to come back to a practical means to store a context in a substream, and make the PCM operations manageable. I totally agree that extending the PCM runtime might not recommended or safe, but at this point I don't have any slack in the existing data structures to add a context in a substream. Does this help clarify the problem statement?

1 0

Re: [Sound-open-firmware] [PATCH v4 01/14] ASoC: SOF: Add Sound Open Firmware driver core
by Pierre-Louis Bossart 20 Feb '19

20 Feb '19

>>>> + /* private data - core does not touch */ >>>> + void *private; /* FIXME: still SOF-specific, needs to less ambiguous */ >>> Then better to name it sof_private? >> Ah, this is a mistake in the FIXME comment. >> initially we had a field called "sof" and Mark made the following comment: > ... > >> so we added a FIXME to track this, then later we moved the field and renamed >> it 'private' so that it can be used by others if needed but didn't remove >> the FIXME. Will fix this. > That doesn't really address the issue - there's multiple drivers using > any given runtime so none of them can safely use a generically named > private data field. Conversely putting a field specific to a given > driver into the core data structures opens the door to everyone wanting > their custom stuff in the core which is also a problem for different > reasons. This would be a lot easier with the DSP represented as a first > class device in the system... I see your point and agree the current direction isn't scalable, but I am not sure about the definition of 'first class device'. Did you mean 'component' at the same level as the 'platforms' and 'codecs', with all the DSP stuff nicely packaged and maintained in a self-contained way? Or a subcomponent that might be part of those platforms and codecs?

1 0

[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