October 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v2 3/3] dt/bindings: Add milivolt, milliamps, and nanohenry units
by Paul.Handrigan＠cirrus.com 19 Oct '16

19 Oct '16

From: Paul Handrigan <Paul.Handrigan(a)cirrus.com> Add millivolt, milliamp, and nanohenry units to the Electricity category. Signed-off-by: Paul Handrigan <Paul.Handrigan(a)cirrus.com> --- Documentation/devicetree/bindings/property-units.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt index 12278d7..92d6793 100644 --- a/Documentation/devicetree/bindings/property-units.txt +++ b/Documentation/devicetree/bindings/property-units.txt @@ -25,9 +25,12 @@ Distance Electricity ---------------------------------------- -microamp : micro amps +-milliamp : milli amps -ohms : Ohms -micro-ohms : micro Ohms -microvolt : micro volts +-millivolt : micro volts +-nanohenry : nano henries Temperature ---------------------------------------- -- 1.9.1

6 5

[alsa-devel] [ANNOUNCE] Sound Open Firmware
by Liam Girdwood 19 Oct '16

19 Oct '16

Sound Open Firmware is an open source, platform/architecture independent audio firmware and SDK intended for the Linux and open source communities. The intention of SOF is to provide an open audio firmware infrastructure and SDK with the following features :- o Optimised for the Linux kernel and userspace. o Provide features not found in proprietary firmwares. o Allow easier integration with audio hardware. o Foster innovation in userspace to support audio processing features. o Fully open source firmware and SDK. SOF currently supports the xtensa audio DSP architecture found in many modern devices. Platform support currently consists of the Intel Baytrail and Cherrytrail platforms (e.g. devices like the Minnowboard Max, UP board, Asus T100, etc). The firmware is modular and abstracts the architecture/platform layers like the Linux kernel, so can be ported to other DSP architectures or target platforms. The SDK provides a compiler, emulator and image builder tools. No other tools are needed to build and run the firmware. More information can be found here on the developer wiki :- http://alsa-project.org/main/index.php/Firmware Mailing list (subscribers only) is here :- http://alsa-project.org/mailman/listinfo/sound-open-firmware Thanks Liam

1 0

[alsa-devel] [SAMPLE-PATCH 0/x] ASoC: replace snd_soc_read/write
by Kuninori Morimoto 19 Oct '16

19 Oct '16

Hi Mark, Lars-Peter These are part of "replace snd_soc_read/write to snd_soc_component_read/write" patch-set. Full-patch-set will be over 100 patches. [0/x] - [x-1/x] : ASoC: use snd_soc_component_read/write on xxxx [x/x] : ASoC: remove snd_soc_component_read/write [0/x] - [x-1/x] are almost same patches. so, I pickuped few of them for reviewing to avoid patch flood on ML. If these review were OK, I will post full-patch-set, or send git-pull-request. Main purpose of these patches are replace current snd_soc_read/write to snd_soc_component_read/write to remove codec related function. Best regards --- Kuninori Morimoto

3 8

[alsa-devel] ASoC TDM channel re-mapping
by Edward Cragg 19 Oct '16

19 Oct '16

Hi, We have an ASoC driver in which we have added support for TDM over an I2S interface. We would like to have the capability of re-mapping the channel ordering, for which i know there is a callback in place to start this process, set_channel_map. The only backend implementation of this is using the ALSA API and the .copy handler in an ALSA PCM driver to mutate data copied out of ALSA before it's DMA'd to hardware. This is in sound/soc/blackfin/bf5xx-i2s-pcm.c The problem we have is that the driver we're using currently uses a dmaengine based PCM driver, and i'm not sure whether this is compatible with using the .copy callback, without reimplementing the driver entirely as an ALSA PCM driver. Since there aren't very many examples in mainline, I was hoping to ask for advice for the best way of doing this. I wondered: - Would it be possible to add a functional copy callback using a dmaengine based PCM driver? - Otherwise, would there be a good way to implement channel remapping in a TDM frame using the dmaengine based PCM driver? or - Would the best way indeed be to reimplement the PCM driver as a normal ALSA PCM driver? Thanks, Ed Cragg

