Alsa-devel September 2013

alsa-devel@alsa-project.org

119 participants
213 discussions

[alsa-devel] alsa/asoundlib.h file not found
by Appalayagari Sreedhar 05 Dec '13

05 Dec '13

Hi, I have integrated the codec driver and the kernel log shows the sound card is detected. now i want to test the codec. i tried the sample test code for capture and playback. i am getting a compilation errors due to the asoundlib.h. please find the error log for my application. main.c:2:23: error: asoundlib.h: No such file or directory main.c: In function 'main': main.c:7: error: 'snd_pcm_t' undeclared (first use in this function) main.c:7: error: (Each undeclared identifier is reported only once main.c:7: error: for each function it appears in.) main.c:7: error: 'pcm_handle' undeclared (first use in this function) main.c:10: error: 'snd_pcm_stream_t' undeclared (first use in this function) main.c:10: error: expected ';' before 'stream' main.c:15: error: 'snd_pcm_hw_params_t' undeclared (first use in this function) main.c:15: error: 'hwparams' undeclared (first use in this function) main.c:22: warning: 'return' with a value, in function returning void main.c:34: error: 'snd_pcm_uframes_t' undeclared (first use in this function) main.c:34: error: expected ';' before 'periodsize' main.c:46: error: 'SND_PCM_ACCESS_RW_INTERLEAVED' undeclared (first use in this function) main.c:48: warning: 'return' with a value, in function returning void main.c:52: error: 'SND_PCM_FORMAT_S16_LE' undeclared (first use in this function) main.c:54: warning: 'return' with a value, in function returning void main.c:62: warning: 'return' with a value, in function returning void main.c:65:19: warning: missing terminating " character main.c:65: error: missing terminating " character main.c:66: error: expected expression before '==' token main.c:66: error: stray '\' in program main.c:66:31: warning: missing terminating " character main.c:66: error: missing terminating " character main.c:67: error: expected ';' before '}' token main.c:72: warning: 'return' with a value, in function returning void main.c:78: warning: 'return' with a value, in function returning void main.c:86: error: 'periodsize' undeclared (first use in this function) main.c:88: warning: 'return' with a value, in function returning void main.c:99: warning: 'return' with a value, in function returning void main.c:112: warning: incompatible implicit declaration of built-in function 'malloc' main.c:115: error: 'num_frames' undeclared (first use in this function) main.c:5: warning: return type of 'main' is not 'int' please suggest what needs to be done to resolve this issue asap. Thank you, Sreedhar.

5 4

[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 0/3] dma: edma: Add cyclic DMA support
by Joel Fernandes 31 Oct '13

31 Oct '13

The following series adds Cyclic DMA support to TI EDMA DMA Engine driver. First we split out the calculations for the Slave DMA case into a separate function so that we may reuse it for the calculations of Cyclic DMA parameters. Next patch then adds the actual support for Cyclic DMA, enables interrupts correctly and uses's the callbacks in virt-dma during interrupts thus signalling back to the ALSA layer that a period was transmitted. Some background on motivation for this series: Currently, only user of Cyclic DMA in EDMA is davinci-pcm driver. As of today, this driver directly calls into the EDMA private API (arch/arm/common/edma.c) without going through the DMAEngine. davinci-pcm in future will be modified to use DMA Engine framework for Cyclic DMA instead of directly using the Private API. However that's a much larger effort, involving dealing with ping-pong from SRAM on user's of the Davinci McASP, etc. As a first step, we add Cyclic DMA support to the EDMA driver so that this may be used when the actual conversion of davinci-pcm happens. Tested series along with couple of hacks to davinci-pcm to work with DMA Engine: git@github.com:joelagnel/linux-kernel.git (branch dma/cyclic) Joel Fernandes (3): dma: edma: Split out PaRAM set calculations into its own function dma: edma: Add support for Cyclic DMA dma: edma: Increase maximum SG limit to 20 drivers/dma/edma.c | 350 +++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 273 insertions(+), 77 deletions(-) -- 1.8.1.2

2 11

[alsa-devel] Variable Delay through ALSA driver
by Brandon Yates 25 Oct '13

25 Oct '13

I have an application using the ALSA API that writes to playback device and simultaneously reads from capture device. My processing loop is : 1)Read from microphone (blocking) 2)Process Data 3)Write to speaker I am measuring the delay from the time I play a series of frames to the speaker until I detect the echo of this coming back in through the microphone. This delay seems to be changing every time I initialize the devices with ALSA. I have measured in the range of 60-160ms delay. I know things like period size effect delay, but using the exact same software and hardware configuration I would expect this to be constant across runs. What are some parameters that can help me make the delay deterministic? Thanks, Brandon

3 2

[alsa-devel] [PATCH v2 00/11] Fix AM335x-evm analog audio support
by jsarha＠ti.com 23 Oct '13

23 Oct '13

