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

[alsa-devel] [PATCH 3.0]ASoC: ad193x: add spi_hw_read, fix sysclk and register definition
by Scott Jiang 11 Aug '11

11 Aug '11

asoc cache layer can't support this kind of spi registers, so bypass cache and read regiters directly Signed-off-by: Scott Jiang <scott.jiang.linux(a)gmail.com> --- sound/soc/blackfin/bf5xx-ad193x.c | 2 +- sound/soc/codecs/ad193x.c | 8 ++++++-- sound/soc/codecs/ad193x.h | 5 +++-- sound/soc/soc-cache.c | 23 +++++++++++++++++++++++ 4 files changed, 33 insertions(+), 5 deletions(-) diff --git a/sound/soc/blackfin/bf5xx-ad193x.c b/sound/soc/blackfin/bf5xx-ad193x.c index d40cf68..417200b 100644 --- a/sound/soc/blackfin/bf5xx-ad193x.c +++ b/sound/soc/blackfin/bf5xx-ad193x.c @@ -56,7 +56,7 @@ static int bf5xx_ad193x_hw_params(struct snd_pcm_substream *substream, switch (params_rate(params)) { case 48000: - clk = 12288000; + clk = 24576000; break; } diff --git a/sound/soc/codecs/ad193x.c b/sound/soc/codecs/ad193x.c index 2374ca5..1447cc8 100644 --- a/sound/soc/codecs/ad193x.c +++ b/sound/soc/codecs/ad193x.c @@ -307,7 +307,8 @@ static int ad193x_hw_params(struct snd_pcm_substream *substream, snd_soc_write(codec, AD193X_PLL_CLK_CTRL0, reg); reg = snd_soc_read(codec, AD193X_DAC_CTRL2); - reg = (reg & (~AD193X_DAC_WORD_LEN_MASK)) | word_len; + reg = (reg & (~AD193X_DAC_WORD_LEN_MASK)) + | (word_len << AD193X_DAC_WORD_LEN_SHFT); snd_soc_write(codec, AD193X_DAC_CTRL2, reg); reg = snd_soc_read(codec, AD193X_ADC_CTRL1); @@ -361,7 +362,10 @@ static int ad193x_probe(struct snd_soc_codec *codec) dev_err(codec->dev, "failed to set cache I/O: %d\n", ret); return ret; } - +#if defined(CONFIG_SPI_MASTER) + /* asoc cache layer can't support this kind of spi registers now */ + codec->cache_bypass = 1; +#endif /* default setting for ad193x */ /* unmute dac channels */ diff --git a/sound/soc/codecs/ad193x.h b/sound/soc/codecs/ad193x.h index 9747b54..cccc2e8 100644 --- a/sound/soc/codecs/ad193x.h +++ b/sound/soc/codecs/ad193x.h @@ -34,7 +34,8 @@ #define AD193X_DAC_LEFT_HIGH (1 << 3) #define AD193X_DAC_BCLK_INV (1 << 7) #define AD193X_DAC_CTRL2 0x804 -#define AD193X_DAC_WORD_LEN_MASK 0xC +#define AD193X_DAC_WORD_LEN_SHFT 3 +#define AD193X_DAC_WORD_LEN_MASK 0x18 #define AD193X_DAC_MASTER_MUTE 1 #define AD193X_DAC_CHNL_MUTE 0x805 #define AD193X_DACL1_MUTE 0 @@ -63,7 +64,7 @@ #define AD193X_ADC_CTRL1 0x80f #define AD193X_ADC_SERFMT_MASK 0x60 #define AD193X_ADC_SERFMT_STEREO (0 << 5) -#define AD193X_ADC_SERFMT_TDM (1 << 2) +#define AD193X_ADC_SERFMT_TDM (1 << 5) #define AD193X_ADC_SERFMT_AUX (2 << 5) #define AD193X_ADC_WORD_LEN_MASK 0x3 #define AD193X_ADC_CTRL2 0x810 diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index 039b953..d9e9682 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -233,6 +233,25 @@ static unsigned int snd_soc_16_8_read_i2c(struct snd_soc_codec *codec, #define snd_soc_16_8_read_i2c NULL #endif +#if defined(CONFIG_SPI_MASTER) +static unsigned int snd_soc_16_8_read_spi(struct snd_soc_codec *codec, + unsigned int r) +{ + struct spi_device *spi = codec->control_data; + + const u16 reg = cpu_to_be16(r | 0x100); + u8 data; + int ret; + + ret = spi_write_then_read(spi, &reg, 2, &data, 1); + if (ret < 0) + return 0; + return data; +} +#else +#define snd_soc_16_8_read_spi NULL +#endif + static unsigned int snd_soc_16_8_read(struct snd_soc_codec *codec, unsigned int reg) { @@ -337,6 +356,7 @@ static struct { int (*write)(struct snd_soc_codec *codec, unsigned int, unsigned int); unsigned int (*read)(struct snd_soc_codec *, unsigned int); unsigned int (*i2c_read)(struct snd_soc_codec *, unsigned int); + unsigned int (*spi_read)(struct snd_soc_codec *, unsigned int); } io_types[] = { { .addr_bits = 4, .data_bits = 12, @@ -360,6 +380,7 @@ static struct { .addr_bits = 16, .data_bits = 8, .write = snd_soc_16_8_write, .read = snd_soc_16_8_read, .i2c_read = snd_soc_16_8_read_i2c, + .spi_read = snd_soc_16_8_read_spi, }, { .addr_bits = 16, .data_bits = 16, @@ -425,6 +446,8 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec, #ifdef CONFIG_SPI_MASTER codec->hw_write = do_spi_write; #endif + if (io_types[i].spi_read) + codec->hw_read = io_types[i].spi_read; codec->control_data = container_of(codec->dev, struct spi_device, -- 1.7.0.4

