November 2017 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Disable DAPM for click avoidance ?
by Ricard Wanderlof 27 Mar '18

27 Mar '18

I'm having an issue with a codec where the normal DAPM procedure of disabling most of the codec when there is no stream ongoing results in large clicks when a playback stream starts and stops, because the output jumps from 0V when the output is disabled to over a volt when the output is enabled. There appears to be a 'slow stop/start' feature in the codec, however, it takes about one second to ramp up and down the output voltage, and that is too long a delay when starting a stream. In our usecase the power consumtion of the codec is negligable compared to the rest of the electronics, so leaving the codec running at all times is perfectly feasible. Is there any way from a machine driver to disable the DAPM switching, i.e. leave parts of the codec running at all times? In this specific case, there are two internal PM controls which enable the output. One of them is controlled by an output mixer element (SND_SOC_DAPM_MIXER_E), and the other one from set_bias_level(). I've had a look in the core code, but it seems that the whole business of changing the bias level when a stream is started is always performed and that there is no way to say "Set the bias level to ON and leave it there". An alternative would be to augment the codec driver with an 'always on' feature, which effectively always enables PM for certain parts of the chip. But it seems like the wrong place to do this type of thing. Another use for this feature is that we have had a lot of problems over the years with buggy I2S interfaces misbehaving when streams are started and stopped, and there would be an advantage to letting the AIF run the whole time after startup. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 11

[alsa-devel] [PATCH 0/8] add UniPhier audio system support
by Katsuhiro Suzuki 12 Feb '18

12 Feb '18

This series adds support for Socionext audio system for UniPhier LD11/LD20 SoCs. This driver supports I2S output for Line-In, Line-Out and S/PDIF output. UniPhier AIO DAI driver provides sound devices such as I2S, S/PDIF. Since the AIO has mixed register map for those I/Os, it is hard to split register areas for each sound devices. UniPhier EVEA is a codec core for Line-In, Line-Out. Since this core is only in internal of UniPhier series SoC, this driver works independently but only UniPhier SoC can use it. Katsuhiro Suzuki (8): ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers ASoC: uniphier: add DT bindings documentation for UniPhier EVEA ASoC: uniphier: add DT bindings documentation for UniPhier AIO ASoC: uniphier: add support for UniPhier EVEA codec ASoC: uniphier: add support for UniPhier AIO driver ASoC: uniphier: add support for UniPhier LD11/LD20 AIO driver MAINTAINERS: add entries for UniPhier ASoC sound drivers arm64: dts: uniphier: add sound node for UniPhier .../devicetree/bindings/sound/uniphier,aio.txt | 36 ++ .../devicetree/bindings/sound/uniphier,evea.txt | 26 + MAINTAINERS | 6 + .../boot/dts/socionext/uniphier-ld11-global.dts | 72 +++ arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 31 + .../boot/dts/socionext/uniphier-ld20-global.dts | 72 +++ arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 35 ++ sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/codecs/spdif_receiver.c | 5 +- sound/soc/codecs/spdif_transmitter.c | 5 +- sound/soc/uniphier/Kconfig | 34 + sound/soc/uniphier/Makefile | 8 + sound/soc/uniphier/aio-core.c | 368 +++++++++++ sound/soc/uniphier/aio-dma.c | 266 ++++++++ sound/soc/uniphier/aio-ld11.c | 343 ++++++++++ sound/soc/uniphier/aio-regctrl.c | 699 +++++++++++++++++++++ sound/soc/uniphier/aio-regctrl.h | 495 +++++++++++++++ sound/soc/uniphier/aio.h | 261 ++++++++ sound/soc/uniphier/evea.c | 567 +++++++++++++++++ 20 files changed, 3327 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/uniphier,aio.txt create mode 100644 Documentation/devicetree/bindings/sound/uniphier,evea.txt create mode 100644 sound/soc/uniphier/Kconfig create mode 100644 sound/soc/uniphier/Makefile create mode 100644 sound/soc/uniphier/aio-core.c create mode 100644 sound/soc/uniphier/aio-dma.c create mode 100644 sound/soc/uniphier/aio-ld11.c create mode 100644 sound/soc/uniphier/aio-regctrl.c create mode 100644 sound/soc/uniphier/aio-regctrl.h create mode 100644 sound/soc/uniphier/aio.h create mode 100644 sound/soc/uniphier/evea.c -- 2.15.0

