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

[alsa-devel] BUG: cx88 can't find device struct
by Timothy E. Krantz 13 Jun '10

13 Jun '10

Hi, I started looking into this problem a while back and gave up. Now I decided to try again. I am running MythDora 12.23 and would like to update the alsa driver to 1.0.23 so that I can use HDMI audio out on my nvidia GT220 card. So I download the alsa-driver-1.0.23.tar.bz file, unpack it, ./configure and make and make install. When I reboot I can verify the new alsa driver by cat/proc/asound/version and it is indeed 1.0.23. If I then try to record an analog station I get: Jun 9 14:40:19 mythdora kernel: BUG: cx88 can't find device struct. Can't proceed with open Jun 9 14:40:19 mythdora kernel: cx88[1]: Calling XC5000 callback Jun 9 14:40:19 mythdora kernel: BUG: cx88 can't find device struct. Can't proceed with open Hmmm, ok the alsa driver implementation updated some kernel header file perhaps, so I download the latest v4l-dvb tree and compile it and install it and reboot. Same thing. No sound on analog recordings. I am sure I am missing some important step or something. Any help would be greatly appreciated! Tim

2 1

Re: [alsa-devel] Alsa-devel Digest, Vol 40, Issue 58
by Tobias Schneider 13 Jun '10

13 Jun '10

----- Ursprüngliche Nachricht ----- Von: alsa-devel-request(a)alsa-project.org Gesendet: Sonntag, 13. Juni 2010 12:00 An: alsa-devel(a)alsa-project.org Betreff: Alsa-devel Digest, Vol 40, Issue 58 Send Alsa-devel mailing list submissions to alsa-devel(a)alsa-project.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.alsa-project.org/mailman/listinfo/alsa-devel or, via email, send a message with subject or body 'help' to alsa-devel-request(a)alsa-project.org You can reach the person managing the list at alsa-devel-owner(a)alsa-project.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Alsa-devel digest..." Today's Topics: 1. Re: ALSA's jack reporting framework map to Android framework (Mark Brown) 2. Re: [PATCH] ASoC: Remove unused header (Mark Brown) 3. Re: Timing Info (Paul Dugas) ---------------------------------------------------------------------- Message: 1 Date: Sat, 12 Jun 2010 18:05:52 +0100 From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Subject: Re: [alsa-devel] ALSA's jack reporting framework map to Android framework To: "Harsha, Priya" <priya.harsha(a)intel.com> Cc: "alsa-devel(a)alsa-project.org" <alsa-devel(a)alsa-project.org>, Mike Lockwood <lockwood(a)android.com> Message-ID: <20100612170552.GA3110(a)sirena.org.uk> Content-Type: text/plain; charset=us-ascii On Sat, Jun 12, 2010 at 09:28:34AM +0530, Harsha, Priya wrote: Please fix your MUA to word wrap your messages, it makes them more legible and easier to reply to. > The ALSA's jack reporting framework reports jacks at > /dev/input/eventx. But the Android framework expects the jack reporting > to be done in /sys/.../switch/h2w. That ... is simply 'class' - the Android kernel includes a new sysfs class for switches, CCing in Mike Lockwood who wrote it in case he's got any input from the Android side. > Any suggestions as to how the ALSA's jack reporting framework to > Android framework? Are there any audio drivers that have mapped this? The obvious thing to do here seems to be to update the Android framework to be able to use the standard kernel interfaces. I obviously can't speak for Google but it seems like the sort of patch they'd be willing to accept, especially if you retain the ability to use the non-standard extensions that are currently being used. I guess an alternative would be to have the Android kernels add an adaptor in the input subsystem (for various reasons not all jack sense goes through ALSA) so that input subsystem switches get represented via the Android switch ABI, though that would increase the amount of out of tree code that needs to be carried and so seems like the wrong direction to be heading. ------------------------------ Message: 2 Date: Sat, 12 Jun 2010 18:07:15 +0100 From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Subject: Re: [alsa-devel] [PATCH] ASoC: Remove unused header To: Liam Girdwood <lrg(a)slimlogic.co.uk> Cc: Grant Likely <grant.likely(a)secretlab.ca>, Herb Peyerl <hpeyerl(a)beer.org>, alsa-devel(a)alsa-project.org, linux-kernel(a)vger.kernel.org Message-ID: <20100612170715.GB3110(a)sirena.org.uk> Content-Type: text/plain; charset=us-ascii On Fri, Jun 11, 2010 at 10:50:40AM +0100, Liam Girdwood wrote: > On Thu, 2010-06-10 at 17:54 -0600, Grant Likely wrote: > > The header contains an extern that isn't used by anything. Remove. > > Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> > Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> Applied, thanks. ------------------------------ Message: 3 Date: Sat, 12 Jun 2010 17:59:27 -0400 From: Paul Dugas <paul(a)dugasenterprises.com> Subject: Re: [alsa-devel] Timing Info To: alsa-devel(a)alsa-project.org Message-ID: <AANLkTik3ycq3POxHRG_bc0jO-KByZVvirVJ-X9-bySY_(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Fri, Jun 11, 2010 at 6:00 PM, Paul Dugas <paul(a)dugasenterprises.com> wrote: > I'm using snd_pcm_readi() to collect samples and am wondering if/how I > can get accurate timestamps for them. ?Seems like the snd_pcm_status() > gives me this info but I'm unclear on the specifics. ?Can someone > point me toward the correct field in the status structure that I > should be using and what sample that timestamp corresponds to? > > Does snd_pcm_status_get_tstamp() get me the timestamp for the first > frame returned by the next snd_pcm_readi() call? I know now get_tstamp() isn't what I'm looking for after reading some prior postings and other web sites. Can't seem to find a discussion of timing in the ALSA docs themselves. Maybe I'm being dense. Looks like some processing of the trigger timestamp is what I need but I'm not following the logic of "triggers" in the simple use of snd_pcm_readi() that I've got. Before the first readi() call, the trigger time is 0. The second time, it's pretty close to the wall time for the first call. Perhaps that's the timestamp of the first sample of the first period I read and I need to add the period_time each time? Seems like that'd accrue error when recording over longer periods of time (which my application does). What's the "timestamp mode". Does it generate a timestamp each period? How would I access that timestamp? Thanks in advance for any assistance, Paul ------------------------------ _______________________________________________ Alsa-devel mailing list Alsa-devel(a)alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel End of Alsa-devel Digest, Vol 40, Issue 58 ******************************************

