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

[alsa-devel] [PATCH] ASoC: WM8903: Implement DMIC support
by Stephen Warren 14 Oct '11

14 Oct '11

In addition to the currently supported analog capture path, the WM8903 also supports digital mics. The analog and digital capture paths are exclusive; a mux is present to select the capture source. Logically, the mux exists to select the decimator's input, from either the ADC or DMIC block outputs. However, the ADC power domain also includes the DMIC interface. Consequently, this change represents the mux as existing immediately before the ADC, and selecting between the Input PGA and DMIC block outputs. An alternative might be to represent the mux in its correct location, and associate the ADC power enable controls with both the real ADC, and a fake ADC for the DMIC? Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/codecs/wm8903.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c index d53f206..f3cab84 100644 --- a/sound/soc/codecs/wm8903.c +++ b/sound/soc/codecs/wm8903.c @@ -634,6 +634,13 @@ static const struct soc_enum lsidetone_enum = static const struct soc_enum rsidetone_enum = SOC_ENUM_SINGLE(WM8903_DAC_DIGITAL_0, 0, 3, sidetone_text); +static const char *adcinput_text[] = { + "ADC", "DMIC" +}; + +static const struct soc_enum adcinput_enum = + SOC_ENUM_SINGLE(WM8903_CLOCK_RATE_TEST_4, 9, 2, adcinput_text); + static const char *aif_text[] = { "Left", "Right" }; @@ -767,6 +774,9 @@ static const struct snd_kcontrol_new lsidetone_mux = static const struct snd_kcontrol_new rsidetone_mux = SOC_DAPM_ENUM("DACR Sidetone Mux", rsidetone_enum); +static const struct snd_kcontrol_new adcinput_mux = + SOC_DAPM_ENUM("ADC Input", adcinput_enum); + static const struct snd_kcontrol_new lcapture_mux = SOC_DAPM_ENUM("Left Capture Mux", lcapture_enum); @@ -817,6 +827,7 @@ SND_SOC_DAPM_INPUT("IN2L"), SND_SOC_DAPM_INPUT("IN2R"), SND_SOC_DAPM_INPUT("IN3L"), SND_SOC_DAPM_INPUT("IN3R"), +SND_SOC_DAPM_INPUT("DMICDAT"), SND_SOC_DAPM_OUTPUT("HPOUTL"), SND_SOC_DAPM_OUTPUT("HPOUTR"), @@ -842,6 +853,9 @@ SND_SOC_DAPM_MUX("Right Input Mode Mux", SND_SOC_NOPM, 0, 0, &rinput_mode_mux), SND_SOC_DAPM_PGA("Left Input PGA", WM8903_POWER_MANAGEMENT_0, 1, 0, NULL, 0), SND_SOC_DAPM_PGA("Right Input PGA", WM8903_POWER_MANAGEMENT_0, 0, 0, NULL, 0), +SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), +SND_SOC_DAPM_MUX("Right ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), + SND_SOC_DAPM_ADC("ADCL", NULL, WM8903_POWER_MANAGEMENT_6, 1, 0), SND_SOC_DAPM_ADC("ADCR", NULL, WM8903_POWER_MANAGEMENT_6, 0, 0), @@ -979,6 +993,11 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "Left Input PGA", NULL, "Left Input Mode Mux" }, { "Right Input PGA", NULL, "Right Input Mode Mux" }, + { "Left ADC Input", "ADC", "Left Input PGA" }, + { "Left ADC Input", "DMIC", "DMICDAT" }, + { "Right ADC Input", "ADC", "Right Input PGA" }, + { "Right ADC Input", "DMIC", "DMICDAT" }, + { "Left Capture Mux", "Left", "ADCL" }, { "Left Capture Mux", "Right", "ADCR" }, @@ -988,9 +1007,9 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "AIFTXL", NULL, "Left Capture Mux" }, { "AIFTXR", NULL, "Right Capture Mux" }, - { "ADCL", NULL, "Left Input PGA" }, + { "ADCL", NULL, "Left ADC Input" }, { "ADCL", NULL, "CLK_DSP" }, - { "ADCR", NULL, "Right Input PGA" }, + { "ADCR", NULL, "Right ADC Input" }, { "ADCR", NULL, "CLK_DSP" }, { "Left Playback Mux", "Left", "AIFRXL" }, -- 1.7.1

4 4

[alsa-devel] Dell XPS 13 (Codec: IDT 92HD73C1X5) and 3 stereo jack output
by Ruben Van Boxem 14 Sep '11

14 Sep '11

Hi, I have been trying to get my Dell XPS 13 to output 5.1 sound through the stereo jacks (because the NVIDIA HDMI only does 2.1). Attached is alsa-info output. I can't seem to be able to set the Line/Mic In to output. I have tried several things, going from fiddling with Kmix to fiddling with the modprobe "model=" parameter, and even looking through the hda_analyzer.py output. This last one lifted a tiny corner of the solution, but I don't think a vanilla Alsa install will get me through this. In Windows, I can use the three jacks to output 2 channels each, so I am sure the hardware is capable of it. In HDA analyzer I can see that there are several "Line Out" entries, but since they all have the node cap "Unsolicited Capabilities", I'm pretty sure the problem is alsa not knowing about the, well, capabilities. I searched the web and documentation for anything sane to try, but nothing worked. The default modprobe "model=" is the best (I can get 4.0 output from the jacks, and everything works, except the third jack). If you need more input or information, please ask, I'm very willing to get this solved! Thanks, Ruben

2 3

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

[alsa-devel] [PATCH] ALSA - HDA - Add period time constraint to hda-intel
by Raymond Yau 23 Jun '11

23 Jun '11