1 0

[alsa-devel] [PATCH] ASoC: Terminate WM8750 SPI device ID table
by Mark Brown 11 Aug '11

11 Aug '11

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> --- Again already applied. sound/soc/codecs/wm8750.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8750.c b/sound/soc/codecs/wm8750.c index f0ccbef..5f62300 100644 --- a/sound/soc/codecs/wm8750.c +++ b/sound/soc/codecs/wm8750.c @@ -789,6 +789,7 @@ static int __devexit wm8750_spi_remove(struct spi_device *spi) static const struct spi_device_id wm8750_spi_ids[] = { { "wm8750", 0 }, { "wm8987", 0 }, + { 0, 0 }, }; MODULE_DEVICE_TABLE(spi, wm8750_spi_id); -- 1.7.5.4

1 0

Re: [alsa-devel] Allocating buffers for USB transfers (again)
by Daniel Mack 11 Aug '11

11 Aug '11

On Thu, Aug 11, 2011 at 1:15 AM, Sarah Sharp <sarah.a.sharp(a)linux.intel.com> wrote: > On Wed, Aug 10, 2011 at 05:33:02PM +0200, Daniel Mack wrote: >> On 08/10/2011 04:32 PM, Alan Stern wrote: >> >Looking at the driver's current code, it appears that your patch >> >does not fix the bug properly. Using discontiguous regions in the >> >transfer buffer is perfectly okay. The real problem is later on, >> >where you do: >> > >> >if (send_it) { out->number_of_packets = FRAMES_PER_URB; >> > >> >This should be >> > >> >out->number_of_packets = outframe; >> > >> >The way it is now, the USB stack will try to use data from all the >> >frame descriptors, and the last few will be stale because the loop >> >doesn't set them. >> >> That's actually true, even though it doesn't seem to cause any trouble. >> I tested everything here of course, and the output URBs return back from >> the USB stack with their length fields zeroed out, which then >> causes the stack to send packets with zero-length fields at the end. > > Actually, it causes system hangs when the driver is loaded on a device > attached to a USB 3.0 port, as Alan Stern pointed out: > > https://bugzilla.kernel.org/show_bug.cgi?id=40702 Yes, I've noticed this. > Please don't submit zero-length transfers. The xHCI driver just isn't > able to handle it. Arguably, it probably should have just rejected your > URB when it found a zero length buffer, so I'll probably be submitting a > patch to fix that. According to the spec, sending zero-length frames should be fine, no? Is there any particular reason why XCHI can't handle this while EHCI can? And does my patch fix the driver for XHCI? Daniel

