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

[Sound-open-firmware] [PATCH 0/8] use semicolons rather than commas to separate statements
by Julia Lawall 27 Oct '20

27 Oct '20

These patches replace commas by semicolons. This was done using the Coccinelle semantic patch (http://coccinelle.lip6.fr/) shown below. This semantic patch ensures that commas inside for loop headers will not be transformed. It also doesn't touch macro definitions. Coccinelle ensures that braces are added as needed when a single-statement branch turns into a multi-statement one. This semantic patch has a few false positives, for variable delcarations such as: LIST_HEAD(x), *y; The semantic patch could be improved to avoid these, but for the moment they have been removed manually (2 occurrences). // <smpl> @initialize:ocaml@ @@ let infunction p = (* avoid macros *) (List.hd p).current_element <> "something_else" let combined p1 p2 = (List.hd p1).line_end = (List.hd p2).line || (((List.hd p1).line_end < (List.hd p2).line) && ((List.hd p1).col < (List.hd p2).col)) @bad@ statement S; declaration d; position p; @@ S@p d // special cases where newlines are needed (hope for no more than 5) @@ expression e1,e2; statement S; position p != bad.p; position p1; position p2 : script:ocaml(p1) { infunction p1 && combined p1 p2 }; @@ - e1@p1,@S@p e2@p2; + e1; e2; @@ expression e1,e2; statement S; position p != bad.p; position p1; position p2 : script:ocaml(p1) { infunction p1 && combined p1 p2 }; @@ - e1@p1,@S@p e2@p2; + e1; e2; @@ expression e1,e2; statement S; position p != bad.p; position p1; position p2 : script:ocaml(p1) { infunction p1 && combined p1 p2 }; @@ - e1@p1,@S@p e2@p2; + e1; e2; @@ expression e1,e2; statement S; position p != bad.p; position p1; position p2 : script:ocaml(p1) { infunction p1 && combined p1 p2 }; @@ - e1@p1,@S@p e2@p2; + e1; e2; @@ expression e1,e2; statement S; position p != bad.p; position p1; position p2 : script:ocaml(p1) { infunction p1 && combined p1 p2 }; @@ - e1@p1,@S@p e2@p2; + e1; e2; @r@ expression e1,e2; statement S; position p != bad.p; @@ e1 ,@S@p e2; @@ expression e1,e2; position p1; position p2 : script:ocaml(p1) { infunction p1 && not(combined p1 p2) }; statement S; position r.p; @@ e1@p1 -,@S@p +; e2@p2 ... when any // </smpl> --- sound/firewire/fireworks/fireworks_pcm.c | 2 +- sound/pci/hda/patch_ca0132.c | 2 +- sound/pci/hda/patch_hdmi.c | 2 +- sound/soc/codecs/madera.c | 4 ++-- sound/soc/codecs/wm8350.c | 3 ++- sound/soc/intel/boards/bytcr_rt5651.c | 2 +- sound/soc/samsung/snow.c | 2 +- sound/soc/soc-dapm.c | 2 +- sound/soc/sof/intel/hda-dsp.c | 2 +- 9 files changed, 11 insertions(+), 10 deletions(-)

2 2

[Sound-open-firmware] [PATCH 0/3] ASoC: sof: cleanup Kconfig files
by Randy Dunlap 14 Oct '20

14 Oct '20

Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: Daniel Baluta <daniel.baluta(a)nxp.com> Cc: sound-open-firmware(a)alsa-project.org Cc: alsa-devel(a)alsa-project.org Some general editing of sound/soc/sof/ Kconfig files: [PATCH 1/3] ASoC: sof: imx: fix Kconfig punctuation [PATCH 2/3] ASoC: sof: intel: fix Kconfig punctuation and wording [PATCH 3/3] ASoC: sof: Kconfig: fix Kconfig punctuation and wording sound/soc/sof/Kconfig | 42 +++++++++++------------ sound/soc/sof/imx/Kconfig | 10 ++--- sound/soc/sof/intel/Kconfig | 62 +++++++++++++++++----------------- 3 files changed, 57 insertions(+), 57 deletions(-)

2 5

[Sound-open-firmware] [PATCH v6 0/4] Add a vhost RPMsg API
by Guennadi Liakhovetski 01 Oct '20

01 Oct '20

Hi, Next update: v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" / AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development, ready for review and submission, available at https://github.com/thesofproject/linux/pull/1501/commits Thanks Guennadi Guennadi Liakhovetski (4): vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl rpmsg: move common structures and defines to headers rpmsg: update documentation vhost: add an RPMsg API Documentation/rpmsg.txt | 6 +- drivers/rpmsg/virtio_rpmsg_bus.c | 78 +------ drivers/vhost/Kconfig | 7 + drivers/vhost/Makefile | 3 + drivers/vhost/rpmsg.c | 373 +++++++++++++++++++++++++++++++ drivers/vhost/vhost_rpmsg.h | 74 ++++++ include/linux/rpmsg/virtio.h | 83 +++++++ include/uapi/linux/rpmsg.h | 3 + include/uapi/linux/vhost.h | 4 +- 9 files changed, 551 insertions(+), 80 deletions(-) create mode 100644 drivers/vhost/rpmsg.c create mode 100644 drivers/vhost/vhost_rpmsg.h create mode 100644 include/linux/rpmsg/virtio.h -- 2.28.0

4 22

[Sound-open-firmware] [ANNOUNCE] SOF v1.6-rc3 released
by Liam Girdwood 29 Sep '20

29 Sep '20

The SOF developers are pleased to announce the release of our first signed release candidate for v1.6. i.e v1.6-rc3 Binaries can be found here. https://github.com/thesofproject/sof-bin/tree/stable-v1.6 New features are * Support for Intel Tigerlake * Support for Maxim Smart Amplifiers * Beamformer Microphone support. * DC blocker audio processing component. * Major feature and performance improvements for ASRC, KWD and FIR/IIR. * Numerous bug fixes and performance improvements for Intel and NXP platforms. In a change from the previous release process, the later release candidates will now be signed by Intel so that users can have the chance to test drive prior to v1.6 final. This will also give distributions more time to integrate and resolve any issues. Firmware issues can be reported here. https://github.com/thesofproject/sof/issues Thanks Liam

1 0

[Sound-open-firmware] [PATCH v7 0/3] Add a vhost RPMsg API
by Guennadi Liakhovetski 21 Sep '20

21 Sep '20

Hi, Next update: v7: - remove documentation update to be send separately - address comments from Mathieu Poirier (thanks) v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" / AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development, ready for review and submission, available at https://github.com/thesofproject/linux/pull/1501/commits Thanks Guennadi Guennadi Liakhovetski (3): vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl rpmsg: move common structures and defines to headers vhost: add an RPMsg API drivers/rpmsg/virtio_rpmsg_bus.c | 78 +------ drivers/vhost/Kconfig | 7 + drivers/vhost/Makefile | 3 + drivers/vhost/rpmsg.c | 370 +++++++++++++++++++++++++++++++ drivers/vhost/vhost_rpmsg.h | 74 +++++++ include/linux/rpmsg/virtio.h | 83 +++++++ include/uapi/linux/rpmsg.h | 3 + include/uapi/linux/vhost.h | 4 +- 8 files changed, 545 insertions(+), 77 deletions(-) create mode 100644 drivers/vhost/rpmsg.c create mode 100644 drivers/vhost/vhost_rpmsg.h create mode 100644 include/linux/rpmsg/virtio.h -- 2.28.0

3 10

[Sound-open-firmware] [PATCH v5 0/4] Add a vhost RPMsg API
by Guennadi Liakhovetski 16 Sep '20

16 Sep '20

Hi, Next update: v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" / AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development, ready for review and submission, available at https://github.com/thesofproject/linux/pull/1501/commits Thanks Guennadi Guennadi Liakhovetski (4): vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl rpmsg: move common structures and defines to headers rpmsg: update documentation vhost: add an RPMsg API Documentation/rpmsg.txt | 6 +- drivers/rpmsg/virtio_rpmsg_bus.c | 78 +------ drivers/vhost/Kconfig | 7 + drivers/vhost/Makefile | 3 + drivers/vhost/rpmsg.c | 373 +++++++++++++++++++++++++++++++ drivers/vhost/vhost_rpmsg.h | 74 ++++++ include/linux/virtio_rpmsg.h | 83 +++++++ include/uapi/linux/rpmsg.h | 3 + include/uapi/linux/vhost.h | 4 +- 9 files changed, 551 insertions(+), 80 deletions(-) create mode 100644 drivers/vhost/rpmsg.c create mode 100644 drivers/vhost/vhost_rpmsg.h create mode 100644 include/linux/virtio_rpmsg.h -- 2.28.0

3 21

[Sound-open-firmware] A branch can be used as to-be-upstreamed?
by Takashi Iwai 08 Sep '20

08 Sep '20

Hi, as we got a bug report about the new Dell laptop with SoundWire audio, I tried to build a kernel with the downstream SOF patches, then I noticed that it's not so trivial to get the patches from SOF git tree that are applicable on top of upstream (either sound or Linus) tree. Do we have a branch that may contain clean commits on top of the recent upstream? That is, a branch that is regularly rebased, so that each commit can be retrieved as a patch. Such a branch will make upstream submission easier, and it makes easier for distros to take the downstream patches, too. thanks, Takashi

4 4

[Sound-open-firmware] Inclusive terminology in SOF
by Sridharan, Ranjani 31 Aug '20

31 Aug '20

Hi All, Recently, Linux kernel and other Open-Source software have been making changes to replace non-inclusive terminologies as in [1]. I was wondering if there are plans for SOF to follow suit as well. Particularly, I am looking for guidance on the multi-core terminology to replace the usage of master/slave cores with maybe primary/secondary cores or something along those lines. There are other instances related to SSP/SPI where we use similar terminology but that likely needs wider approval/acceptance. Appreciate your feedback. Thanks, Ranjani [1] https://lkml.org/lkml/2020/7/4/229

2 1

[Sound-open-firmware] DMA copy flow question
by Daniel Baluta 30 Aug '20

30 Aug '20

Hello, Looking at the code in dai.c, we have: pipeline_trigger() (COMP_TRIGGER_START) -> dai_start() [1] -> dma_start() [2] -> pipeline_schedule_copy() [3] -> pipeline_copy() In our implementation, dai_start() will generate a DMA request immediately and dma_start() will generate a transfer immediately. The biggest problem is that the IRQ handler for DMA request is registered only at point (3) thus sometimes first DMA interrupt is lost resulting in copy not being started. (DMA IRQ is edge triggered). Can one point how working with DMA should look like?

1 0

[Sound-open-firmware] mixer and formats question
by Pierre-Louis Bossart 27 Aug '20

27 Aug '20

Hi, we have a rather odd issue [1] with mixer/formats, where somehow an error is thrown by firmware when we play an S24/32_LE PCM stream through a mixer and into a DAI configured in S16_LE (because of codec restrictions) I could use feedback on the following points: a) was it really a design decision to assume that all sources to the mixer share the same format? b) if yes, how is the format for a mixer defined? We typically convert using volume elements, but somehow a mixer would need to be set-up with a predefined format (i.e. not propagated by hw_params()) if we want the volume elements to know when/what to convert. I see in my experiments that the format for the mixer sources and sinks seems to be changed dynamically, which doesn't seem quite right to me. c) if no, same question "how is the format of the mixer defined"? we would need to have the ability to set a format for the mixer so that it can convert on the fly, but we don't seem to set formats anywhere except for PCM streams and DAIs. Thanks, -Pierre [1] https://github.com/thesofproject/sof/pull/3341

3 4