1 0

[alsa-devel] [PATCH] ASoC: Remove unused header
by Grant Likely 12 Jun '10

12 Jun '10

The header contains an extern that isn't used by anything. Remove. Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> Cc: Liam Girdwood <lrg(a)slimlogic.co.uk> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Jon Smirl <jonsmirl(a)gmail.com> Cc: Herb Peyerl <hpeyerl(a)beer.org> --- sound/soc/fsl/mpc5200_psc_i2s.c | 1 - sound/soc/fsl/mpc5200_psc_i2s.h | 12 ------------ 2 files changed, 0 insertions(+), 13 deletions(-) delete mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c index 4f455bd..676841c 100644 --- a/sound/soc/fsl/mpc5200_psc_i2s.c +++ b/sound/soc/fsl/mpc5200_psc_i2s.c @@ -16,7 +16,6 @@ #include <asm/mpc52xx_psc.h> -#include "mpc5200_psc_i2s.h" #include "mpc5200_dma.h" /** diff --git a/sound/soc/fsl/mpc5200_psc_i2s.h b/sound/soc/fsl/mpc5200_psc_i2s.h deleted file mode 100644 index ce55e07..0000000 --- a/sound/soc/fsl/mpc5200_psc_i2s.h +++ /dev/null @@ -1,12 +0,0 @@ -/* - * Freescale MPC5200 PSC in I2S mode - * ALSA SoC Digital Audio Interface (DAI) driver - * - */ - -#ifndef __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ -#define __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ - -extern struct snd_soc_dai psc_i2s_dai[]; - -#endif /* __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ */

3 2

[alsa-devel] ALSA's jack reporting framework map to Android framework
by Harsha, Priya 12 Jun '10

12 Jun '10

