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

[alsa-devel] [PATCH 00/51] DMA mask changes
by Russell King - ARM Linux 15 Nov '13

15 Nov '13

This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some cases rather buggy. I tried to get some of the bug fixes in before the last merge window, but it seems that the maintainers preferred to have the full solution rather than a simple -rc suitable bug fix. So, this is an attempt to clean things up. The first point here is that drivers performing DMA should be calling dma_set_mask()/dma_set_coherent_mask() in their probe function to verify that DMA can be performed. Lots of ARM drivers omit this step; please refer to the DMA API documentation on this subject. What this means is that the DMA mask provided by bus code is a default value - nothing more. It doesn't have to accurately reflect what the device is actually capable of. Apart from the storage for dev->dma_mask being initialised for any device which is DMA capable, there is no other initialisation which is strictly necessary at device creation time. Now, these cleanups address two major areas: 1. The setting of DMA masks, particularly when both the coherent and streaming DMA masks are set together. 2. The initialisation of DMA masks by drivers - this seems to be becoming a popular habbit, one which may not be entirely the right solution. Rather than having this scattered throughout the tree, I've pulled that into a central location (and called it coercing the DMA mask - because it really is about forcing the DMA mask to be that value.) 3. Finally, addressing the long held misbelief that DMA masks somehow correspond with physical addresses. We already have established long ago that dma_addr_t values returned from the DMA API are the values which you program into the DMA controller, and so are the bus addresses. It is _only_ sane that DMA masks are also bus related too, and not related to physical address spaces. (3) is a very important point for LPAE systems, which may still have less than 4GB of memory, but this memory is all located above the 4GB physical boundary. This means with the current model, any device using a 32-bit DMA mask fails - even though the DMA controller is still only a 32-bit DMA controller but the 32-bit bus addresses map to system memory. To put it another way, the bus addresses have a 4GB physical offset on them. This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Patches based on v3.12-rc1. Documentation/DMA-API-HOWTO.txt | 37 +++++++++------ Documentation/DMA-API.txt | 8 +++ arch/arm/include/asm/dma-mapping.h | 8 +++ arch/arm/mm/dma-mapping.c | 49 ++++++++++++++++++-- arch/arm/mm/init.c | 12 +++--- arch/arm/mm/mm.h | 2 + arch/powerpc/kernel/vio.c | 3 +- block/blk-settings.c | 8 ++-- drivers/amba/bus.c | 6 +-- drivers/ata/pata_ixp4xx_cf.c | 5 ++- drivers/ata/pata_octeon_cf.c | 5 +- drivers/block/nvme-core.c | 10 ++--- drivers/crypto/ixp4xx_crypto.c | 48 ++++++++++---------- drivers/dma/amba-pl08x.c | 5 ++ drivers/dma/dw/platform.c | 8 +-- drivers/dma/edma.c | 6 +-- drivers/dma/pl330.c | 4 ++ drivers/firmware/dcdbas.c | 23 +++++----- drivers/firmware/google/gsmi.c | 13 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 ++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +- drivers/media/platform/omap3isp/isp.c | 6 +- drivers/media/platform/omap3isp/isp.h | 3 - drivers/mmc/card/queue.c | 3 +- drivers/mmc/host/sdhci-acpi.c | 5 +- drivers/net/ethernet/broadcom/b44.c | 3 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 8 +--- drivers/net/ethernet/brocade/bna/bnad.c | 13 ++---- drivers/net/ethernet/emulex/benet/be_main.c | 12 +---- drivers/net/ethernet/intel/e1000/e1000_main.c | 9 +--- drivers/net/ethernet/intel/e1000e/netdev.c | 18 +++----- drivers/net/ethernet/intel/igb/igb_main.c | 18 +++----- drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++----- drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++----- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 ++---- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 ++---- drivers/net/ethernet/nxp/lpc_eth.c | 6 ++- drivers/net/ethernet/octeon/octeon_mgmt.c | 5 +- drivers/net/ethernet/sfc/efx.c | 12 +----- drivers/net/wireless/b43/dma.c | 9 +--- drivers/net/wireless/b43legacy/dma.c | 9 +--- drivers/of/platform.c | 3 - drivers/parport/parport_pc.c | 8 +++- drivers/scsi/scsi_lib.c | 2 +- drivers/staging/dwc2/platform.c | 5 +- drivers/staging/et131x/et131x.c | 17 +------ drivers/staging/imx-drm/imx-drm-core.c | 8 +++- drivers/staging/imx-drm/ipuv3-crtc.c | 4 +- drivers/staging/media/dt3155v4l/dt3155v4l.c | 5 +-- drivers/usb/chipidea/ci_hdrc_imx.c | 7 +-- drivers/usb/dwc3/dwc3-exynos.c | 7 +-- drivers/usb/gadget/lpc32xx_udc.c | 4 +- drivers/usb/host/bcma-hcd.c | 3 +- drivers/usb/host/ehci-atmel.c | 7 +-- drivers/usb/host/ehci-octeon.c | 4 +- drivers/usb/host/ehci-omap.c | 10 ++-- drivers/usb/host/ehci-orion.c | 7 +-- drivers/usb/host/ehci-platform.c | 10 ++-- drivers/usb/host/ehci-s5p.c | 7 +-- drivers/usb/host/ehci-spear.c | 7 +-- drivers/usb/host/ehci-tegra.c | 7 +-- drivers/usb/host/ohci-at91.c | 9 ++-- drivers/usb/host/ohci-exynos.c | 7 +-- drivers/usb/host/ohci-nxp.c | 5 +- drivers/usb/host/ohci-octeon.c | 5 +- drivers/usb/host/ohci-omap3.c | 10 ++-- drivers/usb/host/ohci-pxa27x.c | 8 ++-- drivers/usb/host/ohci-sa1111.c | 6 +++ drivers/usb/host/ohci-spear.c | 7 +-- drivers/usb/host/ssb-hcd.c | 3 +- drivers/usb/host/uhci-platform.c | 7 +-- drivers/usb/musb/am35x.c | 50 +++++++-------------- drivers/usb/musb/da8xx.c | 49 +++++++------------- drivers/usb/musb/davinci.c | 48 +++++++------------- drivers/usb/musb/tusb6010.c | 49 +++++++------------- drivers/video/amba-clcd.c | 5 ++ include/linux/amba/bus.h | 2 - include/linux/dma-mapping.h | 31 +++++++++++++ sound/arm/pxa2xx-pcm.c | 9 +--- sound/soc/atmel/atmel-pcm.c | 11 ++--- sound/soc/blackfin/bf5xx-ac97-pcm.c | 11 ++--- sound/soc/blackfin/bf5xx-i2s-pcm.c | 10 ++--- sound/soc/davinci/davinci-pcm.c | 9 +--- sound/soc/fsl/fsl_dma.c | 9 +--- sound/soc/fsl/mpc5200_dma.c | 10 ++--- sound/soc/jz4740/jz4740-pcm.c | 12 ++--- sound/soc/kirkwood/kirkwood-dma.c | 9 +--- sound/soc/nuc900/nuc900-pcm.c | 9 ++-- sound/soc/omap/omap-pcm.c | 11 ++--- sound/soc/pxa/pxa2xx-pcm.c | 11 ++--- sound/soc/s6000/s6000-pcm.c | 9 +--- sound/soc/samsung/dma.c | 11 ++--- sound/soc/samsung/idma.c | 11 ++--- 93 files changed, 493 insertions(+), 566 deletions(-)

