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

Re: [alsa-devel] [PATCH] soc/sh: Fix I2C dependency for SND_FSI_AK4642
by Mark Brown 15 Jun '10

15 Jun '10

On Tue, Jun 15, 2010 at 04:49:07PM +0200, Peter Hüwe wrote: > So maybe even move the dependency up to SND_SOC_SH4_FSI > since both codecs rely on I2C? No, while the two boards in mainline currently may need I2C obviously other board designs with other control interfaces are possible so it should be on the individual boards.

1 0

[alsa-devel] ASoC updates for 2.6.36
by Mark Brown 15 Jun '10

15 Jun '10

The following changes since commit 9eb34302681d3f6cf0b186aae31ba08cbd5f22fb: Merge branch 'for-2.6.36' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into topic/asoc (2010-06-07 18:38:56 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.36 Mostly minor cleanups plus the fix from 2.6.35. Grant Likely (1): ASoC: Remove unused header from MPC5200 PSC driver Kuninori Morimoto (5): ASoC: header cleanup for FSI ASoC: header cleanup for FSI-AK4642 ASoC: header cleanup for FSI-DA7210 ASoC: header cleanup for ak4642 ASoC: header cleanup for da7210 Mark Brown (2): Merge branch 'ep93xx' into for-2.6.36 Merge branch 'for-2.6.35' into for-2.6.36 Ryan Mallon (2): EP93xx: Add i2s core support ASoC: EP93xx: Add Snapper CL15 i2s audio support Sudhakar Rajashekhara (1): ASoC: DaVinci: Fix McASP hardware FIFO configuration Takashi Iwai (1): Merge branch 'for-2.6.35' of git://git.kernel.org/.../broonie/sound-2.6 into fix/asoc Wan ZongShun (1): ASoC: NUC900: patch for fix build error arch/arm/mach-ep93xx/clock.c | 67 ++++++++++- arch/arm/mach-ep93xx/core.c | 67 ++++++++++ arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h | 10 ++ arch/arm/mach-ep93xx/include/mach/platform.h | 3 + arch/arm/mach-ep93xx/snappercl15.c | 1 + sound/soc/codecs/ak4642.c | 8 -- sound/soc/codecs/da7210.c | 9 -- sound/soc/davinci/davinci-mcasp.c | 2 - sound/soc/ep93xx/Kconfig | 9 ++ sound/soc/ep93xx/Makefile | 3 + sound/soc/ep93xx/snappercl15.c | 150 +++++++++++++++++++++++ sound/soc/fsl/mpc5200_psc_i2s.c | 1 - sound/soc/fsl/mpc5200_psc_i2s.h | 12 -- sound/soc/nuc900/nuc900-audio.c | 2 +- sound/soc/nuc900/nuc900-pcm.c | 2 +- sound/soc/sh/fsi-ak4642.c | 9 -- sound/soc/sh/fsi-da7210.c | 9 -- sound/soc/sh/fsi.c | 9 -- 18 files changed, 311 insertions(+), 62 deletions(-) create mode 100644 sound/soc/ep93xx/snappercl15.c delete mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h

2 1

[alsa-devel] ASoC update for 2.6.35
by Mark Brown 15 Jun '10

15 Jun '10

The following changes since commit e854df613fe934c94a0b39eccb4104e72ccbbded: Merge branch 'for-2.6.35' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into fix/asoc (2010-06-02 14:17:44 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.35 Sudhakar Rajashekhara (1): ASoC: DaVinci: Fix McASP hardware FIFO configuration There is a fix for duplicate enables of the DMA, the changelog is detailed. sound/soc/davinci/davinci-mcasp.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-)

2 1

[alsa-devel] [PATCH 0/6] ASoC: header cleanup
by Kuninori Morimoto 15 Jun '10

15 Jun '10

Dear Mark These are header cleanup patches Kuninori Morimoto (5): ASoC: header cleanup for FSI ASoC: header cleanup for FSI-AK4642 ASoC: header cleanup for FSI-DA7210 ASoC: header cleanup for ak4642 ASoC: header cleanup for da7210 Not so important Best regards -- Kuninori Morimoto

3 8

Re: [alsa-devel] [PATCH] ASoC: DaVinci: Fix McASP hardware FIFO configuration
by Mark Brown 15 Jun '10

15 Jun '10

On Fri, Jun 11, 2010 at 07:24:51PM +0530, Sudhakar Rajashekhara wrote: > On DA830/OMAP-L137 and DA850/OMAP-L138 SoCs, the McASP peripheral > has FIFO support. This FIFO provides additional data buffering. It > also provides tolerance to variation in host/DMA controller response > times. More details of the FIFO operation can be found at Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] soc/sh: Fix I2C dependency for SND_FSI_AK4642
by Mark Brown 14 Jun '10

14 Jun '10

On Mon, Jun 14, 2010 at 05:39:41PM +0200, Peter Huewe wrote: > bool "FSI-AK4642 sound support" > depends on SND_SOC_SH4_FSI > select SND_SOC_AK4642 > + select I2C I'd have thought a depends was more appropriate. Arguably you want to depend on the SH I2C driver since the driver is useless without the relevant I2C controller.

1 0

[alsa-devel] [PATCH] ASoC: DaVinci: Fix McASP hardware FIFO configuration
by Sudhakar Rajashekhara 14 Jun '10

14 Jun '10