Hi all, The ALSA's jack reporting framework reports jacks at /dev/input/eventx. But the Android framework expects the jack reporting to be done in /sys/.../switch/h2w. Any suggestions as to how the ALSA's jack reporting framework to Android framework? Are there any audio drivers that have mapped this? Any kind of input would be really helpful Thanks, Harsha

2 1

[alsa-devel] ac97 Master and PCM volume control
by Raymond Yau 12 Jun '10

12 Jun '10

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/581650 >> Master ranges from -46.5dB to 0dB but PCM ranges from -34.5dB to +12dB, Daniel T Chen <https://launchpad.net/%7Ecrimsun> wrote on 2010-05-18: #1<https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/581650/comments/1> This is not a pulse bug but a hardware one I wonder why you said this is a hardware bug since this is ac97 specification maximum the total gain will be +12dB, not 0dB as indicated. Did you read those ac97 2.x specification ?

1 0

[alsa-devel] extra interrupt on plug insertion undoes mux selection
by Peter M. Petrakis 12 Jun '10

12 Jun '10

Hi All, Trying my hand at snd quirking, I'm working a Dell Latitude E4310. Here's what I'm seeing. There's a headset jack (HP/MIC combo) on the LHS, when I insert a headset I see the following in the logs. Note: port 0xA is the mic jack, 0xB is hp jack, and 0x11 in internal mic. Jun 11 18:17:45 ubuntu-laptop kernel: [ 193.978394] XXX stac92xx_unsol_event: codec subsystem id 10280410 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361330] XXX stac92xx_unsol_event: event - 6 nid - 0a. Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361335] XXX stac92xx_unsol_event: event - 6 MIC Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361337] XXX stac92xx_mic_detect: ENTER Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361340] XXX get_pin_presence:4422 ENTER, NID 0a Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361434] XXX get_pin_presence:4429 EXIT 1, got pin sense Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361439] XXX stac92xx_mic_detect: HERE 4662 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361441] XXX stac92xx_mic_detect: HERE 4676 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361444] XXX stac92xx_mic_detect:4678 mux_nid:0017 index:6 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361449] XXX stac92xx_mic_detect: EXIT Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361451] XXX stac92xx_unsol_event: genevent - 6 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361532] XXX get_pin_presence:4422 ENTER, NID 0a Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361620] XXX get_pin_presence:4429 EXIT 1, got pin sense Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361628] XXX stac92xx_unsol_event: codec subsystem id 10280410 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361631] XXX stac92xx_unsol_event: event - 4 nid - 0b. Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361634] XXX stac92xx_unsol_event: event - 4 HP or LO Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361636] XXX stac92xx_hp_detect: ENTER Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361638] XXX get_pin_presence:4422 ENTER, NID 0b Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361717] XXX get_pin_presence:4429 EXIT 1, got pin sense Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361720] XXX stac92xx_hp_detect:4522 probe_pin:0 hp_pin:000b Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361807] XXX stac92xx_hp_detect: pinctl c0 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361810] XXX stac92xx_hp_detect: HERE 4534 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361812] XXX stac92xx_hp_detect: HERE 4537 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361906] XXX stac92xx_hp_detect: HERE 4569 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361996] XXX stac92xx_hp_detect: EXIT Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.361998] XXX stac92xx_unsol_event: genevent - 4 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.362067] XXX get_pin_presence:4422 ENTER, NID 0b Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.362163] XXX get_pin_presence:4429 EXIT 1, got pin sense Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.362168] XXX stac92xx_unsol_event: codec subsystem id 10280410 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735203] XXX stac92xx_unsol_event: event - 6 nid - 0a. Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735206] XXX stac92xx_unsol_event: event - 6 MIC Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735209] XXX stac92xx_mic_detect: ENTER Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735212] XXX get_pin_presence:4422 ENTER, NID 0a Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735311] XXX get_pin_presence:4433 EXIT 0, no pin sense Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735315] XXX stac92xx_mic_detect: HERE 4666 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735318] XXX stac92xx_mic_detect: HERE 4676 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735320] XXX stac92xx_mic_detect:4678 mux_nid:0017 index:4 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735325] XXX stac92xx_mic_detect: EXIT Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735327] XXX stac92xx_unsol_event: genevent - 6 Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735410] XXX get_pin_presence:4422 ENTER, NID 0a Jun 11 18:17:45 ubuntu-laptop kernel: [ 201.735497] XXX get_pin_presence:4433 EXIT 0, no pin sense I've tested against kernels 2.6.32 and 2.6.35rc2 with the same results. The mux is indeed back where it started after the plug is fully inserted. Node 0x17 [Audio Selector] wcaps 0x300d0d: Stereo Amp-Out R/L Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1 Amp-Out vals: [0x0f 0x0f] Power: setting=D0, actual=D0 Connection: 7 0x0c 0x0e 0x0f 0x1b 0x11* 0x12 0x0a and I can push it around with hda-verb to get the desired result... The question is why is it doing this? To make things weirder, I can get input from the external mic even if it isn't selected. This is my first attempt at making codecs "do the right thing" so I could very well be missing something obvious. What else am I missing here? Thanks. Peter