2 2

[alsa-devel] [PATCH 0/6] ASoC: rsnd: cleanup for IOMMU
by Kuninori Morimoto 19 Oct '16

19 Oct '16

Hi Mark I will post IOMMU support patches for rsnd driver. These are prepare/cleanup for it. Kuninori Morimoto (6): ASoC: rsnd: remove duplicate define of rsnd_dvc_of_node() ASoC: rsnd: amend .probe/.remove call for DPCM ASoC: rsnd: add rsnd_mod_next() for for_each_rsnd_mod_xxx() ASoC: rsnd: use for_each_rsnd_mod_xxx() on rsnd_dai_call() ASoC: rsnd: use for_each_rsnd_mod_xxx() on rsnd_rdai_continuance_probe() ASoC: rsnd: add rsnd_parse_of_node() and integrate rsnd_xxx_of_node sound/soc/sh/rcar/core.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------ sound/soc/sh/rcar/dma.c | 11 +++++++++++ sound/soc/sh/rcar/dvc.c | 2 -- sound/soc/sh/rcar/rsnd.h | 56 +++++++++++++++++++++++++++++++++++++------------------- sound/soc/sh/rcar/ssi.c | 5 ++++- 5 files changed, 125 insertions(+), 64 deletions(-) Best regards --- Kuninori Morimoto

1 6

[alsa-devel] configuring machine specific DAPM for codec + headset jack detect
by Tim Harvey 18 Oct '16

18 Oct '16

Greetings, I have a TI TLV320AIC3105 codec on a board connected to a TS3A227E headset detect chip (which handles switching pins for OMTP vs std jacks as well as jack detect and headset buttons). The AIC3105 doesn't use several of the inputs and outputs yet those inputs and outputs still have mux widgets volume widgets that are not 'off'. Is there a way to easily disable them so they a) are not muxed into mixers, b) have their gains set to 0, and c) are pruned from the list of widgets so users don't have to muddle through them in mixers? I am also fighting both a pop/click issue and am wondering if there is any easy way to disable the DAPM power up/down sequence upon playback start/complete (my application is not power sensitive). I'm still trying to understand the source of the pop/click. Additionally the TS3A227E requires MIC bias to be kept enabled in order to detect headset button presses. I see that setting idle_bias_off to false will keep the MIC bias enabled but I don't see a way to specify that via device-tree. Regards, Tim

2 4

[alsa-devel] [PATCH] ASoC: PXA: Brownstone needs I2C
by Arnd Bergmann 18 Oct '16

18 Oct '16

I rand into a new build error with SND_MMP_SOC_BROWNSTONE: warning: (SND_MMP_SOC_BROWNSTONE && SND_SOC_SAMSUNG_SMDK_WM8994 && SND_SOC_SMDK_WM8994_PCM && SND_SOC_LITTLEMILL) selects MFD_WM8994 which has unmet direct dependencies (HAS_IOMEM && I2C) drivers/mfd/wm8994-core.c:688:1: error: data definition has no type or storage class [-Werror] drivers/mfd/wm8994-core.c:688:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int] I don't see why this never showed up before, as the dependency seems to have been missing since the symbol was first introduced several years ago. This adds a dependency like the other drivers have. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/pxa/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index f2bf8661dd21..823b5a236d8d 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -208,7 +208,7 @@ config SND_PXA2XX_SOC_IMOTE2 config SND_MMP_SOC_BROWNSTONE tristate "SoC Audio support for Marvell Brownstone" - depends on SND_MMP_SOC && MACH_BROWNSTONE + depends on SND_MMP_SOC && MACH_BROWNSTONE && I2C select SND_MMP_SOC_SSPA select MFD_WM8994 select SND_SOC_WM8994 -- 2.9.0

1 0

[alsa-devel] [PATCH] ALSA: hda - allow 40 bit DMA mask for NVidia devices
by Ard Biesheuvel 18 Oct '16

