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

[alsa-devel] got a segmentation fault when use multi-channel device
by Zhang wei 06 Apr '13

06 Apr '13

hello everone. i am now debuging the multi-channel device on my embeded board with alsa-lib.The version alsa-driver and alsa-lib is 1.0.24. -----------------------------> zz@board:$ ls /dev/snd/ by-path controlC0 midiC0D0 pcmC0D0c pcmC0D0p pcmC0D1p seq timer <--------------------------- i edit the asoundrc configure file.like this: ---------------------------------------------------> pcm.!default{ type hw card 0 } ctl.!default{ type hw card 0 } ################################# ## create a virtul device which has 4 channels for playback. ################################# pcm.multi_playback{ type multi; slaves.a.pcm "hw:0,0"; slaves.a.channels 2; slaves.b.pcm "hw:0,1"; slaves.b.channels 2; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave b; bindings.2.channel 0; bindings.3.slave b; bindings.3.channel 1; } ctl.multi_playback{ type hw; card 0; } pcm.ttable{ type route; slave.pcm "multi_playback"; slave.channels 4; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; } ctl.ttable { type hw; card 0; } <-------------------------------------------------- and then get the Segmentation fault: --------------------------------------------------------------> [root@board /tmp]#./pb_pcm_min open...ver:[0.71] playback...capture...device=[multi_playback] #####################snd_pcm_open... zz[snd_dlsym_verify:122],vname=[_snd_config_hook_load_dlsym_config_hook_ 001] zz[snd_dlsym_verify:127] zz[snd_dlsym:167] zz[snd_dlsym:171],name=[snd_config_hook_load] zz[snd_pcm_open_conf:2163] zz[snd_dlsym_verify:122],vname=[__snd_pcm_multi_open_dlsym_pcm_001] Segmentation fault [root@board /tmp]# <--------------------------------------------------------------- To my surpris, it will be fine when run on the PC under the Ubuntu system.I used the same alsa-lib source code and the configure file asoundrc. in my codec-driver .i have not call the functions :snd_soc_add_controls() / snd_soc_dapm_new_controls() / snd_soc_dapm_add_routes(). is it the reason? But the programm have not arrived here. i have traced the source code when the Segmentation fault happened the alsa-lib was calling the function dlysm() with the param vname=__snd_pcm_multi_open_dlsym_pcm_001. But this will not happen on my PC under Ubuntu. could you help me find out what's wrong with me? thanks a lot. zw

1 0

[alsa-devel] PROBLEM: very loud sound of electric discharge on shutdown and restart with ALC882M with all kernels I tried up to 3.9 rc5
by Jenya Y 06 Apr '13

06 Apr '13

I always had this problem in linux and only today tried to search for answers. Solutions I came across involved disabling power management on Intel HDA, which is already 0 by default and also the option of muting on shutdown/ restart, which had absolutely no effect. I wish I could figure this out myself but after 4 hours of searching and trying things out and countless restarts I've given up and decided to come to you for help. Jenya On 03/20/2013 08:41 AM, Jenya Y wrote: > I still didn't receive anything from you as I already mentioned I tried > most of the 'obvious' solutions I came accross and still looking for > answers. > Maybe I'm using the wrong ML for this question. If so, maybe you could at > least suggest another HDA/ ALSA maintainer to contact in this situation. > > TIA, Jenya.

1 0

[alsa-devel] [PATCH v2] ALSA: hda/ca0132 - Update latency based on DSP state.
by Dylan Reid 05 Apr '13

05 Apr '13

The DSP in the CA0132 codec adds a variable latency to audio depending on what processing is being done. Add a new patch op to return that latency for capture and playback streams. The latency is determined by which blocks are enabled and knowing how much latency is added by each block. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- Changes since v1: Rebase on tiwai's patch to add a pcm_op, this is dependent on that. Get ms to frames conversion right. Test loopback and compare measured vs reported latency. sound/pci/hda/patch_ca0132.c | 55 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 12eb21a..841842c 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -131,6 +131,13 @@ enum { /* Effects values size*/ #define EFFECT_VALS_MAX_COUNT 12 +/* Latency introduced by DSP blocks in milliseconds. */ +#define DSP_CAPTURE_INIT_LATENCY 0 +#define DSP_CRYSTAL_VOICE_LATENCY 124 +#define DSP_PLAYBACK_INIT_LATENCY 13 +#define DSP_PLAY_ENHANCEMENT_LATENCY 30 +#define DSP_SPEAKER_OUT_LATENCY 7 + struct ct_effect { char name[44]; hda_nid_t nid; @@ -2743,6 +2750,31 @@ static int ca0132_playback_pcm_cleanup(struct hda_pcm_stream *hinfo, return 0; } +static unsigned int ca0132_playback_pcm_delay(struct hda_pcm_stream *info, + struct hda_codec *codec, + struct snd_pcm_substream *substream) +{ + struct ca0132_spec *spec = codec->spec; + unsigned int latency = DSP_PLAYBACK_INIT_LATENCY; + struct snd_pcm_runtime *runtime = substream->runtime; + + if (spec->dsp_state != DSP_DOWNLOADED) + return 0; + + /* Add latency if playback enhancement and either effect is enabled. */ + if (spec->effects_switch[PLAY_ENHANCEMENT - EFFECT_START_NID]) { + if ((spec->effects_switch[SURROUND - EFFECT_START_NID]) || + (spec->effects_switch[DIALOG_PLUS - EFFECT_START_NID])) + latency += DSP_PLAY_ENHANCEMENT_LATENCY; + } + + /* Applying Speaker EQ adds latency as well. */ + if (spec->cur_out_type == SPEAKER_OUT) + latency += DSP_SPEAKER_OUT_LATENCY; + + return (latency * runtime->rate) / 1000; +} + /* * Digital out */ @@ -2811,6 +2843,23 @@ static int ca0132_capture_pcm_cleanup(struct hda_pcm_stream *hinfo, return 0; } +static unsigned int ca0132_capture_pcm_delay(struct hda_pcm_stream *info, + struct hda_codec *codec, + struct snd_pcm_substream *substream) +{ + struct ca0132_spec *spec = codec->spec; + unsigned int latency = DSP_CAPTURE_INIT_LATENCY; + struct snd_pcm_runtime *runtime = substream->runtime; + + if (spec->dsp_state != DSP_DOWNLOADED) + return 0; + + if (spec->effects_switch[CRYSTAL_VOICE - EFFECT_START_NID]) + latency += DSP_CRYSTAL_VOICE_LATENCY; + + return (latency * runtime->rate) / 1000; +} + /* * Controls stuffs. */ @@ -4002,7 +4051,8 @@ static struct hda_pcm_stream ca0132_pcm_analog_playback = { .channels_max = 6, .ops = { .prepare = ca0132_playback_pcm_prepare, - .cleanup = ca0132_playback_pcm_cleanup + .cleanup = ca0132_playback_pcm_cleanup, + .get_delay = ca0132_playback_pcm_delay, }, }; @@ -4012,7 +4062,8 @@ static struct hda_pcm_stream ca0132_pcm_analog_capture = { .channels_max = 2, .ops = { .prepare = ca0132_capture_pcm_prepare, - .cleanup = ca0132_capture_pcm_cleanup + .cleanup = ca0132_capture_pcm_cleanup, + .get_delay = ca0132_capture_pcm_delay, }, }; -- 1.8.1.5

3 9

[alsa-devel] [PATCH 00/10] UAC2: Automatic clock switching
by Eldad Zack 05 Apr '13

05 Apr '13

Hi, This patch series is intended for-next. It provides automatic clock switching for UAC2 devices (patches #6-#8). If the current selected clock is not valid, other clocks will be checked and the first (indexwise) valid clock will be used. Patch #8 provides a module flag to turn this logic off, since in some use cases (e.g., studio work) it might not be desired. But I think most users want their audio devices to "just work", so the default is on. To make the change more obvious, I first moved the validity check around without changing any logic (#6). Patch #10 adds support for clocks with read-only sample frequency control. All other patches included are trivial clean up patches. I'd appreciate a review and/or testing this patch series. This applies to all UAC2 devices, so please let me know if anyone sees any issue. Tested with mainline. Applies against mainline (3.9-rc4), HEAD at 46a1f21a679abaaeae6db9969963dc998c9f1c1c Applies against Takashi's for-next, HEAD at 4abdbd1c2c1832e7270e546307ffb3e56b286db2 Cheers, Eldad Zack (10): ALSA: usb-audio: convert list_for_each to entry variant ALSA: usb-audio: neaten MODULE_DEVICE_TABLE placement ALSA: usb-audio: neaten EXPORT_SYMBOLS placement ALSA: usb-audio: spelling correction ALSA: usb-audio: use endianness macros ALSA: usb-audio: UAC2: do clock validity check earlier ALSA: usb-audio: UAC2: try to find and switch to valid clock ALSA: usb-audio: UAC2: auto clock selection module param ALSA: usb-audio: show err in set_sample_rate_v2 debug ALSA: usb-audio: UAC2: support read-only freq control sound/usb/card.c | 11 ++-- sound/usb/clock.c | 150 ++++++++++++++++++++++++++++++++++++++------------- sound/usb/clock.h | 3 +- sound/usb/endpoint.c | 18 +++---- sound/usb/endpoint.h | 2 +- sound/usb/format.c | 2 +- sound/usb/midi.c | 12 ++--- sound/usb/pcm.c | 32 ++++------- sound/usb/proc.c | 7 ++- sound/usb/stream.c | 12 ++--- sound/usb/usbaudio.h | 1 + 11 files changed, 155 insertions(+), 95 deletions(-) -- 1.8.1.5

4 23

Re: [alsa-devel] Deadlock over semaphore issue with aplay while using dmix
by mateen 05 Apr '13

05 Apr '13

Hi, I checked with Takshi's patch and would like to suggest couple of changes. 1. We keep dmix_down_sem(dmix) and dmix_up_sem(dmix) as macros instead of defining them as functions. 2. We free up the semaphore in snd_pcm_dmix_close() if it is recognized that the semaphore is held up by the same process, which will be indicated by dmix->semlocked flag. Mateen. diff -Nuar dir2/pcm_direct.h dir1/pcm_direct.h --- dir2/pcm_direct.h 2009-12-16 20:48:51.000000000 +0530 +++ dir1/pcm_direct.h 2013-04-05 17:06:48.331497000 +0530 @@ -123,6 +123,7 @@ int ipc_gid; /* IPC socket gid */ int semid; /* IPC global semaphore identification */ int shmid; /* IPC global shared memory identification */ + int semlocked; snd_pcm_direct_share_t *shmptr; /* pointer to shared memory area */ snd_pcm_t *spcm; /* slave PCM handle */ snd_pcm_uframes_t appl_ptr; diff -Nuar dir2/pcm_dmix.c dir1/pcm_dmix.c --- dir2/pcm_dmix.c 2009-12-16 20:48:51.000000000 +0530 +++ dir1/pcm_dmix.c 2013-04-05 17:04:02.781109000 +0530 @@ -285,8 +285,17 @@ */ #ifndef DOC_HIDDEN #ifdef NO_CONCURRENT_ACCESS -#define dmix_down_sem(dmix) snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT) -#define dmix_up_sem(dmix) snd_pcm_direct_semaphore_up(dmix, DIRECT_IPC_SEM_CLIENT) +#define dmix_down_sem(dmix) \ +{\ +if (!dmix->semlocked++)\ + snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT);\ +} +#define dmix_up_sem(dmix) \ +{\ + if (!--dmix->semlocked)\ + snd_pcm_direct_semaphore_up(dmix, DIRECT_IPC_SEM_CLIENT);\ +} + #else #define dmix_down_sem(dmix) #define dmix_up_sem(dmix) @@ -764,7 +773,13 @@ if (dmix->timer) snd_timer_close(dmix->timer); - snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT); + if(!dmix->semlocked) + snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT); + else{ + snd_pcm_direct_semaphore_up(dmix, DIRECT_IPC_SEM_CLIENT); + snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT); + } + snd_pcm_close(dmix->spcm); if (dmix->server) snd_pcm_direct_server_discard(dmix); ------------------------------ ---------------------------------------- Message: 1 Date: Thu, 04 Apr 2013 18:30:01 +0200 From: Takashi Iwai <tiwai(a)suse.de> To: Jaroslav Kysela <perex(a)perex.cz> Cc: alsa-devel(a)alsa-project.org Subject: Re: [alsa-devel] Deadlock over semaphore issue with aplay while using dmix Message-ID: <s5h38v645ti.wl%tiwai(a)suse.de> Content-Type: text/plain; charset=US-ASCII At Thu, 04 Apr 2013 13:33:08 +0200, Jaroslav Kysela wrote: > > Date 4.4.2013 11:27, mateen wrote: > > Hi, > > > > I seeing sometimes deadlock issue with dmix when I press CTRL+C. > > > > Aplay's signal handler calls snd_pcm_close() if an interrupt occurs. > > snd_pcm_close() will internally call pcm->ops->close() which will fall to > > snd_pcm_dmix_close() in case you are using dmix. > > > > snd_pcm_dmix_close() will try to acquire the semaphore with > > snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT). > > The same semaphore is acquired in snd_pcm_dmix_sync_area() with > > dmix_down_sem() in case of non-concurrent access. > > > > If semaphore is acquired in snd_pcm_dmix_sync_area() which is in thread > > context and interrupt comes, which invokes the signal handler which is in > > ISR context, which calls snd_pcm_close() which in turn calls > > snd_pcm_dmix_close() then we see a deadlock since semaphore is not released > > from thread context and ISR is waiting indefinitely on the same semaphore. > > > > Please suggest a suitable solution for this. > > It seems that also other configurations (alsa-lib plugins) have trouble > with the closing from the signal handler - I hit mutex issues with the > PulseAudio plugin, too. > > The question is, how we can do a clean path in this case. Looking to the > current alsa-lib code, I would suggest to add the snd_pcm_abort() > function (may be called from the interrupt handler) to notify the > library to not ignore -EINTR return codes from poll() and other i/o ops > and pass it to the caller (application) to finish the normal close sequence. > > Opinions? Isn't it only about the direct plugins with the case where no coherent memory is available? If so, we may just avoid the deadlock by checking some internal flag like the patch below (untested)? It's no perfect but just some proof, of course. Takashi -- Regards, Shaikh Mateen S. 09423350444

2 2

[alsa-devel] Deadlock over semaphore issue with aplay while using dmix
by mateen 05 Apr '13

05 Apr '13

Hi, I seeing sometimes deadlock issue with dmix when I press CTRL+C. Aplay's signal handler calls snd_pcm_close() if an interrupt occurs. snd_pcm_close() will internally call pcm->ops->close() which will fall to snd_pcm_dmix_close() in case you are using dmix. snd_pcm_dmix_close() will try to acquire the semaphore with snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT). The same semaphore is acquired in snd_pcm_dmix_sync_area() with dmix_down_sem() in case of non-concurrent access. If semaphore is acquired in snd_pcm_dmix_sync_area() which is in thread context and interrupt comes, which invokes the signal handler which is in ISR context, which calls snd_pcm_close() which in turn calls snd_pcm_dmix_close() then we see a deadlock since semaphore is not released from thread context and ISR is waiting indefinitely on the same semaphore. Please suggest a suitable solution for this. -- Regards, Shaikh Mateen S. 09423350444

3 6

[alsa-devel] [PATCH v6 1/2] ALSA: ASoC: davinci-mcasp: don't configure AFSX direction in DIT mode
by yegorslists＠googlemail.com 05 Apr '13

05 Apr '13

From: Yegor Yefremov <yegorslists(a)googlemail.com> AFSX won't be used in DIT mode. The related pins are AHCLKX and the data pins. Signed-off-by: Yegor Yefremov <yegorslists(a)googlemail.com> Acked-by: Vaibhav Bedia <vaibhav.bedia(a)ti.com> Tested-by: Daniel Mack <zonque(a)gmail.com> --- v6: CC Mark Brown v5: add Daniel's Tested-by v4: change subjuct to include "ALSA: ASoC: " sound/soc/davinci/davinci-mcasp.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 9321e5c..90a9b99 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -772,9 +772,6 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream) /* S/PDIF */ static void davinci_hw_dit_param(struct davinci_audio_dev *dev) { - /* Set the PDIR for Serialiser as output */ - mcasp_set_bits(dev->base + DAVINCI_MCASP_PDIR_REG, AFSX); - /* TXMASK for 24 bits */ mcasp_set_reg(dev->base + DAVINCI_MCASP_TXMASK_REG, 0x00FFFFFF); -- 1.7.7

2 2

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Daniel Mack 05 Apr '13

05 Apr '13

Hi Andreas, On 28.03.2013 05:58, Andreas Koch wrote: >> Am I right to assume that in your case it's the same as for DoP, >> IOW, oldest in MSB? > > Good point - thanks for bringing it up - another can of worms. > With Windows having a little endian philosophy we started early on > with the first DSD workstation by putting the oldest sample in the > LSB position. ASIO came along and adopted the same thing, but then > extended support for the opposite as well. Rigisystems (offering OEM > modules for USB audio) came along about a year ago and insisted that > there is only their way, i.e. putting the oldest bit in the MSB > position. I tried to explain to them that there are already hundreds > of products out in the market that do it differently, but that didn't > matter to them. The result is that now we have implementations with > both. Up until now that was not a huge issue, because there is no > generic Windows driver and every hardware manufacturer had to have a > custom driver. > Now of course, with your heroic effort in creating a generic driver > that would help everyone, we have a mess. Some DACs expect little > endian (mine and others as well) and others (all that are based on > Rigisystems modules) big endian positions. > > Since the time I had the discussions with Rigisystems I didn't have > any further communication with them. Maybe it is a good idea to touch > base with them again and find out what the latest is. I will try my > contact there and let you know. Did you hear back from them yet? Do you think we should allocate types for Big Endian DOP formats? Thanks, Daniel

1 0

[alsa-devel] [PATCH] pcm: fix typo, should be SND_PCM_STATE_PREPARED.
by dsvensson＠gmail.com 05 Apr '13

05 Apr '13

From: Daniel Svensson <dsvensson(a)gmail.com> Signed-off-by: Daniel Svensson <dsvensson(a)gmail.com> --- src/pcm/pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 05737d9..0868dd5 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -162,7 +162,7 @@ The PCM device has accepted communication parameters and it is waiting for #snd_pcm_prepare() call to prepare the hardware for selected operation (playback or capture). -\par SND_PCM_STATE_PREPARE +\par SND_PCM_STATE_PREPARED The PCM device is prepared for operation. Application can use #snd_pcm_start() call, write or read data to start the operation. -- 1.7.12.4 (Apple Git-37)

2 1

[alsa-devel] [PATCH] ALSA: hda/cirrus - Add a quirk for Stumpy ChromeBox.
by Dylan Reid 05 Apr '13

05 Apr '13

The Stumpy ChromeBox needs its pin configs fixed up. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/pci/hda/patch_cirrus.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index 0d9c58f..bd8d46c 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -68,6 +68,7 @@ enum { enum { CS421X_CDB4210, CS421X_SENSE_B, + CS421X_STUMPY, }; /* Vendor-specific processing widget */ @@ -538,6 +539,7 @@ static int patch_cs420x(struct hda_codec *codec) /* CS4210 board names */ static const struct hda_model_fixup cs421x_models[] = { { .id = CS421X_CDB4210, .name = "cdb4210" }, + { .id = CS421X_STUMPY, .name = "stumpy" }, {} }; @@ -559,6 +561,17 @@ static const struct hda_pintbl cdb4210_pincfgs[] = { {} /* terminator */ }; +/* Stumpy ChromeBox */ +static const struct hda_pintbl stumpy_pincfgs[] = { + { 0x05, 0x022120f0 }, + { 0x06, 0x901700f0 }, + { 0x07, 0x02a120f0 }, + { 0x08, 0x77a70037 }, + { 0x09, 0x77a6003e }, + { 0x0a, 0x434510f0 }, + {} /* terminator */ +}; + /* Setup GPIO/SENSE for each board (if used) */ static void cs421x_fixup_sense_b(struct hda_codec *codec, const struct hda_fixup *fix, int action) @@ -578,7 +591,11 @@ static const struct hda_fixup cs421x_fixups[] = { [CS421X_SENSE_B] = { .type = HDA_FIXUP_FUNC, .v.func = cs421x_fixup_sense_b, - } + }, + [CS421X_STUMPY] = { + .type = HDA_FIXUP_PINS, + .v.pins = stumpy_pincfgs, + }, }; static const struct hda_verb cs421x_coef_init_verbs[] = { -- 1.8.1.3.605.g02339dd

2 1

[alsa-devel] [PATCH 1/2] ALSA: hda - Add fixed codec delay to runtime delay.
by Dylan Reid 05 Apr '13

05 Apr '13

Allow a codec to specify a delay in addition to the delay before samples are passed through DMA. Some codecs have large processing delays because of built-in DSPs that require codec-side buffers of many milliseconds. Default to zero delay if the codec doesn't specify a callback to get the processing delay. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/pci/hda/hda_codec.c | 17 +++++++++++++++++ sound/pci/hda/hda_codec.h | 4 ++++ sound/pci/hda/hda_intel.c | 2 ++ 3 files changed, 23 insertions(+) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 17286b3..1d792dd 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3724,6 +3724,23 @@ void snd_hda_codec_set_power_to_all(struct hda_codec *codec, hda_nid_t fg, } EXPORT_SYMBOL_HDA(snd_hda_codec_set_power_to_all); +/** + * snd_hda_codec_processing_delay - get the fixed delay through the codec + * @codec: HD-audio codec + * @stream: playback or capture + * + * This is needed for codecs that contain DSPs that cause long delays. + */ +unsigned int snd_hda_codec_processing_delay(struct hda_codec *codec, + unsigned int stream) +{ + if (codec->patch_ops.get_processing_delay) + return codec->patch_ops.get_processing_delay(codec, stream); + + return 0; +} +EXPORT_SYMBOL_HDA(snd_hda_codec_processing_delay); + /* * supported power states check */ diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 23ca172..23bd1e7 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -725,6 +725,8 @@ struct hda_codec_ops { int (*check_power_status)(struct hda_codec *codec, hda_nid_t nid); #endif void (*reboot_notify)(struct hda_codec *codec); + unsigned int (*get_processing_delay)(struct hda_codec *codec, + unsigned int stream); }; /* record for amp information cache */ @@ -1063,6 +1065,8 @@ void snd_hda_get_codec_name(struct hda_codec *codec, char *name, int namelen); void snd_hda_bus_reboot_notify(struct hda_bus *bus); void snd_hda_codec_set_power_to_all(struct hda_codec *codec, hda_nid_t fg, unsigned int power_state); +unsigned int snd_hda_codec_processing_delay(struct hda_codec *codec, + unsigned int stream); int snd_hda_lock_devices(struct hda_bus *bus); void snd_hda_unlock_devices(struct hda_bus *bus); diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 418bfc0..422bfaf 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2349,6 +2349,7 @@ static unsigned int azx_get_position(struct azx *chip, struct azx_dev *azx_dev, bool with_check) { + struct azx_pcm *apcm = snd_pcm_substream_chip(azx_dev->substream); unsigned int pos; int stream = azx_dev->substream->stream; int delay = 0; @@ -2400,6 +2401,7 @@ static unsigned int azx_get_position(struct azx *chip, chip->driver_caps &= ~AZX_DCAPS_COUNT_LPIB_DELAY; } azx_dev->substream->runtime->delay = + snd_hda_codec_processing_delay(apcm->codec, stream) + bytes_to_frames(azx_dev->substream->runtime, delay); } trace_azx_get_position(chip, azx_dev, pos, delay); -- 1.8.1.5

2 5

[alsa-devel] Handle large period size end-of-stream situation
by Patrick Lai 04 Apr '13

04 Apr '13

Hi, I am dealing with a use case requiring passing large buffer down to the DSP. Application in the user-space passes PCM through mmap interface. Per my understanding, ALSA is designed to work with DMA. Data is transferred in chunk equal to period size. At the end of playback, there may not be enough audio data left in the music stream to fill entire period. If remaining audio data only takes up very small chunk of period, playback takes longer to stop. Given that period size I have to deal with is quite large, this problem is observed easily. If my understanding is correct, what is the standard/recommended way of handling end of stream case? Thanks Patrick -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

3 6

[alsa-devel] [PATCH v5 1/2] ALSA: ASoC: davinci-mcasp: don't configure AFSX direction in DIT mode
by yegorslists＠googlemail.com 04 Apr '13

04 Apr '13

From: Yegor Yefremov <yegorslists(a)googlemail.com> AFSX won't be used in DIT mode. The related pins are AHCLKX and the data pins. Signed-off-by: Yegor Yefremov <yegorslists(a)googlemail.com> Acked-by: Vaibhav Bedia <vaibhav.bedia(a)ti.com> Tested-by: Daniel Mack <zonque(a)gmail.com> --- v5: add Daniel's Tested-by v4: change subjuct to include "ALSA: ASoC: " sound/soc/davinci/davinci-mcasp.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 9321e5c..90a9b99 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -772,9 +772,6 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream) /* S/PDIF */ static void davinci_hw_dit_param(struct davinci_audio_dev *dev) { - /* Set the PDIR for Serialiser as output */ - mcasp_set_bits(dev->base + DAVINCI_MCASP_PDIR_REG, AFSX); - /* TXMASK for 24 bits */ mcasp_set_reg(dev->base + DAVINCI_MCASP_TXMASK_REG, 0x00FFFFFF); -- 1.7.7

3 6

[alsa-devel] ASoC: BeagleBoard driver development (PCM3168)
by Wendelin Klimann 04 Apr '13

04 Apr '13

Hello Peter I am stuck again in my ASoc driver development and it would be really nice if you could give me an hint how i could solve this. Acctually i try to connect my PCM3168 Audio Codec to the McBSP on the BeagleBoard. My new driver loads fine and i got 2 soundcards: *root@beagleboard:/lib/modules/3.7.4+/kernel/sound/soc/omap# aplay -l* **** List of PLAYBACK Hardware Devices **** card 0: omap3beagle [omap3beagle], device 0: TWL4030 twl4030-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: pcm3168 [pcm3168], device 0: PCM3168 pcm3168-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 Your TWL4030 driver is still working perfect with: *root@beagleboard:/lib/modules/3.7.4+/kernel/sound/soc/omap# aplay -Dhw:0,0 /home/root/fifi.wav* [ 1245.302551] omap-dma-engine omap-dma-engine: allocating channel for 33 Playing WAVE '/home/root/fifi.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo but when i play the same file with my new driver i get an error (as codec master and also as codec slave): *root@beagleboard:/lib/modules/3.7.4+/kernel/sound/soc/omap# aplay -Dhw:1,0 /home/root/fifi.wav* [ 1128.677337] omap-dma-engine omap-dma-engine: allocating channel for 17 Playing WAVE '/h[ 1128.689544] can't set codec DAI configuration - pcm3168 ome/root/fifi.wa[ 1128.695281] asoc: machine hw_params failed: -524 v' : Signed 16 b[ 1128.702514] omap-dma-engine omap-dma-engine: freeing channel for 17 it Little Endian, Rate 44100 Hz, Stereo aplay: set_params:1145: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (124988 124989) PERIOD_SIZE: 5512 PERIOD_BYTES: 22048 PERIODS: 5 BUFFER_TIME: (624943 624944) BUFFER_SIZE: 27560 BUFFER_BYTES: 110240 TICK_TIME: 0 To check whether my machine driver (/omap-pcm3168.c/) is working i tried to implement the /twl4030.c/ codec driver into it (and deactivated the omap_twl4030_audio_init() function), which worked just fine. With this setup i changed the /.cpu_dai_name = "omap-mcbsp.2"/ to /.cpu_dai_name = "omap-mcbsp.3"/ and i adjusted the codec as slave (/SND_SOC_DAIFMT_CBS_CFS/) to test whether the McBSP3 setup is right (the PCM3168 codec was disconnected). I still got a clock signal on the McBSP2 but the McBSP2_DX had no signal anymore and on the McBSP3 i did not get any signal at all (measured with an osziloscope). I am a little bit confused as i am not shure why there is still the clk signal on the McBSP2 and furthermore i am not shure whether i test the McBSP3 properly or whether there is a proplem in the McBSP3 setup. The PinMUX for the McBSP3 is done in the kernel (/board-omap3beagle.c/) by setting: static void __init omap3_beagle_config_mcbsp3_mux(void) { omap_mux_init_signal("mcbsp3_fsx.mcbsp3_fsx", OMAP_PIN_INPUT); omap_mux_init_signal("uart2_cts.mcbsp3_dx", OMAP_PIN_OUTPUT); omap_mux_init_signal("uart2_rts.mcbsp3_dr", OMAP_PIN_INPUT); /* NOTE: Clock pins need to be in input mode */ omap_mux_init_signal("uart2_tx.mcbsp3_clkx", OMAP_PIN_INPUT); } It would be really nice if you could help me. Thanks Wendelin ****************************************************************************************************** * kernel_3.7.4+/sound/soc/omap/omap-pcm3168.c * ****************************************************************************************************** /* * PCM3168 ASoC driver for BeagleBoard. * * based on: * > omap3beagle.c -- SoC audio for OMAP3 Beagle * > Author: Steve Sakoman <steve(a)sakoman.com> * * adapted by Klimann Wendelin <wklimann(a)hotmail.com> * * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA * */ #include <linux/clk.h> #include <linux/platform_device.h> #include <linux/module.h> #include <sound/core.h> #include <sound/pcm.h> #include <sound/soc.h> #include <sound/pcm_params.h> #include <asm/mach-types.h> #include <mach/hardware.h> #include <mach/gpio.h> //#include <plat/mcbsp.h> #include "omap-mcbsp.h" #include "omap-pcm.h" /* * Uncomment to test codec in slave mode or without actual codec. This makes * possible to test this driver by letting the OMAP to be DAI link master */ #define PCM3168_CODEC_SLAVE 1 static int pcm3168_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *codec_dai = rtd->codec_dai; struct snd_soc_dai *cpu_dai = rtd->cpu_dai; unsigned int fmt, div; int ret; #ifdef PCM3168_CODEC_SLAVE fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBS_CFS | SND_SOC_DAIFMT_IB_NF; #else fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF; #endif /* Set codec DAI configuration */ ret = snd_soc_dai_set_fmt(codec_dai, fmt); if (ret < 0) { printk(KERN_ERR "can't set codec DAI configuration - pcm3168\n"); return ret; } /* Set cpu DAI configuration */ ret = snd_soc_dai_set_fmt(cpu_dai, fmt); if (ret < 0) { printk(KERN_ERR "can't set cpu DAI configuration - pcm3168\n"); return ret; } #ifdef PCM3168_CODEC_SLAVE ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK, 48000000, SND_SOC_CLOCK_IN); if (ret < 0) { pr_err("can't set McBSP sysclk - pcm3168\n"); return ret; } /* * Calculate McBSP SRG divisor in McBSP master mode */ div = 48000000 / params_rate(params) / params_channels(params); switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: div /= 16; break; case SNDRV_PCM_FORMAT_S24_LE: case SNDRV_PCM_FORMAT_S32_LE: div /= 32; break; }; /* * Round to maximum divisor if needed. This means that extra bit-clock * cycles are transmitted when sample rate and number of bits in frame * (channels * sample bits) are low. */ if (div >= 256) div = 256; ret = snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, div); if (ret < 0) { pr_err("can't set SRG clock divider - pcm3168\n"); return ret; } #endif return 0; } static struct snd_soc_ops pcm3168_ops = { .hw_params = pcm3168_hw_params, }; /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link pcm3168_dai = { .name = "PCM3168", .stream_name = "PCM3168", .cpu_dai_name = "omap-mcbsp.3", .platform_name = "omap-pcm-audio", .codec_dai_name = "pcm3168-hifi", .codec_name = "pcm3168-codec.0", .ops = &pcm3168_ops, }; /* Audio machine driver */ static struct snd_soc_card snd_soc_pcm3168 = { .name = "pcm3168", .owner = THIS_MODULE, .dai_link = &pcm3168_dai, .num_links = 1, }; struct platform_device pcm3168_codec = { .name = "pcm3168-codec", .id = 0, }; struct platform_device pcm3168_soc_audio = { .name = "pcm3168-soc-audio", .id = 0, }; static int __devinit pcm3168_soc_probe(struct platform_device *pdev) { struct snd_soc_card *card = &snd_soc_pcm3168; int ret; pr_info("OMAP3 Beagle - PCM3168 ASoC init\n"); card->dev = &pdev->dev; ret = snd_soc_register_card(card); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card() failed: %d - pcm3168\n", ret); return ret; } return 0; } static int __devexit pcm3168_soc_remove(struct platform_device *pdev) { struct snd_soc_card *card = platform_get_drvdata(pdev); snd_soc_unregister_card(card); return 0; } static struct platform_driver pcm3168_driver = { .driver = { .name = "pcm3168-soc-audio", .owner = THIS_MODULE, }, .probe = pcm3168_soc_probe, .remove = __devexit_p(pcm3168_soc_remove), }; static int __init pcm3168_soc_init(void) { platform_device_register(&pcm3168_codec); platform_device_register(&pcm3168_soc_audio); return platform_driver_register(&pcm3168_driver); } module_init(pcm3168_soc_init); static void __exit pcm3168_soc_exit(void) { platform_driver_unregister(&pcm3168_driver); platform_device_unregister(&pcm3168_soc_audio); platform_device_unregister(&pcm3168_codec); } module_exit(pcm3168_soc_exit); MODULE_AUTHOR("Klimann Wendelin <wklimann(a)hotmail.com>"); MODULE_DESCRIPTION("ALSA SoC PCM3168 add on Soundcard"); MODULE_LICENSE("GPL"); MODULE_ALIAS("platform:pcm3168-soc-audio"); ****************************************************************************************************** * kernel_3.7.4+/sound/soc/codecs/pcm3168.c * ****************************************************************************************************** /* * ALSA Soc PCM3168 codec support * * Author: Klimann Wendelin <wklimann(a)hotmail.com> * * based on: * > pcm3008.c * > Author: Hugo Villeneuve * > Copyright (C) 2008 Lyrtech inc * > * > Based on AC97 Soc codec, original copyright follow: * > Copyright 2005 Wolfson Microelectronics PLC. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA */ #include <linux/init.h> #include <linux/kernel.h> #include <linux/device.h> #include <linux/gpio.h> #include <linux/slab.h> #include <linux/module.h> #include <linux/clk.h> #include <linux/platform_device.h> #include <linux/module.h> #include <sound/core.h> #include <sound/initval.h> #include <sound/pcm.h> #include <sound/pcm_params.h> //#include <sound/soc-dapm.h> #include <sound/soc.h> #include <asm/mach-types.h> #include <mach/hardware.h> #include <mach/gpio.h> //#include <plat/mcbsp.h> #include "../omap/omap-mcbsp.h" #include "../omap/omap-pcm.h" #include "pcm3168.h" #define PCM3168_VERSION "0.1" #define PCM3168_RATES SNDRV_PCM_RATE_8000_96000 /*(SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \ SNDRV_PCM_RATE_48000)*/ #define PCM3168_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE) static struct snd_soc_dai_driver pcm3168_dai = { .name = "pcm3168-hifi", .playback = { .stream_name = "PCM3168 Playback", .channels_min = 2, .channels_max = 8, .rates = PCM3168_RATES, .formats = PCM3168_FORMATS, //SNDRV_PCM_FMTBIT_S16_LE, //SNDRV_PCM_FMTBIT_S32_LE .sig_bits = 24, }, .capture = { .stream_name = "PCM3168 Capture", .channels_min = 2, .channels_max = 6, .rates = PCM3168_RATES, .formats = PCM3168_FORMATS, //SNDRV_PCM_FMTBIT_S16_LE, //SNDRV_PCM_FMTBIT_S32_LE .sig_bits = 24, }, }; static void pcm3168_gpio_free(struct pcm3168_setup_data *setup) { // gpio_free(setup->dem0_pin); // gpio_free(setup->dem1_pin); // gpio_free(setup->pdad_pin); // gpio_free(setup->pdda_pin); } static int pcm3168_soc_probe(struct snd_soc_codec *codec) { struct pcm3168_setup_data *setup = codec->dev->platform_data; int ret = 0; printk(KERN_ALERT "in SOC Probe codec -> kli \n"); printk(KERN_INFO "PCM3168 SoC Audio Codec %s\n", PCM3168_VERSION); return ret; gpio_err: // pcm3168_gpio_free(setup); return ret; } static int pcm3168_soc_remove(struct snd_soc_codec *codec) { struct pcm3168_setup_data *setup = codec->dev->platform_data; // pcm3168_gpio_free(setup); return 0; } #define pcm3168_soc_suspend NULL #define pcm3168_soc_resume NULL static struct snd_soc_codec_driver soc_codec_dev_pcm3168 = { .probe = pcm3168_soc_probe, .remove = pcm3168_soc_remove, .suspend = pcm3168_soc_suspend, .resume = pcm3168_soc_resume, }; static int __devinit pcm3168_codec_probe(struct platform_device *pdev) { int ret; printk(KERN_ALERT "probe pcm3168 codec -> kli \n"); ret = snd_soc_register_codec(&pdev->dev, &soc_codec_dev_pcm3168, &pcm3168_dai, 1); printk(KERN_ALERT "probe_after pcm3168 codec -> kli = %d \n", ret); return ret; } static int __devexit pcm3168_codec_remove(struct platform_device *pdev) { printk(KERN_ALERT "remove pcm3168 codec -> kli \n"); snd_soc_unregister_codec(&pdev->dev); return 0; } MODULE_ALIAS("platform:pcm3168-codec"); static struct platform_driver pcm3168_codec_driver = { .probe = pcm3168_codec_probe, .remove = __devexit_p(pcm3168_codec_remove), .driver = { .name = "pcm3168-codec", .owner = THIS_MODULE, }, }; static int __init pcm3168_modinit(void) { printk(KERN_ALERT "in init of 3168 -> kli \n"); return platform_driver_register(&pcm3168_codec_driver); } module_init(pcm3168_modinit); static void __exit pcm3168_exit(void) { printk(KERN_ALERT "in exit of 3168 -> kli \n"); platform_driver_unregister(&pcm3168_codec_driver); } module_exit(pcm3168_exit); MODULE_DESCRIPTION("Soc PCM3168 driver"); MODULE_AUTHOR("Klimann Wendelin <wklimann(a)hotmail.com>"); MODULE_LICENSE("GPL");

2 5

[alsa-devel] [PATCH] ALSA: hda - fix typo in proc output
by David Henningsson 04 Apr '13

04 Apr '13

Rename "Digitial In" to "Digital In". This function is only used for proc output, so should not cause any problems to change. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/hda_codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 17286b3..e37b738 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -173,7 +173,7 @@ const char *snd_hda_get_jack_type(u32 cfg) "Line Out", "Speaker", "HP Out", "CD", "SPDIF Out", "Digital Out", "Modem Line", "Modem Hand", "Line In", "Aux", "Mic", "Telephony", - "SPDIF In", "Digitial In", "Reserved", "Other" + "SPDIF In", "Digital In", "Reserved", "Other" }; return jack_types[(cfg & AC_DEFCFG_DEVICE) -- 1.7.9.5

2 1

[alsa-devel] [PATCHv2 00/10] UAC2: Automatic clock switching
by Eldad Zack 04 Apr '13

04 Apr '13

This is version 2 of the automatic clock switching. v1: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-March/060734.html No patches added or removed. Rebased patches with "ALSA: usb: Work around CM6631 sample rate change bug", commit 690a863ff03d9a29ace2b752b8f802fba78a842f . Clemens, Takashi and Torstein, thank you very much for reviewing and providing comments! Changes: * Fixed formatting * (#5) Fixed type cast: u32 -> __l32 * (#6) Added rational to commit message * (#7) Fixed assignment of int to unsigned char, return error code if encountered * (#8) Fixed the parameter name, annotated the default value * (#10) Avoid second read of frequency for read-only clocks Tested with Takashi's for-next. Applies against Takashi's for-next HEAD efc33ce197e4b6aaddf1eb2ba6293f51daf3c283 . Cheers, Eldad Zack (10): ALSA: usb-audio: convert list_for_each to entry variant ALSA: usb-audio: neaten MODULE_DEVICE_TABLE placement ALSA: usb-audio: neaten EXPORT_SYMBOLS placement ALSA: usb-audio: spelling correction ALSA: usb-audio: use endianness macros ALSA: usb-audio: UAC2: do clock validity check earlier ALSA: usb-audio: UAC2: try to find and switch to valid clock ALSA: usb-audio: UAC2: auto clock selection module param ALSA: usb-audio: show err in set_sample_rate_v2 debug ALSA: usb-audio: UAC2: support read-only freq control sound/usb/card.c | 11 ++-- sound/usb/clock.c | 153 ++++++++++++++++++++++++++++++++++++++------------- sound/usb/clock.h | 3 +- sound/usb/endpoint.c | 18 +++--- sound/usb/endpoint.h | 2 +- sound/usb/format.c | 2 +- sound/usb/midi.c | 12 ++-- sound/usb/pcm.c | 32 ++++------- sound/usb/proc.c | 7 +-- sound/usb/stream.c | 12 ++-- sound/usb/usbaudio.h | 1 + 11 files changed, 157 insertions(+), 96 deletions(-) -- 1.8.1.5

2 11

[alsa-devel] [PATCH] Enabling Realtek ALC 671 codec
by Rainer Koenig 04 Apr '13

04 Apr '13

Changes: * Added the device ID to the modalias list and assinged ALC662 patches for it * Added 4 port support for the device ID 0671 in alc662_parse_auto_config Signed-off-by: Rainer Koenig <Rainer.Koenig(a)ts.fujitsu.com> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 7743775..fcbf4c9 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6663,7 +6663,8 @@ static int alc662_parse_auto_config(struct hda_codec *codec) const hda_nid_t *ssids; if (codec->vendor_id == 0x10ec0272 || codec->vendor_id == 0x10ec0663 || - codec->vendor_id == 0x10ec0665 || codec->vendor_id == 0x10ec0670) + codec->vendor_id == 0x10ec0665 || codec->vendor_id == 0x10ec0670 || + codec->vendor_id == 0x10ec0671) ssids = alc663_ssids; else ssids = alc662_ssids; @@ -7115,6 +7116,7 @@ static const struct hda_codec_preset snd_hda_preset_realtek[] = { { .id = 0x10ec0665, .name = "ALC665", .patch = patch_alc662 }, { .id = 0x10ec0668, .name = "ALC668", .patch = patch_alc662 }, { .id = 0x10ec0670, .name = "ALC670", .patch = patch_alc662 }, + { .id = 0x10ec0671, .name = "ALC671", .patch = patch_alc662 }, { .id = 0x10ec0680, .name = "ALC680", .patch = patch_alc680 }, { .id = 0x10ec0880, .name = "ALC880", .patch = patch_alc880 }, { .id = 0x10ec0882, .name = "ALC882", .patch = patch_alc882 }, -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig@ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html

2 1

[alsa-devel] How to use implicit feedback with full duplex?
by Clemens Ladisch 04 Apr '13

04 Apr '13

Hi, I thought I'd try to use implicit feedback with my simple audio device: Interface Descriptor: bInterfaceNumber 1 bAlternateSetting 0 Interface Descriptor: bInterfaceNumber 1 bAlternateSetting 1 AudioStreaming Interface Descriptor: ... Endpoint Descriptor: bEndpointAddress 0x01 EP 1 OUT Interface Descriptor: bInterfaceNumber 2 bAlternateSetting 0 Interface Descriptor: bInterfaceNumber 2 bAlternateSetting 1 AudioStreaming Interface Descriptor: ... Endpoint Descriptor: bEndpointAddress 0x82 EP 2 IN So I wrote a patch to configure it like those M-Audio devices: --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -391,6 +391,17 @@ static int set_format(struct snd_usb_substream *subs, struct audioformat *fmt) attr = fmt->ep_attr & USB_ENDPOINT_SYNCTYPE; switch (subs->stream->chip->usb_id) { + case USB_ID(0x0582, 0x0018): + if (is_playback) { + implicit_fb = 1; + ep = 0x82; + iface = usb_ifnum_to_if(dev, 2); + if (!iface || iface->num_altsetting < 2) + return -EINVAL; + alts = &iface->altsetting[1]; + goto add_sync_ep; + } + break; case USB_ID(0x0763, 0x2030): /* M-Audio Fast Track C400 */ if (is_playback) { implicit_fb = 1; This works fine when playing something: kernel: setting usb interface 1:1 kernel: Creating new playback data endpoint #1 kernel: Creating new capture data endpoint #82 kernel: Setting params for ep #1 (type 0, 8 urbs), ret=0 kernel: match_endpoint_audioformats: (fmt @ffff8801fefa8900) score 2 kernel: Setting params for ep #82 (type 0, 8 urbs), ret=0 kernel: Starting data EP @ffff8801fd4e8000 kernel: Starting sync EP @ffff8801fd2ac000 But when I then try to record at the same time, the driver refuses to configure the input endpoint (to the only format, which is already set): kernel: setting usb interface 2:1 kernel: Re-using EP 82 in iface 2,1 @ffff8801fd2ac000 kernel: Unable to change format on ep #82: already in use And despite that "alreay in use" check, the input endpoint is affected so much that playback breaks. Is full duplex supposed to work? Does it work with other devices? Regards, Clemens

5 11

[alsa-devel] [PATCH v5] ALSA: usb: Work around CM6631 sample rate change bug
by Torstein Hegge 03 Apr '13

03 Apr '13

The C-Media CM6631 USB receiver doesn't respond to changes in sample rate while the interface is active. The same behavior is observed in other UAC2 hardware like the VIA VT1731. Reset the interface after setting the sampling frequency on sample rate changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous stream, causing distorted sound on sample rate changes. The reset is performed for all UAC2 devices, as it should not affect a standards compliant device, but it is only necessary for C-Media CM6631, VIA VT1731 and possibly others. Failure to read sample rate from the device is not handled as an error in set_sample_rate_v2(), as (permanent or intermittent) failure to read sample rate isn't essential for a successful sample rate set. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- Changes since v4: - Sample rate read failure is no longer fatal. Failure to read sample rate from the device is degraded from a fatal error to a warning message. The Schiit Bifrost has shown intermittent sample rate read failures, and this shouldn't be a reason to abort the initialization. - The reset is performed for all UAC2 devices. The number of devices affected by this issue seems to be larger than just the C-Media based devices, issues with the VIA VT1731 has been reported by Davor Herga to alsa-user [1]. The additional reset should not affect standards compliant devices and will hopefully improve the compatibility with future devices tested with the OS X UAC2 driver. This can cause problems for a theoretical device where sample rate read always fails, causing the reset to be performed every time the sample rate is set, *and* where repeated resets cause resume after pause to not resume properly, like the issues seen with CM6631 in the first iteration of this patch. [1] http://thread.gmane.org/gmane.linux.alsa.user/37312 Changes since v3: - Use given target rate instead of the new rate read from device when checking if a reset is needed. Some devices (at least Schiit Bifrost) doesn't report a reliable sample rate back right after setting a new rate. This appears to fix the issues with v3 of this patch with the Schiit, as reported by Chris Hermansen in http://thread.gmane.org/gmane.linux.alsa.user/36935/focus=37284 sound/usb/clock.c | 45 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 35 insertions(+), 10 deletions(-) diff --git a/sound/usb/clock.c b/sound/usb/clock.c index 5e634a2..9e2703a 100644 --- a/sound/usb/clock.c +++ b/sound/usb/clock.c @@ -253,7 +253,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, { struct usb_device *dev = chip->dev; unsigned char data[4]; - int err, crate; + int err, cur_rate, prev_rate; int clock = snd_usb_clock_find_source(chip, fmt->clock); if (clock < 0) @@ -266,6 +266,19 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return -ENXIO; } + err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, + USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, + UAC2_CS_CONTROL_SAM_FREQ << 8, + snd_usb_ctrl_intf(chip) | (clock << 8), + data, sizeof(data)); + if (err < 0) { + snd_printk(KERN_WARNING "%d:%d:%d: cannot get freq (v2)\n", + dev->devnum, iface, fmt->altsetting); + prev_rate = 0; + } else { + prev_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + } + data[0] = rate; data[1] = rate >> 8; data[2] = rate >> 16; @@ -280,19 +293,31 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return err; } - if ((err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, - USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, - UAC2_CS_CONTROL_SAM_FREQ << 8, - snd_usb_ctrl_intf(chip) | (clock << 8), - data, sizeof(data))) < 0) { + err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, + USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, + UAC2_CS_CONTROL_SAM_FREQ << 8, + snd_usb_ctrl_intf(chip) | (clock << 8), + data, sizeof(data)); + if (err < 0) { snd_printk(KERN_WARNING "%d:%d:%d: cannot get freq (v2)\n", dev->devnum, iface, fmt->altsetting); - return err; + cur_rate = 0; + } else { + cur_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); } - crate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); - if (crate != rate) - snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate); + if (cur_rate != rate) { + snd_printd(KERN_WARNING + "current rate %d is different from the runtime rate %d\n", + cur_rate, rate); + } + + /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + if (rate != prev_rate) { + usb_set_interface(dev, iface, 0); + usb_set_interface(dev, iface, fmt->altsetting); + } return 0; } -- 1.7.10.4

5 8

Re: [alsa-devel] [PATCH 1/2] ASoC: Samsung: return error if drvdata is not set
by Mark Brown 03 Apr '13

03 Apr '13

On Tue, Apr 02, 2013 at 04:53:01PM +0530, Padmavathi Venna wrote: > From: Prathyush K <prathyush.k(a)samsung.com> > > This patch fixes a possible crash in case drvdata for the secondary > device is not set. Applied both, thanks.

1 0

[alsa-devel] [PATCH] Enable Realtek ALC671 Codec
by Rainer Koenig 03 Apr '13

03 Apr '13

Hi, working on a new mainboard generation with ALC671 codecs the first tests showed that the generic codec parser is just configuring the rear mic in for audio input, line-in and front-mic are missing. I tried to understand the code of patch_realtek.c and after compiling with CONFIG_SND_DEBUG I saw that this module is not used at all for the ALC671 codec because its device-ID was missing. So what I did is: - adding the device id and assigned the ALC662 patches for it. - Added the device id so that it enables 4 ports in alc662_parse_auto_config - changed the conditional in alc_subsystem_id because it looked so strange to me when I tried to understand what is happening. :-) Here is the patch: Signed-off-by: Rainer Koenig <Rainer.Koenig(a)ts.fujitsu.com> --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1283,7 +1283,7 @@ static int alc_subsystem_id(struct hda_codec *codec, } ass = codec->subsystem_id & 0xffff; - if ((ass != codec->bus->pci->subsystem_device) && (ass & 1)) + if ((ass == codec->bus->pci->subsystem_device) && (ass & 1)) goto do_sku; /* invalid SSID, check the special NID pin defcfg instead */ @@ -6663,7 +6663,8 @@ static int alc662_parse_auto_config(struct hda_codec *codec) const hda_nid_t *ssids; if (codec->vendor_id == 0x10ec0272 || codec->vendor_id == 0x10ec0663 || - codec->vendor_id == 0x10ec0665 || codec->vendor_id == 0x10ec0670) + codec->vendor_id == 0x10ec0665 || codec->vendor_id == 0x10ec0670 || + codec->vendor_id == 0x10ec0671) ssids = alc663_ssids; else ssids = alc662_ssids; @@ -7115,6 +7116,7 @@ static const struct hda_codec_preset snd_hda_preset_realtek[] = { { .id = 0x10ec0665, .name = "ALC665", .patch = patch_alc662 }, { .id = 0x10ec0668, .name = "ALC668", .patch = patch_alc662 }, { .id = 0x10ec0670, .name = "ALC670", .patch = patch_alc662 }, + { .id = 0x10ec0671, .name = "ALC671", .patch = patch_alc662 }, { .id = 0x10ec0680, .name = "ALC680", .patch = patch_alc680 }, { .id = 0x10ec0880, .name = "ALC880", .patch = patch_alc880 }, { .id = 0x10ec0882, .name = "ALC882", .patch = patch_alc882 }, -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig@ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html

2 5

Re: [alsa-devel] [PATCH] sound: soc: tegra: do not provide PAUSE/RESUME in hardware info
by Lars-Peter Clausen 03 Apr '13

03 Apr '13

On 04/03/2013 11:19 AM, Laxman Dewangan wrote: > Tegra PCM driver uses the dmaengine based DMA driver and Tegra DMA > driver does not support the pause/resume functionality as hardware > does not support it. > > ALSA driver support the sw based pause/resume functionality if hardware > does not support it and in this case, hw driver should not provide > the hardware info with PAUSE/RESUME bit enable. > > Remmoving the SNDRV_PCM_INFO_PAUSE and SNDRV_PCM_INFO_RESUME from hardware > info and using the snd_dmaengine_pcm_trigger() for pcm_trigger callback. > > Signed-off-by: Laxman Dewangan <ldewangan(a)nvidia.com> Hm, I sent out the same patch just half an our or so ago. - Lars > --- > Lars reported that if driver/chip dma driver does not support the pause/resume > then need not to export this info through the hw capability and leave this > implementation to alsa driver. > > Making the change accordingly. > > sound/soc/tegra/tegra_pcm.c | 24 +----------------------- > 1 files changed, 1 insertions(+), 23 deletions(-) > > diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c > index e67af0b..117cccc 100644 > --- a/sound/soc/tegra/tegra_pcm.c > +++ b/sound/soc/tegra/tegra_pcm.c > @@ -43,8 +43,6 @@ > static const struct snd_pcm_hardware tegra_pcm_hardware = { > .info = SNDRV_PCM_INFO_MMAP | > SNDRV_PCM_INFO_MMAP_VALID | > - SNDRV_PCM_INFO_PAUSE | > - SNDRV_PCM_INFO_RESUME | > SNDRV_PCM_INFO_INTERLEAVED, > .formats = SNDRV_PCM_FMTBIT_S16_LE, > .channels_min = 2, > @@ -121,26 +119,6 @@ static int tegra_pcm_hw_free(struct snd_pcm_substream *substream) > return 0; > } > > -static int tegra_pcm_trigger(struct snd_pcm_substream *substream, int cmd) > -{ > - switch (cmd) { > - case SNDRV_PCM_TRIGGER_START: > - case SNDRV_PCM_TRIGGER_RESUME: > - case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: > - return snd_dmaengine_pcm_trigger(substream, > - SNDRV_PCM_TRIGGER_START); > - > - case SNDRV_PCM_TRIGGER_STOP: > - case SNDRV_PCM_TRIGGER_SUSPEND: > - case SNDRV_PCM_TRIGGER_PAUSE_PUSH: > - return snd_dmaengine_pcm_trigger(substream, > - SNDRV_PCM_TRIGGER_STOP); > - default: > - return -EINVAL; > - } > - return 0; > -} > - > static int tegra_pcm_mmap(struct snd_pcm_substream *substream, > struct vm_area_struct *vma) > { > @@ -158,7 +136,7 @@ static struct snd_pcm_ops tegra_pcm_ops = { > .ioctl = snd_pcm_lib_ioctl, > .hw_params = tegra_pcm_hw_params, > .hw_free = tegra_pcm_hw_free, > - .trigger = tegra_pcm_trigger, > + .trigger = snd_dmaengine_pcm_trigger, > .pointer = snd_dmaengine_pcm_pointer, > .mmap = tegra_pcm_mmap, > };

1 0

[alsa-devel] [PATCH] salsa-lib: Add seq_midi_event.h
by Mihail Zenkov 03 Apr '13

03 Apr '13

--- salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884/configure.ac +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/configure.ac @@ -273,6 +273,7 @@ test "$sndseq" = "yes" && echo "#include \"seq_event.h\"" >> src/asoundlib.h test "$sndseq" = "yes" && echo "#include \"seq.h\"" >> src/asoundlib.h test "$sndseq" = "yes" && echo "#include \"seqmid.h\"" >> src/asoundlib.h +test "$sndseq" = "yes" && echo "#include \"seq_midi_event.h\"" >> src/asoundlib.h cat "$srcdir"/src/asoundlib-tail.h >> src/asoundlib.h echo "SALSA-Lib build configuration:" --- salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884/src/Makefile.am +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/src/Makefile.am @@ -60,7 +60,7 @@ endif if BUILD_SEQ alsainclude_HEADERS += \ - seq.h seq_event.h seqmid.h + seq.h seq_event.h seqmid.h seq_midi_event.h endif noinst_HEADERS = local.h --- /dev/null +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/src/seq_midi_event.h @@ -0,0 +1,78 @@ +#ifndef __ALSA_SEQ_MIDI_EVENT_H +#define __ALSA_SEQ_MIDI_EVENT_H + +#ifdef __cplusplus +extern "C" { +#endif + +/** + * \defgroup MIDI_Event Sequencer event <-> MIDI byte stream coder + * \ingroup Sequencer + * Sequencer event <-> MIDI byte stream coder + * \{ + */ + +/** container for sequencer midi event parsers */ +typedef struct snd_midi_event { + size_t qlen; + size_t read; + int type; + unsigned char lastcmd; + unsigned char nostat; + size_t bufsize; + unsigned char *buf; +} snd_midi_event_t; + +__SALSA_EXPORT_FUNC +int snd_midi_event_new(size_t bufsize, snd_midi_event_t **rdev) +{ + return 0; +} +__SALSA_EXPORT_FUNC +int snd_midi_event_resize_buffer(snd_midi_event_t *dev, size_t bufsize) +{ + return 0; +} +__SALSA_EXPORT_FUNC +void snd_midi_event_free(snd_midi_event_t *dev) +{ +} +__SALSA_EXPORT_FUNC +void snd_midi_event_init(snd_midi_event_t *dev) +{ +} +__SALSA_EXPORT_FUNC +void snd_midi_event_reset_encode(snd_midi_event_t *dev) +{ +} +__SALSA_EXPORT_FUNC +void snd_midi_event_reset_decode(snd_midi_event_t *dev) +{ +} +__SALSA_EXPORT_FUNC +void snd_midi_event_no_status(snd_midi_event_t *dev, int on) +{ +} +__SALSA_EXPORT_FUNC +long snd_midi_event_encode(snd_midi_event_t *dev, const unsigned char *buf, long count, snd_seq_event_t *ev) +{ + return 0; +} +__SALSA_EXPORT_FUNC +int snd_midi_event_encode_byte(snd_midi_event_t *dev, int c, snd_seq_event_t *ev) +{ + return 0; +} +__SALSA_EXPORT_FUNC +long snd_midi_event_decode(snd_midi_event_t *dev, unsigned char *buf, long count, const snd_seq_event_t *ev) +{ + return 0; +} + + +#ifdef __cplusplus +} +#endif + +#endif /* __ALSA_SEQ_MIDI_EVENT_H */ +

2 6

[alsa-devel] [PATCH] salsa-lib: Fix error on jack compilation with salsa
by Mihail Zenkov 03 Apr '13

03 Apr '13

Fix error on jack compilation with salsa: /usr/include/alsa/ctl_macros.h:251:48: error: invalid conversion from 'void*' to 'snd_ctl_elem_id_t* {aka snd_ctl_elem_id*}' [-fpermissive] --- salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884/src/ctl_macros.h +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/src/ctl_macros.h @@ -248,7 +248,7 @@ unsigned int entries) { free(obj->pids); - obj->pids = calloc(entries, sizeof(*obj->pids)); + obj->pids = (snd_ctl_elem_id_t*)calloc(entries, sizeof(*obj->pids)); if (!obj->pids) { obj->space = 0; return -ENOMEM;

3 5

[alsa-devel] [PATCH 0/4] ALSA: Updates for the CA0132 codec
by Ian Minett 03 Apr '13

03 Apr '13

From: Ian Minett <ian_minett(a)creativelabs.com> Hi, This series contains the following updates to CA0132: 1: Add firmware loading for the SpeakerEQ DSP effect. 2: Improve DSP transfer timeout calculations. 3: Add stream and effect latency monitoring routines 4: Update hp unsolicited event handler to manage queued work. These were based on the latest sound.git, but please let me know if they should be against sound-unstable tree instead. Thanks very much, - Ian Signed-off-by: Ian Minett <ian_minett(a)creativelabs.com>

3 19

[alsa-devel] Audio capture on embedded system (via USB port)
by Israel Alejandro Arriaga Trejo 02 Apr '13

02 Apr '13

Hello, I am writing to kindly ask for assistance with ALSA on an embedded platform, in particular to record audio via a USB headset. The embedded platform I am currently using has analog inputs and outputs for audio (mic and headphone). So far I have been able to play and capture audio using the analog audio inputs/outputs with the commands aplay and arecord respectively from ALSA without any problems. However this is not the case when I am trying to use a USB headset via the USB port, at least while trying to record audio (playing audio is not a problem, it works perfectly fine for different rates and formats and the devices are recognized when I type aplay –l or arecord -l). However, when I try to capture audio, using the ALSA command line arecord as in: $ arecord –d 10 –r 16000 –f S16_LE –t wav –Dhw:1,0 test.wav even though the following message appears: $ Recording WAVE ‘test.wav’ : Signed 16 bit Little Endian, Rate 16000 Hz, Mono the application seems “to freeze”. In fact, the recording does not stop in the indicated 10 seconds, instead it continues “working” for a long period of time and creates the file test.wav which after is played it contains fragments of what actually was recorded via the microphone nonetheless, its content is unintelligible. In some cases the following error also appears: $ arecord: pcm_read:1617: read error: Input/Output error As mentioned previously this behavior is only observed during capture mode (while attempting to record using the microphone) since the playback mode using the USB headphone works properly. After browsing for a while I have found similar situations reported, however I have not been able to find a solution to my problem. I would highly appreciate for any hint that could help me to solve this issue. Best regards, Alejandro

2 1

Re: [alsa-devel] [PATCH 1/2] dmaengine: add const for name parameter
by Vinod Koul 02 Apr '13

02 Apr '13

On Fri, Mar 15, 2013 at 09:53:46AM +0100, Markus Pargmann wrote: > Hi, > > I already sent a nearly identical patch: > https://patchwork.kernel.org/patch/2179321/ I applied that one a while ago so Markus can you check my tree and see if anything is remaining, looks most of cases are covered > > Regards, > > Markus > > On Fri, Mar 15, 2013 at 11:36:40AM +0800, Shawn Guo wrote: > > Mark name parameter of generic device tree helpers as const, as it > > shouldn't be changed anyway. > > > > Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> > > --- > > drivers/dma/dmaengine.c | 2 +- > > drivers/dma/of-dma.c | 6 +++--- > > include/linux/dmaengine.h | 7 ++++--- > > include/linux/of_dma.h | 2 +- > > 4 files changed, 9 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c > > index b2728d6..2cbfefe 100644 > > --- a/drivers/dma/dmaengine.c > > +++ b/drivers/dma/dmaengine.c > > @@ -555,7 +555,7 @@ EXPORT_SYMBOL_GPL(__dma_request_channel); > > * @dev: pointer to client device structure > > * @name: slave channel name > > */ > > -struct dma_chan *dma_request_slave_channel(struct device *dev, char *name) > > +struct dma_chan *dma_request_slave_channel(struct device *dev, const char *name) > > { > > /* If device-tree is present get slave info from here */ > > if (dev->of_node) > > diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c > > index 69d04d2..6036cd0 100644 > > --- a/drivers/dma/of-dma.c > > +++ b/drivers/dma/of-dma.c > > @@ -172,8 +172,8 @@ EXPORT_SYMBOL_GPL(of_dma_controller_free); > > * specifiers, matches the name provided. Returns 0 if the name matches and > > * a valid pointer to the DMA specifier is found. Otherwise returns -ENODEV. > > */ > > -static int of_dma_match_channel(struct device_node *np, char *name, int index, > > - struct of_phandle_args *dma_spec) > > +static int of_dma_match_channel(struct device_node *np, const char *name, > > + int index, struct of_phandle_args *dma_spec) > > { > > const char *s; > > > > @@ -198,7 +198,7 @@ static int of_dma_match_channel(struct device_node *np, char *name, int index, > > * Returns pointer to appropriate dma channel on success or NULL on error. > > */ > > struct dma_chan *of_dma_request_slave_channel(struct device_node *np, > > - char *name) > > + const char *name) > > { > > struct of_phandle_args dma_spec; > > struct of_dma *ofdma; > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h > > index 91ac8da..68b4252 100644 > > --- a/include/linux/dmaengine.h > > +++ b/include/linux/dmaengine.h > > @@ -968,7 +968,8 @@ enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie); > > enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx); > > void dma_issue_pending_all(void); > > struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param); > > -struct dma_chan *dma_request_slave_channel(struct device *dev, char *name); > > +struct dma_chan *dma_request_slave_channel(struct device *dev, > > + const char *name); > > void dma_release_channel(struct dma_chan *chan); > > #else > > static inline enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx) > > @@ -984,7 +985,7 @@ static inline struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, > > return NULL; > > } > > static inline struct dma_chan *dma_request_slave_channel(struct device *dev, > > - char *name) > > + const char *name) > > { > > return NULL; > > } > > @@ -1007,7 +1008,7 @@ struct dma_chan *net_dma_find_channel(void); > > static inline struct dma_chan > > *__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn, > > void *fn_param, struct device *dev, > > - char *name) > > + const char *name) > > { > > struct dma_chan *chan; > > > > diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h > > index d15073e..0c4a82e 100644 > > --- a/include/linux/of_dma.h > > +++ b/include/linux/of_dma.h > > @@ -40,7 +40,7 @@ extern int of_dma_controller_register(struct device_node *np, > > void *data); > > extern int of_dma_controller_free(struct device_node *np); > > extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np, > > - char *name); > > + const char *name); > > extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec, > > struct of_dma *ofdma); > > #else > > -- > > 1.7.9.5 > > > > > > > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

4 6

[alsa-devel] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010, IP: [<ffffffff819865fb>] snd_info_get_line+0x3b/0xf0
by Tommi Rantala 02 Apr '13

02 Apr '13

Hello, Saw this while fuzzing with trinity in a qemu virtual machine: [6026] Random reseed: 625996896 [watchdog] 7640111 iterations. [F:6650299 S:989808] [6026] Random reseed: 472197910 [ 459.365417] misc rfkill: uevent: unknown action-string [ 459.521953] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 459.522027] IP: [<ffffffff819865fb>] snd_info_get_line+0x3b/0xf0 [ 459.522027] PGD 52deb067 PUD 50bbc067 PMD 0 [ 459.522027] Oops: 0000 [#1] SMP [ 459.522027] CPU 0 [ 459.522027] Pid: 7781, comm: trinity-child53 Tainted: G W 3.9.0-rc1+ #103 Bochs Bochs [ 459.522027] RIP: 0010:[<ffffffff819865fb>] [<ffffffff819865fb>] snd_info_get_line+0x3b/0xf0 [ 459.522027] RSP: 0018:ffff880065455a88 EFLAGS: 00010202 [ 459.522027] RAX: 0000000000000001 RBX: ffff8800508e1760 RCX: 0000000000000000 [ 459.522027] RDX: ffff880065455b57 RSI: ffff880065455ad8 RDI: ffff8800599ceba0 [ 459.522027] RBP: ffff880065455a88 R08: 0000000000000010 R09: 0000000000000001 [ 459.522027] R10: ffff8800461f5630 R11: 0000000000000000 R12: ffff88007a470960 [ 459.522027] R13: ffff88007a43b980 R14: ffff88007a470000 R15: ffff88007a43b900 [ 459.522027] FS: 00007f9c07c94700(0000) GS:ffff88007f800000(0000) knlGS:0000000000000000 [ 459.522027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 459.522027] CR2: 0000000000000010 CR3: 0000000060ee2000 CR4: 00000000000006f0 [ 459.522027] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 459.522027] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 459.522027] Process trinity-child53 (pid: 7781, threadinfo ffff880065454000, task ffff8800797c2290) [ 459.522027] Stack: [ 459.522027] ffff880065455b88 ffffffff819a3f7e ffff880065455ab8 ffff8800599ceba0 [ 459.522027] ffff8800508e1220 ffff8800508e1200 ffff880065455b48 ffffffff8136eafc [ 459.522027] ffff880065455ae8 ffffffff81091198 ffff88007cc01600 ffff8800508e1200 [ 459.522027] Call Trace: [ 459.522027] [<ffffffff819a3f7e>] snd_mixer_oss_proc_write+0x1ee/0x250 [ 459.522027] [<ffffffff8136eafc>] ? debug_check_no_obj_freed+0x17c/0x230 [ 459.522027] [<ffffffff81091198>] ? kmemcheck_shadow_lookup+0x28/0x80 [ 459.522027] [<ffffffff81985a38>] ? snd_info_entry_release+0x48/0xd0 [ 459.522027] [<ffffffff81199c0c>] ? kfree+0x1ac/0x1e0 [ 459.522027] [<ffffffff81985a50>] snd_info_entry_release+0x60/0xd0 [ 459.522027] [<ffffffff81211022>] proc_reg_release+0x132/0x180 [ 459.522027] [<ffffffff819859f0>] ? snd_info_entry_llseek+0x100/0x100 [ 459.522027] [<ffffffff811a807a>] __fput+0x11a/0x220 [ 459.522027] [<ffffffff811a8189>] ____fput+0x9/0x10 [ 459.522027] [<ffffffff810bcbbe>] task_work_run+0x9e/0xc0 [ 459.522027] [<ffffffff8109d85c>] do_exit+0x3ac/0xad0 [ 459.522027] [<ffffffff810afc29>] ? get_signal_to_deliver+0xf9/0x810 [ 459.522027] [<ffffffff8109e044>] do_group_exit+0x84/0xd0 [ 459.522027] [<ffffffff810b0269>] get_signal_to_deliver+0x739/0x810 [ 459.522027] [<ffffffff810583b2>] do_signal+0x52/0x570 [ 459.522027] [<ffffffff810cbaf3>] ? finish_task_switch+0x43/0x120 [ 459.522027] [<ffffffff810f3366>] ? trace_hardirqs_on_caller+0x16/0x1f0 [ 459.522027] [<ffffffff810f354d>] ? trace_hardirqs_on+0xd/0x10 [ 459.522027] [<ffffffff81fad85b>] ? _raw_spin_unlock_irq+0x2b/0x40 [ 459.522027] [<ffffffff810cbb30>] ? finish_task_switch+0x80/0x120 [ 459.522027] [<ffffffff810cbaf3>] ? finish_task_switch+0x43/0x120 [ 459.522027] [<ffffffff810588f7>] do_notify_resume+0x27/0x70 [ 459.522027] [<ffffffff813663fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 459.522027] [<ffffffff81faf0a2>] int_signal+0x12/0x17 [ 459.522027] Code: 00 8b 4f 14 85 c9 0f 85 cf 00 00 00 44 8b 5f 18 45 85 db 74 6b e9 c1 00 00 00 66 0f 1f 44 00 00 8b 47 08 4c 8b 07 89 c1 83 c0 01 <41> 0f b6 0c 08 89 47 08 44 0f be c1 41 83 f8 0a 75 2b 39 47 0c [ 459.522027] RIP [<ffffffff819865fb>] snd_info_get_line+0x3b/0xf0 [ 459.522027] RSP <ffff880065455a88> [ 459.522027] CR2: 0000000000000010 [ 459.652998] ---[ end trace a9ded493128a1bce ]--- [ 459.654880] Fixing recursive fault but reboot is needed! [6026] Random reseed: 807260652 [watchdog] pid 8469 hasn't made progress in 30 seconds! (last:2725563185 now:2725563215 diff:30). Stuck in syscall 70:msgrcv. Sending SIGKILL. [watchdog] 7677069 iterations. [F:6682605 S:994461] [6026] Random reseed: 575363686 [ 461.032969] misc ashmem: uevent: unknown action-string [6026] Random reseed: 1095114151 [6026] Regenerating random pages, fd's etc. Tommi

2 1

[alsa-devel] How to create and verify verb tables for coreboot?
by Paul Menzel 02 Apr '13

02 Apr '13

Dear ALSA folks, coreboot is a free replacement for the traditional BIOS [1]. Therefore coreboot is also responsible for providing the correct verb table [2]. According to Jens the Verb Table format is not documented and is created by for example Realtek [3]. Could you give some more information about the verb table and how this can be created from scratch? Our developer Rudolf suggests to take the values from /sys/class/sound/hwC1D0/init_pin_configs when running the vendor BIOS [2]. How can a correct verb table be verified? As for the ASRock E350M1 [4][5], I attach the output of `alsa-info.sh` [6] when running coreboot. The one running with the vendor BIOS is uploaded to the server [7] due to the size limit of this mailing list. $ wdiff vendorbios coreboot # init_pin_configs 0x11 [-0x411111f0-] {+0x411110f0+} 0x12 0x411111f0 0x14 [-0x01014010-] {+0x01014030+} 0x15 [-0x01011012-] {+0x01011031+} 0x16 [-0x01016011-] {+0x01016032+} 0x17 [-0x411111f0-] {+0x01012033+} 0x18 [-0x01a19840-] {+0x01a19850+} 0x19 [-0x02a19950-] {+0x02a19c80+} 0x1a [-0x0181304f-] {+0x01813051+} 0x1b [-0x02214120-] {+0x02214c40+} 0x1c [-0x411111f0-] {+0x9933105f+} 0x1d [-0x4005e601-] {+0x00000100+} 0x1e [-0x01452130-] {+0x01441070+} 0x1f [-0x411111f0-] {+0x41c46060+} Thanks, Paul [1] http://www.coreboot.org/ [2] http://www.coreboot.org/pipermail/coreboot/2013-March/075547.html [3] http://review.coreboot.org/#/c/2553/1/src/mainboard/lippert/frontrunner-af/… [4] http://www.coreboot.org/ASRock_E350M1 [5] http://www.coreboot.org/pipermail/coreboot/2013-March/075557.html [6] http://alsa-project.org/main/index.php/Help_To_Debug [7] http://www.alsa-project.org/db/?f=96ff75103a48ab8e58a216bd12f65d2755679cdc

2 1

[alsa-devel] [PATCH v2 2/2] ALSA: hda - bug fix on HDMI ELD debug message
by mengdong.lin＠intel.com 02 Apr '13

02 Apr '13

From: Mengdong Lin <mengdong.lin(a)intel.com> This patch let ELD debug message show 'pin_eld->monitor_present' which reflects the real pin response to verb GET_PIN_SENSE. 'eld->monitor_present' should not be used here because 'eld' is a temp structure now and so its "monitor_present" is not set. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 78e1827..de8ac5c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1196,7 +1196,7 @@ static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll) _snd_printd(SND_PR_VERBOSE, "HDMI status: Codec=%d Pin=%d Presence_Detect=%d ELD_Valid=%d\n", - codec->addr, pin_nid, eld->monitor_present, eld->eld_valid); + codec->addr, pin_nid, pin_eld->monitor_present, eld->eld_valid); if (eld->eld_valid) { if (snd_hdmi_get_eld(codec, pin_nid, eld->eld_buffer, -- 1.7.10.4

3 2

[alsa-devel] [PATCH v2 1/2] ALSA: hda - bug fix on return value when getting HDMI ELD info
by mengdong.lin＠intel.com 02 Apr '13

02 Apr '13

From: Mengdong Lin <mengdong.lin(a)intel.com> In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0. Otherwise it will be returned uninitialized as non-zero after ELD info is got successfully. Thus hdmi_present_sense() will always assume ELD info is invalid by mistake, and /proc file system cannot show the proper ELD info. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c index 7dd8463..d0d7ac1 100644 --- a/sound/pci/hda/hda_eld.c +++ b/sound/pci/hda/hda_eld.c @@ -320,7 +320,7 @@ int snd_hdmi_get_eld(struct hda_codec *codec, hda_nid_t nid, unsigned char *buf, int *eld_size) { int i; - int ret; + int ret = 0; int size; /* -- 1.7.10.4

3 2

[alsa-devel] ASoC updates for v3.9
by Mark Brown 02 Apr '13

02 Apr '13

The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: Linux 3.9-rc4 (2013-03-23 16:52:44 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v3.9-rc4 for you to fetch changes up to 40bac28eb1e39f229a94ad72e2ca8cdeef3ba31a: Merge remote-tracking branch 'asoc/fix/spear' into asoc-next (2013-03-26 14:08:07 +0000) ---------------------------------------------------------------- ASoC: Fixes for v3.9 A few more fixes here and there, including quite a few nasty driver specific ones, but nothing that has a major general impact. ---------------------------------------------------------------- Axel Lin (1): ASoC: si476x: Add missing break for SNDRV_PCM_FORMAT_S8 switch case Joe Perches (1): ASoC:: max98090: Remove executable bit Lars-Peter Clausen (2): ASoC: spear_pcm: Update to new pcm_new() API ASoC: dma-sh7760: Fix compile error Mark Brown (9): ASoC: dapm: Fix handling of loops Merge remote-tracking branch 'asoc/fix/adsp' into asoc-next Merge remote-tracking branch 'asoc/fix/core' into asoc-next Merge remote-tracking branch 'asoc/fix/dapm' into asoc-next Merge remote-tracking branch 'asoc/fix/fsl' into asoc-next Merge remote-tracking branch 'asoc/fix/max98090' into asoc-next Merge remote-tracking branch 'asoc/fix/sh' into asoc-next Merge remote-tracking branch 'asoc/fix/si476x' into asoc-next Merge remote-tracking branch 'asoc/fix/spear' into asoc-next Markus Pargmann (1): ASoC: pcm030 audio fabric: remove __init from probe Peter Ujfalusi (1): ASoC: dapm: Fix pointer dereference in is_connected_output_ep() Sascha Hauer (1): ASoC: imx-ssi: Fix occasional AC97 reset failure Silviu-Mihai Popescu (1): ASoC: core: fix invalid free of devm_ allocated data Wei Yongjun (2): ASoC: wm_adsp: fix possible memory leak in wm_adsp_load_coeff() ASoC: core: fix possible memory leak in snd_soc_bytes_put() include/sound/soc-dapm.h | 1 + sound/soc/codecs/si476x.c | 1 + sound/soc/codecs/wm_adsp.c | 5 +++-- sound/soc/fsl/imx-ssi.c | 5 +++++ sound/soc/fsl/pcm030-audio-fabric.c | 2 +- sound/soc/sh/dma-sh7760.c | 4 ++-- sound/soc/soc-core.c | 8 ++++---- sound/soc/soc-dapm.c | 14 ++++++++++++++ sound/soc/spear/spear_pcm.c | 12 ++++++------ 9 files changed, 37 insertions(+), 15 deletions(-) mode change 100755 => 100644 include/sound/max98090.h mode change 100755 => 100644 sound/soc/codecs/max98090.c mode change 100755 => 100644 sound/soc/codecs/max98090.h

2 2

[alsa-devel] [PATCH] ALSA: hda/ca0132 - Delay HP amp turnon.
by Dylan Reid 02 Apr '13

02 Apr '13

From: Chih-Chung Chang <chihchung(a)chromium.org> Turing on the headphone amp interferes with the impedance measurement used to detect a TRRS style headset microphone. Delay the HP turn on until 500ms after the jack is detected, allowing the mic detection state machine to run to completion. Signed-off-by: Chih-Chung Chang <chihchung(a)chromium.org> Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/pci/hda/patch_ca0132.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 0792b57..12eb21a 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -741,6 +741,9 @@ struct ca0132_spec { long voicefx_val; long cur_mic_boost; + struct hda_codec *codec; + struct delayed_work unsol_hp_work; + #ifdef ENABLE_TUNING_CONTROLS long cur_ctl_vals[TUNING_CTLS_COUNT]; #endif @@ -3227,6 +3230,14 @@ exit: return err < 0 ? err : 0; } +static void ca0132_unsol_hp_delayed(struct work_struct *work) +{ + struct ca0132_spec *spec = container_of( + to_delayed_work(work), struct ca0132_spec, unsol_hp_work); + ca0132_select_out(spec->codec); + snd_hda_jack_report_sync(spec->codec); +} + static void ca0132_set_dmic(struct hda_codec *codec, int enable); static int ca0132_mic_boost_set(struct hda_codec *codec, long val); static int ca0132_effects_set(struct hda_codec *codec, hda_nid_t nid, long val); @@ -4399,8 +4410,7 @@ static void ca0132_process_dsp_response(struct hda_codec *codec) static void ca0132_unsol_event(struct hda_codec *codec, unsigned int res) { - snd_printdd(KERN_INFO "ca0132_unsol_event: 0x%x\n", res); - + struct ca0132_spec *spec = codec->spec; if (((res >> AC_UNSOL_RES_TAG_SHIFT) & 0x3f) == UNSOL_TAG_DSP) { ca0132_process_dsp_response(codec); @@ -4412,8 +4422,13 @@ static void ca0132_unsol_event(struct hda_codec *codec, unsigned int res) switch (res) { case UNSOL_TAG_HP: - ca0132_select_out(codec); - snd_hda_jack_report_sync(codec); + /* Delay enabling the HP amp, to let the mic-detection + * state machine run. + */ + cancel_delayed_work_sync(&spec->unsol_hp_work); + queue_delayed_work(codec->bus->workq, + &spec->unsol_hp_work, + msecs_to_jiffies(500)); break; case UNSOL_TAG_AMIC1: ca0132_select_mic(codec); @@ -4588,6 +4603,7 @@ static void ca0132_free(struct hda_codec *codec) { struct ca0132_spec *spec = codec->spec; + cancel_delayed_work_sync(&spec->unsol_hp_work); snd_hda_power_up(codec); snd_hda_sequence_write(codec, spec->base_exit_verbs); ca0132_exit_chip(codec); @@ -4653,6 +4669,7 @@ static int patch_ca0132(struct hda_codec *codec) if (!spec) return -ENOMEM; codec->spec = spec; + spec->codec = codec; spec->num_mixers = 1; spec->mixers[0] = ca0132_mixer; @@ -4663,6 +4680,8 @@ static int patch_ca0132(struct hda_codec *codec) spec->init_verbs[1] = ca0132_init_verbs1; spec->num_init_verbs = 2; + INIT_DELAYED_WORK(&spec->unsol_hp_work, ca0132_unsol_hp_delayed); + ca0132_init_chip(codec); ca0132_config(codec); -- 1.8.1.3.605.g02339dd

2 1

Re: [alsa-devel] [PATCH] sound: oss: sb_common: Used kmemdup instead of kmalloc and memcpy
by Takashi Iwai 02 Apr '13

02 Apr '13

At Mon, 25 Mar 2013 15:50:34 +0200, Alexandru Gheorghiu wrote: > > Used kmemdup instead of replicating it's behaviour with kmalloc followed > by memcpy. > Patch found using coccinelle. > > Signed-off-by: Alexandru Gheorghiu <gheorghiuandru(a)gmail.com> Thanks, applied. Takashi > --- > sound/oss/sb_common.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/sound/oss/sb_common.c b/sound/oss/sb_common.c > index 7d42c54..851a1da 100644 > --- a/sound/oss/sb_common.c > +++ b/sound/oss/sb_common.c > @@ -626,13 +626,12 @@ int sb_dsp_detect(struct address_info *hw_config, int pci, int pciio, struct sb_ > */ > > > - detected_devc = kmalloc(sizeof(sb_devc), GFP_KERNEL); > + detected_devc = kmemdup(devc, sizeof(sb_devc), GFP_KERNEL); > if (detected_devc == NULL) > { > printk(KERN_ERR "sb: Can't allocate memory for device information\n"); > return 0; > } > - memcpy(detected_devc, devc, sizeof(sb_devc)); > MDB(printk(KERN_INFO "SB %d.%02d detected OK (%x)\n", devc->major, devc->minor, hw_config->io_base)); > return 1; > } > -- > 1.7.9.5 >

1 0

Re: [alsa-devel] [PATCH] sound: oss: uart401: Used kmemdup instead of kmalloc and memcpy
by Takashi Iwai 02 Apr '13

02 Apr '13

At Mon, 25 Mar 2013 15:46:49 +0200, Alexandru Gheorghiu wrote: > > Used kmemdup instead of replicating it's behaviour with kmalloc followed > by memcpy. > Patch found using coccinelle. > > Signed-off-by: Alexandru Gheorghiu <gheorghiuandru(a)gmail.com> Thanks, applied. Takashi > --- > sound/oss/uart401.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/sound/oss/uart401.c b/sound/oss/uart401.c > index 8e514a6..5433c6f 100644 > --- a/sound/oss/uart401.c > +++ b/sound/oss/uart401.c > @@ -352,23 +352,26 @@ int probe_uart401(struct address_info *hw_config, struct module *owner) > goto cleanup_irq; > } > conf_printf(name, hw_config); > - midi_devs[devc->my_dev] = kmalloc(sizeof(struct midi_operations), GFP_KERNEL); > + midi_devs[devc->my_dev] = kmemdup(&uart401_operations, > + sizeof(struct midi_operations), > + GFP_KERNEL); > if (!midi_devs[devc->my_dev]) { > printk(KERN_ERR "uart401: Failed to allocate memory\n"); > goto cleanup_unload_mididev; > } > - memcpy(midi_devs[devc->my_dev], &uart401_operations, sizeof(struct midi_operations)); > > if (owner) > midi_devs[devc->my_dev]->owner = owner; > > midi_devs[devc->my_dev]->devc = devc; > - midi_devs[devc->my_dev]->converter = kmalloc(sizeof(struct synth_operations), GFP_KERNEL); > + midi_devs[devc->my_dev]->converter = kmemdup(&std_midi_synth, > + sizeof(struct synth_operations), > + GFP_KERNEL); > + > if (!midi_devs[devc->my_dev]->converter) { > printk(KERN_WARNING "uart401: Failed to allocate memory\n"); > goto cleanup_midi_devs; > } > - memcpy(midi_devs[devc->my_dev]->converter, &std_midi_synth, sizeof(struct synth_operations)); > strcpy(midi_devs[devc->my_dev]->info.name, name); > midi_devs[devc->my_dev]->converter->id = "UART401"; > midi_devs[devc->my_dev]->converter->midi_dev = devc->my_dev; > -- > 1.7.9.5 >

1 0

[alsa-devel] [PATCH] USB-audio: Add "HP Digital Stereo Headset" to SPDIF blacklist
by David Henningsson 02 Apr '13

02 Apr '13

Yet another headset without digital I/O. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- src/conf/cards/USB-Audio.conf | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/conf/cards/USB-Audio.conf b/src/conf/cards/USB-Audio.conf index 177a7af..71c2971 100644 --- a/src/conf/cards/USB-Audio.conf +++ b/src/conf/cards/USB-Audio.conf @@ -39,7 +39,8 @@ USB-Audio.pcm.iec958_device { # The below don't have digital in/out, so prevent them from being opened. "Blue Snowball" 999 - "Logitech Speaker Lapdesk N700" 999 + "HP Digital Stereo Headset" 999 + "Logitech Speaker Lapdesk N700" 999 "Logitech USB Headset" 999 "Logitech Wireless Headset" 999 "Plantronics GameCom 780" 999 -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH] ASoC: codecs: remove hidden prompt
by Mark Brown 01 Apr '13

01 Apr '13

On Tue, Mar 12, 2013 at 09:08:38PM +0100, Paul Bolle wrote: > The Kconfig symbol SND_SOC_OF_SIMPLE got removed in commit > f0fba2ad1b6b53d5360125c41953b7afcd6deff0 ("ASoC: multi-component - ASoC > Multi-Component Support"). But that commit missed one instance. Remove > it now, together with the prompt it has effectively hidden ever since. Applied, thanks.

1 0

[alsa-devel] [PATCH] ASoC: dapm: Remove redundant clear_walk() for supply widgets
by Mark Brown 01 Apr '13

01 Apr '13

From: Ryo Tsutsui <Ryo.Tsutsui(a)wolfsonmicro.com> We already clear the walked state in dapm_widget_power_check(), no need to do it again. Signed-off-by: Ryo Tsutsui <Ryo.Tsutsui(a)wolfosonmicro.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-dapm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 1896a70..0a395eb 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1179,8 +1179,6 @@ static int dapm_supply_check_power(struct snd_soc_dapm_widget *w) return 1; } - dapm_clear_walk(w->dapm); - return 0; } -- 1.7.10.4

2 1

[alsa-devel] [PATCH] ASoC: dapm: Only clear paths we've walked
by Mark Brown 01 Apr '13

01 Apr '13

From: Ryo Tsutsui <Ryo.Tsutsui(a)wolfsonmicro.com> When clearing the walked flags there is no need to clear all paths, we only need to clear the paths we actually walked. This means we can split dapm_clear_walk() into input and output versions and rather than going through all DAPM paths we can recurse down the path until we encounter paths we have not yet walked. This reduces the number of operations we need to perform and improves cache locality. [Pulled out of the vendor tree that the patch was originally generated for by me, any bugs were introduced in that process -- broonie] Signed-off-by: Ryo Tsutsui <Ryo.Tsutsui(a)wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-dapm.c | 47 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 35 insertions(+), 12 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 0a395eb..93def6f 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -707,14 +707,33 @@ static int dapm_new_pga(struct snd_soc_dapm_widget *w) } /* reset 'walked' bit for each dapm path */ -static inline void dapm_clear_walk(struct snd_soc_dapm_context *dapm) +static void dapm_clear_walk_output(struct snd_soc_dapm_context *dapm, + struct list_head *sink) { struct snd_soc_dapm_path *p; - list_for_each_entry(p, &dapm->card->paths, list) - p->walked = 0; + list_for_each_entry(p, sink, list_source) { + if (p->walked) { + p->walked = 0; + dapm_clear_walk_output(dapm, &p->sink->sinks); + } + } +} + +static void dapm_clear_walk_input(struct snd_soc_dapm_context *dapm, + struct list_head *source) +{ + struct snd_soc_dapm_path *p; + + list_for_each_entry(p, source, list_sink) { + if (p->walked) { + p->walked = 0; + dapm_clear_walk_input(dapm, &p->source->sources); + } + } } + /* We implement power down on suspend by checking the power state of * the ALSA card - when we are suspending the ALSA state for the card * is set to D3. @@ -997,13 +1016,17 @@ int snd_soc_dapm_dai_get_connected_widgets(struct snd_soc_dai *dai, int stream, mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME); dapm_reset(card); - if (stream == SNDRV_PCM_STREAM_PLAYBACK) + if (stream == SNDRV_PCM_STREAM_PLAYBACK) { paths = is_connected_output_ep(dai->playback_widget, list); - else + dapm_clear_walk_output(&card->dapm, + &dai->playback_widget->sinks); + } else { paths = is_connected_input_ep(dai->capture_widget, list); + dapm_clear_walk_input(&card->dapm, + &dai->capture_widget->sources); + } trace_snd_soc_dapm_connected(paths, stream); - dapm_clear_walk(&card->dapm); mutex_unlock(&card->dapm_mutex); return paths; @@ -1106,9 +1129,9 @@ static int dapm_generic_check_power(struct snd_soc_dapm_widget *w) DAPM_UPDATE_STAT(w, power_checks); in = is_connected_input_ep(w, NULL); - dapm_clear_walk(w->dapm); + dapm_clear_walk_input(w->dapm, &w->sources); out = is_connected_output_ep(w, NULL); - dapm_clear_walk(w->dapm); + dapm_clear_walk_output(w->dapm, &w->sinks); return out != 0 && in != 0; } @@ -1131,7 +1154,7 @@ static int dapm_adc_check_power(struct snd_soc_dapm_widget *w) if (w->active) { in = is_connected_input_ep(w, NULL); - dapm_clear_walk(w->dapm); + dapm_clear_walk_input(w->dapm, &w->sources); return in != 0; } else { return dapm_generic_check_power(w); @@ -1147,7 +1170,7 @@ static int dapm_dac_check_power(struct snd_soc_dapm_widget *w) if (w->active) { out = is_connected_output_ep(w, NULL); - dapm_clear_walk(w->dapm); + dapm_clear_walk_output(w->dapm, &w->sinks); return out != 0; } else { return dapm_generic_check_power(w); @@ -1775,9 +1798,9 @@ static ssize_t dapm_widget_power_read_file(struct file *file, return -ENOMEM; in = is_connected_input_ep(w, NULL); - dapm_clear_walk(w->dapm); + dapm_clear_walk_input(w->dapm, &w->sources); out = is_connected_output_ep(w, NULL); - dapm_clear_walk(w->dapm); + dapm_clear_walk_output(w->dapm, &w->sinks); ret = snprintf(buf, PAGE_SIZE, "%s: %s%s in %d out %d", w->name, w->power ? "On" : "Off", -- 1.7.10.4

2 1

[alsa-devel] [PATCH 00/13] mach-mxs header files cleanup
by Shawn Guo 01 Apr '13

01 Apr '13

The series cleans up mach-mxs headers files in order to support multiplatform build on mxs. Andrew, Jonathan, Mark, Can you please give your ACK on the patch you are copied, so that the series can go via arm-soc as a whole? Thanks. Shawn Shawn Guo (13): rtc: stmp3xxx: use stmp_reset_block() instead iio: mxs-lradc: remove unneeded mach header inclusion ASoC: mxs-saif: remove mach header inclusion ARM: mxs: remove empty hardware.h ARM: mxs: get reset address from device tree ARM: mxs: remove system.c ARM: mxs: get ocotp base address from device tree ARM: mxs: use debug_ll_io_init for low-level debug ARM: mxs: remove mm.c ARM: mxs: move mxs_get_ocotp() into mach-mxs.c ARM: mxs: remove common.h ARM: mxs: merge imx23 and imx28 into one machine_desc ARM: mxs: remove unused headers arch/arm/boot/dts/imx23.dtsi | 3 +- arch/arm/boot/dts/imx28.dtsi | 3 +- arch/arm/mach-mxs/Makefile | 4 - arch/arm/mach-mxs/include/mach/common.h | 25 --- arch/arm/mach-mxs/include/mach/debug-macro.S | 9 +- arch/arm/mach-mxs/include/mach/digctl.h | 22 --- arch/arm/mach-mxs/include/mach/hardware.h | 23 --- arch/arm/mach-mxs/include/mach/mx23.h | 169 ------------------- arch/arm/mach-mxs/include/mach/mx28.h | 225 -------------------------- arch/arm/mach-mxs/include/mach/mxs.h | 116 ------------- arch/arm/mach-mxs/mach-mxs.c | 182 +++++++++++++++++---- arch/arm/mach-mxs/mm.c | 52 ------ arch/arm/mach-mxs/ocotp.c | 93 ----------- arch/arm/mach-mxs/system.c | 139 ---------------- drivers/rtc/rtc-stmp3xxx.c | 6 +- drivers/staging/iio/adc/mxs-lradc.c | 3 - include/linux/clk/mxs.h | 16 ++ sound/soc/mxs/mxs-saif.c | 5 +- 18 files changed, 180 insertions(+), 915 deletions(-) delete mode 100644 arch/arm/mach-mxs/include/mach/common.h delete mode 100644 arch/arm/mach-mxs/include/mach/digctl.h delete mode 100644 arch/arm/mach-mxs/include/mach/hardware.h delete mode 100644 arch/arm/mach-mxs/include/mach/mx23.h delete mode 100644 arch/arm/mach-mxs/include/mach/mx28.h delete mode 100644 arch/arm/mach-mxs/include/mach/mxs.h delete mode 100644 arch/arm/mach-mxs/mm.c delete mode 100644 arch/arm/mach-mxs/ocotp.c delete mode 100644 arch/arm/mach-mxs/system.c create mode 100644 include/linux/clk/mxs.h -- 1.7.9.5

2 2

[alsa-devel] [PATCH V2] ASoC: Implement mixer control sharing
by Stephen Warren 31 Mar '13

31 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> This is the equivalent of commit af46800 "ASoC: Implement mux control sharing", but applied to mixers instead of muxes. This allows a single control to affect multiple mixer widgets at once, which is useful when there is a single set of register bits that affects multiple mixers in HW, for example both the L and R mixers of a stereo path. Without this, you either: 1) End up with multiple controls that affect the same register bits, but whose DAPM state falls out of sync with HW, since the DAPM state is only updated for the specific control that is modified, and not for other paths that are affected by the register bit(s). 2) False paths through DAPM, since you end up merging unconnected stereo paths together into a single widget which hosts the single control, and then branching back out again, thus conjoining the enable states of the two input paths. Now that the kcontrol creation logic is split out into a separate function, dapm_create_or_share_mixmux_kcontrol(), also use that to replace most of the body of dapm_new_mux(). This should produce no functional change, but simply eliminates some mostly duplicated code. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- v2: Split dapm_new_mixer()'s loop body into a separate function, dapm_create_or_share_mixmux_kcontrol, to avoid a nasty goto. Also use this for dapm_new_mux(). --- sound/soc/soc-dapm.c | 270 +++++++++++++++++++++++++------------------------- 1 file changed, 136 insertions(+), 134 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 33acd8b..c7cacf9 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -504,17 +504,27 @@ static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, return 0; } -/* create new dapm mixer control */ -static int dapm_new_mixer(struct snd_soc_dapm_widget *w) +/* + * Determine if a kcontrol is shared. If it is, look it up. If it isn't, + * create it. Either way, add the widget into the control's widget list + */ +static int dapm_create_or_share_mixmux_kcontrol(struct snd_soc_dapm_widget *w, + int kci, struct snd_soc_dapm_path *path) { struct snd_soc_dapm_context *dapm = w->dapm; - int i, ret = 0; - size_t name_len, prefix_len; - struct snd_soc_dapm_path *path; struct snd_card *card = dapm->card->snd_card; const char *prefix; + size_t prefix_len; + int shared; + struct snd_kcontrol *kcontrol; struct snd_soc_dapm_widget_list *wlist; + int wlistentries; size_t wlistsize; + bool wname_in_long_name, kcname_in_long_name; + size_t name_len; + char *long_name; + const char *name; + int ret; if (dapm->codec) prefix = dapm->codec->name_prefix; @@ -526,103 +536,141 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) else prefix_len = 0; - /* add kcontrol */ - for (i = 0; i < w->num_kcontrols; i++) { + shared = dapm_is_shared_kcontrol(dapm, w, &w->kcontrol_news[kci], + &kcontrol); - /* match name */ - list_for_each_entry(path, &w->sources, list_sink) { + if (kcontrol) { + wlist = kcontrol->private_data; + wlistentries = wlist->num_widgets + 1; + } else { + wlist = NULL; + wlistentries = 1; + } - /* mixer/mux paths name must match control name */ - if (path->name != (char *)w->kcontrol_news[i].name) - continue; + wlistsize = sizeof(struct snd_soc_dapm_widget_list) + + wlistentries * sizeof(struct snd_soc_dapm_widget *); + wlist = krealloc(wlist, wlistsize, GFP_KERNEL); + if (wlist == NULL) { + dev_err(dapm->dev, "ASoC: can't allocate widget list for %s\n", + w->name); + return -ENOMEM; + } + wlist->num_widgets = wlistentries; + wlist->widgets[wlistentries - 1] = w; - if (w->kcontrols[i]) { - path->kcontrol = w->kcontrols[i]; - continue; + if (!kcontrol) { + if (shared) { + wname_in_long_name = false; + kcname_in_long_name = true; + } else { + switch (w->id) { + case snd_soc_dapm_switch: + case snd_soc_dapm_mixer: + wname_in_long_name = true; + kcname_in_long_name = true; + break; + case snd_soc_dapm_mixer_named_ctl: + wname_in_long_name = false; + kcname_in_long_name = true; + break; + case snd_soc_dapm_mux: + case snd_soc_dapm_virt_mux: + case snd_soc_dapm_value_mux: + wname_in_long_name = true; + kcname_in_long_name = false; + break; + default: + kfree(wlist); + return -EINVAL; } + } + + if (wname_in_long_name && kcname_in_long_name) { + name_len = strlen(w->name) - prefix_len + 1 + + strlen(w->kcontrol_news[kci].name) + 1; - wlistsize = sizeof(struct snd_soc_dapm_widget_list) + - sizeof(struct snd_soc_dapm_widget *), - wlist = kzalloc(wlistsize, GFP_KERNEL); - if (wlist == NULL) { - dev_err(dapm->dev, - "ASoC: can't allocate widget list for %s\n", - w->name); + long_name = kmalloc(name_len, GFP_KERNEL); + if (long_name == NULL) { + kfree(wlist); return -ENOMEM; } - wlist->num_widgets = 1; - wlist->widgets[0] = w; - - /* add dapm control with long name. - * for dapm_mixer this is the concatenation of the - * mixer and kcontrol name. - * for dapm_mixer_named_ctl this is simply the - * kcontrol name. + + /* + * The control will get a prefix from the control + * creation process but we're also using the same + * prefix for widgets so cut the prefix off the + * front of the widget name. */ - name_len = strlen(w->kcontrol_news[i].name) + 1; - if (w->id != snd_soc_dapm_mixer_named_ctl) - name_len += 1 + strlen(w->name); + snprintf(long_name, name_len, "%s %s", + w->name + prefix_len, + w->kcontrol_news[kci].name); + long_name[name_len - 1] = '\0'; + + name = long_name; + } else if (wname_in_long_name) { + long_name = NULL; + name = w->name + prefix_len; + } else { + long_name = NULL; + name = w->kcontrol_news[kci].name; + } - path->long_name = kmalloc(name_len, GFP_KERNEL); + kcontrol = snd_soc_cnew(&w->kcontrol_news[kci], wlist, name, + prefix); + ret = snd_ctl_add(card, kcontrol); + if (ret < 0) { + dev_err(dapm->dev, + "ASoC: failed to add widget %s dapm kcontrol %s: %d\n", + w->name, name, ret); + kfree(wlist); + kfree(long_name); + return ret; + } - if (path->long_name == NULL) { - kfree(wlist); - return -ENOMEM; - } + path->long_name = long_name; + } - switch (w->id) { - default: - /* The control will get a prefix from - * the control creation process but - * we're also using the same prefix - * for widgets so cut the prefix off - * the front of the widget name. - */ - snprintf((char *)path->long_name, name_len, - "%s %s", w->name + prefix_len, - w->kcontrol_news[i].name); - break; - case snd_soc_dapm_mixer_named_ctl: - snprintf((char *)path->long_name, name_len, - "%s", w->kcontrol_news[i].name); - break; - } + kcontrol->private_data = wlist; + w->kcontrols[kci] = kcontrol; + path->kcontrol = kcontrol; - ((char *)path->long_name)[name_len - 1] = '\0'; + return 0; +} - path->kcontrol = snd_soc_cnew(&w->kcontrol_news[i], - wlist, path->long_name, - prefix); - ret = snd_ctl_add(card, path->kcontrol); - if (ret < 0) { - dev_err(dapm->dev, "ASoC: failed to add widget" - " %s dapm kcontrol %s: %d\n", - w->name, path->long_name, ret); - kfree(wlist); - kfree(path->long_name); - path->long_name = NULL; - return ret; +/* create new dapm mixer control */ +static int dapm_new_mixer(struct snd_soc_dapm_widget *w) +{ + int i, ret; + struct snd_soc_dapm_path *path; + + /* add kcontrol */ + for (i = 0; i < w->num_kcontrols; i++) { + /* match name */ + list_for_each_entry(path, &w->sources, list_sink) { + /* mixer/mux paths name must match control name */ + if (path->name != (char *)w->kcontrol_news[i].name) + continue; + + if (w->kcontrols[i]) { + path->kcontrol = w->kcontrols[i]; + continue; } - w->kcontrols[i] = path->kcontrol; + + ret = dapm_create_or_share_mixmux_kcontrol(w, i, path); + if (ret < 0) + return ret; } } - return ret; + + return 0; } /* create new dapm mux control */ static int dapm_new_mux(struct snd_soc_dapm_widget *w) { struct snd_soc_dapm_context *dapm = w->dapm; - struct snd_soc_dapm_path *path = NULL; - struct snd_kcontrol *kcontrol; - struct snd_card *card = dapm->card->snd_card; - const char *prefix; - size_t prefix_len; + struct snd_soc_dapm_path *path; int ret; - struct snd_soc_dapm_widget_list *wlist; - int shared, wlistentries; - size_t wlistsize; - const char *name; if (w->num_kcontrols != 1) { dev_err(dapm->dev, @@ -631,65 +679,19 @@ static int dapm_new_mux(struct snd_soc_dapm_widget *w) return -EINVAL; } - shared = dapm_is_shared_kcontrol(dapm, w, &w->kcontrol_news[0], - &kcontrol); - if (kcontrol) { - wlist = kcontrol->private_data; - wlistentries = wlist->num_widgets + 1; - } else { - wlist = NULL; - wlistentries = 1; - } - wlistsize = sizeof(struct snd_soc_dapm_widget_list) + - wlistentries * sizeof(struct snd_soc_dapm_widget *), - wlist = krealloc(wlist, wlistsize, GFP_KERNEL); - if (wlist == NULL) { - dev_err(dapm->dev, - "ASoC: can't allocate widget list for %s\n", w->name); - return -ENOMEM; - } - wlist->num_widgets = wlistentries; - wlist->widgets[wlistentries - 1] = w; - - if (!kcontrol) { - if (dapm->codec) - prefix = dapm->codec->name_prefix; - else - prefix = NULL; - - if (shared) { - name = w->kcontrol_news[0].name; - prefix_len = 0; - } else { - name = w->name; - if (prefix) - prefix_len = strlen(prefix) + 1; - else - prefix_len = 0; - } - - /* - * The control will get a prefix from the control creation - * process but we're also using the same prefix for widgets so - * cut the prefix off the front of the widget name. - */ - kcontrol = snd_soc_cnew(&w->kcontrol_news[0], wlist, - name + prefix_len, prefix); - ret = snd_ctl_add(card, kcontrol); - if (ret < 0) { - dev_err(dapm->dev, "ASoC: failed to add kcontrol %s: %d\n", - w->name, ret); - kfree(wlist); - return ret; - } + path = list_first_entry(&w->sources, struct snd_soc_dapm_path, + list_sink); + if (!path) { + dev_err(dapm->dev, "ASoC: mux %s has no paths\n", w->name); + return -EINVAL; } - kcontrol->private_data = wlist; - - w->kcontrols[0] = kcontrol; + ret = dapm_create_or_share_mixmux_kcontrol(w, 0, path); + if (ret < 0) + return ret; list_for_each_entry(path, &w->sources, list_sink) - path->kcontrol = kcontrol; + path->kcontrol = w->kcontrols[0]; return 0; } -- 1.7.10.4

2 1

[alsa-devel] Guide to USB debugging in Windows?
by Martin Cracauer 30 Mar '13

30 Mar '13

Does anyone have instructions on how to use a USB traffic monitor on windows to extract some bits needed to control a sound device under ALSA? As in, for people not normally developing in windows? I have here a Sound Devices USBPre v1. It is mostly USB 1.1 sound interface compatible and it accepts a stream played from ALSA under Linux just fine. The problem is that the manufacturer has decided to, in addition to the standard usb sound interface, have all the different inputs on the device behind on/off switches, all of them controlled by secret bits in the windows and mac drivers, all of them default to off. So thingie is a brick as-is. I don't blame them too hard, they now make a v2 of this devices and fixed it. Just so that I don't appear more insane than usual, let me say why I want to bother. The windows drivers for this are only available in 32 bit, and the mac drivers are 32 bit only as well, in addition the mac drivers never went > 16bit/48KHz. The inability to use this on modern macs and windows machines has pushed the price of these things very low on Ebay, considering it is a fully professional device with the best mic preamps you can get. If would be really cool if this could work under ALSA, and as you see I figured it needs just a couple of bits that you need to flip with some magic to at least get it to run up to 16bit/48KHz. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/

3 2

[alsa-devel] [PATCH v2] ASoC: mid-x86 - add support for meaadata apis
by Vinod Koul 29 Mar '13

29 Mar '13

while at it, update the copyright timeline too Signed-off-by: Jeeja KP <jeeja.kp(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- v2: fix the missing header inclusion in patch sound/soc/mid-x86/sst_platform.c | 12 +++++++++++- sound/soc/mid-x86/sst_platform.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletions(-) diff --git a/sound/soc/mid-x86/sst_platform.c b/sound/soc/mid-x86/sst_platform.c index a263cbe..968656c 100644 --- a/sound/soc/mid-x86/sst_platform.c +++ b/sound/soc/mid-x86/sst_platform.c @@ -1,7 +1,7 @@ /* * sst_platform.c - Intel MID Platform driver * - * Copyright (C) 2010-2012 Intel Corp + * Copyright (C) 2010-2013 Intel Corp * Author: Vinod Koul <vinod.koul(a)intel.com> * Author: Harsha Priya <priya.harsha(a)intel.com> * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -652,11 +652,21 @@ static int sst_platform_compr_get_codec_caps(struct snd_compr_stream *cstream, return stream->compr_ops->get_codec_caps(codec); } +static int sst_platform_compr_set_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct sst_runtime_stream *stream = + cstream->runtime->private_data; + + return stream->compr_ops->set_metadata(stream->id, metadata); +} + static struct snd_compr_ops sst_platform_compr_ops = { .open = sst_platform_compr_open, .free = sst_platform_compr_free, .set_params = sst_platform_compr_set_params, + .set_metadata = sst_platform_compr_set_metadata, .trigger = sst_platform_compr_trigger, .pointer = sst_platform_compr_pointer, .ack = sst_platform_compr_ack, diff --git a/sound/soc/mid-x86/sst_platform.h b/sound/soc/mid-x86/sst_platform.h index d61c5d5..cacc906 100644 --- a/sound/soc/mid-x86/sst_platform.h +++ b/sound/soc/mid-x86/sst_platform.h @@ -124,6 +124,8 @@ struct compress_sst_ops { int (*close) (unsigned int str_id); int (*get_caps) (struct snd_compr_caps *caps); int (*get_codec_caps) (struct snd_compr_codec_caps *codec); + int (*set_metadata) (unsigned int str_id, + struct snd_compr_metadata *mdata); }; -- 1.7.0.4

2 1

[alsa-devel] [PATCH] ASoC: wm_adsp: Split ADSP1 and ADSP2 firmware controls
by Mark Brown 29 Mar '13

29 Mar '13

Now that we have regular register mapped controls we should be splitting the control sets for ADSP1 and ADSP2 as the register maps are not identical. Do that. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm2200.c | 2 +- sound/soc/codecs/wm5102.c | 2 +- sound/soc/codecs/wm_adsp.c | 26 +++++++++++++++++++------- sound/soc/codecs/wm_adsp.h | 3 ++- 4 files changed, 23 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index ddc98f0..57ba315 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -1565,7 +1565,7 @@ static int wm2200_probe(struct snd_soc_codec *codec) return ret; } - ret = snd_soc_add_codec_controls(codec, wm_adsp_fw_controls, 2); + ret = snd_soc_add_codec_controls(codec, wm_adsp1_fw_controls, 2); if (ret != 0) return ret; diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index d1b43eb..cb03cc4 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -1572,7 +1572,7 @@ static int wm5102_codec_probe(struct snd_soc_codec *codec) if (ret != 0) return ret; - ret = snd_soc_add_codec_controls(codec, wm_adsp_fw_controls, 2); + ret = snd_soc_add_codec_controls(codec, wm_adsp2_fw_controls, 2); if (ret != 0) return ret; diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 3a481fd..bc03bae 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -247,7 +247,18 @@ static const struct soc_enum wm_adsp_fw_enum[] = { SOC_ENUM_SINGLE(0, 3, ARRAY_SIZE(wm_adsp_fw_text), wm_adsp_fw_text), }; -static const struct soc_enum wm_adsp_rate_enum[] = { +const struct snd_kcontrol_new wm_adsp1_fw_controls[] = { + SOC_ENUM_EXT("DSP1 Firmware", wm_adsp_fw_enum[0], + wm_adsp_fw_get, wm_adsp_fw_put), + SOC_ENUM_EXT("DSP2 Firmware", wm_adsp_fw_enum[1], + wm_adsp_fw_get, wm_adsp_fw_put), + SOC_ENUM_EXT("DSP3 Firmware", wm_adsp_fw_enum[2], + wm_adsp_fw_get, wm_adsp_fw_put), +}; +EXPORT_SYMBOL_GPL(wm_adsp1_fw_controls); + +#if IS_ENABLED(CONFIG_SND_SOC_ARIZONA) +static const struct soc_enum wm_adsp2_rate_enum[] = { SOC_VALUE_ENUM_SINGLE(ARIZONA_DSP1_CONTROL_1, ARIZONA_DSP1_RATE_SHIFT, 0xf, ARIZONA_RATE_ENUM_SIZE, @@ -266,21 +277,22 @@ static const struct soc_enum wm_adsp_rate_enum[] = { arizona_rate_text, arizona_rate_val), }; -const struct snd_kcontrol_new wm_adsp_fw_controls[] = { +const struct snd_kcontrol_new wm_adsp2_fw_controls[] = { SOC_ENUM_EXT("DSP1 Firmware", wm_adsp_fw_enum[0], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP1 Rate", wm_adsp_rate_enum[0]), + SOC_ENUM("DSP1 Rate", wm_adsp2_rate_enum[0]), SOC_ENUM_EXT("DSP2 Firmware", wm_adsp_fw_enum[1], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP2 Rate", wm_adsp_rate_enum[1]), + SOC_ENUM("DSP2 Rate", wm_adsp2_rate_enum[1]), SOC_ENUM_EXT("DSP3 Firmware", wm_adsp_fw_enum[2], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP3 Rate", wm_adsp_rate_enum[2]), + SOC_ENUM("DSP3 Rate", wm_adsp2_rate_enum[2]), SOC_ENUM_EXT("DSP4 Firmware", wm_adsp_fw_enum[3], wm_adsp_fw_get, wm_adsp_fw_put), - SOC_ENUM("DSP4 Rate", wm_adsp_rate_enum[3]), + SOC_ENUM("DSP4 Rate", wm_adsp2_rate_enum[3]), }; -EXPORT_SYMBOL_GPL(wm_adsp_fw_controls); +EXPORT_SYMBOL_GPL(wm_adsp2_fw_controls); +#endif static struct wm_adsp_region const *wm_adsp_find_region(struct wm_adsp *dsp, int type) diff --git a/sound/soc/codecs/wm_adsp.h b/sound/soc/codecs/wm_adsp.h index cb8871a..9f90c9f 100644 --- a/sound/soc/codecs/wm_adsp.h +++ b/sound/soc/codecs/wm_adsp.h @@ -65,7 +65,8 @@ struct wm_adsp { .shift = num, .event = wm_adsp2_event, \ .event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD } -extern const struct snd_kcontrol_new wm_adsp_fw_controls[]; +extern const struct snd_kcontrol_new wm_adsp1_fw_controls[]; +extern const struct snd_kcontrol_new wm_adsp2_fw_controls[]; int wm_adsp1_init(struct wm_adsp *adsp); int wm_adsp2_init(struct wm_adsp *adsp, bool dvfs); -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: Implement mixer control sharing
by Stephen Warren 29 Mar '13

29 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> This is the equivalent of commit af46800 "ASoC: Implement mux control sharing", but applied to mixers instead of muxes. This allows a single control to affect multiple mixer widgets at once, which is useful when there is a single set of register bits that affects both multiple mixers in HW, for example both the L and R mixers of a stereo path. Without this, you either: 1) End up with multiple controls that affect the same register bits, but whose DAPM state falls out of sync with HW, since the DAPM state is only updated for the specific control that is modified, and not for other paths that are affected only by the other control. 2) False paths through DAPM, since you end up merging unconnected stereo paths together into a single widget which hosts the single control, and then branching back out again, thus conjoining the enable states of the two input paths. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- Mark, the goto here might be considered icky. It avoids heavy indent levels. Should I separate out the control creation part of dapm_new_mixer() into a separate function to avoid this? Also, this commit has the potential for user-space impact, since control names could change for existing drivers. However, in this case I suspect the affected controls wouldn't have worked very well anyway, since they'd be affected by one of the problems I mention in the commit description above anyway, so I doubt this will be a practical problem. FYI, this feature for muxes will be useful for the rt5640.c driver, which has a single register for the HPO MUX, which separately affects both a L and R path to the HP outputs. sound/soc/soc-dapm.c | 57 +++++++++++++++++++++++++++++++------------------- 1 file changed, 36 insertions(+), 21 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 33acd8b..9a87aa5 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -508,13 +508,15 @@ static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, static int dapm_new_mixer(struct snd_soc_dapm_widget *w) { struct snd_soc_dapm_context *dapm = w->dapm; - int i, ret = 0; + int i, ret; size_t name_len, prefix_len; struct snd_soc_dapm_path *path; struct snd_card *card = dapm->card->snd_card; const char *prefix; struct snd_soc_dapm_widget_list *wlist; + int shared, wlistentries; size_t wlistsize; + struct snd_kcontrol *kcontrol; if (dapm->codec) prefix = dapm->codec->name_prefix; @@ -531,7 +533,6 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) /* match name */ list_for_each_entry(path, &w->sources, list_sink) { - /* mixer/mux paths name must match control name */ if (path->name != (char *)w->kcontrol_news[i].name) continue; @@ -541,26 +542,41 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) continue; } + shared = dapm_is_shared_kcontrol(dapm, w, + &w->kcontrol_news[i], &kcontrol); + + if (kcontrol) { + wlist = kcontrol->private_data; + wlistentries = wlist->num_widgets + 1; + } else { + wlist = NULL; + wlistentries = 1; + } + wlistsize = sizeof(struct snd_soc_dapm_widget_list) + - sizeof(struct snd_soc_dapm_widget *), - wlist = kzalloc(wlistsize, GFP_KERNEL); + wlistentries * + sizeof(struct snd_soc_dapm_widget *), + wlist = krealloc(wlist, wlistsize, GFP_KERNEL); if (wlist == NULL) { dev_err(dapm->dev, "ASoC: can't allocate widget list for %s\n", w->name); return -ENOMEM; } - wlist->num_widgets = 1; - wlist->widgets[0] = w; + wlist->num_widgets = wlistentries; + wlist->widgets[wlistentries - 1] = w; + + if (kcontrol) + goto skip_new_control; /* add dapm control with long name. * for dapm_mixer this is the concatenation of the * mixer and kcontrol name. - * for dapm_mixer_named_ctl this is simply the - * kcontrol name. + * for dapm_mixer_named_ctl or shared controls, this + * is simply the kcontrol name. */ name_len = strlen(w->kcontrol_news[i].name) + 1; - if (w->id != snd_soc_dapm_mixer_named_ctl) + if (!shared && w->id != snd_soc_dapm_mixer_named_ctl) name_len += 1 + strlen(w->name); path->long_name = kmalloc(name_len, GFP_KERNEL); @@ -570,8 +586,7 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) return -ENOMEM; } - switch (w->id) { - default: + if (!shared && w->id != snd_soc_dapm_mixer_named_ctl) /* The control will get a prefix from * the control creation process but * we're also using the same prefix @@ -581,19 +596,15 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) snprintf((char *)path->long_name, name_len, "%s %s", w->name + prefix_len, w->kcontrol_news[i].name); - break; - case snd_soc_dapm_mixer_named_ctl: + else snprintf((char *)path->long_name, name_len, "%s", w->kcontrol_news[i].name); - break; - } ((char *)path->long_name)[name_len - 1] = '\0'; - path->kcontrol = snd_soc_cnew(&w->kcontrol_news[i], - wlist, path->long_name, - prefix); - ret = snd_ctl_add(card, path->kcontrol); + kcontrol = snd_soc_cnew(&w->kcontrol_news[i], wlist, + path->long_name, prefix); + ret = snd_ctl_add(card, kcontrol); if (ret < 0) { dev_err(dapm->dev, "ASoC: failed to add widget" " %s dapm kcontrol %s: %d\n", @@ -603,10 +614,14 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) path->long_name = NULL; return ret; } - w->kcontrols[i] = path->kcontrol; + +skip_new_control: + path->kcontrol = kcontrol; + kcontrol->private_data = wlist; + w->kcontrols[i] = kcontrol; } } - return ret; + return 0; } /* create new dapm mux control */ -- 1.7.10.4

2 1

[alsa-devel] [PATCH 1/2] ASoC: wm0010: Constify usage of firmware filenames
by Charles Keepax 29 Mar '13

29 Mar '13

Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm0010.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c index 40256b5..a5cd51f 100644 --- a/sound/soc/codecs/wm0010.c +++ b/sound/soc/codecs/wm0010.c @@ -342,7 +342,7 @@ static void byte_swap_64(u64 *data_in, u64 *data_out, u32 len) data_out[i] = cpu_to_be64(le64_to_cpu(data_in[i])); } -static int wm0010_firmware_load(char *name, struct snd_soc_codec *codec) +static int wm0010_firmware_load(const char *name, struct snd_soc_codec *codec) { struct spi_device *spi = to_spi_device(codec->dev); struct wm0010_priv *wm0010 = snd_soc_codec_get_drvdata(codec); -- 1.7.2.5

2 2

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Jussi Laako 28 Mar '13

28 Mar '13

Hi Andreas,> Now of course, with your heroic effort in creating a generic driver that > would help everyone, we have a mess. Some DACs expect little endian > (mine and others as well) and others (all that are based on Rigisystems > modules) big endian positions. OK, we actually have two separate endianess issues here, but only one with word lengths longer than 8-bit. We have the traditional byte order endianess and the bit order endianess. Of course from computer point of view order of bits in a byte is sort of separate issue. And now the two file formats used for DSD use opposite bit ordering, but being byte-based don't have the byte ordering issue. At worst we have four different sample format possibilities for word lengths longer than a byte... Either way, application will have to be able to reshuffle the bits for the other format. - Jussi

2 2

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Daniel Mack 28 Mar '13

28 Mar '13

On 28.03.2013 05:58, Andreas Koch wrote: > >> >> Andreas, >> >> Am I right to assume that in your case it's the same as for DoP, >> IOW, oldest in MSB? > > Good point - thanks for bringing it up - another can of worms. > With Windows having a little endian philosophy we started early on > with the first DSD workstation by putting the oldest sample in the > LSB position. ASIO came along and adopted the same thing, but then > extended support for the opposite as well. Rigisystems (offering OEM > modules for USB audio) came along about a year ago and insisted that > there is only their way, i.e. putting the oldest bit in the MSB > position. I tried to explain to them that there are already hundreds > of products out in the market that do it differently, but that didn't > matter to them. The result is that now we have implementations with > both. Up until now that was not a huge issue, because there is no > generic Windows driver and every hardware manufacturer had to have a > custom driver. > Now of course, with your heroic effort in creating a generic driver > that would help everyone, we have a mess. Some DACs expect little > endian (mine and others as well) and others (all that are based on > Rigisystems modules) big endian positions. > > Since the time I had the discussions with Rigisystems I didn't have > any further communication with them. Maybe it is a good idea to touch > base with them again and find out what the latest is. I will try my > contact there and let you know. Eek, what an utter mess. Just let me know what you find out. We then need to augment the number of DSD formats, but then again, we can also move the sample rate calculation table inside the ALSA kernel core instead. Takashi et al - please don't apply any of these patches yet (expecpt for the the indentation fixup) :) I guess we need some more spins on this. Thanks, Daniel

1 0

[alsa-devel] [PATCH] ALSA: hda - bug fix on return value when getting HDMI ELD info
by mengdong.lin＠intel.com 28 Mar '13

28 Mar '13

From: Mengdong Lin <mengdong.lin(a)intel.com> In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0. Otherwise it will be returned uninitialized as non-zero after ELD info is got successfully. Thus hdmi_present_sense() will always assume ELD info is invalid by mistake, and /proc file system cannot show the proper ELD info. This patch also let debug message show 'pin_eld->monitor_present' which is the real pin response to verb GET_PIN_SENSE. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c index 7dd8463..d0d7ac1 100644 --- a/sound/pci/hda/hda_eld.c +++ b/sound/pci/hda/hda_eld.c @@ -320,7 +320,7 @@ int snd_hdmi_get_eld(struct hda_codec *codec, hda_nid_t nid, unsigned char *buf, int *eld_size) { int i; - int ret; + int ret = 0; int size; /* diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 78e1827..de8ac5c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1196,7 +1196,7 @@ static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll) _snd_printd(SND_PR_VERBOSE, "HDMI status: Codec=%d Pin=%d Presence_Detect=%d ELD_Valid=%d\n", - codec->addr, pin_nid, eld->monitor_present, eld->eld_valid); + codec->addr, pin_nid, pin_eld->monitor_present, eld->eld_valid); if (eld->eld_valid) { if (snd_hdmi_get_eld(codec, pin_nid, eld->eld_buffer, -- 1.7.10.4

3 3

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 28 Mar '13

28 Mar '13

On 03/24/2013 03:50 AM, Andreas Koch wrote: > rate for PCM. If you plug that DAC into a Mac, the Mac will > automatically select 705.6kHz for PCM and then nothing will work because > the DAC doesn't support that in PCM. So then, the DAC would have to > define 2 complete interfaces: one for PCM and one for DSD. That OK, the difference is that I don't use UAC2 at all, but completely different protocol. So what I'm talking about is only how it looks from the driver towards the application... DoP could be implemented similar way inside the UAC driver using for example snd_pcm_hw_rule_add() between SNDRV_PCM_HW_PARAM_FORMAT and SNDRV_PCM_HW_PARAM_RATE. And maybe enabled as quirks? There are many devices having constraints between rate and channels. In this case we just have a constraint between rate and formats. Looking at the UAC driver there seems to be something a bit related: /* FIXME: there is no AC3 format defined yet */ // fp->formats = SNDRV_PCM_FMTBIT_AC3; fp->formats = SNDRV_PCM_FMTBIT_U8; /* temporary hack to receive byte streams */ - Jussi

2 2

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 28 Mar '13

28 Mar '13

Hi Andreas, On 24.03.2013 02:50, Andreas Koch wrote: > At 01:01 PM 3/23/2013, Jussi Laako wrote: >> On 03/22/2013 06:05 PM, Andreas Koch wrote: >>> The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for >>> 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz on >>> the DAC, >> >> I see, this is different from how I've been dealing with it. Since I >> always use uint8 format, but instead vary the rate to 352.8/705.6/etc... >> >> Just because it's much more straightforward form the application's >> perspective -> output rate is always bit rate divided by eight >> (=packet rate). And switch between uint8 / uint32 sample format >> equals to switch between DSD <-> PCM. > > Since the sample rate is defined on the interface level, not on the > alternate interface level, it becomes a problem to vary the sample > rate. For instance, for 5.6MHz DSD a sample rate of 705.6kHz would be > necessary with 8-bit data. But most likely the DAC will not support > that rate for PCM. If you plug that DAC into a Mac, the Mac will > automatically select 705.6kHz for PCM and then nothing will work > because the DAC doesn't support that in PCM. So then, the DAC would > have to define 2 complete interfaces: one for PCM and one for DSD. > That increases the size of the descriptor file (which can be a > problem with some hardware implementations) and increases the > overhead a bit during enumeration and sample rate queries. For the > hardware it is easier to bundle all into one single interface and > then define alternate interfaces for PCM and DSD. > Just my 2 cents from the hardware perspective. Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On that three formats, arbitrary samples can be transported, and the mapping between the configured sample rate and the resulting DSD rates would be as follows (please tell me if I'm correct): 352.8kHz 705.6KHz 1411.2KHz 8-bit 2.8MHz 5.6MHz 11.2MHz 16-bit 5.6MHz 11.2MHz 32-bit 11.2MHz So driver would mark a stream as DSD capable (8, 16, 32bit, depending on the USB descriptors), and then leave it up to the application to do the sample frequency determination according to the above table, and also as stated in the DoP document. Other drivers for more sound cards (presumable on other bus types) might follow. I think it's ok to handle it like this, because after all, what an application sets as sample rate for the stream is the number of actual words that are transported, where as the DSD rate is referring to bits/s. Jussi, for your application, that means that you'd have to add these 3 new formats, and teach your application that they can be used for DSD right away. The question is whether all DSD-capable USB DACs behave correctly in order to make this logic work. Andreas? Thanks, Daniel

2 1

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 28 Mar '13

28 Mar '13

On 03/27/2013 05:08 PM, Andreas Koch wrote: > Clearly, main stream is 2.8MHz DSD. But there are new A/D and D/A chips > becoming available that support up to 11.2MHz. So far I haven't really And many DACs actually support also the 48k-base rates of 3.0/6.1/12.2 MHz. But of course from API point of view that's trivial. - Jussi

1 0

[alsa-devel] [PATCH 1/2] alsa-lib: pcm.c: fix indentation
by Daniel Mack 28 Mar '13

28 Mar '13

Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- src/pcm/pcm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 05737d9..2963711 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -1634,11 +1634,11 @@ static const char *const snd_pcm_type_names[] = { PCMTYPE(LADSPA), PCMTYPE(DMIX), PCMTYPE(JACK), - PCMTYPE(DSNOOP), - PCMTYPE(IEC958), + PCMTYPE(DSNOOP), + PCMTYPE(IEC958), PCMTYPE(SOFTVOL), - PCMTYPE(IOPLUG), - PCMTYPE(EXTPLUG), + PCMTYPE(IOPLUG), + PCMTYPE(EXTPLUG), PCMTYPE(MMAP_EMUL), }; -- 1.8.1.4

2 2

[alsa-devel] [PATCH 1/2] ALSA: add DSD formats
by Daniel Mack 28 Mar '13

28 Mar '13

This patch adds two formats for Direct Stream Digital (DSD), a pulse-density encoding format which is described here: https://en.wikipedia.org/wiki/Direct_Stream_Digital DSD operates on 2.8, 5.6 or 11.2MHz sample rates and as a 1-bit stream. In order to provide a compatibility way for pushing samples of DSD type through ordinary PCM channels, the "DoP open Standard" was created. See http://www.dsd-guide.com for a copy of the documentation. The two new types describe streams that are capable of handling DSD samples in 8-bit or in 16-bit (or at a single or double data rate, respectively). For applications, the following mapping table is used to configure the DSD mode by selecting a combination of PCM sample rates and word lengths: 352.8kHz 705.6KHz 1411.2KHz 8-bit 2.8MHz 5.6MHz 11.2MHz 16-bit 5.6MHz 11.2MHz Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- include/sound/pcm.h | 2 ++ include/uapi/sound/asound.h | 4 +++- sound/core/pcm.c | 2 ++ 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index aa7b0a8..2dffd55 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -181,6 +181,8 @@ struct snd_pcm_ops { #define SNDRV_PCM_FMTBIT_G723_24_1B _SNDRV_PCM_FMTBIT(G723_24_1B) #define SNDRV_PCM_FMTBIT_G723_40 _SNDRV_PCM_FMTBIT(G723_40) #define SNDRV_PCM_FMTBIT_G723_40_1B _SNDRV_PCM_FMTBIT(G723_40_1B) +#define SNDRV_PCM_FMTBIT_DSD_U8 _SNDRV_PCM_FMTBIT(DSD_U8) +#define SNDRV_PCM_FMTBIT_DSD_U16 _SNDRV_PCM_FMTBIT(DSD_U16) #ifdef SNDRV_LITTLE_ENDIAN #define SNDRV_PCM_FMTBIT_S16 SNDRV_PCM_FMTBIT_S16_LE diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h index 1774a5c..f9b0d3f 100644 --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -214,7 +214,9 @@ typedef int __bitwise snd_pcm_format_t; #define SNDRV_PCM_FORMAT_G723_24_1B ((__force snd_pcm_format_t) 45) /* 1 sample in 1 byte */ #define SNDRV_PCM_FORMAT_G723_40 ((__force snd_pcm_format_t) 46) /* 8 Samples in 5 bytes */ #define SNDRV_PCM_FORMAT_G723_40_1B ((__force snd_pcm_format_t) 47) /* 1 sample in 1 byte */ -#define SNDRV_PCM_FORMAT_LAST SNDRV_PCM_FORMAT_G723_40_1B +#define SNDRV_PCM_FORMAT_DSD_U8 ((__force snd_pcm_format_t) 48) /* DSD in 1 byte */ +#define SNDRV_PCM_FORMAT_DSD_U16 ((__force snd_pcm_format_t) 49) /* DSD in 2 bytes */ +#define SNDRV_PCM_FORMAT_LAST SNDRV_PCM_FORMAT_DSD_16U #ifdef SNDRV_LITTLE_ENDIAN #define SNDRV_PCM_FORMAT_S16 SNDRV_PCM_FORMAT_S16_LE diff --git a/sound/core/pcm.c b/sound/core/pcm.c index 578327e..433efdb 100644 --- a/sound/core/pcm.c +++ b/sound/core/pcm.c @@ -209,6 +209,8 @@ static char *snd_pcm_format_names[] = { FORMAT(G723_24_1B), FORMAT(G723_40), FORMAT(G723_40_1B), + FORMAT(DSD_U8), + FORMAT(DSD_U16), }; const char *snd_pcm_format_name(snd_pcm_format_t format) -- 1.8.1.4

1 1

[alsa-devel] [PATCH 1/2 resend] ASoC: cs4271: switch to mute_stream
by Daniel Mack 28 Mar '13

28 Mar '13

Use the newly introduced mute_stream DAI operation, and don't mute the codec if it's called for the _CAPTURE stream. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Acked-by: Alexander Sverdlin <subaparts(a)yandex.ru> --- sound/soc/codecs/cs4271.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index ac0d3b4..03036b3 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -388,7 +388,7 @@ static int cs4271_hw_params(struct snd_pcm_substream *substream, return cs4271_set_deemph(codec); } -static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) +static int cs4271_mute_stream(struct snd_soc_dai *dai, int mute, int stream) { struct snd_soc_codec *codec = dai->codec; struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); @@ -396,6 +396,9 @@ static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) int val_a = 0; int val_b = 0; + if (stream != SNDRV_PCM_STREAM_PLAYBACK) + return 0; + if (mute) { val_a = CS4271_VOLA_MUTE; val_b = CS4271_VOLB_MUTE; @@ -442,7 +445,7 @@ static const struct snd_soc_dai_ops cs4271_dai_ops = { .hw_params = cs4271_hw_params, .set_sysclk = cs4271_set_dai_sysclk, .set_fmt = cs4271_set_dai_fmt, - .digital_mute = cs4271_digital_mute, + .mute_stream = cs4271_mute_stream, }; static struct snd_soc_dai_driver cs4271_dai = { -- 1.8.1.4

2 8

[alsa-devel] [PATCH v7] ASoC: soc-compress: Cancel delayed power down if needed
by Charles Keepax 28 Mar '13

28 Mar '13

When a new stream is being opened it is necessary to cancel any delayed power down of the audio. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- ARGH! White space error. Charles sound/soc/soc-compress.c | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index f9b2197..0f4cfce 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -198,6 +198,7 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, { struct snd_soc_pcm_runtime *rtd = cstream->private_data; struct snd_soc_platform *platform = rtd->platform; + struct snd_soc_dai *codec_dai = rtd->codec_dai; int ret = 0; mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass); @@ -211,19 +212,27 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, if (platform->driver->compr_ops && platform->driver->compr_ops->set_params) { ret = platform->driver->compr_ops->set_params(cstream, params); if (ret < 0) - goto out; + goto err; } if (rtd->dai_link->compr_ops && rtd->dai_link->compr_ops->set_params) { ret = rtd->dai_link->compr_ops->set_params(cstream); if (ret < 0) - goto out; + goto err; } snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_PLAYBACK, SND_SOC_DAPM_STREAM_START); -out: + /* cancel any delayed stream shutdown that is pending */ + rtd->pop_wait = 0; + mutex_unlock(&rtd->pcm_mutex); + + cancel_delayed_work_sync(&rtd->delayed_work); + + return ret; + +err: mutex_unlock(&rtd->pcm_mutex); return ret; } -- 1.7.2.5

2 1

[alsa-devel] [PATCH 1/3] ASoC: Constify the 'driver' field of snd_soc_platform
by Lars-Peter Clausen 28 Mar '13

28 Mar '13

The ASoC core does no not modify the driver of a platform. Making it const allows ASoC platform drivers to declare the snd_soc_platform_driver struct as const. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- include/sound/soc.h | 4 ++-- sound/soc/soc-core.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 1ffe9d4..e666119 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -373,7 +373,7 @@ int snd_soc_suspend(struct device *dev); int snd_soc_resume(struct device *dev); int snd_soc_poweroff(struct device *dev); int snd_soc_register_platform(struct device *dev, - struct snd_soc_platform_driver *platform_drv); + const struct snd_soc_platform_driver *platform_drv); void snd_soc_unregister_platform(struct device *dev); int snd_soc_register_codec(struct device *dev, const struct snd_soc_codec_driver *codec_drv, @@ -829,7 +829,7 @@ struct snd_soc_platform { const char *name; int id; struct device *dev; - struct snd_soc_platform_driver *driver; + const struct snd_soc_platform_driver *driver; struct mutex mutex; unsigned int suspended:1; /* platform is suspended */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 561d589..7bf21a1 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3905,7 +3905,7 @@ static void snd_soc_unregister_dais(struct device *dev, size_t count) * @platform: platform to register */ int snd_soc_register_platform(struct device *dev, - struct snd_soc_platform_driver *platform_drv) + const struct snd_soc_platform_driver *platform_drv) { struct snd_soc_platform *platform; -- 1.8.0

2 3

Re: [alsa-devel] [PATCH] ASoC: add RT5640 CODEC driver
by Mark Brown 28 Mar '13

28 Mar '13

On Tue, Mar 26, 2013 at 05:35:38PM -0600, Stephen Warren wrote: > Mark, a couple questions: > * Is the custom index_reg device attr file OK, or should I remove that? > * Do new CODEC drivers have to use regmap directly, or is using the ASoC > IO system still OK? Convert to regmap please - it looks like this ought to be using the paging support from a quick glance at what the register I/O stuff is doing. The device file appears to duplicate the register dump stuff and isn't suitable for sysfs anyway as it's not one value per file, it ought to be in debugfs. > +/* IN1/IN2 Input Type */ > +static const char * const rt5640_input_mode[] = { > + "Single ended", "Differential"}; This looks like platform data. > +static const char * const rt5640_data_select[] = { > + "Normal", "left copy to right", "right copy to left", "Swap"}; DAPM? > +/* DMIC */ > +static const char * const rt5640_dmic_mode[] = {"Disable", "DMIC1", "DMIC2"}; > + > +static const SOC_ENUM_SINGLE_DECL(rt5640_dmic_enum, 0, 0, rt5640_dmic_mode); DAPM? > +static int rt5640_vol_rescale_get(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct soc_mixer_control *mc = > + (struct soc_mixer_control *)kcontrol->private_value; > + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); > + unsigned int val = snd_soc_read(codec, mc->reg); > + > + ucontrol->value.integer.value[0] = VOL_RESCALE_MAX_VOL - > + ((val & RT5640_L_VOL_MASK) >> mc->shift); > + ucontrol->value.integer.value[1] = VOL_RESCALE_MAX_VOL - > + (val & RT5640_R_VOL_MASK); This looks like a range control. > +static int hp_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + switch (event) { > + case SND_SOC_DAPM_POST_PMU: > + break; > + > + case SND_SOC_DAPM_PRE_PMD: > + break; > + > + default: > + return 0; > + } > + return 0; > +} This does nothing, it should be removed. > +static int rt5640_set_dmic1_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + struct snd_soc_codec *codec = w->codec; > + > + switch (event) { > + case SND_SOC_DAPM_PRE_PMU: > + snd_soc_update_bits(codec, RT5640_GPIO_CTRL1, > + RT5640_GP2_PIN_MASK | RT5640_GP3_PIN_MASK, > + RT5640_GP2_PIN_DMIC1_SCL | RT5640_GP3_PIN_DMIC1_SDA); > + snd_soc_update_bits(codec, RT5640_DMIC, > + RT5640_DMIC_1L_LH_MASK | RT5640_DMIC_1R_LH_MASK | > + RT5640_DMIC_1_DP_MASK, > + RT5640_DMIC_1L_LH_FALLING | RT5640_DMIC_1R_LH_RISING | > + RT5640_DMIC_1_DP_IN1P); > + snd_soc_update_bits(codec, RT5640_DMIC, > + RT5640_DMIC_1_EN_MASK, RT5640_DMIC_1_EN); > + default: > + return 0; The last write there looks awfully like an enable but there's not any corresponding disable... > +static int rt5640_set_dmic2_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + struct snd_soc_codec *codec = w->codec; > + > + switch (event) { > + case SND_SOC_DAPM_PRE_PMU: > + snd_soc_update_bits(codec, RT5640_GPIO_CTRL1, > + RT5640_GP2_PIN_MASK | RT5640_GP4_PIN_MASK, > + RT5640_GP2_PIN_DMIC1_SCL | RT5640_GP4_PIN_DMIC2_SDA); There's a degree of overlap between these two functions... > +static const struct snd_soc_dapm_route rt5640_dapm_routes[] = { > + {"IN1P", NULL, "LDO2"}, > + {"IN2P", NULL, "LDO2"}, > + > + {"IN1P", NULL, "MIC1"}, > + {"IN1N", NULL, "MIC1"}, > + {"IN2P", NULL, "MIC2"}, > + {"IN2N", NULL, "MIC2"}, Are MIC1 and MIC2 pins on the device? It's a bit odd to have a single physical input feeding both sides of a differential path internally. > + {"DMIC L1", NULL, "DMIC CLK"}, > + {"DMIC L2", NULL, "DMIC CLK"}, Shouldn't the DMIC CLK widget be handling the clock enables/muxes from the DMIC event above? > +static int get_sdp_info(struct snd_soc_codec *codec, int dai_id) > +{ > + int ret = 0, val = snd_soc_read(codec, RT5640_I2S1_SDP); > + > + if (codec == NULL) > + return -EINVAL; No point in the NULL check immediately after a dereference. > + val = (val & RT5640_I2S_IF_MASK) >> RT5640_I2S_IF_SFT; > + switch (dai_id) { > + case RT5640_AIF1: > + if (val == RT5640_IF_123 || val == RT5640_IF_132 || > + val == RT5640_IF_113) > + ret |= RT5640_U_IF1; > + if (val == RT5640_IF_312 || val == RT5640_IF_213 || > + val == RT5640_IF_113) > + ret |= RT5640_U_IF2; > + if (val == RT5640_IF_321 || val == RT5640_IF_231) > + ret |= RT5640_U_IF3; The tree of if ( || || ) looks like a switch statement and should probably be written as such. > + frame_size = snd_soc_params_to_frame_size(params); > + if (frame_size < 0) { > + dev_err(codec->dev, "Unsupported frame size: %d\n", frame_size); > + return -EINVAL; > + } The error message here is confusing as a negative code is an errno not a frame size and it probably ought to be passed to the caller. > + bclk_ms = frame_size > 32 ? 1 : 0; Grumble. > +static int rt5640_prepare(struct snd_pcm_substream *substream, > + struct snd_soc_dai *dai) > +{ > + struct snd_soc_pcm_runtime *rtd = substream->private_data; > + struct snd_soc_codec *codec = rtd->codec; > + struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(codec); > + > + rt5640->aif_pu = dai->id; > + return 0; > +} This looks like only one DAI can be active at once, shouldn't there be some sort of checking for busy here? > + dai_sel = get_sdp_info(codec, dai->id); > + if (dai_sel < 0) { > + dev_err(codec->dev, "Failed to get sdp info: %d\n", dai_sel); > + return -EINVAL; > + } I suspect using dai->base (or just picking a suitable value for dai->id even) would be simpler. > + if (dai_sel & RT5640_U_IF1) { > + snd_soc_update_bits(codec, RT5640_I2S1_SDP, > + RT5640_I2S_MS_MASK | RT5640_I2S_BP_MASK | > + RT5640_I2S_DF_MASK, reg_val); > + } > + if (dai_sel & RT5640_U_IF2) { > + snd_soc_update_bits(codec, RT5640_I2S2_SDP, > + RT5640_I2S_MS_MASK | RT5640_I2S_BP_MASK | > + RT5640_I2S_DF_MASK, reg_val); > + } This looks like switch statements again, though (not having checked) I'd expect that there's just blocks of registers for each DAI and we could just work in terms of a base? > +/** > + * rt5640_pll_calc - Calcualte PLL M/N/K code. Typo. > + snd_soc_add_codec_controls(codec, rt5640_snd_controls, > + ARRAY_SIZE(rt5640_snd_controls)); Set in the driver structure. > +static int rt5640_resume(struct snd_soc_codec *codec) > +{ > + int ret = 0 ; > + > + codec->cache_sync = 1; > + ret = snd_soc_cache_sync(codec); > + if (ret) { > + dev_err(codec->dev, "Failed to sync cache: %d\n", ret); > + return ret; > + } > + rt5640_set_bias_level(codec, SND_SOC_BIAS_STANDBY); We also sync the cache in the bias management code. > +static int rt5640_i2c_probe(struct i2c_client *i2c, > + const struct i2c_device_id *id) > +{ > + struct rt5640_priv *rt5640; > + int ret; > + > + rt5640 = kzalloc(sizeof(struct rt5640_priv), GFP_KERNEL); > + if (NULL == rt5640) > + return -ENOMEM; devm_kzalloc() > +struct rt5640_pll_code { > + bool m_bp; /* Indicates bypass m code or not. */ > + int m_code; > + int n_code; > + int k_code; > +}; > + > +struct rt5640_priv { > + struct snd_soc_codec *codec; Move these into the body of the driver.

2 2

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 27 Mar '13

27 Mar '13

On 22.03.2013 17:05, Andreas Koch wrote: > Hi all, > > At 01:11 AM 3/22/2013, Daniel Mack wrote: >> Hi Jussi, >> Hi Andreas, >> >> On 21.03.2013 22:21, Jussi Laako wrote: >>> On 03/18/2013 03:49 PM, Daniel Mack wrote: >>>> Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that >>>> device. But given that there is no application for DSD in userspace >>>> either, we probably don't need to care. >>> >>> Yes there is? At least my application. And I'd be happy to support any >>> custom format created for the purpose... :) >> >> Ah, interesting. So what *are* you using right now for your transport in >> userspace? Is your application abusing standard PCM interfaces that are >> 'known' to be in fact DSD? How do other DACs expose their interfaces in >> the Linux world, and which ones did you test your application with? >> >> If there's actual need for a new SND_PCM_FORMAT, it would be easy to >> patch it through all the layers down to userspace. >> >>> I would propose to create custom 8-bit sample formats for DSD purposes, >>> similar to the ASIO formats. Practically two main ones, byte with oldest >>> bit in MSB and byte with oldest bit in LSB. And maybe the "DSD-wide" one >>> which is 8-bit DSD sample. >> >> Andreas, which modes does the MPD-3 accept exactly on its two 'raw data' >> interfaces? The only hint I have is that one of it is 8-bit and the >> other is 16-bit, but given the lack of a proper test setup for this >> format, I can't currently test anything. > > The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for > 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz > on the DAC, but then sends either 8 bits or 16 bits depending on the > DSD rate. Since 11.2MHz DSD is already on the horizon we may have to > change this to a single 8-bit raw interface and then vary the > underlying USB transfer sample rate between 1x, 2x, 4x 352.8kHz - > that would be more logical and straight forward for the hardware > implementation. This is only supported through my own driver for the > Windows platform which uses the standard ASIO interface that supports > DSD at those rates. Since the Mac OS only supports PCM streams and > nothing else I brought together a bunch of DAC manufacturers and > playback software developers to standardize a method to "cannibalize" > the PCM stream for DSD data. The method is described in the attached > and is now supported by most manufacturers. > This also has been implemented on a few Linux platforms (Auraliti for > instance). Even though the DoP standard works really well so far, it > is a "bandaid" and should only be used if there is no other choice. > If you guys are discussing implementing a dedicated data stream in > your driver for DSD, then I think this would be better and safer in the future. Is there any official stable download location for this document which we could link to from our documentation? Thanks, Daniel

1 0

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 27 Mar '13

27 Mar '13

On 27.03.2013 16:08, Andreas Koch wrote: > At 02:48 AM 3/27/2013, Daniel Mack wrote: >> On 27.03.2013 06:50, Andreas Koch wrote: >>> Hi Daniel >>> >>>> Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On >>>> that three formats, arbitrary samples can be transported, and the >>>> mapping between the configured sample rate and the resulting DSD rates >>>> would be as follows (please tell me if I'm correct): >>>> >>>> 352.8kHz 705.6KHz 1411.2KHz >>>> >>>> 8-bit 2.8MHz 5.6MHz 11.2MHz >>>> 16-bit 5.6MHz 11.2MHz >>>> 32-bit 11.2MHz >>>> >>>> So driver would mark a stream as DSD capable (8, 16, 32bit, depending on >>>> the USB descriptors), and then leave it up to the application to do the >>>> sample frequency determination according to the above table, and also as >>>> stated in the DoP document. Other drivers for more sound cards >>>> (presumable on other bus types) might follow. >>>> >>>> I think it's ok to handle it like this, because after all, what an >>>> application sets as sample rate for the stream is the number of actual >>>> words that are transported, where as the DSD rate is referring to bits/s. >>>> >>>> Jussi, for your application, that means that you'd have to add these 3 >>>> new formats, and teach your application that they can be used for DSD >>>> right away. >>>> >>>> The question is whether all DSD-capable USB DACs behave correctly in >>>> order to make this logic work. Andreas? >>> >>> If I understand this correctly then your driver would send the DSD >>> data in whatever format the DAC requests via its descriptors. The DSD >>> rate would either control the word length (8,16,32) or the underlying >>> sample rate (1x, 2x, 4x 352.8kHz). That would be the most flexible >>> implementation and I don't see why any hardware implementation would >>> have a problem with that. >> >> The question is whether all DACs would assume the same DSD rate as in >> the table above (ie, 8-bit, 352.8kHz == 2.8MHz DSD). > > I don't see how they could assume any different rate, so yes, that > seems a good assumption. Ok, good. >> And do we actually need a 32-bit format at all or is 8 and 16 enough? > > Clearly, main stream is 2.8MHz DSD. But there are new A/D and D/A > chips becoming available that support up to 11.2MHz. So far I > haven't really seen any performance gain with that, but one never > knows what improvements will be made in the future. If that is a > problem on your side I wouldn't spend so much time on it, but if it > is a matter of just adding a few lines then why not. It a bit in a 64bit field, so its a limited resource. If there's no need for it, I'll leave it out for now. I'll send out some trivial patches for DSD stream marking soon. Thanks, Daniel

1 0

Re: [alsa-devel] [PATCH 2/2] ARM: clk: imx35 sound admux_gate bugfix
by Mark Brown 27 Mar '13

27 Mar '13

On Wed, Mar 27, 2013 at 12:57:00PM +0100, Philipp Zabel wrote: > Am Mittwoch, den 27.03.2013, 12:22 +0100 schrieb Markus Pargmann: > > imx-ssi needs admux_gate clock to work on imx35. This patch registers > > this clock and enables it in the imx-ssi driver. > I have no idea what the admux_gate really is, but the ssi driver doesn't > seem like the right place. Isn't this more closely related to the > imx-audmux.c driver? This is a patch to the ASoC driver? I just ignored it since it said it was an ARM patch... Anyway, what I'd expect should be happening here is that the clock API walks up the tree enabling supply clocks - that would mean that either that code isn't there or there's a missing parent child relationship in the data.

2 3

[alsa-devel] [PATCH v6] ASoC: soc-compress: Cancel delayed power down if needed
by Charles Keepax 27 Mar '13

27 Mar '13

When a new stream is being opened it is necessary to cancel any delayed power down of the audio. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- Well hopefully sixth time lucky, generated against the asoc tree for-next branch. Charles sound/soc/soc-compress.c | 16 +++++++++++++--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index f9b2197..4b4b5fa 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -198,8 +198,10 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, { struct snd_soc_pcm_runtime *rtd = cstream->private_data; struct snd_soc_platform *platform = rtd->platform; + struct snd_soc_dai *codec_dai = rtd->codec_dai; int ret = 0; + mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass); /* first we call set_params for the platform driver @@ -211,19 +213,27 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, if (platform->driver->compr_ops && platform->driver->compr_ops->set_params) { ret = platform->driver->compr_ops->set_params(cstream, params); if (ret < 0) - goto out; + goto err; } if (rtd->dai_link->compr_ops && rtd->dai_link->compr_ops->set_params) { ret = rtd->dai_link->compr_ops->set_params(cstream); if (ret < 0) - goto out; + goto err; } snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_PLAYBACK, SND_SOC_DAPM_STREAM_START); -out: + /* cancel any delayed stream shutdown that is pending */ + rtd->pop_wait = 0; + mutex_unlock(&rtd->pcm_mutex); + + cancel_delayed_work_sync(&rtd->delayed_work); + + return ret; + +err: mutex_unlock(&rtd->pcm_mutex); return ret; } -- 1.7.2.5

1 0

[alsa-devel] [PATCH] ASoC: wm5102: Implement OSR support
by Mark Brown 27 Mar '13

27 Mar '13

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm5102.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index b7a3fdc..99972a5 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -612,6 +612,26 @@ static int wm5102_sysclk_ev(struct snd_soc_dapm_widget *w, return 0; } +static const char *wm5102_osr_text[] = { + "Low power", "Normal", "High performance", +}; + +static const unsigned int wm5102_osr_val[] = { + 0x0, 0x3, 0x5, +}; + +static const struct soc_enum wm5102_hpout_osr[] = { + SOC_VALUE_ENUM_SINGLE(ARIZONA_OUTPUT_PATH_CONFIG_1L, + ARIZONA_OUT1_OSR_SHIFT, 0xe00, 3, + wm5102_osr_text, wm5102_osr_val), + SOC_VALUE_ENUM_SINGLE(ARIZONA_OUTPUT_PATH_CONFIG_2L, + ARIZONA_OUT2_OSR_SHIFT, 0xe00, 3, + wm5102_osr_text, wm5102_osr_val), + SOC_VALUE_ENUM_SINGLE(ARIZONA_OUTPUT_PATH_CONFIG_3L, + ARIZONA_OUT3_OSR_SHIFT, 0xe00, 3, + wm5102_osr_text, wm5102_osr_val), +}; + #define WM5102_NG_SRC(name, base) \ SOC_SINGLE(name " NG HPOUT1L Switch", base, 0, 1, 0), \ SOC_SINGLE(name " NG HPOUT1R Switch", base, 1, 1, 0), \ @@ -761,6 +781,8 @@ ARIZONA_MIXER_CONTROLS("SPKOUTR", ARIZONA_OUT4RMIX_INPUT_1_SOURCE), ARIZONA_MIXER_CONTROLS("SPKDAT1L", ARIZONA_OUT5LMIX_INPUT_1_SOURCE), ARIZONA_MIXER_CONTROLS("SPKDAT1R", ARIZONA_OUT5RMIX_INPUT_1_SOURCE), +SOC_SINGLE("Speaker High Performance Switch", ARIZONA_OUTPUT_PATH_CONFIG_4L, + ARIZONA_OUT4_OSR_SHIFT, 1, 0), SOC_SINGLE("SPKDAT1 High Performance Switch", ARIZONA_OUTPUT_PATH_CONFIG_5L, ARIZONA_OUT5_OSR_SHIFT, 1, 0), @@ -790,6 +812,10 @@ SOC_DOUBLE_R_TLV("SPKDAT1 Digital Volume", ARIZONA_DAC_DIGITAL_VOLUME_5L, ARIZONA_DAC_DIGITAL_VOLUME_5R, ARIZONA_OUT5L_VOL_SHIFT, 0xbf, 0, digital_tlv), +SOC_VAL_ENUM("HPOUT1 OSR", wm5102_hpout_osr[0]), +SOC_VAL_ENUM("HPOUT2 OSR", wm5102_hpout_osr[1]), +SOC_VAL_ENUM("HPOUT3 OSR", wm5102_hpout_osr[2]), + SOC_ENUM("Output Ramp Up", arizona_out_vi_ramp), SOC_ENUM("Output Ramp Down", arizona_out_vd_ramp), -- 1.7.10.4

2 2

Re: [alsa-devel] [PATCH 2/2] ARM: clk: imx35 sound admux_gate bugfix
by Markus Pargmann 27 Mar '13

27 Mar '13

Hi Philipp, On Wed, Mar 27, 2013 at 12:57:00PM +0100, Philipp Zabel wrote: > Hi Markus, > > Am Mittwoch, den 27.03.2013, 12:22 +0100 schrieb Markus Pargmann: > > imx-ssi needs admux_gate clock to work on imx35. This patch registers > > this clock and enables it in the imx-ssi driver. > > I have no idea what the admux_gate really is, but the ssi driver doesn't > seem like the right place. Isn't this more closely related to the > imx-audmux.c driver? Actually admux clock is not audmux clock, that one is seperated. So I am not sure where this belongs. As imx-ssi was not working without it, I added it here. But you are right, I also spoke with Sascha and I will simply move the clock enable to imx35-dt.c. > > > A reboot without this patch results in a failing AC97 for example on > > pcm043. > > > > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> > > Cc: stable(a)vger.kernel.org > > --- > > arch/arm/mach-imx/clk-imx25.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx27.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx31.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx35.c | 6 ++++-- > > arch/arm/mach-imx/clk-imx51-imx53.c | 9 ++++++--- > > sound/soc/fsl/imx-ssi.c | 16 +++++++++++++++- > > sound/soc/fsl/imx-ssi.h | 2 ++ > > 7 files changed, 39 insertions(+), 12 deletions(-) > > > > diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c > > index 69858c7..174ff8b 100644 > > --- a/arch/arm/mach-imx/clk-imx25.c > > +++ b/arch/arm/mach-imx/clk-imx25.c > > @@ -285,8 +285,10 @@ int __init mx25_clocks_init(void) > > clk_register_clkdev(clk[lcdc_ipg], "ipg", "imx21-fb.0"); > > clk_register_clkdev(clk[lcdc_ahb], "ahb", "imx21-fb.0"); > > clk_register_clkdev(clk[wdt_ipg], NULL, "imx2-wdt.0"); > > - clk_register_clkdev(clk[ssi1_ipg], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_ipg], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_ipg], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_ipg], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > clk_register_clkdev(clk[esdhc1_ipg_per], "per", "sdhci-esdhc-imx25.0"); > > clk_register_clkdev(clk[esdhc1_ipg], "ipg", "sdhci-esdhc-imx25.0"); > > clk_register_clkdev(clk[esdhc1_ahb], "ahb", "sdhci-esdhc-imx25.0"); > > diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c > > index 30b3242..439d5bd 100644 > > --- a/arch/arm/mach-imx/clk-imx27.c > > +++ b/arch/arm/mach-imx/clk-imx27.c > > @@ -252,8 +252,10 @@ int __init mx27_clocks_init(unsigned long fref) > > clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); > > clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.2"); > > clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.2"); > > - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > clk_register_clkdev(clk[nfc_baud_gate], NULL, "imx27-nand.0"); > > clk_register_clkdev(clk[vpu_baud_gate], "per", "coda-imx27.0"); > > clk_register_clkdev(clk[vpu_ahb_gate], "ahb", "coda-imx27.0"); > > diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c > > index b5b65f3..478b33e 100644 > > --- a/arch/arm/mach-imx/clk-imx31.c > > +++ b/arch/arm/mach-imx/clk-imx31.c > > @@ -171,8 +171,10 @@ int __init mx31_clocks_init(unsigned long fref) > > clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1.0"); > > clk_register_clkdev(clk[sdhc1_gate], NULL, "imx31-mmc.0"); > > clk_register_clkdev(clk[sdhc2_gate], NULL, "imx31-mmc.1"); > > - clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > clk_register_clkdev(clk[firi_gate], "firi", NULL); > > clk_register_clkdev(clk[ata_gate], NULL, "pata_imx"); > > clk_register_clkdev(clk[rtic_gate], "rtic", NULL); > > diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c > > index b95898a..4ab18ac 100644 > > --- a/arch/arm/mach-imx/clk-imx35.c > > +++ b/arch/arm/mach-imx/clk-imx35.c > > @@ -233,8 +233,10 @@ int __init mx35_clocks_init(void) > > clk_register_clkdev(clk[kpp_gate], NULL, "imx-keypad"); > > clk_register_clkdev(clk[owire_gate], NULL, "mxc_w1"); > > clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma"); > > - clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi1_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[admux_gate], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[admux_gate], "admux", "imx-ssi.1"); > > /* i.mx35 has the i.mx21 type uart */ > > clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0"); > > clk_register_clkdev(clk[ipg], "ipg", "imx21-uart.0"); > > diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c > > index 0f39f8c..b413a1e 100644 > > --- a/arch/arm/mach-imx/clk-imx51-imx53.c > > +++ b/arch/arm/mach-imx/clk-imx51-imx53.c > > @@ -275,9 +275,12 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil, > > clk_register_clkdev(clk[usboh3_gate], "ipg", "imx-udc-mx51"); > > clk_register_clkdev(clk[usboh3_gate], "ahb", "imx-udc-mx51"); > > clk_register_clkdev(clk[nfc_gate], NULL, "imx51-nand"); > > - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0"); > > - clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1"); > > - clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "imx-ssi.2"); > > + clk_register_clkdev(clk[ssi1_ipg_gate], "ipg", "imx-ssi.0"); > > + clk_register_clkdev(clk[ssi2_ipg_gate], "ipg", "imx-ssi.1"); > > + clk_register_clkdev(clk[ssi3_ipg_gate], "ipg", "imx-ssi.2"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.0"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.1"); > > + clk_register_clkdev(clk[dummy], "admux", "imx-ssi.2"); > > I think those should be removed completely. If really needed, it should > rather be added to the device tree for i.MX5: Oh yes, I grepped for imx-ssi.. However next patch version will not touch any of the other imxs code. > > --- a/arch/arm/boot/dts/imx53.dtsi > +++ b/arch/arm/boot/dts/imx53.dtsi > @@ -162,7 +162,8 @@ > compatible = "fsl,imx53-ssi", "fsl,imx21-ssi"; > reg = <0x50014000 0x4000>; > interrupts = <30>; > - clocks = <&clks 49>; > + clocks = <&clks 49>, <&clks 0>; > + clock-names = "ipg", "admux"; > fsl,fifo-depth = <15>; > fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */ > status = "disabled"; > @@ -791,7 +792,8 @@ > compatible = "fsl,imx53-ssi", "fsl,imx21-ssi"; > reg = <0x63fcc000 0x4000>; > interrupts = <29>; > - clocks = <&clks 48>; > + clocks = <&clks 48>, <&clks 0>; > + clock-names = "ipg", "admux"; > fsl,fifo-depth = <15>; > fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */ > status = "disabled"; > @@ -815,7 +817,8 @@ > compatible = "fsl,imx53-ssi", "fsl,imx21-ssi"; > reg = <0x63fe8000 0x4000>; > interrupts = <96>; > - clocks = <&clks 50>; > + clocks = <&clks 50>, <&clks 0>; > + clock-names = "ipg", "admux"; > fsl,fifo-depth = <15>; > fsl,ssi-dma-events = <47 46 45 44>; /* TX0 RX0 TX1 RX1 */ > status = "disabled"; > > But again, I'm not convinced the ssi driver is the right place to enable > the "admux" gate. > > > clk_register_clkdev(clk[ssi_ext1_gate], "ssi_ext1", NULL); > > clk_register_clkdev(clk[ssi_ext2_gate], "ssi_ext2", NULL); > > clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma"); > > diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c > > index 55464a5..9f96785 100644 > > --- a/sound/soc/fsl/imx-ssi.c > > +++ b/sound/soc/fsl/imx-ssi.c > > @@ -535,7 +535,7 @@ static int imx_ssi_probe(struct platform_device *pdev) > > > > ssi->irq = platform_get_irq(pdev, 0); > > > > - ssi->clk = devm_clk_get(&pdev->dev, NULL); > > + ssi->clk = devm_clk_get(&pdev->dev, "ipg"); > > if (IS_ERR(ssi->clk)) { > > ret = PTR_ERR(ssi->clk); > > dev_err(&pdev->dev, "Cannot get the clock: %d\n", > > @@ -544,6 +544,15 @@ static int imx_ssi_probe(struct platform_device *pdev) > > } > > clk_prepare_enable(ssi->clk); > > > > + ssi->admux_clk = devm_clk_get(&pdev->dev, "admux"); > > + if (IS_ERR(ssi->admux_clk)) { > > + if (PTR_ERR(ssi->admux_clk) == -ENOMEM) > > + goto failed_admux_clk_mem; > > + ssi->admux_clk = NULL; > > + } else { > > + clk_prepare_enable(ssi->admux_clk); > > + } > > + > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > if (!res) { > > ret = -ENODEV; > > @@ -631,6 +640,9 @@ failed_pdev_fiq_alloc: > > failed_register: > > release_mem_region(res->start, resource_size(res)); > > failed_get_resource: > > + if (ssi->admux_clk) > > + clk_disable_unprepare(ssi->admux_clk); > > +failed_admux_clk_mem: > > clk_disable_unprepare(ssi->clk); > > failed_clk: > > > > @@ -652,6 +664,8 @@ static int imx_ssi_remove(struct platform_device *pdev) > > > > release_mem_region(res->start, resource_size(res)); > > clk_disable_unprepare(ssi->clk); > > + if (ssi->admux_clk) > > + clk_disable_unprepare(ssi->admux_clk); > > > > return 0; > > } > > diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h > > index dc114bd..3dfbd92 100644 > > --- a/sound/soc/fsl/imx-ssi.h > > +++ b/sound/soc/fsl/imx-ssi.h > > @@ -194,6 +194,8 @@ struct imx_ssi { > > > > struct snd_soc_dai *imx_ac97; > > struct clk *clk; > > + /* imx35 has a admux clock that has to be active for sound to work */ > > + struct clk *admux_clk; > > void __iomem *base; > > int irq; > > int fiq_enable; > > regards > Philipp > > Thanks, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

1 0

[alsa-devel] need help for PCM constraint/rules
by Takashi Sakamoto 27 Mar '13

27 Mar '13

Dear developers, I'm a newbile for this project and working for kernel land driver for Fireworks with ALSA framework. I need your help for constraint/rule of PCM component. Related source is: https://github.com/takaswie/snd-firewire-improve/blob/master/fireworks/fire… My device (AudioFirePre8) changes its channels according to sampling rate. For example: 32.0 - 48.0kHz : 16ch: efw->channels_sets[0] 88.2 - 96.0kHz : 12ch: efw->channels_sets[1] 176.4 - 192.0kHz : 10ch: efw->channels_sets[2] (but not available) The other devices such as AudioFire12 has the same number of channels (12ch)in each sampling rate. I managed to write this rule refering to rme9652.c but I cannot achieve my purpose. It's my glad to get some help about this. Regards Takashi Sakamoto o-takashi(a)sakamocchi.jp ======== Fireworks is Echo Audio's series of Firewire Audio interface. http://echoaudio.com/products/audiofire-pre8 It utilizes IEC 61883-1 and -6 in its implementation and familiar with current snd-firewire-lib.ko. FFADO also produce driver for it. It's a user-land implementation. http://www.ffado.org/ My aim is writing kernel-land driver for it with ALSA framework. Takashi Sakamoto o-takashi(a)sakamocchi.jp

2 4

[alsa-devel] [PATCH] ASoC: soc-compress: Cancel delayed power down if needed
by Charles Keepax 27 Mar '13

27 Mar '13

When a new stream is being opened it is necessary to cancel any delayed power down of the audio. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/soc-compress.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index f9fb112..eb8191b 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -194,6 +194,7 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, { struct snd_soc_pcm_runtime *rtd = cstream->private_data; struct snd_soc_platform *platform = rtd->platform; + struct snd_soc_dai *codec_dai = rtd->codec_dai; int ret = 0; mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass); @@ -216,6 +217,12 @@ static int soc_compr_set_params(struct snd_compr_stream *cstream, goto out; } + /* cancel any delayed stream shutdown that is pending */ + if (codec_dai->pop_wait) { + codec_dai->pop_wait = 0; + cancel_delayed_work(&rtd->delayed_work); + } + snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_PLAYBACK, SND_SOC_DAPM_STREAM_START); -- 1.7.2.5

2 8

[alsa-devel] [PATCH 0/2] ARM: imx35 clk bugfixes
by Markus Pargmann 27 Mar '13

27 Mar '13

Hi, Two bugfixes which enable needed clocks. In both cases the first boot worked because the clocks were enabled by default after powerup. After disabling the unused clocks in the boot process, some parts were not working anymore and device init for example after a reboot did not work. Regards, Markus

1 2

Re: [alsa-devel] Support for DSD streams
by Daniel Mack 27 Mar '13

27 Mar '13

On 24.03.2013 02:33, Andreas Koch wrote: > Hi Daniel, > > At 11:43 AM 3/23/2013, Daniel Mack wrote: >> Hi Andreas, >> >> On 23.03.2013 18:35, Andreas Koch wrote: >>>> Yes, understood. The thing is just that we shouldn't break exising >>>> solutions that already rely on this "bandaid". >>> >>> You wouldn't break any existing solution based on DoP, because that >>> solution is dealt with in the application on one side and the DAC on >>> the other side. The driver and USB transfer both think it is PCM data >>> that is being sent. >> >> Well, that was exactly the problem with your device. With the driver as >> it was, it exposed a PCM interface which is 16-bit wide, and that was >> picked by ALSA when playing 16-bit material (because ALSA takes whatever >> is offered by the hardware natively). > > Not quite - the 16-bit wide interface offered by my DAC is not PCM, > but raw data. For the correct quirks handling, I'd need to know whether all products with your vendor ID are DSD capable on alt interface settings > 1. Is that assumption correct or should I narrow it down to the product ID of the MPD-3? Thanks, Daniel

1 0

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 27 Mar '13

27 Mar '13

On 27.03.2013 06:50, Andreas Koch wrote: > Hi Daniel > >> Ok. So we could define 3 DSD formats, for 8-bit, 16-bit and 32-bit. On >> that three formats, arbitrary samples can be transported, and the >> mapping between the configured sample rate and the resulting DSD rates >> would be as follows (please tell me if I'm correct): >> >> 352.8kHz 705.6KHz 1411.2KHz >> >> 8-bit 2.8MHz 5.6MHz 11.2MHz >> 16-bit 5.6MHz 11.2MHz >> 32-bit 11.2MHz >> >> So driver would mark a stream as DSD capable (8, 16, 32bit, depending on >> the USB descriptors), and then leave it up to the application to do the >> sample frequency determination according to the above table, and also as >> stated in the DoP document. Other drivers for more sound cards >> (presumable on other bus types) might follow. >> >> I think it's ok to handle it like this, because after all, what an >> application sets as sample rate for the stream is the number of actual >> words that are transported, where as the DSD rate is referring to bits/s. >> >> Jussi, for your application, that means that you'd have to add these 3 >> new formats, and teach your application that they can be used for DSD >> right away. >> >> The question is whether all DSD-capable USB DACs behave correctly in >> order to make this logic work. Andreas? > > If I understand this correctly then your driver would send the DSD > data in whatever format the DAC requests via its descriptors. The DSD > rate would either control the word length (8,16,32) or the underlying > sample rate (1x, 2x, 4x 352.8kHz). That would be the most flexible > implementation and I don't see why any hardware implementation would > have a problem with that. The question is whether all DACs would assume the same DSD rate as in the table above (ie, 8-bit, 352.8kHz == 2.8MHz DSD). And do we actually need a 32-bit format at all or is 8 and 16 enough? > The only potential fly in the ointment is > that we assume that the raw data format means DSD. In other words, if > a DAC uses raw data for any other purpose with similar wordlength > and/or sample rate spec. then we are in trouble. The chance for that > is small though. As there's nothing the UAC2 spec helps us with, we have to live with quirks for that. Daniel

1 0

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Clemens Ladisch 27 Mar '13

27 Mar '13

Andreas Koch wrote: > ... your driver would send the DSD data in whatever format the DAC > requests via its descriptors. [...] The only potential fly in the > ointment is that we assume that the raw data format means DSD. Add some vendor-specific descriptor to specify that raw means DSD. Regards, Clemens

1 0

[alsa-devel] [PATCH] ASoC: export snd_soc_register_component
by Stephen Warren 26 Mar '13

26 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> Without this, modules will fail to link against those symbols. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/soc-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 7ae68b0..561d589 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -4195,6 +4195,7 @@ error_component_name: return ret; } +EXPORT_SYMBOL_GPL(snd_soc_register_component); /** * snd_soc_unregister_component - Unregister a component from the ASoC core @@ -4220,6 +4221,7 @@ found: dev_dbg(dev, "ASoC: Unregistered component '%s'\n", cmpnt->name); kfree(cmpnt->name); } +EXPORT_SYMBOL_GPL(snd_soc_unregister_component); /* Retrieve a card's name from device tree */ int snd_soc_of_parse_card_name(struct snd_soc_card *card, -- 1.7.10.4

2 1

[alsa-devel] [PATCH 0/53] ASoC: switch over to use snd_soc_register_component()
by Kuninori Morimoto 26 Mar '13

26 Mar '13

Hi Mark, Liam, Lars, Stephen These patches switch over to use snd_soc_register_component() instead of snd_soc_register_dai[s]() on all drivers Last patch moves snd_soc_[un]register_dai[s]() to non global function. I could compile test on some of them, but couldn't for all drivers These patches are based on asoc/topic/component branch Kuninori Morimoto (53): ASoC: switch over to use snd_soc_register_component() on atmel ssc ASoC: switch over to use snd_soc_register_component() on au1x i2sc ASoC: switch over to use snd_soc_register_component() on au1x psc-ac97 ASoC: switch over to use snd_soc_register_component() on au1x psc-i2s ASoC: switch over to use snd_soc_register_component() on au1x ac97c ASoC: switch over to use snd_soc_register_component() on bf6xx i2s ASoC: switch over to use snd_soc_register_component() on bf5xx ac97 ASoC: switch over to use snd_soc_register_component() on bf5xx i2s ASoC: switch over to use snd_soc_register_component() on bf5xx tdm ASoC: switch over to use snd_soc_register_component() on ep93xx ac97 ASoC: switch over to use snd_soc_register_component() on ep93xx i2s ASoC: switch over to use snd_soc_register_component() on davinci i2s ASoC: switch over to use snd_soc_register_component() on davinci vcif ASoC: switch over to use snd_soc_register_component() on davinci mcasp ASoC: switch over to use snd_soc_register_component() on dw i2s ASoC: switch over to use snd_soc_register_component() on mpc5200 ac97 ASoC: switch over to use snd_soc_register_component() on mpc5200 i2s ASoC: switch over to use snd_soc_register_component() on fsl ssi ASoC: switch over to use snd_soc_register_component() on imx ssi ASoC: switch over to use snd_soc_register_component() on jz4740 i2s ASoC: switch over to use snd_soc_register_component() on kirkwood i2s ASoC: switch over to use snd_soc_register_component() on sst ASoC: switch over to use snd_soc_register_component() on mxs saif ASoC: switch over to use snd_soc_register_component() on nuc900 ac97 ASoC: switch over to use snd_soc_register_component() on omap mcbsp ASoC: switch over to use snd_soc_register_component() on omap mcpdm ASoC: switch over to use snd_soc_register_component() on omap dmic ASoC: switch over to use snd_soc_register_component() on omap hdmi ASoC: switch over to use snd_soc_register_component() on pxa ssp ASoC: pxa2xx-ac97: move EXPORT_SYMBOL_GPL() next to definition ASoC: switch over to use snd_soc_register_component() on pxa2xx ac97 ASoC: switch over to use snd_soc_register_component() on pxa2xx i2s ASoC: switch over to use snd_soc_register_component() on mmp sspa ASoC: switch over to use snd_soc_register_component() on s6000 i2s ASoC: switch over to use snd_soc_register_component() on s3c24xx i2s ASoC: switch over to use snd_soc_register_component() on s3c i2s ASoC: switch over to use snd_soc_register_component() on s3c ac97 ASoC: switch over to use snd_soc_register_component() on samsung spdif ASoC: switch over to use snd_soc_register_component() on samsung i2s ASoC: switch over to use snd_soc_register_component() on samsung pcm ASoC: switch over to use snd_soc_register_component() on goni_wm8994 ASoC: switch over to use snd_soc_register_component() on sh4 ssi ASoC: switch over to use snd_soc_register_component() on sh4 siu ASoC: switch over to use snd_soc_register_component() on sh4 hac ASoC: switch over to use snd_soc_register_component() on spear spdif out ASoC: switch over to use snd_soc_register_component() on spear spdif in ASoC: switch over to use snd_soc_register_component() on tegra30 i2s ASoC: switch over to use snd_soc_register_component() on tegra20 spdif ASoC: switch over to use snd_soc_register_component() on tegra20 ac97 ASoC: switch over to use snd_soc_register_component() on tegra20 i2s ASoC: switch over to use snd_soc_register_component() on txx9aclc ac97 ASoC: switch over to use snd_soc_register_component() on ux500 msp ASoC: snd_soc_[un]register_dai[s]() become non global function include/sound/soc-dai.h | 8 -------- sound/soc/atmel/atmel_ssc_dai.c | 11 ++++++++--- sound/soc/au1x/ac97c.c | 9 +++++++-- sound/soc/au1x/i2sc.c | 9 +++++++-- sound/soc/au1x/psc-ac97.c | 9 +++++++-- sound/soc/au1x/psc-i2s.c | 9 +++++++-- sound/soc/blackfin/bf5xx-ac97.c | 9 +++++++-- sound/soc/blackfin/bf5xx-i2s.c | 9 +++++++-- sound/soc/blackfin/bf5xx-tdm.c | 9 +++++++-- sound/soc/blackfin/bf6xx-i2s.c | 9 +++++++-- sound/soc/cirrus/ep93xx-ac97.c | 9 +++++++-- sound/soc/cirrus/ep93xx-i2s.c | 9 +++++++-- sound/soc/davinci/davinci-i2s.c | 15 ++++++++++----- sound/soc/davinci/davinci-mcasp.c | 15 ++++++++++----- sound/soc/davinci/davinci-vcif.c | 11 ++++++++--- sound/soc/dwc/designware_i2s.c | 9 +++++++-- sound/soc/fsl/fsl_ssi.c | 11 ++++++++--- sound/soc/fsl/imx-ssi.c | 11 ++++++++--- sound/soc/fsl/mpc5200_psc_ac97.c | 8 ++++++-- sound/soc/fsl/mpc5200_psc_i2s.c | 9 +++++++-- sound/soc/jz4740/jz4740-i2s.c | 9 +++++++-- sound/soc/kirkwood/kirkwood-i2s.c | 11 ++++++++--- sound/soc/mid-x86/sst_platform.c | 8 ++++++-- sound/soc/mxs/mxs-saif.c | 11 ++++++++--- sound/soc/nuc900/nuc900-ac97.c | 9 +++++++-- sound/soc/omap/omap-dmic.c | 9 +++++++-- sound/soc/omap/omap-hdmi.c | 9 +++++++-- sound/soc/omap/omap-mcbsp.c | 9 +++++++-- sound/soc/omap/omap-mcpdm.c | 9 +++++++-- sound/soc/pxa/mmp-sspa.c | 9 +++++++-- sound/soc/pxa/pxa-ssp.c | 9 +++++++-- sound/soc/pxa/pxa2xx-ac97.c | 11 +++++++---- sound/soc/pxa/pxa2xx-i2s.c | 9 +++++++-- sound/soc/s6000/s6000-i2s.c | 9 +++++++-- sound/soc/samsung/ac97.c | 12 ++++++++---- sound/soc/samsung/goni_wm8994.c | 11 ++++++++--- sound/soc/samsung/i2s.c | 14 ++++++++++---- sound/soc/samsung/pcm.c | 11 ++++++++--- sound/soc/samsung/s3c-i2s-v2.c | 9 +++++---- sound/soc/samsung/s3c-i2s-v2.h | 7 ++++--- sound/soc/samsung/s3c2412-i2s.c | 12 +++++++++--- sound/soc/samsung/s3c24xx-i2s.c | 11 ++++++++--- sound/soc/samsung/spdif.c | 11 ++++++++--- sound/soc/sh/hac.c | 10 +++++++--- sound/soc/sh/siu_dai.c | 11 ++++++++--- sound/soc/sh/ssi.c | 10 +++++++--- sound/soc/soc-core.c | 12 ++++-------- sound/soc/spear/spdif_in.c | 9 +++++++-- sound/soc/spear/spdif_out.c | 9 +++++++-- sound/soc/tegra/tegra20_ac97.c | 15 ++++++++++----- sound/soc/tegra/tegra20_i2s.c | 15 ++++++++++----- sound/soc/tegra/tegra20_spdif.c | 15 ++++++++++----- sound/soc/tegra/tegra30_i2s.c | 15 ++++++++++----- sound/soc/txx9/txx9aclc-ac97.c | 9 +++++++-- sound/soc/ux500/ux500_msp_dai.c | 13 +++++++++---- 55 files changed, 405 insertions(+), 165 deletions(-)

6 137

[alsa-devel] [PATCH 1/2] ASoC: compress - add support for metadata apis
by Vinod Koul 26 Mar '13

26 Mar '13

From: Jeeja KP <jeeja.kp(a)intel.com> Compress core added metadata apis in 9727b4, so add same in ASoC Signed-off-by: Jeeja KP <jeeja.kp(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- Rebased on asoc-next sound/soc/soc-compress.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index b5b3db7..f9b2197 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -322,11 +322,38 @@ static int soc_compr_copy(struct snd_compr_stream *cstream, return ret; } +static int sst_compr_set_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct snd_soc_pcm_runtime *rtd = cstream->private_data; + struct snd_soc_platform *platform = rtd->platform; + int ret = 0; + + if (platform->driver->compr_ops && platform->driver->compr_ops->set_metadata) + ret = platform->driver->compr_ops->set_metadata(cstream, metadata); + + return ret; +} + +static int sst_compr_get_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct snd_soc_pcm_runtime *rtd = cstream->private_data; + struct snd_soc_platform *platform = rtd->platform; + int ret = 0; + + if (platform->driver->compr_ops && platform->driver->compr_ops->get_metadata) + ret = platform->driver->compr_ops->get_metadata(cstream, metadata); + + return ret; +} /* ASoC Compress operations */ static struct snd_compr_ops soc_compr_ops = { .open = soc_compr_open, .free = soc_compr_free, .set_params = soc_compr_set_params, + .set_metadata = sst_compr_set_metadata, + .get_metadata = sst_compr_get_metadata, .get_params = soc_compr_get_params, .trigger = soc_compr_trigger, .pointer = soc_compr_pointer, -- 1.7.0.4

2 2

[alsa-devel] [PATCH 00/14] ASoC: Cleanup dmaengine PCM users
by Lars-Peter Clausen 26 Mar '13

26 Mar '13

Hi, This series cleans up a few of the current users of the dmaengine pcm lib in order to make the introduction of a new more generic PCM dmaengine driver more straight forward. The series consists mainly of two types of changes. One is removing all unnecessary wrappers of snd_soc_dmaengine_close(). For some reason quite a few drivers started providing their own pcm_close callback, which does nothing but calls snd_soc_dmaengine_close, although snd_soc_dmaengine_close can be used directly as the pcm_close callback if nothing else needs to be done. The other is getting rid of snd_dmaengine_pcm_{get,set}_data(). These two functions were initially introduced to deal with a few oddball dmaengine drivers which require that data is passed to them via the private_data field of the channel and we had to keep the data allocated until the channel had been released. A few other driver started using these functions although there is no need to do so. E.g. some drivers just call snd_dmaengine_pcm_set_data(), but never attempt to read the data again using snd_dmaengine_pcm_get_data(). For the drivers, for which snd_dmaengine_pcm_{set,get}_data() was originally introduced, the responsibility of keeping the dma config allocated is shifted from the pcm driver to the i2s drivers. Which in turn makes the code much more straight forward since for most i2s drivers the dma config is either static or setup once at driver probe time. The series has only been compile tested, so please test these patches, especially the non trivial ones for ep93xx, mmp, imx and mxs. - Lars Lars-Peter Clausen (14): ASoC: ux500_pcm: Remove duplicated SNDRV_PCM_HW_PARAM_PERIODS constraint ASoC: spear_pcm: No need to wrap snd_dmaengine_pcm_close() ASoC: omap-pcm: No need to wrap snd_dmaengine_pcm_close() ASoC: tegra_pcm: No need to wrap snd_dmaengine_pcm_close() ASoC: ux500_pcm: No need to wrap snd_dmaengine_pcm_close() ASoC: atmel-pcm-dma: No need to wrap snd_dmaengine_pcm_close() ASoC: ux500_pcm: No need to use snd_dmaengine_pcm_set_data() ASoC: speaer_pcm: No need to use snd_dmaengine_pcm_set_data() ASoC: atmel-pcm-dma: Do not use snd_dmaengine_pcm_{set,get}_data() ASoC: ep93xx: Use ep93xx_dma_params instead of ep93xx_pcm_dma_params ASoC: mmp-pcm: Allocate dma filter parameters on the stack ASoC: imx-pcm: Embed the imx_dma_data struct in the dma_params struct ASoC: mxs: Embed the mxs_dma_data struct in the mxs_pcm_dma_params struct ASoC: dmaengine-pcm: Remove snd_dmaengine_pcm_{set,get}_data include/sound/dmaengine_pcm.h | 3 --- sound/soc/atmel/atmel-pcm-dma.c | 23 +++++++--------------- sound/soc/cirrus/edb93xx.c | 1 - sound/soc/cirrus/ep93xx-ac97.c | 9 +++++---- sound/soc/cirrus/ep93xx-i2s.c | 12 ++++++------ sound/soc/cirrus/ep93xx-pcm.c | 37 +++-------------------------------- sound/soc/cirrus/ep93xx-pcm.h | 20 ------------------- sound/soc/cirrus/simone.c | 2 -- sound/soc/cirrus/snappercl15.c | 1 - sound/soc/fsl/fsl_ssi.c | 17 ++++++++-------- sound/soc/fsl/imx-pcm-dma.c | 35 ++------------------------------- sound/soc/fsl/imx-pcm.h | 17 ++++++++++++++-- sound/soc/fsl/imx-ssi.c | 12 ++++++++---- sound/soc/mxs/mxs-pcm.c | 43 +++++------------------------------------ sound/soc/mxs/mxs-pcm.h | 4 +++- sound/soc/mxs/mxs-saif.c | 6 +++--- sound/soc/omap/omap-pcm.c | 8 +------- sound/soc/pxa/mmp-pcm.c | 33 +++++-------------------------- sound/soc/soc-dmaengine-pcm.c | 29 --------------------------- sound/soc/spear/spear_pcm.c | 18 ++--------------- sound/soc/tegra/tegra_pcm.c | 8 +------- sound/soc/ux500/ux500_pcm.c | 25 +----------------------- 22 files changed, 76 insertions(+), 287 deletions(-) delete mode 100644 sound/soc/cirrus/ep93xx-pcm.h -- 1.8.0

9 30

[alsa-devel] [PATCH] ASoC: omap: Call omap_mcbsp_set_threshold() from mcbsp hw_params
by Lars-Peter Clausen 26 Mar '13

26 Mar '13

The omap PCM driver provides a set_threshold callback which gets called by the PCM driver when either playback or capture is started. The only DAI driver which sets this callback is the mcbsp driver. This patch removes the callback from the PCM driver and moves the invocation of the omap_mcbsp_set_threshold() function to the mcbsp hw_params callback since this is the only place where the threshold size can change. Doing so allows us to use the default dmaengine PCM trigger callback in the omap PCM driver. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Only compile tested, but I don't see why it should not work Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/omap/omap-mcbsp.c | 12 +++++------- sound/soc/omap/omap-pcm.c | 33 +-------------------------------- sound/soc/omap/omap-pcm.h | 1 - 3 files changed, 6 insertions(+), 40 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 8d2defd..406fc87 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -62,24 +62,22 @@ enum { * Stream DMA parameters. DMA request line and port address are set runtime * since they are different between OMAP1 and later OMAPs */ -static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream) +static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream, + unsigned int packet_size) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *cpu_dai = rtd->cpu_dai; struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai); - struct omap_pcm_dma_data *dma_data; int words; - dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream); - /* * Configure McBSP threshold based on either: * packet_size, when the sDMA is in packet mode, or based on the * period size in THRESHOLD mode, otherwise use McBSP threshold = 1 * for mono streams. */ - if (dma_data->packet_size) - words = dma_data->packet_size; + if (packet_size) + words = packet_size; else words = 1; @@ -245,7 +243,6 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, return -EINVAL; } if (mcbsp->pdata->buffer_size) { - dma_data->set_threshold = omap_mcbsp_set_threshold; if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) { int period_words, max_thrsh; int divider = 0; @@ -276,6 +273,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, /* Use packet mode for non mono streams */ pkt_size = channels; } + omap_mcbsp_set_threshold(substream, pkt_size); } dma_data->packet_size = pkt_size; diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index c722c2e..1626fb7 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -129,37 +129,6 @@ static int omap_pcm_hw_free(struct snd_pcm_substream *substream) return 0; } -static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) -{ - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct omap_pcm_dma_data *dma_data; - int ret = 0; - - dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream); - - switch (cmd) { - case SNDRV_PCM_TRIGGER_START: - case SNDRV_PCM_TRIGGER_RESUME: - case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - /* Configure McBSP internal buffer usage */ - if (dma_data->set_threshold) - dma_data->set_threshold(substream); - break; - - case SNDRV_PCM_TRIGGER_STOP: - case SNDRV_PCM_TRIGGER_SUSPEND: - case SNDRV_PCM_TRIGGER_PAUSE_PUSH: - break; - default: - ret = -EINVAL; - } - - if (ret == 0) - ret = snd_dmaengine_pcm_trigger(substream, cmd); - - return ret; -} - static snd_pcm_uframes_t omap_pcm_pointer(struct snd_pcm_substream *substream) { snd_pcm_uframes_t offset; @@ -208,7 +177,7 @@ static struct snd_pcm_ops omap_pcm_ops = { .ioctl = snd_pcm_lib_ioctl, .hw_params = omap_pcm_hw_params, .hw_free = omap_pcm_hw_free, - .trigger = omap_pcm_trigger, + .trigger = snd_dmaengine_pcm_trigger, .pointer = omap_pcm_pointer, .mmap = omap_pcm_mmap, }; diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h index cabe74c..39e6e45 100644 --- a/sound/soc/omap/omap-pcm.h +++ b/sound/soc/omap/omap-pcm.h @@ -31,7 +31,6 @@ struct omap_pcm_dma_data { char *name; /* stream identifier */ int dma_req; /* DMA request line */ unsigned long port_addr; /* transmit/receive register */ - void (*set_threshold)(struct snd_pcm_substream *substream); int data_type; /* 8, 16, 32 (bits) or 0 to let omap-pcm * to decide the sDMA data type */ int packet_size; /* packet size only in PACKET mode */ -- 1.8.0

3 2

Re: [alsa-devel] [PATCH] ASoC: core: Fix to check return value of snd_soc_update_bits_locked()
by Mark Brown 26 Mar '13

26 Mar '13

On Tue, Mar 26, 2013 at 02:41:05PM +0900, Joonyoung Shim wrote: > It can be 0 or 1 return value of snd_soc_update_bits_locked() when it is > success. So just check return value is negative. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH -next] ASoC: arizona: remove duplicated include from arizona.c
by Mark Brown 26 Mar '13

26 Mar '13

On Tue, Mar 26, 2013 at 02:47:08PM +0800, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > Remove duplicated include. Applied, thanks.

1 0

[alsa-devel] ALSA regression Macbook Air 5, 2: No sound from the loudspeaker
by Daniel Wagner 26 Mar '13

26 Mar '13

Hi, I experience a regression on my Macbook Air 2012 model with the 3.9-rc kernels (v3.9-rc2-284-gaea8b5d) The symptoms are that there is just no sound from the loudspeakers. The headphone output works fine. I was able to pin point it down to one commit 1077a024 "ALSA: hda - Use generic parser for Cirrus codec" If I revert this one and all came back to work. By comparing the alsa-info.txt output I figured that there is something wrong with the GPIO settings on node 0x01: This is the excerpt with the previous patch mentioned reverted: Codec: Cirrus Logic CS4206 Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x10134206 Subsystem Id: 0x106b5600 Revision Id: 0x100302 No Modem Function Group found Default PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 CLKSTOP EPSS Power: setting=D0, actual=D0 GPIO: io=4, o=0, i=0, unsolicited=0, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 and here the output vanilla kernel: Codec: Cirrus Logic CS4206 Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x10134206 Subsystem Id: 0x106b5600 Revision Id: 0x100302 No Modem Function Group found Default PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 CLKSTOP EPSS Power: setting=D0, actual=D0 GPIO: io=4, o=0, i=0, unsolicited=0, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 The diff is "IO[3] data=1 vs data=0". I used then the patch function from the awesome hda-analyzer tool to patch this on the vanilla kernel and there suddenly I have output from the speakers. I don't know if someone else has reported this already or if there is already a fix. I was without internet for few days and didn't report this in time. If that is the case, sorry for the noise. The complete logs from hda-analyzer are here: http://www.monom.org/misc/alsa/alsa-info.txt-v3.9-rc2-284-gaea8b5d http://www.monom.org/misc/alsa/alsa-info.txt-revert-1077a024 cheers, daniel

1 1

[alsa-devel] channel swapping issue on OMAP3/TWL4030 is back
by Peter Meerwald 26 Mar '13

26 Mar '13

Hello, I'm running Linux 3.7 on a beagle-xm and observe very reproducible stereo channel swapping issue on playback of a stereo stream (one channel has a sine, the other is zero); the channel swap occurs on starting the playback with a scope I have observed that the audio data indeed swaps relative to the FSX; so the problem is on the I2S bus I see the issue with the TWL4030 audio codec; McBSP2 is slave, TWL4030 is master on a custom board I see the same issue with a TLV320AIC3104 on McBSP3 (have tried to configured the TLV320AIC3104 as slave and master, same channel swapping issue for both configs) the channel swapping issue has been discussed here, http://comments.gmane.org/gmane.linux.alsa.devel/82178, and patches have been pointed out for 2.6.32 it appears that the swapping issue is back, probably due to the DMA rework in recent kernel? can someone confirm the issue? any suggestions? thanks, regards, p. -- Peter Meerwald +43-664-2444418 (mobile)

4 11

[alsa-devel] [bug] sbawe: the PnP won't stop
by David Flater 26 Mar '13

26 Mar '13

I've got an ISA PnP SB AWE type card in a system with a non-working DMA 5. Without intervention, the Sound Blaster always gets the broken DMA. I have no BIOS options to control the allocation of DMAs, and the PnP configuration done within ALSA ignores /etc/isapnp.conf [*]. DMA 6 works fine if I can get sbawe to stop re-initializing the PnP and just use it. # Use setup from isapnp with dma16 moved to 6. modprobe snd-sbawe isapnp=0 port=0x220 mpu_port=0x330 fm_port=0x388 awe_port=0x620 irq=5 dma8=1 dma16=6 modprobe snd-emu8000-synth Problem is, regardless whether isapnp is 0 or 1, sbawe always PnPs the card and puts it back on broken DMA 5. If I have already got the card correctly configured with /sbin/isapnp beforehand, sbawe leaves the original resources tied up as a ghost card and allocates again (/proc/dma): 1: SoundBlaster - 8bit 2: floppy 3: SoundBlaster - 8bit 4: cascade 5: SoundBlaster - 16bit 6: SoundBlaster - 16bit To get it working I ripped the following lines of code out of kernel 3.8.4, blocking PnP completely. As for a proper nondestructive fix, I'm not sure whether the intent was (A) you were only supposed to get one of the two registrations, or (B) the PnP registration was not supposed to reinit everything if it was already set up. --- sound/isa/sb/sb16.c~ 2013-03-14 14:27:14.000000000 -0400 +++ sound/isa/sb/sb16.c 2013-03-23 20:18:50.137987332 -0400 @@ -674,13 +674,6 @@ #ifdef CONFIG_PNP if (!err) isa_registered = 1; - - err = pnp_register_card_driver(&sb16_pnpc_driver); - if (!err) - pnp_registered = 1; - - if (isa_registered) - err = 0; #endif return err; } [*] So is there a different config file for PnP within ALSA? -- DWF

1 1

Re: [alsa-devel] BUG: soft lockup when recording audio on MX28EVK with ASoC sgtl5000
by Fabio Estevam 26 Mar '13

26 Mar '13

Hi Hector, On Mon, Mar 25, 2013 at 7:52 AM, Hector Palacios <hector.palacios(a)digi.com> wrote: > Hello, > > I just tried recording audio on Freescale's MX28EVK that uses ASoC sgtl5000 > (kernel v3.8) with: > > arecord -M -f cd sound.wav --duration 10 > > and got a scheduler message: > > [ 789.041847] [sched_delayed] sched: RT throttling activated I have just tested arecord on 3.8,4 and I haven't seen the 'soft lockup' bug. However, I see that mxs saif gets busy after the record and any attempt to do an 'aplay' after the first arecord fails. With the attached patch applied I am able to do arecord/aplay sequence several times. I don't have a cable handy here to actually test if the sound is recorded properly or not. Could you please test it against 3.8.4? Thanks, Fabio Estevam

1 1

[alsa-devel] [PATCH 1/2] ASoC: tegra: add Tegra114 support to the AHUB driver
by Stephen Warren 25 Mar '13

25 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> Tegra114's AHUB shares a design with Tegra30, with the followin changes: * Supports more (10 vs. 4) bi-directional FIFO channels into RAM. * Requires a separate block of registers to support the above. * Supports more attached clients, i.e. new audio multiplexing and de-multiplexing modules. * Is affected by more clocks due to the above. This change fully defines the device tree binding changes required to represent these changes, and minimally extends the driver to support the new hardware, without exposing any of the new FIFO channels. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- .../bindings/sound/nvidia,tegra30-ahub.txt | 26 ++++++-- sound/soc/tegra/tegra30_ahub.c | 64 ++++++++++++++------ sound/soc/tegra/tegra30_ahub.h | 16 +++++ 3 files changed, 84 insertions(+), 22 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt index 1ac7b16..0e5c12c 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt @@ -1,12 +1,22 @@ NVIDIA Tegra30 AHUB (Audio Hub) Required properties: -- compatible : "nvidia,tegra30-ahub" +- compatible : "nvidia,tegra30-ahub", "nvidia,tegra114-ahub", etc. - reg : Should contain the register physical address and length for each of - the AHUB's APBIF registers and the AHUB's own registers. + the AHUB's register blocks. + - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks. + - Tegra114 requires an additional entry, for the APBIF2 register block. - interrupts : Should contain AHUB interrupt -- nvidia,dma-request-selector : The Tegra DMA controller's phandle and - request selector for the first APBIF channel. +- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each + entry contains the Tegra DMA controller's phandle and request selector. + If a single entry is present, the request selectors for the channels are + assumed to be contiguous, and increment from this value. + If multiple values are given, one value must be given per channel. +- clocks : Must contain an entry for each required entry in clock-names. +- clock-names : Must include the following entries: + - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0, + dam1, dam2, spdif_in. + - Tegra114: Additionally requires amx, adx. - ranges : The bus address mapping for the configlink register bus. Can be empty since the mapping is 1:1. - #address-cells : For the configlink bus. Should be <1>; @@ -25,7 +35,13 @@ ahub@70080000 { reg = <0x70080000 0x200 0x70080200 0x100>; interrupts = < 0 103 0x04 >; nvidia,dma-request-selector = <&apbdma 1>; - + clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>, + <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>, + <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>, + <&tegra_car 110>, <&tegra_car 162>; + clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2", + "i2s3", "i2s4", "dam0", "dam1", "dam2", + "spdif_in"; ranges; #address-cells = <1>; #size-cells = <1>; diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c index e5cfb4a..4405c3a 100644 --- a/sound/soc/tegra/tegra30_ahub.c +++ b/sound/soc/tegra/tegra30_ahub.c @@ -287,16 +287,27 @@ int tegra30_ahub_unset_rx_cif_source(enum tegra30_ahub_rxcif rxcif) } EXPORT_SYMBOL_GPL(tegra30_ahub_unset_rx_cif_source); -static const char * const configlink_clocks[] = { - "i2s0", - "i2s1", - "i2s2", - "i2s3", - "i2s4", - "dam0", - "dam1", - "dam2", - "spdif_in", +#define CLK_LIST_MASK_TEGRA30 BIT(0) +#define CLK_LIST_MASK_TEGRA114 BIT(1) + +#define CLK_LIST_MASK_TEGRA30_OR_LATER \ + (CLK_LIST_MASK_TEGRA30 | CLK_LIST_MASK_TEGRA114) + +static const struct { + const char *clk_name; + u32 clk_list_mask; +} configlink_clocks[] = { + { "i2s0", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s1", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s2", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s3", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s4", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "dam0", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "dam1", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "dam2", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "spdif_in", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "amx", CLK_LIST_MASK_TEGRA114 }, + { "adx", CLK_LIST_MASK_TEGRA114 }, }; #define LAST_REG(name) \ @@ -424,8 +435,24 @@ static const struct regmap_config tegra30_ahub_ahub_regmap_config = { .cache_type = REGCACHE_RBTREE, }; +static struct tegra30_ahub_soc_data soc_data_tegra30 = { + .clk_list_mask = CLK_LIST_MASK_TEGRA30, +}; + +static struct tegra30_ahub_soc_data soc_data_tegra114 = { + .clk_list_mask = CLK_LIST_MASK_TEGRA114, +}; + +static const struct of_device_id tegra30_ahub_of_match[] = { + { .compatible = "nvidia,tegra114-ahub", .data = &soc_data_tegra114 }, + { .compatible = "nvidia,tegra30-ahub", .data = &soc_data_tegra30 }, + {}, +}; + static int tegra30_ahub_probe(struct platform_device *pdev) { + const struct of_device_id *match; + const struct tegra30_ahub_soc_data *soc_data; struct clk *clk; int i; struct resource *res0, *res1, *region; @@ -436,16 +463,24 @@ static int tegra30_ahub_probe(struct platform_device *pdev) if (ahub) return -ENODEV; + match = of_match_device(tegra30_ahub_of_match, &pdev->dev); + if (!match) + return -EINVAL; + soc_data = match->data; + /* * The AHUB hosts a register bus: the "configlink". For this to * operate correctly, all devices on this bus must be out of reset. * Ensure that here. */ for (i = 0; i < ARRAY_SIZE(configlink_clocks); i++) { - clk = clk_get(&pdev->dev, configlink_clocks[i]); + if (!(configlink_clocks[i].clk_list_mask & + soc_data->clk_list_mask)) + continue; + clk = clk_get(&pdev->dev, configlink_clocks[i].clk_name); if (IS_ERR(clk)) { dev_err(&pdev->dev, "Can't get clock %s\n", - configlink_clocks[i]); + configlink_clocks[i].clk_name); ret = PTR_ERR(clk); goto err; } @@ -592,11 +627,6 @@ static int tegra30_ahub_remove(struct platform_device *pdev) return 0; } -static const struct of_device_id tegra30_ahub_of_match[] = { - { .compatible = "nvidia,tegra30-ahub", }, - {}, -}; - static const struct dev_pm_ops tegra30_ahub_pm_ops = { SET_RUNTIME_PM_OPS(tegra30_ahub_runtime_suspend, tegra30_ahub_runtime_resume, NULL) diff --git a/sound/soc/tegra/tegra30_ahub.h b/sound/soc/tegra/tegra30_ahub.h index e690e2e..7189be9 100644 --- a/sound/soc/tegra/tegra30_ahub.h +++ b/sound/soc/tegra/tegra30_ahub.h @@ -468,7 +468,23 @@ extern int tegra30_ahub_set_rx_cif_source(enum tegra30_ahub_rxcif rxcif, enum tegra30_ahub_txcif txcif); extern int tegra30_ahub_unset_rx_cif_source(enum tegra30_ahub_rxcif rxcif); +struct tegra30_ahub_soc_data { + u32 clk_list_mask; + /* + * FIXME: There are many more differences in HW, such as: + * - More APBIF channels. + * - Extra separate chunks of register address space to represent + * the extra APBIF channels. + * - More units connected to the AHUB, so that tegra30_ahub_[rt]xcif + * need expansion, coupled with there being more defined bits in + * the AHUB routing registers. + * However, the driver doesn't support those new features yet, so we + * don't represent them here yet. + */ +}; + struct tegra30_ahub { + const struct tegra30_ahub_soc_data *soc_data; struct device *dev; struct clk *clk_d_audio; struct clk *clk_apbif; -- 1.7.10.4

2 4

[alsa-devel] [PATCH] ASoC: imx-sgtl5000: use of_node to match cpu dai
by Shawn Guo 25 Mar '13

25 Mar '13

Since imx-sgtl5000 is only used on DT platform, it makes more sense to use cpu_of_node rather than cpu_dai_name to match cpu dai. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- sound/soc/fsl/imx-sgtl5000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c index 424347e..9584e78 100644 --- a/sound/soc/fsl/imx-sgtl5000.c +++ b/sound/soc/fsl/imx-sgtl5000.c @@ -148,7 +148,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) data->dai.stream_name = "HiFi"; data->dai.codec_dai_name = "sgtl5000"; data->dai.codec_of_node = codec_np; - data->dai.cpu_dai_name = dev_name(&ssi_pdev->dev); + data->dai.cpu_of_node = ssi_np; data->dai.platform_name = "imx-pcm-audio"; data->dai.init = &imx_sgtl5000_dai_init; data->dai.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | -- 1.7.9.5

2 1

Re: [alsa-devel] [Alsa-user] Audio-gd NFB-17.32 (VIA VT1731)
by Torstein Hegge 25 Mar '13

25 Mar '13

On Mon, Mar 25, 2013 at 08:38:16 +0100, Clemens Ladisch wrote: > Torstein Hegge wrote: > > I think we can conclude that the VIA VT1731 has the same issue as the > > C-Media CM6631. > > > > I'll add the VT1731 as one of the devices that needs a reset after > > sample rate change in the next iteration of the sample rate workaround > > patch. > > Why not just do it for all UAC 2 devices? If new devices that needs this just keeps popping up, that might indeed be the better solution. Torstein

1 0

[alsa-devel] No dmix/dsnoop on Intel ICH4/5 by default?
by Rene Herman 24 Mar '13

24 Mar '13

Good day. I'm out of touch of with alsa -- but should dmix/dsnoop still be enabled by default on hardware that doesn't do hardware mixing? It seems it isn't on my Intel ICH4: $ cat /proc/asound/cards 0 [ICH5 ]: ICH4 - Intel ICH5 Intel ICH5 with AD1980 at irq 17 1 [SAA7134 ]: SAA7134 - SAA7134 saa7134[0] at 0xe8200000 irq 22 I believe that it should be from /usr/share/alsa/cards/ICH4.conf, but I don't get mixing on this setup when using the "default" pcm... (which I may not mind at that much, but I was looking at some other sound-related problem and this has me rather confused) This is arch linux, with alsa-lib, -plugins and -utils 1.0.26 installed, using kernel 3.6.11-1-ARCH (ie, standard). Regards, Rene

4 11

[alsa-devel] [PATCH v4] ALSA: usb: Work around CM6631 sample rate change bug
by Torstein Hegge 24 Mar '13

24 Mar '13

The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sample rate while the interface is active. Reset the interface after setting the sampling frequency on sample rate changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous stream, causing distorted sound on sample rate changes. The reset is performed for all current C-Media UAC V2.0 devices, including CM6610, CM6620 and CM6631, but has only been tested with CM6631. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- Changes since v3: - Use given target rate instead of the new rate read from device when checking if a reset is needed. Some devices (at least Schiit Bifrost) doesn't report a reliable sample rate back right after setting a new rate. This appears to fix the issues with v3 of this patch with the Schiit, as reported by Chris Hermansen in http://thread.gmane.org/gmane.linux.alsa.user/36935/focus=37284 Changes since v2: - More USB ids covered. - int crate -> int cur_rate - unsigned int previous_rate -> int prev_rate sound/usb/clock.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/sound/usb/clock.c b/sound/usb/clock.c index 5e634a2..60c2775 100644 --- a/sound/usb/clock.c +++ b/sound/usb/clock.c @@ -253,7 +253,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, { struct usb_device *dev = chip->dev; unsigned char data[4]; - int err, crate; + int err, cur_rate, prev_rate; int clock = snd_usb_clock_find_source(chip, fmt->clock); if (clock < 0) @@ -266,6 +266,18 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return -ENXIO; } + if ((err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, + USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, + UAC2_CS_CONTROL_SAM_FREQ << 8, + snd_usb_ctrl_intf(chip) | (clock << 8), + data, sizeof(data))) < 0) { + snd_printk(KERN_WARNING "%d:%d:%d: cannot get freq (v2)\n", + dev->devnum, iface, fmt->altsetting); + return err; + } + + prev_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + data[0] = rate; data[1] = rate >> 8; data[2] = rate >> 16; @@ -290,9 +302,39 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return err; } - crate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); - if (crate != rate) - snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate); + cur_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + if (cur_rate != rate) { + snd_printd(KERN_WARNING + "current rate %d is different from the runtime rate %d\n", + cur_rate, rate); + } + + /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + if (rate != prev_rate) { + switch (chip->usb_id) { + /* C-Media CM6610/CM6620/CM6631 */ + case USB_ID(0x054c, 0x06cf): /* Sony */ + case USB_ID(0x0b05, 0x17a8): /* Asus Xonar Essence One */ + case USB_ID(0x0d8c, 0x0301): + case USB_ID(0x0d8c, 0x0302): + case USB_ID(0x0d8c, 0x0304): /* CM6631 (Schiit) */ + case USB_ID(0x0d8c, 0x0305): + case USB_ID(0x0d8c, 0x0306): + case USB_ID(0x0d8c, 0x0309): /* CM6631 */ + case USB_ID(0x0d8c, 0x0310): + case USB_ID(0x0d8c, 0x0311): /* CM6610A */ + case USB_ID(0x0d8c, 0x0312): /* CM6620A */ + case USB_ID(0x0d8c, 0x0313): /* CM6630A */ + case USB_ID(0x0d8c, 0x0314): /* CM6631A */ + case USB_ID(0x0d8c, 0x0315): /* CM6632A */ + case USB_ID(0x0d8c, 0x0319): /* CM6631A */ + case USB_ID(0x200c, 0x1030): /* Reloop */ + usb_set_interface(dev, iface, 0); + usb_set_interface(dev, iface, fmt->altsetting); + break; + } + } return 0; } -- 1.7.10.4

2 2

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 23 Mar '13

23 Mar '13

On 03/22/2013 06:05 PM, Andreas Koch wrote: > The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for > 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz on > the DAC, I see, this is different from how I've been dealing with it. Since I always use uint8 format, but instead vary the rate to 352.8/705.6/etc... Just because it's much more straightforward form the application's perspective -> output rate is always bit rate divided by eight (=packet rate). And switch between uint8 / uint32 sample format equals to switch between DSD <-> PCM. - Jussi

1 0

[alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 23 Mar '13

23 Mar '13

Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb. The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'. The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected. Also, those devices need a 50ms delay after switching the USB interface. Thanks, Daniel Daniel Mack (3): ALSA: snd-usb: handle the bmFormats field as unsigned int ALSA: snd-usb: handle raw data format of UAC2 devices ALSA: snd-usb: add delay quirk for "Playback Design" products include/linux/usb/audio-v2.h | 2 ++ sound/usb/format.c | 20 ++++++++++++-------- sound/usb/format.h | 2 +- sound/usb/pcm.c | 7 +++++++ sound/usb/stream.c | 2 +- 5 files changed, 23 insertions(+), 10 deletions(-) -- 1.7.10.4

4 16

Re: [alsa-devel] Support for DSD streams
by Daniel Mack 23 Mar '13

23 Mar '13

Hi Andreas, On 23.03.2013 18:35, Andreas Koch wrote: >> Yes, understood. The thing is just that we shouldn't break exising >> solutions that already rely on this "bandaid". > > You wouldn't break any existing solution based on DoP, because that > solution is dealt with in the application on one side and the DAC on > the other side. The driver and USB transfer both think it is PCM data > that is being sent. Well, that was exactly the problem with your device. With the driver as it was, it exposed a PCM interface which is 16-bit wide, and that was picked by ALSA when playing 16-bit material (because ALSA takes whatever is offered by the hardware natively). > The applications have a preference setting to > select DoP and likewise the DAC's constantly monitor the PCM > formatted data stream and automatically switch to DSD if they find > the pattern. Hmm, but your device behaves differently here, right? At least, when normal PCM material is sent to the DSD interface, it doesn't play it or switch back or something. And I think other DACs will have similar behaviour. I need to think about all that more deeply next week :) Daniel

1 0

Re: [alsa-devel] ASoC: tegra: Does the PCM_TRIGGER_{PAUSE, RESUME} emulation really work?
by Lars-Peter Clausen 23 Mar '13

23 Mar '13

On 03/23/2013 02:28 PM, Laxman Dewangan wrote: > On Saturday 23 March 2013 06:59 PM, Lars-Peter Clausen wrote: >> On 03/23/2013 02:16 PM, Laxman Dewangan wrote: >>> On Saturday 23 March 2013 05:05 AM, Stephen Warren wrote: >>>> On 03/22/2013 10:26 AM, Lars-Peter Clausen wrote: >>>>> Hi, >>>>> >>>>> The tegra pcm driver tries to emulate SNDRV_PCM_TRIGGER_PAUSE and >>>>> SNDRV_PCM_TRIGGER_RESUME. By passing SNDRV_PCM_TRIGGER_START and >>>>> SNDRV_PCM_TRIGGER_STOP to snd_dmaengine_pcm_trigger. But does this really >>>>> work? The old non-dmaengine based driver implemented this properly. I'd >>>>> reset the dma position pointer for SNDRV_PCM_TRIGGER_START, but keep it >>>>> where it was for SNDRV_PCM_TRIGGER_RESUME. But as far as I can see with >>>>> the >>>>> dmaengine based driver the pointer always gets reset to 0 for both >>>>> SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_RESUME. >>>> It's quite possible this hasn't been tested, or tested recently. I don't >>>> recall how to test PAUSE/RESUME. Can you enlighten me? >>>> >>>> Laxman, can you comment here? >>> The tegra20/Tegra30 does not support the pause of the channel. It was >>> through global pause. hence the pause and resume is implemented like stop >>> transfer and again restart transfer. hence you are seeing this as the reset >>> pointer as 0. >>> >> Yea, but in that case you shouldn't implement pause/resume at all. You've >> changed the semantics on pause/resume on which applications rely. If >> pause/resume are not implemented applications usually workaround it. >> >> - Lars >> > > So should we return -EINVAL in case of following? > > case SNDRV_PCM_TRIGGER_RESUME: > case SNDRV_PCM_TRIGGER_PAUSE_PUSH: > Don't set the SNDRV_PCM_INFO_PAUSE and SNDRV_PCM_INFO_RESUME bits in the pcm_hardware struct and use snd_dmaengine_pcm_trigger as your trigger callback. The ALSA core will take care of everything else. - Lars

1 0

Re: [alsa-devel] ASoC: tegra: Does the PCM_TRIGGER_{PAUSE, RESUME} emulation really work?
by Lars-Peter Clausen 23 Mar '13

23 Mar '13

On 03/23/2013 02:16 PM, Laxman Dewangan wrote: > On Saturday 23 March 2013 05:05 AM, Stephen Warren wrote: >> On 03/22/2013 10:26 AM, Lars-Peter Clausen wrote: >>> Hi, >>> >>> The tegra pcm driver tries to emulate SNDRV_PCM_TRIGGER_PAUSE and >>> SNDRV_PCM_TRIGGER_RESUME. By passing SNDRV_PCM_TRIGGER_START and >>> SNDRV_PCM_TRIGGER_STOP to snd_dmaengine_pcm_trigger. But does this really >>> work? The old non-dmaengine based driver implemented this properly. I'd >>> reset the dma position pointer for SNDRV_PCM_TRIGGER_START, but keep it >>> where it was for SNDRV_PCM_TRIGGER_RESUME. But as far as I can see with the >>> dmaengine based driver the pointer always gets reset to 0 for both >>> SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_RESUME. >> It's quite possible this hasn't been tested, or tested recently. I don't >> recall how to test PAUSE/RESUME. Can you enlighten me? >> >> Laxman, can you comment here? > The tegra20/Tegra30 does not support the pause of the channel. It was > through global pause. hence the pause and resume is implemented like stop > transfer and again restart transfer. hence you are seeing this as the reset > pointer as 0. > Yea, but in that case you shouldn't implement pause/resume at all. You've changed the semantics on pause/resume on which applications rely. If pause/resume are not implemented applications usually workaround it. - Lars > So pause is stop and resume is the start again. > > If it is require to implement the dmaengine_pause/resume() then it can not > be done truely, it can be done atelast in resolution of one buffer transfer. > We can not stop dma in mid of buffer transfer and start from there. We can > do cancel of current buffer transfer and then start from begining of current > buffer, not from the point it was paused. > > However, tegra114 support this pause and resume truely.

1 0

[alsa-devel] Support for DSD streams (was: Re: [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work)
by Daniel Mack 23 Mar '13

23 Mar '13

Hi Andreas, On 22.03.2013 17:05, Andreas Koch wrote: > At 01:11 AM 3/22/2013, Daniel Mack wrote: >> Hi Jussi, >> Hi Andreas, >> >> On 21.03.2013 22:21, Jussi Laako wrote: >>> On 03/18/2013 03:49 PM, Daniel Mack wrote: >>>> Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that >>>> device. But given that there is no application for DSD in userspace >>>> either, we probably don't need to care. >>> >>> Yes there is? At least my application. And I'd be happy to support any >>> custom format created for the purpose... :) >> >> Ah, interesting. So what *are* you using right now for your transport in >> userspace? Is your application abusing standard PCM interfaces that are >> 'known' to be in fact DSD? How do other DACs expose their interfaces in >> the Linux world, and which ones did you test your application with? >> >> If there's actual need for a new SND_PCM_FORMAT, it would be easy to >> patch it through all the layers down to userspace. >> >>> I would propose to create custom 8-bit sample formats for DSD purposes, >>> similar to the ASIO formats. Practically two main ones, byte with oldest >>> bit in MSB and byte with oldest bit in LSB. And maybe the "DSD-wide" one >>> which is 8-bit DSD sample. >> >> Andreas, which modes does the MPD-3 accept exactly on its two 'raw data' >> interfaces? The only hint I have is that one of it is 8-bit and the >> other is 16-bit, but given the lack of a proper test setup for this >> format, I can't currently test anything. > > The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for > 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz > on the DAC, but then sends either 8 bits or 16 bits depending on the > DSD rate. And prior to sending either 8 bits or 16 bits, currently the correct USB alternate interface has to be set, right? > Since 11.2MHz DSD is already on the horizon we may have to > change this to a single 8-bit raw interface and then vary the > underlying USB transfer sample rate between 1x, 2x, 4x 352.8kHz - Yes, especially given that if there's no common standard across different devices, either the drivers or the applications have to implement special handling code for this, and know which interface supports what. So for the ALSA layer, we should probably have a generic SND_PCM_FORMAT_DSD and then rely on the sample rate setting mechanisms to select the right DSD mode. Other solutions, like having a different SND_PCM_FORMAT_DSD_{2_8,5_6,11_2}_MHZ would be hairy to implement, as some devices need to get a sample rate update request, while others don't etc ... > that would be more logical and straight forward for the hardware > implementation. This is only supported through my own driver for the > Windows platform which uses the standard ASIO interface that supports > DSD at those rates. Since the Mac OS only supports PCM streams and > nothing else I brought together a bunch of DAC manufacturers and > playback software developers to standardize a method to "cannibalize" > the PCM stream for DSD data. The method is described in the attached > and is now supported by most manufacturers. Very interesting read. For ALSA though, it's no problem to support that in all layers and make the drivers tell applications about it. We just have to decide for a sane way :) > This also has been implemented on a few Linux platforms (Auraliti for > instance). Even though the DoP standard works really well so far, it > is a "bandaid" and should only be used if there is no other choice. Yes, understood. The thing is just that we shouldn't break exising solutions that already rely on this "bandaid". Daniel

1 0

[alsa-devel] ASoC: tegra: Does the PCM_TRIGGER_{PAUSE, RESUME} emulation really work?
by Lars-Peter Clausen 23 Mar '13

23 Mar '13

Hi, The tegra pcm driver tries to emulate SNDRV_PCM_TRIGGER_PAUSE and SNDRV_PCM_TRIGGER_RESUME. By passing SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_STOP to snd_dmaengine_pcm_trigger. But does this really work? The old non-dmaengine based driver implemented this properly. I'd reset the dma position pointer for SNDRV_PCM_TRIGGER_START, but keep it where it was for SNDRV_PCM_TRIGGER_RESUME. But as far as I can see with the dmaengine based driver the pointer always gets reset to 0 for both SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_RESUME. - Lars

2 2

Re: [alsa-devel] [PATCH V2] Sound: sgtl5000 Allow codec clock frequency to be set.
by Timur Tabi 22 Mar '13

22 Mar '13

On Fri, Mar 22, 2013 at 4:33 AM, Martin Fuzzey <mfuzzey(a)parkeon.com> wrote: > diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c > index 424347e..71ce1f6 100644 > --- a/sound/soc/fsl/imx-sgtl5000.c > +++ b/sound/soc/fsl/imx-sgtl5000.c > @@ -128,18 +128,30 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) > goto fail; > } > > + ret = of_property_read_u32(codec_np, "clock-frequency", > + &data->clk_frequency); I just noticed that you assign 'ret' here, but you never check the value. So I think you should either: 1) Check the value of 'ret' 2) Remove the "ret = "

1 0

[alsa-devel] [PATCH 0/2] ASoC: dmaengine_pcm: support generic DMA binding users
by Shawn Guo 22 Mar '13

22 Mar '13

The series adds a snd_dmaengine_generic_pcm_open() for users that adopt generic DMA binding and helplers. Vinod, AS per the request from Mark, I add the first patch to mark name parameter of dmaengine helpers as const, so that clients can mark const on their side. We need to have these two patches on a topic branch, as I've heard a few people converting their ASoC driver needing the patches. Can you ack the first patch, so that Mark can maintain them in a branch for anyone who needs it to pull? Shawn Guo (2): dmaengine: add const for name parameter ASoC: dmaengine_pcm: add snd_dmaengine_generic_pcm_open() drivers/dma/dmaengine.c | 2 +- drivers/dma/of-dma.c | 6 +++--- include/linux/dmaengine.h | 7 ++++--- include/linux/of_dma.h | 2 +- include/sound/dmaengine_pcm.h | 2 ++ sound/soc/soc-dmaengine-pcm.c | 39 +++++++++++++++++++++++++++++++++++++++ 6 files changed, 50 insertions(+), 8 deletions(-) -- 1.7.9.5

6 18

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 22 Mar '13

22 Mar '13

On 03/22/2013 03:27 AM, Andreas Koch wrote: > I wouldn't worry about DSD wide, because that is a dead format that I > was involved in launching for professional recording applications more > than 10 years ago. It never took off. I just need it for my own purposes, but I can make custom stuff as necessary if there's no interest from others. Right now I'm just hoping to see a well defined common sample formats defined for ALSA that can be utilized by drivers. DoP could be implemented inside the driver or at ALSA layer instead of applications doing it. Not that I would mind, but I would find it cleaner than the current approach... :) Currently, ASIO is the only API to support DSD sample formats. I understand that Microsoft or Apple is a slow to turn giant, but I'd hope ALSA wouldn't be such. ;) There are already those IEC958 and DD/dts things being used for movie playback, so this wouldn't be such a big difference afterall. - Jussi

2 2

[alsa-devel] [PATCH] SoC: dma-sh7760: Fix compile error
by Lars-Peter Clausen 22 Mar '13

22 Mar '13

The dma-sh7760 currently fails with the following compile error: sound/soc/sh/dma-sh7760.c:346:2: error: unknown field 'pcm_ops' specified in initializer sound/soc/sh/dma-sh7760.c:346:2: warning: initialization from incompatible pointer type sound/soc/sh/dma-sh7760.c:347:2: error: unknown field 'pcm_new' specified in initializer sound/soc/sh/dma-sh7760.c:347:2: warning: initialization makes integer from pointer without a cast sound/soc/sh/dma-sh7760.c:348:2: error: unknown field 'pcm_free' specified in initializer sound/soc/sh/dma-sh7760.c:348:2: warning: initialization from incompatible pointer type sound/soc/sh/dma-sh7760.c: In function 'sh7760_soc_platform_probe': sound/soc/sh/dma-sh7760.c:353:2: warning: passing argument 2 of 'snd_soc_register_platform' from incompatible pointer type include/sound/soc.h:368:5: note: expected 'struct snd_soc_platform_driver *' but argument is of type 'struct snd_soc_platform *' This is due the misnaming of the snd_soc_platform_driver type name and 'ops' field. The issue was introduced in commit f0fba2a("ASoC: multi-component - ASoC Multi-Component Support"). Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Given that nobody noticed this over the course of the last three years the code is probably pretty dead by now anyway. --- sound/soc/sh/dma-sh7760.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/dma-sh7760.c b/sound/soc/sh/dma-sh7760.c index 19eff8f..1a8b03e 100644 --- a/sound/soc/sh/dma-sh7760.c +++ b/sound/soc/sh/dma-sh7760.c @@ -342,8 +342,8 @@ static int camelot_pcm_new(struct snd_soc_pcm_runtime *rtd) return 0; } -static struct snd_soc_platform sh7760_soc_platform = { - .pcm_ops = &camelot_pcm_ops, +static struct snd_soc_platform_driver sh7760_soc_platform = { + .ops = &camelot_pcm_ops, .pcm_new = camelot_pcm_new, .pcm_free = camelot_pcm_free, }; -- 1.8.0

2 2

[alsa-devel] [PATCH 1/2] ASoC: compress - add support for metadata apis
by Vinod Koul 22 Mar '13

22 Mar '13

From: Jeeja KP <jeeja.kp(a)intel.com> Compress core added metadata apis in 9727b4, so add same in ASoC Signed-off-by: Jeeja KP <jeeja.kp(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- Mark, Takashi: How do you guys wnat to take this one, Ideally this should go to mark's tree but the dependent apis are in takashi's tree, either way is fine with me :) --- sound/soc/soc-compress.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index 3ea7956..4730789 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -302,11 +302,38 @@ static int soc_compr_pointer(struct snd_compr_stream *cstream, return 0; } +static int sst_compr_set_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct snd_soc_pcm_runtime *rtd = cstream->private_data; + struct snd_soc_platform *platform = rtd->platform; + int ret = 0; + + if (platform->driver->compr_ops && platform->driver->compr_ops->pointer) + ret = platform->driver->compr_ops->set_metadata(cstream, metadata); + + return ret; +} + +static int sst_compr_get_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct snd_soc_pcm_runtime *rtd = cstream->private_data; + struct snd_soc_platform *platform = rtd->platform; + int ret = 0; + + if (platform->driver->compr_ops && platform->driver->compr_ops->pointer) + ret = platform->driver->compr_ops->get_metadata(cstream, metadata); + + return ret; +} /* ASoC Compress operations */ static struct snd_compr_ops soc_compr_ops = { .open = soc_compr_open, .free = soc_compr_free, .set_params = soc_compr_set_params, + .set_metadata = sst_compr_set_metadata, + .get_metadata = sst_compr_get_metadata, .get_params = soc_compr_get_params, .trigger = soc_compr_trigger, .pointer = soc_compr_pointer, -- 1.7.0.4

2 7

Re: [alsa-devel] 答复: 答复: how to combine mutil-channel in playback or capture?
by Daniel Mack 22 Mar '13

22 Mar '13

Hi, please don't top-post. On 22.03.2013 11:11, Zhang wei wrote: > But what is the mechanism to synchronize the data from different > channel,and maybe different channel pairs use different DMA buffer. You can try and see if syncing the individual, non-combinded PCM streams helps: http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_sync > So, I guess ,about the combine ,according to the alsa.conf,the alsa-lib > opened the 4 devices(in my case) and got every channel paris’s data in > turns in a monent. And then combine them together in order as one frame? It will feed the input to all pcm streams. I don't really know if it uses the sync mechanism on that, but I'd guess so. > Because all the CODEC have the same clock timing,so the different DMA > buffer stored the different channel data for the same moment. Alsa-lib > obtains the same size data from each buffer in turns in once.repeat it > again and again. > > Right? Yes, and so the streams won't drift. Why don't you just go ahead and try it? You should play back some wav file with a test pattern which you can recognize on a DSO or IIS analyzer on the bus. Then see if they are in sync. Daniel

1 0

Re: [alsa-devel] 答复: how to combine mutil-channel in playback or capture?
by Daniel Mack 22 Mar '13

22 Mar '13

On 22.03.2013 10:23, Zhang wei wrote: > Thank you. Yes,you're right. I need 4 different stereo Codecs at > least more than one on my board and i think that will be more funy > than 1 Codec.In this case ,the struct snd_soc_card will be > initialized as following: Struct snd_soc_card test_card= { > .name=”Test Card”, .dai_link=&test_dai_codecs, .num_links=4; } As a > result ,there would be 4 devices named pcmC0Dnp(n=0,1,2,3) under the > directory /dev/snd. I wounder how and who combines the multi-channel > audio data togother? Is it the plugin ? Yes, you can use the alsa userspace for that. See http://www.alsa-project.org/main/index.php/Asoundrc Daniel

1 0

[alsa-devel] how to combine mutil-channel in playback or capture?
by Zhang wei 22 Mar '13

22 Mar '13

I have already achieved the alsa-driver which can playback and capture function with two channel. My board based on ARM9 which have 3 ADC & 1 DAC in IIS bus and all of them shared the same BCLK and LRCK. The pins figure Like this: _________________ | BCLK |___________ | | | LRCK |___________ | | | ADCDAT0 |___________ | | | ADCDAT1 |___________ | | | ADCDAT2 |___________ | | | DACDATA |___________ | | |_______________| Every ADCDATn(n=0,1,2) has two channel so the question is how can I get multi-channel audio data such as 4 or 6 in capture funciton? BR

2 1

[alsa-devel] [PATCH] sound: max98090: Remove executable bit
by Joe Perches 21 Mar '13

21 Mar '13

Source files shouldn't have the executable bit set. Signed-off-by: Joe Perches <joe(a)perches.com> --- include/sound/max98090.h | 0 sound/soc/codecs/max98090.c | 0 sound/soc/codecs/max98090.h | 0 3 files changed, 0 insertions(+), 0 deletions(-) diff --git a/include/sound/max98090.h b/include/sound/max98090.h old mode 100755 new mode 100644 diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c old mode 100755 new mode 100644 diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h old mode 100755 new mode 100644

2 13

Re: [alsa-devel] [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set.
by Timur Tabi 21 Mar '13

21 Mar '13

On 03/21/2013 12:46 PM, Martin Fuzzey wrote: > On 21/03/13 17:11, Timur Tabi wrote: >> On Thu, Mar 21, 2013 at 3:39 AM, Martin Fuzzey <mfuzzey(a)parkeon.com> wrote: >> >>> With this patch and that DT example the frequency of clock 162 will be _set_ >>> to 20MHz >> Does that mean that it ignores the ' clocks' parameter? > No, in this case the clocks parameter must contain the phandle of a clock > whose rate is configurable. > >> If clock-frequency is omitted the binding is still correct (hence the >> optional) but the frequency of clock 162 would not be modified. >> >> In the documentation I wrote "If both a clock and clock-frequency are >> provided the clock's rate will be set. " maybe this is not clear enough? >> It's not clear what it will be set *to*. > It will be set to the frequency specified by the clock-frquency attribute. > > Would > "If both a clock and clock-frequency are provided clock must support > the set_rate operation and its frequency will be set to the value specified > by clock-frequency" be better? Yes, that's much better. > > > The possible configurations and their use cases are: > > 1) only 'clocks' specified > clock points to a clock specified in the DT which already has an > appropriate frequency and is > configured by some other means external to the sgtl5000 driver > (bootloader, board setup code, or just a fixed rate clock) > > 2) only 'clock-frequency' specified > The chip is assumed to be clocked by a signal having the given > frequency, which may even be generated by a clock unknown to linux. > This could actually be represented as a special case of 1) by defining a > fixed-rate clock in the DT. > > 3) Both 'clocks' and 'clock-frequency' specified > The chip is assumed to be clocked by a rate programmable clock defined > in the clock tree. > clk_set_rate() will be called for this clock to set its rate to that > specified by clock-frequency This should all be in the binding document. > Cases 1 and 2 exist in the current code, this patch adds support for case 3. > > Prior to commit 81e8e4926167ab32593bbb915b45a42024ca1020 "ASoC: fsl: add > sgtl5000 clock support for imx-sgtl5000" > only case 2 was supported > This explains why 2 is not implemented as a special case of 1) > plain 'clock-frequency' was supported before the driver learnt how to > get a clock from the DT And this should be in the patch description. -- Timur Tabi

1 0

Re: [alsa-devel] [PATCH 50/54 v2] ASoC: switch over to use snd_soc_register_component() on tegra20 ac97
by Stephen Warren 21 Mar '13

21 Mar '13

On 03/21/2013 11:19 AM, Lucas Stach wrote: > Am Donnerstag, den 21.03.2013, 11:03 -0600 schrieb Stephen Warren: >> On 03/21/2013 04:37 AM, Kuninori Morimoto wrote: >> >> Lucas, can you please test this to make sure that the change from >> snd_soc_register_dais() to snd_soc_register_dai() (the latter inside >> snd_soc_register_component()) coupled with the change to the >> tegra_wm9712.c machine driver yields the correct results. Thanks. > > Can someone please FWD me the whole patch? I'm not subscribed to > ALSA-devel and wasn't on CC for this patch. I'll do that off-list.

1 0

[alsa-devel] [PATCH] ALSA: hda - Introduce "Headset Mic" name
by David Henningsson 21 Mar '13

21 Mar '13

Headset mic jacks, i e TRRS style jacks with Headphone Left, Headphone Right, Mic and GND signals, are becoming increasingly common and are now being shipped by several manufacturers. Unfortunately, the HDA specification does not give us any hint of whether a Mic pin belongs to such a jack or not, but it would still be helpful for the user to know (especially if there is one TRS Mic jack and one TRRS headset jack). This new fixup causes the first (non-dock, non-internal) mic to be a headset mic jack. The algorithm can be later refined if needed. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/hda_auto_parser.c | 24 ++++++++++++++++++++++-- sound/pci/hda/hda_auto_parser.h | 2 ++ sound/pci/hda/patch_sigmatel.c | 6 +++++- 3 files changed, 29 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c index a3ea76a..6b173b3 100644 --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -260,6 +260,22 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, } } + /* Take first mic to be a headset mic pin */ + if (cond_flags & HDA_PINCFG_HEADSET_MIC) { + for (i = 0; i < cfg->num_inputs; i++) { + int attr; + unsigned int def_conf; + if (cfg->inputs[i].type != AUTO_PIN_MIC) + continue; + def_conf = snd_hda_codec_get_pincfg(codec, cfg->inputs[i].pin); + attr = snd_hda_get_input_pin_attr(def_conf); + if (attr <= INPUT_PIN_ATTR_DOCK) + continue; + cfg->inputs[i].is_headset_mic = 1; + break; + } + } + /* FIX-UP: * If no line-out is defined but multiple HPs are found, * some of them might be the real line-outs. @@ -388,6 +404,7 @@ EXPORT_SYMBOL_HDA(snd_hda_get_input_pin_attr); */ static const char *hda_get_input_pin_label(struct hda_codec *codec, + const struct auto_pin_cfg_item *item, hda_nid_t pin, bool check_location) { unsigned int def_conf; @@ -400,6 +417,8 @@ static const char *hda_get_input_pin_label(struct hda_codec *codec, switch (get_defcfg_device(def_conf)) { case AC_JACK_MIC_IN: + if (item && item->is_headset_mic) + return "Headset Mic"; if (!check_location) return "Mic"; attr = snd_hda_get_input_pin_attr(def_conf); @@ -480,7 +499,8 @@ const char *hda_get_autocfg_input_label(struct hda_codec *codec, has_multiple_pins = 1; if (has_multiple_pins && type == AUTO_PIN_MIC) has_multiple_pins &= check_mic_location_need(codec, cfg, input); - return hda_get_input_pin_label(codec, cfg->inputs[input].pin, + return hda_get_input_pin_label(codec, &cfg->inputs[input], + cfg->inputs[input].pin, has_multiple_pins); } EXPORT_SYMBOL_HDA(hda_get_autocfg_input_label); @@ -649,7 +669,7 @@ int snd_hda_get_pin_label(struct hda_codec *codec, hda_nid_t nid, } } if (!name) - name = hda_get_input_pin_label(codec, nid, true); + name = hda_get_input_pin_label(codec, NULL, nid, true); break; } if (!name) diff --git a/sound/pci/hda/hda_auto_parser.h b/sound/pci/hda/hda_auto_parser.h index f748071..98a72d0 100644 --- a/sound/pci/hda/hda_auto_parser.h +++ b/sound/pci/hda/hda_auto_parser.h @@ -36,6 +36,7 @@ enum { struct auto_pin_cfg_item { hda_nid_t pin; int type; + int is_headset_mic:1; }; struct auto_pin_cfg; @@ -80,6 +81,7 @@ struct auto_pin_cfg { /* bit-flags for snd_hda_parse_pin_def_config() behavior */ #define HDA_PINCFG_NO_HP_FIXUP (1 << 0) /* no HP-split */ #define HDA_PINCFG_NO_LO_FIXUP (1 << 1) /* don't take other outs as LO */ +#define HDA_PINCFG_HEADSET_MIC (1 << 2) /* Take first mic as headset mic */ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, struct auto_pin_cfg *cfg, diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 3be877b..1d9d642 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3528,8 +3528,12 @@ static int stac_parse_auto_config(struct hda_codec *codec) { struct sigmatel_spec *spec = codec->spec; int err; + int flags = 0; - err = snd_hda_parse_pin_defcfg(codec, &spec->gen.autocfg, NULL, 0); + if (spec->headset_jack) + flags |= HDA_PINCFG_HEADSET_MIC; + + err = snd_hda_parse_pin_defcfg(codec, &spec->gen.autocfg, NULL, flags); if (err < 0) return err; -- 1.7.9.5

2 7

Re: [alsa-devel] [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set.
by Timur Tabi 21 Mar '13

21 Mar '13

On Thu, Mar 21, 2013 at 3:39 AM, Martin Fuzzey <mfuzzey(a)parkeon.com> wrote: > With this patch and that DT example the frequency of clock 162 will be _set_ > to 20MHz Does that mean that it ignores the ' clocks' parameter? > If clock-frequency is omitted the binding is still correct (hence the > optional) but the frequency of clock 162 would not be modified. > > In the documentation I wrote "If both a clock and clock-frequency are > provided the clock's rate will be set. " maybe this is not clear enough? It's not clear what it will be set *to*.

1 0

[alsa-devel] [PATCH v2 1/2] ALSA: hda - Introduce "Headset Mic" name
by David Henningsson 21 Mar '13

21 Mar '13

Headset mic jacks, i e TRRS style jacks with Headphone Left, Headphone Right, Mic and GND signals, are becoming increasingly common and are now being shipped by several manufacturers. Unfortunately, the HDA specification does not give us any hint of whether a Mic pin belongs to such a jack or not, but it would still be helpful for the user to know (especially if there is one TRS Mic jack and one TRRS headset jack). This new fixup causes the first (non-dock, non-internal) mic to be a headset mic jack. The algorithm can be later refined if needed. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/hda_auto_parser.c | 24 ++++++++++++++++++++++-- sound/pci/hda/hda_auto_parser.h | 2 ++ 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c index a3ea76a..6b173b3 100644 --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -260,6 +260,22 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, } } + /* Take first mic to be a headset mic pin */ + if (cond_flags & HDA_PINCFG_HEADSET_MIC) { + for (i = 0; i < cfg->num_inputs; i++) { + int attr; + unsigned int def_conf; + if (cfg->inputs[i].type != AUTO_PIN_MIC) + continue; + def_conf = snd_hda_codec_get_pincfg(codec, cfg->inputs[i].pin); + attr = snd_hda_get_input_pin_attr(def_conf); + if (attr <= INPUT_PIN_ATTR_DOCK) + continue; + cfg->inputs[i].is_headset_mic = 1; + break; + } + } + /* FIX-UP: * If no line-out is defined but multiple HPs are found, * some of them might be the real line-outs. @@ -388,6 +404,7 @@ EXPORT_SYMBOL_HDA(snd_hda_get_input_pin_attr); */ static const char *hda_get_input_pin_label(struct hda_codec *codec, + const struct auto_pin_cfg_item *item, hda_nid_t pin, bool check_location) { unsigned int def_conf; @@ -400,6 +417,8 @@ static const char *hda_get_input_pin_label(struct hda_codec *codec, switch (get_defcfg_device(def_conf)) { case AC_JACK_MIC_IN: + if (item && item->is_headset_mic) + return "Headset Mic"; if (!check_location) return "Mic"; attr = snd_hda_get_input_pin_attr(def_conf); @@ -480,7 +499,8 @@ const char *hda_get_autocfg_input_label(struct hda_codec *codec, has_multiple_pins = 1; if (has_multiple_pins && type == AUTO_PIN_MIC) has_multiple_pins &= check_mic_location_need(codec, cfg, input); - return hda_get_input_pin_label(codec, cfg->inputs[input].pin, + return hda_get_input_pin_label(codec, &cfg->inputs[input], + cfg->inputs[input].pin, has_multiple_pins); } EXPORT_SYMBOL_HDA(hda_get_autocfg_input_label); @@ -649,7 +669,7 @@ int snd_hda_get_pin_label(struct hda_codec *codec, hda_nid_t nid, } } if (!name) - name = hda_get_input_pin_label(codec, nid, true); + name = hda_get_input_pin_label(codec, NULL, nid, true); break; } if (!name) diff --git a/sound/pci/hda/hda_auto_parser.h b/sound/pci/hda/hda_auto_parser.h index f748071..c7826ce 100644 --- a/sound/pci/hda/hda_auto_parser.h +++ b/sound/pci/hda/hda_auto_parser.h @@ -36,6 +36,7 @@ enum { struct auto_pin_cfg_item { hda_nid_t pin; int type; + unsigned int is_headset_mic:1; }; struct auto_pin_cfg; @@ -80,6 +81,7 @@ struct auto_pin_cfg { /* bit-flags for snd_hda_parse_pin_def_config() behavior */ #define HDA_PINCFG_NO_HP_FIXUP (1 << 0) /* no HP-split */ #define HDA_PINCFG_NO_LO_FIXUP (1 << 1) /* don't take other outs as LO */ +#define HDA_PINCFG_HEADSET_MIC (1 << 2) /* Take first mic as headset mic */ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, struct auto_pin_cfg *cfg, -- 1.7.9.5

1 1

Re: [alsa-devel] [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set.
by Timur Tabi 21 Mar '13

21 Mar '13

Martin Fuzzey wrote: > +If a clock is provided, clock-frequency is optional > + > +If no clock is provided clock-frequency is required (this represents the codec > +being clocked by an external signal not present in the clock tree) > + > +If both a clock and clock-frequency are provided the clock's rate will be set. > + > + > Example: > > codec: sgtl5000@0a { > compatible = "fsl,sgtl5000"; > reg = <0x0a>; > + clock-frequency = <20000000>; > + clocks = <&clks 162>; /* cko1 */ The code looks okay, but I'm not sure this example is right. The binding says that clock-frequency is optional if 'clocks' is provided, but here you list both. You should probably have two examples. -- Timur Tabi

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: wm8903: Add the DAC boost control
by Mark Brown 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 05:37:32PM +0100, Alban Bedel wrote: > Signed-off-by: Alban Bedel <alban.bedel(a)avionic-design.de> Applied, thanks.

1 0

[alsa-devel] [PATCH] salsa-lib: Rename _sndrv_pcm_format to _snd_pcm_format
by Mihail Zenkov 20 Mar '13

20 Mar '13

Rename _sndrv_pcm_format to _snd_pcm_format for compatible with alsa-lib. --- salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884/src/asound.h +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/src/asound.h @@ -133,7 +133,7 @@ SND_PCM_ACCESS_LAST = SND_PCM_ACCESS_RW_NONINTERLEAVED, } snd_pcm_access_t; -typedef enum _sndrv_pcm_format { +typedef enum _snd_pcm_format { SND_PCM_FORMAT_UNKNOWN = -1, SND_PCM_FORMAT_S8 = 0, /* signed */ SND_PCM_FORMAT_U8, /* unsigned */

2 1

[alsa-devel] [PATCH] salsa-lib: Set SNDRV_PCM_HW_PARAMS_NORESAMPLE by default
by Mihail Zenkov 20 Mar '13

20 Mar '13

As we don't allow resampling set SNDRV_PCM_HW_PARAMS_NORESAMPLE by default to respect snd_pcm_hw_rule_noresample in drivers. --- salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884/src/pcm_params.c +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/src/pcm_params.c @@ -436,6 +436,7 @@ params->rmask = ~0U; params->cmask = 0; params->info = ~0U; + params->flags = SNDRV_PCM_HW_PARAMS_NORESAMPLE; } int snd_pcm_hw_params_any(snd_pcm_t *pcm, snd_pcm_hw_params_t *params)

2 1

[alsa-devel] [PATCH] salsa-lib: Fix mistakes after refactoring pcm_params.c
by Mihail Zenkov 20 Mar '13

20 Mar '13

Fix some regressions after refactoring pcm_params.c These mistakes don't allow snd_pcm_hw_param_set_near to establish correct value. --- salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884/src/pcm_params.c +++ salsa-lib-a55ce0c348cd16e7853dae11e8e0e1b5a101d884-1/src/pcm_params.c @@ -590,11 +590,9 @@ save = *params; err = hw_param_set_max(params, var, *val, dir ? *dir : 0); - if (!err) { - err = hw_param_update_var(pcm, params, var, err); - if (!err) - return _snd_pcm_hw_param_get_max(params, var, val, dir); - } + err = hw_param_update_var(pcm, params, var, err); + if (!err) + return _snd_pcm_hw_param_get_max(params, var, val, dir); *params = save; return err; } @@ -683,7 +681,7 @@ snd_pcm_hw_params_t save = *params; int err = hw_param_set(params, var, val, dir); err = hw_param_update_var(pcm, params, var, err); - if (err) + if (err < 0) *params = save; return err; } @@ -712,7 +710,7 @@ save = *params; i->integer = 1; err = hw_param_update_var(pcm, params, var, 1); - if (err) + if (err < 0) *params = save; return err; } @@ -827,7 +825,7 @@ else if (valdir == 0) maxdir = -1; else { - valdir = 1; + maxdir = 1; max--; } save = *params;

2 1

Re: [alsa-devel] [PATCH] sound: soc: fix invalid free of devm_ allocated data
by Mark Brown 20 Mar '13

20 Mar '13

On Sat, Mar 16, 2013 at 01:45:34PM +0200, Silviu-Mihai Popescu wrote: > The objects allocated by devm_* APIs are managed by devres and are freed when > the device is detached. Hence there is no need to use kfree() explicitly. ...but I applied this anyway since it's clearly an improvement and a small leak is better than a crash.

1 0

Re: [alsa-devel] [PATCH] sound: soc: fix invalid free of devm_ allocated data
by Mark Brown 20 Mar '13

20 Mar '13

On Sat, Mar 16, 2013 at 01:45:34PM +0200, Silviu-Mihai Popescu wrote: > The objects allocated by devm_* APIs are managed by devres and are freed when > the device is detached. Hence there is no need to use kfree() explicitly. In this case since we're in error handling paths which might not be fatal (though I suspect they probably should be normally) it looks like the better fix is to use devm_kfree() to free immediately. Otherwise the unused memory will end up hanging around for as long as the device is bound.

1 0

[alsa-devel] [PATCH 1/2] ASoC: spear_pcm: Update to new pcm_new() API
by Lars-Peter Clausen 20 Mar '13

20 Mar '13

Commit 552d1ef6 ("ASoC: core - Optimise and refactor pcm_new() to pass only rtd") updated the pcm_new() callback to take the rtd as the only parameter. The spear PCM driver (which was merged much later) still uses the old API. This patch updates the driver to the new API. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Btw. where are the Kconfig and Makefile files for spear? --- sound/soc/spear/spear_pcm.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/soc/spear/spear_pcm.c b/sound/soc/spear/spear_pcm.c index 9b76cc5..5e7aebe 100644 --- a/sound/soc/spear/spear_pcm.c +++ b/sound/soc/spear/spear_pcm.c @@ -149,9 +149,9 @@ static void spear_pcm_free(struct snd_pcm *pcm) static u64 spear_pcm_dmamask = DMA_BIT_MASK(32); -static int spear_pcm_new(struct snd_card *card, - struct snd_soc_dai *dai, struct snd_pcm *pcm) +static int spear_pcm_new(struct snd_soc_pcm_runtime *rtd) { + struct snd_card *card = rtd->card->snd_card; int ret; if (!card->dev->dma_mask) @@ -159,16 +159,16 @@ static int spear_pcm_new(struct snd_card *card, if (!card->dev->coherent_dma_mask) card->dev->coherent_dma_mask = DMA_BIT_MASK(32); - if (dai->driver->playback.channels_min) { - ret = spear_pcm_preallocate_dma_buffer(pcm, + if (rtd->cpu_dai->driver->playback.channels_min) { + ret = spear_pcm_preallocate_dma_buffer(rtd->pcm, SNDRV_PCM_STREAM_PLAYBACK, spear_pcm_hardware.buffer_bytes_max); if (ret) return ret; } - if (dai->driver->capture.channels_min) { - ret = spear_pcm_preallocate_dma_buffer(pcm, + if (rtd->cpu_dai->driver->capture.channels_min) { + ret = spear_pcm_preallocate_dma_buffer(rtd->pcm, SNDRV_PCM_STREAM_CAPTURE, spear_pcm_hardware.buffer_bytes_max); if (ret) -- 1.8.0

3 3

[alsa-devel] [PATCH 0/3] ASoC: omap-mcpdm: Fix for full duplex audio
by Peter Ujfalusi 20 Mar '13

20 Mar '13

Hi, We had this issue for a long time but I had no time to think and fix it. With this series the full duplex audio will work correctly with McPDM. Under the hood we have HW limitation which prevents us to start up/downlink separately. Regards, Peter --- Peter Ujfalusi (3): ASoC: omap-mcpdm: Collect link direction configuration under a struct ASoC: omap-mcpdm: Fix for full duplex audio use case ASoC: omap-mcpdm: Remove leftower define for IO address sound/soc/omap/omap-mcpdm.c | 66 ++++++++++++++++++++++++++++++++------------- 1 file changed, 48 insertions(+), 18 deletions(-) -- 1.8.1.5

2 4

[alsa-devel] [PATCH] ASoC: fsl: imx-pcm-fiq: Use 'unsigned int' for period
by Fabio Estevam 20 Mar '13

20 Mar '13

From: Fabio Estevam <fabio.estevam(a)freescale.com> Fix the following warning when building with W=1 option: sound/soc/fsl/imx-pcm-fiq.c: In function 'snd_hrtimer_callback': sound/soc/fsl/imx-pcm-fiq.c:76:12: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/fsl/imx-pcm-fiq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c index 920f945..47228c0 100644 --- a/sound/soc/fsl/imx-pcm-fiq.c +++ b/sound/soc/fsl/imx-pcm-fiq.c @@ -34,7 +34,7 @@ #include "imx-ssi.h" struct imx_pcm_runtime_data { - int period; + unsigned int period; int periods; unsigned long offset; unsigned long last_offset; -- 1.7.9.5

2 1

[alsa-devel] [PATCH 1/2] ALSA: snd-usb: mixer: propagate errors up the call chain
by Daniel Mack 20 Mar '13

20 Mar '13

In check_input_term() and parse_audio_feature_unit(), propagate the error value that has been returned by a failing function instead of -EINVAL. That helps cleaning up the error pathes in the mixer. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- sound/usb/mixer.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 638e7f7..db30d02 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -715,8 +715,9 @@ static int check_input_term(struct mixer_build *state, int id, struct usb_audio_ case UAC2_CLOCK_SELECTOR: { struct uac_selector_unit_descriptor *d = p1; /* call recursively to retrieve the channel info */ - if (check_input_term(state, d->baSourceID[0], term) < 0) - return -ENODEV; + err = check_input_term(state, d->baSourceID[0], term); + if (err < 0) + return err; term->type = d->bDescriptorSubtype << 16; /* virtual type */ term->id = id; term->name = uac_selector_unit_iSelector(d); @@ -1356,8 +1357,9 @@ static int parse_audio_feature_unit(struct mixer_build *state, int unitid, void return err; /* determine the input source type and name */ - if (check_input_term(state, hdr->bSourceID, &iterm) < 0) - return -EINVAL; + err = check_input_term(state, hdr->bSourceID, &iterm); + if (err < 0) + return err; master_bits = snd_usb_combine_bytes(bmaControls, csize); /* master configuration quirks */ -- 1.8.1.4

2 2

[alsa-devel] [PATCH] ALSA: usb: Parse UAC2 extension unit like for UAC1
by Torstein Hegge 20 Mar '13

20 Mar '13

UAC2_EXTENSION_UNIT_V2 differs from UAC1_EXTENSION_UNIT, but can be handled in the same way when parsing the unit. Otherwise parse_audio_unit() fails when it sees an extension unit on a UAC2 device. UAC2_EXTENSION_UNIT_V2 is outside the range allocated by UAC1. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- sound/usb/mixer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 638e7f7..8eb84c0 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -725,7 +725,8 @@ static int check_input_term(struct mixer_build *state, int id, struct usb_audio_ case UAC1_PROCESSING_UNIT: case UAC1_EXTENSION_UNIT: /* UAC2_PROCESSING_UNIT_V2 */ - /* UAC2_EFFECT_UNIT */ { + /* UAC2_EFFECT_UNIT */ + case UAC2_EXTENSION_UNIT_V2: { struct uac_processing_unit_descriptor *d = p1; if (state->mixer->protocol == UAC_VERSION_2 && @@ -2052,6 +2053,8 @@ static int parse_audio_unit(struct mixer_build *state, int unitid) return parse_audio_extension_unit(state, unitid, p1); else /* UAC_VERSION_2 */ return parse_audio_processing_unit(state, unitid, p1); + case UAC2_EXTENSION_UNIT_V2: + return parse_audio_extension_unit(state, unitid, p1); default: snd_printk(KERN_ERR "usbaudio: unit %u: unexpected type 0x%02x\n", unitid, p1[2]); return -EINVAL; -- 1.7.10.4

3 6

[alsa-devel] [TINYCOMPRESS] Remove local copies of kernel headers?
by Richard Fitzgerald 20 Mar '13

20 Mar '13

I'm assuming that the local copies of compress_offload.h and compress_params.h were there as a convenience during early development Can we remove these local copies now?

3 2

[alsa-devel] ASoC: atmel-pcm-dma: Leaking memory in atmel_pcm_hw_params
by Lars-Peter Clausen 19 Mar '13

19 Mar '13

Hi, The dmaengine based pcm driver for atmel calls snd_dmaengine_pcm_open from it's hw_params callback. There is nothing preventing an application calling hw_params more than once. snd_dmaengine_pcm_open allocates a new prtd struct each time it gets called. So in case hw_params is called multiple times we leak memory here. Is there any specific reason why snd_dmaengine_pcm_open() needs to be called from the hw_params callback and why it can't be called from the open callback? The filter function depends on the data returned by snd_soc_dai_get_dma_data(), but as far as I can see the DAI driver calls snd_soc_dai_set_dma_data() from its startup() callback, so the data is available in the PCM drivers open callback. - Lars

2 3

[alsa-devel] [PATCH 1/2] snd-usb-audio: Playback and MIDI support for Novation Twitch DJ controller
by Mark Hills 18 Mar '13

18 Mar '13

The hardware also has a PCM capture device which is not implemented in this patch. It may be possible to generalise this to Saffire 6 USB support and some of the other Focusrite interfaces, but as I don't have access to these devices we should wait until capture support is working first. Capture support is not implemented because the code assumes the endpoint to have its own interface (instead, it shares the interface with playback) and some thought will be needed to lift this limitation. --- sound/usb/quirks-table.h | 40 ++++++++++++++++++++++++++++++++++++++++ sound/usb/quirks.c | 15 +++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 820580a..1c8db85 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2677,6 +2677,46 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, { + USB_DEVICE(0x1235, 0x0018), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .vendor_name = "Novation", + .product_name = "Twitch", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_FIXED_ENDPOINT, + .data = & (const struct audioformat) { + .formats = SNDRV_PCM_FMTBIT_S24_3LE, + .channels = 4, + .iface = 0, + .altsetting = 1, + .altset_idx = 1, + .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, + .endpoint = 0x01, + .ep_attr = USB_ENDPOINT_XFER_ISOC, + .rates = SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000, + .rate_min = 44100, + .rate_max = 48000, + .nr_rates = 2, + .rate_table = (unsigned int[]) { + 44100, 48000 + } + } + }, + { + .ifnum = 1, + .type = QUIRK_MIDI_RAW_BYTES + }, + { + .ifnum = -1 + } + } + } +}, +{ USB_DEVICE_VENDOR_SPEC(0x1235, 0x4661), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Novation", diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 0115289..b0f7140 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -446,6 +446,17 @@ static int snd_usb_cm6206_boot_quirk(struct usb_device *dev) } /* + * Novation Twitch DJ controller + */ +static int snd_usb_twitch_boot_quirk(struct usb_device *dev) +{ + /* preemptively set up the device because otherwise the + * raw MIDI endpoints are not active */ + usb_set_interface(dev, 0, 1); + return 0; +} + +/* * This call will put the synth in "USB send" mode, i.e it will send MIDI * messages through USB (this is disabled at startup). The synth will * acknowledge by sending a sysex on endpoint 0x85 and by displaying a USB @@ -746,6 +757,10 @@ int snd_usb_apply_boot_quirk(struct usb_device *dev, /* Digidesign Mbox 2 */ return snd_usb_mbox2_boot_quirk(dev); + case USB_ID(0x1235, 0x0018): + /* Focusrite Novation Twitch */ + return snd_usb_twitch_boot_quirk(dev); + case USB_ID(0x133e, 0x0815): /* Access Music VirusTI Desktop */ return snd_usb_accessmusic_boot_quirk(dev); -- 1.7.12.1

2 4

Re: [alsa-devel] [PATCH] documentation: alsa: Fix typo in Documentation/sound
by Takashi Iwai 17 Mar '13

17 Mar '13

At Sun, 17 Mar 2013 02:57:28 +0900, Masanari Iida wrote: > > Correct spelling typos in Documentation/sound/alsa > > Signed-off-by: Masanari Iida <standby24x7(a)gmail.com> Thanks, applied. Takashi > --- > Documentation/sound/alsa/ALSA-Configuration.txt | 2 +- > Documentation/sound/alsa/seq_oss.html | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt > index ce6581c..4499bd9 100644 > --- a/Documentation/sound/alsa/ALSA-Configuration.txt > +++ b/Documentation/sound/alsa/ALSA-Configuration.txt > @@ -912,7 +912,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. > models depending on the codec chip. The list of available models > is found in HD-Audio-Models.txt > > - The model name "genric" is treated as a special case. When this > + The model name "generic" is treated as a special case. When this > model is given, the driver uses the generic codec parser without > "codec-patch". It's sometimes good for testing and debugging. > > diff --git a/Documentation/sound/alsa/seq_oss.html b/Documentation/sound/alsa/seq_oss.html > index d9776cf..9663b45 100644 > --- a/Documentation/sound/alsa/seq_oss.html > +++ b/Documentation/sound/alsa/seq_oss.html > @@ -285,7 +285,7 @@ sample data. > <H4> > 7.2.4 Close Callback</H4> > The <TT>close</TT> callback is called when this device is closed by the > -applicaion. If any private data was allocated in open callback, it must > +application. If any private data was allocated in open callback, it must > be released in the close callback. The deletion of ALSA port should be > done here, too. This callback must not be NULL. > <H4> > -- > 1.8.2 >

1 0

[alsa-devel] [PATCH] ASoC: core: Add support for platform and CODEC drivers on same device
by Charles Keepax 15 Mar '13

15 Mar '13

Currently DAI playback and capture widgets are created during soc_probe_codec and soc_probe_platform, using the device associated with the DAI to check which widgets should be created. If a device registers both a CODEC and platform driver this leads the CODEC playback and capture widgets being overwritten by the widgets created by the platform probe. It is more sensible to retain the CODEC widgets as the most common use case for registering both a CODEC and platform driver on the same chip is a CODEC which contains a DSP for compressed playback. In this situation it is more sensible to attach the routing information to the CODEC and add a thin platform driver interface to link into the compressed API. So this patch will check for existing widgets during soc_probe_platform and only create new widgets if no existing ones exist. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/soc-core.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 04af2a6..53efe1d 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1159,7 +1159,8 @@ static int soc_probe_platform(struct snd_soc_card *card, /* Create DAPM widgets for each DAI stream */ list_for_each_entry(dai, &dai_list, list) { - if (dai->dev != platform->dev) + if (dai->dev != platform->dev || + dai->playback_widget || dai->capture_widget) continue; snd_soc_dapm_new_dai_widgets(&platform->dapm, dai); -- 1.7.2.5

2 6

[alsa-devel] [PATCH V2 0/2] ASoC: OMAP2+: Update Audio IP with sDMA binding for DT boot
by Sebastien Guiriec 15 Mar '13

15 Mar '13

This patch serie is converting OMAP Audio IPs in order to use OMAP sDMA DT binding in case of DT boot on OMAP2+ platforms. It is depending on the next patches: [1] http://www.spinics.net/lists/arm-kernel/msg227836.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg84668.html It has been tested on: - OMAP5 (sEVM/panda)in DT boot (McPDM/DMIC). - OMAP4 (SDP4430/Panda) in both DT/non DT boot (McPDM/DMIC) - OMAP3 (Beagle XM) in both DT/non DT boot (McBSP) Update since v1: - Put DTS patch in first. - Squash all OMAP IPs patch together. Sebastien Guiriec (2): ARM: dts: OMAP2+: Add SDMA Audio IPs bindings ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding arch/arm/boot/dts/omap2420.dtsi | 6 ++++++ arch/arm/boot/dts/omap2430.dtsi | 15 +++++++++++++++ arch/arm/boot/dts/omap3.dtsi | 15 +++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 17 +++++++++++++++++ arch/arm/boot/dts/omap5.dtsi | 14 ++++++++++++++ sound/soc/omap/mcbsp.c | 26 ++++++++++++++++---------- sound/soc/omap/omap-dmic.c | 15 +++++++++------ sound/soc/omap/omap-mcpdm.c | 22 ++++++++++++++-------- sound/soc/omap/omap-pcm.c | 12 ++++++++++-- sound/soc/omap/omap-pcm.h | 1 + 10 files changed, 117 insertions(+), 26 deletions(-) -- 1.7.10.4

6 16

[alsa-devel] [PATCH] ALSA: at73c213: Use dev_pm_ops
by Lars-Peter Clausen 15 Mar '13

15 Mar '13

Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/spi/at73c213.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/sound/spi/at73c213.c b/sound/spi/at73c213.c index 4dd60d8..a1a24b9 100644 --- a/sound/spi/at73c213.c +++ b/sound/spi/at73c213.c @@ -1075,10 +1075,11 @@ out: return 0; } -#ifdef CONFIG_PM -static int snd_at73c213_suspend(struct spi_device *spi, pm_message_t msg) +#ifdef CONFIG_PM_SLEEP + +static int snd_at73c213_suspend(struct device *dev) { - struct snd_card *card = dev_get_drvdata(&spi->dev); + struct snd_card *card = dev_get_drvdata(dev); struct snd_at73c213 *chip = card->private_data; ssc_writel(chip->ssc->regs, CR, SSC_BIT(CR_TXDIS)); @@ -1087,9 +1088,9 @@ static int snd_at73c213_suspend(struct spi_device *spi, pm_message_t msg) return 0; } -static int snd_at73c213_resume(struct spi_device *spi) +static int snd_at73c213_resume(struct device *dev) { - struct snd_card *card = dev_get_drvdata(&spi->dev); + struct snd_card *card = dev_get_drvdata(dev); struct snd_at73c213 *chip = card->private_data; clk_enable(chip->board->dac_clk); @@ -1097,18 +1098,21 @@ static int snd_at73c213_resume(struct spi_device *spi) return 0; } + +static SIMPLE_DEV_PM_OPS(at73c213_pm_ops, snd_at73c213_suspend, + snd_at73c213_resume); +#define AT73C213_PM_OPS (&at73c213_pm_ops) + #else -#define snd_at73c213_suspend NULL -#define snd_at73c213_resume NULL +#define AT73C213_PM_OPS NULL #endif static struct spi_driver at73c213_driver = { .driver = { .name = "at73c213", + .pm = AT73C213_PM_OPS, }, .probe = snd_at73c213_probe, - .suspend = snd_at73c213_suspend, - .resume = snd_at73c213_resume, .remove = snd_at73c213_remove, }; -- 1.8.0

1 0

Re: [alsa-devel] [PATCH 08/10] ASoC: dmaengine_pcm: Add open function for DT DMA request
by Shawn Guo 15 Mar '13

15 Mar '13

On Thu, Mar 14, 2013 at 02:08:32PM +0100, Markus Pargmann wrote: > On Wed, Mar 13, 2013 at 10:18:29AM +0800, Shawn Guo wrote: > > On Tue, Mar 12, 2013 at 07:02:07PM +0000, Mark Brown wrote: > > > On Sun, Mar 10, 2013 at 07:33:09PM +0100, Markus Pargmann wrote: > > > > Add a function to open a DMA PCM substream using devicetree data > > > > provided via the client device node. The patch introduces a public > > > > function and a private subfunction that is called by both open > > > > functions. > > > > > > Someone (I think it was Shawn) sent a very similar patch just recently > > > which appears to have fallen out of my inbox unfortunately - can you > > > please check what's going on there and coordinate with them? Let me > > > know if you can't find the patch and I'll dig it out. > > > > It's here, Markus. > > > > http://thread.gmane.org/gmane.linux.alsa.devel/106027/focus=106031 > > > > Thanks. Do you already have a patch for the non-generic function which I > could use instead? > I do not follow. With my patch in place, there will be two dmaengine_pcm APIs. int snd_dmaengine_pcm_open(struct snd_pcm_substream *substream, dma_filter_fn filter_fn, void *filter_data) int snd_dmaengine_generic_pcm_open(struct snd_pcm_substream *substream, struct device *dev, const char *name) The first one is for users that their dmaengine driver hasn't converted to generic device tree bindings, and the second one is for users that their dmaengine driver is converted to generic device tree bindings. Shawn

2 1

[alsa-devel] [PATCH 0/3] ALSA: hda/ca0132 - Better handle a failed DSP firmware load.
by Dylan Reid 15 Mar '13

15 Mar '13

Enabling CONFIG_SND_HDA_CODEC_CA0132_DSP on the Chromebook Pixel leads to 10+ a second delay between running aplay and hearing audio. This was caused by the driver thinking the DSP was loaded when it had actually failed. The first two patches avoid that situation, the DSP still fails to load every time, but at least the system continues without a painful delay. The third patch is just a cleanup that touches the same state variable. Dylan Reid (3): ALSA: hda/ca0132 - Check if dspload_image succeeded. ALSA: hda/ca0132 - Check download state of DSP. ALSA: hda/ca0132 - Remove extra setting of dsp_state. sound/pci/hda/patch_ca0132.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) -- 1.8.1.3.605.g02339dd

2 4

[alsa-devel] [patch] sound: sequencer: cap array index in seq_chn_common_event()
by Dan Carpenter 15 Mar '13

15 Mar '13

"chn" here is a number between 0 and 255, but ->chn_info[] only has 16 elements so there is a potential write beyond the end of the array. If the seq_mode isn't SEQ_2 then we let the individual drivers (either opl3.c or midi_synth.c) handle it. Those functions all do a bounds check on "chn" so I haven't changed anything here. The opl3.c driver has up to 18 channels and not 16. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- Static checker stuff. diff --git a/sound/oss/sequencer.c b/sound/oss/sequencer.c index 30bcfe4..4ff60a6 100644 --- a/sound/oss/sequencer.c +++ b/sound/oss/sequencer.c @@ -545,6 +545,9 @@ static void seq_chn_common_event(unsigned char *event_rec) case MIDI_PGM_CHANGE: if (seq_mode == SEQ_2) { + if (chn > 15) + break; + synth_devs[dev]->chn_info[chn].pgm_num = p1; if ((int) dev >= num_synths) synth_devs[dev]->set_instr(dev, chn, p1); @@ -596,6 +599,9 @@ static void seq_chn_common_event(unsigned char *event_rec) case MIDI_PITCH_BEND: if (seq_mode == SEQ_2) { + if (chn > 15) + break; + synth_devs[dev]->chn_info[chn].bender_value = w14; if ((int) dev < num_synths)

2 1

[alsa-devel] [PATCH 1/2] ASoC: cs4271: switch to mute_stream
by Daniel Mack 15 Mar '13

15 Mar '13

Use the newly introduced mute_stream DAI operation, and don't mute the codec if it's called for the _CAPTURE stream. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- sound/soc/codecs/cs4271.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index ac0d3b4..03036b3 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -388,7 +388,7 @@ static int cs4271_hw_params(struct snd_pcm_substream *substream, return cs4271_set_deemph(codec); } -static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) +static int cs4271_mute_stream(struct snd_soc_dai *dai, int mute, int stream) { struct snd_soc_codec *codec = dai->codec; struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); @@ -396,6 +396,9 @@ static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) int val_a = 0; int val_b = 0; + if (stream != SNDRV_PCM_STREAM_PLAYBACK) + return 0; + if (mute) { val_a = CS4271_VOLA_MUTE; val_b = CS4271_VOLB_MUTE; @@ -442,7 +445,7 @@ static const struct snd_soc_dai_ops cs4271_dai_ops = { .hw_params = cs4271_hw_params, .set_sysclk = cs4271_set_dai_sysclk, .set_fmt = cs4271_set_dai_fmt, - .digital_mute = cs4271_digital_mute, + .mute_stream = cs4271_mute_stream, }; static struct snd_soc_dai_driver cs4271_dai = { -- 1.8.1.4

1 1

[alsa-devel] [PATCH] ASoC: dapm: Fix pointer dereference in is_connected_output_ep()
by Peter Ujfalusi 15 Mar '13

15 Mar '13

*path is not yet initialized when we check if the widget is connected. The compiler also warns about this: sound/soc/soc-dapm.c: In function 'is_connected_output_ep': sound/soc/soc-dapm.c:824:18: warning: 'path' may be used uninitialized in this function Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- Hi Mark, Liam, This patch is for the for-next branch. I got NULL pointer dereference because of this depending on the used toolchain. Regards, Peter sound/soc/soc-dapm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index eaf9b74..33acd8b 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -821,7 +821,6 @@ static int is_connected_output_ep(struct snd_soc_dapm_widget *widget, (widget->id == snd_soc_dapm_line && !list_empty(&widget->sources))) { widget->outputs = snd_soc_dapm_suspend_check(widget); - path->walking = 0; return widget->outputs; } } -- 1.8.1.5

2 1

[alsa-devel] [PATCH 0/2] ASoC: add new struct snd_soc_chip
by Kuninori Morimoto 15 Mar '13

15 Mar '13

Hi Mark, Liam, Stephen, Lars In my understanding on ASoC, - We will clean-up ASoC code. - CODEC/CPU will be common struct (platform too ??) As 1st trigger for this common struct, I created very basic struct snd_soc_chip. I hope it is accepted, and updated to be more useful. Kuninori Morimoto (2): ASoC: add snd_soc_register_chip() ASoC: fsi: use snd_soc_register_chip() instead of snd_soc_register_dais() include/sound/soc.h | 19 +++++++++++++ sound/soc/sh/fsi.c | 11 +++++--- sound/soc/soc-core.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 103 insertions(+), 4 deletions(-)

4 18

[alsa-devel] [PATCH v3] ALSA: ASoC: cs4271: convert to direct regmap API usage
by Daniel Mack 15 Mar '13

15 Mar '13

By using the regmap API directly, we can make use of the .write_flag_mask for SPI, which allows us to drop the strange register hacks that were necessary so far. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- v3: dropped one more (now misleading) comment v2: added a .write_flag_mask sound/soc/codecs/cs4271.c | 159 ++++++++++++++++++++++++++-------------------- 1 file changed, 91 insertions(+), 68 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index 2415a41..ac0d3b4 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -39,17 +39,15 @@ /* * CS4271 registers - * High byte represents SPI chip address (0x10) + write command (0) - * Low byte - codec register address */ -#define CS4271_MODE1 0x2001 /* Mode Control 1 */ -#define CS4271_DACCTL 0x2002 /* DAC Control */ -#define CS4271_DACVOL 0x2003 /* DAC Volume & Mixing Control */ -#define CS4271_VOLA 0x2004 /* DAC Channel A Volume Control */ -#define CS4271_VOLB 0x2005 /* DAC Channel B Volume Control */ -#define CS4271_ADCCTL 0x2006 /* ADC Control */ -#define CS4271_MODE2 0x2007 /* Mode Control 2 */ -#define CS4271_CHIPID 0x2008 /* Chip ID */ +#define CS4271_MODE1 0x01 /* Mode Control 1 */ +#define CS4271_DACCTL 0x02 /* DAC Control */ +#define CS4271_DACVOL 0x03 /* DAC Volume & Mixing Control */ +#define CS4271_VOLA 0x04 /* DAC Channel A Volume Control */ +#define CS4271_VOLB 0x05 /* DAC Channel B Volume Control */ +#define CS4271_ADCCTL 0x06 /* ADC Control */ +#define CS4271_MODE2 0x07 /* Mode Control 2 */ +#define CS4271_CHIPID 0x08 /* Chip ID */ #define CS4271_FIRSTREG CS4271_MODE1 #define CS4271_LASTREG CS4271_MODE2 @@ -144,23 +142,27 @@ * Array do not include Chip ID, as codec driver does not use * registers read operations at all */ -static const u8 cs4271_dflt_reg[CS4271_NR_REGS] = { - 0, - 0, - CS4271_DACCTL_AMUTE, - CS4271_DACVOL_SOFT | CS4271_DACVOL_ATAPI_AL_BR, - 0, - 0, - 0, - 0, +static const struct reg_default cs4271_reg_defaults[] = { + { CS4271_MODE1, 0, }, + { CS4271_DACCTL, CS4271_DACCTL_AMUTE, }, + { CS4271_DACVOL, CS4271_DACVOL_SOFT | CS4271_DACVOL_ATAPI_AL_BR, }, + { CS4271_VOLA, 0, }, + { CS4271_VOLB, 0, }, + { CS4271_ADCCTL, 0, }, + { CS4271_MODE2, 0, }, }; +static bool cs4271_volatile_reg(struct device *dev, unsigned int reg) +{ + return reg == CS4271_CHIPID; +} + struct cs4271_private { /* SND_SOC_I2C or SND_SOC_SPI */ - enum snd_soc_control_type bus_type; unsigned int mclk; bool master; bool deemph; + struct regmap *regmap; /* Current sample rate for de-emphasis control */ int rate; /* GPIO driving Reset pin, if any */ @@ -210,14 +212,14 @@ static int cs4271_set_dai_fmt(struct snd_soc_dai *codec_dai, switch (format & SND_SOC_DAIFMT_FORMAT_MASK) { case SND_SOC_DAIFMT_LEFT_J: val |= CS4271_MODE1_DAC_DIF_LJ; - ret = snd_soc_update_bits(codec, CS4271_ADCCTL, + ret = regmap_update_bits(cs4271->regmap, CS4271_ADCCTL, CS4271_ADCCTL_ADC_DIF_MASK, CS4271_ADCCTL_ADC_DIF_LJ); if (ret < 0) return ret; break; case SND_SOC_DAIFMT_I2S: val |= CS4271_MODE1_DAC_DIF_I2S; - ret = snd_soc_update_bits(codec, CS4271_ADCCTL, + ret = regmap_update_bits(cs4271->regmap, CS4271_ADCCTL, CS4271_ADCCTL_ADC_DIF_MASK, CS4271_ADCCTL_ADC_DIF_I2S); if (ret < 0) return ret; @@ -227,7 +229,7 @@ static int cs4271_set_dai_fmt(struct snd_soc_dai *codec_dai, return -EINVAL; } - ret = snd_soc_update_bits(codec, CS4271_MODE1, + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE1, CS4271_MODE1_DAC_DIF_MASK | CS4271_MODE1_MASTER, val); if (ret < 0) return ret; @@ -252,7 +254,7 @@ static int cs4271_set_deemph(struct snd_soc_codec *codec) val <<= 4; } - ret = snd_soc_update_bits(codec, CS4271_DACCTL, + ret = regmap_update_bits(cs4271->regmap, CS4271_DACCTL, CS4271_DACCTL_DEM_MASK, val); if (ret < 0) return ret; @@ -341,14 +343,14 @@ static int cs4271_hw_params(struct snd_pcm_substream *substream, !dai->capture_active) || (substream->stream == SNDRV_PCM_STREAM_CAPTURE && !dai->playback_active)) { - ret = snd_soc_update_bits(codec, CS4271_MODE2, - CS4271_MODE2_PDN, - CS4271_MODE2_PDN); + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_PDN, + CS4271_MODE2_PDN); if (ret < 0) return ret; - ret = snd_soc_update_bits(codec, CS4271_MODE2, - CS4271_MODE2_PDN, 0); + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_PDN, 0); if (ret < 0) return ret; } @@ -378,7 +380,7 @@ static int cs4271_hw_params(struct snd_pcm_substream *substream, val |= cs4271_clk_tab[i].ratio_mask; - ret = snd_soc_update_bits(codec, CS4271_MODE1, + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE1, CS4271_MODE1_MODE_MASK | CS4271_MODE1_DIV_MASK, val); if (ret < 0) return ret; @@ -389,6 +391,7 @@ static int cs4271_hw_params(struct snd_pcm_substream *substream, static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) { struct snd_soc_codec *codec = dai->codec; + struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); int ret; int val_a = 0; int val_b = 0; @@ -398,10 +401,13 @@ static int cs4271_digital_mute(struct snd_soc_dai *dai, int mute) val_b = CS4271_VOLB_MUTE; } - ret = snd_soc_update_bits(codec, CS4271_VOLA, CS4271_VOLA_MUTE, val_a); + ret = regmap_update_bits(cs4271->regmap, CS4271_VOLA, + CS4271_VOLA_MUTE, val_a); if (ret < 0) return ret; - ret = snd_soc_update_bits(codec, CS4271_VOLB, CS4271_VOLB_MUTE, val_b); + + ret = regmap_update_bits(cs4271->regmap, CS4271_VOLB, + CS4271_VOLB_MUTE, val_b); if (ret < 0) return ret; @@ -463,25 +469,33 @@ static struct snd_soc_dai_driver cs4271_dai = { static int cs4271_soc_suspend(struct snd_soc_codec *codec) { int ret; + struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); + /* Set power-down bit */ - ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN, - CS4271_MODE2_PDN); + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_PDN, CS4271_MODE2_PDN); if (ret < 0) return ret; + return 0; } static int cs4271_soc_resume(struct snd_soc_codec *codec) { int ret; + struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); + /* Restore codec state */ - ret = snd_soc_cache_sync(codec); + ret = regcache_sync(cs4271->regmap); if (ret < 0) return ret; + /* then disable the power-down bit */ - ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN, 0); + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_PDN, 0); if (ret < 0) return ret; + return 0; } #else @@ -542,40 +556,22 @@ static int cs4271_probe(struct snd_soc_codec *codec) cs4271->gpio_nreset = gpio_nreset; - /* - * In case of I2C, chip address specified in board data. - * So cache IO operations use 8 bit codec register address. - * In case of SPI, chip address and register address - * passed together as 16 bit value. - * Anyway, register address is masked with 0xFF inside - * soc-cache code. - */ - if (cs4271->bus_type == SND_SOC_SPI) - ret = snd_soc_codec_set_cache_io(codec, 16, 8, - cs4271->bus_type); - else - ret = snd_soc_codec_set_cache_io(codec, 8, 8, - cs4271->bus_type); - if (ret) { - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); - return ret; - } - - ret = snd_soc_update_bits(codec, CS4271_MODE2, - CS4271_MODE2_PDN | CS4271_MODE2_CPEN, - CS4271_MODE2_PDN | CS4271_MODE2_CPEN); + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_PDN | CS4271_MODE2_CPEN, + CS4271_MODE2_PDN | CS4271_MODE2_CPEN); if (ret < 0) return ret; - ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN, 0); + ret = regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_PDN, 0); if (ret < 0) return ret; /* Power-up sequence requires 85 uS */ udelay(85); if (amutec_eq_bmutec) - snd_soc_update_bits(codec, CS4271_MODE2, - CS4271_MODE2_MUTECAEQUB, - CS4271_MODE2_MUTECAEQUB); + regmap_update_bits(cs4271->regmap, CS4271_MODE2, + CS4271_MODE2_MUTECAEQUB, + CS4271_MODE2_MUTECAEQUB); return snd_soc_add_codec_controls(codec, cs4271_snd_controls, ARRAY_SIZE(cs4271_snd_controls)); @@ -597,13 +593,24 @@ static struct snd_soc_codec_driver soc_codec_dev_cs4271 = { .remove = cs4271_remove, .suspend = cs4271_soc_suspend, .resume = cs4271_soc_resume, - .reg_cache_default = cs4271_dflt_reg, - .reg_cache_size = ARRAY_SIZE(cs4271_dflt_reg), - .reg_word_size = sizeof(cs4271_dflt_reg[0]), - .compress_type = SND_SOC_FLAT_COMPRESSION, }; #if defined(CONFIG_SPI_MASTER) + +static const struct regmap_config cs4271_spi_regmap = { + .reg_bits = 16, + .val_bits = 8, + .max_register = CS4271_LASTREG, + .read_flag_mask = 0x21, + .write_flag_mask = 0x20, + + .reg_defaults = cs4271_reg_defaults, + .num_reg_defaults = ARRAY_SIZE(cs4271_reg_defaults), + .cache_type = REGCACHE_RBTREE, + + .volatile_reg = cs4271_volatile_reg, +}; + static int cs4271_spi_probe(struct spi_device *spi) { struct cs4271_private *cs4271; @@ -613,7 +620,9 @@ static int cs4271_spi_probe(struct spi_device *spi) return -ENOMEM; spi_set_drvdata(spi, cs4271); - cs4271->bus_type = SND_SOC_SPI; + cs4271->regmap = devm_regmap_init_spi(spi, &cs4271_spi_regmap); + if (IS_ERR(cs4271->regmap)) + return PTR_ERR(cs4271->regmap); return snd_soc_register_codec(&spi->dev, &soc_codec_dev_cs4271, &cs4271_dai, 1); @@ -643,6 +652,18 @@ static const struct i2c_device_id cs4271_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, cs4271_i2c_id); +static const struct regmap_config cs4271_i2c_regmap = { + .reg_bits = 8, + .val_bits = 8, + .max_register = CS4271_LASTREG, + + .reg_defaults = cs4271_reg_defaults, + .num_reg_defaults = ARRAY_SIZE(cs4271_reg_defaults), + .cache_type = REGCACHE_RBTREE, + + .volatile_reg = cs4271_volatile_reg, +}; + static int cs4271_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -653,7 +674,9 @@ static int cs4271_i2c_probe(struct i2c_client *client, return -ENOMEM; i2c_set_clientdata(client, cs4271); - cs4271->bus_type = SND_SOC_I2C; + cs4271->regmap = devm_regmap_init_i2c(client, &cs4271_i2c_regmap); + if (IS_ERR(cs4271->regmap)) + return PTR_ERR(cs4271->regmap); return snd_soc_register_codec(&client->dev, &soc_codec_dev_cs4271, &cs4271_dai, 1); -- 1.8.1.4

2 3

Re: [alsa-devel] [PATCH 08/10] ASoC: dmaengine_pcm: Add open function for DT DMA request
by Mark Brown 15 Mar '13

15 Mar '13

On Sun, Mar 10, 2013 at 07:33:09PM +0100, Markus Pargmann wrote: > Add a function to open a DMA PCM substream using devicetree data > provided via the client device node. The patch introduces a public > function and a private subfunction that is called by both open > functions. Someone (I think it was Shawn) sent a very similar patch just recently which appears to have fallen out of my inbox unfortunately - can you please check what's going on there and coordinate with them? Let me know if you can't find the patch and I'll dig it out.

2 4

Re: [alsa-devel] [Alsa-user] Master volume control
by Paul D. DeRocco 14 Mar '13

14 Mar '13

> From: Clemens Ladisch [mailto:cladisch@googlemail.com] > > #include <stdio.h> > #include <stdlib.h> > #include <alsa/asoundlib.h> > > static void check(int err, const char *f) > { > if (err < 0) { > fprintf(stderr, "%s failed: %s\n", f, > snd_strerror(err)); > exit(EXIT_FAILURE); > } > } > #define CHECK(f) check(f, #f) > > int main() > { > snd_ctl_t *ctl; > snd_ctl_elem_value_t *value; > > CHECK(snd_ctl_open(&ctl, "default", 0)); > > snd_ctl_elem_value_alloca(&value); > snd_ctl_elem_value_set_interface(value, > SND_CTL_ELEM_IFACE_MIXER); > snd_ctl_elem_value_set_name(value, "Master Playback Volume"); > snd_ctl_elem_value_set_integer(value, 0, 42); > CHECK(snd_ctl_elem_write(ctl, value)); > > snd_ctl_close(ctl); > return 0; > } Well, I finally got a chance to try this. It "works", but the snd_ctl_elem_write call takes a couple of milliseconds (that's around a million instructions on my Atom), and it apparently spends this time in kernel state, because it causes my sound thread to underrun, so it's not usable. If I use alsamixer, I don't have this problem; I can manipulate the master volume smoothly while I'm playing my synth app. So I went through the source, and found that it's using snd_mixer_selem_set_playback_volume. This is apparently part of something called the "Simple Mixer Interface", yet another section of ALSA which is completely undocumented, other than the Doxygen stuff (which is only meaningful as a reference for someone who already knows it inside out, but can't remember e.g. whether playback_pcm comes before or after capture_pcm in the snd_mixer_selem_regopt structure). So what's the minimum I need to do in order to get at the Master Playback Volume, via the Simple Mixer Interface? -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com

3 6

[alsa-devel] [PATCH v2] ALSA: hda - Disable IDT eapd_switch if there are no internal speakers
by David Henningsson 14 Mar '13

14 Mar '13

If there are no internal speakers, we should not turn the eapd switch off, because it might be necessary to keep high for Headphone. BugLink: https://bugs.launchpad.net/bugs/1155016 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_sigmatel.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) I'm okay with your suggestion. I only changed from "false" to "0" to be consistent with other usage of eapd_switch. diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index d57c81e..3566731 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -815,6 +815,29 @@ static int find_mute_led_cfg(struct hda_codec *codec, int default_polarity) return 0; } +/* check whether a built-in speaker is included in parsed pins */ +static bool has_builtin_speaker(struct hda_codec *codec) +{ + struct sigmatel_spec *spec = codec->spec; + hda_nid_t *nid_pin; + int nids, i; + + if (spec->gen.autocfg.line_out_type == AUTO_PIN_SPEAKER_OUT) { + nid_pin = spec->gen.autocfg.line_out_pins; + nids = spec->gen.autocfg.line_outs; + } else { + nid_pin = spec->gen.autocfg.speaker_pins; + nids = spec->gen.autocfg.speaker_outs; + } + + for (i = 0; i < nids; i++) { + unsigned int def_conf = snd_hda_codec_get_pincfg(codec, nid_pin[i]); + if (snd_hda_get_input_pin_attr(def_conf) == INPUT_PIN_ATTR_INT) + return true; + } + return false; +} + /* * PC beep controls */ @@ -3891,6 +3914,12 @@ static int patch_stac92hd73xx(struct hda_codec *codec) return err; } + /* Don't GPIO-mute speakers if there are no internal speakers, because + * the GPIO might be necessary for Headphone + */ + if (spec->eapd_switch && !has_builtin_speaker(codec)) + spec->eapd_switch = 0; + codec->proc_widget_hook = stac92hd7x_proc_hook; snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_PROBE); -- 1.7.9.5

2 1

[alsa-devel] [PATCH] ALSA: hda - Disable IDT eapd_switch if there are no internal speakers
by David Henningsson 14 Mar '13

14 Mar '13

If there are no internal speakers, we should not turn the eapd switch off, because it might be necessary to keep high for Headphone. BugLink: https://bugs.launchpad.net/bugs/1155016 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_sigmatel.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) Hi Takashi, I encountered the bug when working with a pre-release machine (so no alsa-info, unfortunately). Feel free to commit if you think this is a good idea. Or can you think of a use case where this would cause a regression? diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index d57c81e..66200ea8 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -3524,6 +3524,31 @@ static int stac_parse_auto_config(struct hda_codec *codec) if (err < 0) return err; + /* Don't GPIO-mute speakers if there are no internal speakers, because + the GPIO might be necessary for Headphone */ + if (spec->eapd_switch) { + hda_nid_t *nid_pin; + int nids, i; + bool found = false; + if (spec->gen.autocfg.line_out_type == AUTO_PIN_SPEAKER_OUT) { + nid_pin = spec->gen.autocfg.line_out_pins; + nids = spec->gen.autocfg.line_outs; + } else { + nid_pin = spec->gen.autocfg.speaker_pins; + nids = spec->gen.autocfg.speaker_outs; + } + for (i = 0; i < nids; i++) { + unsigned int def_conf = snd_hda_codec_get_pincfg(codec, nid_pin[i]); + unsigned int attr = snd_hda_get_input_pin_attr(def_conf); + if (attr == INPUT_PIN_ATTR_INT) { + found = true; + break; + } + } + if (!found) + spec->eapd_switch = 0; + } + /* minimum value is actually mute */ spec->gen.vmaster_tlv[3] |= TLV_DB_SCALE_MUTE; -- 1.7.9.5

2 1

[alsa-devel] [PATCH 1/2] ALSA: info: Avoid leaking kernel memory
by Takashi Iwai 14 Mar '13

14 Mar '13

Make sure that the allocated buffer for reading the proc file won't expose the uncleared kernel memory. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/info.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/info.c b/sound/core/info.c index db308db..58e97b3 100644 --- a/sound/core/info.c +++ b/sound/core/info.c @@ -89,7 +89,7 @@ static int resize_info_buffer(struct snd_info_buffer *buffer, char *nbuf; nsize = PAGE_ALIGN(nsize); - nbuf = krealloc(buffer->buffer, nsize, GFP_KERNEL); + nbuf = krealloc(buffer->buffer, nsize, GFP_KERNEL | __GFP_ZERO); if (! nbuf) return -ENOMEM; @@ -353,7 +353,7 @@ static int snd_info_entry_open(struct inode *inode, struct file *file) goto __nomem; data->rbuffer = buffer; buffer->len = PAGE_SIZE; - buffer->buffer = kmalloc(buffer->len, GFP_KERNEL); + buffer->buffer = kzalloc(buffer->len, GFP_KERNEL); if (buffer->buffer == NULL) goto __nomem; } -- 1.8.1.4

2 3

[alsa-devel] [PATCH] ASoC: arizona: Ensure we clock two channels for I2S mode
by Mark Brown 13 Mar '13

13 Mar '13

I2S requires stereo clocking even for mono data. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index 0c70d503..2b0803e 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -818,7 +818,7 @@ static int arizona_hw_params(struct snd_pcm_substream *substream, struct arizona *arizona = priv->arizona; int base = dai->driver->base; const int *rates; - int i, ret; + int i, ret, val; int chan_limit = arizona->pdata.max_channels_clocked[dai->id - 1]; int bclk, lrclk, wl, frame, bclk_target; @@ -834,6 +834,13 @@ static int arizona_hw_params(struct snd_pcm_substream *substream, bclk_target *= chan_limit; } + /* Force stereo for I2S mode */ + val = snd_soc_read(codec, base + ARIZONA_AIF_FORMAT); + if (params_channels(params) == 1 && (val & ARIZONA_AIF1_FMT_MASK)) { + arizona_aif_dbg(dai, "Forcing stereo mode\n"); + bclk_target *= 2; + } + for (i = 0; i < ARRAY_SIZE(arizona_44k1_bclk_rates); i++) { if (rates[i] >= bclk_target && rates[i] % params_rate(params) == 0) { -- 1.7.10.4

1 0

[alsa-devel] [PATCH 1/3] ALSA: hda - Drop explicit memset() by reallocation with __GFP_ZERO
by Takashi Iwai 13 Mar '13

13 Mar '13

Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 04b5738..a1c5053 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -5539,10 +5539,9 @@ void *snd_array_new(struct snd_array *array) void *nlist; if (snd_BUG_ON(num >= 4096)) return NULL; - nlist = krealloc(array->list, size, GFP_KERNEL); + nlist = krealloc(array->list, size, GFP_KERNEL | __GFP_ZERO); if (!nlist) return NULL; - memset(nlist + oldsize, 0, size - oldsize); array->list = nlist; array->alloced = num; } -- 1.8.1.4

1 2

[alsa-devel] How to send non-SysEx system messages via ALSA?
by Joerg-Cyril.Hoehle＠t-systems.com 13 Mar '13

13 Mar '13

Hi, seqmid.h contains function that declare the major event types like snd_seq_ev_set_noteon and snd_seq_ev_set_sysex. However, seq_event.h knows many more types, e.g. SND_SEQ_EVENT_START and SND_SEQ_EVENT_CLOCK/TICK. Now, consider an app playing a MIDI file or a debug tool that allows to send arbitrary messages. How should such an app send e.g. the 2-byte MTC Quarter Frame sequence via ALSA? A. Use a 2 byte buffer F1 xx and snd_seq_ev_set_sysex(&event, 2, buf); B. Use SND_SEQ_EVENT_TICK and figure out some copy&paste code from seqmidi.h, perhaps snd_seq_ev_set_queue_control(ev,SND_SEQ_EVENT_TICK,SND_SEQ_QUEUE_DIRECT,xx) But why does that alter my destination port via snd_seq_ev_set_dest(ev, SND_SEQ_CLIENT_SYSTEM, SND_SEQ_PORT_SYSTEM_TIMER)? C. It's SND_SEQ_EVENT_CLOCK actually, TICK being the one byte F8 real-time message? Background: Wine on Linux needs to generate such messages on behalf of applications and users with real MIDI HW. So far Wine assumes that it can encapsulate all system messages in a SysEx, IOW Wine does A. Is that usage of the set_sysex API correct? More generally, can Wine transparently stuff system messages into a byte buffer and send them off via snd_seq_ev_set_sysex? Thank you, Jörg Höhle

5 8

[alsa-devel] [patch] ALSA: ASoC: tas5086: signedness bug in tas5086_hw_params()
by Dan Carpenter 13 Mar '13

13 Mar '13

"val" has to be signed for the error handling to work. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c index 008bea4..41d03ae 100644 --- a/sound/soc/codecs/tas5086.c +++ b/sound/soc/codecs/tas5086.c @@ -251,7 +251,7 @@ static int tas5086_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_codec *codec = dai->codec; struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); - unsigned int val; + int val; int ret; priv->rate = params_rate(params);

3 2

[alsa-devel] [PATCH] ASoC: fsi: remove unused irq
by Kuninori Morimoto 13 Mar '13

13 Mar '13

FSI is using devm_request_irq() from 1ddd82868cc888e008ed520465c172a6cdddd689 (ASoC: fsi: use devm_request_irq()) master->irq is no longer needed. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/fsi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index a606d0f..7a874a3 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -300,7 +300,6 @@ struct fsi_core { struct fsi_master { void __iomem *base; - int irq; struct fsi_priv fsia; struct fsi_priv fsib; struct fsi_core *core; @@ -2086,7 +2085,6 @@ static int fsi_probe(struct platform_device *pdev) } /* master setting */ - master->irq = irq; master->core = (struct fsi_core *)id_entry->driver_data; spin_lock_init(&master->lock); -- 1.7.9.5

2 3

[alsa-devel] [PATCH 2/2] ASoC: fsl: imx-audmux: Use devm_clk_get()
by Fabio Estevam 13 Mar '13

13 Mar '13

From: Fabio Estevam <fabio.estevam(a)freescale.com> By using devm_clk_get() we can save a call to clk_put(). Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/fsl/imx-audmux.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c index 3f333e5..47f046a 100644 --- a/sound/soc/fsl/imx-audmux.c +++ b/sound/soc/fsl/imx-audmux.c @@ -262,7 +262,7 @@ static int imx_audmux_probe(struct platform_device *pdev) return PTR_ERR(pinctrl); } - audmux_clk = clk_get(&pdev->dev, "audmux"); + audmux_clk = devm_clk_get(&pdev->dev, "audmux"); if (IS_ERR(audmux_clk)) { dev_dbg(&pdev->dev, "cannot get clock: %ld\n", PTR_ERR(audmux_clk)); @@ -282,7 +282,6 @@ static int imx_audmux_remove(struct platform_device *pdev) { if (audmux_type == IMX31_AUDMUX) audmux_debugfs_remove(); - clk_put(audmux_clk); return 0; } -- 1.7.9.5

2 3

Re: [alsa-devel] [PATCH] ASoC: samsung: remove last traces of neo1973-gta01
by Mark Brown 13 Mar '13

13 Mar '13

On Tue, Mar 12, 2013 at 11:09:35PM +0100, Paul Bolle wrote: > The (rudimentary) support for the Openmoko Neo1973 GTA01 got removed in > commit 1ae5cbc52e7c6619a3f44b87809fd25370df31bb ("ASoC: neo1973_wm8753: > remove references to the neo1973-gta01 machine"). Remove its last traces > in the Kconfig file too. The support wasn't rudimentary, it was a pretty much complete audio driver. Anyway I've applied this with a fixed up commit message.

1 0

Re: [alsa-devel] [PATCH] ASoC: samsung: remove last traces of neo1973-gta01
by Kukjin Kim 13 Mar '13

13 Mar '13

Paul Bolle wrote: > > The (rudimentary) support for the Openmoko Neo1973 GTA01 got removed in > commit 1ae5cbc52e7c6619a3f44b87809fd25370df31bb ("ASoC: neo1973_wm8753: > remove references to the neo1973-gta01 machine"). Remove its last traces > in the Kconfig file too. > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> Acked-by: Kukjin Kim <kgene.kim(a)samsung.com> - Kukjin > --- > Untested. > > sound/soc/samsung/Kconfig | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig > index 90e7e66..475fb0d 100644 > --- a/sound/soc/samsung/Kconfig > +++ b/sound/soc/samsung/Kconfig > @@ -35,11 +35,10 @@ config SND_SAMSUNG_I2S > tristate > > config SND_SOC_SAMSUNG_NEO1973_WM8753 > - tristate "Audio support for Openmoko Neo1973 Smartphones (GTA01/GTA02)" > - depends on SND_SOC_SAMSUNG && (MACH_NEO1973_GTA01 || MACH_NEO1973_GTA02) > + tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)" > + depends on SND_SOC_SAMSUNG && MACH_NEO1973_GTA02 > select SND_S3C24XX_I2S > select SND_SOC_WM8753 > - select SND_SOC_LM4857 if MACH_NEO1973_GTA01 > select SND_SOC_DFBMCS320 > help > Say Y here to enable audio support for the Openmoko Neo1973 > -- > 1.7.11.7

1 0

Re: [alsa-devel] HDA regression on Fujitsu S7020 laptop (ALC260 codec)
by Jonathan Woithe 12 Mar '13

12 Mar '13

Hi Takashi > > On Wed, Feb 20, 2013 at 02:14:20PM +0100, Takashi Iwai wrote: > > > > Sounds good - I will test in the next day or so and report back. What's the > > > > most efficient way to get hold of this tree / branch given that I have the > > > > for-next branch of sound.git? Can I somehow leverage this, or do I need to > > > > do a completely separate checkout? Apologies if this is a basic question - > > > > I'm still coming to terms with git. > > > > > > sound-unstable git tree always contains the sound git tree master > > > branch, so everything is there basically. ... > > > > What's the next step in the process? I've reported the outcome of the tests > > of sound-unstable as per that report progress is being made. Is it a case > > of waiting for things to stabilise, or do you need me to do something to > > move things along? If so, what? > > I merged the patches to the main sound git tree for-next branch now. > > Also a few updates are merged there, too: now the hp mic jack mode > should be able to change the pin control no matter whether which > capture source is. Also, the capture source won't change the hp/mic > pinctl when the jack mode enum is created. This reduces the > automation but also reduces the confusion, too. After all, when jack > mode is present, user wants to control the pin by himself. > > Let me know if anything else is missing or broken. I've given this new revision a quick test; sorry for the delay. With this revision, when using "model=fujitsu-jwse" things seem to be working pretty well. In particular, the updates you mention greatly improve usability; the lack of automatic interaction between mixer controls makes it much easier to use and understand. I think everything is present and accounted for in this latest revision. Thanks for your work on this. The only slightly odd thing I noticed was that whenever the driver is loaded the "headphone mic jack mode" defaults to "mic bias 80pc", rather than "line out" or "headphone" which I would have expected. Obviously this can be manually or automatically overridden after module load, but in many ways it would be good if it defaulted to one of the output modes (given that the jack's primary purpose is for output). Where does this leave us now? Is the "fujitsu-jwse" a permanent thing, or will the respective changes be rolled into something more generic? Regards jonathan

2 2

Re: [alsa-devel] [PATCH linux-next v2] ASoC: adau1373: adau1373_hw_params: Silence overflow warning
by Mark Brown 12 Mar '13

12 Mar '13

On Tue, Mar 12, 2013 at 01:17:26PM -0600, Tim Gardner wrote: > > threads (I nearly deleted this unread) and avoid including > > enormous CC lists like this in the body of the mail. > I'm just going by the default output of scripts/get_maintainer.pl. Are > there better options to filter the roles ? In this case I received a > review from a supporter (Lars), and the patch is being committed by > yet another supporter (yourself). Would you have noticed this patch > had I restricted the Cc list to just maintainers and lists ? I specifically mean don't include the lists in the body of the mail - it means they either litter the git log or need to be manually deleted. If you're just using unfiltered get_maintainer output then I'd suggest that you generate the CCs in your scripts when sending rather than putting them in the changelog.

1 0

[alsa-devel] [PATCH] ALSA: ASoC: davinci-mcasp: clean ip davinci_hw_common_param()
by Daniel Mack 12 Mar '13

12 Mar '13

As pointed of by Vaibhav, commit 2952b27e2 ("ASoC: davinci-mcasp: Add support for multichannel playback") duplicated the logic of counting the active serializers. That can be avoided by shifting the code around a bit. Also, drop two unused defines introduced by the same commit. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Michal Bachraty <michal.bachraty(a)streamunlimited.com> Cc: Vaibhav Bedia <vaibhav.bedia(a)ti.com> --- sound/soc/davinci/davinci-mcasp.c | 34 +++++++++++----------------------- 1 file changed, 11 insertions(+), 23 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index b386cad..8a9c0ee 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -237,8 +237,6 @@ #define RXSTATE BIT(5) #define SRMOD_MASK 3 #define SRMOD_INACTIVE 0 -#define SRMOD_TX 1 -#define SRMOD_RX 2 /* * DAVINCI_MCASP_LBCTL_REG - Loop Back Control Register Bits @@ -691,27 +689,6 @@ static int davinci_hw_common_param(struct davinci_audio_dev *dev, int stream, } for (i = 0; i < dev->num_serializer; i++) { - if (dev->serial_dir[i] == TX_MODE) - tx_ser++; - if (dev->serial_dir[i] == RX_MODE) - rx_ser++; - } - - if (stream == SNDRV_PCM_STREAM_PLAYBACK) - ser = tx_ser; - else - ser = rx_ser; - - if (ser < max_active_serializers) { - dev_warn(dev->dev, "stream has more channels (%d) than are " - "enabled in mcasp (%d)\n", channels, ser * slots); - return -EINVAL; - } - - tx_ser = 0; - rx_ser = 0; - - for (i = 0; i < dev->num_serializer; i++) { mcasp_set_bits(dev->base + DAVINCI_MCASP_XRSRCTL_REG(i), dev->serial_dir[i]); if (dev->serial_dir[i] == TX_MODE && @@ -730,6 +707,17 @@ static int davinci_hw_common_param(struct davinci_audio_dev *dev, int stream, } } + if (stream == SNDRV_PCM_STREAM_PLAYBACK) + ser = tx_ser; + else + ser = rx_ser; + + if (ser < max_active_serializers) { + dev_warn(dev->dev, "stream has more channels (%d) than are " + "enabled in mcasp (%d)\n", channels, ser * slots); + return -EINVAL; + } + if (dev->txnumevt && stream == SNDRV_PCM_STREAM_PLAYBACK) { if (dev->txnumevt * tx_ser > 64) dev->txnumevt = 1; -- 1.8.1.4

4 4

Re: [alsa-devel] [PATCH 07/10] ASoC: phycore-ac97: Add DT support
by Mark Brown 12 Mar '13

12 Mar '13

On Sun, Mar 10, 2013 at 07:33:08PM +0100, Markus Pargmann wrote: > Add devicetree support for this audio soc fabric driver. > > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> > --- > sound/soc/fsl/phycore-ac97.c | 148 ++++++++++++++++++++++++++++++++++++------- > 1 file changed, 125 insertions(+), 23 deletions(-) A binding document is mandatory for new bindings. > +#ifdef CONFIG_MACH_IMX27_DT > + .cpu_dai_name = "10010000.ssi", > + .platform_name = "imx-fiq-pcm-audio", > +#else This looks wrong, at least the CPU DAI name should be being looked up via the DT. > +static const struct of_device_id imx_phycore_ac97_of_dev_id[] = { > + { > + .compatible = "phytec,imx27-pca100-ac97", > + .data = (void *)MX27_PCA100, > + }, { > + .compatible = "phytec,imx27-pcm043-ac97", > + .data = (void *)MX27_PCM043 > + }, { > + /* sentinel */ > + } > +}; > +MODULE_DEVICE_TABLE(of, imx_phycore_ac97_of_dev_id); It seems like we ought to be able to describe the properties of the boards in this class rather than just enumerating the boards. What are the differences? > MODULE_AUTHOR("Sascha Hauer <s.hauer(a)pengutronix.de>"); > -MODULE_DESCRIPTION("PhyCORE ALSA SoC driver"); > +MODULE_DESCRIPTION(DRV_NAME ": PhyCORE ALSA SoC fabric driver"); Please don't make up terms like "fabric driver".

1 0

Re: [alsa-devel] [PATCH 05/10] ASoC: pcm030 audio fabric: remove __init from probe
by Mark Brown 12 Mar '13

12 Mar '13

On Sun, Mar 10, 2013 at 07:33:06PM +0100, Markus Pargmann wrote: > Remove probe function from the init section. > > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> Applied, thanks.

1 0

Re: [alsa-devel] [PATCH 04/10] ASoC: Kconfig: imx-ssi needs imx-fiq and imx-dma
by Mark Brown 12 Mar '13

12 Mar '13

On Sun, Mar 10, 2013 at 07:33:05PM +0100, Markus Pargmann wrote: > config SND_SOC_IMX_SSI > + select SND_SOC_IMX_PCM_DMA > + select SND_SOC_IMX_PCM_FIQ > tristate Really? I'd expect this to be an or, if we've got DMA I can't see any reason why we'd want to use the FIQ.

1 0

Re: [alsa-devel] [PATCH 03/10] mx-ssi: flush fifos
by Mark Brown 12 Mar '13

12 Mar '13

On Sun, Mar 10, 2013 at 07:33:04PM +0100, Markus Pargmann wrote: > From: Sascha Hauer <s.hauer(a)pengutronix.de> > > Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> Why? Is this a bug fix? I'm guessing it is but...

1 0

Re: [alsa-devel] [PATCH 02/10] imx-ssi: Fix occasional AC97 reset failure
by Mark Brown 12 Mar '13

12 Mar '13

On Sun, Mar 10, 2013 at 07:33:03PM +0100, Markus Pargmann wrote: > From: Sascha Hauer <s.hauer(a)pengutronix.de> > > Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> > Signed-off-by: Markus Pargmann <mpa(a)pengutronix.de> Applied but *always* use subject lines appropriate to the subsystem and bugfixes like this should be pulled to the front of the series as they should be sent to mainline earlier.

1 0

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

12 Mar '13

On Sun, Mar 10, 2013 at 07:33:02PM +0100, Markus Pargmann 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. Applied, but some notes about why this is already supported would be useful and *always* use subject lines appropriate for the subsystem.

1 0

Re: [alsa-devel] [PATCH linux-next] ASoC: wm_hubs: Silence reg_r and reg_l 'may be used uninitialized' warnings
by Mark Brown 12 Mar '13

12 Mar '13

On Sun, Mar 10, 2013 at 10:58:21AM -0600, Tim Gardner wrote: > Return an error from wm_hubs_read_dc_servo() if hubs->dcs_readback_mode is not > correctly initialized. You might as well bail out since nothing is likely to > work correctly afterwards. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH linux-next v2] ASoC: adau1373: adau1373_hw_params: Silence overflow warning
by Mark Brown 12 Mar '13

12 Mar '13

On Mon, Mar 11, 2013 at 01:18:23PM -0600, 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 Applied, but please don't bury patches in the middle of e-mail threads (I nearly deleted this unread) and avoid including > 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> enormous CC lists like this in the body of the mail.

1 0

Re: [alsa-devel] [PATCH] omap: convert to devm_ioremap_resource()
by Mark Brown 12 Mar '13

12 Mar '13

On Mon, Mar 11, 2013 at 05:58:57PM +0200, Silviu-Mihai Popescu wrote: > Convert all uses of devm_request_and_ioremap() to the newly introduced > devm_ioremap_resource() which provides more consistent error handling. > > devm_ioremap_resource() provides its own error messages so all explicit > error messages can be removed from the failure code paths. Applied, thanks. Please use subject lines appropriate to the subsystem.

1 0

Re: [alsa-devel] [PATCH] ASoC: core: fix possible memory leak in snd_soc_bytes_put()
by Mark Brown 12 Mar '13

12 Mar '13

On Tue, Mar 12, 2013 at 12:35:14AM +0800, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > 'data' is malloced in snd_soc_bytes_put() and should be freed > before leaving from the error handling cases, otherwise it will cause > memory leak. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm_adsp: fix possible memory leak in wm_adsp_load_coeff()
by Mark Brown 12 Mar '13

12 Mar '13

On Tue, Mar 12, 2013 at 12:23:15AM +0800, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > 'file' is malloced in wm_adsp_load_coeff() and should be freed > before leaving from the error handling cases, otherwise it will cause > memory leak. Applied, thanks.

1 0

[alsa-devel] [RFC][PATCH] ASoC: remove codec from list if registration failed
by Kuninori Morimoto 12 Mar '13

12 Mar '13

Current snd_soc_register_codec() adds codec to list, and calls snd_soc_register_dais(). But, this listed codec should be removed if dais registration was failed. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- If my understanding is correct... sound/soc/soc-core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 1ac96df..38d6182 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -4097,6 +4097,10 @@ int snd_soc_register_codec(struct device *dev, return 0; fail_codec_name: + mutex_lock(&client_mutex); + list_del(&codec->list); + mutex_unlock(&client_mutex); + kfree(codec->name); fail_codec: kfree(codec); -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH -next] ASoC: tas5086: use module_i2c_driver to simplify the code
by Mark Brown 12 Mar '13

12 Mar '13

On Tue, Mar 12, 2013 at 09:36:24PM +0800, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > Use the module_i2c_driver() macro to make the code smaller > and a bit simpler. Applied, thanks.

1 0

[alsa-devel] [PATCH] hda-emu: stream tag should always be non-zero
by David Henningsson 12 Mar '13

12 Mar '13

Sending zero as stream tag is discouraged, because it means no data, and the real code doesn't do that. Avoid it here too. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- hda-emu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hda-emu.c b/hda-emu.c index c98a3ea..13756bb 100644 --- a/hda-emu.c +++ b/hda-emu.c @@ -760,7 +760,7 @@ void hda_test_pcm(int id, int op, int subid, } hda_log(HDA_LOG_INFO, "PCM format_val = 0x%x\n", format_val); #ifdef HAVE_COMMON_PREPARE - err = snd_hda_codec_prepare(_codec, hinfo, subid, + err = snd_hda_codec_prepare(_codec, hinfo, subid + 1, format_val, substream); #else err = hinfo->ops.prepare(hinfo, _codec, 1, format_val, substream); -- 1.7.9.5

2 1

[alsa-devel] [PATCH] hda-emu: Fix typo in HAVE_COMMON_PREPARE
by David Henningsson 12 Mar '13

12 Mar '13

This typo caused snd_hda_codec_prepare never to be executed by hda-emu. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4b20f50..01a3a16 100644 --- a/configure.ac +++ b/configure.ac @@ -501,7 +501,7 @@ if grep -q snd_hda_codec_prepare hda/hda_codec.h; then else AC_MSG_RESULT(no) fi -if test "$HAVE_COMMON_PREAPRE" = "yes"; then +if test "$HAVE_COMMON_PREPARE" = "yes"; then AC_DEFINE(HAVE_COMMON_PREPARE) fi -- 1.7.9.5

2 1

[alsa-devel] [PATCH] Revert "ALSA: hda - Remove limit of widget connections"
by David Henningsson 12 Mar '13

12 Mar '13

This reverts commit 4eea30914facd2c99061cd70e5b05d3c76c743a2. The commit causes an error with node ranges: In my case, connection list length is 3, with a connection list read of 0x1e9915: a total of 6 nids (0x15, 0x16, 0x17, 0x18, 0x19, 0x1e). Since the new code makes us allocate only 3 nids to the array sent to get_raw_connections, the function fails. --- sound/pci/hda/hda_codec.c | 62 +++++++++++++++----------------------------- sound/pci/hda/hda_codec.h | 4 ++- sound/pci/hda/hda_proc.c | 20 +++----------- sound/pci/hda/patch_hdmi.c | 3 --- 4 files changed, 28 insertions(+), 61 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 97c68dd..e5e8549 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -382,23 +382,13 @@ static void remove_conn_list(struct hda_codec *codec) /* read the connection and add to the cache */ static int read_and_add_raw_conns(struct hda_codec *codec, hda_nid_t nid) { - hda_nid_t list[32]; - hda_nid_t *result = list; + hda_nid_t list[HDA_MAX_CONNECTIONS]; int len; len = snd_hda_get_raw_connections(codec, nid, list, ARRAY_SIZE(list)); - if (len == -ENOSPC) { - len = snd_hda_get_num_raw_conns(codec, nid); - result = kmalloc(sizeof(hda_nid_t) * len, GFP_KERNEL); - if (!result) - return -ENOMEM; - len = snd_hda_get_raw_connections(codec, nid, result, len); - } - if (len >= 0) - len = snd_hda_override_conn_list(codec, nid, len, result); - if (result != list) - kfree(result); - return len; + if (len < 0) + return len; + return snd_hda_override_conn_list(codec, nid, len, list); } /** @@ -476,27 +466,6 @@ int snd_hda_get_connections(struct hda_codec *codec, hda_nid_t nid, } EXPORT_SYMBOL_HDA(snd_hda_get_connections); -/* return CONNLIST_LEN parameter of the given widget */ -static unsigned int get_num_conns(struct hda_codec *codec, hda_nid_t nid) -{ - unsigned int wcaps = get_wcaps(codec, nid); - unsigned int parm; - - if (!(wcaps & AC_WCAP_CONN_LIST) && - get_wcaps_type(wcaps) != AC_WID_VOL_KNB) - return 0; - - parm = snd_hda_param_read(codec, nid, AC_PAR_CONNLIST_LEN); - if (parm == -1) - parm = 0; - return parm; -} - -int snd_hda_get_num_raw_conns(struct hda_codec *codec, hda_nid_t nid) -{ - return get_num_conns(codec, nid) & AC_CLIST_LENGTH; -} - /** * snd_hda_get_raw_connections - copy connection list without cache * @codec: the HDA codec @@ -514,16 +483,19 @@ int snd_hda_get_raw_connections(struct hda_codec *codec, hda_nid_t nid, unsigned int parm; int i, conn_len, conns; unsigned int shift, num_elems, mask; + unsigned int wcaps; hda_nid_t prev_nid; int null_count = 0; if (snd_BUG_ON(!conn_list || max_conns <= 0)) return -EINVAL; - parm = get_num_conns(codec, nid); - if (!parm) + wcaps = get_wcaps(codec, nid); + if (!(wcaps & AC_WCAP_CONN_LIST) && + get_wcaps_type(wcaps) != AC_WID_VOL_KNB) return 0; + parm = snd_hda_param_read(codec, nid, AC_PAR_CONNLIST_LEN); if (parm & AC_CLIST_LONG) { /* long form */ shift = 16; @@ -580,13 +552,21 @@ int snd_hda_get_raw_connections(struct hda_codec *codec, hda_nid_t nid, continue; } for (n = prev_nid + 1; n <= val; n++) { - if (conns >= max_conns) - return -ENOSPC; + if (conns >= max_conns) { + snd_printk(KERN_ERR "hda_codec: " + "Too many connections %d for NID 0x%x\n", + conns, nid); + return -EINVAL; + } conn_list[conns++] = n; } } else { - if (conns >= max_conns) - return -ENOSPC; + if (conns >= max_conns) { + snd_printk(KERN_ERR "hda_codec: " + "Too many connections %d for NID 0x%x\n", + conns, nid); + return -EINVAL; + } conn_list[conns++] = val; } prev_nid = val; diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 23ca172..246ed53 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -551,6 +551,9 @@ enum { AC_JACK_PORT_BOTH, }; +/* max. connections to a widget */ +#define HDA_MAX_CONNECTIONS 32 + /* max. codec address */ #define HDA_MAX_CODEC_ADDRESS 0x0f @@ -957,7 +960,6 @@ snd_hda_get_num_conns(struct hda_codec *codec, hda_nid_t nid) { return snd_hda_get_connections(codec, nid, NULL, 0); } -int snd_hda_get_num_raw_conns(struct hda_codec *codec, hda_nid_t nid); int snd_hda_get_raw_connections(struct hda_codec *codec, hda_nid_t nid, hda_nid_t *conn_list, int max_conns); int snd_hda_get_conn_list(struct hda_codec *codec, hda_nid_t nid, diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c index 0fee8fa..5e02f26 100644 --- a/sound/pci/hda/hda_proc.c +++ b/sound/pci/hda/hda_proc.c @@ -22,7 +22,6 @@ */ #include <linux/init.h> -#include <linux/slab.h> #include <sound/core.h> #include "hda_codec.h" #include "hda_local.h" @@ -624,7 +623,7 @@ static void print_codec_info(struct snd_info_entry *entry, snd_hda_param_read(codec, nid, AC_PAR_AUDIO_WIDGET_CAP); unsigned int wid_type = get_wcaps_type(wid_caps); - hda_nid_t *conn = NULL; + hda_nid_t conn[HDA_MAX_CONNECTIONS]; int conn_len = 0; snd_iprintf(buffer, "Node 0x%02x [%s] wcaps 0x%x:", nid, @@ -661,18 +660,9 @@ static void print_codec_info(struct snd_info_entry *entry, if (wid_type == AC_WID_VOL_KNB) wid_caps |= AC_WCAP_CONN_LIST; - if (wid_caps & AC_WCAP_CONN_LIST) { - conn_len = snd_hda_get_num_raw_conns(codec, nid); - if (conn_len > 0) { - conn = kmalloc(sizeof(hda_nid_t) * conn_len, - GFP_KERNEL); - if (!conn) - return; - if (snd_hda_get_raw_connections(codec, nid, conn, - conn_len) < 0) - conn_len = 0; - } - } + if (wid_caps & AC_WCAP_CONN_LIST) + conn_len = snd_hda_get_raw_connections(codec, nid, conn, + HDA_MAX_CONNECTIONS); if (wid_caps & AC_WCAP_IN_AMP) { snd_iprintf(buffer, " Amp-In caps: "); @@ -745,8 +735,6 @@ static void print_codec_info(struct snd_info_entry *entry, if (codec->proc_widget_hook) codec->proc_widget_hook(buffer, codec, nid); - - kfree(conn); } snd_hda_power_down(codec); } diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 78e1827..d24af4a 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -64,9 +64,6 @@ struct hdmi_spec_per_cvt { unsigned int maxbps; }; -/* max. connections to a widget */ -#define HDA_MAX_CONNECTIONS 32 - struct hdmi_spec_per_pin { hda_nid_t pin_nid; int num_mux_nids; -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH -next] ASoC: tas5086: use module_i2c_driver to simplify the code
by Daniel Mack 12 Mar '13

12 Mar '13

On 12.03.2013 14:36, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > Use the module_i2c_driver() macro to make the code smaller > and a bit simpler. Thanks for catching this! > Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> Acked-by: Daniel Mack <zonque(a)gmail.com> > --- > sound/soc/codecs/tas5086.c | 12 +----------- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c > index 008bea4..40cee84 100644 > --- a/sound/soc/codecs/tas5086.c > +++ b/sound/soc/codecs/tas5086.c > @@ -584,17 +584,7 @@ static struct i2c_driver tas5086_i2c_driver = { > .remove = tas5086_i2c_remove, > }; > > -static int __init tas5086_modinit(void) > -{ > - return i2c_add_driver(&tas5086_i2c_driver); > -} > -module_init(tas5086_modinit); > - > -static void __exit tas5086_modexit(void) > -{ > - i2c_del_driver(&tas5086_i2c_driver); > -} > -module_exit(tas5086_modexit); > +module_i2c_driver(tas5086_i2c_driver); > > MODULE_AUTHOR("Daniel Mack <zonque(a)gmail.com>"); > MODULE_DESCRIPTION("Texas Instruments TAS5086 ALSA SoC Codec Driver"); > >

1 0

[alsa-devel] [PATCH] salsa-lib: define __SALSA_EXPORT_FUNC in version.h
by Mihail Zenkov 12 Mar '13

12 Mar '13

We have to include "global.h" to define __SALSA_EXPORT_FUNC --- salsa-lib-0.1.3/src/version.h.in +++ salsa-lib-0.1.3-1/src/version.h.in @@ -1,6 +1,8 @@ #ifndef __ALSA_VERSION_H #define __ALSA_VERSION_H +#include "global.h" + #define SND_LIB_MAJOR @SND_LIB_MAJOR@ #define SND_LIB_MINOR @SND_LIB_MINOR@ #define SND_LIB_SUBMINOR @SND_LIB_SUBMINOR@

2 2

Re: [alsa-devel] [PATCH] omap: convert to devm_ioremap_resource()
by Peter Ujfalusi 12 Mar '13

12 Mar '13

On 03/11/2013 04:58 PM, Silviu-Mihai Popescu wrote: > Convert all uses of devm_request_and_ioremap() to the newly introduced > devm_ioremap_resource() which provides more consistent error handling. > > devm_ioremap_resource() provides its own error messages so all explicit > error messages can be removed from the failure code paths. Acked-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> > > Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990(a)gmail.com> > --- > sound/soc/omap/omap-dmic.c | 9 +++------ > sound/soc/omap/omap-mcpdm.c | 8 +++----- > 2 files changed, 6 insertions(+), 11 deletions(-) > > diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c > index 77e9e7e..8ebaf11 100644 > --- a/sound/soc/omap/omap-dmic.c > +++ b/sound/soc/omap/omap-dmic.c > @@ -493,12 +493,9 @@ static int asoc_dmic_probe(struct platform_device *pdev) > goto err_put_clk; > } > > - dmic->io_base = devm_request_and_ioremap(&pdev->dev, res); > - if (!dmic->io_base) { > - dev_err(&pdev->dev, "cannot remap\n"); > - ret = -ENOMEM; > - goto err_put_clk; > - } > + dmic->io_base = devm_ioremap_resource(&pdev->dev, res); > + if (IS_ERR(dmic->io_base)) > + return PTR_ERR(dmic->io_base); > > ret = snd_soc_register_dai(&pdev->dev, &omap_dmic_dai); > if (ret) > diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c > index 079f277..ddfcc18 100644 > --- a/sound/soc/omap/omap-mcpdm.c > +++ b/sound/soc/omap/omap-mcpdm.c > @@ -464,11 +464,9 @@ static int asoc_mcpdm_probe(struct platform_device *pdev) > if (res == NULL) > return -ENOMEM; > > - mcpdm->io_base = devm_request_and_ioremap(&pdev->dev, res); > - if (!mcpdm->io_base) { > - dev_err(&pdev->dev, "cannot remap\n"); > - return -ENOMEM; > - } > + mcpdm->io_base = devm_ioremap_resource(&pdev->dev, res); > + if (IS_ERR(mcpdm->io_base)) > + return PTR_ERR(mcpdm->io_base); > > mcpdm->irq = platform_get_irq(pdev, 0); > if (mcpdm->irq < 0) > -- Péter

1 0

Re: [alsa-devel] [PATCH] omap: convert to devm_ioremap_resource()
by Peter Ujfalusi 12 Mar '13

12 Mar '13

On 03/12/2013 09:24 AM, Silviu Popescu wrote: > As far as I can tell from the mails that you have provided, those > patches replace devm_request_mem_region(), followed by devm_ioremap() > with devm_request_and_ioremap(). > What this patch attempts to do is replace devm_request_and_ioremap() > with the newly introduced devm_ioremap_resource(), for the reasons > expressed in the patch body. Ah, true. -- Péter

1 0

[alsa-devel] [PATCH v3] ALSA: usb: Work around CM6631 sample rate change bug
by Torstein Hegge 12 Mar '13

12 Mar '13

The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sample rate while the interface is active. Reset the interface after setting the sampling frequency on sample rate changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous stream, causing distorted sound on sample rate changes. The reset is performed for all current C-Media UAC V2.0 devices, including CM6610, CM6620 and CM6631, but has only been tested with CM6631. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- Changes since v2: - More USB ids covered. - int crate -> int cur_rate - unsigned int previous_rate -> int prev_rate sound/usb/clock.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/sound/usb/clock.c b/sound/usb/clock.c index 5e634a2..98c4e26 100644 --- a/sound/usb/clock.c +++ b/sound/usb/clock.c @@ -253,7 +253,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, { struct usb_device *dev = chip->dev; unsigned char data[4]; - int err, crate; + int err, cur_rate, prev_rate; int clock = snd_usb_clock_find_source(chip, fmt->clock); if (clock < 0) @@ -266,6 +266,18 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return -ENXIO; } + if ((err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, + USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, + UAC2_CS_CONTROL_SAM_FREQ << 8, + snd_usb_ctrl_intf(chip) | (clock << 8), + data, sizeof(data))) < 0) { + snd_printk(KERN_WARNING "%d:%d:%d: cannot get freq (v2)\n", + dev->devnum, iface, fmt->altsetting); + return err; + } + + prev_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + data[0] = rate; data[1] = rate >> 8; data[2] = rate >> 16; @@ -290,9 +302,39 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return err; } - crate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); - if (crate != rate) - snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate); + cur_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + if (cur_rate != rate) { + snd_printd(KERN_WARNING + "current rate %d is different from the runtime rate %d\n", + cur_rate, rate); + } + + /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + if (cur_rate != prev_rate) { + switch (chip->usb_id) { + /* C-Media CM6610/CM6620/CM6631 */ + case USB_ID(0x054c, 0x06cf): /* Sony */ + case USB_ID(0x0b05, 0x17a8): /* Asus Xonar Essence One */ + case USB_ID(0x0d8c, 0x0301): + case USB_ID(0x0d8c, 0x0302): + case USB_ID(0x0d8c, 0x0304): /* CM6631 (Schiit) */ + case USB_ID(0x0d8c, 0x0305): + case USB_ID(0x0d8c, 0x0306): + case USB_ID(0x0d8c, 0x0309): /* CM6631 */ + case USB_ID(0x0d8c, 0x0310): + case USB_ID(0x0d8c, 0x0311): /* CM6610A */ + case USB_ID(0x0d8c, 0x0312): /* CM6620A */ + case USB_ID(0x0d8c, 0x0313): /* CM6630A */ + case USB_ID(0x0d8c, 0x0314): /* CM6631A */ + case USB_ID(0x0d8c, 0x0315): /* CM6632A */ + case USB_ID(0x0d8c, 0x0319): /* CM6631A */ + case USB_ID(0x200c, 0x1030): /* Reloop */ + usb_set_interface(dev, iface, 0); + usb_set_interface(dev, iface, fmt->altsetting); + break; + } + } return 0; } -- 1.7.10.4

2 3

Re: [alsa-devel] [PATCH] omap: convert to devm_ioremap_resource()
by Peter Ujfalusi 12 Mar '13

12 Mar '13

Hi, On 03/11/2013 04:58 PM, Silviu-Mihai Popescu wrote: > Convert all uses of devm_request_and_ioremap() to the newly introduced > devm_ioremap_resource() which provides more consistent error handling. > > devm_ioremap_resource() provides its own error messages so all explicit > error messages can be removed from the failure code paths. I believe both of the drivers has been patched for this: omap-mcbpdm: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-February/059484.h… http://mailman.alsa-project.org/pipermail/alsa-devel/2013-February/059427.h… omap-dmic: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-February/059485.h… and they should be already queued for next. -- Péter > > Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990(a)gmail.com> > --- > sound/soc/omap/omap-dmic.c | 9 +++------ > sound/soc/omap/omap-mcpdm.c | 8 +++----- > 2 files changed, 6 insertions(+), 11 deletions(-) > > diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c > index 77e9e7e..8ebaf11 100644 > --- a/sound/soc/omap/omap-dmic.c > +++ b/sound/soc/omap/omap-dmic.c > @@ -493,12 +493,9 @@ static int asoc_dmic_probe(struct platform_device *pdev) > goto err_put_clk; > } > > - dmic->io_base = devm_request_and_ioremap(&pdev->dev, res); > - if (!dmic->io_base) { > - dev_err(&pdev->dev, "cannot remap\n"); > - ret = -ENOMEM; > - goto err_put_clk; > - } > + dmic->io_base = devm_ioremap_resource(&pdev->dev, res); > + if (IS_ERR(dmic->io_base)) > + return PTR_ERR(dmic->io_base); > > ret = snd_soc_register_dai(&pdev->dev, &omap_dmic_dai); > if (ret) > diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c > index 079f277..ddfcc18 100644 > --- a/sound/soc/omap/omap-mcpdm.c > +++ b/sound/soc/omap/omap-mcpdm.c > @@ -464,11 +464,9 @@ static int asoc_mcpdm_probe(struct platform_device *pdev) > if (res == NULL) > return -ENOMEM; > > - mcpdm->io_base = devm_request_and_ioremap(&pdev->dev, res); > - if (!mcpdm->io_base) { > - dev_err(&pdev->dev, "cannot remap\n"); > - return -ENOMEM; > - } > + mcpdm->io_base = devm_ioremap_resource(&pdev->dev, res); > + if (IS_ERR(mcpdm->io_base)) > + return PTR_ERR(mcpdm->io_base); > > mcpdm->irq = platform_get_irq(pdev, 0); > if (mcpdm->irq < 0) >

1 0

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

12 Mar '13

>> David Helstroom wrote: >>> Interface 1 does not exist Please try the patch below. Regards, Clemens --8<---------------------------------------------------------------->8-- ALSA: usb-audio: add a workaround for the NuForce UDH-100 The NuForce UDH-100 numbers its interfaces incorrectly, which makes the interface associations come out wrong, which results in the driver erroring out with the message "Audio class v2 interfaces need an interface association". Work around this by searching for the interface association descriptor also in some other place where it might have ended up. Reported-by: Dave Helstroom <helstroom(a)google.com> Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> --- sound/usb/card.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/sound/usb/card.c b/sound/usb/card.c index df2f6d0..34dc3e8 100644 --- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -245,6 +245,21 @@ static int snd_usb_create_streams(struct snd_usb_audio *chip, int ctrlif) usb_ifnum_to_if(dev, ctrlif)->intf_assoc; if (!assoc) { + /* + * Firmware writers cannot count to three. So to find + * the IAD on the NuForce UDH-100, also check the next + * interface. + */ + struct usb_interface *iface = + usb_ifnum_to_if(dev, ctrlif + 1); + if (iface && + iface->intf_assoc && + iface->intf_assoc->bFunctionClass == USB_CLASS_AUDIO && + iface->intf_assoc->bFunctionProtocol == UAC_VERSION_2) + assoc = iface->intf_assoc; + } + + if (!assoc) { snd_printk(KERN_ERR "Audio class v2 interfaces need an interface association\n"); return -EINVAL; }

2 1

Re: [alsa-devel] [PATCH] ALSA: asihpi - fix potential NULL pointer dereference
by Takashi Iwai 12 Mar '13

12 Mar '13

At Tue, 12 Mar 2013 00:16:40 +0800, Wei Yongjun wrote: > > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > The dereference should be moved below the NULL test. > > Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> Applied now. Thanks. Takashi > --- > sound/pci/asihpi/asihpi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/pci/asihpi/asihpi.c b/sound/pci/asihpi/asihpi.c > index 3536b07..0aabfed 100644 > --- a/sound/pci/asihpi/asihpi.c > +++ b/sound/pci/asihpi/asihpi.c > @@ -2549,7 +2549,7 @@ static int snd_asihpi_sampleclock_add(struct snd_card_asihpi *asihpi, > > static int snd_card_asihpi_mixer_new(struct snd_card_asihpi *asihpi) > { > - struct snd_card *card = asihpi->card; > + struct snd_card *card; > unsigned int idx = 0; > unsigned int subindex = 0; > int err; > @@ -2557,6 +2557,7 @@ static int snd_card_asihpi_mixer_new(struct snd_card_asihpi *asihpi) > > if (snd_BUG_ON(!asihpi)) > return -EINVAL; > + card = asihpi->card; > strcpy(card->mixername, "Asihpi Mixer"); > > err = > >

1 0

[alsa-devel] In 3.8 kernel alsa only talks HDMI, hardware also has S/PDIF optical
by Tom Horsley 12 Mar '13

12 Mar '13

See https://bugzilla.redhat.com/show_bug.cgi?id=919630 for details. Comment 4 in that bug is from someone who says it looks like the driver only created the HDMI and not the separate optical S/PDIF output. On my Asus P8H67-V there really are two physically separate audio outputs. I have the optical port connected to my receiver for when I want to pass through the 5.1 audio tracks in movie files and DVDs and the HDMI connected to the TV for more ordinary audio (error beeps from the computer, etc). In kernel 3.7.9 I could output to both devices (one at a time - never tried simultaneous). I've seen a bunch of patches in the archives that seem to be related to this, but if fedora 18 has those patches, they don't seem to be working.

3 4

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

11 Mar '13

On 03/11/2013 08:18 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 > > Add 2 more BCLKDIV mask macros as explained by Lars: > > The BCLKDIV has three fields. The bitclock divider (bit 0-1), the samplerate > (bit 2-4) and the source select (bit 5). Here we want to update the bitclock > divider field and the samplerate field. When I wrote the code I was lazy and > used ~ADAU1373_BCLKDIV_SOURCE as the mask, which for this register is > functionally equivalent to ADAU1373_BCLKDIV_SR_MASK | ADAU1373_BCLKDIV_BCLK_MASK. > > 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> Acked-by: Lars-Peter Clausen <lars(a)metafoo.de> Thanks. > --- > v1 - simple cast solution > v2 - Implement a full set of field masks as suggested by Lars. > > sound/soc/codecs/adau1373.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > 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

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

11 Mar '13

On 03/11/2013 04:37 PM, Tim Gardner wrote: > On 03/11/2013 04:01 AM, Lars-Peter Clausen wrote: >> 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: >> >> > > That seems way more complicated then need be. It also uses 2 bits in the > mask whereas the original code only used 1, e.g., bit 5. Is that correct ? The BCLKDIV has three fields. The bitclock divider (bit 0-1), the samplerate (bit 2-4) and the source select (bit 5). Here we want to update the bitclock divider field and the samplerate field. When I wrote the code I was lazy and used ~ADAU1373_BCLKDIV_SOURCE as the mask, which for this register is functional equivalent to ADAU1373_BCLKDIV_SR_MASK | ADAU1373_BCLKDIV_BCLK_MASK. > > How about just open coding the macro thusly: > > #define ADAU1373_BCLKDIV_SOURCE (1<<5) /*BIT(5)*/ But now there is a inconsistency where we sometimes use (1<<x) and sometimes BIT(x). I prefer my solution. - Lars

1 0

Re: [alsa-devel] [PATCH] omap: convert to devm_ioremap_resource()
by Jarkko Nikula 11 Mar '13

11 Mar '13

Hi On 03/11/2013 05:58 PM, Silviu-Mihai Popescu wrote: > Convert all uses of devm_request_and_ioremap() to the newly introduced > devm_ioremap_resource() which provides more consistent error handling. > > devm_ioremap_resource() provides its own error messages so all explicit > error messages can be removed from the failure code paths. > > Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990(a)gmail.com> > --- > sound/soc/omap/omap-dmic.c | 9 +++------ > sound/soc/omap/omap-mcpdm.c | 8 +++----- > 2 files changed, 6 insertions(+), 11 deletions(-) > Acked-by: Jarkko Nikula <jarkko.nikula(a)bitmer.com>

1 0

[alsa-devel] twl4030 and Puredata/jack
by Anders Alex 11 Mar '13

11 Mar '13

Ok, Let me start off that I know very little about audio and drivers. Recently I started looking in to running Puredata and possibly jack on the Pandora handheld. However I ran in to a number of problems getting these to interface with alsa. I should note that on the pandora we don't have too up to date versions of alsa and kernel so perhaps these are already resolved. In SL4P (slackware for pandora) I have: ALSA: 1.0.24 Kernel: 3.2.30 I will paste a couple of use-cases and their corresponding dmesg output: When I run ~$ pd -alsa I get: snd_pcm_hw_params (input): Invalid argument snd_pcm_hw_params (output): Invalid argument and: [201429.385345] omap_mcbsp_dai_hw_params: not enough bandwidth for desired rate and channels [201429.385375] asoc: interface omap-mcbsp-dai.1 hw params failed With 'jackd -d alsa -S' (need s16_le): loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|16bit control device hw:0 configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods ALSA: final selected sample format for capture: 16bit little-endian ALSA: use 2 periods for capture ALSA: cannot set hardware parameters for capture ALSA: cannot configure capture channel cannot load driver module alsa and: [201746.759857] asoc: can't set codec twl4030-hifi hw params The pandora kernel-dev explained that the hardware can only handle stereo streams. However someone in #jack explains it as the following: "This typically means that the ALSA driver is incomplete or buggy when used the way JACK does (poll+mmap) vs. the way aplay does (blocking read+write). So things that do stuff the "aplay way" will work; things that do stuff the JACK way will not work." I hope someone can shed some light on this and perhaps give some ideas to how to get this working. cheers, alexander

4 7

[alsa-devel] [PATCH v2] ALSA: ASoC: davinci-mcasp: clean up davinci_hw_common_param()
by Daniel Mack 11 Mar '13

11 Mar '13

As pointed of by Vaibhav, commit 2952b27e2 ("ASoC: davinci-mcasp: Add support for multichannel playback") duplicated the logic of counting the active serializers. That can be avoided by shifting the code around a bit. Also, drop two unused defines introduced by the same commit. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Michal Bachraty <michal.bachraty(a)streamunlimited.com> Cc: Vaibhav Bedia <vaibhav.bedia(a)ti.com> --- v2: fix typo in subject sound/soc/davinci/davinci-mcasp.c | 34 +++++++++++----------------------- 1 file changed, 11 insertions(+), 23 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index b386cad..8a9c0ee 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -237,8 +237,6 @@ #define RXSTATE BIT(5) #define SRMOD_MASK 3 #define SRMOD_INACTIVE 0 -#define SRMOD_TX 1 -#define SRMOD_RX 2 /* * DAVINCI_MCASP_LBCTL_REG - Loop Back Control Register Bits @@ -691,27 +689,6 @@ static int davinci_hw_common_param(struct davinci_audio_dev *dev, int stream, } for (i = 0; i < dev->num_serializer; i++) { - if (dev->serial_dir[i] == TX_MODE) - tx_ser++; - if (dev->serial_dir[i] == RX_MODE) - rx_ser++; - } - - if (stream == SNDRV_PCM_STREAM_PLAYBACK) - ser = tx_ser; - else - ser = rx_ser; - - if (ser < max_active_serializers) { - dev_warn(dev->dev, "stream has more channels (%d) than are " - "enabled in mcasp (%d)\n", channels, ser * slots); - return -EINVAL; - } - - tx_ser = 0; - rx_ser = 0; - - for (i = 0; i < dev->num_serializer; i++) { mcasp_set_bits(dev->base + DAVINCI_MCASP_XRSRCTL_REG(i), dev->serial_dir[i]); if (dev->serial_dir[i] == TX_MODE && @@ -730,6 +707,17 @@ static int davinci_hw_common_param(struct davinci_audio_dev *dev, int stream, } } + if (stream == SNDRV_PCM_STREAM_PLAYBACK) + ser = tx_ser; + else + ser = rx_ser; + + if (ser < max_active_serializers) { + dev_warn(dev->dev, "stream has more channels (%d) than are " + "enabled in mcasp (%d)\n", channels, ser * slots); + return -EINVAL; + } + if (dev->txnumevt && stream == SNDRV_PCM_STREAM_PLAYBACK) { if (dev->txnumevt * tx_ser > 64) dev->txnumevt = 1; -- 1.8.1.4

1 0

Re: [alsa-devel] [PATCH 06/10] ARM: soc-audio phycore-ac97: fix driver init order
by Mark Brown 11 Mar '13

11 Mar '13

On Sun, Mar 10, 2013 at 07:33:07PM +0100, Markus Pargmann wrote: > Adding a soc-audio sound driver internally uses snd_soc_register_device, > which tries to bind it with the codec. The adding of the driver is > deferred because the codec driver is not loaded. > This patch changes the order of registration. The codec driver is there > before the ac97 driver, so the snd_soc_register_device call is > successfull. You shouldn't be using soc-audio in the first place...

1 0

[alsa-devel] [PATCH 0/7] TCO fixes for RME MADI/Raydat/AIO/AES cards
by Adrian Knoth 11 Mar '13

11 Mar '13

Hi! I've spent another day at IOSONO to work with them on QA patches for the RME MADI series, especially the optional TCO module (LTC synchronisation with video cameras). Here are our results, all tested for an entire week in their lab. Cheers Adrian Knoth (7): ALSA: hdspm - Refactor sample rate acquisition ALSA: hdspm - Allow the TCO and SYNC-IN to be used in slave mode ALSA: hdspm - Provide ALSA control to disable 96K frames ALSA: hdspm - Remove duplicate code from ALSA controls ALSA: hdspm - Also check for TCO sync states ALSA: hdspm - Add ALSA controls to read the TCO LTC state ALSA: hdspm - Enable new TCO ALSA controls sound/pci/rme9652/hdspm.c | 379 ++++++++++++++++++++++++++++----------------- 1 file changed, 237 insertions(+), 142 deletions(-) -- 1.7.10.4

2 10

[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

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

10 Mar '13

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? Regards, Clemens

1 0

Re: [alsa-devel] plans for fireworks driver
by Doug McLain 10 Mar '13

10 Mar '13

After realizing that the ffado-mixer also didn't work on my AF12, I found that echo firmware > 4.8 broke ffado for the AF12 & AF8: http://subversion.ffado.org/ticket/360 Interestingly though, I have been running 5.7 for a couple years using the snd-fireworks driver with no problems. I have no use for the mixer on the AF12 after I initially set it up way before the firmware problem came about, so I never noticed anything was wrong. Your driver now discovers the AF12 fine: $ cat /proc/asound/card1/efc_hardware flags: 0x11 guid_hi: 0x14860F guid_lo: 0xC44A84A6 type: 0xAF12 version: 0x0 vendor_name: Echo Digital Audio model_name: AudioFire12 supported_clock: 0x5 nb_1394_playback_channels: 0xC nb_1394_capture_channels: 0xC nb_phys_audio_out: 0xC nb_phys_audio_in: 0xC nb_out_groups: 0x1 out_group[0x0]: type 0x0, count 0x12 out_group[0x1]: type 0x0, count 0x0 out_group[0x2]: type 0x0, count 0x0 out_group[0x3]: type 0x0, count 0x0 out_group[0x4]: type 0x0, count 0x0 out_group[0x5]: type 0x0, count 0x0 out_group[0x6]: type 0x0, count 0x0 out_group[0x7]: type 0x0, count 0x0 nb_in_groups: 0x1 out_group[0x0]: type 0x0, count 0x12 out_group[0x1]: type 0x0, count 0x0 out_group[0x2]: type 0x0, count 0x0 out_group[0x3]: type 0x0, count 0x0 out_group[0x4]: type 0x0, count 0x0 out_group[0x5]: type 0x0, count 0x0 out_group[0x6]: type 0x0, count 0x0 out_group[0x7]: type 0x0, count 0x0 nb_midi_out: 0x1 nb_midi_in: 0x1 max_sample_rate: 0x2EE00 min_sample_rate: 0x7D00 dsp_version: 0x4080000 arm_version: 0x4080000 mixer_playback_channels: 0xC mixer_capture_channels: 0xC fpga_version: 0x0 nb_1394_playback_channels_2x: 0xC nb_1394_capture_channels_2x: 0xC nb_1394_playback_channels_4x: 0xC nb_1394_capture_channels_4x: 0xC Interestingly though, I've been running On 03/09/2013 09:11 PM, Takashi Sakamoto wrote: > Hi Doug, > > Thanks for your checking my source. > > >> The latest change, which prompted me to write this email in the >> first place, was the removal of __devinit and friends from kernel 3.8. > > Oh, it's my fault... __devXXX macros are removed from Linux tree since > Dec 2012. > For Linux 3.8-rc4 or later my module needs your patch but i's inconvenient. > I realized it but have been forgeting... > > I remove them with this commit. Now you can build my module without your > patch. > https://github.com/takaswie/snd-firewire-improve/commit/77742d3f68e98e94ff9… > > > > > ...and the AF2 > > Thank you. I add your log in the end of README. > https://github.com/takaswie/snd-firewire-improve/commit/52beb73fa1e248a8eec… > > > >> It discovers the AF2, but not the AF12. Here is the log from the AF12: > > Mar 9 15:47:11 iggy kernel: [63134.769274] ALSA fireworks_command.c:313 > > EFC Failed [0/1]: 0 > > H'm... It looks to fail to get the number of hardware metering channels > when proving my module. > To investigating this, anyway, I need the hardware information of AF12... > > Would you try this patch for AF12? This patch disable to get hardware > metering channels during module proving process. > > --- a/fireworks/fireworks.c > +++ b/fireworks/fireworks.c > @@ -329,11 +329,6 @@ static int snd_efw_probe(struct device *dev) > if (err < 0) > goto error_card; > > - /* get the number of hardware meters */ > - err = snd_efw_get_hardware_meters_count(efw); > - if (err < 0) > - goto error_card; > - > efw->syt_interval = 8; > > for (i = 0; i < MAX_MIDI_OUTPUTS; i += 1) > > > Thanks > > > Takashi Sakamoto > o-takashi(a)sakamocchi.jp > > (Mar 10 2013 05:52), Doug McLain wrote: >> Attached is a patch of my hack to build your source of Fedora 18 with >> kernel 3.8. As I mentioned in the last email, I have had to do various >> little hacks to the other snd-fireworks module source over the past few >> years as chnages were made to the kernel API. The latest change, which >> prompted me to write this email in the first place, was the removal of >> __devinit and friends from kernel 3.8. So now its built, installed, and >> running. It discovers the AF2, but not the AF12. Here is the log from >> the AF12: >> >> Mar 9 15:47:06 iggy kernel: [63129.761604] firewire_core 0000:01:0b.0: >> phy config: new root=ffc2, gap_count=7 >> Mar 9 15:47:11 iggy kernel: [63134.769274] ALSA fireworks_command.c:313 >> EFC Failed [0/1]: 0 >> Mar 9 15:47:11 iggy kernel: [63134.769289] snd-fireworks: probe of >> fw2.0 failed with error -5 >> Mar 9 15:47:11 iggy kernel: [63134.769293] firewire_core 0000:01:0b.0: >> created device fw2: GUID 0014860fc44a84a6, S400 >> >> >> ...and the AF2 >> $ cat /proc/asound/card0/efc_hardware >> flags: 0xA1 >> guid_hi: 0x148606 >> guid_lo: 0x9D5BD6CA >> type: 0xAF2 >> version: 0x0 >> vendor_name: Echo Digital Audio >> model_name: AudioFire2 >> supported_clock: 0x9 >> nb_1394_playback_channels: 0x6 >> nb_1394_capture_channels: 0x4 >> nb_phys_audio_out: 0x6 >> nb_phys_audio_in: 0x4 >> nb_out_groups: 0x3 >> out_group[0x0]: type 0x0, count 0x2 >> out_group[0x1]: type 0x5, count 0x2 >> out_group[0x2]: type 0x1, count 0x2 >> out_group[0x3]: type 0x0, count 0x0 >> out_group[0x4]: type 0x0, count 0x0 >> out_group[0x5]: type 0x0, count 0x0 >> out_group[0x6]: type 0x0, count 0x0 >> out_group[0x7]: type 0x0, count 0x0 >> nb_in_groups: 0x2 >> out_group[0x0]: type 0x0, count 0x2 >> out_group[0x1]: type 0x5, count 0x2 >> out_group[0x2]: type 0x1, count 0x2 >> out_group[0x3]: type 0x0, count 0x0 >> out_group[0x4]: type 0x0, count 0x0 >> out_group[0x5]: type 0x0, count 0x0 >> out_group[0x6]: type 0x0, count 0x0 >> out_group[0x7]: type 0x0, count 0x0 >> nb_midi_out: 0x1 >> nb_midi_in: 0x1 >> max_sample_rate: 0x17700 >> min_sample_rate: 0x7D00 >> dsp_version: 0x0 >> arm_version: 0x4080000 >> mixer_playback_channels: 0x6 >> mixer_capture_channels: 0x4 >> fpga_version: 0x3000200 >> nb_1394_playback_channels_2x: 0x6 >> nb_1394_capture_channels_2x: 0x4 >> nb_1394_playback_channels_4x: 0x6 >> nb_1394_capture_channels_4x: 0x4 >> >> -D >> >> On 03/09/2013 07:30 AM, Takashi Sakamoto wrote: >>> Dear Doug, >>> >>> I'm a newcomer of ALSA project and currently working for snd-fireworks. >>> Then I have a favour of you. >>> (My first name is the same one that ALSA core developer has. But I'm >>> newcomer Takashi) >>> >>> Unfortunatelly my post isn't delivered by mailman of >>> alsa-devel(a)alsa-project.org. But I'm not a professional for mailman or >>> SMTP so it takes a bit time that I debut in alsa-devel... >>> >>> Well, my source is here. >>> https://github.com/takaswie/snd-firewire-improve >>> >>> It's a bit worse to you because current source has a lack of some >>> functions that Clemens' snd-fireworks has. >>> >>> - playback is available, capture is not. Additionally 2ch are >>> available (under investigating...) >>> - MIDI is not available >>> >>> The reason is snd-firewire-lib.ko has these functions. Currently I'm >>> working for them. >>> >>> But the implementation of hardware control is almost done: >>> - Hardware metering/monitoring/mixing are visible via procfs, but not >>> configurable >>> - sampling rate, digital mode, digital format and clock source are >>> changeable via alsamixer >>> >>> Hardware metering/monitoring/mixing will also be available via alsamixer >>> after I've investigated the suitable way in ALSA's control component >>> API. >>> >>> My favor of you is "building and installing my module and give me >>> hardware information of your AF2 and AF12". I'm working with Ubuntu and >>> utilize DKMS for debugging my module. You can see an instruction in >>> README. >>> >>> If your Fireworks is identified by your system, there is >>> /proc/asound/cardX/efc_hardware. If you "cat" this file, my module >>> submit a command to your device to get hardware information and print >>> the value. My module decide available functions refering it so it's very >>> important. >>> >>> This is the output of my device, for your information: >>> $ cat /proc/asound/card2/efc_hardware >>> flags: 0x625 >>> guid_hi: 0x14860A >>> guid_lo: 0x5B6BDB9B >>> type: 0xAF9 >>> version: 0x0 >>> vendor_name: Echo Digital Audio >>> model_name: AudioFirePre8 >>> supported_clock: 0x1D >>> nb_1394_playback_channels: 0x10 >>> nb_1394_capture_channels: 0x10 >>> nb_phys_audio_out: 0x10 >>> nb_phys_audio_in: 0x10 >>> nb_out_groups: 0x2 >>> out_group[0x0]: type 0x0, count 0x8 >>> out_group[0x1]: type 0x3, count 0x8 >>> out_group[0x2]: type 0x0, count 0x0 >>> out_group[0x3]: type 0x0, count 0x0 >>> out_group[0x4]: type 0x0, count 0x0 >>> out_group[0x5]: type 0x0, count 0x0 >>> out_group[0x6]: type 0x0, count 0x0 >>> out_group[0x7]: type 0x0, count 0x0 >>> nb_in_groups: 0x2 >>> out_group[0x0]: type 0x0, count 0x8 >>> out_group[0x1]: type 0x3, count 0x8 >>> out_group[0x2]: type 0x0, count 0x0 >>> out_group[0x3]: type 0x0, count 0x0 >>> out_group[0x4]: type 0x0, count 0x0 >>> out_group[0x5]: type 0x0, count 0x0 >>> out_group[0x6]: type 0x0, count 0x0 >>> out_group[0x7]: type 0x0, count 0x0 >>> nb_midi_out: 0x1 >>> nb_midi_in: 0x1 >>> max_sample_rate: 0x17700 >>> min_sample_rate: 0x7D00 >>> dsp_version: 0x0 >>> arm_version: 0x5050000 >>> mixer_playback_channels: 0x10 >>> mixer_capture_channels: 0x10 >>> fpga_version: 0x4010100 >>> nb_1394_playback_channels_2x: 0xC >>> nb_1394_capture_channels_2x: 0xC >>> nb_1394_playback_channels_4x: 0xA >>> nb_1394_capture_channels_4x: 0xA >>> >>> Kind Regards >>> >>> >>> Takashi Sakamoto >>> o-takashi(a)sakamocchi.jp >>> >>> (2013年03月09日 06:49), Doug McLain wrote: >>>> I have been building and using the fireworks driver from >>>> alsa-kprivate/fireworks for a few years now with my AF2 and AF12. The >>>> driver works great for me, although every so often after a kernel >>>> update, compilation breaks and I have to hack at it a little bit to get >>>> it to build again. >>>> >>>> Are there any plans to include this driver into the kernel? >>> >

2 3

Re: [alsa-devel] plans for fireworks driver
by Doug McLain 09 Mar '13

09 Mar '13

Attached is a patch of my hack to build your source of Fedora 18 with kernel 3.8. As I mentioned in the last email, I have had to do various little hacks to the other snd-fireworks module source over the past few years as chnages were made to the kernel API. The latest change, which prompted me to write this email in the first place, was the removal of __devinit and friends from kernel 3.8. So now its built, installed, and running. It discovers the AF2, but not the AF12. Here is the log from the AF12: Mar 9 15:47:06 iggy kernel: [63129.761604] firewire_core 0000:01:0b.0: phy config: new root=ffc2, gap_count=7 Mar 9 15:47:11 iggy kernel: [63134.769274] ALSA fireworks_command.c:313 EFC Failed [0/1]: 0 Mar 9 15:47:11 iggy kernel: [63134.769289] snd-fireworks: probe of fw2.0 failed with error -5 Mar 9 15:47:11 iggy kernel: [63134.769293] firewire_core 0000:01:0b.0: created device fw2: GUID 0014860fc44a84a6, S400 ...and the AF2 $ cat /proc/asound/card0/efc_hardware flags: 0xA1 guid_hi: 0x148606 guid_lo: 0x9D5BD6CA type: 0xAF2 version: 0x0 vendor_name: Echo Digital Audio model_name: AudioFire2 supported_clock: 0x9 nb_1394_playback_channels: 0x6 nb_1394_capture_channels: 0x4 nb_phys_audio_out: 0x6 nb_phys_audio_in: 0x4 nb_out_groups: 0x3 out_group[0x0]: type 0x0, count 0x2 out_group[0x1]: type 0x5, count 0x2 out_group[0x2]: type 0x1, count 0x2 out_group[0x3]: type 0x0, count 0x0 out_group[0x4]: type 0x0, count 0x0 out_group[0x5]: type 0x0, count 0x0 out_group[0x6]: type 0x0, count 0x0 out_group[0x7]: type 0x0, count 0x0 nb_in_groups: 0x2 out_group[0x0]: type 0x0, count 0x2 out_group[0x1]: type 0x5, count 0x2 out_group[0x2]: type 0x1, count 0x2 out_group[0x3]: type 0x0, count 0x0 out_group[0x4]: type 0x0, count 0x0 out_group[0x5]: type 0x0, count 0x0 out_group[0x6]: type 0x0, count 0x0 out_group[0x7]: type 0x0, count 0x0 nb_midi_out: 0x1 nb_midi_in: 0x1 max_sample_rate: 0x17700 min_sample_rate: 0x7D00 dsp_version: 0x0 arm_version: 0x4080000 mixer_playback_channels: 0x6 mixer_capture_channels: 0x4 fpga_version: 0x3000200 nb_1394_playback_channels_2x: 0x6 nb_1394_capture_channels_2x: 0x4 nb_1394_playback_channels_4x: 0x6 nb_1394_capture_channels_4x: 0x4 -D On 03/09/2013 07:30 AM, Takashi Sakamoto wrote: > Dear Doug, > > I'm a newcomer of ALSA project and currently working for snd-fireworks. > Then I have a favour of you. > (My first name is the same one that ALSA core developer has. But I'm > newcomer Takashi) > > Unfortunatelly my post isn't delivered by mailman of > alsa-devel(a)alsa-project.org. But I'm not a professional for mailman or > SMTP so it takes a bit time that I debut in alsa-devel... > > Well, my source is here. > https://github.com/takaswie/snd-firewire-improve > > It's a bit worse to you because current source has a lack of some > functions that Clemens' snd-fireworks has. > > - playback is available, capture is not. Additionally 2ch are > available (under investigating...) > - MIDI is not available > > The reason is snd-firewire-lib.ko has these functions. Currently I'm > working for them. > > But the implementation of hardware control is almost done: > - Hardware metering/monitoring/mixing are visible via procfs, but not > configurable > - sampling rate, digital mode, digital format and clock source are > changeable via alsamixer > > Hardware metering/monitoring/mixing will also be available via alsamixer > after I've investigated the suitable way in ALSA's control component API. > > My favor of you is "building and installing my module and give me > hardware information of your AF2 and AF12". I'm working with Ubuntu and > utilize DKMS for debugging my module. You can see an instruction in README. > > If your Fireworks is identified by your system, there is > /proc/asound/cardX/efc_hardware. If you "cat" this file, my module > submit a command to your device to get hardware information and print > the value. My module decide available functions refering it so it's very > important. > > This is the output of my device, for your information: > $ cat /proc/asound/card2/efc_hardware > flags: 0x625 > guid_hi: 0x14860A > guid_lo: 0x5B6BDB9B > type: 0xAF9 > version: 0x0 > vendor_name: Echo Digital Audio > model_name: AudioFirePre8 > supported_clock: 0x1D > nb_1394_playback_channels: 0x10 > nb_1394_capture_channels: 0x10 > nb_phys_audio_out: 0x10 > nb_phys_audio_in: 0x10 > nb_out_groups: 0x2 > out_group[0x0]: type 0x0, count 0x8 > out_group[0x1]: type 0x3, count 0x8 > out_group[0x2]: type 0x0, count 0x0 > out_group[0x3]: type 0x0, count 0x0 > out_group[0x4]: type 0x0, count 0x0 > out_group[0x5]: type 0x0, count 0x0 > out_group[0x6]: type 0x0, count 0x0 > out_group[0x7]: type 0x0, count 0x0 > nb_in_groups: 0x2 > out_group[0x0]: type 0x0, count 0x8 > out_group[0x1]: type 0x3, count 0x8 > out_group[0x2]: type 0x0, count 0x0 > out_group[0x3]: type 0x0, count 0x0 > out_group[0x4]: type 0x0, count 0x0 > out_group[0x5]: type 0x0, count 0x0 > out_group[0x6]: type 0x0, count 0x0 > out_group[0x7]: type 0x0, count 0x0 > nb_midi_out: 0x1 > nb_midi_in: 0x1 > max_sample_rate: 0x17700 > min_sample_rate: 0x7D00 > dsp_version: 0x0 > arm_version: 0x5050000 > mixer_playback_channels: 0x10 > mixer_capture_channels: 0x10 > fpga_version: 0x4010100 > nb_1394_playback_channels_2x: 0xC > nb_1394_capture_channels_2x: 0xC > nb_1394_playback_channels_4x: 0xA > nb_1394_capture_channels_4x: 0xA > > Kind Regards > > > Takashi Sakamoto > o-takashi(a)sakamocchi.jp > > (2013年03月09日 06:49), Doug McLain wrote: >> I have been building and using the fireworks driver from >> alsa-kprivate/fireworks for a few years now with my AF2 and AF12. The >> driver works great for me, although every so often after a kernel >> update, compilation breaks and I have to hack at it a little bit to get >> it to build again. >> >> Are there any plans to include this driver into the kernel? >

1 0

[alsa-devel] plans for fireworks driver
by Doug McLain 08 Mar '13

08 Mar '13

I have been building and using the fireworks driver from alsa-kprivate/fireworks for a few years now with my AF2 and AF12. The driver works great for me, although every so often after a kernel update, compilation breaks and I have to hack at it a little bit to get it to build again. Are there any plans to include this driver into the kernel?

1 0

[alsa-devel] [PATCH 0/5] ASoC: OMAP2+: Update Audio IP with sDMA binding for DT boot
by Sebastien Guiriec 08 Mar '13

08 Mar '13

This patch serie is converting OMAP Audio IPs in order to use OMAP sDMA DT binding in case of DT boot on OMAP2+ platforms. It is depending on the next patches: [1] http://www.spinics.net/lists/arm-kernel/msg227836.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg84668.html It has been tested on: - OMAP5 (sEVM/panda)in DT boot (McPDM/DMIC). - OMAP4 (SDP4430/Panda) in both DT/non DT boot (McPDM/DMIC) - OMAP3 (Beagle XM) in both DT/non DT boot (McBSP) Sebastien Guiriec (5): ASoC: omap-pcm: Move to generic DMA for DT binding ASoC: omap-dmic: Update driver for DMA DT binding. ASoC: omap-mcpdm: Update driver for DMA DT binding. ASoC: omap-mcbsp:Update driver for DMA DT binding. ARM: dts: OMAP2+: Add SDMA Audio IPs bindings arch/arm/boot/dts/omap2420.dtsi | 6 ++++++ arch/arm/boot/dts/omap2430.dtsi | 15 +++++++++++++++ arch/arm/boot/dts/omap3.dtsi | 15 +++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 17 +++++++++++++++++ arch/arm/boot/dts/omap5.dtsi | 14 ++++++++++++++ sound/soc/omap/mcbsp.c | 26 ++++++++++++++++---------- sound/soc/omap/omap-dmic.c | 15 +++++++++------ sound/soc/omap/omap-mcpdm.c | 22 ++++++++++++++-------- sound/soc/omap/omap-pcm.c | 12 ++++++++++-- sound/soc/omap/omap-pcm.h | 1 + 10 files changed, 117 insertions(+), 26 deletions(-) -- 1.7.10.4

4 9

[alsa-devel] [PATCH v2] ALSA: ASoC: add codec driver for TI TAS5086
by Daniel Mack 08 Mar '13

08 Mar '13

This patch adds a driver for TI's TA5086 6-channel PWM processor. This chip has a very unusual register layout, specifically because the registers are of unequal size, and multi-byte registers require bulk writes to take effect. Regmap does not support these kind of mappings. Currently, the driver does not touch any of the registers >= 0x20, so it doesn't matter, because the register map is mapped to an 8-bit array. In case more features will be added in the future that require access to higher registers, the entire regmap H/W I/O routines have to be open-coded. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- v2: * define clock indices in a header * switched to switch-case in some places * dropped empty suspend function * moved device id checks and gpio allocations to i2c level * switched to mute_stream() .../devicetree/bindings/sound/ti,tas5086.txt | 32 ++ include/sound/tas5086.h | 7 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tas5086.c | 601 +++++++++++++++++++++ 5 files changed, 646 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ti,tas5086.txt create mode 100644 include/sound/tas5086.h create mode 100644 sound/soc/codecs/tas5086.c diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt new file mode 100644 index 0000000..8ea4f5b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt @@ -0,0 +1,32 @@ +Texas Instruments TAS5086 6-channel PWM Processor + +Required properties: + + - compatible: Should contain "ti,tas5086". + - reg: The i2c address. Should contain <0x1b>. + +Optional properties: + + - reset-gpio: A GPIO spec to define which pin is connected to the + chip's !RESET pin. If specified, the driver will + assert a hardware reset at probe time. + + - ti,charge-period: This property should contain the time in microseconds + that closely matches the external single-ended + split-capacitor charge period. The hardware chip + waits for this period of time before starting the + PWM signals. This helps reduce pops and clicks. + + When not specified, the hardware default of 1300ms + is retained. + +Examples: + + i2c_bus { + tas5086@1b { + compatible = "ti,tas5086"; + reg = <0x1b>; + reset-gpio = <&gpio 23 0>; + ti,charge-period = <156000>; + }; + }; diff --git a/include/sound/tas5086.h b/include/sound/tas5086.h new file mode 100644 index 0000000..aac481b --- /dev/null +++ b/include/sound/tas5086.h @@ -0,0 +1,7 @@ +#ifndef _SND_SOC_CODEC_TAS5086_H_ +#define _SND_SOC_CODEC_TAS5086_H_ + +#define TAS5086_CLK_IDX_MCLK 0 +#define TAS5086_CLK_IDX_SCLK 1 + +#endif /* _SND_SOC_CODEC_TAS5086_H_ */ diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 500f666..18fea10 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -64,6 +64,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_STA32X if I2C select SND_SOC_STA529 if I2C select SND_SOC_STAC9766 if SND_SOC_AC97_BUS + select SND_SOC_TAS5086 if I2C select SND_SOC_TLV320AIC23 if I2C select SND_SOC_TLV320AIC26 if SPI_MASTER select SND_SOC_TLV320AIC32X4 if I2C @@ -324,6 +325,9 @@ config SND_SOC_STA529 config SND_SOC_STAC9766 tristate +config SND_SOC_TAS5086 + tristate + config SND_SOC_TLV320AIC23 tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index 3a7ec1c..b9e41c9 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -56,6 +56,7 @@ snd-soc-ssm2602-objs := ssm2602.o snd-soc-sta32x-objs := sta32x.o snd-soc-sta529-objs := sta529.o snd-soc-stac9766-objs := stac9766.o +snd-soc-tas5086-objs := tas5086.o snd-soc-tlv320aic23-objs := tlv320aic23.o snd-soc-tlv320aic26-objs := tlv320aic26.o snd-soc-tlv320aic3x-objs := tlv320aic3x.o @@ -179,6 +180,7 @@ obj-$(CONFIG_SND_SOC_SSM2602) += snd-soc-ssm2602.o obj-$(CONFIG_SND_SOC_STA32X) += snd-soc-sta32x.o obj-$(CONFIG_SND_SOC_STA529) += snd-soc-sta529.o obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o +obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c new file mode 100644 index 0000000..008bea4 --- /dev/null +++ b/sound/soc/codecs/tas5086.c @@ -0,0 +1,601 @@ +/* + * TAS5086 ASoC codec driver + * + * Copyright (c) 2013 Daniel Mack <zonque(a)gmail.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * TODO: + * - implement DAPM and input muxing + * - implement modulation limit + * - implement non-default PWM start + * + * Note that this chip has a very unusual register layout, specifically + * because the registers are of unequal size, and multi-byte registers + * require bulk writes to take effect. Regmap does not support that kind + * of devices. + * + * Currently, the driver does not touch any of the registers >= 0x20, so + * it doesn't matter because the entire map can be accessed as 8-bit + * array. In case more features will be added in the future + * that require access to higher registers, the entire regmap H/W I/O + * routines have to be open-coded. + */ + +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/delay.h> +#include <linux/gpio.h> +#include <linux/i2c.h> +#include <linux/regmap.h> +#include <linux/spi/spi.h> +#include <linux/of_device.h> +#include <linux/of_gpio.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/tlv.h> +#include <sound/tas5086.h> + +#define TAS5086_PCM_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S20_3LE | \ + SNDRV_PCM_FMTBIT_S24_3LE) + +#define TAS5086_PCM_RATES (SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \ + SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | \ + SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_176400 | \ + SNDRV_PCM_RATE_192000) + +/* + * TAS5086 registers + */ +#define TAS5086_CLOCK_CONTROL 0x00 /* Clock control register */ +#define TAS5086_CLOCK_RATE(val) (val << 5) +#define TAS5086_CLOCK_RATE_MASK (0x7 << 5) +#define TAS5086_CLOCK_RATIO(val) (val << 2) +#define TAS5086_CLOCK_RATIO_MASK (0x7 << 2) +#define TAS5086_CLOCK_SCLK_RATIO_48 (1 << 1) +#define TAS5086_CLOCK_VALID (1 << 0) + +#define TAS5086_DEEMPH_MASK 0x03 +#define TAS5086_SOFT_MUTE_ALL 0x3f + +#define TAS5086_DEV_ID 0x01 /* Device ID register */ +#define TAS5086_ERROR_STATUS 0x02 /* Error status register */ +#define TAS5086_SYS_CONTROL_1 0x03 /* System control register 1 */ +#define TAS5086_SERIAL_DATA_IF 0x04 /* Serial data interface register */ +#define TAS5086_SYS_CONTROL_2 0x05 /* System control register 2 */ +#define TAS5086_SOFT_MUTE 0x06 /* Soft mute register */ +#define TAS5086_MASTER_VOL 0x07 /* Master volume */ +#define TAS5086_CHANNEL_VOL(X) (0x08 + (X)) /* Channel 1-6 volume */ +#define TAS5086_VOLUME_CONTROL 0x09 /* Volume control register */ +#define TAS5086_MOD_LIMIT 0x10 /* Modulation limit register */ +#define TAS5086_PWM_START 0x18 /* PWM start register */ +#define TAS5086_SURROUND 0x19 /* Surround register */ +#define TAS5086_SPLIT_CAP_CHARGE 0x1a /* Split cap charge period register */ +#define TAS5086_OSC_TRIM 0x1b /* Oscillator trim register */ +#define TAS5086_BKNDERR 0x1c + +/* + * Default TAS5086 power-up configuration + */ +static const struct reg_default tas5086_reg_defaults[] = { + { 0x00, 0x6c }, + { 0x01, 0x03 }, + { 0x02, 0x00 }, + { 0x03, 0xa0 }, + { 0x04, 0x05 }, + { 0x05, 0x60 }, + { 0x06, 0x00 }, + { 0x07, 0xff }, + { 0x08, 0x30 }, + { 0x09, 0x30 }, + { 0x0a, 0x30 }, + { 0x0b, 0x30 }, + { 0x0c, 0x30 }, + { 0x0d, 0x30 }, + { 0x0e, 0xb1 }, + { 0x0f, 0x00 }, + { 0x10, 0x02 }, + { 0x11, 0x00 }, + { 0x12, 0x00 }, + { 0x13, 0x00 }, + { 0x14, 0x00 }, + { 0x15, 0x00 }, + { 0x16, 0x00 }, + { 0x17, 0x00 }, + { 0x18, 0x3f }, + { 0x19, 0x00 }, + { 0x1a, 0x18 }, + { 0x1b, 0x82 }, + { 0x1c, 0x05 }, +}; + +static bool tas5086_accessible_reg(struct device *dev, unsigned int reg) +{ + return !((reg == 0x0f) || (reg >= 0x11 && reg <= 0x17)); +} + +static bool tas5086_volatile_reg(struct device *dev, unsigned int reg) +{ + switch (reg) { + case TAS5086_DEV_ID: + case TAS5086_ERROR_STATUS: + return true; + } + + return false; +} + +static bool tas5086_writeable_reg(struct device *dev, unsigned int reg) +{ + return tas5086_accessible_reg(dev, reg) && (reg != TAS5086_DEV_ID); +} + +struct tas5086_private { + struct regmap *regmap; + unsigned int mclk, sclk; + unsigned int format; + bool deemph; + /* Current sample rate for de-emphasis control */ + int rate; + /* GPIO driving Reset pin, if any */ + int gpio_nreset; +}; + +static int tas5086_deemph[] = { 0, 32000, 44100, 48000 }; + +static int tas5086_set_deemph(struct snd_soc_codec *codec) +{ + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + int i, val = 0; + + if (priv->deemph) + for (i = 0; i < ARRAY_SIZE(tas5086_deemph); i++) + if (tas5086_deemph[i] == priv->rate) + val = i; + + return regmap_update_bits(priv->regmap, TAS5086_SYS_CONTROL_1, + TAS5086_DEEMPH_MASK, val); +} + +static int tas5086_get_deemph(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + + ucontrol->value.enumerated.item[0] = priv->deemph; + + return 0; +} + +static int tas5086_put_deemph(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + + priv->deemph = ucontrol->value.enumerated.item[0]; + + return tas5086_set_deemph(codec); +} + + +static int tas5086_set_dai_sysclk(struct snd_soc_dai *codec_dai, + int clk_id, unsigned int freq, int dir) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + + switch (clk_id) { + case TAS5086_CLK_IDX_MCLK: + priv->mclk = freq; + break; + case TAS5086_CLK_IDX_SCLK: + priv->sclk = freq; + break; + } + + return 0; +} + +static int tas5086_set_dai_fmt(struct snd_soc_dai *codec_dai, + unsigned int format) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + + /* The TAS5086 can only be slave to all clocks */ + if ((format & SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBS_CFS) { + dev_err(codec->dev, "Invalid clocking mode\n"); + return -EINVAL; + } + + /* we need to refer to the data format from hw_params() */ + priv->format = format; + + return 0; +} + +static const int tas5086_sample_rates[] = { + 32000, 38000, 44100, 48000, 88200, 96000, 176400, 192000 +}; + +static const int tas5086_ratios[] = { + 64, 128, 192, 256, 384, 512 +}; + +static int index_in_array(const int *array, int len, int needle) +{ + int i; + + for (i = 0; i < len; i++) + if (array[i] == needle) + return i; + + return -ENOENT; +} + +static int tas5086_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params, + struct snd_soc_dai *dai) +{ + struct snd_soc_codec *codec = dai->codec; + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + unsigned int val; + int ret; + + priv->rate = params_rate(params); + + /* Look up the sample rate and refer to the offset in the list */ + val = index_in_array(tas5086_sample_rates, + ARRAY_SIZE(tas5086_sample_rates), priv->rate); + + if (val < 0) { + dev_err(codec->dev, "Invalid sample rate\n"); + return -EINVAL; + } + + ret = regmap_update_bits(priv->regmap, TAS5086_CLOCK_CONTROL, + TAS5086_CLOCK_RATE_MASK, + TAS5086_CLOCK_RATE(val)); + if (ret < 0) + return ret; + + /* MCLK / Fs ratio */ + val = index_in_array(tas5086_ratios, ARRAY_SIZE(tas5086_ratios), + priv->mclk / priv->rate); + if (val < 0) { + dev_err(codec->dev, "Inavlid MCLK / Fs ratio\n"); + return -EINVAL; + } + + ret = regmap_update_bits(priv->regmap, TAS5086_CLOCK_CONTROL, + TAS5086_CLOCK_RATIO_MASK, + TAS5086_CLOCK_RATIO(val)); + if (ret < 0) + return ret; + + + ret = regmap_update_bits(priv->regmap, TAS5086_CLOCK_CONTROL, + TAS5086_CLOCK_SCLK_RATIO_48, + (priv->sclk == 48 * priv->rate) ? + TAS5086_CLOCK_SCLK_RATIO_48 : 0); + if (ret < 0) + return ret; + + /* + * The chip has a very unituitive register mapping and muxes information + * about data format and sample depth into the same register, but not on + * a logical bit-boundary. Hence, we have to refer to the format passed + * in the set_dai_fmt() callback and set up everything from here. + * + * First, determine the 'base' value, using the format ... + */ + switch (priv->format & SND_SOC_DAIFMT_FORMAT_MASK) { + case SND_SOC_DAIFMT_RIGHT_J: + val = 0x00; + break; + case SND_SOC_DAIFMT_I2S: + val = 0x03; + break; + case SND_SOC_DAIFMT_LEFT_J: + val = 0x06; + break; + default: + dev_err(codec->dev, "Invalid DAI format\n"); + return -EINVAL; + } + + /* ... then add the offset for the sample bit depth. */ + switch (params_format(params)) { + case SNDRV_PCM_FORMAT_S16_LE: + val += 0; + break; + case SNDRV_PCM_FORMAT_S20_3LE: + val += 1; + break; + case SNDRV_PCM_FORMAT_S24_3LE: + val += 2; + break; + default: + dev_err(codec->dev, "Invalid bit width\n"); + return -EINVAL; + }; + + ret = regmap_write(priv->regmap, TAS5086_SERIAL_DATA_IF, val); + if (ret < 0) + return ret; + + /* clock is considered valid now */ + ret = regmap_update_bits(priv->regmap, TAS5086_CLOCK_CONTROL, + TAS5086_CLOCK_VALID, TAS5086_CLOCK_VALID); + if (ret < 0) + return ret; + + return tas5086_set_deemph(codec); +} + +static int tas5086_mute_stream(struct snd_soc_dai *dai, int mute, int stream) +{ + struct snd_soc_codec *codec = dai->codec; + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + unsigned int val = 0; + + if (mute) + val = TAS5086_SOFT_MUTE_ALL; + + return regmap_write(priv->regmap, TAS5086_SOFT_MUTE, val); +} + +/* TAS5086 controls */ +static const DECLARE_TLV_DB_SCALE(tas5086_dac_tlv, -10350, 50, 1); + +static const struct snd_kcontrol_new tas5086_controls[] = { + SOC_SINGLE_TLV("Master Playback Volume", TAS5086_MASTER_VOL, + 0, 0xff, 1, tas5086_dac_tlv), + SOC_DOUBLE_R_TLV("Channel 1/2 Playback Volume", + TAS5086_CHANNEL_VOL(0), TAS5086_CHANNEL_VOL(1), + 0, 0xff, 1, tas5086_dac_tlv), + SOC_DOUBLE_R_TLV("Channel 3/4 Playback Volume", + TAS5086_CHANNEL_VOL(2), TAS5086_CHANNEL_VOL(3), + 0, 0xff, 1, tas5086_dac_tlv), + SOC_DOUBLE_R_TLV("Channel 5/6 Playback Volume", + TAS5086_CHANNEL_VOL(4), TAS5086_CHANNEL_VOL(5), + 0, 0xff, 1, tas5086_dac_tlv), + SOC_SINGLE_BOOL_EXT("De-emphasis Switch", 0, + tas5086_get_deemph, tas5086_put_deemph), +}; + +static const struct snd_soc_dai_ops tas5086_dai_ops = { + .hw_params = tas5086_hw_params, + .set_sysclk = tas5086_set_dai_sysclk, + .set_fmt = tas5086_set_dai_fmt, + .mute_stream = tas5086_mute_stream, +}; + +static struct snd_soc_dai_driver tas5086_dai = { + .name = "tas5086-hifi", + .playback = { + .stream_name = "Playback", + .channels_min = 2, + .channels_max = 6, + .rates = TAS5086_PCM_RATES, + .formats = TAS5086_PCM_FORMATS, + }, + .ops = &tas5086_dai_ops, +}; + +#ifdef CONFIG_PM +static int tas5086_soc_resume(struct snd_soc_codec *codec) +{ + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + + /* Restore codec state */ + return regcache_sync(priv->regmap); +} +#else +#define tas5086_soc_resume NULL +#endif /* CONFIG_PM */ + +#ifdef CONFIG_OF +static const struct of_device_id tas5086_dt_ids[] = { + { .compatible = "ti,tas5086", }, + { } +}; +MODULE_DEVICE_TABLE(of, tas5086_dt_ids); +#endif + +/* charge period values in microseconds */ +static const int tas5086_charge_period[] = { + 13000, 16900, 23400, 31200, 41600, 54600, 72800, 96200, + 130000, 156000, 234000, 312000, 416000, 546000, 728000, 962000, + 1300000, 169000, 2340000, 3120000, 4160000, 5460000, 7280000, 9620000, +}; + +static int tas5086_probe(struct snd_soc_codec *codec) +{ + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + int charge_period = 1300000; /* hardware default is 1300 ms */ + int i, ret; + + if (of_match_device(of_match_ptr(tas5086_dt_ids), codec->dev)) { + struct device_node *of_node = codec->dev->of_node; + of_property_read_u32(of_node, "ti,charge-period", &charge_period); + } + + /* lookup and set split-capacitor charge period */ + if (charge_period == 0) { + regmap_write(priv->regmap, TAS5086_SPLIT_CAP_CHARGE, 0); + } else { + i = index_in_array(tas5086_charge_period, + ARRAY_SIZE(tas5086_charge_period), + charge_period); + if (i >= 0) + regmap_write(priv->regmap, TAS5086_SPLIT_CAP_CHARGE, + i + 0x08); + else + dev_warn(codec->dev, + "Invalid split-cap charge period of %d ns.\n", + charge_period); + } + + /* enable factory trim */ + ret = regmap_write(priv->regmap, TAS5086_OSC_TRIM, 0x00); + if (ret < 0) + return ret; + + /* start all channels */ + ret = regmap_write(priv->regmap, TAS5086_SYS_CONTROL_2, 0x20); + if (ret < 0) + return ret; + + /* set master volume to 0 dB */ + ret = regmap_write(priv->regmap, TAS5086_MASTER_VOL, 0x30); + if (ret < 0) + return ret; + + /* mute all channels for now */ + ret = regmap_write(priv->regmap, TAS5086_SOFT_MUTE, + TAS5086_SOFT_MUTE_ALL); + if (ret < 0) + return ret; + + return 0; +} + +static int tas5086_remove(struct snd_soc_codec *codec) +{ + struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); + + if (gpio_is_valid(priv->gpio_nreset)) + /* Set codec to the reset state */ + gpio_set_value(priv->gpio_nreset, 0); + + return 0; +}; + +static struct snd_soc_codec_driver soc_codec_dev_tas5086 = { + .probe = tas5086_probe, + .remove = tas5086_remove, + .resume = tas5086_soc_resume, + .controls = tas5086_controls, + .num_controls = ARRAY_SIZE(tas5086_controls), +}; + +static const struct i2c_device_id tas5086_i2c_id[] = { + { "tas5086", 0 }, + { } +}; +MODULE_DEVICE_TABLE(i2c, tas5086_i2c_id); + +static const struct regmap_config tas5086_regmap = { + .reg_bits = 8, + .val_bits = 8, + .max_register = ARRAY_SIZE(tas5086_reg_defaults), + .reg_defaults = tas5086_reg_defaults, + .num_reg_defaults = ARRAY_SIZE(tas5086_reg_defaults), + .cache_type = REGCACHE_RBTREE, + .volatile_reg = tas5086_volatile_reg, + .writeable_reg = tas5086_writeable_reg, + .readable_reg = tas5086_accessible_reg, +}; + +static int tas5086_i2c_probe(struct i2c_client *i2c, + const struct i2c_device_id *id) +{ + struct tas5086_private *priv; + struct device *dev = &i2c->dev; + int gpio_nreset = -EINVAL; + int i, ret; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + priv->regmap = devm_regmap_init_i2c(i2c, &tas5086_regmap); + if (IS_ERR(priv->regmap)) { + ret = PTR_ERR(priv->regmap); + dev_err(&i2c->dev, "Failed to create regmap: %d\n", ret); + return ret; + } + + i2c_set_clientdata(i2c, priv); + + if (of_match_device(of_match_ptr(tas5086_dt_ids), dev)) { + struct device_node *of_node = dev->of_node; + gpio_nreset = of_get_named_gpio(of_node, "reset-gpio", 0); + } + + if (gpio_is_valid(gpio_nreset)) + if (devm_gpio_request(dev, gpio_nreset, "TAS5086 Reset")) + gpio_nreset = -EINVAL; + + if (gpio_is_valid(gpio_nreset)) { + /* Reset codec - minimum assertion time is 400ns */ + gpio_direction_output(gpio_nreset, 0); + udelay(1); + gpio_set_value(gpio_nreset, 1); + + /* Codec needs ~15ms to wake up */ + msleep(15); + } + + priv->gpio_nreset = gpio_nreset; + + /* The TAS5086 always returns 0x03 in its TAS5086_DEV_ID register */ + ret = regmap_read(priv->regmap, TAS5086_DEV_ID, &i); + if (ret < 0) + return ret; + + if (i != 0x3) { + dev_err(dev, + "Failed to identify TAS5086 codec (got %02x)\n", i); + return -ENODEV; + } + + return snd_soc_register_codec(&i2c->dev, &soc_codec_dev_tas5086, + &tas5086_dai, 1); +} + +static int tas5086_i2c_remove(struct i2c_client *i2c) +{ + snd_soc_unregister_codec(&i2c->dev); + return 0; +} + +static struct i2c_driver tas5086_i2c_driver = { + .driver = { + .name = "tas5086", + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(tas5086_dt_ids), + }, + .id_table = tas5086_i2c_id, + .probe = tas5086_i2c_probe, + .remove = tas5086_i2c_remove, +}; + +static int __init tas5086_modinit(void) +{ + return i2c_add_driver(&tas5086_i2c_driver); +} +module_init(tas5086_modinit); + +static void __exit tas5086_modexit(void) +{ + i2c_del_driver(&tas5086_i2c_driver); +} +module_exit(tas5086_modexit); + +MODULE_AUTHOR("Daniel Mack <zonque(a)gmail.com>"); +MODULE_DESCRIPTION("Texas Instruments TAS5086 ALSA SoC Codec Driver"); +MODULE_LICENSE("GPL"); -- 1.8.1.4

2 1

[alsa-devel] [PATCH 1/2] ASoC: Drop unused "dapm" field form soc_enum struct
by Lars-Peter Clausen 08 Mar '13

08 Mar '13

This field was added in commit 2e72f8e ("ASoC: New enum type: value_enum"), but has never been used since. Considering that the soc_enum struct is usually shared between all instances of a CODEC, it also doesn't make much sense to have a pointer to DAPM specific data in it. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- include/sound/soc.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index a6a059c..c84062b 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1086,7 +1086,6 @@ struct soc_enum { unsigned int mask; const char * const *texts; const unsigned int *values; - void *dapm; }; /* codec IO */ -- 1.8.0

2 2

[alsa-devel] [PATCH] ALSA: ASoC: Add codec driver for AK5386
by Daniel Mack 08 Mar '13

08 Mar '13

Adds a driver for Asahi Kasei's AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC. The device has no control port interface but an optional RESET/PDN GPIO pin. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- Documentation/devicetree/bindings/sound/ak5386.txt | 19 +++ sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/ak5386.c | 152 +++++++++++++++++++++ 4 files changed, 177 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ak5386.txt create mode 100644 sound/soc/codecs/ak5386.c diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt new file mode 100644 index 0000000..dc3914f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak5386.txt @@ -0,0 +1,19 @@ +AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC + +This device has no control interface. + +Required properties: + + - compatible : "asahi-kasei,ak5386" + +Optional properties: + + - reset-gpio : a GPIO spec for the reset/power down pin. + If specified, it will be deasserted at probe time. + +Example: + +spdif: ak5386@0 { + compatible = "asahi-kasei,ak5386"; + reset-gpio = <&gpio0 23>; +}; diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 86b3524..18fea10 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -26,6 +26,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4641 if I2C select SND_SOC_AK4642 if I2C select SND_SOC_AK4671 if I2C + select SND_SOC_AK5386 select SND_SOC_ALC5623 if I2C select SND_SOC_ALC5632 if I2C select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC @@ -204,6 +205,9 @@ config SND_SOC_AK4642 config SND_SOC_AK4671 tristate +config SND_SOC_AK5386 + tristate + config SND_SOC_ALC5623 tristate config SND_SOC_ALC5632 diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index 8077bc2..b9e41c9 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -14,6 +14,7 @@ snd-soc-ak4535-objs := ak4535.o snd-soc-ak4641-objs := ak4641.o snd-soc-ak4642-objs := ak4642.o snd-soc-ak4671-objs := ak4671.o +snd-soc-ak5386-objs := ak5386.o snd-soc-arizona-objs := arizona.o snd-soc-cq93vc-objs := cq93vc.o snd-soc-cs42l51-objs := cs42l51.o @@ -138,6 +139,7 @@ obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_AK4641) += snd-soc-ak4641.o obj-$(CONFIG_SND_SOC_AK4642) += snd-soc-ak4642.o obj-$(CONFIG_SND_SOC_AK4671) += snd-soc-ak4671.o +obj-$(CONFIG_SND_SOC_AK5386) += snd-soc-ak5386.o obj-$(CONFIG_SND_SOC_ALC5623) += snd-soc-alc5623.o obj-$(CONFIG_SND_SOC_ALC5632) += snd-soc-alc5632.o obj-$(CONFIG_SND_SOC_ARIZONA) += snd-soc-arizona.o diff --git a/sound/soc/codecs/ak5386.c b/sound/soc/codecs/ak5386.c new file mode 100644 index 0000000..1f30398 --- /dev/null +++ b/sound/soc/codecs/ak5386.c @@ -0,0 +1,152 @@ +/* + * ALSA SoC driver for + * Asahi Kasei AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC + * + * (c) 2013 Daniel Mack <zonque(a)gmail.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/of.h> +#include <linux/of_gpio.h> +#include <linux/of_device.h> +#include <sound/soc.h> +#include <sound/pcm.h> +#include <sound/initval.h> + +struct ak5386_priv { + int reset_gpio; +}; + +static struct snd_soc_codec_driver soc_codec_ak5386; + +static int ak5386_set_dai_fmt(struct snd_soc_dai *codec_dai, + unsigned int format) +{ + struct snd_soc_codec *codec = codec_dai->codec; + + format &= SND_SOC_DAIFMT_FORMAT_MASK; + if (format != SND_SOC_DAIFMT_LEFT_J && + format != SND_SOC_DAIFMT_I2S) { + dev_err(codec->dev, "Invalid DAI format\n"); + return -EINVAL; + } + + return 0; +} + +static int ak5386_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params, + struct snd_soc_dai *dai) +{ + struct snd_soc_codec *codec = dai->codec; + struct ak5386_priv *priv = snd_soc_codec_get_drvdata(codec); + + /* + * From the datasheet: + * + * All external clocks (MCLK, SCLK and LRCK) must be present unless + * PDN pin = “L”. If these clocks are not provided, the AK5386 may + * draw excess current due to its use of internal dynamically + * refreshed logic. If the external clocks are not present, place + * the AK5386 in power-down mode (PDN pin = “L”). + */ + + if (gpio_is_valid(priv->reset_gpio)) + gpio_set_value(priv->reset_gpio, 1); + + return 0; +} + +static int ak5386_hw_free(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct snd_soc_codec *codec = dai->codec; + struct ak5386_priv *priv = snd_soc_codec_get_drvdata(codec); + + if (gpio_is_valid(priv->reset_gpio)) + gpio_set_value(priv->reset_gpio, 0); + + return 0; +} + +static const struct snd_soc_dai_ops ak5386_dai_ops = { + .set_fmt = ak5386_set_dai_fmt, + .hw_params = ak5386_hw_params, + .hw_free = ak5386_hw_free, +}; + +static struct snd_soc_dai_driver ak5386_dai = { + .name = "ak5386-hifi", + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rates = SNDRV_PCM_RATE_8000_192000, + .formats = SNDRV_PCM_FMTBIT_S8 | + SNDRV_PCM_FMTBIT_S16_LE | + SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S24_3LE, + }, + .ops = &ak5386_dai_ops, +}; + +#ifdef CONFIG_OF +static const struct of_device_id ak5386_dt_ids[] = { + { .compatible = "asahi-kasei,ak5386", }, + { } +}; +MODULE_DEVICE_TABLE(of, ak5386_dt_ids); +#endif + +static int ak5386_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct ak5386_priv *priv; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + priv->reset_gpio = -EINVAL; + dev_set_drvdata(dev, priv); + + if (of_match_device(of_match_ptr(ak5386_dt_ids), dev)) + priv->reset_gpio = of_get_named_gpio(dev->of_node, + "reset-gpio", 0); + + if (gpio_is_valid(priv->reset_gpio)) + if (devm_gpio_request_one(dev, priv->reset_gpio, + GPIOF_OUT_INIT_LOW, + "AK5386 Reset")) + priv->reset_gpio = -EINVAL; + + return snd_soc_register_codec(dev, &soc_codec_ak5386, + &ak5386_dai, 1); +} + +static int ak5386_remove(struct platform_device *pdev) +{ + snd_soc_unregister_codec(&pdev->dev); + return 0; +} + +static struct platform_driver ak5386_driver = { + .probe = ak5386_probe, + .remove = ak5386_remove, + .driver = { + .name = "ak5386", + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(ak5386_dt_ids), + }, +}; + +module_platform_driver(ak5386_driver); + +MODULE_DESCRIPTION("ASoC driver for AK5386 ADC"); +MODULE_AUTHOR("Daniel Mack <zonque(a)gmail.com>"); +MODULE_LICENSE("GPL"); -- 1.8.1.4

2 1

[alsa-devel] [PATCH v2 00/12] ARM: mxs: move to generic DMA device tree binding
by Shawn Guo 08 Mar '13

08 Mar '13

The series converts mxs-dma and its clients to generic DMA device tree binding/helper. I published a branch below to ease people who is willing to help testing the series. git://git.linaro.org/people/shawnguo/linux-2.6.git devel/mxs-dma-dt Changes since v1: - Remove the use of of_dma_filter_info which should not be needed by a customized xlate function - Correct dma-names to have it mean the channel function in client devices - Add a new dmaengine_pcm API snd_dmaengine_generic_pcm_open() for users that support generic DMA device tree binding - Remove the old fsl,<module>-dma-channel properties from device tree Subsystem maintainers, I need your ACKs to have the series go via arm-soc as a whole if the patches look good to you. Thanks, Shawn Shawn Guo (12): ARM: dts: add generic DMA device tree binding for mxs-dma dma: mxs-dma: use devm_* managed functions dma: mxs-dma: move to generic device tree binding mmc: mxs-mmc: move to use generic DMA helper spi: mxs-spi: move to use generic DMA helper i2c: i2c-mxs: move to use generic DMA helper mtd: gpmi: move to use generic DMA helper serial: mxs-auart: move to use generic DMA helper ASoC: dmaengine_pcm: add snd_dmaengine_generic_pcm_open() ASoC: mxs: move to use generic DMA helper dma: mxs-dma: remove code left from generic DMA binding conversion ARM: dts: remove old DMA binding data from client nodes .../devicetree/bindings/dma/fsl-mxs-dma.txt | 49 +++++++- Documentation/devicetree/bindings/i2c/i2c-mxs.txt | 12 +- Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 12 +- .../devicetree/bindings/mtd/gpmi-nand.txt | 17 +-- .../devicetree/bindings/sound/mxs-saif.txt | 18 +-- Documentation/devicetree/bindings/spi/mxs-spi.txt | 12 +- .../bindings/tty/serial/fsl-mxs-auart.txt | 16 ++- arch/arm/boot/dts/imx23.dtsi | 57 +++++++-- arch/arm/boot/dts/imx28.dtsi | 104 +++++++++++----- arch/arm/boot/dts/imx6qdl.dtsi | 12 +- drivers/dma/mxs-dma.c | 128 +++++++++++--------- drivers/i2c/busses/i2c-mxs.c | 40 +----- drivers/mmc/host/mxs-mmc.c | 48 +------- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 51 +------- drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 3 +- drivers/spi/spi-mxs.c | 60 ++------- drivers/tty/serial/mxs-auart.c | 52 +------- include/linux/fsl/mxs-dma.h | 20 --- include/linux/spi/mxs-spi.h | 4 +- include/sound/dmaengine_pcm.h | 2 + sound/soc/mxs/mxs-pcm.c | 42 +------ sound/soc/mxs/mxs-pcm.h | 5 - sound/soc/mxs/mxs-saif.c | 28 +---- sound/soc/mxs/mxs-saif.h | 1 - sound/soc/soc-dmaengine-pcm.c | 39 ++++++ 25 files changed, 368 insertions(+), 464 deletions(-) delete mode 100644 include/linux/fsl/mxs-dma.h -- 1.7.9.5

4 10