1 0

Re: [alsa-devel] [PATCH 3/4] ALSA: usb-audio: parse UAC2 sample rate ranges correctly
by Daniel Mack 11 Jun '10

11 Jun '10

On Fri, Jun 11, 2010 at 10:59:44PM +0800, Alex Lee wrote: > If the device has a variable clock, it may report a RES of only 1. So you > may end up with thousands (and even millions) of sample rates. It might be > better to have separate code to cater to discrete clocks vs variable clocks. AFAIK, ALSA cannot cope with that yet. Am I right? Daniel > On Fri, Jun 11, 2010 at 9:33 PM, Daniel Mack <daniel(a)caiaq.de> wrote: > > > A device may report its supported sample rates in ranges rather than in > > discrete triplets. The code used to only parse the MIN field instead of > > properly paying attention to the MAX and RES values. > > > > Signed-off-by: Daniel Mack <daniel(a)caiaq.de> > > Reported-by: Alex Lee <alexlee188(a)gmail.com> > > --- > > sound/usb/format.c | 80 > > ++++++++++++++++++++++++++++++++++++++++----------- > > 1 files changed, 62 insertions(+), 18 deletions(-) > > > > diff --git a/sound/usb/format.c b/sound/usb/format.c > > index 8eccf17..e946db7 100644 > > --- a/sound/usb/format.c > > +++ b/sound/usb/format.c > > @@ -206,6 +206,47 @@ static int parse_audio_format_rates_v1(struct > > snd_usb_audio *chip, struct audiof > > } > > > > /* > > + * Helper function to walk the array of sample rate triplets reported by > > + * the device. The problem is that we need to parse whole array first to > > + * get to know how many sample rates we have to expect. > > + * Then fp->rate_table can be allocated and filled. > > + */ > > +static int parse_uac2_sample_rate_range(struct audioformat *fp, int > > nr_triplets, > > + const unsigned char *data) > > +{ > > + int i, nr_rates = 0; > > + > > + fp->rates = fp->rate_min = fp->rate_max = 0; > > + > > + for (i = 0; i < nr_triplets; i++) { > > + int min = combine_quad(&data[2 + 12 * i]); > > + int max = combine_quad(&data[6 + 12 * i]); > > + int res = combine_quad(&data[10 + 12 * i]); > > + int rate; > > + > > + if ((max < 0) || (min < 0) || (res < 0) || (max < min)) > > + continue; > > + > > + for (rate = min; rate <= max; rate += res) { > > + if (fp->rate_table) > > + fp->rate_table[nr_rates] = rate; > > + if (!fp->rate_min || rate < fp->rate_min) > > + fp->rate_min = rate; > > + if (!fp->rate_max || rate > fp->rate_max) > > + fp->rate_max = rate; > > + fp->rates |= snd_pcm_rate_to_rate_bit(rate); > > + nr_rates++; > > + > > + /* avoid endless loop */ > > + if (res == 0) > > + break; > > + } > > + } > > + > > + return nr_rates; > > +} > > + > > +/* > > * parse the format descriptor and stores the possible sample rates > > * on the audioformat table (audio class v2). > > */ > > @@ -215,7 +256,7 @@ static int parse_audio_format_rates_v2(struct > > snd_usb_audio *chip, > > { > > struct usb_device *dev = chip->dev; > > unsigned char tmp[2], *data; > > - int i, nr_rates, data_size, ret = 0; > > + int nr_triplets, data_size, ret = 0; > > int clock = snd_usb_clock_find_source(chip, chip->ctrl_intf, > > fp->clock); > > > > if (clock < 0) { > > @@ -237,8 +278,8 @@ static int parse_audio_format_rates_v2(struct > > snd_usb_audio *chip, > > goto err; > > } > > > > - nr_rates = (tmp[1] << 8) | tmp[0]; > > - data_size = 2 + 12 * nr_rates; > > + nr_triplets = (tmp[1] << 8) | tmp[0]; > > + data_size = 2 + 12 * nr_triplets; > > data = kzalloc(data_size, GFP_KERNEL); > > if (!data) { > > ret = -ENOMEM; > > @@ -259,26 +300,29 @@ static int parse_audio_format_rates_v2(struct > > snd_usb_audio *chip, > > goto err_free; > > } > > > > - fp->rate_table = kmalloc(sizeof(int) * nr_rates, GFP_KERNEL); > > + /* Call the triplet parser, and make sure fp->rate_table is NULL. > > + * We just use the return value to know how many sample rates we > > + * will have to deal with. */ > > + kfree(fp->rate_table); > > + fp->rate_table = NULL; > > + fp->nr_rates = parse_uac2_sample_rate_range(fp, nr_triplets, data); > > + > > + if (fp->nr_rates == 0) { > > + snd_printk(KERN_ERR "%s(): unable to parse sample rate > > triplets\n", > > + __func__); > > + ret = -EINVAL; > > + goto err_free; > > + } > > + > > + fp->rate_table = kmalloc(sizeof(int) * fp->nr_rates, GFP_KERNEL); > > if (!fp->rate_table) { > > ret = -ENOMEM; > > goto err_free; > > } > > > > - fp->nr_rates = 0; > > - fp->rate_min = fp->rate_max = 0; > > - > > - for (i = 0; i < nr_rates; i++) { > > - int rate = combine_quad(&data[2 + 12 * i]); > > - > > - fp->rate_table[fp->nr_rates] = rate; > > - if (!fp->rate_min || rate < fp->rate_min) > > - fp->rate_min = rate; > > - if (!fp->rate_max || rate > fp->rate_max) > > - fp->rate_max = rate; > > - fp->rates |= snd_pcm_rate_to_rate_bit(rate); > > - fp->nr_rates++; > > - } > > + /* Call the triplet parser again, but this time, fp->rate_table is > > + * allocated, so the rates will be stored */ > > + parse_uac2_sample_rate_range(fp, nr_triplets, data); > > > > err_free: > > kfree(data); > > -- > > 1.7.1 > > > >

4 11

[alsa-devel] usb-audio: some UAC2 fixes
by Daniel Mack 11 Jun '10

11 Jun '10

Hi, here are four small patches that fix some minor bugs in the UAC2 implementation. Thanks to Alex Lee for reporting them. Don't know if it's possible to get them into 2.6.35 as they're no regressions in respect to 2.6.34 (I followed the recent discussions on LKML). However, they fix real bugs and I would also label them stable(a)kernel.org if 2.6.35 would have already been released. So .. I don't know :) I have a number of more patches that do cleanups and implement more functions, but they can certainly go into 2.6.36 and they're not finished yet, so I'm cooking them for some more time. Thanks, Daniel [PATCH 1/4] ALSA: usb-audio: add check for faulty clock in parse_audio_format_rates_v2() [PATCH 2/4] ALSA: usb-audio: fix control messages for USB_RECIP_INTERFACE [PATCH 3/4] ALSA: usb-audio: parse UAC2 sample rate ranges correctly [PATCH 4/4] ALSA: usb-audio: fix UAC2 control value queries

1 5

[PATCH] ALSA: usb-audio: fix UAC2 control value queries
by Daniel Mack 11 Jun '10

11 Jun '10

For RANGE requests, we should only query as much bytes as we're in face interested in. For CUR requests, we shouldn't confuse the firmware with an overlong request but just ask for 2 bytes. This might need fixing in the future as it's not entirely clear when to dispatch 1-byte, 2-byte and 4-byte request blocks. For now, we assume everything is coded in 16bit - this works for all firmware implementations I've seen. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> Reported-by: Alex Lee <alexlee188(a)gmail.com> --- sound/usb/mixer.c | 19 ++++++++++++++----- 1 files changed, 14 insertions(+), 5 deletions(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index a060d00..6939d0f 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -297,20 +297,27 @@ static int get_ctl_value_v1(struct usb_mixer_elem_info *cval, int request, int v static int get_ctl_value_v2(struct usb_mixer_elem_info *cval, int request, int validx, int *value_ret) { - unsigned char buf[14]; /* enough space for one range of 4 bytes */ + unsigned char buf[2 + 3*sizeof(__u16)]; /* enough space for one range */ unsigned char *val; - int ret; + int ret, size; __u8 bRequest; - bRequest = (request == UAC_GET_CUR) ? - UAC2_CS_CUR : UAC2_CS_RANGE; + if (request == UAC_GET_CUR) { + bRequest = UAC2_CS_CUR; + size = sizeof(__u16); + } else { + bRequest = UAC2_CS_RANGE; + size = sizeof(buf); + } + + memset(buf, 0, sizeof(buf)); ret = snd_usb_ctl_msg(cval->mixer->chip->dev, usb_rcvctrlpipe(cval->mixer->chip->dev, 0), bRequest, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, validx, cval->mixer->ctrlif | (cval->id << 8), - buf, sizeof(buf), 1000); + buf, size, 1000); if (ret < 0) { snd_printk(KERN_ERR "cannot get ctl value: req = %#x, wValue = %#x, wIndex = %#x, type = %d\n", @@ -318,6 +325,8 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info *cval, int request, int v return ret; } + /* FIXME: how should we handle multiple triplets here? */ + switch (request) { case UAC_GET_CUR: val = buf; -- 1.7.1

1 0

[alsa-devel] [PATCH 0/3] EP93xx: Add i2s audio support
by Ryan Mallon 11 Jun '10

11 Jun '10

Repost of the i2s audio series for ep93xx. Patch 2/3 is unchanged. The core support has been modified to move setting of the SPOL and ORIDE bits of the i2sclkdiv register, as well as the i2s pin strapping configuration, to a new function called ep93xx_i2s_acquire which is called from the audio board drivers. Ryan Mallon (3): EP93xx: Add i2s core support EP93xx: Add i2s audio driver EP93xx: Add Snapper CL15 i2s audio support arch/arm/mach-ep93xx/clock.c | 67 +++- arch/arm/mach-ep93xx/core.c | 67 +++ arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 10 + arch/arm/mach-ep93xx/include/mach/platform.h | 3 + arch/arm/mach-ep93xx/snappercl15.c | 1 + sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + sound/soc/ep93xx/Kconfig | 18 + sound/soc/ep93xx/Makefile | 11 + sound/soc/ep93xx/ep93xx-i2s.c | 487 +++++++++++++++++++++++ sound/soc/ep93xx/ep93xx-i2s.h | 18 + sound/soc/ep93xx/ep93xx-pcm.c | 319 +++++++++++++++ sound/soc/ep93xx/ep93xx-pcm.h | 22 + sound/soc/ep93xx/snappercl15.c | 150 +++++++ 14 files changed, 1174 insertions(+), 1 deletions(-) create mode 100644 sound/soc/ep93xx/Kconfig create mode 100644 sound/soc/ep93xx/Makefile create mode 100644 sound/soc/ep93xx/ep93xx-i2s.c create mode 100644 sound/soc/ep93xx/ep93xx-i2s.h create mode 100644 sound/soc/ep93xx/ep93xx-pcm.c create mode 100644 sound/soc/ep93xx/ep93xx-pcm.h create mode 100644 sound/soc/ep93xx/snappercl15.c

3 18