4 19

[alsa-devel] [PATCH 0/x] ASoC: replace platform to component
by Kuninori Morimoto 12 Feb '18

12 Feb '18

Hi Mark These are for replace "platform" to "component". It needs 3 steps I think. step1. "component" needs _add_ function, like "platform" step2. "component" level pcm_new/free support step3. replace platform to component We can get platform pointer from rtd->platform on current style. But these are very categorized pointer, in other words, non generic pointer. This cleanup is 1st step of merging all feature into component. I think new style wil be CPU + Codec + Platform = Component I think merging CPU into Component is already done. This patch set merges Platform feature into Component, and remove Platform. Merging Codec into Component is next step. This patch set will add new rtd connected component list. All CPU/Codec/Platform are connected to this list. And we can get each component pointer by using rtd and its driver name. Here, We can replace rtd->platform like below - struct device *dev = rtd->platform->dev; + struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd, DRIVER_NAME); + struct device *dev = component->dev; - if(rtd->platform->pcm_new) - rtd->platform->pcm_new(yyy); + for_each_rtdcom(rtd, rtdcom) { + component = rtdcom->component; /* rtd connected CPU/Codec/Platform */ + if (component->pcm_new) + component->pcm_new(yyy); + } Now, only platform has pcm_new/free, but in new style, all component can have it. I will post step1/2/3 patch-set. step1 is normal patches. step2/3 are now still [RFC]. Best regards --- Kuninori Morimoto

2 23