10 54

[alsa-devel] [PATCH 00/10] Yet another small covery bug fixes
by Takashi Iwai 15 Nov '13

15 Nov '13

Hi, here is yet another series of fixes for bugs reported by coverity. Mostly driver-specific bugs, no serious ones, as far as I look over them. Takashi

2 12

[alsa-devel] [PATCH v2 1/2] ASoC: dmaengine-pcm: Add support for querying DMA capabilities
by Lars-Peter Clausen 13 Nov '13

13 Nov '13

Currently each platform making use the the generic dmaengine PCM driver still needs to provide a custom snd_pcm_hardware struct which specifies the capabilities of the DMA controller, e.g. the maximum period size that can be supported. This patch adds code which uses the newly introduced dma_get_slave_caps() API to query this information from the dmaengine driver. The new code path will only be taken if the 'pcm_hardware' field of the snd_dmaengine_pcm_config struct is NULL. The patch also introduces a new 'fifo_size' field to the snd_dmaengine_dai_dma_data struct which is used to initialize the snd_pcm_hardware 'fifo_size' field and needs to be set by the DAI driver. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Changes since v1: * Use dma_get_max_seg_size() to get the maximum size of one period * Assume that a DMA engine driver is able to support an infinite number of periods * Increase min_period_bytes from 16 to 256. --- include/sound/dmaengine_pcm.h | 2 ++ sound/soc/soc-generic-dmaengine-pcm.c | 55 ++++++++++++++++++++++++++++------- 2 files changed, 47 insertions(+), 10 deletions(-) diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h index f11c35c..83b2c3e 100644 --- a/include/sound/dmaengine_pcm.h +++ b/include/sound/dmaengine_pcm.h @@ -61,6 +61,7 @@ struct dma_chan *snd_dmaengine_pcm_get_chan(struct snd_pcm_substream *substream) * @slave_id: Slave requester id for the DMA channel. * @filter_data: Custom DMA channel filter data, this will usually be used when * requesting the DMA channel. + * @fifo_size: FIFO size of the DAI controller in bytes */ struct snd_dmaengine_dai_dma_data { dma_addr_t addr; @@ -68,6 +69,7 @@ struct snd_dmaengine_dai_dma_data { u32 maxburst; unsigned int slave_id; void *filter_data; + unsigned int fifo_size; }; void snd_dmaengine_pcm_set_config_from_dai_data( diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index e29ec3c..c39e19e 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -36,6 +36,15 @@ static struct dmaengine_pcm *soc_platform_to_pcm(struct snd_soc_platform *p) return container_of(p, struct dmaengine_pcm, platform); } +static struct device *dmaengine_dma_dev(struct dmaengine_pcm *pcm, + struct snd_pcm_substream *substream) +{ + if (!pcm->chan[substream->stream]) + return NULL; + + return pcm->chan[substream->stream]->device->dev; +} + /** * snd_dmaengine_pcm_prepare_slave_config() - Generic prepare_slave_config callback * @substream: PCM substream @@ -92,28 +101,54 @@ static int dmaengine_pcm_hw_params(struct snd_pcm_substream *substream, return snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params)); } -static int dmaengine_pcm_open(struct snd_pcm_substream *substream) +static int dmaengine_pcm_set_runtime_hwparams(struct snd_pcm_substream *substream) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct dmaengine_pcm *pcm = soc_platform_to_pcm(rtd->platform); + struct device *dma_dev = dmaengine_dma_dev(pcm, substream); struct dma_chan *chan = pcm->chan[substream->stream]; + struct snd_dmaengine_dai_dma_data *dma_data; + struct dma_slave_caps dma_caps; + struct snd_pcm_hardware hw; int ret; - ret = snd_soc_set_runtime_hwparams(substream, + if (pcm->config->pcm_hardware) + return snd_soc_set_runtime_hwparams(substream, pcm->config->pcm_hardware); - if (ret) - return ret; - return snd_dmaengine_pcm_open(substream, chan); + dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream); + + memset(&hw, 0, sizeof(hw)); + hw.info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | + SNDRV_PCM_INFO_INTERLEAVED; + hw.periods_min = 2; + hw.periods_max = UINT_MAX; + hw.period_bytes_min = 256; + hw.period_bytes_max = dma_get_max_seg_size(dma_dev); + hw.buffer_bytes_max = SIZE_MAX; + hw.fifo_size = dma_data->fifo_size; + + ret = dma_get_slave_caps(chan, &dma_caps); + if (ret == 0) { + if (dma_caps.cmd_pause) + hw.info |= SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME; + } + + return snd_soc_set_runtime_hwparams(substream, &hw); } -static struct device *dmaengine_dma_dev(struct dmaengine_pcm *pcm, - struct snd_pcm_substream *substream) +static int dmaengine_pcm_open(struct snd_pcm_substream *substream) { - if (!pcm->chan[substream->stream]) - return NULL; + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct dmaengine_pcm *pcm = soc_platform_to_pcm(rtd->platform); + struct dma_chan *chan = pcm->chan[substream->stream]; + int ret; - return pcm->chan[substream->stream]->device->dev; + ret = dmaengine_pcm_set_runtime_hwparams(substream); + if (ret) + return ret; + + return snd_dmaengine_pcm_open(substream, chan); } static void dmaengine_pcm_free(struct snd_pcm *pcm) -- 1.8.0

3 12

[alsa-devel] [PATCHv1 0/8] ALSA: Add SAI driver and enable SGT15000 codec.
by Xiubo Li 12 Nov '13

12 Nov '13

This patch series is mostly Freescale's SAI SoC Digital Audio Interface driver implementation. And the implementation is only compatible with device tree definition. This patch series is based on linux-next and has been tested on Vybrid VF610 Tower board using device tree. Added in v1: - Add SAI SoC Digital Audio Interface driver. - Add Freescale SAI ALSA SoC Digital Audio Interface node for VF610. - Enables SAI ALSA SoC DAI device for Vybrid VF610 TOWER board. - Add device tree bindings for Freescale SAI. - Revise the bugs about the sgt15000 codec. - Add SGT15000 based audio machine driver. - Enable SGT15000 codec based audio driver node for VF610. - Add device tree bindings for Freescale VF610 sound.

10 46

[alsa-devel] [COMPRESS] [PATCH] ALSA: compress_core: don't return -EBADFD from poll if paused
by Richard Fitzgerald 12 Nov '13

12 Nov '13

Pausing audio playback is not an illegal state so it doesn't seem sensible for poll() to return -EBADFD on a paused stream. There's also no reason to assume that we can't write more data to the DSP while playback is paused. Remove the -EBADFD so that a stream in paused state will still report the buffer availability from poll(). It is up to the user process to manage its state so that it knows whether it is paused or not. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- sound/core/compress_offload.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index bea523a..30ca133 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -384,8 +384,7 @@ static unsigned int snd_compr_poll(struct file *f, poll_table *wait) return -EFAULT; mutex_lock(&stream->device->lock); - if (stream->runtime->state == SNDRV_PCM_STATE_PAUSED || - stream->runtime->state == SNDRV_PCM_STATE_OPEN) { + if (stream->runtime->state == SNDRV_PCM_STATE_OPEN) { retval = -EBADFD; goto out; } -- 1.7.2.5

3 2

[alsa-devel] [TINYCOMPRESS][PATCH] compress: compress_wait() must return error if timed out
by Richard Fitzgerald 12 Nov '13

12 Nov '13

The caller must be certain that a return of 0 really means that compress is ready for more data, so when poll() returns 0 for a timeout we must report that as an error. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> --- compress.c | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/compress.c b/compress.c index 5cd0966..d1a2283 100644 --- a/compress.c +++ b/compress.c @@ -616,15 +616,17 @@ int compress_wait(struct compress *compress, int timeout_ms) fds.events = POLLOUT | POLLIN; ret = poll(&fds, 1, timeout_ms); - if (fds.revents & POLLERR) { - return oops(compress, EIO, "poll returned error!"); + if (ret > 0) { + if (fds.revents & POLLERR) + return oops(compress, EIO, "poll returned error!"); + if (fds.revents & (POLLOUT | POLLIN)) + return 0; } - /* A pause will cause -EBADFD or zero. */ - if ((ret < 0) && (ret != -EBADFD)) + if (ret == 0) + return oops(compress, ETIME, "poll timed out"); + if (ret < 0) return oops(compress, errno, "poll error"); - if (fds.revents & (POLLOUT | POLLIN)) { - return 0; - } - return ret; + + return oops(compress, EIO, "poll signalled unhandled event"); } -- 1.7.2.5

