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

[alsa-devel] Send to stable for "ALSA: hda - Move one-time init codes from generic_hdmi_init()"?
by David Henningsson 11 Mar '13

11 Mar '13

Hi Takashi, Should this patch be sent to stable? commit 8b8d654b55648561287bd8baca0f75f964a17038 Author: Takashi Iwai <tiwai(a)suse.de> Date: Wed Jun 20 16:32:22 2012 +0200 ALSA: hda - Move one-time init codes from generic_hdmi_init() I'm investigating a kernel panic under kernel 3.5, and I'm not 100% sure (still waiting for person with hw to report back), but the only reasonable explanation I can find is that there is some power management activity going while the repoll timer (for hdmi_present_sense) is running, and that generic_hdmi_init reinitializes the delayed_work struct, thus causing the panic when the timer has elapsed. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic

2 1

Re: [alsa-devel] running 32 chan AD/DA on Linux
by Daniel Mack 11 Mar '13

11 Mar '13

Hi Igor, On 11.03.2013 09:56, Igor Levin wrote: > Thank you so much for a quick answer, are you in Europe by any chance? Yes, in Germany. > Could you give us a link where we can browse the source code on the Net, > or tell us where to get those files > mentioned as there seem to be so many Linux source files floating in the > web. Please forgive my ignorance > if this question seems so naive, I am really a hardware engineer :) There's Linus' repository which ends up in the official tarball releases on a regular basis. You can browse that tree online in its cgit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/… > Do you believe the code base as it stands will work with 32 channels > In/Out pipes or do we need to > get the unit to one of you guys to test it and make corrections as needed? I'm not aware of any sound specific limitations in that area. Just try it, and let us know how it goes. Sending the output of 'lsusb -v' for a descriptor dump is mandatory in order to understand how your device is designed. Thanks, Daniel

1 0

Re: [alsa-devel] [PATCH] ASoC: adau1373: adau1373_hw_params: Silence overflow warning
by Lars-Peter Clausen 11 Mar '13

11 Mar '13

