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

[alsa-devel] ALSA vs. non coherent DMA
by Benjamin Herrenschmidt 08 May '08

08 May '08

Hi Takashi ! I'm bringing up an old thread as I'm just discovering that the problem still hasn't been fixed. There seem to be a few issues with ALSA current usage of mmap vs. non cache coherent architecture, such as embedded PowerPC's. I can see at least two with a quick look to pcm-native.c, one I don't understand and one I think I do: - The control/status mapping. Can you elaborate a bit on what this is actually doing and why it shouldn't be done on "non coherent" architectures ? Currently this -is- done on all powerpc's, whether they are coherent or not and I want to understand what the underlying issue is. - The mmap of DMA pages. Here, the problem appears two fold: * Use of virt_to_page() on virtual addresses returned by dma_alloc_coherent(). * No using the appropriate page protection for a DMA coherent mapping to userspace. It seems like you have solved that in part with implementing a generic dma_mmap_coherent() in the past that for some reason you never merged upstream (I can track that to about 2 years ago). Is there a reason ? I think we need to at least apply a band-aid today as it's becoming a nasty issue for several non-coherent powerpc platforms. It could be in the form of implementing dma_mmap_coherent() and changing Alsa to use it with the appropriate ifdef, or just adding an ifdef CONFIG_PPC with the right code in there for now until a better solution is found. It should be trivial though. Getting the PFN from the DMA address is easy if we have the dma handle and the virtual address, though that -is- definitely platform specific. I can implement a function for that if you need. As for the pgprot, we can come up with something like pgprot_mmap_dma(). Either that or I can fold it all in a powerpc wide implementation of a dma_mmap_coherent() like we envisioned initially. Let me know what approach is preferred here and I'll come up with patches ASAP. As far as I'm concerned, this is a bug and thus must be fixed now for .26 and possibly backported to stable even if we can come up with a non invasive solution). I'm annoyed because it represents a trivial amount of code, this problem should have been fixed a long time ago. Cheers, Ben.

4 5

[alsa-devel] [PATCH] snd_usb_caiaq: add support for "Session I/O" interface
by Daniel Mack 08 May '08

08 May '08

Hi, this patch adds support for "Session I/O". As it certainly won't break anything it could still go for 2.6.26, right? Thanks, Daniel

2 2

[alsa-devel] [PATCH 1/2] soc - at91-pcm - Fix line wrapping
by Mark Brown 08 May '08

08 May '08

There's more checkpatch stuff to fix in the driver, this just fixes the minimum required for the following patch to be clean. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/at91/at91-pcm.c | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/sound/soc/at91/at91-pcm.c b/sound/soc/at91/at91-pcm.c index 67c88e3..e36533d 100644 --- a/sound/soc/at91/at91-pcm.c +++ b/sound/soc/at91/at91-pcm.c @@ -103,7 +103,8 @@ static void at91_pcm_dma_irq(u32 ssc_sr, if (prtd->period_ptr >= prtd->dma_buffer_end) { prtd->period_ptr = prtd->dma_buffer; } - at91_ssc_write(params->ssc_base + params->pdc->xnpr, prtd->period_ptr); + at91_ssc_write(params->ssc_base + params->pdc->xnpr, + prtd->period_ptr); at91_ssc_write(params->ssc_base + params->pdc->xncr, prtd->period_size / params->pdc_xfer_size); } @@ -191,10 +192,12 @@ static int at91_pcm_trigger(struct snd_pcm_substream *substream, at91_ssc_write(params->ssc_base + AT91_SSC_IER, params->mask->ssc_endx | params->mask->ssc_endbuf); - at91_ssc_write(params->ssc_base + ATMEL_PDC_PTCR, params->mask->pdc_enable); + at91_ssc_write(params->ssc_base + ATMEL_PDC_PTCR, + params->mask->pdc_enable); - DBG("sr=%lx imr=%lx\n", at91_ssc_read(params->ssc_base + AT91_SSC_SR), - at91_ssc_read(params->ssc_base + AT91_SSC_IER)); + DBG("sr=%lx imr=%lx\n", + at91_ssc_read(params->ssc_base + AT91_SSC_SR), + at91_ssc_read(params->ssc_base + AT91_SSC_IER)); break; case SNDRV_PCM_TRIGGER_STOP: -- 1.5.5.1

2 2

[alsa-devel] SoC sound support for imx27
by Juergen Beisert 08 May '08

08 May '08

Hi, I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)? Regards Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9

5 16

[alsa-devel] [PATCH] soc at91 minor bug fixes
by Patrik Sevallius 08 May '08

08 May '08