From: Jyri Sarha <jsarha(a)ti.com> The first version of patches can been found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066178.… Changes for v2 - Dropped our "ASoC: davinci-mcasp: Add pinctrl support" since driver core is taking care of this now. - Cleanup am33xx audio build - Add regulators to tlv320aic3x DT binding document - Remove dm365-voice-codec-audio DT support as it has never been tested an probably does not work - Add output pins and Line In connector to davinci-evm-audio DT binding doc - Remove asp_chan_q and ram_chan_q properties from mcasp DT node in DT mode mcasp is hardcoded to event queue 0 (highest priority) - Add pins to tlv320aic3x DT bindings document. If I misunderstood Marks comment and this patch is not needed, then just leave it out Changes based on TI internal discussions - Move system clock rate logic away from from evm_hw_params soc-op - Remove unnecesary #if defined(CONFIG_OF) from davinci-evm.c - Make dma property DT binding document more exact - Add only "dma" reg location instead of separate "dma-tx" and "dma-rx" - Primarily look for "mpu" reg property, but fall back to index 0 if not found - Remove interrupt property from mcasp DT node as it is not used - Remove #address-cells and #size-cells mcasp properties as they are not needed This set of patches fixes the basic audio support for am335x-evm. It should also be relatively simple to add the necessary nodes to relevant dts files to get BeagleBone + AudioCape and am335x-evmsk working too. The patch set depends on following patches: [PATCH v11 4/8] ARM: dts: add AM33XX EDMA support https://lkml.org/lkml/2013/6/18/49 [PATCH v11 5/8] ARM: dts: add AM33XX SPI DMA support https://lkml.org/lkml/2013/6/18/55 [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA resources https://lkml.org/lkml/2013/7/22/441 I have tried my best not to break the existing support for older davinci boards, but since I do not have those boards I can not be sure. Some commit comments refer to a dmaengine based davinci audio implementation which is planned for but nothing has been done yet. Best regards, Jyri Darren Etheridge (1): ARM/dts: am335x-evm: Add audio support for am335x-evm.dts Hebbar, Gururaja (2): ASoC: davinci-evm: Add device tree binding ASoC: davinci: Add support for AM33xx SoC Audio Jyri Sarha (7): ASoC: davinci-evm: Move sysclk logic away from evm_hw_params ASoC: davinci-mcasp: Add DMA register locations to DT ASoC: davinci-mcasp: Extract DMA channels directly from DT ASoC: davinci-mcasp: Remove interrupt property from DT bindings doc ASoC: tlv320aic3x: Add regulators to DT bindings document ASoC: tlv320aic3x: Add codec pins to DT bindings document ARM/dts: am33xx: mcasp: Add new dma register location to reg-property Pantelis Antoniou (1): ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries .../bindings/sound/davinci-evm-audio.txt | 58 ++++++ .../bindings/sound/davinci-mcasp-audio.txt | 15 +- .../devicetree/bindings/sound/tlv320aic3x.txt | 26 +++ arch/arm/boot/dts/am335x-evm.dts | 56 ++++++ arch/arm/boot/dts/am33xx.dtsi | 25 +++ include/linux/platform_data/davinci_asp.h | 2 + sound/soc/davinci/Kconfig | 18 +- sound/soc/davinci/Makefile | 1 + sound/soc/davinci/davinci-evm.c | 184 +++++++++++++++++--- sound/soc/davinci/davinci-mcasp.c | 106 +++++++---- 10 files changed, 428 insertions(+), 63 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/davinci-evm-audio.txt -- 1.7.9.5

9 121

[alsa-devel] Questions about virtual ALSA driver (dummy), PortAudio and full-duplex drops
by Smilen Dimitrov 21 Oct '13

21 Oct '13

