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

[alsa-devel] hda-intel and runtime power-management
by Tatulea, Dragos 28 Jul '11

28 Jul '11

Hi, I'm in the process of enabling pm runtime pm for the hda_intel driver, not being sure if this is a sane task :). Noticed that CONFIG_SND_HDA_POWER_SAVE disables codecs and chip when they are not in use, but the power gain is not noticeable on my hw. On the other hand, a full suspend (azx_suspend) does save a few hundred mW's. I am aware that this is hw specific, but I would like to take advantage of the full suspend. Suspend/resume latency is below jiffy resolution. How about a more aggressive scheme?: allow runtime power management (with azx_suspend/resume as runtime pm ops) to kick in when all streams are stopped/suspended/paused. And resume upon stream is start/resume. I don't have enough context into ALSA & sound drivers so I need a reality check: is this crazy/stupid? Thanks, Dragos

2 1

[alsa-devel] [PATCH 5/6] sound/core/pcm_compat.c: adjust array index
by Julia Lawall 28 Jul '11

28 Jul '11

From: Julia Lawall <julia(a)diku.dk> Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // </smpl> Signed-off-by: Julia Lawall <julia(a)diku.dk> --- Not tested. sound/core/pcm_compat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -u -p a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c --- a/sound/core/pcm_compat.c +++ b/sound/core/pcm_compat.c @@ -342,7 +342,7 @@ static int snd_pcm_ioctl_xfern_compat(st kfree(bufs); return -EFAULT; } - bufs[ch] = compat_ptr(ptr); + bufs[i] = compat_ptr(ptr); bufptr++; } if (dir == SNDRV_PCM_STREAM_PLAYBACK)

2 1

Re: [alsa-devel] Realtek ALC889: HDA Intel and kernel 3.0 gives choppy sound
by Takashi Iwai 28 Jul '11

28 Jul '11

At Tue, 26 Jul 2011 23:14:47 +0200, Colomban Wendling wrote: > > Hi, > > Following a bug report started in Debian BTS, in bug 635362 [1], I was > asked to post here after testing upstream kernels and reproducing the bug. > > So, here's the problem: my HDA audio chip [2] started to output very > choppy sound with Linux kernel 3.0, while it worked perfectly well in > previous versions -- latest two I used being 2.6.38 and 2.6.39 from > Debian. Please note that simply booting on 2.6.39 works as usual, so > it's IMHO definitely a driver regression. Do you have 2.6.39 kernel messages? I see the warnings in your dmesg below in 3.0* kernels. Did you get it with the working kernel as well? > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: at drivers/pci/dmar.c:634 warn_invalid_dmar+0x77/0x85() > [ 0.000000] Hardware name: MS-7636 > [ 0.000000] Your BIOS is broken; DMAR reported at address fed93000 returns all ones! > [ 0.000000] BIOS vendor: American Megatrends Inc.; Ver: V1.1; Product Version: 1.0 > [ 0.000000] Modules linked in: > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.0.0 #4 > [ 0.000000] Call Trace: > [ 0.000000] [<ffffffff81043359>] ? warn_slowpath_common+0x78/0x8c > [ 0.000000] [<ffffffff810433bb>] ? warn_slowpath_fmt_taint+0x3d/0x42 > [ 0.000000] [<ffffffff81318a7e>] ? __pte+0x7/0x8 > [ 0.000000] [<ffffffff816b2a2d>] ? __early_set_fixmap+0x89/0x8d > [ 0.000000] [<ffffffff81318a7e>] ? __pte+0x7/0x8 > [ 0.000000] [<ffffffff816b2a2d>] ? __early_set_fixmap+0x89/0x8d > [ 0.000000] [<ffffffff81318a7e>] ? __pte+0x7/0x8 > [ 0.000000] [<ffffffff811b72c9>] ? warn_invalid_dmar+0x77/0x85 > [ 0.000000] [<ffffffff816b2e3a>] ? early_iounmap+0xc5/0x114 > [ 0.000000] [<ffffffff816c6f13>] ? check_zero_address+0xb0/0xeb > [ 0.000000] [<ffffffff81327736>] ? bad_to_user+0x620/0x620 > [ 0.000000] [<ffffffff816c6f5f>] ? detect_intel_iommu+0x11/0xa6 > [ 0.000000] [<ffffffff816a5b29>] ? pci_iommu_alloc+0x3f/0x67 > [ 0.000000] [<ffffffff816b280c>] ? mem_init+0x14/0xe5 > [ 0.000000] [<ffffffff8169f94e>] ? start_kernel+0x1d0/0x3c8 > [ 0.000000] [<ffffffff8169f140>] ? early_idt_handlers+0x140/0x140 > [ 0.000000] [<ffffffff8169f3c4>] ? x86_64_start_kernel+0x104/0x111 > [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- Also, you can replace the files in sound/pci/hda/* from 2.6.39 kernel tree. If this fixes the problem, it's a sound driver bug. If not, it's anything else, e.g. the problem in more core side, e.g. IOMMU like above or the timer change, etc. Takashi