1 0

[alsa-devel] [PATCH] ASoC: Add missing break in WM8994 probe
by Mark Brown 10 Aug '11

10 Aug '11

This error would have no effect on current silicon revisions, the fall through case has the same behaviour. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 1a9ef7f..e1fb844 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3042,6 +3042,7 @@ static int wm8994_codec_probe(struct snd_soc_codec *codec) wm8994->hubs.dcs_readback_mode = 2; break; } + break; case WM8958: wm8994->hubs.dcs_readback_mode = 1; -- 1.7.5.4

2 1

Re: [alsa-devel] Allocating buffers for USB transfers (again)
by Daniel Mack 10 Aug '11

10 Aug '11

On 08/10/2011 04:32 PM, Alan Stern wrote: > Looking at the driver's current code, it appears that your patch > does not fix the bug properly. Using discontiguous regions in the > transfer buffer is perfectly okay. The real problem is later on, > where you do: > > if (send_it) { out->number_of_packets = FRAMES_PER_URB; > > This should be > > out->number_of_packets = outframe; > > The way it is now, the USB stack will try to use data from all the > frame descriptors, and the last few will be stale because the loop > doesn't set them. That's actually true, even though it doesn't seem to cause any trouble. I tested everything here of course, and the output URBs return back from the USB stack with their length fields zeroed out, which then causes the stack to send packets with zero-length fields at the end. However, doing it right doesn't harm either. Thanks for spotting. Takashi, can you apply this version? Thanks, Daniel

2 1

Re: [alsa-devel] [PATCH] ASoC: soc-io: Add CONFIG_REGMAP_I2C/CONFIG_REGMAP_SPI guards for regmap_init_i2c/regmap_init_spi
by Mark Brown 10 Aug '11

10 Aug '11

On Wed, Aug 10, 2011 at 04:24:12PM +0800, Axel Lin wrote: > In the case of "make da8xx_omapl_defconfig;make", the SPI support is disabled. > Thus calling regmap_init_spi in soc-io.c has below build error. Applied, thanks.

1 0

[alsa-devel] [PATCH] sound/pci/azt3328.c: adjust error handling code to include debugging code
by Julia Lawall 10 Aug '11

10 Aug '11

From: Julia Lawall <julia(a)diku.dk> snd_azf3328_dbgcallenter is called at the very beginning of the function, so it could be useful to call snd_azf3328_dbgcallleave at all exit points. Signed-off-by: Julia Lawall <julia(a)diku.dk> --- sound/pci/azt3328.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/sound/pci/azt3328.c b/sound/pci/azt3328.c index e4d76a2..579fc0d 100644 --- a/sound/pci/azt3328.c +++ b/sound/pci/azt3328.c @@ -2625,16 +2625,19 @@ snd_azf3328_probe(struct pci_dev *pci, const struct pci_device_id *pci_id) int err; snd_azf3328_dbgcallenter(); - if (dev >= SNDRV_CARDS) - return -ENODEV; + if (dev >= SNDRV_CARDS) { + err = -ENODEV; + goto out; + } if (!enable[dev]) { dev++; - return -ENOENT; + err = -ENOENT; + goto out; } err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); if (err < 0) - return err; + goto out; strcpy(card->driver, "AZF3328"); strcpy(card->shortname, "Aztech AZF3328 (PCI168)");

3 4

[alsa-devel] Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers.
by ashwanik 10 Aug '11

10 Aug '11

Hi All, I am using USB mic on omap4 board(panda). When I am trying to use "gst-launch-0.10 pulsesrc ! pulsesink" pipeline, getting 1-2 sec audio delay and following error messages: E: alsa-source.c: ALSA woke us up to read new data from the device, but there was actually nothing to read! E: alsa-source.c: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. E: alsa-source.c: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. I am attaching the complete log. please find pointers. Regards, Ashwani