2 1

Re: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600
by Alan Stern 10 Nov '13

10 Nov '13

On Tue, 8 Oct 2013 baumber(a)hotmail.com wrote: > Hello, > > please help me with the bug for my Logitech Headset; > > https://bugzilla.kernel.org/show_bug.cgi?id=62691 > > Bug ID: 62691 > Summary: no reset_resume for driver snd-usb-audio for logitech headset H600 > > Thank you > > Best regards, Bernhard Actually this should be brought to the attention of the ALSA developers (CC'ed). They are the people in charge of the snd-usb-audio driver. Alan Stern

4 8

[alsa-devel] [RFC/RFT v2 0/4] ALSA: hda - hdmi: ATI/AMD multi-channel and HBR support
by Anssi Hannula 08 Nov '13

08 Nov '13

Hi all! Here is a second revision of the ATI/AMD multichannel patch, now a patchset. Since the last revision from a bit over the week ago, AMD has released more documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf ), so the patchset contains new additions: - HBR bitstreaming support (HD passthrough, for DTS-HD and Dolby TrueHD) o This completes the set, now we have HBR on NVIDIA, Intel and AMD :) - More complete ELD emulation on revision 3+ (0x100300) codecs o Untested, though from what I can see the newly added fields may not be filled in yet by the radeon driver. - Ramp up/down configuration according to non-pcm bit on rev3+ o I guess this means gradual fade-in/out? Untested. Other changes since the previous post: - ELD emulation moved to hda_eld.c and cleaned up a bit - Some fixes to hdmi_chmap_ctl_tlv() changes (and maybe something else I forgot - if so, sorry) Also, the pairwise channel mapping code has been tested to work with custom channel maps. The TLV contents are shown as follows by amixer: | chmap-paired=FL,FR | chmap-paired=FL,FR,NA,LFE | chmap-paired=FL,FR,FC,NA | chmap-paired=FL,FR,RL,RR | chmap-paired=FL,FR,FC,LFE | chmap-paired=FL,FR,NA,LFE,RL,RR | chmap-paired=FL,FR,FC,NA,RL,RR [etc] Rafał, do you know about the missing (AFAICS) support for lipsync (F7B) and sink information (F81) in radeon driver? This patchset requires at least more testing before it should be applied. A few other somewhat open things: - I named everything ati/ATI except for is_amdhdmi_rev3() and has_amd_full_remap_support() that are AMD-only, though AMD-only verbs I still named ATI to have similar names to other verbs. Does that seem sensible or how should this be done? - Currently setup_audio_infoframe() writes the channel mapping every time for ATI/AMD, should we try to avoid that? If so, any suggestions? (argh, just noticed this is broken for manual channel maps on non-ATI; if just the chmap is changed, channel mapping is not updated; so this requires fixes in the generic side as well) I'm especially interested in testers with: - Older codecs other than 0x1002aa01. My best guess still is that the new code works on them as well. o On these I'd like to know if multichannel and the new formats work, i.e. e.g. speaker-test -D hdmi:CARD=Generic,DEV=0 -c8 -r192000 -F S32_LE - Codec 0x1002aa01 revisions 0x100300 (Rev ID 3) or later (see /proc/asound/cardX/codec#Y). These are HD7750+ I think. Stuff to be tested on these: o The ramp up/down stuff, i.e. patch 4. Is there any difference seen with these, in the beginning/end (i.e. fade-out/in): speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x04 -c2 -r48000 speaker-test -D hdmi:CARD=Generic,DEV=0,AES0=0x06 -c2 -r48000 Also, is there a difference in the beginning of these (maybe garbage sound and/or slightly slower startup?): aplay -Dhdmi:CARD=Generic,DEV=0,AES0=4 -r44100 -f s16_le -c2 testi.dts.cut.spdif aplay -Dhdmi:CARD=Generic,DEV=0,AES0=6 -r44100 -f s16_le -c2 testi.dts.cut.spdif o Contents of /proc/asound/cardX/eld#0. I'd like to see the contents both with radeon and with the proprietary fglrx driver in use Olivier, can you test again on your rev3 hw? :) The patchset can be found in combined form (for e.g. testing purposes) at: http://onse.fi/files/atihdmi5.patch The test file referenced above can be found at: http://onse.fi/files/testi.dts.cut.spdif.gz (just regular DTS) Anssi Hannula (4): ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs sound/pci/hda/hda_eld.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ sound/pci/hda/hda_local.h | 5 +++ sound/pci/hda/patch_hdmi.c | 424 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------ 3 files changed, 547 insertions(+), 39 deletions(-) -- Anssi Hannula

4 29

[alsa-devel] async between dmaengine_pcm_dma_complete and snd_pcm_release
by Qiao Zhou 05 Nov '13

05 Nov '13

Hi Mark, Liam, Jaroslav, Takashi I met an issue in which kernel panic appears in dmaengine_pcm_dma_complete function on a quad-core system. The dmaengine_pcm_dma_complete is running core0, while snd_pcm_release has already been executed on core1, due to in low memory stress oom killer kills the audio thread to release some memory. snd_pcm_release frees the runtime parameters, and runtime is used in dmaengine_pcm_dma_complete, which is a callback from tasklet in dmaengine. In current audio driver, we can't promise that dmaengine_pcm_dma_complete is not executed after snd_pcm_release on multi cores. Maybe we should add some protection. Do you have any suggestion? I have tried to apply below workaround, which can fix the panic, but I'm not confident it's proper. Need your comment and better suggestion. From d568a88e8f66ee21d44324bdfb48d2a3106cf0d1 Mon Sep 17 00:00:00 2001 From: Qiao Zhou <zhouqiao(a)marvell.com> Date: Wed, 9 Oct 2013 15:24:29 +0800 Subject: [PATCH] ASoC: soc-dmaengine: add mutex to protect runtime param under SMP arch, the dmaengine_pcm_dma_complete callback has the chance to run on one cpu while at the same time, the substream is released on another cpu. thus it may access param which is already freed. we need to add mutes to protect such access, and check PCM availability before using it. Signed-off-by: Qiao Zhou <zhouqiao(a)marvell.com> --- sound/soc/soc-dmaengine-pcm.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c index 111b7d9..5917029 100644 --- a/sound/soc/soc-dmaengine-pcm.c +++ b/sound/soc/soc-dmaengine-pcm.c @@ -125,13 +125,22 @@ EXPORT_SYMBOL_GPL(snd_hwparams_to_dma_slave_config); static void dmaengine_pcm_dma_complete(void *arg) { struct snd_pcm_substream *substream = arg; - struct dmaengine_pcm_runtime_data *prtd = substream_to_prtd(substream); + struct dmaengine_pcm_runtime_data *prtd; + + mutex_lock(&substream->pcm->open_mutex); + if (!substream || !substream->runtime) { + mutex_unlock(&substream->pcm->open_mutex); + return; + } + + prtd = substream_to_prtd(substream); prtd->pos += snd_pcm_lib_period_bytes(substream); if (prtd->pos >= snd_pcm_lib_buffer_bytes(substream)) prtd->pos = 0; snd_pcm_period_elapsed(substream); + mutex_unlock(&substream->pcm->open_mutex); } static int dmaengine_pcm_prepare_and_submit(struct snd_pcm_substream *substream) -- 1.7.0.4 -- Best Regards Qiao

4 18

[alsa-devel] NVIDIA HDMI: Channel remapping does not work for stereo?
by Anssi Hannula 04 Nov '13

04 Nov '13

Hi! I just noticed while testing the ALSA HDMI channel remapping code that my NVIDIA codec 0x10de0015 does not seem to follow the Audio Sample Packet (ASP) channel mapping (set by verb F34h as per HDA spec 7.3.3.41) when playing back stereo audio. This can be reproduced by e.g.: $ speaker-test -c2 -Dhdmi:CARD=NVidia,DEV=0 -m FR,FL The channels are reversed compared to what the printout is (i.e. the codec plays the streams straight-through instead of swapping channels as instructed). E.g. this works expectedly, however: $ speaker-test -c4 -Dhdmi:CARD=NVidia,DEV=1 -m FR,FL,RR,RL (note that recent sound git master or for-next is needed for these kind of remappings to work properly at all) On Intel HDMI codec 0x80862806 both work. While stereo right-left swapping is admittedly a rather corner-case situation, I guess we should probably refuse such chmaps when they are not supported. Aaron, do you have any information on whether this affects all NVIDIA HDMI codecs? -- Anssi Hannula

3 5