2 8

[alsa-devel] [PATCH v5 0/4] ASoC: mxs: add audio support
by Dong Aisheng 28 Jul '11

28 Jul '11

According to Liam's comment, i redo the patch set based on the for-next branch on Mark's sound-2.6 tree. The based one is [PATCH v4 00/10] ARM: mxs: add audio support. For asoc part (1-4), only one change is updating mxs_pcm_new since this API has been updated to pass in the runtime data only For mxs part, no changes made. This patch series is to add audio support based on saif for mxs platform. The driver only supports playback currently. For capturing, due to hardware limitation that we have to use two saif instances to implement full duplex (playback & recording), we need to figure out a good design to fit in ASoC as the following work. In addition, we simply just support master mode since saif tx can only work as a master due to hw limitation(rx can work in both master & slave mode). Tested on MX28EVK. For the ASoC-patches (1-4): Tested-by: Wolfram Sang <w.sang(a)pengutronix.de> For the mach-mxs-Patches (5-10): Reviewed-by: Wolfram Sang <w.sang(a)pengutronix.de> Changes since v4: * ASoC: mxs: add mxs-pcm driver update mxs_pcm_new due to this API's parameter number is changed. Changes since v3: This version only has one patch changed with another two for rebase the changed one. * [PATCH v4 06/10] ARM: mxs: add saif device Drop DIGCTRL-handling based on Wolfram's comment * [PATCH v4 07/10] ARM: mxs: add sgtl5000 i2c device Resend for rebase [PATCH v4 06/10] ARM: mxs: add saif device * [PATCH v4 08/10] ARM: mxs: add mxs-sgtl5000 device Resend for rebase [PATCH v4 06/10] ARM: mxs: add saif device changes since v2: * mxs-pcm - fix wrong periods_max. - For robustness replace the channels_min check with a check for the relevant substream being present * mxs-saif - Add IRQ_NONE handle - improve mxs_saif_set_clk to make it more easy to read - correct return value - request_irq sequence changed to after ioremap * mxs-sgtl5000 - clean up a few unused code * Kconfig&Makefile - SND_SOC_MXS_SGTL5000 should depend on I2C in Kconfig * mxs - Select MXS_I2C in kconfig for mxs-sgtl5000 changes since v1: * export saif mclk control interface to machine driver. Machine driver can decide whether it needs to use mclk supplied by saif according to its requirement. * error checking improvement * remove a few unneccesary code Dong Aisheng (4): ASoC: mxs: add mxs-pcm driver ASoC: mxs: add mxs-saif driver ASoC: mxs: add mxs-sgtl5000 machine driver ASoC: mxs: add asoc configuration files sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/mxs/Kconfig | 20 ++ sound/soc/mxs/Makefile | 10 + sound/soc/mxs/mxs-pcm.c | 359 ++++++++++++++++++++++ sound/soc/mxs/mxs-pcm.h | 43 +++ sound/soc/mxs/mxs-saif.c | 677 ++++++++++++++++++++++++++++++++++++++++++ sound/soc/mxs/mxs-saif.h | 130 ++++++++ sound/soc/mxs/mxs-sgtl5000.c | 165 ++++++++++ 9 files changed, 1406 insertions(+), 0 deletions(-) create mode 100644 sound/soc/mxs/Kconfig create mode 100644 sound/soc/mxs/Makefile create mode 100644 sound/soc/mxs/mxs-pcm.c create mode 100644 sound/soc/mxs/mxs-pcm.h create mode 100644 sound/soc/mxs/mxs-saif.c create mode 100644 sound/soc/mxs/mxs-saif.h create mode 100644 sound/soc/mxs/mxs-sgtl5000.c