Found these two bugs while browsing through the code. The first one is a cut-n-paste bug, instead of disabling the clock when request_irq() fails, it enabled it once more. The second one fixes a debug printout, AT91_SSC_IER is write only, AT91_SSC_IMR is readable (the printed string actually says imr). Frank Mandarino was busy so he asked me to send these to this list. /Patrik Signed-off-by: Patrik Sevallius <patrik.sevallius(a)enea.com> Signed-off-by: Frank Mandarino <fmandarino(a)endrelia.com> ================================================================================ --- sound/soc/at91/at91-ssc.c.orig 2008-05-07 09:33:49.000000000 +0200 +++ sound/soc/at91/at91-ssc.c 2008-05-07 09:34:18.000000000 +0200 @@ -590,7 +590,7 @@ printk(KERN_WARNING "at91-ssc: request_irq failure\n"); DBG("Stopping pid %d clock\n", ssc_p->ssc.pid); - at91_sys_write(AT91_PMC_PCER, 1<<ssc_p->ssc.pid); + at91_sys_write(AT91_PMC_PCDR, 1<<ssc_p->ssc.pid); return ret; } --- sound/soc/at91/at91-pcm.c.orig 2008-05-07 13:23:12.000000000 +0200 +++ sound/soc/at91/at91-pcm.c 2008-05-07 13:26:40.000000000 +0200 @@ -194,7 +194,7 @@ at91_ssc_write(params->ssc_base + ATMEL_PDC_PTCR, params->mask->pdc_enable); DBG("sr=%lx imr=%lx\n", at91_ssc_read(params->ssc_base + AT91_SSC_SR), - at91_ssc_read(params->ssc_base + AT91_SSC_IER)); + at91_ssc_read(params->ssc_base + AT91_SSC_IMR)); break; case SNDRV_PCM_TRIGGER_STOP:

2 1

Re: [alsa-devel] [pulseaudio-discuss] alsa pulse bugs
by Lennart Poettering 06 May '08

06 May '08

On Mon, 05.05.08 09:58, Colin Guthrie (gmane(a)colin.guthr.ie) wrote: > > tom(a)dbservice.com wrote: > > I reported three bugs to the alsa bugtracker: > > > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942 > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943 > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944 > > > > It's three bugs after all. Once these are fixed I expect Wine to work. > > *fingers crossed* > > Ace Tom :) > > I've cross posted this to the alsa devel list. Hopefully Takashi (who's > committed some pulse-related stuff recently) will have some insight here. > > Re the snd_pcm_delay() including network latency (#3945), this clearly > makes sense for network streams. Does you proposed fix include this > delay (albeit with the improvement that it also will drop to 0 if there > are no samples queued)? > > Also re #3942, I believe (but not sure) that the max buffer in the > glitch free branch has been increased significantly (as it now needs to > keep some degree of past sound as well as future buffer to allow the > rewinds to work properly (this is no doubt an inaccurate description of > why it's needed.... :p)) I'm not sure how this would affect this > solution, but Lennart will be able to advise better. Yes, with glitch-free maxlength becomes mostly irrelevant. It should default to "0" know, to let the server decide. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

1 0

[alsa-devel] Auzentech and Creative X-FI
by Sebastian Schneider 06 May '08

06 May '08

Hi, I was wondering if the X-FI drivers will be working with the X-FI from Auzentech or just with the cards from Creative. Is there something known about this? And how far is the development? Is somewhere a cvs/svn/git system where to get the live files? Thanks in advance. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

2 1

[alsa-devel] [RFC] virtual master control for HD-audio
by Takashi Iwai 06 May '08

06 May '08

Hi, another thing I'd like to push into the next kernel is the virtual master volume control. As I posted in earlier posts, it adds virtual controls that have several slave controls with the same types, e.g. Front, Surround, Center, LFE, etc. Then these are adjusted simultaneously via the master control. It'd be appreciated if some one can test the patches with HD-audio h/w that has no master control yet (e.g. some STAC codecs). Note that this won't add the master volumes if there are no real volume controls. Some codecs have really no volume control, and this won't help for such devices. Two (and one for driver) patches will follow after this. Takashi

5 27

[alsa-devel] Where can I find ALSA driver for smdk2410-UDA1341?
by yushilin 06 May '08

06 May '08

Any one knows? Thanks！

3 2

[alsa-devel] [PATCH 1/3] soc - S3C2410 pcm - Update for changed s3c2410 DMA API change
by Mark Brown 05 May '08

05 May '08

From: ing. Davide Rizzo <davide(a)elpa.it> S3C2410 pcm doesn't work. s3c2410_dma_request() now returns the channel number and not 0 if OK. Davide This patch to update to a s3c2410_dma_request return value change Signed-off-by: Davide Rizzo <davide(a)elpa.it> Acked-by: Liam Girdwood <lg(a)opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/s3c24xx/s3c24xx-pcm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/s3c24xx/s3c24xx-pcm.c b/sound/soc/s3c24xx/s3c24xx-pcm.c index 6c70a81..7806ae6 100644 --- a/sound/soc/s3c24xx/s3c24xx-pcm.c +++ b/sound/soc/s3c24xx/s3c24xx-pcm.c @@ -171,7 +171,7 @@ static int s3c24xx_pcm_hw_params(struct snd_pcm_substream *substream, ret = s3c2410_dma_request(prtd->params->channel, prtd->params->client, NULL); - if (ret) { + if (ret < 0) { DBG(KERN_ERR "failed to get dma channel\n"); return ret; } -- 1.5.5.1

2 3