As there is a 10 seconds schedule_timeout in alsa-kernel The following error occur when aplay/arecord using a period time longer than 10 seconds for for those hda codec which support rate lower than 32000 when prealloc = 4096 ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x1aeb00, format=0x4111 ... ALSA pcm_native.c:1531: playback drain error (DMA or IRQ trouble?) aplay -v -Dhw:1 --period-time=10001000 22050.wav Playing WAVE '22050.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Stereo Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 22050 exact rate : 22050 (22050/1) msbits : 16 buffer_size : 441024 period_size : 220512 period_time : 10000544 tstamp_mode : NONE period_step : 1 avail_min : 220512 period_event : 0 start_threshold : 441024 stop_threshold : 441024 silence_threshold: 0 silence_size : 0 boundary : 1806434304 appl_ptr : 0 hw_ptr : 0 ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x9c500, format=0x511 ALSA hda_codec.c:1295: hda_codec_setup_stream: NID=0x8, stream=0x1, channel=0, format=0x511 ALSA pcm_lib.c:1789: capture write error (DMA or IRQ trouble?) arecord -Dhw:1 -v --period-time=10005000 -r 8000 -c2 -f S16_LE /dev/null Recording WAVE '/dev/null' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 160064 period_size : 80032 period_time : 10004000 tstamp_mode : NONE period_step : 1 avail_min : 80032 period_event : 0 start_threshold : 1 stop_threshold : 160064 silence_threshold: 0 silence_size : 0 boundary : 1311244288 appl_ptr : 0 hw_ptr : 0 arecord: pcm_read:1773: read error: Input/output error

2 4

[alsa-devel] [PATCH] ALSA: isight: add now required waking of DMA context
by Stefan Richter 22 Jun '11

22 Jun '11

Since commit 13882a82ee16, upper-layer firewire drivers are required to flush after enqueueing a batch of isochronous buffers. Signed-off-by: Stefan Richter <stefanr(a)s5r6.in-berlin.de> --- Actually, snd-isight still worked for me without it but I guess I was just lucky that the controllers (FW643-e, JMB381, XIO2213A) never read up to the current tail of the DMA program. Dismiss this if you already have something like this in the pipeline. sound/firewire/isight.c | 1 + 1 file changed, 1 insertion(+) Index: b/sound/firewire/isight.c =================================================================== --- a/sound/firewire/isight.c +++ b/sound/firewire/isight.c @@ -213,6 +213,7 @@ static void isight_packet(struct fw_iso_ if (++index >= QUEUE_LENGTH) index = 0; isight->packet_index = index; + fw_iso_context_queue_flush(isight->context); } static int isight_connect(struct isight *isight) -- Stefan Richter -=====-==-== -=-= ===== http://arcgraph.de/sr/

2 3

Re: [alsa-devel] [PATCH] ASoC: Add support for Cirrus Logic CS42L52 Lowpower Stereo Codec
by Mark Brown 22 Jun '11

22 Jun '11