On 03/10/2013 06:34 PM, Tim Gardner wrote: > ADAU1373_BCLKDIV_SOURCE is defined as BIT(5) which uses UL constants. On > amd64 the result of the ones complement operator is then truncated to > unsigned int according to the prototype of snd_soc_update_bits(). I think > gcc is correctly warning that the upper 32 bits are lost. > > sound/soc/codecs/adau1373.c: In function 'adau1373_hw_params': > sound/soc/codecs/adau1373.c:940:3: warning: large integer implicitly truncated to unsigned type [-Woverflow] > > gcc version 4.6.3 > > Cc: Lars-Peter Clausen <lars(a)metafoo.de> > Cc: Liam Girdwood <lgirdwood(a)gmail.com> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Cc: Jaroslav Kysela <perex(a)perex.cz> > Cc: Takashi Iwai <tiwai(a)suse.de> > Cc: device-drivers-devel(a)blackfin.uclinux.org > Cc: alsa-devel(a)alsa-project.org > Signed-off-by: Tim Gardner <tim.gardner(a)canonical.com> > --- > sound/soc/codecs/adau1373.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/codecs/adau1373.c b/sound/soc/codecs/adau1373.c > index 068b3ae..56ed788 100644 > --- a/sound/soc/codecs/adau1373.c > +++ b/sound/soc/codecs/adau1373.c > @@ -132,7 +132,7 @@ struct adau1373 { > #define ADAU1373_DAI_FORMAT_I2S 0x2 > #define ADAU1373_DAI_FORMAT_DSP 0x3 > > -#define ADAU1373_BCLKDIV_SOURCE BIT(5) > +#define ADAU1373_BCLKDIV_SOURCE (unsigned int)BIT(5) Hm, that's a bit ugly. How about the following instead: diff --git a/sound/soc/codecs/adau1373.c b/sound/soc/codecs/adau1373.c index 068b3ae..1aa10dd 100644 --- a/sound/soc/codecs/adau1373.c +++ b/sound/soc/codecs/adau1373.c @@ -133,6 +133,8 @@ struct adau1373 { #define ADAU1373_DAI_FORMAT_DSP 0x3 #define ADAU1373_BCLKDIV_SOURCE BIT(5) +#define ADAU1373_BCLKDIV_SR_MASK (0x07 << 2) +#define ADAU1373_BCLKDIV_BCLK_MASK 0x03 #define ADAU1373_BCLKDIV_32 0x03 #define ADAU1373_BCLKDIV_64 0x02 #define ADAU1373_BCLKDIV_128 0x01 @@ -937,7 +939,8 @@ static int adau1373_hw_params(struct snd_pcm_substream *substream, adau1373_dai->enable_src = (div != 0); snd_soc_update_bits(codec, ADAU1373_BCLKDIV(dai->id), - ~ADAU1373_BCLKDIV_SOURCE, (div << 2) | ADAU1373_BCLKDIV_64); + ADAU1373_BCLKDIV_SR_MASK | ADAU1373_BCLKDIV_BCLK_MASK, + (div << 2) | ADAU1373_BCLKDIV_64); switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE:

1 0

[alsa-devel] snd_seq_timer_open() NULL pointer dereference
by Tommi Rantala 11 Mar '13

11 Mar '13

Hello, I'm hitting this while fuzzing the kernel with Trinity: [ 239.006244] BUG: unable to handle kernel NULL pointer dereference at 00000000000002ae [ 239.007011] IP: [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130 [ 239.007011] PGD 785cd067 PUD 76964067 PMD 0 [ 239.007011] Oops: 0002 [#4] SMP [ 239.007011] CPU 0 [ 239.007011] Pid: 4288, comm: trinity-child7 Tainted: G D W 3.9.0-rc1+ #100 Bochs Bochs [ 239.007011] RIP: 0010:[<ffffffff819b3477>] [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130 [ 239.007011] RSP: 0018:ffff88006ece7d38 EFLAGS: 00010246 [ 239.007011] RAX: 0000000000000286 RBX: ffff88007851b400 RCX: 0000000000000000 [ 239.007011] RDX: 000000000000ffff RSI: ffff88006ece7d58 RDI: ffff88006ece7d38 [ 239.007011] RBP: ffff88006ece7d98 R08: 000000000000000a R09: 000000000000fffe [ 239.007011] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 239.007011] R13: ffff8800792c5400 R14: 0000000000e8f000 R15: 0000000000000007 [ 239.007011] FS: 00007f7aaa650700(0000) GS:ffff88007f800000(0000) knlGS:0000000000000000 [ 239.007011] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 239.007011] CR2: 00000000000002ae CR3: 000000006efec000 CR4: 00000000000006f0 [ 239.007011] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 239.007011] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 239.007011] Process trinity-child7 (pid: 4288, threadinfo ffff88006ece6000, task ffff880076a8a290) [ 239.007011] Stack: [ 239.007011] 0000000000000286 ffffffff828f2be0 ffff88006ece7d58 ffffffff810f354d [ 239.007011] 65636e6575716573 2065756575712072 ffff8800792c0030 0000000000000000 [ 239.007011] ffff88006ece7d98 ffff8800792c5400 ffff88007851b400 ffff8800792c5520 [ 239.007011] Call Trace: [ 239.007011] [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10 [ 239.007011] [<ffffffff819b17e9>] snd_seq_queue_timer_open+0x29/0x70 [ 239.007011] [<ffffffff819ae01a>] snd_seq_ioctl_set_queue_timer+0xda/0x120 [ 239.007011] [<ffffffff819acb9b>] snd_seq_do_ioctl+0x9b/0xd0 [ 239.007011] [<ffffffff819acbe0>] snd_seq_ioctl+0x10/0x20 [ 239.007011] [<ffffffff811b9542>] do_vfs_ioctl+0x522/0x570 [ 239.007011] [<ffffffff8130a4b3>] ? file_has_perm+0x83/0xa0 [ 239.007011] [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10 [ 239.007011] [<ffffffff811b95ed>] sys_ioctl+0x5d/0xa0 [ 239.007011] [<ffffffff813663fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 239.007011] [<ffffffff81faed69>] system_call_fastpath+0x16/0x1b [ 239.007011] Code: e8 ef b4 fd ff 85 c0 41 89 c4 79 18 44 89 e6 48 c7 c7 e0 f0 5f 82 31 c0 e8 e7 34 5e 00 eb 35 0f 1f 44 00 00 48 8b 45 a0 45 31 e4 <48> c7 40 28 e0 2e 9b 81 4c 89 68 38 83 48 10 08 48 89 43 50 eb [ 239.007011] RIP [<ffffffff819b3477>] snd_seq_timer_open+0xe7/0x130 [ 239.007011] RSP <ffff88006ece7d38> [ 239.007011] CR2: 00000000000002ae [ 239.055294] ---[ end trace bfb5b965ff1d73a3 ]--- Tommi

2 3

Re: [alsa-devel] running 32 chan AD/DA on Linux
by Daniel Mack 11 Mar '13

11 Mar '13

Hi Igor, please don't remove the alsa ML from Cc:. On 11.03.2013 09:37, Igor Levin wrote: [...] > But now we got a bit of a breather and our developers are finally able > to give Linux the attention it deserves > to get it going. I have couple fundamental question which you guys can > help us with: > > 1) Does Linux audio support the Implicit feedback mode where the Out > pipe will source the same amount of > samples as are coming into related IN pipe. Yes. > This is the sync mode > we use in Orion 32. If this is so, could > you kindly provide the file/line number in the source code where we > can see how it makes the packetising > decision. Please have a look at sound/usb/endpoint.c - this is where the packet logic lives in. Please read the comments in this file - the packet sending for this implicit feedback mode is implemented in queue_pending_output_urbs(). > 2) We are upgrading our Zodiac DAC to use asynchronous feedback mode. > What Async feedback mode formats > does Linux support? Where can we see it in the source? Linux supports feedback over dedicated isochronous endpoints as well. The format is auto-detected in snd_usb_handle_sync_urb(), also in sound/usb/endpoint.c, after each stream start. Internally, the driver uses Q16.16. Hope this helps. In case of more specific questions, please just let me know. Thanks, Daniel

1 0

Re: [alsa-devel] [PATCH][RESEND] Add a USB audio quirk for the NuForce UDH-100 device.
by Clemens Ladisch 11 Mar '13

11 Mar '13

David Helstroom wrote: > Interface 1 does not exist Then it doesn't need a quirk, does it? > and Interface 0 should be ignored. Why? If the driver doesn't like something in interface 0, that bug should be fixed. What is the output of "lsusb -v" for this device? Regards, Clemens

1 0

[alsa-devel] davici-mcasp: "tx-num-evt" confusion with number of serializers
by Michal Bachraty 11 Mar '13

11 Mar '13

Hi, I'm working on multichannel version of davinci-mcasp and also davinci-pcm. I have first version running and now I want to refine code. I found one confusion in davinci-mcasp with using of DT property "tx-num-evt". In DT binding documentation "tx-num-evt" is defined as "FIFO levels", but in Mcasp src, there is code, which mixes tx-num-evt with number of serializers (i2s data lines) that are enabled for data playback and receive (dev->txnumevt * tx_ser) mcasp_mod_bits(dev->base + MCASP_VER3_WFIFOCTL, (((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK); >From dacinci pcm, DMA data tranfer use txnumevt as number of serializers and also for data prefetching. I undestand definition "FIFO levels" as how many prefetched data are in FIFO. Prefetched data are for me frame data / 2 ( all left or right channels for one sampling time). This results me from AM335x FIFO documantation. What is original purpose for "tx-num-evt" parameter? Thanks, Michal

5 12

[alsa-devel] Add ALSA driver to Buildroot image or add / load it after booting the image
by Marc Schultz 11 Mar '13

11 Mar '13

Hey ALSA-Devel community, I'm successfully booting a Buildroot made Linux image on my board. This board has an Cirrus Logic CS4270 sound chip and now I want to activate the specific sound card driver for it. Is there a good way to put the CS4270 driver files into the Linux Kernel folders of Buildroot to get them compressed into the Linux image or do I have to go one of the following ways after booting the image on my target hardware? http://www.alsa-project.org/main/index.php/Matrix:Module-cs4270 http://www.alsa-project.org/main/index.php/Driver_Compilation) Do you have a good workflow for me to get this thing working? Best regards, Marc Schultz

2 1

Re: [alsa-devel] [PATCH] emu10k1: Fix coccicheck warning
by Clemens Ladisch 10 Mar '13

10 Mar '13

Vicentiu Ciorbaru wrote: > On Sun, Mar 10, 2013 at 6:32 PM, Clemens Ladisch <clemens(a)ladisch.de> wrote: >> Vicentiu Ciorbaru wrote: >>> Removed redundant cast of kmalloc return pointer. >> >>> - (icode->gpr_map = (u_int32_t __user *) >>> - kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t), >>> - GFP_KERNEL)) == NULL || >>> + (icode->gpr_map = kcalloc(512 + 256 + 256 + 2 * 1024, >>> + sizeof(u_int32_t), GFP_KERNEL)) == NULL || >> >> Why would casting to __user be redundant? > > My reasoning behind the patch is that the C standard does not require a > specific cast of a void pointer in order to set it to the type of the > member gpr_map of the struct snd_emu10k1_fx8010_code. I named it redundant > because the compiler would cast to it anyway. That's correct as far as the C standard is concerned. However, __user is a non-standard extension. > The line also appears as a warning when running make coccicheck. And when you remove the __user, you get a warning when running make C=x. Both coccinelle and sparse are merely tools for finding likely bugs. When it isn't possible to make them both happy with or without the cast, that just shows that the code itself is badly designed. The driver should be redesigned to not access user and kernel space memory through the same pointer. Regards, Clemens

1 0

Re: [alsa-devel] [PATCH 01/10] imx-ssi: Fix AC97 rates
by Fabio Estevam 10 Mar '13

10 Mar '13

Hi Markus, On Sun, Mar 10, 2013 at 3:33 PM, Markus Pargmann <mpa(a)pengutronix.de> wrote: > From: Sascha Hauer <s.hauer(a)pengutronix.de> > > This device supports multiple rates as described in later AC97 > standards. This patch allows playback of different sample frequencies > without conversion. > > Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> > --- > sound/soc/fsl/imx-ssi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Currently we have the following ssi drivers for imx: sound/soc/fsl/imx-ssi.c: for i.mx SoCs running on non-dt platform sound/soc/fsl/fsl_ssi.c: for PowerPC and i.mx SoCs running on dt platforms I see that in this series you convert sound/soc/fsl/imx-ssi.c into dt. Shouldn't we use sound/soc/fsl/fsl_ssi.c instead and maybe even get rid of sound/soc/fsl/imx-ssi.c when all imx become converted to dt?

1 0