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

[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

[Sound-open-firmware] [PATCH v4 0/4] Add a vhost RPMsg API
by Guennadi Liakhovetski 25 Aug '20

25 Aug '20

Hi, Now that virtio-rpmsg endianness fixes have been merged we can proceed with the next step. 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 | 375 +++++++++++++++++++++++++++++++ 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, 553 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.27.0

3 23

Re: [Sound-open-firmware] [PATCH] ASoC: SOF: imx: use resource_size
by Mark Brown 31 Jul '20

31 Jul '20

On Sun, 26 Jul 2020 10:25:33 +0200, Julia Lawall wrote: > Use resource_size rather than a verbose computation on > the end and start fields. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > <smpl> > @@ struct resource ptr; @@ > - (ptr.end - ptr.start + 1) > + resource_size(&ptr) > </smpl> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: imx: use resource_size commit: afd842c031408f9eaf689ff417071eed15afa05e 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

1 0

[Sound-open-firmware] Input/output error for simple pipeline with mixer
by Daniel Baluta 22 Jul '20

22 Jul '20

Hi Tomasz, Karol, Ranjani, I wonder if you have any clues on why $subject happens. We have a simple pipeline like this: PCM0 --> B0--+ |--mixer-->B1-->DAI PCM1 --> B1--+ Subdevices are created like this: oot@imx8qxpc0mek:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sofwm8960audio [sof-wm8960-audio], device 0: Port0 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofwm8960audio [sof-wm8960-audio], device 1: Passthrough Playback 1 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 But, when we use aplay in the following order: $ (1) aplay -Dhw:0,1 -f S32_LE -c 2 -r 48000 file1.wav $ (2) aplay -Dhw:0,0 -f S32_LE -c 2 -r 48000 file0.wav everything is OK, mixing works. But when the order is reversed: $ (2) aplay -Dhw:0,0 -f S32_LE -c 2 -r 48000 file0.wav $ (1) aplay -Dhw:0,1 -f S32_LE -c 2 -r 48000 file1.wav (1) aplay exists with an error: aplay: pcm_write:2057: write error: Input/output error I wonder if you met this. Topology looks to be symmetric with respect to PCM0/PCM1.

3 2

[Sound-open-firmware] [PATCH v3 0/5] Add a vhost RPMsg API
by Guennadi Liakhovetski 14 Jul '20

14 Jul '20

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 A further patch for the ADSP vhost RPMsg driver will be sent separately for review only since it cannot be merged without audio patches being upstreamed first. Thanks Guennadi Guennadi Liakhovetski (5): vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl vhost: (cosmetic) remove a superfluous variable initialisation 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 | 382 +++++++++++++++++++++++++++++++++++++++ drivers/vhost/vhost.c | 2 +- drivers/vhost/vhost_rpmsg.h | 74 ++++++++ include/linux/virtio_rpmsg.h | 81 +++++++++ include/uapi/linux/rpmsg.h | 3 + include/uapi/linux/vhost.h | 4 +- 10 files changed, 559 insertions(+), 81 deletions(-) create mode 100644 drivers/vhost/rpmsg.c create mode 100644 drivers/vhost/vhost_rpmsg.h create mode 100644 include/linux/virtio_rpmsg.h -- 1.9.3

6 28

Re: [Sound-open-firmware] [PATCH AUTOSEL 5.7 15/53] ASoC: SOF: Intel: add PCI IDs for ICL-H and TGL-H
by Sasha Levin 10 Jul '20

10 Jul '20

On Thu, Jul 02, 2020 at 05:05:28PM +0100, Mark Brown wrote: >On Thu, Jul 02, 2020 at 10:42:21AM -0500, Pierre-Louis Bossart wrote: >> On 7/2/20 6:18 AM, Mark Brown wrote: >> > On Wed, Jul 01, 2020 at 09:21:24PM -0400, Sasha Levin wrote: >> > > From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> > >> > > [ Upstream commit c8d2e2bfaeffa0f914330e8b4e45b986c8d30b58 ] > >> > > Usually the DSP is not traditionally enabled on H skews but this might >> > > be used moving forward. > >> > "This might be used moving forward"? > >> There are two conditions for the SOF driver to be used in a distro: >> a) the DSP needs to be enabled (as reported by the pci class info) >> b) sound/hda/intel-dsp-config.c needs to contain a quirk to select SOF over >> the legacy HDaudio, such as presence of DMIC/SoundWire or a known vendor >> DMI. > >> Traditionally for desktops neither a) nor b) are true, but this is changing: >> we will start adding quirks for specific product lines as requested by OEMs. > >> Does this answer to your question? > >The question was more of a why is this being backported one - without >those extra quirks this does nothing, and frankly with them it seems >like a *major* change someone might see in stable if they update their >kernel and it suddenly switches to an entirely different DSP software >stack. Hey Mark, It got picked up because the stable rules explicitly call out PCI IDs as something we take into the stable trees, and so the AUTOSEL brains picked up on this... I'll drop this patch as it doesn't do much. -- Thanks, Sasha

1 0