On Thu, Feb 25, 2010 at 06:07:35PM -0600, Brian wrote: This is a quick first pass review only. It'd be best if you could include a Signed-off-by line in submissions so that they can be merged if they're OK, even if you expect problems you may be surprised! Overall this looks fairly good - there's a lot of comments below but the vast majority of them are stylistic issues or needing to update to current APIs rather than major structural problems with the code. The main thing I don't really follow is the register access code, there's quite a bit of stuff going on in there. > + * published by the Free Software Foundation. > + * Revision history > + * Nov 2007 Initial version. > + * Oct 2008 Updated to 2.6.26 > + * Feb 2010 Updated to latest asoc git tree Please remove the changelog, once things are merged git takes care of that. > + */ > +#define DEBUG Not by default in mainline :) > +#ifdef DEBUG > +#define SOCDBG(fmt, arg...) printk(KERN_ERR "%s: %s() " fmt, SOC_CS42L52_NAME, __FUNCTION__, ##arg) > +#else > +#define SOCDBG(fmt, arg...) > +#endif > +#define SOCINF(fmt, args...) printk(KERN_INFO "%s: " fmt, SOC_CS42L52_NAME, ##args) > +#define SOCERR(fmt, args...) printk(KERN_ERR "%s: " fmt, SOC_CS42L52_NAME, ##args) Please convert the driver to use the standard dev_ and pr_ macros for this (where possible the dev_ ones are better). > +static int soc_cs42l52_set_bias_level(struct snd_soc_codec *codec, > + enum snd_soc_bias_level level); > +static int soc_cs42l52_pcm_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *params, > + struct snd_soc_dai *dai); > +static int soc_cs42l52_set_sysclk(struct snd_soc_dai *codec_dai, > + int clk_id, u_int freq, int dir); > +static int soc_cs42l52_digital_mute(struct snd_soc_dai *dai, int mute); > +static int soc_cs42l52_set_fmt(struct snd_soc_dai *codec_dai, > + u_int fmt); > + > +static unsigned int soc_cs42l52_read(struct snd_soc_codec *codec, > + u_int reg); Please use 'unsigned int' rather than 'u_int' for consistency with the rest of ASoC. It's a bit surprising that you need the forward declarations at all but they do no harm. > +/** > + * snd_soc_get_volsw - single mixer get callback > + * @kcontrol: mixer control > + * @uinfo: control element information > + * > + * Callback to get the value of a single mixer control. > + * > + * Returns 0 for success. > + */ > +int snd_soc_cs42l5x_get_volsw(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); > + int reg = kcontrol->private_value & 0xff; The indentation looks wrong - should be tabs for indenting the code blocks. scripts/checkpatch.pl is a pretty good check for this sort of stuff, I'll not mention other issues. > + int shift = (kcontrol->private_value >> 8) & 0x0f; > + int rshift = (kcontrol->private_value >> 12) & 0x0f; > + int max = (kcontrol->private_value >> 16) & 0xff; > + int mask = (1 << fls(max)) - 1; > + int min = (kcontrol->private_value >> 24) & 0xff; > + > + ucontrol->value.integer.value[0] = > + ((snd_soc_read(codec, reg) >> shift) - min) & mask; > + if (shift != rshift) > + ucontrol->value.integer.value[1] = > + ((snd_soc_read(codec, reg) >> rshift) - min) & mask; This and most of the other custom control stuff looks an awful lot like it should be done by adding a SND_SOC_DOUBLE_SIGNED() or something along the lines of the existing _S8() but I didn't read entirely closely. I was speaking to someone on IRC only the other day who needed some of those types for a different device. These should also be updated to use struct soc_mixer_control for the private value rather than shifting everything into the private value, it allows wider ranges and is less error prone. > +static const u8 soc_cs42l52_reg_default[] = { > + 0x00, 0xE0, 0x01, 0x07, 0x05, /*4*/ > + 0xa0, 0x00, 0x00, 0x81, /*8*/ Very nitpicky but you're using a mix of upper and lower case for the letters in the hex digits. > +static inline int soc_cs42l52_read_reg_cache(struct snd_soc_codec *codec, > + u_int reg) > +{ > + u8 *cache = codec->reg_cache; > + > + return reg > SOC_CS42L52_REG_NUM ? -EINVAL : cache[reg]; > +} You should be able to replace all your register I/O code with use of soc-cache.c with 8 bit data, 8 bit register. Except... > + if(info->flags & SOC_CS42L52_ALL_IN_ONE) > + { > + for(i = 0; i < codec->num_dai; i++) > + { > + if(info->machine_handler) > + info->machine_handler(i); ...I'm not sure what's going on here but it could really use an explanation? I'm not sure what ALL_IN_ONE is supposed to do, or what the machine_handler() function is for. > + if(info->flags & SOC_CS42L52_CHIP_SWICTH) > + { > + num = info->flags & SOC_CS42L52_CHIP_MASK; > + if(info->machine_handler) > + info->machine_handler(num); > + } This too. There's a lot of unusual code using this machine handler function. I suspect this can all use ASoC standard stuff. > +static inline int soc_cs42l52_get_revison(struct snd_soc_codec *codec) > +{ > + u8 data; > + u8 addr; > + int num, ret = 0; > + struct soc_codec_cs42l52 *info = (struct soc_codec_cs42l52*)codec->private_data; No need to cast away from void (quite a few examples of this in the code). > + return ret < 0 ? ret : data; I'm not a big fan of the ternery operator... > +static unsigned int soc_cs42l52_read(struct snd_soc_codec *codec, > + u_int reg) > +{ > + u8 data; > + u8 addr; > + int i, ret = 0; > + struct soc_codec_cs42l52 *info = (struct soc_codec_cs42l52*)codec->private_data; > +#ifndef CONFIG_CS42L52_DEBUG > + if(reg == CODEC_CS42L52_SPK_STATUS) > + { > +#endif This really shouldn't be ifdefed. If you need to handle registers that report status from the device with the soc-cache stuff use the volatile_register() callback in the CODEC, any registers that need a CODEC read will call through to the hardware rather than using the cache. > +static const char *cs42l52_adc_mux[] = {"AIN1", "AIN2", "AIN3", "AIN4", "PGA"}; > +static const char *cs42l52_mic_mux[] = {"MIC1", "MIC2"}; > +static const char *cs42l52_stereo_mux[] = {"Mono", "Stereo"}; > +static const char *cs42l52_off[] = {"On", "Off"}; > +static const char *cs42l52_hpmux[] = {"Off", "On"}; > + > +static const struct soc_enum soc_cs42l52_enum[] = { > +SOC_ENUM_DOUBLE(CODEC_CS42L52_ANALOG_HPF_CTL, 4, 6, 2, cs42l52_hpf_freeze), /*0*/ > +SOC_ENUM_SINGLE(CODEC_CS42L52_ADC_HPF_FREQ, 0, 4, cs42l52_hpf_corner_freq), Don't use an array of enums, define individual variables for them. Some drivers use the arrays for historical reasons - they're quite painful to work with if you ever want to change anything in the middle and we've found a few off by one errors in the referencing into the arrays before :/. > +static const struct snd_kcontrol_new soc_cs42l52_controls[] = { > + > +SOC_ENUM("Mic VA Capture Switch", soc_cs42l52_enum[18]), /*0*/ enums shouldn't be called Switch - Switch has a specific meaning to ALSA (see Documentation/sound/alsa/ControlNames.txt, there's quite a few other controls could do with having the components of the name reordered and various other things following that). Normally just omit the ' Switch' from the name. > +SOC_DOUBLE("Analog SR Capture Switch", CODEC_CS42L52_ANALOG_HPF_CTL, 1, 3, 1, 1), > +SOC_DOUBLE("Analog ZC Capture Switch", CODEC_CS42L52_ANALOG_HPF_CTL, 0, 2, 1, 1), This'd normally be 'Capture ZC Switch' if it's for zero cross. > +SOC_ENUM("HPF corner freq Capture Switch", soc_cs42l52_enum[1]), /*5*/ > + > +SOC_SINGLE("Ganged Ctl Capture Switch", CODEC_CS42L52_ADC_MISC_CTL, 7, 1, 1), /* should be enabled init */ What does the comment mean here? > +SOC_SINGLE("HP Analog Gain Playback Volume", CODEC_CS42L52_PB_CTL1, 5, 7, 0), Just "Headphone Volume"? > +SOC_SINGLE("Playback B=A Volume Playback Switch", CODEC_CS42L52_PB_CTL1, 4, 1, 0), /*10*/ /*should be enabled init*/ If this is the mute for the headphone volume it should have the same name but with Switch instead of Volume so applications like alsamixer can display the two together. > +static int soc_cs42l52_add_controls(struct snd_soc_codec *codec) > +{ > + int i,ret = 0; > + > + for(i = 0; i < ARRAY_SIZE(soc_cs42l52_controls); i++) > + { > + ret = snd_ctl_add(codec->card, > + snd_soc_cnew(&soc_cs42l52_controls[i], codec, NULL)); > + if(ret < 0) > + { > + SOCDBG("add cs42l52 controls failed\n"); > + break; Replace this with snd_soc_add_controls(). > + /* Sum switches */ > + SND_SOC_DAPM_PGA("AIN1A Switch", CODEC_CS42L52_ADC_PGA_A, 0, 0, NULL, 0), Without having checked the datasheet I *suspect* most of these switches should be modelled as inputs to a mixer (possibly one with no power control of its own)? The "Switch" in the name certainly looks very out of place in the name of a DAPM control. > + /* Output path */ > + SND_SOC_DAPM_MUX("Passthrough Left Playback Switch", SND_SOC_NOPM, 0, 0, &cs42l52_hpa_mux), Normally "Bypass" instead of "Passthrough". > + /* Mic Bias */ > + {"Mic Bias Capture Switch", "On", "PGA MICA"}, > + {"Mic Bias Capture Switch", "On", "PGA MICB"}, > + {"Mic-Bias", NULL, "Mic Bias Capture Switch"}, > + {"Mic-Bias", NULL, "Mic Bias Capture Switch"}, > + {"ADC Mux Left Capture Switch", "PGA", "Mic-Bias"}, > + {"ADC Mux Right Capture Switch", "PGA", "Mic-Bias"}, > + {"Passthrough Left Playback Switch", "On", "Mic-Bias"}, > + {"Passthrough Right Playback Switch", "On", "Mic-Bias"}, This looks odd - normally the microphone bias would be connected to the microphone input externally and would not be hooked up as an input wihtin the CODEC? > + /* terminator */ > + {NULL, NULL, NULL}, Not needed any more (I'm vaugely surprised this doesn't generate an error). > +#define SOC_CS42L52_RATES ( SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 | \ > + SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 | \ > + SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \ > + SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | \ > + SNDRV_PCM_RATE_96000 ) /*refer to cs42l52 datasheet page35*/ This is equivalent to SNDRV_PCM_RATE_8000_96000 > +/* #define CONFIG_MANUAL_CLK */ This might use some comments (or should possibly be deleted)? > + soc_cs42l52_set_bias_level(soc_codec, SND_SOC_BIAS_OFF); > + soc_codec->bias_level = SND_SOC_BIAS_STANDBY; > + schedule_delayed_work(&soc_codec->delayed_work, msecs_to_jiffies(1000)); > + soc_cs42l52_required_setup(soc_codec); A comment about what the delayed work is up to wouldn't hurt? > + /*set hp default volume*/ > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_HPA_VOL, DEFAULT_HP_VOL); > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_HPB_VOL, DEFAULT_HP_VOL); For pretty much all the configuration you're doing here just let userspace set things up, there's no telling what's an appropriate setting on any given system and presumably the chip designers made a reasonable effort to ensure that the default state of the chip is at least not harmful. > +#ifdef CONFIG_MANUAL_CLK > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_CLK_CTL, > + (soc_cs42l52_read(soc_codec, CODEC_CS42L52_CLK_CTL) > + & ~CLK_CTL_AUTODECT_ENABLE)); Pass this configuration in as platform data, this will allow multiple boards to build from the same kernel. > + ret = snd_soc_init_card(soc_dev); > + if(ret) > + { > + SOCERR("add snd card failed\n"); > + goto card_err; > + } Please develop against git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.35 (or whatever the latest kernel version branch is at any given time.) You should also be calling snd_soc_register_codec() and snd_soc_register_dai() from this function. > +#if defined (CONFIG_I2C) || defined (CONFIG_I2C_MODULE) No need for the ifdefs if you only support I2C, the ifdefs are used by drivers that have multiple control interfaces (typically I2C plus SPI). > + } > + > + > + return ret; > +} > + > +static int cs42l52_i2c_remove(struct i2c_client *client) > +{ > + struct snd_soc_codec *soc_codec; > + if(client) > + { > + soc_codec = i2c_get_clientdata(client); > + if(soc_codec) > + kfree(soc_codec->reg_cache); > + } > + return 0; > +} This should be unregistering from ASoC as well, or refusing to remove if not implemented. > + case SND_SOC_DAIFMT_DSP_B: > + SOCINF("unsupported format\n"); > + ret = -EINVAL; > + goto done; > + default: > + SOCINF("invaild format\n"); > + ret = -EINVAL; > + goto done; Could just squash these together. > + case SND_SOC_DAIFMT_IB_IF: > + SOCDBG("codec dai fmt inversed sclk\n"); > + iface |= IFACE_CTL1_INV_SCLK; > + break; > + case SND_SOC_DAIFMT_IB_NF: > + iface |= IFACE_CTL1_INV_SCLK; > + break; It looks like the hardware only supports the inversion of one of the clocks so only two of the clock polarity combinations should be supported? > + info->format = iface; I'd really expect to see interaction with the hardware here? > + /* 96k */ > + {12288000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_128, 0}, > + {18432000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_128, 0},/*29*/ > + {12000000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_125, 0}, > + {24000000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_125, 1}, If you're feeling adventurous you should be able to use this data to set up constraints for the DAI in the startup() callback so only sample rates supported from the system clock can be used by userspace. > +static int soc_cs42l52_pcm_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *params, > + struct snd_soc_dai *dai) > +{ > + int ret = 0; > + struct snd_soc_pcm_runtime *rtd = substream->private_data; > + struct snd_soc_device *soc_dev = rtd->socdev; > + struct snd_soc_codec *soc_codec = soc_dev->card->codec; > + struct soc_codec_cs42l52 *info = (struct soc_codec_cs42l52*)soc_codec->private_data; > + > + u32 clk = 0; > + int index = soc_cs42l52_get_clk(info->sysclk, params_rate(params)); > +static int soc_cs42l52_suspend(struct platform_device *pdev, pm_message_t state) > +{ > + struct snd_soc_device *soc_dev = (struct snd_soc_device*)platform_get_drvdata(pdev); > + struct snd_soc_codec *soc_codec = soc_dev->card->codec; > + > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_PWCTL1, PWCTL1_PDN_CODEC); > + soc_cs42l52_set_bias_level(soc_codec, SND_SOC_BIAS_OFF); I'd expect that set_bias_level() would do what the explict write does? > +#if defined (CONFIG_I2C) || defined (CONFIG_I2C_MODULE) > + if(soc_codec_data->i2c_addr) > + { > + ret = i2c_add_driver(&cs42l52_i2c_drv); > + > + if(ret) > + { > + SOCERR("register i2c driver failed\n"); > + goto out; > + > + } > + SOCINF("Cirrus Logic ALSA SoC codec cs42l52 driver verison 1.2 2/2010\n"); > + return ret; > + } This should be changed to use standard device model registration - see http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commit;h=… for an example of doing the conversion. > +struct soc_codec_cs42l52_data{ > + u_short i2c_addr; > +}; With the device model stuff this won't be needed any more. > +/* > + *CS42L52 internal registers > + */ > +#define CODEC_CS42L52_CHIP 0x01 > +#define CHIP_ID 0xE0 > +#define CHIP_ID_MASK 0xF8 Many of the register names and other definitions for register fields and values need to be namespace to avoid collisions.

4 5

[alsa-devel] Via VT2020: issues with kernel 2.6.38.{2, 3} (alsa 1.0.23) - working with 2.6.33.2 (alsa 1.0.21)
by alex dot baldacchino dot alsasub at gmail dot com 20 Jun '11

20 Jun '11

Hello, First of all let me apologize if I'm not fulfilling any requirements for this list, and for any errors in my English. I've sent a mail with same subject and content to this list as a non-subscriber on April, 26, but perhaps that's gone lost, or perhaps is still under moderation or didn't pass it, so I'm resending this from a different address as a subscriber. So, please, ignore my previous mail if it came out from moderation. As per subject, I'm experiencing problems with my motherboard built-in audio device (an Asrock with ATI SB8xx), embedding a Via VT2020 codec (I haven't tested the ATI HDMI part in same conditions). The card is recognized 'about' correctly (later in this mail something about dmesg and other issues), and stuff in /proc/asound seems correct, also I have no apparent problem with /dev special files, but I get no sound after having installed kernel 2.6.38.2 and updated to version 2.6.38.3 (both compiled from source); no mixer seems to work (later specific errors), but everything still works with older kernel 2.6.33.2 I've kept in my system (built with the same build environment). Since I'm using the very same userspace environment in both cases, I deem it to be a driver(s) related issue more likely; though, I've updated my alsa-lib and -utils to latest versions (were such when I downloaded sources - alsa-lib 1.0.24.1 & alsa-utils 1.0.24.2) and still get the very same results. But let me go into more details. Here is an excerpt from dmesg called with kernel 2.6.33.2 (sound works, but I'm just using headphone jack, so I can't tell about anything related with later issue with smart5.1 and hda I've seen in list archives): [...] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 HDA Intel 0000:01:05.1: irq 28 for MSI/MSI-X HDA Intel 0000:01:05.1: setting latency timer to 64 [...] ohci1394 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ohci1394 0000:04:00.0: setting latency timer to 64 [...] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[fe9ff800-fe9fffff] Max Packet=[2048] IR/IT contexts=[4/8] ieee1394: Host added: ID:BUS[0-00:1023] GUID[008f130043910900] [...] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0001 [...] Notice last line is an harmless warning (sound works) and is there because msi seems to be enabled by default; by adding "options snd-hda-intel enable_msi=0" to /etc/modprobe.d/alsa-base.conf both the warning and any reference to MSI/MSI-X disappear; same effect with pci=nomsi on command line (this time affecting other drivers, such as r8169). VT2020 is part of device 0000:00:14.2 sharing IRQ 16 with ohci1394; device 0000:01:05.1 is ATI HDMI, while device 0000:05.0 should be embedded radeon vga (bridged together according with lspci -t with 0000:00:01.0 on top); for each bridge I can find with lspci -t corresponding msi_bus file in sys filesystem (in /sys/bus/pci/devices/*) is always 1, regardless of any boot command (this with kernel 2.6.33.2). Now an excerpt from dmesg in kernel 2.6.38.3: [...] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 hda-codec: no NID for mapping control Independent HP:0:0 HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 HDA Intel 0000:01:05.1: setting latency timer to 64 [...] r8169 0000:03:00.0: irq 43 for MSI/MSI-X [...] firewire_ohci 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 firewire_ohci 0000:04:00.0: setting latency timer to 64 [...] firewire_ohci: Added fw-ohci device 0000:04:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x11 firewire_core: created device fw0: GUID 008f130043910900, S400 [...] Now firewire_ohci replaces ohci1394, again sharing IRQ 16 with hda-intel for vt2020. Line about r8169 is just for reference, since it gets a different irq for msi now. Similar behaviour for MSI: enabled/disabled with pci=nomsi (seems to be enabled by default without pci=msi) and msi_bus == 1 for bridges regardless of boot options, *but for bridge on top of ati hdmi device*: now msi seems to be disabled regardless of both 'enable_msi' option and pci=* boot command and corresponding bridge (device at bus 0000:00:01.0) holds a value of 0 for msi_bus... Notice there are no more warnings about response timeouts, as it happened in older kernel after disabling msi (both globally and for alsa through alsa config options). Notice also line "hda-codec: no NID for mapping control Independent HP:0:0". That's because function 'snd_hda_get_connections' (patch_via.c) called by 'via_hp_build' returns 3 ( test for 'nums <= 1' fails and the function doesn't return), but function 'side_mute_channel', called to init knew->subdevice when 'registering' via_hp_mixer[1], returns 0 (default value) and so condition 'if(nid > 0)', in function 'snd_hda_add_nid' (hda_codec.c), is not met and the error is triggered (by the way, param nid is of type hda_nid_t which in turn is an unsigned integer (u16), so, should that be 'if(nid != 0)' instead? just to avoid the risk of giving the impression that negative values are possible but mistaken (hda_nid_t is defined elsewhere). Also: param @nid, in function comment/documentation is defined as optional, but it doesn't seem to be). Incidentally, in /proc/asound/card0/codec#0 node 0x35 looks much like node 0x34 (with both older and newer kernel; posting excerpt for kernel 2.6.38.3): Node 0x34 [Audio Selector] wcaps 0x300501: Stereo Control: name="Independent HP", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 3 0x08 0x0b 0x0c* Node 0x35 [Audio Selector] wcaps 0x300501: Stereo Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 3 0x08 0x0b* 0x0c (notice connections and wcaps similarity, if relevant at all) Since I'm quite crazy, I've tried to modify 'side_mute_channel' to have it returning '0x35' for codec type 'VT1718S', but to no avail; I also tried to bypass 'snd_hda_add_nid', both avoiding 'via_hp_build' to clone via_hp_mixer[<something>] and/or modifying 'via_build_controls' and 'snd_hda_add_new_ctls' (hda_control.c) so that "Independent HP" ctls were handled by the latter (achieving this was just a matter of a pair of strcmp's to choose skipping the rest of an iteration or not), as I deem it was done in alsa 1.0.21 (embedded in kernel 2.6.33.2), but it didn't work (the only result I got this ways was to avoid that error message about nids in system logs). Additional infos from userspace applications: mplayer works fine with kernel 2.6.33.2 (again, only using one exit, I haven't tested all jacks combinations); called from cmdline (under X - but that's the same shutting X down) with default options ('mplayer <path/to/file>') it gives the following output (relevant excerpt, as I deem it, after codec choice, can provide more if needed): socket(): Address family not supported by protocol AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... (notice I'm not using alsa-tools, such as pulse-audio; with the above invocation sound/video works) running mplayer with option '-ao sdl' (using sdl audio, same file) I get the following output: [AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le AO: [sdl] 44100Hz 2ch s16le (2 bytes per sample) Starting playback... Again, sound works. In both cases, I can notice a change in /proc/asound/card0/codec#0 as follows: In nodes 0x08, 0x09, 0x0a, 0x0e (all [Audio Output] nodes, first 3 with 'wcaps 0x41d: Stereo Amp-Out', last with 'wcaps 0x611: Stereo Digital'), the following line: Converter: stream=0, channel=0 changes into: Converter: stream=5, channel=0 With kernel 2.6.38.x I get the following: running mplayer with no option, I get no sound and following output: socket(): Address family not supported by protocol AO: [pulse] Init failed: Connection refused Failed to initialize audio driver 'pulse' [AO_ALSA] alsa-lib: confmisc.c:768:(parse_card) cannot find card '0' [AO_ALSA] alsa-lib: conf.c:4184:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device [AO_ALSA] alsa-lib: confmisc.c:392:(snd_func_concat) error evaluating strings [AO_ALSA] alsa-lib: conf.c:4184:(_snd_config_evaluate) function snd_func_concat returned error: No such device [AO_ALSA] alsa-lib: confmisc.c:1251:(snd_func_refer) error evaluating name [AO_ALSA] alsa-lib: conf.c:4184:(_snd_config_evaluate) function snd_func_refer returned error: No such device [AO_ALSA] alsa-lib: conf.c:4663:(snd_config_expand) Evaluate error: No such device [AO_ALSA] alsa-lib: pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM default [AO_ALSA] Playback open error: No such device Failed to initialize audio driver 'alsa' [AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le [AO SDL] using aalib audio driver. [AO SDL] Unable to open audio: No available audio device Failed to initialize audio driver 'sdl:aalib' Could not open/initialize audio device -> no sound. Audio: no sound and nothing changes in codec#0 file; with option -ao sdl, instead: [AO SDL] Samplerate: 44100Hz Channels: Stereo Format s16le ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4184:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4184:(_snd_config_evaluate) function snd_func_concat returned error: No such device ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4184:(_snd_config_evaluate) function snd_func_refer returned error: No such device ALSA lib conf.c:4663:(snd_config_expand) Evaluate error: No such device ALSA lib pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM default AO: [sdl] 44100Hz 2ch s16le (2 bytes per sample) And sound works! Same changes as per (working) playback with kernel 33.2 (alsa 1.0.21) are noticeable in /proc/asound/card0/codec#0 in this case (that is, when getting sound with kernel 2.6.38.x); in addition, node 0x0c, now changes as well (again, '[Audio Output] wcaps 0x41d: Stereo Amp-Out.' and 'Converter: stream=5, channel=0') Moreover: with kernel 38.2, 38.3 alsamixer fails telling about problems finding device: cannot open mixer: No such device And amixer says: amixer: Mixer attach default error: No such device But there's no problem with /dev stuff (and same devices works pretty fine with kernel 2.6.33.2) - aplay -l doesn't work as well: aplay: device_list:240: no soundcards found... With kernel 2.6.33.2, aplay -l says: **** List of PLAYBACK Hardware Devices **** card 0: SB [HDA ATI SB], device 0: VT2020 Analog [VT2020 Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 0: SB [HDA ATI SB], device 1: VT2020 Digital [VT2020 Digital] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 A 'third party' mixer embedded in my distribution aborts by hitting a failed assertion in function 'snd_hctl_load' (hcontrol.c) failing assertion being 'assert(hctl->count == 0)' - I've added a few simple lines above the assertion to print out some info on stderr, and got the following results: In kernel 2.6.33.2: hctl->count: 0 hctl->ctl: 134748144 (0x80817F0) hctl->ctl->name: hw:0 which seems reasonable - according to /proc/iomem address 0x80817F0 is in range 00100000-cf83ffff (system ram) and higher than kernel stuff subranges ( 01000000-012c3be7: Kernel code - 012c3be8-0141dadf : Kernel data - 01481000-014b1e03 : Kernel bss); In kernel 2.6.38.2 & .38.3: hctl->count: 1156 hctl->ctl: 5398 (0x1516) Segmentation fault suggesting memory corruption (that's always the same address) - according to /proc/iomem address 0x1516 is in first range (0x0000-0xffff) which is reserved. I thought (and hoped) that could have been somehow related to cached/noncached pages issue solved by commit c27b92295ab4c6b90b1cee94c4c9c1b4732e1c2e, but applying diff patch for kernel 2.6.38.3 didn't change anything. After that, I've read changelog for kermel 2.6.38.4 but such didn't seem to me to present related material, so I didn't updgrade. I hope this post can help solving this issue and improving alsa infrastracture (I cannot easily go further). Best regards.

2 19

[alsa-devel] [PATCH V2 0/2] Add WM8994 PCM Machine driver for Exynos4210
by Sangbeom Kim 17 Jun '11

17 Jun '11

Hi, This is 2nd patchset for WM8994 pcm machine driver that supports PCM audio on SMDKV310, SMDKC210 and test is done. This is minor change version. AS jassi comment, I added new pcm structure for quirk handling. And added Liam's acked. Based on these patches WM8994 pcm machine driver supports followings: o Playback supports 8kHz sampling rates. o Capture supports 8kHz sampling rates. This patchset contains followings o To Kukjin Kim and Ben Dooks, [PATCH 1/2] ARM: EXYNOS4: Add PCM audio support for WM8994 o To Jassi Brar, Mark Brown and Liam Girdwood, [PATCH 2/2] ASoC: SAMSUNG: Add WM8580 PCM Machine driver Best Regards, SB Kim (Sangbeom Kim)

5 10

Re: [alsa-devel] Driver for TerraTec DMX 6Fire USB
by Takashi Iwai 16 Jun '11

16 Jun '11

At Tue, 18 Jan 2011 14:41:47 +0100, torsten.schenk wrote: > > Hello, > > (to all those who already got this mail: sorry, I sent the attachment accidentally in html format so it was ignored by alsa-devel ML distributor) > > i recently got a TerraTec DMX 6Fire USB. Since it's not supported by alsa, I decided to look into communications between the windows driver and the card. Here is the result. > > What should be revised: > - I was unsure about naming conventions, so please check the name of card/midi/pcm/module. > - Also the device needs firmware to be able to run, so I included the firmware from the windows driver in the attachment. I read about that Linus Torvalds doesn't like .ihex-parsing in drivers, but I cannot convert the files easily into a binary format because the offsets are not contiguous. Of course there could be alternate ways to be thought about, which would imply that original files from TT are not supported since they are in ihex. > - I didn't manage to create a configuration in /usr/share/alsa/cards. > > What is working: Everything except SPDIF > - Hardware Master volume > - PCM 44-192kHz@24 bits, 6 channels out, 4 channels in (analog) > - MIDI in/out > - firmware loading for coldplugged devices > - phono/line switching > > If anything else comes to your attention, just let me know. Sorry for the late reply. It took some time until I have free slot. First off, there are lots of coding-style issues to be fixed. Try to run scripts/checkpatch.pl once with your patch. Not all warnings have to be fixed (e.g. 80-chars) but would be nice if fixed. Here are some review comments through a very quirk glance: > +static int __devinit probe(struct usb_interface *intf, const struct usb_device_id *usb_id) Adding a short prefix (e.g. usb6fire_probe()) is better in general. Otherwise the stack trace would be difficult to read. Of course, too long names are also annoying, so it's a matter of taste. ... > + chip = (struct sfire_chip*)card->private_data; You can avoid cast here. > + chips[regidx] = chip; > + chip->dev = device; > + chip->regidx = regidx; > + chip->intf_count = 1; > + chip->card = card; > + chip->shutdown = FALSE; > + chip->midi = NULL; > + chip->comm = NULL; > + chip->control = NULL; > + chip->pcm = NULL; NULLs are automatically filled, so these can be skipped. > + ret = snd_usb_6fire_comm_init(chip); > + if(ret < 0) > + { > + snd_card_free(card); > + return ret; > + } > + > + ret = snd_usb_6fire_midi_init(chip); > + if(ret < 0) > + { > + snd_usb_6fire_comm_destroy(chip); > + snd_card_free(card); > + return ret; > + } > + > + ret = snd_usb_6fire_pcm_init(chip); > + if(ret < 0) > + { > + snd_usb_6fire_midi_destroy(chip); > + snd_usb_6fire_comm_destroy(chip); > + snd_card_free(card); > + return ret; > + } > + > + ret = snd_usb_6fire_control_init(chip); > + if(ret < 0) > + { > + snd_usb_6fire_pcm_destroy(chip); > + snd_usb_6fire_midi_destroy(chip); > + snd_usb_6fire_comm_destroy(chip); > + snd_card_free(card); > + return ret; > + } > + > + ret = snd_card_register(card); > + if(ret < 0) > + { > + snd_usb_6fire_pcm_destroy(chip); > + snd_usb_6fire_midi_destroy(chip); > + snd_usb_6fire_comm_destroy(chip); > + snd_usb_6fire_control_destroy(chip); > + snd_card_free(card); A general way for error-handling is either using goto or using a common destructor. In either way, you can call the *_free or *_destroy with the non-NULL check of each instance. It's a cleaner in general. > +static void disconnect(struct usb_interface *intf) > +{ > + struct sfire_chip *chip; > + struct snd_card *card; > + > + chip = usb_get_intfdata(intf); > + if(chip) //if !chip, fw upload has been performed so that we don't have a chip. > + { > + card = chip->card; > + chip->intf_count--; > + if (chip->intf_count == 0) > + { > + chip->shutdown = TRUE; > + snd_card_disconnect(card); > + snd_usb_6fire_comm_destroy(chip); > + snd_usb_6fire_control_destroy(chip); > + snd_usb_6fire_pcm_destroy(chip); > + snd_usb_6fire_midi_destroy(chip); > + snd_card_free(card); > + usb_set_intfdata(intf, NULL); The same destructor as in probe can be used here. > +static struct usb_device_id device_table[] = > +{ > + { > + .match_flags = USB_DEVICE_ID_MATCH_DEVICE, > + .idVendor = 0x0ccd, > + .idProduct = 0x0080 > + }, > + { } > +}; Usually MODULE_DEVICE_TABLE() follows just after the definition. > diff -Nur a/sound/usb/6fire/chip.h b/sound/usb/6fire/chip.h > --- a/sound/usb/6fire/chip.h 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/chip.h 2011-01-18 13:58:06.000000000 +0100 > @@ -0,0 +1,30 @@ > +/* > + * Linux driver for TerraTec DMX 6Fire USB > + * > + * Author: Torsten Schenk > + * Created: Jan 01, 2011 > + * Copyright: (C) Torsten Schenk > + * > + * 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. > + */ > +#pragma once Don't use prgram. Also, add #ifdef xxx for protecting the double inclusion. > +#include "common.h" > + > +struct sfire_chip > +{ > + struct usb_device *dev; > + struct snd_card *card; > + int intf_count; //number of registered interfaces > + int regidx; //index in module parameter arrays > + BOOL shutdown; Don't use own bool type. Use the generic "bool" type, and use true/false instead of TRUE/FALSE (unless the size really matters). > diff -Nur a/sound/usb/6fire/comm.c b/sound/usb/6fire/comm.c > --- a/sound/usb/6fire/comm.c 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/comm.c 2011-01-18 13:58:21.000000000 +0100 ... > +static int write_02(struct comm_runtime *rt, __u8 reg, __u16 value) Use u8 and u16. > diff -Nur a/sound/usb/6fire/comm.h b/sound/usb/6fire/comm.h > --- a/sound/usb/6fire/comm.h 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/comm.h 2011-01-18 13:58:29.000000000 +0100 > @@ -0,0 +1,42 @@ > +/* > + * Linux driver for TerraTec DMX 6Fire USB > + * > + * Author: Torsten Schenk > + * Created: Jan 01, 2011 > + * Copyright: (C) Torsten Schenk > + * > + * 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. > + */ > + > +#pragma once Ditto. No pragma and add ifdef. > diff -Nur a/sound/usb/6fire/common.h b/sound/usb/6fire/common.h > --- a/sound/usb/6fire/common.h 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/common.h 2011-01-18 13:58:38.000000000 +0100 > +#pragma once > + > +#include <linux/slab.h> > +#include <linux/usb.h> > +#include <sound/core.h> > + > +#define BOOL char > +#define TRUE 1 > +#define FALSE 0 Don't use these. > +#define MIN(X, Y) ((X) < (Y) ? (X) : (Y)) > +#define MAX(X, Y) ((X) > (Y) ? (X) : (Y)) Use standard min() / max() macros. > +#define ERR KERN_ERR "6fire: " > +#define WARNING KERN_WARNING "6fire: " Hmm... These are also better to be avoided. At most, define "6fire: " as PREFIX or PFX or whatever. But KERN_ERR should be put plainly. > diff -Nur a/sound/usb/6fire/control.c b/sound/usb/6fire/control.c > --- a/sound/usb/6fire/control.c 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/control.c 2011-01-18 13:58:57.000000000 +0100 > diff -Nur a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c > --- a/sound/usb/6fire/firmware.c 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/firmware.c 2011-01-18 13:57:15.000000000 +0100 ... > +static inline int fpga_write(struct usb_device *device, char *data, int len) Avoid inline unless you really need it. Also add MODULE_FIRMWARE() definitions in this file. > diff -Nur a/sound/usb/6fire/Makefile b/sound/usb/6fire/Makefile > --- a/sound/usb/6fire/Makefile 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/Makefile 2011-01-16 23:14:22.000000000 +0100 > @@ -0,0 +1,13 @@ > +obj-m += snd-usb-6fire.o > +snd-usb-6fire-objs += chip.o comm.o midi.o control.o firmware.o pcm.o > + > +all: > + make CONFIG_DEBUG_SECTION_MISMATCH=y -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules > + > +clean: > + make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean > + > +install: > + mkdir -p /lib/modules/$(shell uname -r)/extras > + cp snd-usb-6fire.ko /lib/modules/$(shell uname -r)/extras Remove all, clean, install things. > diff -Nur a/sound/usb/6fire/pcm.c b/sound/usb/6fire/pcm.c > --- a/sound/usb/6fire/pcm.c 1970-01-01 01:00:00.000000000 +0100 > +++ b/sound/usb/6fire/pcm.c 2011-01-18 13:59:57.000000000 +0100 > diff -Nur a/sound/usb/Kconfig b/sound/usb/Kconfig > --- a/sound/usb/Kconfig 2011-01-16 23:20:41.000000000 +0100 > +++ b/sound/usb/Kconfig 2011-01-16 23:14:22.000000000 +0100 > @@ -32,6 +32,17 @@ > To compile this driver as a module, choose M here: the module > will be called snd-ua101. > +config SND_USB_6FIRE > + tristate "TerraTec DMX 6Fire USB" > + depends on X86 > + select SND_HWDEP Do you really need hwdep? Rather select FW_LOADER, if any. > + select SND_PCM Missing SND_RAWMIDI dependency. > @@ -65,7 +76,6 @@ > * Native Instruments Guitar Rig Session I/O > * Native Instruments Guitar Rig mobile > * Native Instruments Traktor Kontrol X1 > - * Native Instruments Traktor Kontrol S4 > To compile this driver as a module, choose M here: the module > will be called snd-usb-caiaq. > @@ -83,7 +93,6 @@ > * Native Instruments Kore Controller > * Native Instruments Kore Controller 2 > * Native Instruments Audio Kontrol 1 > - * Native Instruments Traktor Kontrol S4 Don't bother others ;) thanks, Takashi

2 20

Re: [alsa-devel] linux-next: Tree for May 23 (sound/soc/codecs)
by Randy Dunlap 16 Jun '11

16 Jun '11

On Mon, 23 May 2011 15:45:18 +1000 Stephen Rothwell wrote: > Hi all, > > Changes since 20110520: when CONFIG_GPIOLIB is not enabled and CONFIG_GENERIC_GPIO is not enabled: sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function) sound/soc/codecs/wm8915.c:2857: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***

5 26