Hi list(s), Apologies in advance for the longish exposition - however, I have bumped into a problem with ALSA driver development, which raised some questions that I cannot really understand at the moment. I find it especially frustrating that I cannot formulate a simple question, but instead I have to resort to test code, captures and plots, to discuss my (mis)conceptions through those - so I hope at least someone will bear with this wall of text (some 23KB plaintext), and I'll be able to get some help with this. I originally started working on a 16-bit, 44.1 kHz stereo ALSA driver for a device; and came to a point where I could achieve (what I thought was) full-duplex by running `arecord` and `aplay`, in separate shells, without any problems. However, if I tried to do the same from `audacity` - that is, have "record" running, while another track plays on the same card, with "Audacity Preferences/Recording/Overdub: Play other tracks while recording new one" enabled - then I'd experience some strange drops in the capture, which were not reported by any debug messages, even after I rebuilt and used PortAudio with debug messages on (my eventual goal is to have this experiment running in Audacity without drops). (Therefore CC to audacity-devel, since I first started looking for "audacity full duplex drops" and couldn't find much; and CC to portaudio since some of my questions depend on correct understanding of PortAudio). Anyways, I think I managed to reconstruct the drop problem I get (with my device driver and `audacity`), by using a modified command line program from the tests in the PortAudio distribution, and a modified `dummy` driver from the ALSA distribution. The complete code and test scripts are available in this directory: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/ I ran this on Ubuntu 11.04 Natty, Linux 2.6.38 and corresponding ALSA 1.0.24.2, audacity-1.3.13, PortAudio V19 - more about my machine and environment setup is in the Readme: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/Readme In that directory there is a script, `run-alsa-pa-tests.sh`; which compiles: the ALSA driver from `dummy-2.6.32-patest.c`; and the PortAudio program from `patest_duplex_wire.c`; with different compile-time defines - and then runs the program, obtaining verbose logs (some timestamped through `ftrace`), which end up as .csv files. The .csv files are finally plotted in the time domain using a gnuplot script, `traceLogGraph.gp`, through a batch script `batch_traceLogFile.sh`. Note you may have to change some hardcoded values in the source codes, if you want to run this collection on your machine - see the Readme for more. The file `captures01-04.tar.gz` contains complete logs from four runs of `run-alsa-pa-tests.sh` (NB: +70MB expanded), with respective `traceLogGraph.gp` gnuplot scripts that allow for reconstruction of all .png images; while the `captures_0*/` directories contain only some .pngs (those that will be referenced here). Back to the problem: once I started working with `patest_duplex_wire.c`, I realised there are actually two ways to implement "full-duplex", understood simply as "playback and record at the same time", in PortAudio: * By using two separate `PaStream*`s, with two `Pa_OpenStream`s and `Pa_StartStream`s, started one right after the other - and using their separate "record" (capture) and "play" callbacks * By using a single `PaStream*`, which correspondingly has only one callback ("wire" callback), which handles memory copying in both playback and capture directions In Audacity, as far as I could see, there is only one PortAudio callback defined (audacity-1.3.13/src/AudioIO.cpp has audacityAudioCallback;), so Audacity basically has a single "wire" callback for full-duplex. Because of that, both Audacity and `patest_duplex_wire.c` (when using a single stream/"wire" callback), can enter this section of portaudio-v19/src/hostapi/alsa/pa_linux_alsa.c: if( !xrun ) { /* Get the number of available frames for the pcms that are marked ready. * @concern FullDuplex If only one direction is marked ready (from poll), the number of frames available for * the other direction is returned. Output is normally preferred over capture however, so capture frames may be * discarded to avoid overrun unless paNeverDropInput is specified. */ int captureReady = self->capture.pcm ? self->capture.ready : 0, playbackReady = self->playback.pcm ? self->playback.ready : 0; PA_ENSURE( PaAlsaStream_GetAvailableFrames( self, captureReady, playbackReady, framesAvail, &xrun ) ); if( self->capture.pcm && self->playback.pcm ) { if( !self->playback.ready && !self->neverDropInput ) { /* Drop input, a period's worth */ PA_MDEBUG(( "%s: full-duplex (not xrun): Drop input, a period's worth - fra:%lu \n", __FUNCTION__, *framesAvail )); //added assert( self->capture.ready ); PaAlsaStreamComponent_EndProcessing( &self->capture, PA_MIN( self->capture.framesPerBuffer, *framesAvail ), &xrun ); *framesAvail = 0; self->capture.ready = 0; } } else if( self->capture.pcm ) assert( self->capture.ready ); else assert( self->playback.ready ); } ... ... which is precisely the section that seems to be causing the full-duplex capture drops I experience. I think I tried `neverDropInput` with `patest_duplex_wire.c`, and it kept segfaulting - but in any case, I don't think Audacity (at least this version) has any UI to manipulate this parameter; so I'd rather code the ALSA driver properly, so PortAudio thinks it's getting a proper full-duplex stream from it. However, this is where I get stuck - because all I can see in the code snippet are boolean conditions. Thus I cannot see what the condition is to enter this segment - in terms of variables visible from the ALSA driver (like dpcm->pcm_buf_pos, or snd_pcm_capture_avail/_hw_avail(substream->runtime)). In other words, I'd like to know what sort of rule should the ALSA driver variables observe, so the above "drop input" section is never entered when using a single PortAudio stream/"wire" callback. This is the reason why I tried adding some extra debugging statements to PortAudio (see `audacity-portaudio.patch` in the online folder), to obtain logs through `ftrace` - in hope that I'd get accurate timestamps from both user- and kernel- space, against which variable values from logs could be plotted. In brief, some of the variables on the plots are: * frabCC/frabPC = framesAvail (Capture/Playback) in bytes from CallbackThreadFunc (pa_linux_alsa.c) * frabCW/frabPW = framesAvail (Capture/Playback) in bytes from PaAlsaStream_WaitForFrames (pa_linux_alsa.c) * frgbtc/frgbtp = framesGot (Capture/Playback) in bytes total (cumulative); CallbackThreadFunc (pa_linux_alsa.c) * pav/cav/phwav/chwav = snd_pcm_playback/capture_avail/_hw_avail(substream->runtime) in bytes (dummy-2.6.32-patest.c) * aptbC/aptbP/hptbC/hptbP = (Capture/Playback) substream->runtime->control->appl_ptr/hw_ptr in bytes (dummy-2.6.32-patest.c) [ When a single PortAudio "wire" callback is used, only frabCC, frabCW and frgbtc appear (there are no separate playback variants then) - however, the driver still has separate timer functions/tasklets for each direction (playback or capture). ] The original `dummy` driver has code for both Linux kernel system timers, and for high-resolution timers; the driver builds on my system automatically with hrtimers, which is what I'm interested in. Initially, I started by working with hrtimer functions set to a period of one jiffy: since HZ in my OS is defined as 250, one jiffy is 1/HZ = 1/250 = 4 ms - and then I calculated bytes per period as total bytes per second 44100*2*2 = 176400 divided by HZ, which gives 176400/250 = 705.6 ; and then I tried to increase dpcm->pcm_buf_pos with 705 each time the hrtimer tasklet was called (those captures have folder names ending with `_jif`). That results in a behavior like this: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… That is a capture with driver debug tracing (D), fixed bytes per period in driver (F), playback+record callbacks in `patest_duplex_wire.c` (pr), with request of 512 FRAMES_PER_BUFFER (512). What I find surprising here, is that driver's `chwav` (and `cav`) stay mostly constant, "resetting" themselves in just three "hits" of the timer/tasklet after 0.12 sec; while `pav` slowly raises (and `phwav` slowly falls) - until a point after 0.12 sec, where they "reset" themselves in just one "hit" of the timer function. Furthermore, `frabPC`, `frabCC` and `frabPW` also follow the `pav` line (indicating that some frames were left 'avail', after the requested 512 frames were 'got' in PA's `CallbackThreadFunc`). For a while I thought that this slow "raise" was the cause for the drop - but it isn't, as that particular capture doesn't display a drop (and it cannot either, because it doesn't use a single "wire" callback) Then, I thought that the reason for the `pav` rising slope could be, that I'm taking too much time processing in the driver callbacks; but that can't be it, because the capture above is obtained with the "snd-dummy" driver - which does pretty much nothing in its hrtimer/takslet function, but increasing the pcm_buf_pos counters (and memsetting a couple of bytes in the capture direction); I cannot really see that as a CPU hog?! Then I thought, maybe it's a rounding problem, since I should be increasing driver pointers by 705.6 bytes per timer tick, and I'm increasing for 705 bytes instead - but then, that should result with _less_ data available for playback; while `pav` rising implies that _more_ data than needed is delivered to the PortAudio callback. Then I did another test, trying to check the delta between the kernel timestamps for capture and playback driver tasklets separately; it turns out, even if the period is specified as 4000000e-9 nsecs (4 ms) - the deltas still gr avitate around 3.99x ms; I tried also calculating cumulative bytes per second (based on deltas and bytes per period) - and for different captures, they typically tended to stabilize to some +80 Bps to some +100 Bps above the required (176400 Bps). So, if the hrtimer indeed runs a bit faster, then indeed we may feed more data than needed from the driver to userspace (PA) - but then again, the slope of `pav` is at least 668 bytes for 12.6 ms, which is >> 80 Bps; so I'm still not sure where exactly does that slope come from. Then, I noticed that the original `dummy.c` driver doesn't increase its counters by a fixed amount of bytes - but instead, by what I'd call "adaptive" amount of bytes: delta to a base time is taken; and it can be used to calculate the expected (wrapped) buffer position depending on the requested rate (although `dummy.c` does this in frames, and does it in the `_pointer` callback). So I did the same in the hrtimer tasklet - and, this seemingly does very little in respect to the `pav` slope: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... which is still present, with nearly the same slope as before. Unfortunately, passing "adaptive" amount of bytes/frames around is not the solution to the drops either - because here is a capture of a "drop input" (`frabDI`), with single "wire" callback requesting 512 FRAMES_PER_BUFFER - happening at approx 60 ms, even before the first correction happens (after 0.12 sec): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… The only thing I can notice here, is that when the drop happens, `phwav` briefly "crosses" below the value of `pav` (which otherwise never happens; the same goes for cav/chwav) - but I'm not sure if this is the cause, or the effect, of the drop. Also, it can be noted that for a PA single "wire" callback, the driver's playback and capture hrtimer tasklets hit very close to each other, and the corresponding variables are also very close - at the above resolution, the trace points for both nearly overlap. Another thing I suspected was FRAMES_PER_BUFFER in the PortAudio program, so the test script switches the setting in `patest_duplex_wire.c` between 512 and 0 (which is `paFramesPerBufferUnspecified`). Note that when using 0 frames per buffer: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... and playback+record callbacks, the is no more long slope of `pav`/`phwav`, and it self-corrects more quickly; while `cav`/`chwav` stay nearly constant - however, also note the condition where `phwav` briefly "crosses" below the value of `pav`, appears here again (but no "drop input" is detected, because we're not using a single "wire" callback). However, not even FRAMES_PER_BUFFER=0 seems to help; as it doesn't prevent the "drop input" for a single "wire" callback, in the capture below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… Since I was also suspecting the debug traces from the driver for having an influence on the drop, the debug traces are disabled for the driver (x) in that capture - and obviously, this is not the sole cause of the drop either. Note that the original `dummy.c` kernel module calculates the period in nanoseconds, so it matches the pcm period size; in that case, one does not have to calculate if the current buffer position went over a period size - but can, instead, issue `snd_pcm_period_elapsed` directly at each call of the hrtimer tasklet. In this case, say for a pcm_period_size: 512 bytes, we might get a hrtimer period of 2902495 ns = 2.9 ms. This is controlled by the USE_JIFFY_PERIOD variable in the `dummy-2.6.32-patest.c` driver code, though not controlled by the `run-alsa-pa-tests.sh` - thus it has to be enabled manually; captures which USE_JIFFY_PERIOD have `_jif` as extension to the folder name, those that match to period size have `_psz` as extension. Again, even this doesn't prevent occurrence of the full-duplex "drop input"s - in all, these of the provided captures in the .tar.gz file feature drops: captures_01_psz/trace_patest__07_DA_w_0_drop.csv captures_03_psz/trace_patest__16_DF_w_512_drop.csv captures_01_psz/trace_patest__15_DF_w_0_drop.csv captures_04_jif/trace_patest__03_xA_w_0_drop.csv captures_02_jif/trace_patest__03_xA_w_0_drop.csv captures_04_jif/trace_patest__07_DA_w_0_drop.csv captures_02_jif/trace_patest__07_DA_w_0_drop.csv captures_04_jif/trace_patest__11_xF_w_0_drop.csv captures_02_jif/trace_patest__08_DA_w_512_drop.csv captures_04_jif/trace_patest__15_DF_w_0_drop.csv captures_02_jif/trace_patest__11_xF_w_0_drop.csv captures_04_jif/trace_patest__16_DF_w_512_drop.csv captures_03_psz/trace_patest__07_DA_w_0_drop.csv As the filenames indicate: * Regardless of whether the driver tunes its timer period to a jiffy (_jif) or to the period size (_psz); * Regardless of whether I use trace debug statement in the driver (D), or not (x); * Regardless of whether the driver "returns" adaptive (A) or fixed (F) amount of bytes; * Regardless of whether we use paFramesPerBufferUnspecified=0 or 512 frames per buffer in PortAudio; ... as long as there is a single stream/"wire callback" used from PortAudio, a "drop input" is liable to happen when running `patest_duplex_wire.c` - and this, even with a virtual `dummy` driver, which has no communication with real hardware at all, and pretty much does nothing: its role of "reading"/"writing" or "returning" bytes is merely simulated by increasing the stream buffer position counters! The mind boggles - especially since, the way I see it, one should do nothing else but properly increase these buffer counters from the driver, in order to have PortAudio "believe" a "proper" full-duplex transfer is occurring?!... and yet, what this "proper" rule (of increasing driver buffer counters) should be, completely evades me. Here I'd also like to note a few other observations - first, note that when scaling the driver hrtimer period to the period size (_psz), the `pav`/`phwav` became nearly constant, in comparison to the slopes still present upon FRAMES_PER_BUFFER=0 (which confuses me, since both: 705 bytes @ 4ms; and 2.9 bytes @ 2.9ms; should both be nearly as close to a rate of 44100 frames = 176400 bytes per second): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… ... but then, as the filenames above indicate, drops happen even then - although somewhat less often, and only when debug tracing in the driver is enabled. Could it be, that debug tracing directly from the driver can have such an effect on performance, so as to influence appearance of full-duplex "drop inputs" - even if precautions were taken, such as using `ftrace`s `trace_printk` (instead of the usual syslog `printk`), and piping the debug output directly to RAM (by using `/dev/shm`)? On a scale of a complete capture, I'd usually expect all cumulative pointers to essentially follow a single line; and usually when a capture goes well, that is how it appears - like on the image below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_04_jif/tr… While it may be a bit difficult to follow all variables (recreate the plot in the interactive `wxt` terminal in `gnuplot`, to be able to turn off individual function plots), they all generally follow each other in the same general slope; also note that the capture ends at about 2 seconds (as programmed in `patest_duplex_wire.c`) - but playback lingers on for half a second more. However, a full-duplex drop can seemingly happen even on a line that otherwise appears straight - like on the plot below (although the reason for that could be that the drop happens early in that capture): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... but usually, a "drop input" resets (at least) the driver's playback `hw_ptr` (and others), like on the capture below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_04_jif/tr… Note that when using playback/record PA callbacks (which cannot detect a "drop input"), may have similar resets of playback `hw_ptr`: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… ... but also the capture variables may reset: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… The above capture also shows `frgbtc` starting to deviate from `frgbtp`, when these "resets" occur - but piecewise, `frgbtc` still seems to keep slope parallel to `frgbtp` (and the rest of the cumulative position variables). However, this seems to be a case of proper XRUN, as the respective log for that capture includes "PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN" (while the full-duplex "drop input" is specifically _not_ an xrun). Note also, that sometimes I get some variables to be completely non-linear: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_01_psz/tr… ... however, note also that `captures_01_psz` was taken with an older version of the scripts, where I may have possibly failed to increase `ftrace` buffering - so I think those interruptions in the capture data are actually an artifact of a tracing problem. Otherwise, is it possible that ALSA could "pause" the playback/capture hrtimer tasklets for a while? Interestingly, when I tried using `patest_duplex_wire.c` with my onboard HDA Intel soundcard (naturally, without any kernel driver variable tracing, only the PA part) - a lot of the times it ended up producing similar non-linear (and diverging) cumulative variable traces - however, it never triggered a full-duplex "drop input". Finally, I suspect that these settings in the `dummy-2.6.32-patest.c` module, may also play a role in the behavior that results with full-duplex drops (they are otherwise kept the same as in the original `dummy` module): static struct snd_pcm_hardware dummy_pcm_hardware = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_MMAP_VALID), ... .buffer_bytes_max = MAX_BUFFER_SIZE, .period_bytes_min = 64, .period_bytes_max = MAX_PERIOD_SIZE, //(64*1024) .periods_min = USE_PERIODS_MIN, //1 .periods_max = USE_PERIODS_MAX, //1024 .fifo_size = 0, ... ... and my questions in respect to them, would be this (considering the capture data should be available through address substream->runtime->dma_area in the driver): * Given that this is a virtual driver, there is no hardware with buffers whose status (how filled they are) could generate (hardware) interrupts; instead we "raise" hrtimer functions (softirq priority) directly from the kernel module - which further schedule a tasklet (with even lower priority), and where we have the opportunity to control the repetition period of the timer functions (and thus the expected transferred bytes per period, for a given audio rate). In this context, what is the meaning of `period_bytes_min` and `periods_min`? Can they be arbitrarily set - or should one set them in relation to the expected bytes per period achieved through the timer functions? * Given that `dummy` is a virtual driver, and doesn't communicate with hardware - there is no actual DMA operation performed through it, right? * If there is no actual DMA - is there actual MMAP? In other words, does the MMAP in SNDRV_PCM_INFO_MMAP refer to: memory mapping of a hardware card DMA bus address, to substream->runtime->dma_area; or to: memory mapping of kernel-space substream->runtime->dma_area, to whatever address user-space (e.g. snd_pcm_read()) uses to access it? * If there is no actual DMA - should SNDRV_PCM_INFO_MMAP_VALID be then kept? (original `dummy` driver keeps it) What would be the meaning of SNDRV_PCM_INFO_MMAP_VALID in this context (of a virtual driver with hrtimer functions/tasklets?) * What would be the meaning of SNDRV_PCM_INFO_JOINT_DUPLEX in this context? (I've seen [http://mailman.alsa-project.org/pipermail/alsa-devel/2007-December/004801.h… "[alsa-devel] How do I use SNDRV_PCM_INFO_JOINT_DUPLEX?"], but I can't really relate it to this context) Could usage of SNDRV_PCM_INFO_JOINT_DUPLEX help avoid the PortAudio full-duplex drops? And to summarize my general questions: * Given the 'telecom' definition of full-duplex as "a point-to-point system composed of two connected parties or devices that can communicate with one another in both directions, simultaneously" (wiki), is there a stricter/more specific definition of "full-duplex": ** in terms of digital audio generally? ** specifically in PortAudio (I guess yes: "when a single callback is used for both playback and capture", but there's probably more in terms of buffer positions), and in ALSA (I guess no)? * Given that none of the approaches used in the test (debug driver traces on vs. off; driver returning fixed vs. adaptive number of frames/bytes per period; driver tuning the period to pcm_period_size vs. to a jiffy; PA using fixed vs. using unspecified amount of frames per period) have explicitly prevented the appearance of single "wire" callback (full-duplex) drops; and given that the driver is a virtual one (merely updating buffer positions, which shouldn't be a CPU hog) - what could possibly be the reason for the full-duplex drops? * Is it possible at all, to use the architecture of the `dummy` driver (hrtimer + tasklet just updating buffer positions) to code an ALSA driver, that will not generate full-duplex drops when used from PortAudio with single "wire" callback? ** If so, is there a metric/conditions in terms of ALSA driver variables, that should be followed to ensure proper full-duplex operation (under PortAudio with single callback)? * Is it possible that the driver is OK - and instead I have a problem with coding of the single "wire" callback in PortAudio? (even though most of it is copied from examples) Well, that was certainly a mouthful - but I hope at least I managed to provide a reproducible example, if not a coherent explanation of the problem... Thanks in advance for any answers/pointers, Cheers!

6 15

[alsa-devel] [PATCH] ASoC: kirkwood: add S/PDIF support
by Jean-Francois Moine 18 Oct '13

18 Oct '13

This patch adds S/PDIF input/output for mvebu DT boards. Signed-off-by: Jean-Francois Moine <moinejf(a)free.fr> --- Documentation/devicetree/bindings/sound/mvebu-audio.txt | 23 +++++ sound/soc/kirkwood/kirkwood-i2s.c | 128 ++++++++++++++++---------- sound/soc/kirkwood/kirkwood.h | 2 + 3 files changed, 102 insertions(+), 51 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt index f0062c5..c19a5d3 100644 --- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt +++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt @@ -22,6 +22,27 @@ Required properties: "internal" for the internal clock "extclk" for the external clock +Optional properties: + +- i2s-out: This is a boolean property. If present, the transmitting + function of I2S will be enabled, indicating the I2S is connected + to some IP block, such as an HDMI encoder/display-controller. + +- i2s-in: This is a boolean property. If present, the receiving + function of I2S will be enabled, indicating the I2S is connected + to some IP block, such as an HDMI encoder/display-controller. + +- spdif-out: This is a boolean property. If present, the transmitting + function of S/PDIF will be enabled, indicating there's a physical + S/PDIF out connector/jack on the board or it's connecting to some + other IP block, such as an HDMI encoder/display-controller. + +- spdif-in: This is a boolean property. If present, the receiving + function of S/PDIF will be enabled, indicating there's a physical + S/PDIF in connector/jack on the board. + +* Note: At least one of these four properties should be set in the DT binding. + Example: i2s1: audio-controller@b4000 { @@ -30,4 +51,6 @@ i2s1: audio-controller@b4000 { interrupts = <21>, <22>; clocks = <&gate_clk 13>; clock-names = "internal"; + i2s-out; + spdif-out; }; diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c index 0f3d73d..c62c7fa 100644 --- a/sound/soc/kirkwood/kirkwood-i2s.c +++ b/sound/soc/kirkwood/kirkwood-i2s.c @@ -160,9 +160,11 @@ static int kirkwood_i2s_hw_params(struct snd_pcm_substream *substream, case SNDRV_PCM_FORMAT_S16_LE: i2s_value |= KIRKWOOD_I2S_CTL_SIZE_16; ctl_play = KIRKWOOD_PLAYCTL_SIZE_16_C | - KIRKWOOD_PLAYCTL_I2S_EN; + KIRKWOOD_PLAYCTL_I2S_EN | + KIRKWOOD_PLAYCTL_SPDIF_EN; ctl_rec = KIRKWOOD_RECCTL_SIZE_16_C | - KIRKWOOD_RECCTL_I2S_EN; + KIRKWOOD_RECCTL_I2S_EN | + KIRKWOOD_RECCTL_SPDIF_EN; break; /* * doesn't work... S20_3LE != kirkwood 20bit format ? @@ -178,9 +180,11 @@ static int kirkwood_i2s_hw_params(struct snd_pcm_substream *substream, case SNDRV_PCM_FORMAT_S24_LE: i2s_value |= KIRKWOOD_I2S_CTL_SIZE_24; ctl_play = KIRKWOOD_PLAYCTL_SIZE_24 | - KIRKWOOD_PLAYCTL_I2S_EN; + KIRKWOOD_PLAYCTL_I2S_EN | + KIRKWOOD_PLAYCTL_SPDIF_EN; ctl_rec = KIRKWOOD_RECCTL_SIZE_24 | - KIRKWOOD_RECCTL_I2S_EN; + KIRKWOOD_RECCTL_I2S_EN | + KIRKWOOD_PLAYCTL_I2S_EN; break; case SNDRV_PCM_FORMAT_S32_LE: i2s_value |= KIRKWOOD_I2S_CTL_SIZE_32; @@ -253,12 +257,14 @@ static int kirkwood_i2s_play_trigger(struct snd_pcm_substream *substream, writel(value, priv->io + KIRKWOOD_INT_MASK); /* enable playback */ + ctl &= priv->ctl_play_mask; writel(ctl, priv->io + KIRKWOOD_PLAYCTL); break; case SNDRV_PCM_TRIGGER_STOP: /* stop audio, disable interrupts */ - ctl |= KIRKWOOD_PLAYCTL_PAUSE | KIRKWOOD_PLAYCTL_I2S_MUTE; + ctl |= KIRKWOOD_PLAYCTL_PAUSE | KIRKWOOD_PLAYCTL_I2S_MUTE | + KIRKWOOD_PLAYCTL_SPDIF_MUTE; writel(ctl, priv->io + KIRKWOOD_PLAYCTL); value = readl(priv->io + KIRKWOOD_INT_MASK); @@ -272,13 +278,15 @@ static int kirkwood_i2s_play_trigger(struct snd_pcm_substream *substream, case SNDRV_PCM_TRIGGER_PAUSE_PUSH: case SNDRV_PCM_TRIGGER_SUSPEND: - ctl |= KIRKWOOD_PLAYCTL_PAUSE | KIRKWOOD_PLAYCTL_I2S_MUTE; + ctl |= KIRKWOOD_PLAYCTL_PAUSE | KIRKWOOD_PLAYCTL_I2S_MUTE | + KIRKWOOD_PLAYCTL_SPDIF_MUTE; writel(ctl, priv->io + KIRKWOOD_PLAYCTL); break; case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - ctl &= ~(KIRKWOOD_PLAYCTL_PAUSE | KIRKWOOD_PLAYCTL_I2S_MUTE); + ctl &= ~(KIRKWOOD_PLAYCTL_PAUSE | KIRKWOOD_PLAYCTL_I2S_MUTE | + KIRKWOOD_PLAYCTL_SPDIF_MUTE); writel(ctl, priv->io + KIRKWOOD_PLAYCTL); break; @@ -301,7 +309,8 @@ static int kirkwood_i2s_rec_trigger(struct snd_pcm_substream *substream, case SNDRV_PCM_TRIGGER_START: /* configure */ ctl = priv->ctl_rec; - value = ctl & ~KIRKWOOD_RECCTL_I2S_EN; + value = ctl & ~(KIRKWOOD_RECCTL_I2S_EN | + KIRKWOOD_RECCTL_SPDIF_EN); writel(value, priv->io + KIRKWOOD_RECCTL); /* enable interrupts */ @@ -310,6 +319,7 @@ static int kirkwood_i2s_rec_trigger(struct snd_pcm_substream *substream, writel(value, priv->io + KIRKWOOD_INT_MASK); /* enable record */ + ctl &= priv->ctl_rec_mask; writel(ctl, priv->io + KIRKWOOD_RECCTL); break; @@ -404,55 +414,75 @@ static const struct snd_soc_dai_ops kirkwood_i2s_dai_ops = { .set_fmt = kirkwood_i2s_set_fmt, }; +static const struct snd_soc_component_driver kirkwood_i2s_component = { + .name = DRV_NAME, +}; -static struct snd_soc_dai_driver kirkwood_i2s_dai = { - .probe = kirkwood_i2s_probe, - .playback = { - .channels_min = 1, - .channels_max = 2, - .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | - SNDRV_PCM_RATE_96000, - .formats = KIRKWOOD_I2S_FORMATS, - }, - .capture = { +static int kirkwood_register_component(struct device *dev, + struct kirkwood_dma_data *priv) +{ + struct device_node *np = dev->of_node; + uint32_t ctl_play_mask = ~(KIRKWOOD_PLAYCTL_I2S_EN | + KIRKWOOD_PLAYCTL_SPDIF_EN); + uint32_t ctl_rec_mask = ~(KIRKWOOD_RECCTL_I2S_EN | + KIRKWOOD_RECCTL_SPDIF_EN); + int ret; + + static const struct snd_soc_pcm_stream stream = { .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_96000, .formats = KIRKWOOD_I2S_FORMATS, - }, - .ops = &kirkwood_i2s_dai_ops, -}; + }; -static struct snd_soc_dai_driver kirkwood_i2s_dai_extclk = { - .probe = kirkwood_i2s_probe, - .playback = { - .channels_min = 1, - .channels_max = 2, - .rates = SNDRV_PCM_RATE_8000_192000 | - SNDRV_PCM_RATE_CONTINUOUS | - SNDRV_PCM_RATE_KNOT, - .formats = KIRKWOOD_I2S_FORMATS, - }, - .capture = { - .channels_min = 1, - .channels_max = 2, - .rates = SNDRV_PCM_RATE_8000_192000 | - SNDRV_PCM_RATE_CONTINUOUS | - SNDRV_PCM_RATE_KNOT, - .formats = KIRKWOOD_I2S_FORMATS, - }, - .ops = &kirkwood_i2s_dai_ops, -}; + if (np) { + if (of_property_read_bool(np, "i2s-in")) + ctl_rec_mask |= KIRKWOOD_RECCTL_I2S_EN; + if (of_property_read_bool(np, "i2s-out")) + ctl_play_mask |= KIRKWOOD_PLAYCTL_I2S_EN; + if (of_property_read_bool(np, "spdif-in")) + ctl_rec_mask |= KIRKWOOD_RECCTL_SPDIF_EN; + if (of_property_read_bool(np, "spdif-out")) + ctl_play_mask |= KIRKWOOD_PLAYCTL_SPDIF_EN; + } else { + ctl_rec_mask |= KIRKWOOD_RECCTL_I2S_EN; + ctl_play_mask |= KIRKWOOD_PLAYCTL_I2S_EN; + } + priv->ctl_play_mask = ctl_play_mask; + priv->ctl_rec_mask = ctl_rec_mask; + + priv->soc_dai.probe = kirkwood_i2s_probe; + priv->soc_dai.ops = &kirkwood_i2s_dai_ops; + if (ctl_play_mask & (KIRKWOOD_PLAYCTL_I2S_EN | + KIRKWOOD_PLAYCTL_SPDIF_EN)) { + memcpy(&priv->soc_dai.playback, &stream, + sizeof priv->soc_dai.playback); + if (!IS_ERR(priv->extclk)) + priv->soc_dai.playback.rates = SNDRV_PCM_RATE_8000_192000 | + SNDRV_PCM_RATE_CONTINUOUS | + SNDRV_PCM_RATE_KNOT; + } + if (ctl_rec_mask & (KIRKWOOD_RECCTL_I2S_EN | + KIRKWOOD_RECCTL_SPDIF_EN)) { + memcpy(&priv->soc_dai.capture, &stream, + sizeof priv->soc_dai.capture); + if (!IS_ERR(priv->extclk)) + priv->soc_dai.capture.rates = SNDRV_PCM_RATE_8000_192000 | + SNDRV_PCM_RATE_CONTINUOUS | + SNDRV_PCM_RATE_KNOT; + } -static const struct snd_soc_component_driver kirkwood_i2s_component = { - .name = DRV_NAME, -}; + ret = snd_soc_register_component(dev, &kirkwood_i2s_component, + &priv->soc_dai, 1); + if (ret) + dev_err(dev, "snd_soc_register_component failed\n"); + return ret; +} static int kirkwood_i2s_dev_probe(struct platform_device *pdev) { struct kirkwood_asoc_platform_data *data = pdev->dev.platform_data; - struct snd_soc_dai_driver *soc_dai = &kirkwood_i2s_dai; struct kirkwood_dma_data *priv; struct resource *mem; struct device_node *np = pdev->dev.of_node; @@ -503,7 +533,6 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev) } else { dev_info(&pdev->dev, "found external clock\n"); clk_prepare_enable(priv->extclk); - soc_dai = &kirkwood_i2s_dai_extclk; } } @@ -520,12 +549,9 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev) priv->ctl_rec |= KIRKWOOD_RECCTL_BURST_128; } - err = snd_soc_register_component(&pdev->dev, &kirkwood_i2s_component, - soc_dai, 1); - if (err) { - dev_err(&pdev->dev, "snd_soc_register_component failed\n"); + err = kirkwood_register_component(&pdev->dev, priv); + if (err) goto err_component; - } err = snd_soc_register_platform(&pdev->dev, &kirkwood_soc_platform); if (err) { diff --git a/sound/soc/kirkwood/kirkwood.h b/sound/soc/kirkwood/kirkwood.h index f8e1ccc..8f11e03 100644 --- a/sound/soc/kirkwood/kirkwood.h +++ b/sound/soc/kirkwood/kirkwood.h @@ -134,6 +134,8 @@ struct kirkwood_dma_data { struct clk *extclk; uint32_t ctl_play; uint32_t ctl_rec; + uint32_t ctl_play_mask, ctl_rec_mask; + struct snd_soc_dai_driver soc_dai; struct snd_pcm_substream *substream_play; struct snd_pcm_substream *substream_rec; int irq; -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/

3 11

[alsa-devel] [PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
by Lars-Peter Clausen 17 Oct '13

17 Oct '13

Hi, This series removes the redundant driver field from the i2c_client struct. The field is redundant since the same pointer can be accessed through to_i2c_driver(client->dev.driver). The commit log suggests that the field has been around since forever (since before v2.6.12-rc2) and it looks as if it was simply forgotten to remove it during the conversion of the i2c framework to the generic device driver model. Nevertheless there are a still a few users of the field around. This series first updates all users to use an alternative method of accessing the same data and then the last patch removes the driver field from the i2c_client struct. Note that due to this changes on most architectures neither the code size nor the type of generated instructions will change. This is due to the fact that we aren't really interested in the pointer value itself, but rather want to dereference it to access one of the fields of the struct. offset_of() (and hence to_i2c_driver) works by subtracting a offset from the pointer, so the compiler can internally create the sum of these two offsets and use that to access the field. E.g. on ARM the expression client->driver->command(...) generates ... ldr r3, [r0, #28] ldr r3, [r3, #32] blx r3 ... and the expression to_i2c_driver(client->dev.driver)->command(...) generates ... ldr r3, [r0, #160] ldr r3, [r3, #-4] blx r3 ... Other architectures will generate similar code. The most common pattern is to use the i2c_driver to get to the device_driver struct embedded in it. The same struct can easily be accessed through the device struct embedded in the i2c_client struct. E.g. client->driver->driver.field can be replaced by client->dev.driver->field. Here again the generated code is almost identical and only the offsets differ. E.g. on ARM the expression 'client->driver->driver.owner' generates ldr r3, [r0, #28] ldr r0, [r3, #44] and 'client->dev.driver->owner' generates ldr r3, [r0, #160] ldr r0, [r3, #8] The kernel overall code size is slightly reduced since the code that manages the driver field is removed and of course also the runtime memory footprint of the i2c_client struct is reduced. - Lars Lars-Peter Clausen (8): [media] s5c73m3: Don't use i2c_client->driver [media] exynos4-is: Don't use i2c_client->driver [media] core: Don't use i2c_client->driver drm: encoder_slave: Don't use i2c_client->driver drm: nouveau: Don't use i2c_client->driver ALSA: ppc: keywest: Don't use i2c_client->driver ASoC: imx-wm8962: Don't use i2c_client->driver i2c: Remove redundant 'driver' field from the i2c_client struct drivers/gpu/drm/drm_encoder_slave.c | 8 ++++---- drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 3 ++- drivers/i2c/i2c-core.c | 21 ++++++++++++--------- drivers/i2c/i2c-smbus.c | 10 ++++++---- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/platform/exynos4-is/media-dev.c | 6 +++--- drivers/media/v4l2-core/tuner-core.c | 6 +++--- drivers/media/v4l2-core/v4l2-common.c | 10 +++++----- include/linux/i2c.h | 2 -- include/media/v4l2-common.h | 2 +- sound/ppc/keywest.c | 4 ++-- sound/soc/fsl/imx-wm8962.c | 2 +- 12 files changed, 40 insertions(+), 36 deletions(-) -- 1.8.0

7 17

[alsa-devel] [PATCH 1/5] ARM: Kconfig: Move if ARCH_S3C64XX statement to mach-s3c64xx/Kconfig
by Tomasz Figa 11 Oct '13

11 Oct '13

All other platforms have this condition checked inside their own Kconfig files, so for consistency this patch makes it this way for mach-s3c64xx as well. Signed-off-by: Tomasz Figa <tomasz.figa(a)gmail.com> --- arch/arm/Kconfig | 2 -- arch/arm/mach-s3c64xx/Kconfig | 4 ++++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b766dad..dc51f8a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -995,9 +995,7 @@ source "arch/arm/mach-sti/Kconfig" source "arch/arm/mach-s3c24xx/Kconfig" -if ARCH_S3C64XX source "arch/arm/mach-s3c64xx/Kconfig" -endif source "arch/arm/mach-s5p64x0/Kconfig" diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index bd14e3a..0e23910 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -3,6 +3,8 @@ # # Licensed under GPLv2 +if ARCH_S3C64XX + # temporary until we can eliminate all drivers using it. config PLAT_S3C64XX bool @@ -322,3 +324,5 @@ config MACH_S3C64XX_DT board. Note: This is under development and not all peripherals can be supported with this machine file. + +endif -- 1.8.3.2

5 9

[alsa-devel] Internal Mic Boost channel is unused
by Nathanael D. Noblet 10 Oct '13

10 Oct '13

Hello, I have an issue I'd like to help completely solve. Unfortunately I only have a tenuous grasp of what is actually going on so some of this could be wrong/include errors. Here's what I know. 1) I have the following hardware (alsa-info attached). 2) The internal microphone requires that the mic boost channel be something other than 0 to function properly. 3) Changing what pulseaudio expects things to be labelled causes the problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf). From the discussion with David Henningsson (diwic on IRC). It seems that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics. I'd love to be able to help any way I can to get these fixed once and for all. Let me know if you need more information or what not. -- Nathanael d. Noblet t 403.875.4613

3 13

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Alsa-devel September 2013