On DA830/OMAP-L137 and DA850/OMAP-L138 SoCs, the McASP peripheral has FIFO support. This FIFO provides additional data buffering. It also provides tolerance to variation in host/DMA controller response times. More details of the FIFO operation can be found at http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spr… Existing sequence of steps for audio playback/capture are: a. DMA configuration b. McASP configuration (configures and enables FIFO) c. Start DMA d. Start McASP (enables FIFO) During McASP configuration, while FIFO was being configured, FIFO was being enabled in davinci_hw_common_param() function of sound/soc/davinci/davinci-mcasp.c file. This generated a transmit DMA event, which gets serviced when DMA is started. https://patchwork.kernel.org/patch/84611/ patch clears the DMA events before starting DMA, which is the right thing to do. But this resulted in a state where DMA was waiting for an event from McASP (after step c above), but the event which was already there, has got cleared (because of step b above). The fix is not to enable the FIFO during McASP configuration as FIFO was being enabled as part of McASP start. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj(a)ti.com> --- Applies to latest of Linus's tree. sound/soc/davinci/davinci-mcasp.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 79f0f4a..d395509 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -612,7 +612,6 @@ static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream) NUMDMA_MASK); mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, ((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK); - mcasp_set_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE); } if (dev->rxnumevt && stream == SNDRV_PCM_STREAM_CAPTURE) { @@ -623,7 +622,6 @@ static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream) NUMDMA_MASK); mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, ((dev->rxnumevt * rx_ser) << 8), NUMEVT_MASK); - mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE); } } -- 1.5.6

2 1

Re: [alsa-devel] [PATCH 3/4] ALSA: usb-audio: parse UAC2 sample rate ranges correctly
by Daniel Mack 14 Jun '10

14 Jun '10

On Fri, Jun 11, 2010 at 10:59:44PM +0800, Alex Lee wrote: > If the device has a variable clock, it may report a RES of only 1. So you > may end up with thousands (and even millions) of sample rates. It might be > better to have separate code to cater to discrete clocks vs variable clocks. Just for the records: this is exactly what Mac OS X does, and it will comsume 100% CPU when a device with such descriptors is plugged in. So even though this is now sanely handled by ALSA, it really shouldn't be done that way by implementors. Daniel

1 0

Re: [alsa-devel] [PATCH 1/1] ALSA: hda - Fix line-in for mb5 model MacBook (Pro) 5, 1 / 5, 2
by Takashi Iwai 14 Jun '10

14 Jun '10

At Mon, 14 Jun 2010 16:31:21 +0930, Alex Murray wrote: > > Takashi - There is no incompatibilty, both are the same - the mb5 model > is used for all MacBook (Pro) 5,1 / 5,2 models, the only differnce > between the Pro and non-Pro is the Pro has the subwoofer (LFE) which the > non-Pro lacks. > > You can see here > http://ubuntuforums.org/showpost.php?p=9444153&postcount=3 for a copy > of /proc/asound/card0/codec#0 on a MacBook 5,1 (i.e. not Pro) which > confirms the line-out is 0x7 for that model as well - I've tested this > directly on my MacBook Pro 5,1 - so I am 100% confident this is correct > for both Pro and non-Pro models, unless you have evidence otherwise? OK, then it's all green. I applied the patch now. Thanks for a quick response! Takashi

1 0

Re: [alsa-devel] [PATCH 1/1] ALSA: hda - Fix line-in for mb5 model MacBook (Pro) 5, 1 / 5, 2
by Takashi Iwai 14 Jun '10

14 Jun '10

At Mon, 14 Jun 2010 12:08:43 +0930, murray.alex(a)gmail.com wrote: > > From: Alex Murray <murray.alex(a)gmail.com> > > The line-in input is 0x7 not 0x2 for MacBook (Pro) 5,1 / 5,2 models > > Signed-off-by: Alex Murray <murray.alex(a)gmail.com> MB5 != MBP5, so I suspect this might be rather the incompatibility between them... Takashi > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index 17d4548..007f96b 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -6948,7 +6948,7 @@ static struct hda_input_mux mb5_capture_source = { > .num_items = 3, > .items = { > { "Mic", 0x1 }, > - { "Line", 0x2 }, > + { "Line", 0x7 }, > { "CD", 0x4 }, > }, > }; > @@ -7469,8 +7469,8 @@ static struct snd_kcontrol_new alc885_mb5_mixer[] = { > HDA_BIND_MUTE ("LFE Playback Switch", 0x0e, 0x02, HDA_INPUT), > HDA_CODEC_VOLUME("Headphone Playback Volume", 0x0f, 0x00, HDA_OUTPUT), > HDA_BIND_MUTE ("Headphone Playback Switch", 0x0f, 0x02, HDA_INPUT), > - HDA_CODEC_VOLUME("Line Playback Volume", 0x0b, 0x02, HDA_INPUT), > - HDA_CODEC_MUTE ("Line Playback Switch", 0x0b, 0x02, HDA_INPUT), > + HDA_CODEC_VOLUME("Line Playback Volume", 0x0b, 0x07, HDA_INPUT), > + HDA_CODEC_MUTE ("Line Playback Switch", 0x0b, 0x07, HDA_INPUT), > HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x01, HDA_INPUT), > HDA_CODEC_MUTE ("Mic Playback Switch", 0x0b, 0x01, HDA_INPUT), > HDA_CODEC_VOLUME("Line Boost", 0x15, 0x00, HDA_INPUT), > @@ -7853,10 +7853,9 @@ static struct hda_verb alc885_mb5_init_verbs[] = { > {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, > {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE}, > > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, > + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0x1)}, > + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0x7)}, > + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0x4)}, > { } > }; > > -- > 1.7.0.4 >

1 0