[alsa-devel] [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink
by Jeffy Chen 25 Jan '18

25 Jan '18

The rt5514 dsp captures pcm data through spi directly, so we should not use rockchip-i2s as it's cpu dai like other codecs. Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again. Reported-by: Jimmy Cheng-Yi Chiang <cychiang(a)google.com> Fixes: (72cfb0f20c75 ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp) Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> --- sound/soc/rockchip/rk3399_gru_sound.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c index d64fbbd50544..aa8ffd035377 100644 --- a/sound/soc/rockchip/rk3399_gru_sound.c +++ b/sound/soc/rockchip/rk3399_gru_sound.c @@ -367,7 +367,8 @@ static const struct snd_soc_dai_link rockchip_dais[] = { [DAILINK_RT5514_DSP] = { .name = "RT5514 DSP", .stream_name = "Wake on Voice", - .codec_dai_name = "rt5514-dsp-cpu-dai", + .codec_name = "snd-soc-dummy", + .codec_dai_name = "snd-soc-dummy-dai", }, }; @@ -528,7 +529,18 @@ static int rockchip_sound_of_parse_dais(struct device *dev, if (index < 0) continue; - np_cpu = (index == DAILINK_CDNDP) ? np_cpu1 : np_cpu0; + switch (index) { + case DAILINK_CDNDP: + np_cpu = np_cpu1; + break; + case DAILINK_RT5514_DSP: + np_cpu = np_codec; + break; + default: + np_cpu = np_cpu0; + break; + } + if (!np_cpu) { dev_err(dev, "Missing 'rockchip,cpu' for %s\n", rockchip_dais[index].name); @@ -538,7 +550,8 @@ static int rockchip_sound_of_parse_dais(struct device *dev, dai = &card->dai_link[card->num_links++]; *dai = rockchip_dais[index]; - dai->codec_of_node = np_codec; + if (!dai->codec_name) + dai->codec_of_node = np_codec; dai->platform_of_node = np_cpu; dai->cpu_of_node = np_cpu; -- 2.11.0

3 2

[alsa-devel] [PATCH 4/6] alsa-lib:pcm: fix the hw_ptr update until the boundary available.
by sutar.mounesh＠gmail.com 19 Jan '18

19 Jan '18

From: mahendran.k <mahendran.kuppusamy(a)in.bosch.com> For long time test case, the slave_hw_ptr will exceed the boundary and wraparound the slave_hw_ptr. This slave boundary wraparound will cause the rate->hw_ptr to wraparound irrespective of the rate->boundary availability and due to that the available size goes wrong. Hence, To get the correct available size, - Its necessary to increment the rate->hw_ptr upto the rate->boundary and then wraparound the rate->hw_ptr. - While handling fraction part of slave period, rounded value will be introduced by input_frames(). To eliminate rounding issue on rate->hw_ptr, subtract last rounded value from rate->hw_ptr and add new rounded value of present slave_hw_ptr fraction part to rate->hw_ptr. Signed-off-by: mahendran.k <mahendran.kuppusamy(a)in.bosch.com> Signed-off-by: Mounesh Sutar <mounesh_sutar(a)mentor.com> diff --git a/src/pcm/pcm_rate.c b/src/pcm/pcm_rate.c index 1f830dd..5bee77c 100644 --- a/src/pcm/pcm_rate.c +++ b/src/pcm/pcm_rate.c @@ -50,7 +50,7 @@ typedef struct _snd_pcm_rate snd_pcm_rate_t; struct _snd_pcm_rate { snd_pcm_generic_t gen; - snd_pcm_uframes_t appl_ptr, hw_ptr; + snd_pcm_uframes_t appl_ptr, hw_ptr, last_slave_hw_ptr; snd_pcm_uframes_t last_commit_ptr; snd_pcm_uframes_t orig_avail_min; snd_pcm_sw_params_t sw_params; @@ -563,14 +563,28 @@ static inline void snd_pcm_rate_sync_hwptr0(snd_pcm_t *pcm, snd_pcm_uframes_t sl { snd_pcm_rate_t *rate = pcm->private_data; + snd_pcm_sframes_t slave_hw_ptr_diff = slave_hw_ptr - rate->last_slave_hw_ptr; + snd_pcm_sframes_t last_slave_hw_ptr_frac; + if (pcm->stream != SND_PCM_STREAM_PLAYBACK) return; - /* FIXME: boundary overlap of slave hw_ptr isn't evaluated here! - * e.g. if slave rate is small... - */ - rate->hw_ptr = - (slave_hw_ptr / rate->gen.slave->period_size) * pcm->period_size + - rate->ops.input_frames(rate->obj, slave_hw_ptr % rate->gen.slave->period_size); + + if (slave_hw_ptr_diff < 0) + slave_hw_ptr_diff += rate->gen.slave->boundary; /* slave boundary wraparound */ + else if (slave_hw_ptr_diff == 0) + return; + last_slave_hw_ptr_frac = rate->last_slave_hw_ptr % rate->gen.slave->period_size; + /* While handling fraction part fo slave period, rounded value will be introduced by input_frames(). + * To eliminate rounding issue on rate->hw_ptr, subtract last rounded value from rate->hw_ptr and + * add new rounded value of present slave_hw_ptr fraction part to rate->hw_ptr. Hence, + * rate->hw_ptr += [ (no. of updated slave periods * pcm rate period size) - + * fractional part of last_slave_hw_ptr rounded value + + * fractional part of updated slave hw ptr's rounded value ] */ + rate->hw_ptr += ( + (((last_slave_hw_ptr_frac + slave_hw_ptr_diff) / rate->gen.slave->period_size) * pcm->period_size) - + rate->ops.input_frames(rate->obj, last_slave_hw_ptr_frac) + + rate->ops.input_frames(rate->obj, (last_slave_hw_ptr_frac + slave_hw_ptr_diff) % rate->gen.slave->period_size)); + rate->last_slave_hw_ptr = slave_hw_ptr; rate->hw_ptr %= pcm->boundary; } @@ -635,6 +649,7 @@ static int snd_pcm_rate_prepare(snd_pcm_t *pcm) return err; *pcm->hw.ptr = 0; *pcm->appl.ptr = 0; + rate->last_slave_hw_ptr = 0; err = snd_pcm_rate_init(pcm); if (err < 0) return err; @@ -650,6 +665,7 @@ static int snd_pcm_rate_reset(snd_pcm_t *pcm) return err; *pcm->hw.ptr = 0; *pcm->appl.ptr = 0; + rate->last_slave_hw_ptr = 0; err = snd_pcm_rate_init(pcm); if (err < 0) return err; -- 1.7.9.5

3 2

[alsa-devel] [PATCH v5 00/13] Add STM32 DFSDM support
by Arnaud Pouliquen 10 Jan '18

10 Jan '18

Hello, Here is a new version integrating remarks from Rob and Jonathan. Main deltas vs V4: - Integrate ASOC DAI not as a subnode of the DFSDM. - Add in kernel consumer interface to allow to manipulate attribute. Context reminder: ----------------- DFSDM peripheral is a peripheral that allows to connect some sigma delta ADCs or PDM microphones via a SPI or Manchester bus. DFSDM integrates digital filters to offer up to 24 bits final resolution. In term of SW architecture. 2 use-cases have to be supported: 1) Sigma delta ADC conversion through IIO framework. Sigma delta ADC is handled by generic sigma delta modulator driver. DFSDM peripheral is binded to a SD modulator ADC using the IIO HW consumer interface. Please notice that IIO HW consumer interface has be proposed by Lars, but is part of this patchset with Lars's agreement. User interface is IIO one. Notice that this patch-set propose only a raw conversion, to simplify review. Buffer and trigger management will be added in next patch-sets. 2) PDM microphone record through ALSA framework. PDM microphone is handled by ASOC Generic DMIC codec driver. ADFSDM ASOC DAI driver is binded to IIO driver using the IIO consumer interface ADFSDM ASOC DAI driver is binded to a PDM microphone ASOC component using ASOC Of_graph. User interface is ALSA one. As IIO DMA management is not adapted to an audio realtime stream. A specific DMA management has been implemented in IIO driver for audio purposes. Regards, Arnaud Arnaud Pouliquen (12): docs: driver-api: add iio hw consumer section IIO: hw_consumer: add devm_iio_hw_consumer_alloc IIO: inkern: API for manipulating channel attributes IIO: Add DT bindings for sigma delta adc modulator IIO: ADC: add sigma delta modulator support IIO: add DT bindings for stm32 DFSDM filter IIO: ADC: add stm32 DFSDM core support IIO: ADC: add STM32 DFSDM sigma delta ADC support IIO: ADC: add stm32 DFSDM support for PDM microphone IIO: consumer: allow to set buffer sizes ASoC: add bindings for stm32 DFSDM filter ASoC: stm32: add DFSDM DAI support Lars-Peter Clausen (1): iio: Add hardware consumer buffer support .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 16 + .../bindings/iio/adc/sigma-delta-modulator.txt | 13 + .../bindings/iio/adc/st,stm32-dfsdm-adc.txt | 127 ++ .../devicetree/bindings/sound/st,stm32-adfsdm.txt | 62 + Documentation/driver-api/iio/hw-consumer.rst | 51 + Documentation/driver-api/iio/index.rst | 1 + drivers/iio/adc/Kconfig | 37 + drivers/iio/adc/Makefile | 3 + drivers/iio/adc/sd_adc_modulator.c | 81 ++ drivers/iio/adc/stm32-dfsdm-adc.c | 1232 ++++++++++++++++++++ drivers/iio/adc/stm32-dfsdm-core.c | 318 +++++ drivers/iio/adc/stm32-dfsdm.h | 319 +++++ drivers/iio/buffer/Kconfig | 10 + drivers/iio/buffer/Makefile | 1 + drivers/iio/buffer/industrialio-buffer-cb.c | 11 + drivers/iio/buffer/industrialio-hw-consumer.c | 248 ++++ drivers/iio/inkern.c | 18 +- include/linux/iio/adc/stm32-dfsdm-adc.h | 28 + include/linux/iio/consumer.h | 37 + include/linux/iio/hw-consumer.h | 22 + sound/soc/stm/Kconfig | 11 + sound/soc/stm/Makefile | 3 + sound/soc/stm/stm32_adfsdm.c | 386 ++++++ 23 files changed, 3030 insertions(+), 5 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 create mode 100644 Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt create mode 100644 Documentation/driver-api/iio/hw-consumer.rst create mode 100644 drivers/iio/adc/sd_adc_modulator.c create mode 100644 drivers/iio/adc/stm32-dfsdm-adc.c create mode 100644 drivers/iio/adc/stm32-dfsdm-core.c create mode 100644 drivers/iio/adc/stm32-dfsdm.h create mode 100644 drivers/iio/buffer/industrialio-hw-consumer.c create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h create mode 100644 include/linux/iio/hw-consumer.h create mode 100644 sound/soc/stm/stm32_adfsdm.c -- 2.7.4

4 21

[alsa-devel] [PATCH v4 00/12] Add STM32 DFSDM support
by Arnaud Pouliquen 10 Jan '18

10 Jan '18

Hello, Here is a new version of the DFSDM proposed. Context reminder: ----------------- DFSDM peripheral is a peripheral that allows to connect some sigma delta ADCs or PDM microphones via a SPI or Manchester bus. DFSDM integrates digital filters to offer up to 24 bits final resolution. In term of SW architecture. 2 use-cases have to be supported: 1) Sigma delta ADC conversion through IIO framework. Sigma delta ADC is handled by generic sigma delta modulator driver. DFSDM peripheral is binded to a SD modulator ADC using the IIO HW consumer interface. Please notice that IIO HW consumer interface has be proposed by Lars, but is part of this patchset with Lars's agreement. User interface is IIO one. Notice that this patch-set propose only a raw conversion, to simplify review. Buffer and trigger management will be added in next patch-sets. 2) PDM microphone record through ALSA framework. PDM microphone is handled by ASOC Generic DMIC codec driver. ADFSDM ASOC DAI driver is binded to IIO driver using the IIO consumer interface ADFSDM ASOC DAI driver is binded to a PDM microphone ASOC component using ASOC Of_graph. User interface is ALSA one. As IIO DMA management is not adapted to an audio realtime stream. A specific DMA management has been implemented in IIO driver for audio purposes. History of the versions: ----------------------- V3: Implementation with DMA support in IIO instead of handling it in ASOC. - New patches to support ASoC DMA codec in DT - ASoC: Add Bindins for DMIC codec driver. - ASoC: codec: add DT support in dmic codec. - New patches to allow in-kernel set of IIO buffer size and watermark - IIO: consumer: allow to set buffer sizes. - IIO DFSDM drivers - Split audio and ADC support in 2 drivers. - Implement DMA cyclic mode. - Add SPI bus Trigger for buffer management. - IIO sigma delta adc drivers - Suppress "simple and rename driver. - ASoC driver - Suppress DMA engine. - Suppress copy ops. - Use IIO consmumer interface to enable/Disable DFSDM. V2: Patch-set associated to this RFC proposes an implementation of the DFSDM features shared between ASoC and IIO frameworks. Patch-set is only a Skeleton of the drivers, so a base to discuss and validate a design. It contains minimum code to allow probing (with DT) and to expose the ASoC and IIO ABI. Hope that is sufficent in a first step to allow to focus on APIs. In this patch-set there are two new APIs used: - IIO in-kern API: based on hw_customer API proposed by Lars - ASOC <-> IIO API inspired by API defined for hdmi-codec for ASoC/DRM interconnect. API is dedicated to DFSDM only. Notice also that this design is based on following assumption: - Audio stream ABI interface is ASoC, no access to data through IIO ABI for PDM. - ASoC DMA should be used for audio transfer as designed for real time stream. - Need some runtime parameters exchange between ASoC and IIO due to the correlation between the sample frequency, the DFSDM decimation factor and the associated scaling. - "ASoC: dmaengine_pcm: add copy support" patch: I added a patch in ASoC that allows to implement a copy function to process data after DMA transfer. Requested, as DFSDM samples captured contain channel ID on 8-LSB bits and need also a potential rescale to present DAT on 24-bits. - "IIO: ADC: add sigma delta modulator support" patch: Simple dummy driver created to support external Sigma delta modulator. It is binded to DFSDM driver through hw_customer API. Regards, Arnaud Arnaud Pouliquen (11): docs: driver-api: add iio hw consumer section IIO: hw_consumer: add devm_iio_hw_consumer_alloc IIO: Add DT bindings for sigma delta adc modulator IIO: ADC: add sigma delta modulator support IIO: add DT bindings for stm32 DFSDM filter IIO: ADC: add stm32 DFSDM core support IIO: ADC: add STM32 DFSDM sigma delta ADC support IIO: ADC: add stm32 DFSDM support for PDM microphone IIO: consumer: allow to set buffer sizes ASoC: add bindings for stm32 DFSDM filter ASoC: stm32: add DFSDM DAI support Lars-Peter Clausen (1): iio: Add hardware consumer buffer support .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 22 + .../bindings/iio/adc/sigma-delta-modulator.txt | 13 + .../bindings/iio/adc/st,stm32-dfsdm-adc.txt | 127 ++ .../devicetree/bindings/sound/st,stm32-adfsdm.txt | 63 + Documentation/driver-api/iio/hw-consumer.rst | 50 + Documentation/driver-api/iio/index.rst | 1 + drivers/iio/adc/Kconfig | 37 + drivers/iio/adc/Makefile | 3 + drivers/iio/adc/sd_adc_modulator.c | 82 ++ drivers/iio/adc/stm32-dfsdm-adc.c | 1250 ++++++++++++++++++++ drivers/iio/adc/stm32-dfsdm-core.c | 318 +++++ drivers/iio/adc/stm32-dfsdm.h | 319 +++++ drivers/iio/buffer/Kconfig | 10 + drivers/iio/buffer/Makefile | 1 + drivers/iio/buffer/industrialio-buffer-cb.c | 11 + drivers/iio/buffer/industrialio-hw-consumer.c | 248 ++++ include/linux/iio/adc/stm32-dfsdm-adc.h | 27 + include/linux/iio/consumer.h | 11 + include/linux/iio/hw-consumer.h | 22 + sound/soc/stm/Kconfig | 11 + sound/soc/stm/Makefile | 3 + sound/soc/stm/stm32_adfsdm.c | 388 ++++++ 22 files changed, 3017 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 create mode 100644 Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt create mode 100644 Documentation/driver-api/iio/hw-consumer.rst create mode 100644 drivers/iio/adc/sd_adc_modulator.c create mode 100644 drivers/iio/adc/stm32-dfsdm-adc.c create mode 100644 drivers/iio/adc/stm32-dfsdm-core.c create mode 100644 drivers/iio/adc/stm32-dfsdm.h create mode 100644 drivers/iio/buffer/industrialio-hw-consumer.c create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h create mode 100644 include/linux/iio/hw-consumer.h create mode 100644 sound/soc/stm/stm32_adfsdm.c -- 2.7.4

4 28

[alsa-devel] [RFC PATCH 0/7] Fix Intel audio Kconfig issues
by Pierre-Louis Bossart 08 Jan '18

08 Jan '18

At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up. The first patch *should* implement what Linus, Takashi and Mark tried to explain by email. There should be no functionality change and could be merged if deemed ok. The rest of the patch series does a more in-depth cleanup and should not be merged without more testing (hence the RFC). The 4th patch is really the most important one, there were nested configs which made no sense to me. I don't know the history which led to such complicated stuff but simpler is better. The last 3 patches are just clean-ups of the machine driver configs, for some reason there is no consistency in the settings so I tried to apply common sense. There might be additional cleanup needed since I don't really get why we need references to LPSS or DESIGNWARE for things which are not visible to a machine driver, we should only depend on IC2 or SPI in my opinion - depending on what the control interface is. I tried to keep things to a minimum in each patch to make the reviews easier, if people want them squashed that's fine by me. I'll do some more testing on my side but I could use feedback. Thanks! Pierre-Louis Bossart (7): ASoC: Intel: Fix Kconfig ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies ASoC: Intel: document what Kconfig options do ASoC: Intel: Fix nested/unnecessary Kconfig dependencies ASoC: Intel: boards: align Kconfig dependencies for Haswell/Broadwell ASoC: Intel: boards: align Kconfig configurations for HiFi2 ASoC: Intel: boards: align/fix SKL/BXT/KBL Kconfigs sound/soc/intel/Kconfig | 89 ++++++++++++++++++-------- sound/soc/intel/boards/Kconfig | 140 ++++++++++++++++++++++------------------- 2 files changed, 137 insertions(+), 92 deletions(-) -- 2.14.1

8 30

[alsa-devel] ALSA: Soc_compress open file node allows more than once
by b_lkasam＠codeaurora.org 28 Dec '17

28 Dec '17

Hi ALSA team, This is regarding compress offload framework file operations wrt open system call. For open call to this driver currently allows for same node more than once. This may result in memleak issues or data corruption if same node in use by multiple instances. can we have restriction to avoid open of same node using some refcount? we can either have refcount under compr->private_data and cross check in below function before proceeding. static int snd_compr_open(struct inode *inode, struct file *f) Please suggest accordingly. Thanks Laxminath Kasam, Qualcomm.

3 3

[alsa-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver
by Oleksandr Andrushchenko 22 Dec '17

22 Dec '17

Hi, all! Foreword ======== This RFC is aimed to introduce support of para-virtualized sound frontend driver for Xen [1] and gather opinions from the relevant communities (ALSA, Xen). It implements the protocol from [2] with the following limitations: - mute/unmute is not supported - get/set volume is not supported Volume control is not supported for the reason that most of the use-cases (at the moment) are based on scenarios where unprivileged OS (e.g. Android, AGL etc) uses software mixers. Both capture and playback are supported. The relevant backend is implemented as a user-space application [3] and uses accompanying helper library [4]. Both frontend driver and backend were tested on real HW running Xen hypervisor (Renesas R-Car ARM based H3/M3 boards, x86). Discussion ========== During the first attempt to upstream the driver [5] number of comments and concerns were raised, one of the biggest flaws in the design were questioned by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of synchronization between frontend and backend during capture/playback. Two options were discussed: “In design of ALSA PCM core, drivers are expected to synchronize to actual hardwares for semi-realtime data transmission. The synchronization is done by two points: 1) Interrupts to respond events from actual hardwares. 2) Positions of actual data transmission in any serial sound interfaces of actual hardwares. “ and finally a change to the existing protocol was suggested: “In 'include/xen/interface/io/sndif.h', there's no functionalities I described the above: 1. notifications from DomU to Dom0 about the size of period for interrupts from actual hardwares. Or no way from Dom0 to DomU about the configured size of the period. 2. notifications of the interrupts from actual hardwares to DomU.” This is implemented as a change to the sndif protocol [8] and allows removing period emulation: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend (in Linux implementation). Sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. Along with these changes other comments on the driver were addressed, e.g. split into smaller chunks, moved the driver from misc to xen etc. Hope, this helps to get the full picture of what was discussed and makes it possible to move forward. Waiting for your valuable comments, Thank you, Oleksandr [1] https://github.com/andr2000/linux/commits/snd_upstream_v1 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc… [3] https://github.com/xen-troops/snd_be [4] https://github.com/xen-troops/libxenbe [5] https://lkml.org/lkml/2017/8/7/363 [6] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html [7] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de560…

3 6