5 12

[alsa-devel] [RME - hdsp] alsa-lib's hdsp.h out of sync
by Adrian Knoth 28 Jul '11

28 Jul '11

Hi! While hacking on RPM support for hdspmixer, I've noticed that alsa-lib's hdsp.h doesn't reflect the kernel's hdsp.h: RPM is missing in HDSP_IO_Type. AFAIK, somebody has to regenerate alsa-lib's hdsp.h, right? Please do so. ;) Cheers

2 3

Re: [alsa-devel] [patch] ALSA: asihpi - off by one in asihpi_hpi_ioctl()
by Eliot Blennerhassett 27 Jul '11

27 Jul '11

On 28/07/11 00:55, Dan Rosenberg wrote: > On Wed, 2011-07-27 at 15:02 +0300, Dan Carpenter wrote: >> "adapter" is used as an array index in the adapters[] array so >> the off by one would make us read past the end. >> > > Agreed. I also don't like the fact that the "pa" pointer can be set to > an arbitrary address because the index isn't checked until after its > assignment. Even though the fix to the check prevents this pointer from > being dereferenced if it's out-of-bounds, it's still wrong. :( I have to agree. I'll submit another patch that avoids doing this. > I agree. This code seems to make assumptions in more than one place > that the adapters array is fully populated with non-NULL elements. At a > glance, I can't see where such initialization occurs though. It does, in void __init asihpi_init(void) ... memset(adapters, 0, sizeof(adapters)); -- Eliot Blennerhassett AudioScience Inc.

1 0

[alsa-devel] [PATCH V2 0/3] ASoC: au1x: update PSC AC97/I2S code
by Manuel Lauss 27 Jul '11

27 Jul '11

The following two patches depend on patchset "ASoC for Alchemy Au1000/1500/1100" to apply and work. Patch #1 moves the DBDMA (PCM) device registration from the AC97/I2S drivers into the board code. Patch #2 changes use of "soc-audio" platform device int db1200 machine code to the new way. Patch #3 removes the use of custom PCM_TX/RX constants in favour of the established SNDRV_PCM_SUBTREAM_PLAYBACK/CAPTURE. Changes since V1: - added patch #3 - tidied patch #1 a bit more. Run-tested on DB1200, DB1300 and DB1550 boards. Manuel Lauss (3): ASoC: au1x: remove automatic DMA device registration from PSC drivers ASoC: au1x: update db1200 machine to the new way of things ASoC: au1x: use substream stream info directly arch/mips/alchemy/devboards/db1200/platform.c | 16 +++++ sound/soc/au1x/db1200.c | 64 ++++++++++++------ sound/soc/au1x/dbdma2.c | 91 +++++-------------------- sound/soc/au1x/psc-ac97.c | 48 +++++++++----- sound/soc/au1x/psc-i2s.c | 42 +++++++---- sound/soc/au1x/psc.h | 11 --- 6 files changed, 133 insertions(+), 139 deletions(-) -- 1.7.6 -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

4 7

[alsa-devel] [PATCH V5 0/3] ASoC for Alchemy Au1000/1500/1100
by Manuel Lauss 27 Jul '11

27 Jul '11

Hello, Here's V5 of the AC97/I2S ASoC patchset for early Alchemy chips and their respective evaluation boards. The patches are largely based on the old mips/au1x00.c driver which they replace. AC97 Tested on a Db1500 development board; I2S untested since none of the testboards I have actually have an I2S codec (just testpoints). Changes since V4: - incorporate feedback from Liam Girdwood. - rediff against latest ASoC changes Changes since V3: - dropped the hunk which removed the I2S constants from the au1000.h header to avoid merge conflicts with other patches. - use the context structure declared in psc.h. Follow-up patches for psc* code depend on this. Changes since V2: - implemented changes after feedback from Lars-Peter Clausen: * split patch 1 in two, one for the ASoC drivers, and a separate for DB1000 machine code. * get rid of automatic dma device registration * tidied the I2S/AC97 sources - mark sound/mips/au1x00.c as DEPRECATED instead of removing it outright. Changes since V1: - added untested I2S controller driver for completeness, removed the audio defines from the au1000 header. Manuel Lauss (3): ASoC: Alchemy AC97C/I2SC audio support ASoC: Add a DB1x00 AC97 machine driver ALSA: deprecate MIPS AU1X00 AC97 driver arch/mips/alchemy/devboards/db1x00/platform.c | 48 ++++ sound/mips/Kconfig | 5 +- sound/soc/au1x/Kconfig | 28 ++ sound/soc/au1x/Makefile | 10 + sound/soc/au1x/ac97c.c | 365 ++++++++++++++++++++++++ sound/soc/au1x/db1000.c | 75 +++++ sound/soc/au1x/dma.c | 377 +++++++++++++++++++++++++ sound/soc/au1x/i2sc.c | 347 +++++++++++++++++++++++ sound/soc/au1x/psc.h | 19 +- 9 files changed, 1264 insertions(+), 10 deletions(-) create mode 100644 sound/soc/au1x/ac97c.c create mode 100644 sound/soc/au1x/db1000.c create mode 100644 sound/soc/au1x/dma.c create mode 100644 sound/soc/au1x/i2sc.c -- 1.7.6 -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

4 11

Re: [alsa-devel] [PATCH 1/1] oss: rename local change_bits to avoid powerpc bitsops.h definition
by Takashi Iwai 27 Jul '11

27 Jul '11

At Wed, 27 Jul 2011 17:48:41 +0100, Andy Whitcroft wrote: > > This collides with powerpc exported functions from bitops.h. Rename the > local copy in the oss soundblaster mixer and ad1848 driver. > > Signed-off-by: Andy Whitcroft <apw(a)canonical.com> Applied now. Thanks. Takashi > --- > sound/oss/ad1848.c | 6 +++--- > sound/oss/sb_mixer.c | 6 +++--- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c > index 4d2a6ae..8415158 100644 > --- a/sound/oss/ad1848.c > +++ b/sound/oss/ad1848.c > @@ -458,7 +458,7 @@ static int ad1848_set_recmask(ad1848_info * devc, int mask) > return mask; > } > > -static void change_bits(ad1848_info * devc, unsigned char *regval, > +static void oss_change_bits(ad1848_info * devc, unsigned char *regval, > unsigned char *muteval, int dev, int chn, int newval) > { > unsigned char mask; > @@ -516,10 +516,10 @@ static void ad1848_mixer_set_channel(ad1848_info *devc, int dev, int value, int > > if (muteregoffs != regoffs) { > muteval = ad_read(devc, muteregoffs); > - change_bits(devc, &val, &muteval, dev, channel, value); > + oss_change_bits(devc, &val, &muteval, dev, channel, value); > } > else > - change_bits(devc, &val, &val, dev, channel, value); > + oss_change_bits(devc, &val, &val, dev, channel, value); > > spin_lock_irqsave(&devc->lock,flags); > ad_write(devc, regoffs, val); > diff --git a/sound/oss/sb_mixer.c b/sound/oss/sb_mixer.c > index 2039d31..0266088 100644 > --- a/sound/oss/sb_mixer.c > +++ b/sound/oss/sb_mixer.c > @@ -232,7 +232,7 @@ static int detect_mixer(sb_devc * devc) > return 1; > } > > -static void change_bits(sb_devc * devc, unsigned char *regval, int dev, int chn, int newval) > +static void oss_change_bits(sb_devc * devc, unsigned char *regval, int dev, int chn, int newval) > { > unsigned char mask; > int shift; > @@ -284,7 +284,7 @@ int sb_common_mixer_set(sb_devc * devc, int dev, int left, int right) > return -EINVAL; > > val = sb_getmixer(devc, regoffs); > - change_bits(devc, &val, dev, LEFT_CHN, left); > + oss_change_bits(devc, &val, dev, LEFT_CHN, left); > > if ((*devc->iomap)[dev][RIGHT_CHN].regno != regoffs) /* > * Change register > @@ -304,7 +304,7 @@ int sb_common_mixer_set(sb_devc * devc, int dev, int left, int right) > * Read the new one > */ > } > - change_bits(devc, &val, dev, RIGHT_CHN, right); > + oss_change_bits(devc, &val, dev, RIGHT_CHN, right); > > sb_setmixer(devc, regoffs, val); > > -- > 1.7.4.1 >

1 0

[alsa-devel] Searching an argument in mailing post
by Ru Vuott 27 Jul '11

27 Jul '11

Hello, how can I do searching an particular argument in Alsa-mailing list post ?

1 0