1 0

[alsa-devel] [PATCH] ASoC: Specify register defaults for WM8958 MICBIAS1 and MICBIAS2
by Mark Brown 10 Aug '11

10 Aug '11

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994-tables.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8994-tables.c b/sound/soc/codecs/wm8994-tables.c index a87adbd..13e5a01 100644 --- a/sound/soc/codecs/wm8994-tables.c +++ b/sound/soc/codecs/wm8994-tables.c @@ -1635,8 +1635,8 @@ const u16 wm8994_reg_defaults[WM8994_CACHE_SIZE] = { 0x0000, /* R58 - MICBIAS */ 0x000D, /* R59 - LDO 1 */ 0x0003, /* R60 - LDO 2 */ - 0x0000, /* R61 */ - 0x0000, /* R62 */ + 0x0039, /* R61 - MICBIAS1 */ + 0x0039, /* R62 - MICBIAS2 */ 0x0000, /* R63 */ 0x0000, /* R64 */ 0x0000, /* R65 */ -- 1.7.5.4

2 1

Re: [alsa-devel] Allocating buffers for USB transfers (again)
by Daniel Mack 10 Aug '11

10 Aug '11

On Thu, Jul 7, 2011 at 5:16 PM, Florian Mickler <florian(a)mickler.org> wrote: > [adding Robert Hancock] > see here for the whole thread: https://lkml.org/lkml/2011/7/7/150 > > 2011/7/7 Daniel Mack <zonque(a)gmail.com>: >> On Thu, Jul 7, 2011 at 2:33 PM, Oliver Neukum <oliver(a)neukum.org> wrote: >> >>> PS: Do you still see this if you enable 64bit DMA for EHCI? >> >> The problem is that I personally don't see that issue at all. I even >> installed 4GB of RAM to my development machine last year to be able to >> reproduce this, but I can't, even when the memory allocator is under >> heavy load. The only people who see this effect are Pedro Ribeiro and >> William Light (both in Cc:), and both have been very helpful in trying >> patches and reporting back in detail. Which instructions could we >> probably give to these people to finally hunt this issue down? >> >> Daniel >> >> > > Did someone affected already try the suggestions from Robert : > http://lkml.org/lkml/2010/4/10/66 > > That is checking if it really is a 64bit vs 32bit issue by booting > with mem=4096M ? So it seems we can finally close this issue. I got myself a new laptop recently, and was actually happy to see that this machine showed the bug as well. So I started investigating on what's going on and after hours of debugging in the wrong area, I stumbled over a bug in my own code. The patch attached fixes the problem for me, and William (one of the very few people who saw it, too) also reported green light. However, it remains a puzzle to me where the acutal root cause is for this is, and I would much like to know. Let me briefly explain what I'm seeing. The driver operates in a mode so that it copies the layout of its inbound stream to the output stream, thus guaranteeing the data rate of outbound data is equal to that of the input stream. For that, I walk the isochronous frames of each received urb and prepare an urb for sending that has the same iso packet structure in terms of lengths and offsets, jumping over and ignoring frames that are actually invalid (status != 0). So here was the problem: if there were frames with any different status field, the driver would calculate the wrong offset and the playback stream will have artefacts. So, a classic bug you might think, and the fix is trivial. However, what I really don't understand is why this wasn't observed any earlier by any of the many users, and why iit makes a difference which type of memory I use for this. Recall that my original patch that allocates DMA coherent memory for the transfer buffers also fixes the problem just fine. Or put it that way: when allocating "normal" memory using kmalloc(), the stream appears to have "holes" in the iso packet structure, while with DMA coherent memory, the layout is different. And all this only happens on fairly new 64bit-enabled machines. Can anyone explain this? Many thanks to everyone involved in this - and especially to William and Pedro who spent a lot of time in trying my patches and sending me debug information. Daniel

1 0