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

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

[alsa-devel] hda-intel missing mixer channels
by Orm Finnendahl 26 Aug '13

26 Aug '13

Hi, I sent this to alsa-user a week ago but didn't get any reply. Does anybody know, what is responsible for the missing faders? Did the driver change or is it some module loading mechanism in the distro which prevents the faders from showing up in alsamixer? This is so strange. Please help! -- Orm -------------------------------------------------------------------- Hi everybody, after the last update of Ubuntu (intrepid to jaunty) on my Lenovo Ideapad my microphone input doesn't work anymore (neither internal nor external). I found out that alsamixer lacks quite a lot of faders in the newer kernel/module compared to the older one. Some of the faders now unavailable were crucial for Mic input to work on the older system so I'd very much like to get them back ;-) Some more infos: Soundcard: Intel 82801G (ICH7 Family) Chip: Realtek ALC269 Module: snd_hda_intel (in both kernels) Older kernel: Ubuntu stock 2.6.27-14-generic Newer kernel: Ubuntu stock 2.6.28-13-rt Is there any way to make the missing controls available or did the driver change and I have to compile the older driver for the new kernel? Yours, Orm

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

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] Conexant CX20561 - Microphone problems
by Shawn Starr 19 Apr '11

19 Apr '11

Hello ALSA developers, I am having problems with the microphone on the following hardware this is on a Lenovo W500 laptop. Card: HDA Intel Chip: Conexant CX20561 (Hermosa) Here is the problems im noticing: 1) If I use ALSA 'default' with the microphone I get noise interference on output [high/low/high/low]. If I switch this to use the "ALSA Capture on HDA Intel [CONEXANT Analog] I get interference except it is the standard 60Hz electrical noise [steady noise] 2) Using the internal/external microphones gives an inconsistent volume. It also does not seem to work with the microphone cutting out so much. I need to adjust Digital + another microphone but it still drops capturing. Alsamixer shows: Digital/Docking Microphone/External Microphone/Internal Microphone Here is the module options I give to the sound driver: options snd-intel-hda enable_msi=1 power_save=10 power_save_controller=true model=laptop index=0 Assuming power saving/controller causes the microphone to cut out or not. 3) I'm now aware that this card has no pinouts for PCM capture https://bugzilla.redhat.com/show_bug.cgi?id=502293 Thanks for any help, Shawn.

2 12

[alsa-devel] CA0110 taints kernel
by Vedran Miletić 13 Apr '11

13 Apr '11