18 Oct '16

Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits for Nvidia audio controllers") simply disabled any DMA exceeding 32 bits for NVidia devices, even though they are capable of performing DMA up to 40 bits. On some architectures (such as arm64), system memory is not guaranteed to be 32-bit addressable by PCI devices, and so this change prevents NVidia devices from working on platforms such as AMD Seattle. Since the original commit already mentioned that up to 40 bits of DMA is supported, and given that the code has been updated in the meantime to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf and explicitly set the DMA mask to 40 bits for NVidia devices. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- sound/pci/hda/hda_intel.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index c3469f756ec2..c64d986009a9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -341,8 +341,7 @@ enum { /* quirks for Nvidia */ #define AZX_DCAPS_PRESET_NVIDIA \ - (AZX_DCAPS_NO_MSI | /*AZX_DCAPS_ALIGN_BUFSIZE |*/ \ - AZX_DCAPS_NO_64BIT | AZX_DCAPS_CORBRP_SELF_CLEAR |\ + (AZX_DCAPS_NO_MSI | AZX_DCAPS_CORBRP_SELF_CLEAR |\ AZX_DCAPS_SNOOP_TYPE(NVIDIA)) #define AZX_DCAPS_PRESET_CTHDA \ @@ -1716,6 +1715,10 @@ static int azx_first_init(struct azx *chip) } } + /* NVidia hardware normally only supports up to 40 bits of DMA */ + if (chip->pci->vendor == PCI_VENDOR_ID_NVIDIA) + dma_bits = 40; + /* disable 64bit DMA address on some devices */ if (chip->driver_caps & AZX_DCAPS_NO_64BIT) { dev_dbg(card->dev, "Disabling 64bit DMA\n"); -- 2.7.4

3 7

[alsa-devel] [PATCH] ASoC: sst-bxt-da7219_max98357a: fix obsoleted initializer for array
by Colin King 18 Oct '16

18 Oct '16

From: Colin Ian King <colin.king(a)canonical.com> Smatch reports below warnings: bxt_da7219_max98357a.c:352:9: warning: obsolete array initializer, use C99 syntax An earlier commit cleaned up similar warnings, however, a recent commit 43c02ede76a60de ("ASoC: Intel: Add DMIC channel constraint for bxt machine") re-introduced the older initializer style. So fix this warning to make the code consistent. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c index 865a21e..bff80b4 100644 --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c @@ -348,7 +348,7 @@ static struct snd_soc_dai_link broxton_dais[] = { .dynamic = 1, .ops = &broxton_refcap_ops, }, - [BXT_DPCM_AUDIO_DMIC_CP] + [BXT_DPCM_AUDIO_DMIC_CP] = { .name = "Bxt Audio DMIC cap", .stream_name = "dmiccap", -- 2.9.3

3 2

[alsa-devel] [PATCH] sound/pci/asihpi: fix kernel memory disclosure
by Vlad Tsyrklevich 18 Oct '16

18 Oct '16

Some elements in hr are not cleared before being copied to user space, leaking kernel heap memory to user space. For example, this happens in the error handling code for the HPI_ADAPTER_DELETE case. Zero the memory before it's copied. Signed-off-by: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> --- sound/pci/asihpi/hpioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/asihpi/hpioctl.c b/sound/pci/asihpi/hpioctl.c index d17937b..7e3aa50 100644 --- a/sound/pci/asihpi/hpioctl.c +++ b/sound/pci/asihpi/hpioctl.c @@ -111,7 +111,7 @@ long asihpi_hpi_ioctl(struct file *file, unsigned int cmd, unsigned long arg) return -EINVAL; hm = kmalloc(sizeof(*hm), GFP_KERNEL); - hr = kmalloc(sizeof(*hr), GFP_KERNEL); + hr = kzalloc(sizeof(*hr), GFP_KERNEL); if (!hm || !hr) { err = -ENOMEM; goto out; -- 2.7.0

2 1