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

[alsa-devel] [PATCH] ASoC: Fix build error in sound/soc/kirkwood/kirkwood-i2s.c
by Axel Lin 28 Dec '11

28 Dec '11

Since commit db33f4de "ARM: Orion: Remove address map info from all platform data structures", the dram is removed from struct kirkwood_asoc_platform_data. This patch fixes below build error: CC sound/soc/kirkwood/kirkwood-i2s.o sound/soc/kirkwood/kirkwood-i2s.c: In function 'kirkwood_i2s_dev_probe': sound/soc/kirkwood/kirkwood-i2s.c:444: error: 'struct kirkwood_asoc_platform_data' has no member named 'dram' sound/soc/kirkwood/kirkwood-i2s.c:450: error: 'struct kirkwood_asoc_platform_data' has no member named 'dram' make[3]: *** [sound/soc/kirkwood/kirkwood-i2s.o] Error 1 make[2]: *** [sound/soc/kirkwood] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin(a)gmail.com> Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: Nicolas Pitre <nico(a)fluxnic.net> --- This patch is against linux-next tree. sound/soc/kirkwood/kirkwood-i2s.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c index f6bb211..3cb9aa4 100644 --- a/sound/soc/kirkwood/kirkwood-i2s.c +++ b/sound/soc/kirkwood/kirkwood-i2s.c @@ -441,13 +441,12 @@ static __devinit int kirkwood_i2s_dev_probe(struct platform_device *pdev) goto err_ioremap; } - if (!data || !data->dram) { + if (!data) { dev_err(&pdev->dev, "no platform data ?!\n"); err = -EINVAL; goto err_ioremap; } - priv->dram = data->dram; priv->burst = data->burst; return snd_soc_register_dai(&pdev->dev, &kirkwood_i2s_dai); -- 1.7.5.4

1 0

Re: [alsa-devel] [PATCH 3/3 v2] sound/soc/lapis: add platform driver for ML7213 IOH I2S
by Mark Brown 27 Dec '11

27 Dec '11

On Tue, Dec 20, 2011 at 11:45:44AM +0900, Tomoya MORINAGA wrote: > +static int ignore_overrun = 1; > +module_param(ignore_overrun, int, 0444); > +MODULE_PARM_DESC(ignore_overrun, "ignore RX overruns (default=0)"); This shouldn't be a driver specific thing, and if we were to have such a feature a module parameter doesn't seem like a great way of doing it. > +/***************************************************************************** > + * I2S HAL (Hardware Abstruction Layer) > + *****************************************************************************/ Please follow the kernel coding style in terms of comments. > +static void ioh_i2s_enable_interrupts(int ch, enum dma_data_direction dir) > +{ > + unsigned int intr_lines; > + > + if (dir) > + intr_lines = 1 << (I2S_IMASK_RX_BIT_START + ch); > + > + else > + intr_lines = 1 << (I2S_IMASK_TX_BIT_START + ch); I'd expect a switch statement corresponding to the enum, not an if statement. > +static void ioh_i2s_disable_interrupts(int ch, enum dma_data_direction dir) > +{ > + unsigned int intr_lines; > + > + /*intr_lines&=I2S_ALL_INTERRUPT_BITS; */ > + intr_lines = ioread32(i2s_data->iobase + I2SIMASK_OFFSET); What's this commented out code for? Also as a coding style thing you should have a space between /* and the text in the comment (this applies throughout the driver). > + /*disable interrupts for specified channel */ > + if (dir) > + intr_lines |= 1 << (I2S_IMASK_RX_BIT_START + ch); > + else > + intr_lines |= 1 << (I2S_IMASK_TX_BIT_START + ch); > + > + /*Mask the specific interrupt bits */ > + iowrite32(intr_lines, i2s_data->iobase + I2SIMASK_OFFSET); What ensures that this read/modify/write cycle can't race with another caller? > +/* Clear interrupt status */ > +static void ioh_i2s_clear_tx_sts_ir(int ch) > +{ > + int offset = ch * 0x800; > + > + iowrite32(I2S_TX_FINT | I2S_TX_AFINT | I2S_TX_EINT | I2S_TX_AEINT, > + i2s_data->iobase + I2SISTTX_OFFSET + offset); > +} This appears to unconditionally acknowledge all interrupts, generally you should only acknowledge interrupts that have been handled. Otherwise it's possible that interrupts may be dropped if they're flagged between the status read and acknowledgement write. > +/***************************************************************************** > + * I2S Middle ware > + *****************************************************************************/ I'm really not convinced of the value of these layers, reading the code it really feels incredibly verbose in comparison with what I'd expect from such a driver and I can't help that think that a lot of this verbosity is down to muddling through these abstraction layers. > +static bool filter(struct dma_chan *chan, void *slave) This needs a better name. It's not namespaced and it's not clear what it's filtering. > +static struct dma_chan *ioh_request_dma_channel( > + int ch, struct ioh_i2s_dma *dma, enum dma_data_direction dir) > +{ > + dma_cap_mask_t mask; > + struct dma_chan *chan; > + struct pci_dev *dma_dev; > + dma_cap_zero(mask); > + dma_cap_set(DMA_SLAVE, mask); > + > + dma_dev = pci_get_bus_and_slot(2, PCI_DEVFN(0, 1)); /* Get DMA's dev > + information */ > + > + if (dir == DMA_FROM_DEVICE) { /* Rx */ switch statement to select between multiple options in the enum. This applies throughout the code. > +static void > +ioh_i2s_write(struct snd_pcm_substream *substream, const void *data, int len) > +{ > + int rem1; > + int rem2; What is this supposed to do? There's an awful lot of it, and it looks like it's supposed to be rewriting the data format for some reason which isn't something that a driver ought to be doing (apart from anything else it does rather defeat the point of DMA). > +static void ioh_i2s_configure_i2s_regs(int ch, enum ioh_direction dir) > +{ > + int offset = ch * 0x800; You should have a function to map the channel into a number. > + > + if (dir) { > + /* Rx register */ > + iowrite32(I2S_AFULL_THRESH / 2, > + i2s_data->iobase + I2SAFRX_OFFSET + offset); > + iowrite32(0x1F, i2s_data->iobase + I2SAERX_OFFSET + offset); > + iowrite32(0x1F, i2s_data->iobase + I2SMSKRX_OFFSET + offset); > + iowrite32(0xC, i2s_data->iobase + I2SISTRX_OFFSET + offset); Lots of magic numbers here and given that the function is called just "configure" it's not clear what the intended purpose is. This needs to be clarified. > + /* Rx configuration */ > + if (atomic_read(&dma->rx_busy)) { > + dev_err(i2s_data->dev, "rx i2s%dalready opened\n", ch); ... > + } else { > + /* Tx configuration */ > + if (atomic_read(&dma->tx_busy)) { There's a *lot* of duplicate code in the driver for TX and RX, it should be possible to abstract out much more common code. > +static void i2s_tx_almost_empty_ir(int ch) > +{ > + struct dma_async_tx_descriptor *desc; > + int num; > + int tx_comp_index; > + struct ioh_i2s_dma *dma = &dmadata[ch]; > + struct scatterlist *sg = dma->sg_tx_p; > + void *cb_ch; > + > + dev_dbg(i2s_data->dev, "%s: data_head=%p data_complete=%p\n", __func__, > + dma->tx_data_head, dma->tx_complete); > + > + num = ((int)dma->tx_avail) / (I2S_AEMPTY_THRESH * 4); That case looks *very* suspect. > + tx_comp_index = (((int)(dma->tx_complete - dma->tx_head))) /\ > + (I2S_AEMPTY_THRESH * 4); There is very rarely any need for line continuations outside of macros. > +static inline void ioh_i2s_interrupt_sub_tx(int ch) > +{ > + unsigned int status; > + int offset = ch * 0x800; > + > + status = ioread32(i2s_data->iobase + I2SISTTX_OFFSET + offset); > + if (status & I2S_TX_EINT) > + i2s_tx_empty_ir(ch); > + if (status & I2S_TX_AEINT) > + i2s_tx_almost_empty_ir(ch); Given that all you're doing is logging just open code the log message. > + default: > + return -1; Return error codes, you EPERM almost certainly isn't the error you meant to report. > +static int ioh_i2s_pci_suspend(struct pci_dev *pdev, pm_message_t state) > +{ > + int ret; > + > + ioh_i2s_save_reg_conf(pdev); You should be doing this in ASoC suspend/resume callbacks, not in PCI ones.

2 8

[alsa-devel] [PATCH 0/4] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
by Janusz Krzysztofik 27 Dec '11

27 Dec '11

The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. Janusz Krzysztofik (4): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ASoC: cx20442: add bias control over a platform provided regulator ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig | 2 + arch/arm/mach-omap1/board-ams-delta.c | 116 +++++++++++++++++++-- arch/arm/plat-omap/include/plat/board-ams-delta.h | 1 - sound/soc/codecs/cx20442.c | 58 ++++++++++- sound/soc/omap/ams-delta.c | 34 ------ 5 files changed, 165 insertions(+), 46 deletions(-) -- 1.7.3.4

2 12

[alsa-devel] Driver Soudcard/Midi BCD2000 Behringer
by William Martins 27 Dec '11

27 Dec '11

Good evening Messrs. Developers, at times I'm trying to make this device work in linux (Behringer BCD2000-), without success, that happens a few days I discovered that the manufacturer built the same non-standard midi, so it is not recognized by the kernel as a midi device. I realized that there is a need to build a drive for him, I am not a developer to develop it, the more I have some idea, after some research, that this site will find it a Sr, can develop it for mac, and made available on its website http : / / evinyatar.ath.cx / sphpblog / static.php? page = bcd2ktech some codes to serve as instruction for those who want to develop. Come and ask that if possible, you develop the driver for this device because the community waits anxiously for the same support. I look back. Thank you! William R. Martins IT Consultant / Support Specialist Tels: (98) 8197-3909 / 8884-9517

2 1

Re: [alsa-devel] [PATCH] ASoC: Allocate PCM operations dynamically to support multiple DAIs
by Sangsu Park 27 Dec '11

27 Dec '11

> This looks wrong. It will probably cause regression for all non ASoC sound > card drivers. > > The issue this patch addresses came up before and I think the conclusion was > that it is best to embed the snd_pcm_ops struct into the snd_soc_pcm_runtime > struct. Hi, I'm Sangsu Park. (sangsu4u.park(a)samsung.com) I'm using gmail because of company's firewall problems... I agree you, So I've changed some code like follows. If you like that, I'll make patch version 2nd using that. //------------------------------------------------------------------------------ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 42ad2db..d1468aa 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -918,6 +918,9 @@ static void soc_remove_dai_link(struct snd_soc_card *card, int num, int order) list_del(&cpu_dai->card_list); module_put(cpu_dai->dev->driver->owner); } + + /* free the ops memory */ + if (rtd->ops) kfree(rtd->ops); } diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 8aa7cec..4eb793b 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -641,22 +645,23 @@ int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num) INIT_DELAYED_WORK(&rtd->delayed_work, close_delayed_work); rtd->pcm = pcm; + rtd->ops = soc_pcm_ops; pcm->private_data = rtd; if (platform->driver->ops) { ------------------------------------------------------------------------------// Thanks.

2 1

Re: [alsa-devel] [PATCH] ASoC: Allocate PCM operations dynamically to support multiple DAIs
by Sangsu Park 27 Dec '11

27 Dec '11

> On Fri, Dec 23, 2011 at 10:37:51AM +0900, Sangbeom Kim wrote: > > > + soc_pcm_ops = kzalloc(sizeof(*soc_pcm_ops), GFP_KERNEL); > > + if (soc_pcm_ops == NULL) { > > + snd_printk(KERN_ERR "Cannot allocate PCM OPS\n"); > > + return -ENOMEM; > > + } > > This patch is good and fixes a real problem but can you please change it > slightly so that instead of dynamically allocating the soc_pcm_ops we > just embed it directly in the runtime structure. Since every runtime > needs an ops structure we may as well just have it embedded directly and > not write the allocation, freeing and error handling code. Hi, I'm Sangsu Park. (sangsu4u.park(a)samsung.com) I'm using gmail because of company's firewall problems... I've implement your guide like follows. //-------------------------------------------------------------------------------------------------------------------------------- struct snd_soc_dai *codec_dai = rtd->codec_dai; struct snd_soc_dai *cpu_dai = rtd->cpu_dai; + struct snd_pcm_ops *soc_pcm_ops = platform->driver->ops; struct snd_pcm *pcm; char new_name[64]; int ret = 0, playback = 0, capture = 0; if (playback) - snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &soc_pcm_ops); + snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, soc_pcm_ops); if (capture) - snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &soc_pcm_ops); + snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, soc_pcm_ops); --------------------------------------------------------------------------------------------------------------------------------// But, it seems to make mutex dead lock. When starting playback, it tells some messages. //-------------------------------------------------------------------------------------------------------------------------------- # aplay -twav Test.wav INFO: task aplay:1071 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. aplay D c01d1ba4 0 1071 1051 0x00000000 [<c01d1ba4>] (__schedule+0x244/0x6cc) from [<c01d2db0>] (__mutex_lock_slowpath+0x180/0x360) [<c01d2db0>] (__mutex_lock_slowpath+0x180/0x360) from [<c01d2f9c>] (mutex_lock+0xc/0x24) [<c01d2f9c>] (mutex_lock+0xc/0x24) from [<c01c10c4>] (soc_pcm_open+0x38/0x48c) [<c01c10c4>] (soc_pcm_open+0x38/0x48c) from [<c01c1114>] (soc_pcm_open+0x88/0x48c) [<c01c1114>] (soc_pcm_open+0x88/0x48c) from [<c01b0fcc>] (snd_pcm_open_substream+0x60/0xa0) [<c01b0fcc>] (snd_pcm_open_substream+0x60/0xa0) from [<c01b1134>] (snd_pcm_open+0x128/0x270) [<c01b1134>] (snd_pcm_open+0x128/0x270) from [<c01a4034>] (snd_open+0x130/0x2ec) [<c01a4034>] (snd_open+0x130/0x2ec) from [<c00b00e4>] (chrdev_open+0x10c/0x1f0) [<c00b00e4>] (chrdev_open+0x10c/0x1f0) from [<c00aad24>] (__dentry_open+0x220/0x328) [<c00aad24>] (__dentry_open+0x220/0x328) from [<c00aaef4>] (nameidata_to_filp+0x60/0x68) [<c00aaef4>] (nameidata_to_filp+0x60/0x68) from [<c00bb5d4>] (do_last+0x214/0xcc0) [<c00bb5d4>] (do_last+0x214/0xcc0) from [<c00bc13c>] (path_openat+0xbc/0x3a8) [<c00bc13c>] (path_openat+0xbc/0x3a8) from [<c00bc510>] (do_filp_open+0x30/0x84) [<c00bc510>] (do_filp_open+0x30/0x84) from [<c00aa954>] (do_sys_open+0xe4/0x184) [<c00aa954>] (do_sys_open+0xe4/0x184) from [<c000f3c0>] (ret_fast_syscall+0x0/0x30) --------------------------------------------------------------------------------------------------------------------------------// "sound/core/" uses soc_pcm_ops using substream->ops, and "sound/soc/" uses soc_pcm_ops using platform->driver->ops. So, I think that they must have their own soc_pcm_ops object. How do you think about this?

2 1

Re: [alsa-devel] [RFC] hda - is_jack_detectable()
by Raymond Yau 27 Dec '11

27 Dec '11

2011/11/14 Takashi Iwai <tiwai(a)suse.de>: > At Sat, 12 Nov 2011 19:31:20 +0800, > Raymond Yau wrote: >> >> 2011/11/9 Takashi Iwai <tiwai(a)suse.de>: >> > At Wed, 09 Nov 2011 08:08:17 +0100, >> > Takashi Iwai wrote: >> >> >> >> At Wed, 9 Nov 2011 12:06:04 +0800, >> >> Raymond Yau wrote: >> >> > >> >> > 2011/11/6 Takashi Iwai <tiwai(a)suse.de>: >> >> > > At Sat, 5 Nov 2011 13:30:21 +0800, >> >> > > Raymond Yau wrote: >> >> > >> >> >> > >> 2011/11/2 Takashi Iwai <tiwai(a)suse.de>: >> >> > >> > At Tue, 01 Nov 2011 17:03:29 -0400, >> >> > >> > David Henningsson wrote: >> >> > >> >> >> >> > >> >> 2011-10-24 23:31, Raymond Yau skrev: >> >> > >> >> > sorry, it should be >> >> > >> >> > >> >> > >> >> > static inline bool is_jack_detectable(struct hda_codec *codec, hda_nid_t nid) >> >> > >> >> > { >> >> > >> >> > return (snd_hda_query_pin_caps(codec, nid)& AC_PINCAP_PRES_DETECT)&& >> >> > >> >> > + !(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid) >> >> > >> >> > & AC_DEFCFG_MISC_NO_PRESENCE))&& >> >> > >> >> > (get_wcaps(codec, nid)& AC_WCAP_UNSOL_CAP); >> >> > >> >> > } >> >> > >> >> > >> >> > >> >> I also think it is a good idea, in fact I thought it was this way >> >> > >> >> already. Can we merge this patch? >> >> > >> > >> >> > >> > OK, I checked through alsa-info series and confirmed that this causes >> >> > >> > no harm, so I merged it now. >> >> > >> > >> >> > >> > >> >> > >> > thanks, >> >> > >> > >> >> > >> > Takashi >> >> > >> > >> >> > >> > >> >> > >> >> >> > >> Sorry the previous patch is wrong >> >> > > >> >> > > Ugh, so actually changing it would may bring too many changes, and >> >> > > most likely regressions, too. I disabled the code for now for 3.2-rc1. >> >> > > Once when we cover all test cases and fix broken BIOS devices enough, >> >> > > we can re-enable it in near future. >> >> > > >> >> > >> attach the patch and test cases (pins 0x11 and 0x14) front panel >> >> > >> green and pink jacks when set Front Audio Panel to AC97 or HD in BIOS >> >> > >> setup >> >> > > >> >> > > OK, thanks, we can refer to this for more tests. >> >> > > >> >> > > >> >> > > Takashi >> >> > > >> >> > >> >> > If bit 0 is set, it indicates that the jack has no presence detect capability >> >> > >> >> > >> >> > The Configuration Default register is defined as shown in Figure 66. >> >> > 31:30 29:24 23:20 19:16 15:12 11:8 >> >> > 7:4 3:0 >> >> > Port Location Default Connection Color Misc >> >> > Default Sequence >> >> > Connectivity Device Type Association >> >> > Figure 66. Configuration Data Structure >> >> > >> >> > >> >> > This mean that bit 0 of Misc is bit 8 of the Configuration Default register >> >> > >> >> > >> >> > !(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) >> >> > & AC_DEFCFG_MISC_NO_PRESENCE)&& >> >> > >> >> >> >> Yeah, I already tried it and it still gives too many false-positives. >> >> Many ASUS laptops (also mobo) set this bit to all pins no matter >> >> whether it's an obviously detectable jack or not. Some Toshiba >> >> laptops do so, too. >> >> >> >> That being said, checking this bit alone isn't reliable because of too >> >> many BIOS bugs. A bit more clever test is necessary. >> > >> > It seems that a broken BIOS sets this bit on all pins in general. >> > So, the patch below (against the latest sound git tree or 3.2-rc1 >> > kernel) seems working well by filtering out such a brokenness. >> > >> > Let me know if this works. If it's OK, I'll try to merge it for >> > 3.2-rc2. >> > >> >> The patch seem ok >> >> Need a hack to build the hda-jack branch >> >> It is quite simple to enable unsolicited event for all proper jacks by >> >> snd_hda_jack_add_kctrls(codec,(codec->spec->autocfg)); >> >> and >> >> static void ad1988_unsol_event(struct hda_codec *codec, unsigned int res) >> { >> struct ad198x_spec *spec = codec->spec; >> struct hda_jack_tbl *jack; >> u32 sense, caps; >> int pin; >> jack = snd_hda_jack_tbl_get_from_tag(codec, res >> 26); >> pin = jack->nid; >> caps = snd_hda_codec_get_pincfg(codec, pin); >> sense = snd_hda_codec_read(codec, pin, 0, AC_VERB_GET_PIN_SENSE, 0); >> if (sense & AC_PINSENSE_PRESENCE) >> snd_printdd("Pin 0x%x pd=1 imp=%d %s at %s %s %s\n", >> pin, >> sense & AC_PINSENSE_IMPEDANCE_MASK, >> snd_hda_get_jack_type(caps), >> snd_hda_get_jack_connectivity(caps), >> snd_hda_get_jack_location(caps), >> get_jack_color(caps)); >> else >> snd_printdd("Pin 0x%x pd=0 %s at %s %s %s\n", >> pin, >> snd_hda_get_jack_type(caps), >> snd_hda_get_jack_connectivity(caps), >> snd_hda_get_jack_location(caps), >> get_jack_color(caps)); >> >> if (pin == spec->autocfg.hp_pins[0] && !spec->independent_hp) >> ad198x_hp_automute(codec); >> if (pin == spec->ext_mic_pin) >> ad198x_mic_automute(codec); >> } >> >> >> However it seem that result is different in kctl >> >> >> amixer -c1 contents >> numid=5,iface=CARD,name='Front Headphone Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=6,iface=CARD,name='Front Mic Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=8,iface=CARD,name='Line Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=1,iface=CARD,name='Line-Out Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=2,iface=CARD,name='Line-Out Jack',index=1 >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=3,iface=CARD,name='Line-Out Jack',index=2 >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=4,iface=CARD,name='Line-Out Jack',index=3 >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=7,iface=CARD,name='Rear Mic Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> >> >> >> >> ./hda-jack-sense-test.py -c1 >> Pin 0x11 Green HP Out (Ext Front): Present = NO >> Pin 0x12 Green Line Out (Ext Rear): Present = YES Impedance = 19 >> Pin 0x14 Pink Mic (Ext Front): Present = NO >> Pin 0x15 Blue Line In (Ext Rear): Present = NO >> Pin 0x16 Black Line Out (Ext Rear): Present = YES Impedance = 3200 >> Pin 0x17 Pink Mic (Ext Rear): Present = YES Impedance = 896 >> Pin 0x18 Black CD (Int ATAPI): No jack detect capability >> Pin 0x1a Other (Int ATAPI): No jack detect capability >> Pin 0x1b Other SPDIF Out (Ext Rear): No jack detect capability >> Pin 0x24 Orange Line Out (Ext Rear): Present = NO >> Pin 0x25 Grey Line Out (Ext Rear): Present = YES Impedance = 3200 >> >> >> It need "SET_PIN_SENSE" and some delay to get the correct impedance >> of the jacks during driver load >> >> >> int snd_hda_jack_detect_enable(struct hda_codec *codec, hda_nid_t nid, >> unsigned char action) >> { >> + int ret; >> struct hda_jack_tbl *jack = snd_hda_jack_tbl_new(codec, nid); >> if (!jack) >> return -ENOMEM; >> if (jack->jack_detect) >> return 0; /* already registered */ >> jack->jack_detect = 1; >> if (action) >> jack->action = action; >> + ret = snd_hda_codec_write_cache(codec, nid, 0, >> + AC_VERB_SET_UNSOLICITED_ENABLE, >> + AC_USRSP_EN | jack->tag); >> + if (snd_hda_query_pin_caps(codec, nid) & AC_PINCAP_IMP_SENSE) { >> snd_hda_codec_read(codec, nid, 0, >> AC_VERB_SET_PIN_SENSE, 0); >> + msleep(200); >> + } >> + return ret; > > The lack of the initial pin-state of kclts was fixed in a different > patch now. But, the need of 200ms delay worries me whether it's > needed generically at each pin-sense reading or it's just only for the > initial reading. > > Does the pin-sense reading work in general after loading the driver > stably? > > > Presence detect bit is alway correct, without the delay. the only issue is the impedance measurement of the plugged jacks at computer boot need a delay 200ms For the user application to know the impedance , it seem the client application have to issue 1) set_pin_sense 2) delay 3) get_pin_sense to get the correct impedance of the attached device just like my modified hda-jack-sense-test in previous email Can it measure the impedance of the jacks of your computer ?

2 4

[alsa-devel] Capture from 3+ cards connected to a USB hub - distorted samples
by Pavel Hofman 26 Dec '11

26 Dec '11

Hi, I have been informed about the following problem which I was able to reproduce afterwards: * Latest git.alsa-project.org drivers * USB 2.0 hub, 3 or more USB soundcards (inexpensive USB sticks, USB audio v.1 types, async capture, adaptive playback) hooked to the hub, identified A, B, C, D. * NONE of these soundcards is playing back Now: * Card A begins microphone capturing (mono 48/16), result OK * Card B begins capturing (mono 48/16), both results still OK * As soon as the third card C begins capturing, the signal captured from cards A and B gets distorted. Audacity shows some samples are incorrect, distorting the expected sine waveform of the testing signal. I can provide screenshots as well as recorded samples, if needed. * The signal recorded from card C is OK. BUT * If any card hooked to the HUB is playing back (even a fourth one D), the distortion does not occur. It happens only when there is no playback stream going through the hub. Traffic on another USB port has no effect, in fact the test signal for the three cards was provided by a multichannel USB card hooked to another USB port. It seems to me as if blocks of samples for each card in the USB frame sometimes overlap by a few bits, corrupting the neighbouring card samples, or are recovered incorrectly. I understand I have provided no real data, I am ready to do so plus any tests you would consider useful. Thanks a lot for suggestions of the next debugging steps I should do. Regards, Pavel.

2 4

[alsa-devel] [PATCH v2] ASoC: jz4740: Convert qi_lb60 to use snd_soc_register_card()
by Axel Lin 26 Dec '11

26 Dec '11

Use snd_soc_register_card() instead of creating a "soc-audio" platform device. Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- v2: fix a typo in v1. Only compile tested, I appreciate if someone can test it. arch/mips/jz4740/board-qi_lb60.c | 6 ++++ sound/soc/jz4740/qi_lb60.c | 56 +++++++++++++++++-------------------- 2 files changed, 32 insertions(+), 30 deletions(-) diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c index 639e3ce..9a91fe9 100644 --- a/arch/mips/jz4740/board-qi_lb60.c +++ b/arch/mips/jz4740/board-qi_lb60.c @@ -418,6 +418,11 @@ static struct platform_device qi_lb60_charger_device = { }, }; +/* audio */ +static struct platform_device qi_lb60_audio_device = { + .name = "qi-lb60-audio", + .id = -1, +}; static struct platform_device *jz_platform_devices[] __initdata = { &jz4740_udc_device, @@ -434,6 +439,7 @@ static struct platform_device *jz_platform_devices[] __initdata = { &qi_lb60_gpio_keys, &qi_lb60_pwm_beeper, &qi_lb60_charger_device, + &qi_lb60_audio_device, }; static void __init board_gpio_setup(void) diff --git a/sound/soc/jz4740/qi_lb60.c b/sound/soc/jz4740/qi_lb60.c index 0097c3b..b29aa55 100644 --- a/sound/soc/jz4740/qi_lb60.c +++ b/sound/soc/jz4740/qi_lb60.c @@ -91,56 +91,52 @@ static struct snd_soc_card qi_lb60 = { .num_dapm_routes = ARRAY_SIZE(qi_lb60_routes), }; -static struct platform_device *qi_lb60_snd_device; - static const struct gpio qi_lb60_gpios[] = { { QI_LB60_SND_GPIO, GPIOF_OUT_INIT_LOW, "SND" }, { QI_LB60_AMP_GPIO, GPIOF_OUT_INIT_LOW, "AMP" }, }; -static int __init qi_lb60_init(void) +static int __devinit qi_lb60_probe(struct platform_device *pdev) { + struct snd_soc_card *card = &qi_lb60; int ret; - qi_lb60_snd_device = platform_device_alloc("soc-audio", -1); - - if (!qi_lb60_snd_device) - return -ENOMEM; - ret = gpio_request_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); - if (ret) { - pr_err("qi_lb60 snd: Failed to request gpios: %d\n", ret); - goto err_device_put; - } + if (ret) + return ret; - platform_set_drvdata(qi_lb60_snd_device, &qi_lb60); + card->dev = &pdev->dev; - ret = platform_device_add(qi_lb60_snd_device); + ret = snd_soc_register_card(card); if (ret) { - pr_err("qi_lb60 snd: Failed to add snd soc device: %d\n", ret); - goto err_unset_pdata; + dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n", + ret); + gpio_free_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); } - - return 0; - -err_unset_pdata: - platform_set_drvdata(qi_lb60_snd_device, NULL); -/*err_gpio_free_array:*/ - gpio_free_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); -err_device_put: - platform_device_put(qi_lb60_snd_device); - return ret; } -module_init(qi_lb60_init); -static void __exit qi_lb60_exit(void) +static int __devexit qi_lb60_remove(struct platform_device *pdev) { - platform_device_unregister(qi_lb60_snd_device); + struct snd_soc_card *card = platform_get_drvdata(pdev); + gpio_free_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); + snd_soc_unregister_card(card); + return 0; } -module_exit(qi_lb60_exit); + +static struct platform_driver qi_lb60_driver = { + .driver = { + .name = "qi-lb60-audio", + .owner = THIS_MODULE, + }, + .probe = qi_lb60_probe, + .remove = __devexit_p(qi_lb60_remove), +}; + +module_platform_driver(qi_lb60_driver); MODULE_AUTHOR("Lars-Peter Clausen <lars(a)metafoo.de>"); MODULE_DESCRIPTION("ALSA SoC QI LB60 Audio support"); MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:qi-lb60-audio"); -- 1.7.5.4

2 1

[alsa-devel] [PATCH] ASoC: jz4740: Convert qi_lb60 to use snd_soc_register_card()
by Axel Lin 24 Dec '11

24 Dec '11

Use snd_soc_register_card() instead of creating a "soc-audio" platform device. Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- arch/mips/jz4740/board-qi_lb60.c | 6 ++++ sound/soc/jz4740/qi_lb60.c | 57 ++++++++++++++++++-------------------- 2 files changed, 33 insertions(+), 30 deletions(-) diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c index 639e3ce..9a91fe9 100644 --- a/arch/mips/jz4740/board-qi_lb60.c +++ b/arch/mips/jz4740/board-qi_lb60.c @@ -418,6 +418,11 @@ static struct platform_device qi_lb60_charger_device = { }, }; +/* audio */ +static struct platform_device qi_lb60_audio_device = { + .name = "qi-lb60-audio", + .id = -1, +}; static struct platform_device *jz_platform_devices[] __initdata = { &jz4740_udc_device, @@ -434,6 +439,7 @@ static struct platform_device *jz_platform_devices[] __initdata = { &qi_lb60_gpio_keys, &qi_lb60_pwm_beeper, &qi_lb60_charger_device, + &qi_lb60_audio_device, }; static void __init board_gpio_setup(void) diff --git a/sound/soc/jz4740/qi_lb60.c b/sound/soc/jz4740/qi_lb60.c index 0097c3b..f152b81a7 100644 --- a/sound/soc/jz4740/qi_lb60.c +++ b/sound/soc/jz4740/qi_lb60.c @@ -91,56 +91,53 @@ static struct snd_soc_card qi_lb60 = { .num_dapm_routes = ARRAY_SIZE(qi_lb60_routes), }; -static struct platform_device *qi_lb60_snd_device; - static const struct gpio qi_lb60_gpios[] = { { QI_LB60_SND_GPIO, GPIOF_OUT_INIT_LOW, "SND" }, { QI_LB60_AMP_GPIO, GPIOF_OUT_INIT_LOW, "AMP" }, }; -static int __init qi_lb60_init(void) +static int __devinit qi_lb60_probe(struct platform_device *pdev) { + struct snd_soc_card *card = &qi_lb60; int ret; - qi_lb60_snd_device = platform_device_alloc("soc-audio", -1); - - if (!qi_lb60_snd_device) - return -ENOMEM; - ret = gpio_request_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); - if (ret) { - pr_err("qi_lb60 snd: Failed to request gpios: %d\n", ret); - goto err_device_put; - } + if (ret) + return ret; - platform_set_drvdata(qi_lb60_snd_device, &qi_lb60); + card->dev = &pdev->dev; - ret = platform_device_add(qi_lb60_snd_device); + ret = snd_soc_register_card(card); if (ret) { - pr_err("qi_lb60 snd: Failed to add snd soc device: %d\n", ret); - goto err_unset_pdata; + dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n", + ret); + gpio_free_array(qi_lb60_audio_gpios, + ARRAY_SIZE(qi_lb60_audio_gpios)); } - - return 0; - -err_unset_pdata: - platform_set_drvdata(qi_lb60_snd_device, NULL); -/*err_gpio_free_array:*/ - gpio_free_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); -err_device_put: - platform_device_put(qi_lb60_snd_device); - return ret; } -module_init(qi_lb60_init); -static void __exit qi_lb60_exit(void) +static int __devexit qi_lb60_remove(struct platform_device *pdev) { - platform_device_unregister(qi_lb60_snd_device); + struct snd_soc_card *card = platform_get_drvdata(pdev); + gpio_free_array(qi_lb60_gpios, ARRAY_SIZE(qi_lb60_gpios)); + snd_soc_unregister_card(card); + return 0; } -module_exit(qi_lb60_exit); + +static struct platform_driver qi_lb60_driver = { + .driver = { + .name = "qi-lb60-audio", + .owner = THIS_MODULE, + }, + .probe = qi_lb60_probe, + .remove = __devexit_p(qi_lb60_remove), +}; + +module_platform_driver(qi_lb60_driver); MODULE_AUTHOR("Lars-Peter Clausen <lars(a)metafoo.de>"); MODULE_DESCRIPTION("ALSA SoC QI LB60 Audio support"); MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:qi-lb60-audio"); -- 1.7.5.4

1 0