Hi, I experience frequent kernel crashes with 2.6.31 and CA0110. I know this card doesn't work, and there is no problem with that; however, it crashing non-stop is not very nice. Also, card doesn't get any controls (and I believe it does get some controls when it's the only card using HDA driver, that is when I disable onboard one). dmesg is here: http://pastebin.com/m7c53562f lspci: 02:00.0 PCI bridge: Creative Labs Device 7006 (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=64 Memory behind bridge: fe900000-fe9fffff Capabilities: [50] Power Management version 3 Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [80] Subsystem: Creative Labs Device 0010 Capabilities: [90] Express PCI/PCI-X Bridge, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel modules: shpchp 03:00.0 Audio device: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG Subsystem: Creative Labs Device 0018 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fe9fc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [dc] Power Management version 3 Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Any ideas? -- Vedran Miletić P.S. Please CC me, as I'm not subscribed to mailing list at the moment.

2 2

[alsa-devel] some questions about sound system
by loody 17 Mar '11

17 Mar '11

Dear all: I just install Ubuntu9.10 on my laptop and I try to update my sound system and recompile the utility. there are some questions I met: 1. when configure the utility it says checking panel.h presence... no checking for panel.h... no configure: error: required curses helper header not found and config.log is "conftest.c:10:42: error: CoreFoundation/CFPreferences.h: No such file or directory conftest.c: In function 'main': conftest.c:14: error: 'NULL' undeclared (first use in this function) conftest.c:14: error: (Each undeclared identifier is repor" the above error seems I miss install some package before. I google the name but I have no improvement. "conftest.c:20:28: error: ac_nonexistent.h: No such file or directory configure:7397: $? = 1" the above error seems the header located where the conftest.c doesn't expect. how could solve them all? 2. there are some configure file in share when I compile advance linux sound architecture. like alsa.conf. have anyone know where I can find the naming rule? appreciate your help, miloody

4 7

[alsa-devel] idt STAC927x adat supported (sigmatel HDA codec) ?
by Eric 03 Mar '11

03 Mar '11

Is the ADAT output of the IDT (sigmatel) STAC927x HDA codec supported in alsa ? If not could someone please try to add this incredibly nice feature in the existing alsa driver ? Thank you very much

4 13

[alsa-devel] [PATCH 1/2] ARM: S5PV210: Add audio support to Aquila
by Chanwoo Choi 30 Sep '10

30 Sep '10

This patch the I2C board information for the WM8994 used in the Aquila as audio codec and adds the I2C/I2S platform drivers. Additionlly, to control power consumption have registerd the voltage consumer of WM8994 to the regulator framework. I initialize gpio settting relevant to operation of audio codec. I explain following comment concering gpio setting: - CODEC_XTAL_EN : This gpio enables that the main clock is provided to operate audio codec. - MICBIAS_EN : This gpio enable the microphone to input analog - ADC_EN : This gpio enable the ADC device which is used to detect the kind of jack. (SND_JACK_HEADPHONE/HEADSET/MECHANICAL/AVOUT) According to the kind of jack, an electric current is changed. Signed-off-by : Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by : Joonyoung Shim <jy0922.shim(a)samsung.com> Signed-off-by : Kyungmin Park <kyungmin.park(a)samsung.com> --- arch/arm/mach-s5pv210/mach-aquila.c | 177 +++++++++++++++++++++++++++++++++++ 1 files changed, 177 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s5pv210/mach-aquila.c b/arch/arm/mach-s5pv210/mach-aquila.c index f0f960f..d027f9d 100644 --- a/arch/arm/mach-s5pv210/mach-aquila.c +++ b/arch/arm/mach-s5pv210/mach-aquila.c @@ -17,9 +17,11 @@ #include <linux/i2c-gpio.h> #include <linux/i2c/mcs.h> #include <linux/mfd/max8998.h> +#include <linux/mfd/wm8994/pdata.h> #include <linux/gpio_keys.h> #include <linux/input.h> #include <linux/gpio.h> +#include <linux/regulator/fixed.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> @@ -397,6 +399,120 @@ static struct max8998_platform_data aquila_max8998_pdata = { }; #endif +static struct regulator_consumer_supply wm8994_fixed_voltage0_supplies[] = { + { + .dev_name = "5-001a", + .supply = "DBVDD", + }, { + .dev_name = "5-001a", + .supply = "AVDD2", + }, { + .dev_name = "5-001a", + .supply = "CPVDD", + }, + +}; + +static struct regulator_consumer_supply wm8994_fixed_voltage1_supplies[] = { + { + .dev_name = "5-001a", + .supply = "SPKVDD1", + }, { + .dev_name = "5-001a", + .supply = "SPKVDD2", + }, +}; + +static struct regulator_init_data wm8994_fixed_voltage0_init_data = { + .constraints = { + .always_on = 1, + }, + .num_consumer_supplies = ARRAY_SIZE(wm8994_fixed_voltage0_supplies), + .consumer_supplies = wm8994_fixed_voltage0_supplies, +}; + +static struct regulator_init_data wm8994_fixed_voltage1_init_data = { + .constraints = { + .always_on = 1, + }, + .num_consumer_supplies = ARRAY_SIZE(wm8994_fixed_voltage1_supplies), + .consumer_supplies = wm8994_fixed_voltage1_supplies, +}; + +static struct fixed_voltage_config wm8994_fixed_voltage0_config = { + .supply_name = "VCC_1.8V_PDA", + .microvolts = 1800000, + .gpio = -EINVAL, + .init_data = &wm8994_fixed_voltage0_init_data, +}; + +static struct fixed_voltage_config wm8994_fixed_voltage1_config = { + .supply_name = "V_BAT", + .microvolts = 3700000, + .gpio = -EINVAL, + .init_data = &wm8994_fixed_voltage1_init_data, +}; + +static struct platform_device wm8994_fixed_voltage0 = { + .name = "reg-fixed-voltage", + .id = 0, + .dev = { + .platform_data = &wm8994_fixed_voltage0_config, + }, +}; + +static struct platform_device wm8994_fixed_voltage1 = { + .name = "reg-fixed-voltage", + .id = 1, + .dev = { + .platform_data = &wm8994_fixed_voltage1_config, + }, +}; + +static struct regulator_consumer_supply wm8994_avdd1_supply = { + .dev_name = "5-001a", + .supply = "AVDD1", +}; + +static struct regulator_consumer_supply wm8994_dcvdd_supply = { + .dev_name = "5-001a", + .supply = "DCVDD", +}; + +static struct regulator_init_data wm8994_ldo1_data = { + .constraints = { + .name = "AVDD1_3.0V", + .valid_ops_mask = REGULATOR_CHANGE_STATUS, + }, + .num_consumer_supplies = 1, + .consumer_supplies = &wm8994_avdd1_supply, +}; + +static struct regulator_init_data wm8994_ldo2_data = { + .constraints = { + .name = "DCVDD_1.0V", + }, + .num_consumer_supplies = 1, + .consumer_supplies = &wm8994_dcvdd_supply, +}; + +static struct wm8994_pdata wm8994_platform_data = { + /* configure gpio1 function: 0x0001(Logic level input/output) */ + .gpio_defaults[0] = 0x0001, + /* configure gpio3/4/5/7 function for AIF2 voice */ + .gpio_defaults[2] = 0x8100, + .gpio_defaults[3] = 0x8100, + .gpio_defaults[4] = 0x8100, + .gpio_defaults[6] = 0x0100, + /* configure gpio8/9/10/11 function for AIF3 BT */ + .gpio_defaults[7] = 0x8100, + .gpio_defaults[8] = 0x0100, + .gpio_defaults[9] = 0x0100, + .gpio_defaults[10] = 0x0100, + .ldo[0] = { S5PV210_MP03(6), NULL, &wm8994_ldo1_data }, /* XM0FRNB_2 */ + .ldo[1] = { 0, NULL, &wm8994_ldo2_data }, +}; + /* GPIO I2C PMIC */ #define AP_I2C_GPIO_PMIC_BUS_4 4 static struct i2c_gpio_platform_data aquila_i2c_gpio_pmic_data = { @@ -422,6 +538,58 @@ static struct i2c_board_info i2c_gpio_pmic_devs[] __initdata = { #endif }; +/* GPIO I2C AP 1.8V */ +#define AP_I2C_GPIO_BUS_5 5 +static struct i2c_gpio_platform_data i2c_gpio5_data = { + .sda_pin = S5PV210_MP05(3), /* XM0ADDR_11 */ + .scl_pin = S5PV210_MP05(2), /* XM0ADDR_10 */ +}; + +static struct platform_device i2c_gpio5 = { + .name = "i2c-gpio", + .id = AP_I2C_GPIO_BUS_5, + .dev = { + .platform_data = &i2c_gpio5_data, + }, +}; + +static struct i2c_board_info i2c_gpio5_devs[] __initdata = { + { + /* CS/ADDR = low 0x34 (FYI: high = 0x36) */ + I2C_BOARD_INFO("wm8994", 0x34 >> 1), + .platform_data = &wm8994_platform_data, + }, +}; + +static void __init aquila_sound_init(void) +{ + unsigned int gpio; + + /* CODEC_XTAL_EN */ + gpio = S5PV210_GPH3(2); /* XEINT_26 */ + gpio_request(gpio, "CODEC_XTAL_EN"); + s3c_gpio_cfgpin(gpio, S3C_GPIO_OUTPUT); + s3c_gpio_setpull(gpio, S3C_GPIO_PULL_NONE); + gpio_direction_output(gpio, 1); + + /* CLKOUT[9:8] set to 0x3(XUSBXTI) of 0xE010E000(OTHERS) + * for 24MHZ + */ + writel(readl(S5P_OTHERS) | (0x3 << 8), S5P_OTHERS); + + /* MICBIAS_EN */ + gpio = S5PV210_GPJ4(2); /* XMSMRN */ + gpio_request(gpio, "MICBIAS_EN"); + s3c_gpio_cfgpin(gpio, S3C_GPIO_OUTPUT); + gpio_direction_output(gpio, 1); + + /* ADC_EN */ + gpio = S5PV210_GPJ3(2); + gpio_request(gpio, "ADC_EN"); + s3c_gpio_cfgpin(gpio, S3C_GPIO_OUTPUT); + gpio_direction_output(gpio, 1); +} + /* PMIC Power button */ static struct gpio_keys_button aquila_gpio_keys_table[] = { { @@ -523,6 +691,10 @@ static struct platform_device *aquila_devices[] __initdata = { &s5pc110_device_onenand, &samsung_device_keypad, &i2c_gpio10, + &wm8994_fixed_voltage0, + &wm8994_fixed_voltage1, + &s5pv210_device_iis0, + &i2c_gpio5, }; static void __init aquila_map_io(void) @@ -539,6 +711,11 @@ static void __init aquila_machine_init(void) i2c_register_board_info(AP_I2C_GPIO_PMIC_BUS_4, i2c_gpio_pmic_devs, ARRAY_SIZE(i2c_gpio_pmic_devs)); + /* SOUND */ + i2c_register_board_info(AP_I2C_GPIO_BUS_5, i2c_gpio5_devs, + ARRAY_SIZE(i2c_gpio5_devs)); + aquila_sound_init(); + /* FB */ s3c_fb_set_platdata(&aquila_lcd_pdata); -- 1.6.3.3

5 10

[alsa-devel] davinci-i2c,pcm updates
by Troy Kisky 27 Sep '10

27 Sep '10

This patch set is against git://git.alsa-project.org/alsa-kernel.git but the last patch in series won't compile until the sram allocator patch is available.

8 44